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

[Christopher Havel]

That's exactly what I needed :)

One more question -- should I want to broadcast an image to the list, 
would it be better done as a hyperlink pointing to a host elsewhere (for 
me this will almost certainly be imgur) or as an email attachment? I'm 
guessing the first (hyperlink) but I figured that it wouldn't hurt to ask...

On 10/13/2013 3:06 PM, luke.leighton wrote:
> 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.
>
> _______________________________________________
> 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