redboot based boot loader for kernels?

[M. Warner Losh]

In message: <20070305194018.GA73100 at zibbi.meraka.csir.co.za>
            John Hay <jhay at meraka.org.za> writes:
: > : > Hi,
: > : > 
: > : > Does anyone have or is busy with an app that one can load in the
: > : > redboot flash, that will load the kernel from the active partition
: > : > of a compact flash? I know one can load the kernel in the redboot
: > : > flash, but that makes remote upgrading more difficult. The way I
: > : > have done with our wrap and soekris boards, is to create 2 slices
: > : > on the CF. When upgrading, you just format and install on the
: > : > non-active slice, change the active bit and reboot.
: > : 
: > : A certain someone promised to add read/write support for the flash.
: > 
: > That would be me...  My day job has been crazy and my new son isn't
: > yet sleeping through the night.
: > 
: > : When that happens another option is to write the new kernel to flash
: > : before rebooting.  Otherwise we need a redboot image that grok's ufs or
: > : a secondary bootstrap that can be written to flash that knows how to
: > : boot from cf (I recall the latter might be in the obsd thecus work).
: > 
: > The at91 boot2 groks ufs and only needs a function that can read the
: > sectors from the underlying media to grok new media.  Of course, it
: > inherited most of that from the i386 boot2.
: 
: Ok, I have it somewhat working for my Avila Gateworks board. I have
: a bug somewhere in the code that do 16 bit reads from the CF, so for
: now I have switched to 8 bit accesses. :-/ I'll search for that a
: little later.

Cool!  I'd love to check out the source...

: One thing that I would like to do is to pass the disk/slice info to
: the kernel. The reason being that I have 2 FreeBSD slices and would
: like the kernel to mount the one the boot loader tells it to. From
: looking at how some of the other archs do it, it looks like I will
: need some arm assembler foo. :-/ Anybody got ideas/code? I even
: thought of compiling the kernel with "options ROOTDEVNAME" and then
: the loader can load the kernel in ram and then search for the
: ufs:ad0s1a string and twiddle it as appropriate, but that would not
: work well with .gz.tramp kernels. :-)

The way that's normally done is that the boot loader tells the OS in
some block of memory...  Trouble is that none of that is standard, and
besides, the boot loader doesn't really pass anything on ARM right now
(it should be passing the board type, but that's about it).  That's a
long way of saying 'we should invent something'.  However, since we're
in the Linux space here, chances are good there's already a standard
for passing strings in, and maybe we should piggy back on it...

Warner