On 12/17/09 08:31, Somebody in the thread at some point said:
Hi -
Just read about this a little late :-)
I wrote the bulk of Qi while at Openmoko.
Qi currently supports samsung s3c24xx series, s3c6410, TI omap3530. The
I also ported it to iMX31.
- Generalize components which could be used in common such as I2C drivers.
Example: platform specific I2C driver -> GPIO bitbang driver.
I wrote a generic bitbang I2C "driver" for Qi back in 2007, it's used on
the GTA02 build IIRC to talk to the PMU:
http://git.warmcat.com/cgi-bin/cgit/qi/tree/src/drivers/i2c-bitbang.c?h=txtr
- Remove duplicated, unused code, header definition. Keep Qi as minimum
as needed.
What I can suggest would be worthwhile goals are:
- extending the targeted CPU arches
- folding the OMAP branch (written by Matt) back into the main tree
- improving the memory test to force burst mode
On the txtr branch (currently they are my customer and we use Qi on
their iMX31 e-book reader) there's already various tidying up and
advances like FAT filesystem, PRNG-based memory test.
http://git.warmcat.com/cgi-bin/cgit/qi/log/?h=txtr
Here is a bit more about the reasoning for bothering with another
bootloader and the philosophy behind Qi.
While working at Openmoko maintaining their kernel, it became obvious
that U-Boot was turning into a mini-me for Linux. Many cut-down Linux
drivers were appearing there, there was a shell with an environment
holding private states like booting action commands. This led to a
situation where two identical devices with same patchlevel of everything
including bootloader may act differently according to what's in that
hidden environment. Wanting a "boot menu" meant supporting graphics and
some of the drivers like for Glamo were complex and always forked from
their Linux counterparts.
The burden of maintaining forked drivers in two places (the U-Boot ones
had to be "dumbed down" to the point it can't share sources) and the
additional complexity of trying to manage power and additional device
state in two places are all actually completely unnecessary. All the
bootloader needs is just enough to get hold of a kernel and boot it.
That is Qi's philosophy in a nutshell: "load [the kernel], then boot".
Linux is then the single place for good support of all assets on the device.
It can work from NAND or NOR but actually the existing support is
designed to work with SD Card boot. Recent devices like s3c6410 and
i.MX31 can completely boot from SD Card, including getting their
bootloader from there. On i.MX31 using this scheme, we are able to boot
to a bash prompt in 2.5s from cold.
Another big problem with U-Boot was the inability to update the
bootloader from the Linux world. Instead the bootloader was treated
special and had to be updated over USB with DFU (the exclusivity of it
enforced by an ECC policy disconnected from Linux, meaning U-Boot had to
write it in there). In Qi, the bootloader can be updated by a packaged
update like anything else in the rootfs.
There are no private environment / states, there are per-board
heuristics for where to look for a kernel, and filesystem files which
can append to kernel commandlines if present. Therefore identical
devices with the same Qi patchlevel will always act the same.
-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
