please don't switch to kexec (was Re: R70/R71 on debug v3 board ?)

[Harald Welte]

On Mon, Feb 11, 2008 at 09:32:11AM -0300, Werner Almesberger wrote:
> Harald Welte wrote:
> > Do you realize that you are just scrapping the ability to 
> > boot any different OS on the device?
> 
> I wonder how you jump to this conclusion. It's not as if there'd be
> some "secret trusted BIOS" that enforces signed binaries or such.

no.  but it's something that is at the state of 'oh yes theoretically
you can do XYZ, but we have not heard of anyone doing it so far, and we
will not provide you all the tools you need.'

> > By switching to kexec, you virtually remove that ability.  Yes, people
> > can still replace the linux kernel with a bootloader, but it is _MUCH_
> > harder since you have to do all the low-leve setup such as GPIO
> > configuration, etc. again.  A common bootloader for PLL/GPIO init helps
> > a lot in that regard.
> 
> They'll have to port tons of drivers anyway. 

that's easy.  IF you have the GPIO/PLL right and get to a serial
console, everything else is just a matter of systematic debugging.  But
up to that point, it's _really_ hard.

> I doubt a few GPIOs, would break their back :-) If they're really
> having too hard a time to bring up their kernel, they could even take
> the old u-boot code and run that first. Or just bring up Linux and
> dump the registers they're interested in.

being a person who has ported linux to devices for which no existing
bootloader was there, I assure you that if you don't have existing code
that reliably puts the hardware in a working state, it makes a lot of
difference.   It's not the amount of time you spend to implement
drivers, it's the amount of time you waste while not knowing anything
for sure, not even if the GPIO pins are configured right.

And yes, the difference is that the openmoko linux kernel is open
source, and that it is possible to read all those bits from there in
source, rather than object code.  Still, there's a plethora of mistakes.

> Yes, I can see how it might (*) make the effort of porting a non-Linux
> system marginally easier. However, I don't see any sensible relation
> between this and the drain of resources keeping u-boot around means
> to us.

To me, any effort is sensible if it makes the device easier to hack on,
in whatever way.

Please also factor in the knowledge curve.  u-boot is well understood in
the embedded world.  Almost everyone has seen/used it, there's lots of
documentation.  Last, but not least, most of the existing openmoko
developers in the community have experience with using it.

Switching to a hyper-new kboot/kexec approach that has not seen
widespread adoption in the embedded world will scrap all that.  People
first have to understand and learn how to work in that new world.

To me, having a bootloader in an embedded device is just 'industry
standard'.  OF all the embedded Linux devices that I've seen on system
level (mostly related to gpl-violations.org), 99% have a bootloader
independent from the OS.  A bootloader that can do tftp (in case of
networked devices), boot from sd-card, ...  Some use blob, some redboot,
some u-boot, some others are proprietary.

Now if you replace that with a 'linux based bootloader', I generally
don't mind.  But Linux is just a kernel, not a bootloader.  Where is the
standard commandset that the bootloader understands?  Where is the
standard solution for implementing things like the u-boot environment
(aka config file) or the interactive shell with a standard set of
commands?   Basically I think you can very well replce bootloader X with
bootloader Y.  But at the moment I have the feeling you want to replace
bootloader X with a toolkit-that-could-well-become-a-bootloader Y.

I like the toolkit.  And I like the idea of the flexibility that it has.
But I dislike that all we then get is a kernel and busybox.  Oh yes, one
_could_ put this or that custom script in there.  

It's flexibility, but has a distinct loss of structure.

>From a bootloader user perspective you don't want a general purpose
shell into whcih you can put your own scripts. You want something
concisive, tailored to your application.  You don't want to fiddle
around cycling throguh /proc, /sys and /dev, trying to figure out which
bits you need where, trying to find the important in all the noise.

Sure, all that can be implemented on top of the linux kernel. But will
you do it?  Where is the 'mmcload/ext2load/loadelf/...' level of
abstraction?

> (*) Actually, if I had to start from scratch, I'd probably just do all
>     the initialization myself anyway, so that it's done by code I
>     fully control.

mh, yes. very convenient for the developer who does it.  very sucking
for the user who wants to see one of the standard three arm bootloaders
out there, which he has worked on before, for which he can easily google
all the questions and answers that he wants.

> I can understand your decision for choosing u-boot when there was no
> code at all that ran on our platform. But now we're in a much better
> situation, and we can move on and use tools that fit our needs better.

I think adhering to some 'best current practise' (how worse it might
actually be)  has way more advantages than switching to something
hyper-cool, new, efficient, but little known/understood.

> > Also, dual-booting different OS's is no longer possible.
> 
> We obviously want to be able to choose kernels. 

yes, but we want to be able to boot things that don't behave like a
linux kernel.   You cannot expect everyone to accomodate their
boot/calling/parameter passsing conventions how you like them.

Traditionally it has been the task of the bootloader to
accomodate/implement those different booting conventions.  If you now
expect everything to look like a linux image, then you either force the
other ones to adopt, or somebody would have to add an intermediate shim
layer.  If that latter shim layer came as a standard with
whatever-on-top-of-kboot-kexec, it would be acceptable.

> So any other OS would just be another binary that you load and jump
> to. No discrimination there. (BTW, you're already talking about the
> next step, which would be NAND booting. For now, we're just thinking
> about NOR.)

so you want a kernel in nor and u-boot in NAND?  Well, in that case, if
its just for the emergency, I don't particularly care what is booted
there.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone