| 01:59:43 | Sammy | morning all |
| 02:05:04 | prpplague | morning sammy |
| 04:10:30 | Sammy | Is that blob only support 4MB for jffs2 file ? |
| 04:11:14 | Sammy | can any one give me a hint ... |
| 04:11:55 | prpplague | Sammy |
| 04:12:09 | prpplague | sammy: i've not started working with jffs2 yet |
| 04:12:20 | prpplague | Sammy: no help from me, sorry |
| 04:15:13 | Sammy | : ) ok |
| 05:28:54 | BZFlag | Sammy: blob in cvs does not support jffs2 reading. |
| 05:29:04 | BZFlag | the ramdisk support is 4M yeah, |
| 05:29:31 | BZFlag | but you should be able to flash a larger jffs2 image with little trouble. |
| 05:30:07 | BZFlag | I hope to be doing a 16M - 128k jffs2 image on a new platform soon. |
| 05:40:44 | Sammy | Thank's BZFlag , this why I have some problem with 12MB -256k jffs2 image :( |
| 06:14:47 | BZFlag | how much ram do you have? If you have 16M or more, you should be able to flash a 12M image, but a 12M ramdisk (ie initrd, not jffs2) might be a prblem. |
| 08:09:04 | | well, Russ is my big hunk of man-love |
| 08:09:04 | Sammy | Russ ? |
| 08:10:00 | | Sammy: what? |
| 08:10:00 | Sammy | ibot: set !! |
| 08:10:11 | | Sammy: huh? |
| 08:10:11 | Sammy | ibot: set |
| 08:10:21 | | Sammy: excuse me? |
| 08:10:21 | Sammy | ibot: set down ... |
| 08:10:51 | | Sammy: sorry... |
| 08:10:51 | Sammy | ibot: go get the ball now ... |
| 08:11:09 | Sammy | ... |
| 10:00:03 | erikm | morning |
| 10:02:44 | seletz | hi |
| 10:04:15 | erikm | flames jamey |
| 10:04:38 | seletz | lol! |
| 10:04:54 | seletz | erikm: i read the flames from yesterday: woha! |
| 10:05:20 | seletz | erikm: funny, tough. Everyone is sooo polite ... |
| 10:07:55 | erikm | seletz: jamey contradicts himself |
| 10:08:54 | seletz | erikm: read: jamey is out-argumented by joined forces from some _very_ competent linux-arm people. |
| 10:09:17 | erikm | seletz: he forgot the KISS principle |
| 10:11:04 | seletz | erikm: woha. not so polite anymore. |
| 10:11:42 | seletz | (mean the last posts yesterday) |
| 10:12:32 | seletz | erikm: well, rmk _can_ be funny. :D |
| 10:16:25 | erikm | seletz: nico once made the remark that everything from the handhelds.org CVS gets redone... |
| 10:18:26 | Sammy | hi < erikm> <seletz> |
| 10:18:55 | seletz | erim: well, i heard rumors 'bout handheld.org's patches, which are erm, somewhat not acceptable to rmk. |
| 10:20:00 | seletz | erikm: well, i'ts a pity tough to have some working code which needs heavy re-designing. |
| 10:20:05 | erikm | seletz: usually because they have the "all the world is an ipaq" approach |
| 10:21:06 | seletz | erikm: "do it right the first time" said herman the german, and that should be followed by _everyone_ involved in software design, or engeneering in general. |
| 10:21:12 | erikm | seletz: did you read rmk's interview with kerneltrap.com? he made some very valid remarks about external CVS trees |
| 10:21:39 | seletz | erikm: hmmm, kerneltrap.com, hear it the first time. |
| 10:21:42 | seletz | checking out |
| 10:21:50 | erikm | seletz: there is a link on the LART site |
| 10:22:52 | erikm | seletz: http://kerneltrap.com/article.php?sid=340 |
| 10:24:02 | seletz | oh, thanks :) |
| 10:25:03 | seletz | reading ... |
| 10:33:50 | seletz | erikm: hmmm, rmk doesn't mention CVS in _this_ interview ... ? |
| 10:36:20 | erikm | seletz: hmm... lemme see.... it must have been on some advogato.org article.... |
| 10:36:23 | erikm | searches |
| 10:39:04 | erikm | seletz: hmm. it was more about mailing lists outside the linux-arm-* lists. |
| 10:39:18 | erikm | seletz: see http://www.advogato.org/article/378.html and search for rmk |
| 10:40:21 | seletz | looking |
| 10:41:50 | seletz | found it & reading :) |
| 10:43:41 | seletz | erikm: well, rmk souds a little, erm, frustrated? bitter? disappointed? |
| 10:44:30 | erikm | seletz: *nod* |
| 10:45:16 | erikm | seletz: but be careful, rmk tends to exaggerate things |
| 10:46:52 | seletz | erikm: well, what really strucks me now, this post is from 25-11-2001, so i can't assume that things gone _better_ up to now. Oh well. Bad bad bad. |
| 10:47:12 | seletz | erikm: I can understand him, tough. |
| 10:48:38 | seletz | erikm: I personally had quite some arguments with my customers to let patches flow back to the community. Well, at last the agreed (because of lack of arguments against :). |
| 11:05:47 | seletz | Sammy: hi (late but ...:) |
| 11:06:33 | erikm | SIGLUNCH |
| 11:24:38 | Sammy | /nick Sammy_homr |
| 11:24:42 | Sammy | /nick Sammy_home |
| 14:37:28 | erikm | returns |
| 15:02:35 | prpplague | howdy all |
| 15:02:41 | erikm | hello prpplague |
| 15:02:51 | prpplague | everyone having fun today? got larted yet today? |
| 15:02:59 | prpplague | still stuck in barbados |
| 15:03:18 | prpplague | is having arm development withdrawal symptoms |
| 15:03:32 | erikm | prpplague: heh, read the flamewar on linux-arm-kernel :) |
| 15:04:55 | prpplague | which one? the ts api or the undocument symbols? |
| 15:05:51 | erikm | prpplague: the "parse_bootldr_partitions" thread |
| 15:07:42 | prpplague | erikm: ohh, no , i've kinda avoid reading that one, i figure it was getting nasty |
| 15:08:11 | prpplague | doesn't get along with the hh.org crowd |
| 15:08:17 | erikm | prpplague: nah, I've seen worse flamewars |
| 15:08:29 | erikm | prpplague: jamey's last message is quite positive |
| 15:08:50 | prpplague | if i get time today i'll have a look-see |
| 15:09:47 | prpplague | i was suppose move a system in place last night, but i mis understood what the customer wanted to do, so i'm stuck her for another day |
| 15:10:10 | erikm | what a pity. stuck on barbados }:-> |
| 15:10:59 | prpplague | ls /barbados/hotel* ; ls /barbados/computerroom * |
| 15:11:15 | prpplague | thats all i've seen for the last couple days |
| 15:12:08 | prpplague | but the raid array seems to be performing well |
| 15:12:14 | erikm | ah, good |
| 15:12:53 | prpplague | erikm: have you checked out the arm+net processor from netsilicon? |
| 15:13:01 | erikm | not yet |
| 15:13:28 | prpplague | erikm: these guys are pestering me to use it in our thin client |
| 15:15:45 | prpplague | argh, i've got two new webpads at the office waiting to be larted.... |
| 15:32:35 | seletz | back |
| 15:47:52 | seletz | erikm: are you here? |
| 15:48:05 | erikm | seletz: yes |
| 15:48:17 | erikm | remembers to read seletz patch |
| 15:48:47 | seletz | erikm: do you have the time to look at some code with me that i dont understand (in mach-sa1100/neponset.c) |
| 15:49:17 | erikm | ok |
| 15:49:58 | seletz | erikm: ok, look up line 222 (i have 2.4.16-rmk2) |
| 15:50:07 | seletz | erikm: please :) |
| 15:50:33 | seletz | erikm: you should be in neponset_irq_demux() |
| 15:50:35 | erikm | hmm, I have to untar 2.4.16-rmk2 |
| 15:50:46 | erikm | seletz: could you /dcc me the file? |
| 15:50:55 | seletz | erikm: nah, use that what you have. this func didnt change at all |
| 15:51:14 | seletz | erikm: ok? |
| 15:51:15 | erikm | ok |
| 15:51:18 | seletz | :) |
| 15:51:33 | seletz | erikm: neponset_IRQ_demux() |
| 15:51:46 | erikm | found it |
| 15:52:13 | seletz | erikm: ok, neponset routes sa1111 irq and lan irq through a cpld to GPIO25 |
| 15:52:33 | seletz | erikm: this func demuxes the irq lines based on an Irq Source Reggy |
| 15:52:58 | seletz | erikm: now, _why_ is there a line irr ^= (IRR_ETHG | IRR_USAR ); |
| 15:54:46 | seletz | erikm: are those bits set back in interrupt handlers or by HW? |
| 15:54:56 | erikm | scratches behind his ear |
| 15:55:33 | seletz | erikm: OK, if the irq levels are low-active on neponset, then this would change them to high-active. |
| 15:56:10 | erikm | I think that's the only explanation |
| 15:56:12 | seletz | erikm: BUT: are IRQs cleared when handling is done? |
| 15:56:30 | seletz | erikm: otherwise bad things happen |
| 15:56:47 | seletz | erikm: for (;;) |
| 15:57:00 | erikm | seletz: I don't know. I'd have to read the neponset docs on that |
| 15:57:41 | seletz | erikm: ok, this would then be some HW specific thing, and IRQ lines are not cleared by linux handlers by default? |
| 15:58:01 | seletz | erikm: the reason i ask this is: |
| 15:58:38 | seletz | erikm: our board works the same way, so there's a system3_irq_demux() with the same stuff in it. |
| 15:59:12 | seletz | erikm: now when i try to get pcmcia working i end up the ethernet irq locking my system. |
| 15:59:56 | seletz | erikm: so, when this irq status lines are _not_ cleared, then this would be the reason ... |
| 16:00:08 | erikm | makes sense, I think |
| 16:00:18 | seletz | erikm: (wild guesses, i know. but i'm quite struck.) |
| 16:00:32 | seletz | hmmmm. |
| 16:00:54 | seletz | phoning hw guru |
| 16:22:33 | erikm | seletz: I'm reading through your patch right now. |
| 16:22:47 | erikm | seletz: first reaction: watch the copyright attributions |
| 16:23:50 | erikm | seletz: i.e.: if you used brad parker's code, leave the copyright intact |
| 16:24:13 | erikm | hello BZFlag |
| 16:25:12 | erikm | prpplague_away: :-P |
| 16:25:33 | seletz | erikm: ok, sure. I don't want to steal code, that's for sure. |
| 16:28:24 | seletz | erikm: in src/diag/system3.c::pcmcia_test() (or similar) is what i used to test the hw, and shows how i thought one would use the pcmcia api in blob. |
| 16:35:26 | seletz | erikm: and remember: the ide stuff done wrong right now. CF card not correctly initialized and so on. The only thin that works ist CIS tuple parsing and slot detection/activation. |
| 16:44:14 | BZFlag | erikm: heya. been busy http://Cameron.Rikers.org/ so not much blob progress yet. |
| 16:45:24 | erikm | BZFlag: congratulations! |
| 16:46:02 | BZFlag | thanx! mom will probably come home today, don't know about cameron yet. |
| 16:46:29 | seletz | BZFlag: woha! Congratulations from Germany too! |
| 16:46:56 | BZFlag | thanx! |
| 17:23:03 | BZFlag | erikm_dinner: any ipaq progress? |
| 18:01:21 | sammy_wms | BZFlag: I have 32MB flash , so as you say , it's only use 13 MB ,so not the problem with jffs2 image file, maybe the problem is rootfs got something wrong ... |
| 18:03:09 | sammy_wms | another confuse not clear , why is that everyone I try use init=/linuxrc to let the kernel read /sbin/init always got wrong ... |
| 18:03:27 | sammy_wms | er everytime |
| 18:04:19 | sammy_wms | and if I copy set it in /bin/init and copy init file from /sbin tp /bin , then it's can work , why ? |
| 18:05:10 | sammy_wms | why kernel only can read init file from /bin but can't from /sbin ? |
| 18:20:32 | BZFlag | sammy_wms: that does not make sense. the kernel should be able to find init as long as init= is set right. |
| 18:21:49 | seletz | sammy_wms: wild guess: try passing "noinitrd" to the kernel. |
| 18:22:17 | seletz | sammy_wms: and your "init=whatever" option of course. |
| 18:35:22 | erikm | BZFlag: not yet. I've been busy with project related work the last couple of weeks |
| 18:35:28 | sammy_wms | BZFlag: I know , but that's why kernel panic and made me in trouble last week ... |
| 18:35:51 | sammy_wms | thanx seletz, I'll give it a try . |
| 18:36:25 | BZFlag | erikm: no prob, just curious |
| 18:37:50 | BZFlag | how is diag supposed to work? It is supposed to be loaded as if it were a kernel, no? It won't load on the Tux. |
| 18:38:27 | BZFlag | twould be nice to have a README for diag. ;-) perhaps just a bit more of a blurb in the normal README would suffice. |
| 18:40:06 | erikm | if you do so, could you put it it the doc/ directory? |
| 18:40:42 | erikm | IMHO the README file is becoming too large, so I think it's a good idea to split it a bit out in doc/ |
| 18:42:11 | seletz | remembers once promised a doc for diag ... |
| 18:43:40 | seletz | erikm: well, i probably could come up with some docs for diag until monday. |
| 18:44:55 | erikm | seletz: I'm not in a hurry... :) |
| 18:45:20 | seletz | erikm: but perhaps BZflag is ?? :p |
| 18:45:20 | sammy_wms | reboot ... |
| 18:45:29 | erikm | BZFlag: btw, /etc/modules.conf is not a solution |
| 18:45:45 | seletz | ? sammy rebooting himself ? Be careful, sammy ... |
| 18:46:11 | sammy_wms | not me :-P |
| 18:46:17 | erikm | BZFlag: think about it: I have two flash add-on boards, one with two partitions, and the other one with three. how would you distinguish between them? |
| 18:46:22 | sammy_wms | brb |
| 19:00:25 | seletz | needs some food --- see you later |
| 19:20:46 | erikm | BZFlag: btw, any progress on porting blob to non-strongarm architectures? |
| 20:30:26 | BZFlag | MAIN_BLOCK_SIZE -> what? |
| 20:30:38 | BZFlag | erikm: duck is hacking on it now. |
| 20:30:56 | erikm | BZFlag: IIRC I got rid of MAIN_BLOCK_SIZE |
| 20:30:57 | BZFlag | I believe he has it booting with serial output, but not loading the kernel |
| 20:31:26 | BZFlag | hmm.. updating Russ' jffs2 code and it is using it. |
| 20:34:54 | BZFlag | KERNEL_START -> ?? |
| 20:35:03 | BZFlag | that was mem location right? |
| 20:35:58 | erikm | BZFlag: get the 2.0.4 source, it's still in there |
| 20:35:58 | BZFlag | now KERNEL_RAM_BASE? |
| 20:36:51 | erikm | BZFlag: jdb created that part. it confused me like hell, so I rewrote it |
| 20:37:31 | BZFlag | heh. ;-) |
| 20:37:50 | BZFlag | the new names are more clear. |
| 20:38:08 | erikm | that was my intention :) |
| 20:38:40 | erikm | anyway, /me throws some more fuel on the flamewar |
| 20:44:06 | BZFlag | oh goodie. |
| 20:48:07 | erikm | I'm not gonna flame, just bringing in some more arguments why having the partition information *on* the block device is the only sane place |
| 21:00:55 | BZFlag | ah, but all proposals ARE on flash. it's just a question of where. |
| 21:01:09 | BZFlag | and who reads the info. |
| 21:01:56 | erikm | BZFlag: the easiest way is to put it *explicitly* on flash so the kernel can read it |
| 21:02:23 | erikm | BZFlag: much in the same way that you don't want to have the kernel to search for /etc/fstab to figure out the partitions on a disk |
| 21:02:43 | BZFlag | following your ide logic, we should have a boot flash block that has geometry info and a jump to the start of the next block and that's all. |
| 21:03:04 | erikm | the IDE logic is from nico, not from me |
| 21:03:08 | BZFlag | 100 bytes in a 256k block. |
| 21:03:29 | BZFlag | the point is that flash is NOT a normal block device. |
| 21:03:43 | BZFlag | wasting a block is a big deal on most platforms. |
| 21:03:46 | erikm | I know. but jamey's logic is flawed |
| 21:04:02 | erikm | he could put the *default* flash partitioning in the bootldr image |
| 21:04:13 | BZFlag | I like the kernel command line option. should work for modules as well from modules.conf |
| 21:04:25 | erikm | it's fundamentally broken |
| 21:05:01 | BZFlag | I don't quite agree. the default will change from release to release. and breaking the installed os would not be nice. |
| 21:05:28 | erikm | but the kernel will read the default if it doesn't find a partition table in the second flash block |
| 21:05:36 | BZFlag | so the bootloader should figure it out. if that's just a default, then fine. if it's not, also fine. |
| 21:06:16 | BZFlag | and how will the kernel "read the default" ? |
| 21:06:21 | erikm | I proposed a perfectly simple solution that solved all problems, and russ even supplied code for that |
| 21:06:22 | BZFlag | looking at the end of the flash block? |
| 21:06:44 | BZFlag | I guess I missed that proposal in the onslaught. ;-) |
| 21:07:14 | erikm | first search second flash block for bootldr partition table (just like it is right now). if not found, go look for the default partition table in the first flash block |
| 21:07:33 | erikm | works with older bootldrs, doesn't break anything. |
| 21:07:56 | erikm | also avoids all the fundamental problems that all other proposals have. |
| 21:08:15 | BZFlag | found it. |
| 21:08:38 | BZFlag | what if I want blob,zImage,jffs2 and the default is blob,jffs2 ? |
| 21:09:11 | BZFlag | I then _have_ to do blob,params,zImage,jffs2 |
| 21:09:13 | erikm | that's what jamey proposes in his last message |
| 21:09:38 | BZFlag | "that's"? which? |
| 21:09:53 | erikm | both |
| 21:10:14 | erikm | if you want something different from the default partitioning, you'll have to waste a flash block |
| 21:10:39 | BZFlag | hmm... why? |
| 21:10:40 | erikm | (for the partition table) |
| 21:11:05 | erikm | because you want to avoid to write to the same flash block where the boot loader lives |
| 21:11:19 | BZFlag | if I can have default in the bootloader, and it can pass commandline args, then I'm set for booting, and less than ideal for non-boot, but still fixible. |
| 21:11:24 | erikm | though in theory that should be possible as well, as long as you don't *erase* the flash block |
| 21:12:25 | BZFlag | the bootloader could look in the second for a zImage, and skip to the end of it and have partition info there, etc. |
| 21:13:21 | erikm | if you don't want to use the default partition layout in the bootloader, you somehow *have* to store it in the flash. better make that explicitly so the kernel can find it |
| 21:13:49 | BZFlag | I don't agree for all cases. |
| 21:13:55 | erikm | and I don't care if it solves the boot process. it should work for modules as well |
| 21:14:03 | BZFlag | let's say I want to store it in the serial flash on the tux. |
| 21:14:13 | erikm | then let the kernel read the serial flash |
| 21:14:22 | BZFlag | or some silly cmos memory area, etc. |
| 21:14:35 | erikm | then let the kernel read the silly cmos area |
| 21:15:03 | BZFlag | the mtd driver for the linear flash should load a kernel driver for the serial flash, know what to expect there and be able to partition the linear flash!? |
| 21:15:35 | erikm | yes, and why not. that's what initramfs is for, right |
| 21:15:53 | BZFlag | this implies that the info is always stored in the same format on serial flash/cmos/etc |
| 21:16:48 | erikm | yes, but the same holds if the bootloader has to figure out the partition information |
| 21:17:03 | BZFlag | ok, and let's say the initrd and kernel are loaded via tftp with a config file for flash? |
| 21:17:43 | erikm | that's sick IMHO |
| 21:18:03 | erikm | the point is that partition information is a fundamental property of a block device |
| 21:18:51 | BZFlag | I don't agree. I think of flash as a more of a loop device. |
| 21:19:20 | BZFlag | I need to tell it how big etc when modprobing it. |
| 21:19:35 | erikm | no. modern flashes have CFI information for that |
| 21:19:52 | erikm | just like modern disks can tell you exactly how large they are |
| 21:19:59 | BZFlag | and since the bootloader or the initramfs can grok whatever I can devise, the block device may or maynot want to have a partition table on it. |
| 21:20:03 | erikm | (scsi could do that for as ling as I can remember) |
| 21:20:14 | BZFlag | I meant how big each partition is. |
| 21:22:35 | BZFlag | CFI will tell you the max extents. I'd rather see a default of one big mtd device and then have kernel commandline args to set anything else. |
| 21:22:41 | erikm | you tell that with some kind of partition table. jamey pointed out that they use a partition table with the backpaq. |
| 21:22:50 | BZFlag | this does not restrict the use of the first block. (or any other) |
| 21:23:24 | erikm | <record mode=broken>that's a flawed idea</record> |
| 21:23:28 | erikm | and I show you why |
| 21:23:44 | BZFlag | listens |
| 21:24:14 | erikm | let's assume that I have two identical flash cards: one with two partitions, one with three. |
| 21:24:41 | erikm | assume we are already booted and I can hotplug those cards |
| 21:24:50 | BZFlag | then a user space app should determine which and mount it correctly. |
| 21:24:53 | erikm | (btw flash card != CF card) |
| 21:25:07 | erikm | the userspace app can't because the flash cards are identical |
| 21:25:21 | erikm | just like two disks can be identical |
| 21:25:31 | BZFlag | the user space can mount it as one device, grok it and remount it. |
| 21:25:36 | erikm | the module parameters method doesn't work |
| 21:25:53 | BZFlag | mount -> load the block device, not mount a fs. |
| 21:26:05 | erikm | did you ever try that for a disk? |
| 21:26:07 | BZFlag | the module parameters works fine. |
| 21:26:19 | BZFlag | this is not a disk, as you mentioned. |
| 21:26:33 | erikm | ok, I give you my flash card, but I don't give you the partition information |
| 21:26:40 | erikm | how do you figure out the partition layout |
| 21:27:05 | BZFlag | no problem. the user space app knows this is a socketed card, and will look for a grok a partition table in the right place. |
| 21:27:21 | erikm | so why doesn't that work for disks? |
| 21:27:37 | erikm | why do disks have that *fundamental* information *on* the medium? |
| 21:27:39 | BZFlag | but this does not force that layout on a non-removeable mtd device. |
| 21:28:01 | BZFlag | be cause as far as the cpu is concerned they are not memory. |
| 21:28:08 | erikm | that doesn't matter |
| 21:28:18 | BZFlag | mtd devices on arm have 0x0 bootloaders |
| 21:28:30 | BZFlag | on x86 they will often have 0x-1 bootloaders |
| 21:28:41 | BZFlag | on mips they have other screwy layouts. |
| 21:28:42 | erikm | 0x-1 bootloaders? |
| 21:28:47 | BZFlag | last byte. |
| 21:28:54 | BZFlag | well, last 4 bytes. |
| 21:28:58 | erikm | ok |
| 21:29:40 | BZFlag | so x86 based would want partition info (if any) on the last, and arm on the first, and mips perhaps in the middle, etc. |
| 21:29:50 | erikm | it's also wrong to put the absolute address in a partition table, but that's a different story. that's why you see offset+len in partition tables |
| 21:30:03 | BZFlag | agreed on that point. |
| 21:30:38 | erikm | I'm looking at the general case. I don't care where the flash is mapped |
| 21:30:44 | BZFlag | so mandating the location of a partition table for a _bootable_ flash device is a bad idea. it's platform dependant. |
| 21:31:32 | erikm | that's why I propose at least two locations to put the partition table: on the first or the second block |
| 21:31:35 | BZFlag | for non-bootable, it's a different story as there should be no arch implications on layout. (just byte ordering etc. ;-) |
| 21:31:53 | BZFlag | neither is good for x86 |
| 21:32:22 | erikm | of course it is. x86 boots from the last block, so it doesn't care what is in the lower blocks |
| 21:32:37 | BZFlag | but you now force the waste of one block |
| 21:32:52 | BZFlag | same argument says arm is fine with last block. |
| 21:33:20 | erikm | x86 has code in the lower blocks as well. you could put the *default* flash partition in a flash block full of code |
| 21:33:36 | BZFlag | x86 (non-dos) does not. |
| 21:34:45 | erikm | then for x86 we put the default partition table in the last block, and if you want something different, you'll have to waste the second last flash block |
| 21:34:59 | BZFlag | not to mention what will happen with other arches.... the point is the same. |
| 21:35:50 | BZFlag | and the first as well, as it now will not be part of a larger block. |
| 21:36:19 | erikm | indeed. if the bootloader can get the flash layout, there's no reason to assume the kernel can't |
| 21:36:42 | BZFlag | also consider multiple mtd devices. they may want the entire second device for jffs2 |
| 21:37:03 | BZFlag | common on mips is 1 64k flash device and then another 4M flash device. |
| 21:37:09 | erikm | that's why having the partition table on flash solves the whole issue |
| 21:37:24 | BZFlag | disagree completely. |
| 21:37:35 | erikm | than we'll have to disagree |
| 21:37:42 | BZFlag | let's say the bootloader is in ROM and then there is flash. |
| 21:37:54 | BZFlag | the kernel will not know where to look for partition info. |
| 21:38:21 | BZFlag | but the bootloader always knows what to pass the kernel on the commandline. (for bootable devices) |
| 21:38:34 | erikm | so we actually need the bootloader to pass the position of the partition table |
| 21:39:11 | BZFlag | you assume it will be mapable in kernel memory space. sometimes the ROM/flash banks are paged. |
| 21:39:31 | erikm | and why would that be a problem? |
| 21:40:13 | BZFlag | ie: on some systems I have ROM at 0x0 which then becomes flash at 0x0 after the rom bootloader is copied to ram. |
| 21:40:29 | BZFlag | this is NOT mmu setup it it a control bit on the board. |
| 21:41:37 | BZFlag | the point of all this is: the bootloader always knows. they kernel may not. so require the bootloader to tell the kernel. |
| 21:41:39 | erikm | like the C64 BASIC ROM which was mapped over RAM. you just unmapped it and you could use the RAM |
| 21:41:54 | BZFlag | compare to the memory detection procedure. |
| 21:42:22 | BZFlag | c64, similar yes, but normally rom/flash instead of rom/ram. same idea |
| 21:43:23 | BZFlag | there are a ton of methods to determine ram layout. the kernel could well have all of them in it. it does not. It expects the bootloader to have the Right Ones and then tell the kernel where ram is and how much. |
| 21:43:45 | erikm | the memory detection procedure is something different because the kernel really has no way to figure out |
| 21:44:18 | BZFlag | the kernel could not do what the bootloaders do? why not? |
| 21:45:18 | erikm | because the bootloader can figure out the memory setup before the memory is loaded with kernels and ramdisk images. |
| 21:45:39 | erikm | that's not a problem when you have plenty of memory, but it is when you're tight on memory |
| 21:45:56 | BZFlag | excellent. ditto for flash partitions. |
| 21:47:02 | BZFlag | I could copy a ton of cruft into my initramfs and then the kernel can do what the bootloader does anyway, but "that's not a problem when you have plenty of [flash], but it is when you're tight on [flash]" |
| 21:48:04 | erikm | no. in order to detect the memory, you'll have to be careful not to trash the memory you're running from (or you need to be able to run). that works pretty well for the bootloader because it's small (32k) and we assume memory comes in blocks larger than 32k. but that doesn't work for large kernels |
| 21:48:54 | BZFlag | same sort of implitions on wasting flash blocks that you mention for memory regions. |
| 21:49:22 | erikm | *sigh* there is no need to waste flash blocks |
| 21:49:34 | erikm | especially not for a boot flash |
| 21:49:48 | BZFlag | cept intead of "trashing" at runtime, it's "trashing" by mandating usage of some locations. |
| 21:53:08 | BZFlag | well, after all this.... |
| 21:53:26 | erikm | ... I think I'm going home :) |
| 21:53:28 | BZFlag | I can see that for many situations a partition table of known format is a Good Thing. |
| 21:54:19 | BZFlag | However it would be nice to get one big device if none can be found, and a signature that makes it highly unlikely that it created randomly |
| 21:54:39 | BZFlag | then have kernel commandline to be able to override. |
| 21:54:41 | BZFlag | thoughts? |
| 21:54:42 | erikm | BZFlag: like a fresg disk is unpartitioned |
| 21:54:48 | erikm | fresh I mean |
| 21:54:59 | BZFlag | yep, good example. |
| 21:55:26 | erikm | I agree that the commandline/module paramaters could be used to override the partition table |
| 21:56:26 | erikm | s/could/should/ |
| 21:56:38 | BZFlag | sounds good to me then. if the partition table is not required, but is the norm and the command line options are not required either but are common on some platforms, then I can agree to that. ;-) |
| 21:57:30 | erikm | BZFlag: pfew, what a flamewar to get onto this point :) |
| 22:01:37 | BZFlag | heh ;-) I gleaned some things from your points that I have not thought of. So I don't mind the flaming. It's not personal, just investigatory. ;-) |
| 22:01:51 | erikm | same for me |
| 22:03:21 | erikm | just found Xpenguins in the GNOME panel applets menu. 8 penguins are now reading/walking/digging/floating/falling over my screen :) |
| 22:03:36 | BZFlag | heh, fun fun! |
| 22:03:57 | BZFlag | I have most of russ' jffs2 integrated. still have to do some testing. |
| 22:04:04 | erikm | cool |
| 22:04:35 | erikm | I just heard that we have to take a mandatory holiday between x-mas and new year because of some work in the building |
| 22:05:05 | erikm | nice time to work on the blob flash partitioning |
| 22:06:37 | erikm | BZFlag: btw, rmk told me that the bootp/tftp licensing issue has been resolved |
| 22:07:04 | erikm | BZFlag: he'll send me the code with proper GPL headers so I can include it into blob |
| 22:09:28 | erikm | goes zzz |
| 22:09:29 | erikm | bye |