[Arm-netbook] motherboard negotiation

[lkcl luke]

On Fri, Jan 13, 2012 at 7:56 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Fri, Jan 13, 2012 at 2:48 PM, lkcl luke <luke.leighton at gmail.com> wrote:
>> 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
>
> this one is need

 yes.  full spec of the darn LCD panel.  *sigh*.  i talked to wookey
about this one, a while back.  people who only do x86 linux kernel
hacking simply have no idea that every single f*****g LCD panel in
existence in every single product with very few exceptions is
hard-coded into the linux kernel, on a per-product basis.

the reason is simple: it's normally the BIOS's problem and/or the VGA
graphics card's problem, but that isn't the case in the embedded
world.

so, the infrastructure to do dynamic panel attachment and discovery
simply is... non-existent.

>>  * one for the USB bus
>
> don't need this one, USB is discoverable
> node on the EOMA device tree to say that you have a USB bus

 of course.  good point.

>>  * one for the I2C bus
>
> the node for the i2c bus will be in the EOMA device tree
> you need nodes in the base board for the objects that are on the bus.

 ok, so it's discoverable, too, effectively?


>>  * 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)
>
> EOMA device tree has node indicating presence of SATA controller
> SATA is discoverable so no need for baseboard support

 ack.

>>  * another for Ethernet (or is this generic enough to have one bit
>> "yes or no" i think it might be)
>
> Node for the Ethernet controller be in the EOMA tree
> Node for the PHY chip, on the baseboard? where is it?

 has to be on the baseboard, because you can't put MII ethernet out.
it has to be the balanced-line pairs.

>>  * 16 for each of the GPIO pins
>
> That one is a lot more complicated if the GPIOs can be remapped into
> other devices.

  yes.

 ok, so... actually... we're down to two groups:

 1) LCD
 2) GPIO.

 which is kinda good.

 l.