considering the switch to 2.6.24

[Andy Green]

-----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-----