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.
So I can sort of figure out that external to the CPU Card, there needs to be an I2C EEPROM. What I can't quite figure out is the purpose of that EEPROM. 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) so that the CPU card can turn off what's not needed, and provide proper I/O protocols to what is needed -- but that's only a guess, because it's extremely unclear on the Wiki page.
Would you folks be able to provide some clarification?
Thanks!
Christopher
On Sun, Oct 13, 2013 at 7:50 PM, Christopher Havel laserhawk64@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.
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@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@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Oct 13, 2013 at 8:41 PM, Christopher Havel laserhawk64@gmail.com wrote:
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
yes - unless you're happy for it to be stripped out and placed onto files.phcomp.co.uk: see the end of the message (signature).
(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...
there's a limit of 40k on the list, set by alain who runs phcomp.co.uk.
l.
arm-netbook@lists.phcomp.co.uk
-
Christopher Havel -
luke.leighton