The major reason for Qi's existence is maintainability. U-Boot has a problem with all drivers for different HW being copied from the kernel tree. When the kernel is updated/patched, the fixes don't automagically appear in U-Boot. Qi instead try to do as little as possible to be HW independant. Then you can use a mini-kernel to make a boot menu. In this way you get all the fixes from upstream development without the need of any manual copy/paste and possible further debugging to get it to work.
>From a strict user perspective, Qi don't give any more features. However it's a lot easier to make new features for Qi, since you can use normal development tools and don't have to learn the "U-Boot" way. If X is installed for the boot-menu, it can use a lot of eye-candy! (although probably way to heavy) /Micael On Tue, Jun 2, 2009 at 3:54 PM, Joachim Ott <jo.o...@googlemail.com> wrote: > 2009/6/2 Robin Paulson <robin.paul...@gmail.com>: >> 2009/6/2 Al Johnson <openm...@mazikeen.demon.co.uk>: >>> On Tuesday 26 May 2009, Robin Paulson wrote: >>>> there's no incentive i can see to stay with uboot >>> >>> You probably don't have 4 different distros on your SD then ;-) >> >> no, i don't. >> >> but it doesn't look like it will be long before qi can do multi-boot >> >> http://wiki.openmoko.org/wiki/Qi#Boot_Menu > > Quoting from that paragraph: > > - Therefore Qi does NOT provide a boot menu. This should rather be > implemented by a minimal Kernel, initramfs and menu system. > > Qi will not initialize any video, that's why it needs to boot a > mini-kernel which then provides a boot menu where a user can select > from which partition he wants to boot. I ask you, what was wrong with > u-boot, which already did that without that mini-kernel? It cannot be > speeding up the boot-process, because the loading time for Qi or > u-boot cannot be much different, and when the kernel is loaded and > started, both loaders vanish. I'm sure you can add a kernel > cmdline-param -quiet to u-boot too. > > _______________________________________________ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > _______________________________________________ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support