-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
> By the way, jserv is investigating the option of putting the kernel > and a small initramfs into NOR. The idea is to have a more > feature-rich environment than just u-boot, inspired by what we did > with DM2 in HXD8. Yeah -- I replied to this but it seems you didn't get it? I mail it directly to you. > Since this would also change the usage pattern of the NOR, I think we > should leave this partitioning choice open for now, and only define a > "works for sure" fallback option, i.e., the "u-boot alone" concept I've > mentioned above. If I understood it, this "leave it open" approach means you won't be able to use a NOR partition in Linux without rewriting your U-Boot env, since NOR ones are allocated first as we know and it will shift all the NAND ones down. I think we need to at least propose Linux's view of any NOR partitions as part of this... 1 for the whole 2MB is fine, 2 in the 256K / 1.75MB is fine too, but 0 means you can't update the NOR contents from Linux without PITA. >> In this case though >> - -- separating the rootfs into two partitions as I suggested before will >> definitely cut the initial JFFS2 mount time to 20% of the current time? > > Yes, that would help. I'm a bit afraid of fragmenting the NAND too much, > though. We now have u-boot, u-boot_env, splash, factory (proposed), > kernel, boot (proposed), rootfs, and "home" (proposed). Partitions are normally evil in my book... but these are pretty cuddly ones, just logical partitions without a footprint, most of them small and with contents that are not much in danger of hitting their limits. They don't drain much resources either. I dunno if you noticed but there is a 20s boot time target being talked about now. Something radical will have to be done to get near that and this is it, I think. > Perhaps we can gather all the data we have early next week and then > settle this issue ? By then, I should also have the devirginator work Yes it's fine by then. I also am interested in hearing Nod's POV. > properly again (right now, I'm stuck with my main lab machine not > having reliable JTAG - didn't see that one coming :-( ), so we can > actually implement the changes painlessly. Wah -- make sure libftdi didn't get updated, 0.8 was golden for me. >> Note though that the Glamo SD patches mess with that same code -- I have to >> reserve a 64K block for shared memory with the SD state machine, but >> we'll figure it out. > > We left the other 4MB for you :-) I set it here so the Video has (8MB - 64K) :-) - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFHhivcOjLpvpq7dMoRAsluAJj719+O1Za+BPKYLItqEvWAIjNvAJ0dmFnl XQ2ZJ0exxt7J897a2zjo3g== =3C4a -----END PGP SIGNATURE-----
