[Arm-netbook] motherboard negotiation

[jonsmirl at gmail.com]

On Fri, Jan 13, 2012 at 3:10 PM, lkcl luke <luke.leighton at gmail.com> wrote:
> 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.

There is no good solution to the LCD problem, they are simply way too
many variations. I suspect that you'll end up with at most two or
three different LCDs interfaced to the EOMA board.

You also have to deal with the fact that different CPU LCD controllers
have different capabilities. You may make a baseboard for an LCD that
a future CPU does not have the ability to control.

Plus what about touch?  4-wire, 5-wire, capacitive, etc...

Take our current mess for example. We designed for a 24b screen. When
we get the screen it is a 24b screen but it has a 18b controller chip
soldered to it. Now we have to redesign to work around this. The
hardware worked but it messed up all of the software.




>
>>>  * 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.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk



-- 
Jon Smirl
jonsmirl at gmail.com