| 02:24:36 | Russ|werk | hey tim |
| 02:31:59 | BZFlag | hey |
| 02:32:08 | BZFlag | threw my back out on friday. =( |
| 02:32:39 | Russ|werk | bummer |
| 02:32:44 | Russ|werk | so thats where you've been |
| 02:33:17 | Russ|werk | have you tried blob cvs lately? |
| 02:34:44 | BZFlag | not in a week or so. |
| 02:35:36 | Russ|werk | seems to break on the 17th |
| 02:40:21 | Russ|werk | BZFlag: I think I will go for one of those little handhelds, what kind of development are you looking for? |
| 02:46:47 | BZFlag | games, qt stuff, kernel mods, etc. I think you'll find something you want to hack on. ;-) |
| 02:48:51 | BZFlag | hates cleaning up other peoples machines after they have been rooted. |
| 02:48:53 | Russ|werk | I'm usually good with kernel stuff |
| 02:49:03 | Russ|werk | BZFlag: rh 6.2 box? |
| 02:49:28 | BZFlag | yeah, how'd you guess? ;=) |
| 02:50:03 | Russ|werk | lots of cd's floating around |
| 02:50:55 | BZFlag | yep. any open things other that what updates.r.c covers? |
| 02:51:05 | BZFlag | and where's the best openssh to install? |
| 02:51:43 | Russ|werk | dunno, I just trust the debian people |
| 02:52:23 | BZFlag | yeah, if it was a local box I'd just nuke it and install debian. ;-) |
| 02:52:33 | Russ|werk | its remote? |
| 02:53:32 | BZFlag | yeah, I'm in UT and it's in boston. |
| 02:53:59 | BZFlag | it's logged into a bunch of irc servers, recording passwords etc. you get the picture. |
| 02:54:40 | Russ|werk | do you know what kit it is? |
| 02:55:35 | BZFlag | no. I can tell you what's been hacked though. |
| 02:56:28 | Russ|werk | have you seen the chkrootkit package? |
| 02:58:07 | BZFlag | nope. |
| 02:59:03 | Russ|werk | http://www.chkrootkit.org/ |
| 03:01:18 | Russ|werk | anyway, time to go |
| 09:56:15 | Sammy | is away : dinner ... |
| 10:32:19 | seletz | morning |
| 10:33:01 | erikm | morning |
| 10:34:45 | i0stream | boot loader channel |
| 10:34:48 | i0stream | how neat :) |
| 10:35:14 | seletz | erikm: what's those "cvs is broken" messages? Did you see them? |
| 10:35:22 | erikm | seletz: yeah, but it isn't |
| 10:35:28 | erikm | seletz: I just replied |
| 10:35:40 | seletz | ah, ok. phew. |
| 10:35:52 | seletz | :q! |
| 10:36:01 | seletz | sorry wronk window :/ |
| 10:36:48 | erikm | :q :q! :w :w! :wq :wq! :quit :quit! :help quit :helpquit :quit help |
| 10:36:48 | erikm | :quithelp :quit help! :Q :QUIT ^Q ^X^C ^C^C^C^C :QUITDAMMIT!!! ^[:wq |
| 10:36:48 | erikm | s |
| 10:36:53 | erikm | seletz: ;0 |
| 10:36:57 | erikm | seletz: ;) even |
| 10:38:01 | seletz | is _really_ tired. |
| 10:38:09 | seletz | gets caffeine _now_ |
| 10:38:59 | mmatten | hoi |
| 10:39:07 | erikm | hi |
| 10:46:33 | erikm | hello BZFlag |
| 10:46:46 | erikm | BZFlag: isn't this a bit early/late for you? |
| 10:50:46 | seletz | brb, reboot |
| 10:55:44 | BZFlag | trouble sleeping tonight, so I'm hacking a bit. |
| 12:34:41 | seletz | hi again |
| 12:36:21 | erikm | rehi |
| 12:38:00 | seletz | erikm: when one gets used to mutt, its quite cool. Just works, like vi :) |
| 12:38:19 | erikm | *nod* |
| 12:38:57 | seletz | and all of a sudden patches get accepted by the patch system :} |
| 12:39:05 | erikm | hehe |
| 12:39:34 | seletz | suspects a filter: if ( !agent =="MUTT" ) then reject; |
| 12:39:48 | seletz | :) |
| 12:41:04 | erikm | no, I've submitted patches with Elm as well |
| 12:58:22 | seletz | erikm: hmm, ATM there's _no_ way to flash arbitary memory areas in blob, am i right? |
| 13:00:01 | BZFlag | seletz: correct. also true for erase. |
| 13:00:11 | BZFlag | I plan on adding those this week. |
| 13:00:44 | seletz | BZFlag: i have those commands in system3.c .... |
| 13:01:20 | seletz | BZFlag: maybe i should just move them over to src/commands |
| 13:02:32 | BZFlag | yes, please. |
| 13:02:35 | BZFlag | syntax? |
| 13:03:01 | seletz | fwrite srcadr destadr size(bytes) |
| 13:03:17 | seletz | ferase adr size(bytes) |
| 13:03:20 | BZFlag | I was planning to add "erase 0x00020000-0x00040000" etc. |
| 13:03:40 | seletz | do we need the "-"? |
| 13:03:57 | seletz | ferase _could_ calculate the area |
| 13:04:07 | BZFlag | start and end, instead of start and length. |
| 13:04:30 | seletz | ok, when i think of it, yes. Thats more useful ... |
| 13:04:53 | seletz | should i check for erase zize boundary etc? |
| 13:05:05 | seletz | s/zize/size/ |
| 13:05:12 | BZFlag | where does fwrite get it's data? |
| 13:05:18 | seletz | memory |
| 13:05:35 | seletz | i have a download cmd which downloads to memory |
| 13:05:44 | BZFlag | so you xdownload ramdisk (or something) then fwrite by address? |
| 13:05:51 | seletz | yup |
| 13:05:57 | BZFlag | ah, download syntax? |
| 13:06:07 | seletz | that way i'm able to do a crc or md5 _before_ flashing :) |
| 13:06:31 | seletz | dlfile destadr file_length |
| 13:07:18 | seletz | that cmd does not use xmodem ATM, old uuencode stuff. Also does no md5/crc32 sum. |
| 13:07:24 | BZFlag | I was thinking of doing the same for *download, ie: xdownload 0xd0000000-0xd0040000 |
| 13:07:55 | seletz | yup, we need that. |
| 13:08:08 | BZFlag | I suppose end is not required for that, but is a good sanity check, |
| 13:08:14 | seletz | maybe you could hack up xmodem support into my dlfile or xdownload? |
| 13:08:43 | seletz | IMHO file length is better, or does xmodem deliver the length? |
| 13:14:59 | BZFlag | xmodem pads to block size |
| 13:15:25 | seletz | hmmm, XModemReceive() gets buffer an length of buffer. I think we should take file length |
| 13:15:47 | BZFlag | perhaps |
| 13:16:05 | seletz | _and_ check for end addr? |
| 13:16:30 | seletz | syntax: xdown staradr-endadr length |
| 13:17:05 | seletz | or xdown length start-end |
| 13:17:11 | seletz | with -end optional |
| 13:18:59 | seletz | ok, I'll hack it that way and commit it, as we need that _now_ :) |
| 13:19:22 | seletz | I'll add it to src/commands |
| 13:20:02 | seletz | Ok? |
| 13:35:16 | seletz | erikm: any opinions against that? |
| 13:36:04 | seletz | doesn't want to implement things which will purged afterwards :) |
| 13:39:47 | erikm | seletz: arbitrary flashing will be there when I finish the partitioning code |
| 13:41:12 | erikm | seletz: I rather have the problem solved right than some kind of hack |
| 13:45:36 | seletz | erikm: ok, i certanly dont want to make hacks. Perhaps we can add this command and re-use it later? |
| 13:45:57 | seletz | erikm: just let us agree on an interface or so. |
| 13:47:23 | seletz | erikm: my problem now is: i have an assabet/neponset where i want to boot with cramfs using a initrd. I need to flash initrd and cramfs images. |
| 13:47:43 | erikm | *nod* I know. we need a memory allocator |
| 13:48:04 | seletz | hmm? Why? Some sort of ressource management? |
| 13:48:07 | erikm | yes |
| 13:48:39 | erikm | partitions that have to be loaded need some memory space |
| 13:48:41 | seletz | ah, keep a linked list of aloc'd blocks. Ok, maybe i can come up with something like that. |
| 13:49:01 | erikm | the kernel needs to be loaded at 0xc0008000, ramdisks can be loaded anywhere |
| 13:49:02 | seletz | like in linux: request_ressource() and free_ressource(). |
| 13:49:19 | erikm | better name it request_mem() and free_mem() |
| 13:49:34 | erikm | and also have request_mem_fixed() |
| 13:49:47 | seletz | such ressources then could be flashed. yes, the names were just examples. |
| 13:49:50 | erikm | (which requests a piece of memory at a fixed location) |
| 13:50:02 | erikm | the information is already in the flash |
| 13:50:28 | erikm | a partition that has the load flag set and specifies a load address needs a memory region at that address |
| 13:52:32 | seletz | hmmm |
| 13:52:51 | erikm | if you burn the information fixed in the flash, you can't cope with memory extension boards (like the LART 64MB board) |
| 13:53:22 | seletz | Partitions would be autoloaded to memory? |
| 13:53:38 | seletz | Or just the partition "table" |
| 13:54:01 | erikm | no, partitions. read include/blob/partition.h |
| 13:54:11 | seletz | looks |
| 13:54:26 | erikm | I've put in quite a lot of comments over there |
| 13:55:28 | seletz | one mmt, brb |
| 14:12:17 | seletz | erikm: ok, now we have 2 tables, one default, one eventually on flash. |
| 14:12:28 | erikm | yes |
| 14:13:24 | seletz | erikm: all we need to do is to parse the flash partition table in "download", or give a partition number to download files/images to that memory area specified. |
| 14:13:34 | erikm | yes |
| 14:13:47 | seletz | erikm: add/remove partitions will be needed, too. |
| 14:13:52 | erikm | yes, working on that |
| 14:14:33 | seletz | erikm: ok, how about MTD kernel stuff? Will those partitions be recognized? |
| 14:14:53 | seletz | erikm: its a mess to edit the static mappings |
| 14:16:22 | seletz | erikm: may I help out somewhere to get this going? I just dont want to re-implement the wheel, but i _need_ that stuff :} |
| 14:16:52 | seletz | promises to keep the linux kernel coding style |
| 14:16:54 | seletz | :) |
| 14:18:14 | erikm | MTD doesn't recognise it yet, I'm talking with dwmw2 about it |
| 14:18:31 | BZFlag | what's the plan? |
| 14:18:42 | BZFlag | what happened to partitioning on the command line? |
| 14:18:49 | erikm | it's not there |
| 14:19:02 | BZFlag | but is it the way forward? |
| 14:19:06 | erikm | yes |
| 14:19:29 | BZFlag | is there an agreed syntax? |
| 14:19:32 | erikm | BZFlag: there is a default partition that lives in the machine dependent code, so each machine can partition like it will |
| 14:19:56 | erikm | BZFlag: so the partition table doesn't occupy a complete flash block |
| 14:20:27 | erikm | BZFlag: if however there is a normal partition table, it will overrule the default partition table |
| 14:20:36 | BZFlag | I'm thinking or writing "partition" discovery such that even blob+initrd+kernel+params all concatinated would work. |
| 14:21:12 | erikm | that would be an "all" partition, just like the third partition on SUN hard disk partition tables |
| 14:21:21 | BZFlag | I don't see the point in a "partition table" as the kernel should get fixed to take partitions on the command line anyway. |
| 14:21:39 | erikm | it won't |
| 14:21:39 | BZFlag | no, I mean with no padding. |
| 14:21:56 | erikm | there is no way the kernel will take fied partitions on the command line |
| 14:22:03 | erikm | that's jamey's idea, but it is broken |
| 14:22:04 | BZFlag | concat blob+initrd+kernel+params and flash it. |
| 14:22:15 | erikm | s/fied/fixed/ |
| 14:22:42 | BZFlag | why not? |
| 14:23:01 | erikm | if the bootloader can get the partition table layout, the kernel canb |
| 14:23:09 | seletz | BZFlag: why do you want that? Being able to flash independently is not good? |
| 14:23:44 | erikm | BZFlag: part of the reason I wrote this partition table layout is to have a proof of concept that it works this way |
| 14:23:46 | BZFlag | actually in the case of blob+initrd+kernel+params the kernel does not need to know. initrd would be copied to ram. |
| 14:24:23 | BZFlag | seletz: I still want to be able to reflash pieces and have blob move them around. |
| 14:24:39 | seletz | ah, ok. phew. |
| 14:25:07 | erikm | BZFlag: you can still make an "all" partition that contains the complete flash |
| 14:25:23 | BZFlag | I would likely use blob, then another partition with initrd+kernel+params. |
| 14:25:39 | BZFlag | erikm: _without padding_ |
| 14:25:40 | erikm | BZFlag: whatever :) |
| 14:25:50 | seletz | erikm: how is the table organized? like "TABLE P1 P2 P3" or "T1 P1 T2 P2 T3 P3..." |
| 14:26:14 | erikm | seletz: like the first |
| 14:27:06 | BZFlag | ie blob could discover the initrd,kernel,params and then when I reflash an initrd, it would move the others to the end of the new initrd |
| 14:27:50 | seletz | BZFlag: why move? |
| 14:28:14 | erikm | BZFlag: and how would blob discover kernel and params? osmosis? |
| 14:28:15 | BZFlag | seletz: so that you can flash one piece without resending everything. |
| 14:28:38 | erikm | BZFlag: KISS principle, please. you just want partitions |
| 14:28:38 | seletz | BZFlag: when initrd grows, you mean. |
| 14:29:08 | BZFlag | erikm: initrd's, zImage, params, all have length info in them. |
| 14:29:10 | seletz | I'd be happy with fixed length partitions. |
| 14:29:16 | BZFlag | blob could too for that matter. |
| 14:29:50 | erikm | BZFlag: that's not what I mean. you're adding code for some stuff that would only be used in 1% of the time |
| 14:29:56 | erikm | even less |
| 14:30:13 | erikm | BZFlag: when would one upgrade initrd? only in the development phase |
| 14:30:17 | BZFlag | so I could concat blob+initrd+kernel+params and flash at 0x0 and have blob read the bytes following blob abd discover that that is the initrd, keep going all the way through. |
| 14:30:51 | erikm | BZFlag: if blob is still the same, the flash writer will discover that and completely skip those blocks |
| 14:31:11 | erikm | BZFlag: try to flash blob twice and you will see that it doesn't erase the blocks |
| 14:31:19 | BZFlag | yes, but youy still (currently) would need to upload the complete image. |
| 14:31:31 | seletz | BZFlag: you only get a problem when images grow. Thats a real problem only for blob IMHO. |
| 14:31:54 | BZFlag | seletz: why only a problem for blob? |
| 14:32:09 | erikm | BZFlag: ok, but it is *only* used for development purposes. and for that purpose a slightly larger partition doesn't hurt |
| 14:32:28 | seletz | BZFlag: because when blob gets a added command, it grows. FS images are fixed, are they not? |
| 14:32:32 | BZFlag | erikm: huh? |
| 14:33:09 | BZFlag | a release image my well have blob+initrd+kernel+params all in one partition, no? |
| 14:33:25 | erikm | yes, a *RELEASE* image |
| 14:33:37 | erikm | but a release image doesn't need all that auto-move magic |
| 14:33:41 | BZFlag | blob needs to be able to discover that in order to load the right pieces in the right places. |
| 14:33:49 | erikm | so we are not going to need the feature anyway |
| 14:34:03 | erikm | and because we aren't there is no point in adding it |
| 14:34:23 | seletz | gets confused |
| 14:34:34 | BZFlag | perhaps. but if the partition discovery code copies each piece to ram, why not allow it to reflash the same pieces? |
| 14:34:49 | erikm | it doesn't copy each piece to ram |
| 14:35:01 | seletz | you just follow the link pointers |
| 14:35:08 | BZFlag | kernel, initrd, params? which one it not copied to ram? |
| 14:35:21 | erikm | it only copies partitions to ram that have the BLOB_PART_FLAG_LOAD flags set |
| 14:35:36 | BZFlag | and in this case they all have it set, no? |
| 14:35:48 | erikm | so JFFS2 and cramfs images aren't loaded to ram |
| 14:36:05 | BZFlag | you will note I did not include a jffs2 or cramfs image. |
| 14:36:34 | seletz | BZFlag: you have the idea of a "master" partition? |
| 14:36:59 | seletz | BZFlag: which only holds strictly blob+initrd+kernel+params ? |
| 14:37:01 | erikm | BZFlag: if you have the BLOB_PART_FLAG_LOAD set, they will be loaded |
| 14:37:13 | BZFlag | jffs2/cramfs (well mtd mounted ones anyway) would need partitions. |
| 14:37:51 | BZFlag | seems to me that blob should "know" what jffs2 looks like and know not to load it. |
| 14:37:59 | erikm | no |
| 14:38:11 | erikm | blob shouldn't be too smart about what is in a partition |
| 14:38:12 | BZFlag | then a "ramdisk" partition could have whatever the user wants. |
| 14:38:14 | seletz | what about "my_funky_rrom_fs" type? |
| 14:38:46 | seletz | and "another_fs_type"? no, i dont think we should parse the image contents. |
| 14:39:05 | seletz | _except_ we would be able to load the kernel from it of course. |
| 14:39:06 | erikm | seletz: except for the images where we know how to boot a kernel from it |
| 14:39:06 | BZFlag | erikm: why not? a small set of magic values would allow smarter partition discovery. |
| 14:39:28 | erikm | BZFlag: because that limits your flexibility |
| 14:40:05 | seletz | what when JFFS people change their magic values? |
| 14:40:14 | seletz | it breaks. bad. |
| 14:40:34 | BZFlag | I disagree. a partition table could still override discovered entries, and it would still have defaults in case discovery only finds erased blocks etc. |
| 14:41:01 | erikm | BZFlag: that's what the default partition table is for |
| 14:41:08 | BZFlag | seletz: then you change/add the new magic. |
| 14:41:12 | erikm | BZFlag: I repeat: KISS principle |
| 14:41:25 | seletz | I still dont understand why you need the block move feature. |
| 14:41:48 | BZFlag | erikm: this could be very simple and easy to follow. just have the magics in a table and be able to determin length. |
| 14:42:02 | BZFlag | seletz: let's forget the move for now... |
| 14:42:07 | seletz | ok |
| 14:42:13 | erikm | BZFlag: seletz already showed you that it breaks with JFFS3 |
| 14:42:25 | erikm | BZFlag: while a simple partition table doesn't break |
| 14:42:43 | erikm | BZFlag: blob should not *care* about *what* is in a partition |
| 14:43:02 | BZFlag | as I mentioned jffs* would need a partition table, cause the kernel would be erasing any blocks that the fs occupied. |
| 14:43:38 | seletz | BZFlag: you _can_ have your all-in-one partition. Its just how you create the default partition in blob, no? |
| 14:43:46 | BZFlag | seletz: no. |
| 14:44:11 | BZFlag | having a "partition table" assumes that entries start at flash block boundries, no? |
| 14:44:24 | erikm | BZFlag: which is sane |
| 14:44:31 | BZFlag | but not optimal. |
| 14:44:34 | erikm | BZFlag: you can't erase half-a-block |
| 14:44:34 | seletz | BZFlag: why? at compile time you know the image sizes, you can create code on the fly. |
| 14:44:53 | BZFlag | you can erase and rewrite half a block. |
| 14:45:03 | erikm | BZFlag: KISS principle: don't do that |
| 14:45:26 | BZFlag | for very small flash systems, that becomes very valuable. |
| 14:45:43 | erikm | small flashes also have small blocks |
| 14:45:46 | BZFlag | especially if they have large erase block sizes for some lame reason. |
| 14:46:24 | BZFlag | ok, another advantage.... |
| 14:46:25 | seletz | BZFlag: ok, if you have small flash size, then flashing the whole area does not matter much, no? |
| 14:46:54 | BZFlag | xmodem pads files, but if you have "size discovery" code, you can determine the real size and md5s will match. |
| 14:47:09 | erikm | BZFlag: KISS principle --> use YMODEM |
| 14:47:17 | BZFlag | seletz: forget the move.... I'm talking discovery. |
| 14:47:45 | BZFlag | KISS include generic flexible reusable discovery code |
| 14:48:00 | erikm | BZFlag: and that's exactly what a partition table gives you |
| 14:48:18 | BZFlag | works for any transfer protocol, no matter where the data is loaded from or resides. |
| 14:48:24 | seletz | BZFlag: yup, me too. Let me explain again. Have the default, compiled-in partition table match exactly the sizes when you create your "all-in-one" partitions and you're set. |
| 14:49:02 | BZFlag | seletz: this does not work unless each file is padded. cause blob will only erase/program complete blocks. |
| 14:49:11 | erikm | BZFlag: KISS principle: use dd to pad the file before you upload |
| 14:49:56 | BZFlag | KISS use discovery code and avoid trying to explain the extra unneeded dd procedure to en users that ask "why is my md5 wrong?" |
| 14:49:58 | seletz | BZFlag: ok, in _your_ case, you dont need to care about berase blocks, because you'd flass the whole image at once. |
| 14:50:58 | erikm | BZFlag: discovery code severely limits the flexibility. seletz made an excellent point with his JFFS3 example. if blob wouldn't be too smart about partition discovery it would just work |
| 14:51:22 | erikm | BZFlag: and also think about the time it costs to figure out the partition boundaries. the partition table tells use *immediately* |
| 14:52:18 | seletz | BZFlag: how much of the flash area gets wasted when images are boundary-aligned? |
| 14:52:32 | seletz | depends on flashes, but in your case? |
| 14:52:33 | erikm | BZFlag: I can perfectly use JFFS2 with blob-2.0.4 because blob doesn't care about what is in the ramdisk partition. why? because blob isn't too smart |
| 14:52:48 | BZFlag | erikm: the jffs3 argument is lame. if the kernel changes to need a new params struct, blob needs patching, this is no different. |
| 14:53:00 | erikm | BZFlag: no, it's not lame |
| 14:53:39 | BZFlag | ok, and other lame jffs3 argument, my --enable-jffs2 would no longer work. |
| 14:53:50 | erikm | BZFlag: it would still work |
| 14:54:06 | BZFlag | it's silly. blob is open source. if there is a new filesystem it's trivial to add new detect code. |
| 14:54:08 | erikm | BZFlag: --enable-jffs2 is only to let blob load a kernel from jffs2. it doesn't limit the kernel |
| 14:54:28 | BZFlag | certianly more trivial than adding read support which would likely get added anyway. |
| 14:55:09 | erikm | BZFlag: and about the param struct. struct param_struct is depracated exactly because of the reason you just gave. that's why blob uses ATAG nodes: they are backwards compatible |
| 14:56:18 | BZFlag | ok, but blob can have specific jffs2/cramfs code. |
| 14:56:37 | BZFlag | and it needs a way to determine whether it should load a ramdisk partition. |
| 14:57:01 | erikm | BZFlag: that's where the BLOB_PART_FLAG_LOAD flag is for |
| 14:57:04 | BZFlag | as on my board with 16M flash, I have initrd images sometimes, and jffs2 images at other times. |
| 14:57:28 | BZFlag | If there is enough ram, I may have large initrd images. |
| 14:57:34 | seletz | BZFlag: thats why i asked about arbitary flashes. My board now gets initrd and cramfs |
| 14:57:43 | erikm | BZFlag: which is silly, but anyway :) |
| 14:58:03 | BZFlag | which is silly? |
| 14:58:10 | erikm | large ramdisks |
| 14:58:26 | BZFlag | ah. well ok, I'll give you that one. ;-) |
| 14:58:49 | erikm | BZFlag: see http://lists.arm.linux.org.uk/pipermail/linux-arm/2001-February/000545.html |
| 14:58:53 | BZFlag | but a small ramdisk or a large jffs2 should both be able to fit in the ramdisk partition. |
| 14:59:03 | erikm | yes |
| 14:59:16 | erikm | but JFFS2 needs to be erase block aligned |
| 14:59:25 | BZFlag | and a larger than ram jffs2 needs to be flashable. |
| 14:59:26 | seletz | there should be noc such thing as a "ramdisk partition". Thats silly. |
| 14:59:39 | seletz | There should be only "partiotions" |
| 14:59:56 | erikm | BZFlag: larger than ram jffs2 can be done without problem |
| 15:00:09 | BZFlag | not at present.. |
| 15:00:13 | erikm | BZFlag: even now |
| 15:00:17 | erikm | well, not now |
| 15:00:26 | erikm | as soon as the partition table stuff is ready |
| 15:00:46 | BZFlag | ok, how does one upload/flash in the brave new world? |
| 15:00:55 | seletz | :) |
| 15:02:08 | erikm | BZFlag: first way: create two smaller partitions, cut jffs2 image in half and load each partition |
| 15:02:30 | erikm | BZFlag: now remove two partitions and make one large partition that spans both |
| 15:03:22 | erikm | BZFlag: second way: first upload small part of the jffs2 image, boot kernel, download rest of the image as normal file |
| 15:04:59 | BZFlag | well, second way works now, but erase does not erase it all. |
| 15:05:26 | erikm | erase partition should erase the whole partition |
| 15:05:28 | BZFlag | first way requires rewriting partition table every time you reflash? |
| 15:05:34 | seletz | erikm: sure we could add something like a blocked upload/flash which uses a buffer and MD5sums each block. |
| 15:05:44 | BZFlag | looks... |
| 15:06:35 | erikm | BZFlag: note that a partition can be changed without having to write it to flash. I designed it like this with exactly this feature in mind |
| 15:07:47 | BZFlag | ahh, yes. current source does not actually implement/use BLOB_PART_FLAG_LOAD correct? |
| 15:07:56 | erikm | no, it's a work in progress |
| 15:08:08 | BZFlag | so my "ramdisk" partition is marked as being smaller at present. |
| 15:08:28 | BZFlag | bloc erases what it knows, but the kernel sees more. |
| 15:08:30 | erikm | right now the code doesn't even do anything |
| 15:08:50 | seletz | erikm: you need to change the "size" field, too, dont'you? |
| 15:08:52 | erikm | but I commited it so people would look at it |
| 15:09:19 | erikm | seletz: what do you mean? "size" is the partition size |
| 15:09:35 | erikm | seletz: you want a "load_size" entry in it? |
| 15:09:50 | BZFlag | can we do away with loading ramdisks into ram and just pass the flash address to the kernel? |
| 15:09:58 | seletz | erikm: yup, when you have that "split" upload scenario, you have to makr one as "invalid" and change the first partition entry's size field. |
| 15:10:04 | erikm | BZFlag: hmm, don't know |
| 15:10:18 | BZFlag | course if one was downloaded, it would be a ram address. |
| 15:10:43 | BZFlag | the first thing initrd load does is decompress fromt the address blob passes into another address. |
| 15:10:48 | BZFlag | that should work from flash. |
| 15:10:54 | erikm | asks rmk |
| 15:11:51 | erikm | btw: http://kerneltrap.org/node.php?id=46 <-- interview with rik van riel |
| 15:19:27 | BZFlag | what about kernel+params from jffs2/cramfs files? |
| 15:19:54 | BZFlag | can params include partition info? |
| 15:20:07 | erikm | no, it shouldn't |
| 15:20:17 | BZFlag | shouldn't or can't? |
| 15:20:17 | seletz | that would be strange, no? |
| 15:20:37 | BZFlag | not if the partitions on the kernel command line is the brave new world. |
| 15:20:40 | erikm | it's completely different. a partition table tells how the flash is organised. a param table tells how blob should behave |
| 15:20:45 | BZFlag | then it's just another kernel option. |
| 15:21:41 | erikm | BZFlag: forget about the partitions on command line. the concept is broken and it's not going to make it into the kernel |
| 15:22:28 | seletz | erikm: im just curious: how does blob tell the kernel about partitions, then? tag lists? |
| 15:22:41 | erikm | seletz: param table in flash, just how it should |
| 15:22:54 | erikm | s/param/partition/ |
| 15:23:26 | seletz | erikm: ok, then the kernel parses the table again. Ok, the kernel loads it, no parsing. |
| 15:24:19 | erikm | seletz: a partition table is a fundamental property of a block device. |
| 15:25:15 | BZFlag | does not agree, but oh well. |
| 15:25:36 | seletz | erikm: ah. didtnt realize that ... Well, then MTD folks will have to add a "parse blob partitions" option & code :/ |
| 15:25:53 | erikm | seletz: s/MTD folks/erikm/ :) |
| 15:26:00 | prpplague | are we discussing the never ending question of flash partitioning? |
| 15:26:04 | seletz | erikm: or will it be generalized |
| 15:26:14 | seletz | prpplague: hi, btw :) |
| 15:26:20 | seletz | prpplague: and yup. |
| 15:26:35 | BZFlag | seletz: that's the plan. adding that code to the bootldr, angel, etc partition table support. |
| 15:26:52 | seletz | hmm. |
| 15:27:07 | BZFlag | it's been "generalized" quite a few times now. ;-) |
| 15:27:24 | seletz | hmm-hmm. |
| 15:27:59 | seletz | ok, but better than static partitions in mtd/maps/sa1100-flash.c :) |
| 15:28:13 | BZFlag | agreed |
| 15:30:00 | seletz | The way i solved this up to now was: Install redboot, create partitions, flash them, get offsets and adresses, install blob and have the kernel recognize redboot partitions. But i _dont_ _want_ to use redboot for anything. |
| 15:32:22 | prpplague | seletz: ya i've tried redboot and several other propreitary partioning schemes and haven't found any that i like yet |
| 15:34:25 | seletz | erikm: back to the root of _my_ problem. How do i install initrd+cramfs in a more sane way now with blob? |
| 15:34:58 | seletz | erikm: can't we have a command that supports this and phase it out when partitioning support is in? |
| 15:34:59 | erikm | seletz: right now there is no solution, but once I finished the partition table it will be a breeze |
| 15:35:26 | erikm | seletz: what command do you need? |
| 15:35:37 | seletz | fwrite src dest length |
| 15:35:45 | seletz | ferase adr length |
| 15:35:59 | prpplague | erikm: so you've finalized a plan for blob partitioning? |
| 15:36:01 | seletz | xdownload dest length |
| 15:36:11 | BZFlag | seletz: pad the initrd, and hardcode the partition sizes in the kernel. |
| 15:36:29 | erikm | prpplague: yes, part of it is already in CVS |
| 15:36:41 | erikm | BZFlag: that's another way |
| 15:37:45 | seletz | ok, so my initrd mimics a ramdisk. i copy mtd tools to that initrd and flash from kernel. hrmpf. |
| 15:38:07 | erikm | seletz: otherwise just put it in your arch dependent code |
| 15:38:33 | seletz | erikm: i have it already, but i want to do this on assabet/neponset. |
| 15:39:40 | BZFlag | anyone know where to get assabet/neponset schematics? |
| 15:40:01 | erikm | BZFlag: AFAIK they are on developer.intel.com |
| 15:40:19 | BZFlag | I founds docs there, but can't fin schematics anymore. |
| 15:40:26 | erikm | oh wait |
| 15:40:34 | erikm | they stopped shipping the assabet, right? |
| 15:40:40 | BZFlag | I think so, yes. |
| 15:40:45 | seletz | BZFlag: i have two copies, so if you dont mind waiting .... |
| 15:40:54 | erikm | so the damn fools probably also pulled the schematics from the website |
| 15:40:59 | BZFlag | pdf? email to tim@rikers.org ? |
| 15:41:06 | prpplague | intel has this thing about leaving info on their site after they stop shipping it |
| 15:41:15 | seletz | BZFlag: nah, paper copies ... |
| 15:41:17 | BZFlag | erikm: yep, same as the sa1100 docs... =( |
| 15:41:29 | erikm | prpplague: yes, but only for ARM. they leave the i386 stuff on their site |
| 15:41:39 | erikm | BZFlag: that's why I put the docs on the LART site |
| 15:41:48 | seletz | maybe they're ashamed of the errata lists .... |
| 15:41:51 | BZFlag | nod |
| 15:42:08 | prpplague | erikm: they've been dropping a bunch of their raid stuff as well, most annoying |
| 15:42:29 | erikm | BZFlag: the legalese didn't forbid me doing it :) |
| 15:42:32 | Russ | erikm: that doesn't fix my problem, I've tried all that (make maintainer-clean, tools/rebuild-gcc) |
| 15:42:54 | BZFlag | erikm: agreed. I think I put em up on TuxScreen.net as well. |
| 15:43:02 | seletz | BZFlag: what do you need? assabet? neponset? both? |
| 15:43:08 | BZFlag | anyone have electronic assabet schematics? |
| 15:43:16 | BZFlag | seletz: both. |
| 15:43:21 | erikm | BZFlag: yes, at home |
| 15:43:42 | BZFlag | erikm: when's the next time you are home? ;-) |
| 15:43:59 | erikm | BZFlag: tonight, I'd guess |
| 15:44:12 | erikm | Russ: but I have the same automake version |
| 15:44:21 | BZFlag | can you email em to me then? |
| 15:44:38 | Russ | erikm: my Makefile.in always ends up like this: |
| 15:44:42 | erikm | BZFlag: oh, sorry, no, I only have them in paper version |
| 15:44:47 | Russ | blob-rest-elf32: $(blob_rest_elf32_OBJECTS) $(blob_rest_elf32_DEPENDENCIES) |
| 15:44:48 | Russ | @rm -f blob-rest-elf32 |
| 15:44:48 | Russ | $(LINK) $(blob_rest_elf32_LDFLAGS) $(blob_rest_elf32_OBJECTS) |
| 15:44:51 | Russ | .... |
| 15:44:55 | BZFlag | oh. |
| 15:45:33 | BZFlag | seletz: you have paper versions then? scan em for me? ;-) |
| 15:46:04 | erikm | Russ: did you try rm -rf'ed the .deps directories? |
| 15:46:11 | Russ | haven't tried that |
| 15:46:28 | erikm | blob-rest-elf32: $(blob_rest_elf32_OBJECTS) $(blob_rest_elf32_DEPENDENCIES) |
| 15:46:32 | Russ | I also noticed that ledasm.o doesn't depend on files in the include/blob/arch directory like it should |
| 15:46:35 | erikm | @rm -f blob-rest-elf32 |
| 15:46:49 | erikm | $(LINK) $(blob_rest_elf32_LDFLAGS) $(blob_rest_elf32_OBJECTS) $(blob_rest_elf32_LDADD) $(LIBS) |
| 15:47:07 | Russ | is autoconf used to? |
| 15:47:15 | BZFlag | arm-linux-gcc -Os -I/home/timr/work/shannon/buildroot-tux/linux/include -Wall -march=armv4 -mtune=strongarm1100 -mapcs-32 -fomit-frame-pointer -fno-builtin -static -nostdlib -o blob-rest-elf32 chkmem.o clock.o cramfs.o amd32.o compr_rtime.o compr_rubin.o jffs2.o shannon.o uucodec.o xmodem.o -Wl,-T,rest-ld-script -Wl,-Map,blob-rest-elf32.map trampoline.o flashasm.o testmem2.o bootldrpart.o commands.o flas |
| 15:47:17 | BZFlag | h.o flash-commands.o initcalls.o linux.o main.o memory.o param_block.o partition.o reboot.o load_kernel.o zImage.o -L../../src/commands -L../../src/lib -lcommands -lblob -lgcc |
| 15:47:32 | Russ | BZFlag has it too |
| 15:47:33 | BZFlag | current cvs just built for me. |
| 15:47:45 | BZFlag | did not flash it etc. |
| 15:47:57 | Russ | BZFlag: arm-linux-objdump blob-rest-elf32 -D | head |
| 15:48:38 | erikm | hmm |
| 15:48:40 | erikm | I see |
| 15:48:40 | Russ | the first line should say somethnig about trampoline, but in your case, will say something about chkmem |
| 15:48:49 | erikm | so why does it work for lart |
| 15:48:53 | erikm | investigates |
| 15:48:59 | Russ | Autoconf version 2.13 |
| 15:49:20 | erikm | same over here (debian testing :) |
| 15:49:30 | BZFlag | erikm: let's see your link line. |
| 15:50:08 | erikm | hmm, after a re-configre not anymore |
| 15:50:11 | Russ | --with-board=shannon --with-linux-prefix=... --enable-maintainer-mode --enable-uucodec |
| 15:50:51 | erikm | --enable-maintainer-mode --with-board=lart --with-linux-prefix=... -enable-xmodem arm-unknown-linux-gnu |
| 15:50:56 | Russ | goes back to sleep for a bit |
| 15:52:28 | erikm | doh! |
| 15:52:42 | BZFlag | ./configure --with-linux-prefix=... --enable-maintainer-mode --enable-clock-scaling --enable-memtest --enable-debug --enable-lcd --enable-jffs2 --with-board=shannon --enable-all-features arm-linux |
| 15:52:57 | BZFlag | course not all those work at present... ;-) |
| 15:53:23 | erikm | this is what we want: |
| 15:53:26 | erikm | arm-linux-gcc -Os -I/home/erik/LART/build/linux/elinux/include -Wall -march=armv4 -mtune=strongarm1100 -mapcs-32 -fomit-frame-pointer -fno-builtin -static -nostdlib -o blob-rest-elf32 -Wl,-T,rest-ld-script -Wl,-Map,blob-rest-elf32.map trampoline.o flashasm.o testmem2.o bootldrpart.o commands.o flash.o flash-commands.o initcalls.o linux.o main.o memory.o param_block.o partition.o reboot.o load_kernel.o zImage.o intel32.o lart.o xmodem.o -L |
| 15:53:26 | erikm | ../../src/commands -L../../src/lib -lcommands -lblob -lgcc |
| 15:53:55 | erikm | and for NESA: |
| 15:54:08 | erikm | arm-linux-gcc -Os -I/home/erik/LART/build/linux/elinux/include -Wall -march=armv4 -mtune=strongarm1100 -mapcs-32 -fomit-frame-pointer -fno-builtin -static -nostdlib -o blob-rest-elf32 -Wl,-T,rest-ld-script -Wl,-Map,blob-rest-elf32.map trampoline.o flashasm.o testmem2.o bootldrpart.o commands.o flash.o flash-commands.o initcalls.o linux.o main.o memory.o param_block.o partition.o reboot.o load_kernel.o zImage.o chkmem.o clock.o cramfs.o amd32. |
| 15:54:08 | erikm | o |
| 15:54:08 | erikm | compr_rtime.o compr_rubin.o jffs2.o nesa.o uucodec.o xmodem.o |
| 15:54:08 | erikm | -L../../src/commands -L../../src/lib -lcommands -lblob -lgcc |
| 15:54:54 | seletz | BZFlag: sorry, scanning, hmm, ok. why not. |
| 15:55:15 | seletz | BZFlag: all pages or what? |
| 15:56:00 | BZFlag | seletz: how large is it? |
| 15:56:15 | BZFlag | bbiab |
| 15:56:29 | seletz | BZFlag: assabet: 12 pages A3 |
| 15:57:12 | erikm | ok, I fixed it. the optional object files should be in LDADD, not in LDFLAGS |
| 15:57:37 | seletz | BZFlag: Neponset: (not counted) 10-15 |
| 16:01:04 | BZFlag | back. |
| 16:01:31 | BZFlag | seletz: ugh. How dod you two get them? was there a pdf version available? I thought there was. |
| 16:01:36 | BZFlag | s/dod/did/ |
| 16:01:48 | erikm | BZFlag: yes, "was" |
| 16:01:54 | seletz | BZFlag: we bought the assabet/neponset board ... |
| 16:02:06 | seletz | BZFlag: actually, we bought six |
| 16:02:38 | seletz | BZFlag: i know of the dev books as pdf. |
| 16:04:53 | seletz | BZFlag: ok, i could mail them to you, but this would take some time. Scanning them would take some time _and_ space. I'd probably put them on my ftp server. |
| 16:06:27 | BZFlag | well, perhaps I'll ask on some of the mailing lists first. |
| 16:06:38 | seletz | ok, np |
| 16:07:45 | erikm | just flame intel :) |
| 16:08:35 | BZFlag | Yeah, I think I will. |
| 16:09:55 | BZFlag | http://developer.intel.com/design/strong/schems/278279.htm <- that it? |
| 16:10:12 | seletz | looking |
| 16:10:53 | seletz | yeah |
| 16:11:02 | seletz | assabet schematics |
| 16:11:12 | seletz | cool |
| 16:11:38 | BZFlag | sweet. not removed, just hidden. |
| 16:12:01 | seletz | http://developer.intel.com/design/pca/applicationsprocessors/schems/index.htm |
| 16:12:20 | seletz | neat list of all stuff |
| 16:13:14 | seletz | even cpld source, gerber files and cabling .... |
| 16:13:43 | seletz | and PBXA250 stuff |
| 16:14:08 | BZFlag | http://developer.intel.com/design/edk/product/strongarm_edk.htm |
| 17:55:07 | erikm | Russ: so does it work again? |
| 18:55:25 | Russ | yup, thank |
| 18:55:26 | Russ | s |
| 19:07:12 | Russ | erikm: you play with 2.4.17-rmk5 any? |
| 19:07:30 | erikm | looks |
| 19:07:36 | erikm | no, I'm still at -rmk3 |
| 19:09:37 | Russ | mcp-core uses __MOD_INC_USE_COUNT |
| 19:10:17 | Russ | __MOD_INC_USE_COUNT(mcp->owner); |
| 19:10:36 | Russ | mcp is defined as a static struct in mcp-sa1100 |
| 19:10:49 | Russ | owner: THIS_MODULE, |
| 19:11:18 | Russ | which is NULL (built into kernel), and so __MOD_INC_USE_COUNT causes an oops |
| 19:11:57 | erikm | oops |
| 21:25:13 | AKIRA-away | has seletz been here the last 5 hours or so ? |
| 21:47:14 | | seletz was last seen on #blob 5 hours, 33 minutes and 31 seconds ago, saying: and PBXA250 stuff [Tue Feb 26 16:13:43 2002] |
| 21:47:14 | BZFlag | ibot: seen seletz |
| 22:34:21 | seletz | hi again :) |
| 22:34:40 | prpplague | wb seletz |
| 22:35:22 | seletz | had some network downtime due to a DSL backbone switch oopsed nearby ... |
| 22:39:15 | seletz | someone used t2.5.2-rmk6 recently? |
| 22:39:24 | seletz | s/t// |
| 22:40:00 | seletz | gives me random oopse at random, weird places |
| 22:40:52 | erikm | just bk pulled linux-2.5.6-pre1 |
| 22:42:17 | seletz | preparing patches for pcmcia MECR handling ... |
| 22:43:59 | erikm | that's already done |
| 22:44:26 | erikm | goes zzz |
| 22:44:57 | seletz | rmk did nod sys so yesterday ... |
| 22:45:10 | erikm | he did in a message to lak |
| 22:45:54 | seletz | oh well. |