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 inevitably results in u-boot being slower to boot. 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. 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. 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). > 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@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community