5 sec boot

[pgf at laptop.org]

mitch wrote:
 > Deepak Saxena wrote:
 > > On Oct 04 2008, at 15:49, Mitch Bradley was caught saying:
 > >   
 > >> c) Raw FLASH read time maxes out at 20 MB/sec.  But you don't get that  
 > >> speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec.
 > >>
 > >> Considering all the intricacies of JFFS2, my best guess is that it's  
 > >> going to be close to a wash whether the kernel + initrd is stored in  
 > >> compressed or uncompressed form.
 > >>
 > >> OTOH, if the kernel + initrd were in a separate partition in e.g. romfs  
 > >> format, where OFW could just blast them into memory without doing JFFS2  
 > >> node processing, we could probably get close to the 20 MB/sec speed.
 > >>     
 > >
 > > We can probably just get away with making all of /boot into a
 > > romfs; however, do we even need to bother with a filesystem 
 > > representation of the images?  We could have four partions 
 > > (kernel0, kernel1, initrd0, initrd1) that contain the binary 
 > > data for current and alternate images and some sort of way
 > > to tell which one is current and which one is alternate.

+1.  there's no need for the primary kernel to be in the rootfs
on this platform, that i can see, as long as there's a choice
when booting for getting at non-primary kernels, whether in a
secondary partition, or in the rootfs or other storage.  i'm sure
OFW is capable of giving us such a choice.  :-)

 > >
 > > ~Deepak
 > >
 > >   
 > I have considered something like that off and on.  It's sort of nice to 
 > have a definite length for the images.  There are ways around that, but 
 > they are a bit ugly at some level.  It's sort of a tossup at some level.

reading a header of some sort (for the size), then the image,
doesn't seem all that ugly to me.  (maybe i misunderstand you.)

 > 
 > One difficultly with having a lot of partitions is that it makes it more 
 > likely that you will encounter the resizing issue.

i'd think the amount of flash we'd lose by making a couple of
kernel+initrd partitions (or maybe we only need one) that were
big enough to hold foreseeable needs (e.g., current size + 50%)
would be pretty small.

 > On a related topic, I would like to see us start bundling the initrd 
 > into the kernel image.  It's certainly possible to do that with existing 

"into"?  i'd rather see it simply concatenated, unless the tools
to insert an initrd "into" the kernel are trivial, and allow
repackaging with a different initrd in a trivial manner.  my
experience has been with the mkimage tool that comes with uboot --
it's a simple blob encapsulator, and lets you repackage your
kernel pretty simply.  since you always need the two pieces
together, pulling them out as one seems to make sense.  after
concatenating the two, dd the result into a flash partition, and
you're done.

paul

 > kernel mechanisms.  The two pieces are interdependent enough that they 
 > really have to be updated together, at which point it's really better to 
 > have them in the same image.
 > 

=---------------------
 paul fox, pgf at laptop.org