Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader

[Andy Green <andy@warmcat.com>]

On 12/23/09 02:28, Somebody in the thread at some point said:

Hi -

> No TCP/IP, no TFTP, not even BOOTP (but it's a nice bonus), no command
> line interpreter (just a GPIO on board to boot into "unbrick me" mode
> :-), and most strikingly _no_ flash driver for flash chip du jour.
>
> To flash it you send a kernel to boot from RAM which is capable of
> flashing it.

Sorry I missed where this kernel appears from and the bootloader that 
spawned it, since both could get trashed.  That is actually a conundrum 
on a lot of systems and some of the solutions (write-once backup 
bootloader) in the long run lead to other issues.

True SD Boot does truly deliver unbrickability if you are willing to 
swap out or reformat the SD card.

>>> http://wiki.openmoko.org/wiki/Qi
>>
>> Looking at the screen shot there, you've got code to parse ext2 filesystems.
>> What is your definition of "minimal"?
>
> Ew, ext2 doesn't even satisfy powerfail-during-kernel-upgrade safety.

It's just misleading (but accurate).  ext2 is the "lowest common 
denominator" read-only parsing that actually supports ext3 and ext4 if 
you are careful about the formatting options.  So the actual filesystem 
is ext3 or ext4 typically (ext3 in GTA02 case), it's not that the 
bootloader is mandating specifically ext2.

> I agree it does beg the question of what is "minimal".
>
> The proposal did explain quite well what Qi aims for: not duplicating
> lots of kernel drivers badly.  If it succeeds in the area of flash
> writing, network drivers, network protocols and so on it would be no
> bad thing.

Thanks.

> One area for potential common ground among bootloaders could be to
> share the code for parsing filesystems.  It'd be great to see that in
> a library shared by GRUB, Qi, U-boot and so on as it's not device
> specific at all and not particularly large, but not so trivial that
> it's good to have lots of clones.

Yeah it's not a bad idea.

> It's possible to boot without parsing filesystems, but that is one
> rather nice feature, and with the right filesystems it can make system
> updates powerfail-safe.

Bootloader is tricky, but actually on this iMX31 device Fedora is used, 
yum update keeps the last 3 kernels around and our kernel package 
follows that.  So it's possible to have backup kernels automatically 
integrated into the bootloader and packaging system.

>> Rationale for not providing a boot menu is you don't want to mess with video
>> init.  I don't think I've actually seen an embedded bootloader that messes
>> with video, they do serial console instead, and you have a screen shot of
>> serial console messages so apparently the serial driver part is there...
>
> In perspective, serial is usually quite simple.  Output only serial is
> even simpler, though :-)

Totally agree!

-Andy