[Arm-netbook] motherboard negotiation

[lkcl luke]

On Fri, Jan 13, 2012 at 5:43 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Fri, Jan 13, 2012 at 11:09 AM, lkcl luke <luke.leighton at gmail.com> wrote:
>> ok, separate discussion
>>
>> i'd taken into consideration being able to identify motherboards, by
>> putting in an I2C EEPROM.  various ideas included having a USB-like
>> "category / class" thing, and also the idea of putting the linux
>> kernel device tree data directly into the I2C EEPROM had occurred to
>> me.
>
> A scheme based on device tree is probably the best bet. uboot already
> takes the built-in device tree and adjusts it for the amount RAM,
> flash, CPU clk speed.

 ok cool, that's a good starting point

> The base board will need to have some device tree nodes described in
> the EEPROM. The uboot on the EOMA card will read these and then look
> for markers in it's tree on where to insert these nodes. This is
> similar to how clock speed is fixed up.
>
> You need to use substitution markers since EOMA board 1 might have
> i2c-1 connected to the PCMCIA connector and board 2 might have i2c-3
> brought out to the connector. Or it might not have anything connected.

 ok, so, strictly speaking, there would need to be devicetree
fragments, including:

 * one for the LCD interface
 * one for the USB bus
 * one for the I2C bus
 * one for SATA (or is this generic enough to just have a bit "yes or
no" hmm no it isn't, you could have an SATA bus IC splitting to 16
devices)
 * another for Ethernet (or is this generic enough to have one bit
"yes or no" i think it might be)
 * 16 for each of the GPIO pins

i don't think it's worthwhile worrying about the expansion header.

you know... this sounds like the allwinner system would actually be
more flexible.


> You can't put the full device tree into the baseboard since you are
> planning on changing CPUs in the future.

 ouch.  that hadn't occurred to me.

 l.