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

Joshua Wise joshua at joshuawise.com
Wed Jul 19 21:30:25 EDT 2006


On Wed, 19 Jul 2006, Jordan Crouse wrote:
> On 19/07/06 09:23 -0600, Ronald G Minnich wrote:
>> 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.

I agree with you on this. LAB, at the moment, pretty severely lacks GUI
functionality. If we wanted graphical boot screens other than a simple logo,
it would take a bit of hacking. LAB isn't really about GUI boot screens --
it's about a quick boot time in probably half to a quarter the space of
userspace code.

> I'm going to take the opposite position - If the ROM Is hosed in the field,
> then there isn't much a shell is going to be able to do for 99.99% of the
> intended users.  Its nice to have for the uber hackers among us, but we can't
> let that distract us from a slick user experience.
>
> Certainly a shell is important, especially at this point in time, but as we
> improve the ROM, the shell is going to fall further into disuse.  Eventually,
> it is my hope that we'll be able to disconnect the menu option all-together.
>
> Luckily, for the near future, we can have our cake and eat it too.  The UI
> I'm working on should come in about 13k or so, plus 100k for the pictures
> (thats raw picture data - it will compress fabulously) so we shouldn't have
> to compromise too much at this point.

Near the end of the lifecycle of the old CRL bootloader, we had a
compactflash reflash option that didn't require serial. It had a small font
stored in ROM, and knew how to read a control file off a CF card and prompt
the user for which one to reflash. That's about the extent of the
maintenance that makes sense to me to perform at home without a serial
cable/console cable (perhaps a kernel selector as well, to back things down,
or a boot device selector).

How much UI were you thinking?

I'll make a tarball of the code later tonight.

joshua

>
> Jordan
> -- 
> Jordan Crouse
> Senior Linux Engineer
> Advanced Micro Devices, Inc.
> <www.amd.com/embeddedprocessors>
>
>
>



More information about the Devel mailing list