[Arm-netbook] A point of confusion re: EOMA-68

[luke.leighton]

On Sun, Oct 13, 2013 at 7:50 PM, Christopher Havel
<laserhawk64 at gmail.com> wrote:
> Hello all!
>
> I just wanted to try and understand something with EOMA-68 -- just a small
> question that's not explained well on the Wiki page. I had a design idea
> that I wanted to draw up (not much of the actual circuitry -- I'm not that
> good -- but enough so that some electronics engineers can "fill in the
> blanks", if you will, with the circuitry I can't figure out), but I've got
> to get this figured out first.

 good idea, that :)

> So I can sort of figure out that external to the CPU Card, there needs to be
> an I2C EEPROM.

 yep.
> What I can't quite figure out is the purpose of that EEPROM.

 to store "description" information that allows a CPU Card to work out
what the "non-self-describing" interfaces are to be used for.

 the last time this was discussed (on the list about 18 months ago)
the general consensus was "store a device tree file in it".  exactly
how that is to be organised has yet to be decided.

> I'm *guessing* that it's for IDing what the external interfaces are on the
> host board / carrier board (the PCB that the CPU Card plugs into)

 correct.  USB2: self-describing.  SATA: self-describing.  Ethernet:
self-describing.  I2C: there are "heuristics" but it's a bad idea to
rely on them, hence the hardware behind the I2C bus needs identifying.
 GPIO: *definitely* not self-describing.  RGB/TTL: definitely not
self-describing.

> so that the CPU card can turn off what's not needed,

 ... can't turn it if it don't know it's there, can it? :)

basically the format hasn't yet been decided - this is going to need
some discussion, some linux kernel driver code, some hacking on u-boot
and so on.

but the general idea is that device-tree files will specify basic
things such as:

"there is a reset button, it uses the 'reset switch' linux kernel
driver, and that must use GPIO 2 as specified in this section of the
device-tree file wot is stored in the EEPROM at location
0xfeasdasdasdas".

or:

"there is a power button 'capability', it uses an AXP209 which is
(device-tree) on I2C bus 1 at address (device-tree) 0x34, and you need
to load the 'use-axp209-power-button-linux-kernel-driver'
(device-tree) to access it"

or:

"there is an RGB/TTL thing which (device-tree) outputs in VGA
therefore we can't tell you what resolutions are because they're not
fixed so using the 'read-edid-linux-kernel-driver' (device-tree) you
get the information from the I2C bus 1 (device tree) at address NNN
(device-tree) in order to read the EDID information such that you can
find out the VGA resolution".

is that sufficiently general to illustrate the purpose and enough in
the way of examples so as to illustrate why those examples are not on
the wiki page because they are nothing to do with the specification,
which has not specifically yet been discussed or agreed as to the
format, yet?

l.