considering the switch to 2.6.24
werner at openmoko.org
Thu Jan 10 15:08:58 CET 2008
Andy Green wrote:
> We need to do what we are doing on NOR / U-Boot / other partitions I
> think at the same time.
Hmm, why ? For the partitioning, it shouldn't really matter what kernel
I agree that we need to settle our partitioning concept soon, though.
For NOR, the simplest option would be to give it all to u-boot, and be
done with it. Developers who only wish to use it for basic recovery
won't change it anyway. Those who have a (v3) debug board can
experiment with more interesting uses, but those concepts then don't
have to be finalized by the time we produce the devices.
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.
(Background: DM2 is part of our production testing software used at
the factory. It runs under Linux and comes as a kernel+initramfs
package. In HXD8 production, we use it also as a more or less general
Linux environment, to which we can SSH, and perform automated download
and configuration tasks.)
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
> Well, at least we take the full hit and it doesn't get 5 times worse
> when you fill the filesystem from 20% -> 100% :-)
Yeah, the good thing about being a pessimist is that there are no
bad surprises ;-)
> 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).
I think it would help a lot if we could find a way to just make file
system access faster, either through faster mounting, or through at
least accelerated access to selected files.
What I'd love to have for loading the kernel is basically something like
LILO's map file - an extremely simple structure any boot loader can read
easily. Of course, we wouldn't want to have to run the equivalent of
/sbin/lilo whenever something changes.
Regarding the partitioning, I've asked our production people to specify
what they expect to do with the "factory" partition. That's also
information we need for defining the partitions.
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
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.
> 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 :-)
> For end users we don't show them the kernel boot, it won't be an issue
> anyway, it was just a pleasant surprise for me that we have a little
> secret boot speedup hidden away.
We can ask the people who've already been working on the Glamo if this
would be easy to implement. A fast text console can be quite useful when
debugging (in particular if it's fast enough to make your printks finish
before the next X Hz interrupt hits ;-)
More information about the openmoko-kernel