[FSO] add QCT msm7* modem support

Andy Green andy at openmoko.com
Sat Nov 22 18:30:44 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Hi Andy,
|> Just curious about this "machine name" concept, what does it actually
|> address?

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
rootfs configuration.

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
packages such
| as:
| mickey at localhost:/local/pkg/oe/openembedded$ find . -name om-gta01
| ./packages/scummvm/files/om-gta01
| ./packages/uclibc/uclibc-0.9.29/om-gta01
| ./packages/uclibc/uclibc-0.9.30/om-gta01

uClibc cares?

| ./packages/netbase/netbase/om-gta01
| ./packages/u-boot/u-boot-1.2.0/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.

| ./packages/base-files/base-files/om-gta01

Can't guess why that one exists.

| ./packages/tslib/tslib/om-gta01

Or that one, it is the same LCM.

| ./packages/gpephone/gpe-applauncher/om-gta01

No real idea.

| ./packages/gpsd/files/om-gta01

Yes different GPS chip needs a binary blob.

| ./packages/pointercal/files/om-gta01

Again it's the same LCM.

| ./packages/freesmartphone/frameworkd/om-gta01

Dunno, is it /sys?

| ./packages/openmoko2/openmoko-dialer2/om-gta01

Same calypso stuff needs different package?

| ./packages/initscripts/initscripts-1.0/om-gta01

Dunno what the difference can be.

| ./packages/fbset/fbset-modes/om-gta01

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
machines like
| 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
configuration and
| 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.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the devel mailing list