[OLPC-devel] Boot tasks -- the iPAQ way

[Ronald G Minnich]

Joshua Wise wrote:

> A while back, we had a similar conundrum when we wanted to move to the 
> Linux
> kernel as a bootloader on the iPAQ. We really wanted the drivers from Linux
> without having to reimplement them in the CRL bootldr (in particular, we
> wanted jffs2 on NAND), but we couldn't afford the space of a full userspace
> with a loader, libc, etcetera.

we had a discussion about this a while back, when I was trying to jam 
everything into 512k -- I suggested (and even cobbled together at home) 
a boot loader which was in linux main(), that simply read an elfimage 
from whatever storage the user selected. No user space.

General feeling is that this is a good backup plan, but I personally 
would rather not do this for the shipping product. In user mode, a 
memcpy() that goes awry gets you a nice segv etc; in kernel mode, it 
gets you an undebuggable mess. I spent enough time in my life debugging 
apps in a non-protected-mode world (amiga, vxworks, etc.) that I'd 
rather have my userspace apps in ... userspace. Applications programming 
in kernel mode is occasionally tricky, and the result of trivial 
programming errors is much more serious than in user mode.

Kernel-mode applications are still a great idea if we really end up 
running out of 1M, but I think we're going to be ok. I've been using 
busybox booted out of flash for some time now, and it works very well.

I will once again repeat my plea: the most important thing we can put in 
BIOS flash is capability. Yes, graphics are nice, but if you sacrifice 
capability (such as mknod, mkdir, etc) then you will find yourselves, at 
some point, wishing you had the capability, not the pretty pictures. So, 
let's be careful about trading off capability for nice looking boot 
screens.

In particular, if the quest for graphical boot screens drives us away 
from busybox and into kernel-mode applications programming, then I think 
we've taken the wrong path.

Thanks

ron