Qi - why only 3 partitions on SD card?

[Dr. H. Nikolaus Schaller]

Am 26.09.2009 um 10:20 schrieb Dave Ball:

> Dr. H. Nikolaus Schaller wrote:
>> What I wonder is why nobody did fix u-boot if it had problems with
>> bigger kernels.
>>
> I'm just a bystander here, but from what I understood this wasn't the
> reason Qi was started.
>
> u-boot is an entire environment that needs drivers for a lot of the
> hardware (usb, graphics, pmu, etc.) all of which end up duplicated in
> the Linux kernel.  The u-boot philosophy (of an entire environment
> supporting DFU and a boot menu) implies that those drivers have to be
> maintained in two places (u-boot and kernel) which cases pain, and

I see. This is surely a problem.
For u-boot there are estimatedly 200 other hardware projects around  
that have the same issue. Therfore porting & fixing is only 1/200 of  
efforts. Except the hardware specific parts (e.g. LCD).

> inevitably results in u-boot being slower to boot.

That one I do not really understand. If I want to load a kernel from  
MMC it needs the driver anyway. And why is it slower if there are  
other (unused) drivers available?

The only delay I am aware of for u-boot is from waiting if someone  
wants to break into command line mode through the console...

Otherwise the boot speed should only be limited by how fast we can  
locate and fetch the kernel image from peripheral memory.

> Qi starts with a completely different philosophy - that the bootlooder
> should do as little as possible, and that it should need to know as
> little as possible about the hardware.  In terms of intent, it's  
> closer
> to the coreboot project than it is to u-boot.  You really couldn't
> achieve this [separation of bootloader & device drivers] with u-boot,
> which is why the separate Qi project was formed instead of  
> continuing to
> evolve u-boot.

But u-boot evolves anyway (with us or without) because many other  
projects simply use it.

Nevertheless your point with the LCD device driver is very valid. It  
is specific to every piece of hardware. Only the CPU is more generic.

> So what you _can't_ do inside Qi is have a graphical boot menu, or
> support dfu - because Qi doesn't know how to talk to the hardware.   
> What
> you _can_ do is construct a mini Linux environment that provides a  
> boot
> menu / usb-dfu, and is booted by Qi in the normal way.  This would  
> place
> those tools in regular Linux userspace, i.e. much more accessible to
> regular non kernel / bootloader hackers.  This could be the default or
> secondary boot option - provide a boot menu and then chainload the
> desired final Linux environment.

Isn't this even slower than u-boot?

> There's a philosophical difference between the two projects, and I  
> think
> Qi's approach is much better suited to this kind of hardware, than
> u-boot could ever be (with trunk, or with the existing gripes  
> resolved).

Hm. This makes me raise some questions:
* what is so specific with this hardware so that Qi is better suited?
* is there any indication that Qi is adopted by other hardware projects?

>
>> But you can only influence the future but never change the history...
>>
>
> Wise words! :-)  Imho our time would be better spent building this
> mini-environment (which would probably be best constructed in initrd  
> as
> Paul mentioned) than returning to u-boot.
>
> Any takers?
>
>
> Dave
>
>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

Nikolaus