[FSO] add QCT msm7* modem support
andy at openmoko.com
Sat Nov 22 18:30:44 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Hi Andy,
|> Just curious about this "machine name" concept, what does it actually
Thanks for the info.
| This is what you give to OE as the MACHINE settings, it defines things
| * jffs2 params for the rootfs
This is highly raw NAND specific.
| * flash size
Outside of special case of onboard raw NAND, today storage sizes are
bigger to the point it doesn't need to be a real consideration for
Not trying to invalidate the need to work with this for devices that
have no choice, just saying that going on raw NAND constraint is not
necessarily a major factor.
| * serial tty setting
Bootloader has to typically know this: it could export the knowledge.
| * preferred X server
| * machine capabilities in general (phone, screen, keyboard, usbhost, ...)
To some or complete extent chosen kernel has to know this, could export
it. If there's a choice, which kernel chosen is again a bootloader
| This MACHINE setting is also used as OVERRIDE for config file in
| mickey at localhost:/local/pkg/oe/openembedded$ find . -name om-gta01
Yes can't avoid that, bootloader for 2410 and 2442 or 6410 are
different. But it could determine what's righteous by inheriting
something from the bootloader that started Linux.
Can't guess why that one exists.
Or that one, it is the same LCM.
No real idea.
Yes different GPS chip needs a binary blob.
Again it's the same LCM.
Dunno, is it /sys?
Same calypso stuff needs different package?
Dunno what the difference can be.
Guess it's something to do with direct LCD controller vs Glamo, but
still hard to guess exactly what since it is same LCM and we use fbset /
framebuffer kernel driver to abstract it all.
|> It has become clear lately that we need single rootfs image
|> that deals with several types of device, is that what it actually does?
| While a single rootfs image is very appealing, our experience says it
| works well on device families where the siblings are _very_ related.
Underpinning all this is need for instruction set compatibility, ie, can
eat armv4. After that, I think we find everything can be runtime
determined (via cpu-specific bootloader + device-specific kernel)
| (It may work for gta01 and gta02, but we're also talking about
| the Motorola EZX series here or the Zaurus family which have dozens of
| somewhat similar, but still too different variants)
| Of course you can try to achieve most of this with runtime
| shipping stuff for all variants, but you will run into limitations,
| especially regarding flash size.
Fair enough, but only if one runs from NAND.
I wouldn't want to be the guy that said hiding the differences between
these devices in a single rootfs is in any way going to be easy, but, I
think as the number of devices cranks up -- and we can expect it to get
quite large even a couple of years out I think -- the multi-rootfs story
seems to me it won't stay under control, considering these things are
50+MB and take a while to create and the maintainence angle.
In contrast we will definitely need separate kernels per-device whatever
we do... it could be quite interesting to try to cope / expose / own all
device specific detail in the bootloader + kernel with totally shared
rootfs per instruction set, referring to the kernel for any config.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel