Hi...
On the eoma68 spec it says:
"The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68."
My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree. It would be most useful if there was a definition on the layout. *cough* A defined data structure allowing for future expansion as well as vendor specific additions would be golden.
A simple page based system would suffice afaics. Sth like:
Address Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data 0x06 val 0x02 Page data
Page data would (obviously) be limited to a maximum 64k in size, but that really should not be an issue given the application (and given how much data you can read at a time via i2c_smbus calls). A checksum could be added to the page header if desired to verify the data read in, but that could also be left to the page specific data. I don’t think a checksum is needed for the device ID page, for instance.
Page identifiers would be things like: "0x01 Device ID".
A simple, sequential page ordering would to make it easy to use a function lookup table to parse the data. Page 0x00 would be a special “there are no more pages” id.
The page ID # space could be split in 2 between EOMA68 and vendor, giving 32768 possible page IDs to both (far more than necessary, but 1 byte isn’t enough, and i don’t see any benefit to trying to pack bytes together and bit twiddling on the software side to unpack them). this would have the nice characteristic of any page id with the high bit set to 1 would be a vendor page.
The device ID page data definition might look sth like:
Size in Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring
A set of defined pages would be marked as REQUIRED and standard page IDs would be defined as well. I’d actually recommend this definition to be housed *outside* of the EOMA68 spec so that it can be used more broadly by the open hardware community (where such things seem non-existent) and to keep the EOMA68 spec from becoming too monstrous.
This approach would have a number of advantages imo:
* quick access to any given page without lots of index overhead (just jump through the page headers) * minimum size is self documenting: all REQUIRED pages (e.g. device ID page) become the minimum size for the EEPROM on the device * It avoids (imho) stupid hard coded lengths; it’s no longer 1985, even in the embedded world people and many/most of the products we’re working on have application class processors, and even the ones with “just” microcontrolers can do a hell of a lot such that hard coded page sizes just don’t make sense * It allows some vendor flexibility
I am willing to write a small C library that takes a well formed set of data, parses all the EOMA68 bits and offers nice API to access things like device ID data, keeping implementation details at arms length from applications. I could also provide a tool that takes a descriptor file in a human readable format and converts it into a proper EOMA68 packed structure to be written to an EEPROM. Obviously we need agreement on the above before I do this.
Some additional semi-random notes from reading the EOMA68 spec regarding the EEPROM:
In the "Start-up procedure” section, it gives the EEPROM address as 0xA2 rather than 0x51. I would recommend not putting the address here, but rather dealing with all those details in the "Requirements for I2C” section and giving the EEPROM a proper name there (e.g. the RID EEPROM, for Required IDentification).
In fact, I’d re-org that section entirely to be like:
Required Interfaces Rational for interface selections* i2c The "Required IDentification” EEPROM USB SATA ETHERNET RGB/TTL
* I would remove all mention of specific vendors here; this is a specification after all, so I’d kill the last para about All Winner and costing. I would also move each of the line items about the interfaces to the section on that interface
Thoughts?
hi aaron, thanks for joining in here. most welcome.
On Sun, Nov 3, 2013 at 9:34 AM, Aaron J. Seigo aseigo@kde.org wrote:
Hi...
On the eoma68 spec it says:
"The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68."
yes. my concerns here are that the EEPROM would be overwritten by user applications otherwise, potentially destroying the ability of CPU Cards to identify the device. as it is i'm concerned about the possibility of android viruses resulting in the id info being destroyed and ending up with mass product recalls. if it wasn't for the possibility of kernel upgrades breaking device-tree file format or interoperability i would have said it has to be a one-time fusable PROM [or at least there being a factory-install write protect on the EEPROM].
the hardware's not going to change, so why would the data representing it change?
My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree.
there was some debate about whether device node trees *plural* would be more appropriate - one per "thing". e.g. "GPIO pin 5" would have its own device-tree node describing what it was for. "LCD" would have its own device-node tree in lieu of most LCDs not properly supporting EDID [and even when they do they often have totally false data] and so on.
the other possibility being considered was to turn that on its head and define "purposes". such as a "Reset" purpose, to which "GPIO5" happens to be allocated. and "display", to which "LCD" happens to be allocated. this would make more sense inasmuch as some hardware devices will have e.g. DisplayLink USB-based screens, but then those are USB and they're self-describing so are out-of-scope _anyway_.
It would be most useful if there was a definition on the layout.
indeed! it's been very much a "we'll cross that bridge when we get to it" thing - and that's almost time, now.
*cough*
:)
A defined data structure allowing for future expansion
yes. this can be something as simple as a bit field (i learned a trick or two from microsoft and the DCE/RPC specification). the trick is describe "capabilities" rather than have "revision numbers" - how can future hardware / software otherwise support interoperability? i've been working with Ettus Research USRPs recently and their hard-coded use of "revision numbers" for communications formats between firmware and the libraries is a downgrade-upgrade nightmare. so. yes. bit-field with "capabilities" where the last bit is reserved for "yet more future expansion" a la escape-sequence.
as well as vendor specific additions would be golden.
ah. right. knowing partly the answer already [and thank you for agreeing to join the list to discuss this!], i have to ask, for the benefit of the list: what _kind_ of vendor-specific additions? specific examples, general examples, doesn't matter.
bear in mind that the EEPROM is only 32k in size, it's a $0.10 part, and its main purpose is to store this critical missing identification data that all the other EOMA68 buses don't need because they're self-describing.
A simple page based system would suffice afaics. Sth like:
Address Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data 0x06 val 0x02 Page data
Page data would (obviously) be limited to a maximum 64k in size, but that really should not be an issue given the application (and given how much data you can read at a time via i2c_smbus calls). A checksum could be added to the page header if desired to verify the data read in, but that could also be left to the page specific data. I don’t think a checksum is needed for the device ID page, for instance.
i recommend having at least one byte saying "capabilities", as the first byte. then you can read that first byte and go "oh. bit {say} 5 is set! that means we use the new-spangly-expanded-data-format" which happens to be that you use 32-bit addressing not 16-bit for example. 8th bit you set to be "escape sequence".
then, yes! you can set one of the bits as "there is a checksum". another way to do this is to have a checksum "page". hmm, so many possibilities...
Page identifiers would be things like: "0x01 Device ID".
originally i was going to follow the principle of USB class : vendor. but now that i think about it this is best reserved for an actual in-page piece of information. so there would be "0x01 Device ID Page Info" then a page with that type would have... oh you describe it below already :)
A simple, sequential page ordering would to make it easy to use a function lookup table to parse the data. Page 0x00 would be a special “there are no more pages” id.
... giving a simple linked list in effect. yes. like it.
The page ID # space could be split in 2 between EOMA68 and vendor, giving 32768 possible page IDs to both (far more than necessary, but 1 byte isn’t enough, and i don’t see any benefit to trying to pack bytes together and bit twiddling on the software side to unpack them).
true.
this would have the nice characteristic of any page id with the high bit set to 1 would be a vendor page.
... but, again, before getting to that, i'd like to determine what those vendor-specific applications are, and to discuss whether it's appropriate to even have them. given the potential risks of having the hardware destroyed by user applications getting it wrong i'm inclined very much towards the "absolutely not" end of the spectrum.
i owned a Motorola A1200. actually i owned two. one of them was already a brick (ebay purchase... *sigh*...) in the end i worked out what happened, after i had the phone switched off over a timezone change. basically when i powered the phone up after a prolonged period of disuse, it tried to overwrite its own firmware, got it wrong, and destroyed itself. that was _two_ $300 costly bricks i owned. both of them out of warranty.
so for safety, even _allowing_ vendors to write to the EEPROM is something that i would like to see *actively* prevented.
if vendors *really* want some non-volatile space, there's a couple of options. 1) some NAND/NOR 2) a second EEPROM [with a different address] 3) other [e.g. a proper crypto-chip].
these I2C EEPROMs are only $0.10 to $0.15 so it's not a huge deal to put a 2nd one down on any board.
The device ID page data definition might look sth like:
Size in Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring
can i think of anything else here.... no i think you have it covered. the guiding principle here is the USB spec / consortium. and the linux kernel MACHINE_TYPE registry.
A set of defined pages would be marked as REQUIRED and standard page IDs would be defined as well. I’d actually recommend this definition to be housed *outside* of the EOMA68 spec so that it can be used more broadly by the open hardware community (where such things seem non-existent) and to keep the EOMA68 spec from becoming too monstrous.
yes. 2nd spec. and separate registry.
This approach would have a number of advantages imo:
- quick access to any given page without lots of index overhead (just jump
through the page headers)
yep.
- minimum size is self documenting: all REQUIRED pages (e.g. device ID page)
become the minimum size for the EEPROM on the device
yep.
- It avoids (imho) stupid hard coded lengths;
duh.
it’s no longer 1985, even in the embedded world people and many/most of the products we’re working on have application class processors, and even the ones with “just” microcontrolers can do a hell of a lot such that hard coded page sizes just don’t make sense
- It allows some vendor flexibility
... let's discuss this separately ok?
I am willing to write a small C library that takes a well formed set of data, parses all the EOMA68 bits and offers nice API to access things like device ID data, keeping implementation details at arms length from applications. I could also provide a tool that takes a descriptor file in a human readable format and converts it into a proper EOMA68 packed structure to be written to an EEPROM.
awesome!
Obviously we need agreement on the above before I do this.
yes. my only main addition would be that "capabilities" field, as well as asking you to come up with some reasonable argument as to why the risk of vendors (or viruses) overwriting critical data should be considered.
Some additional semi-random notes from reading the EOMA68 spec regarding the EEPROM:
In the "Start-up procedure” section, it gives the EEPROM address as 0xA2 rather than 0x51. I would recommend not putting the address here, but rather dealing with all those details in the "Requirements for I2C” section and giving the EEPROM a proper name there (e.g. the RID EEPROM, for Required IDentification).
... ey good idea.
In fact, I’d re-org that section entirely to be like:
Required Interfaces Rational for interface selections* i2c The "Required IDentification” EEPROM USB SATA ETHERNET RGB/TTL
- I would remove all mention of specific vendors here; this is a specification
after all,
true.
so I’d kill the last para about All Winner and costing. I would also move each of the line items about the interfaces to the section on that interface
Thoughts?
register on elinux.org, knock yourself out. it's a wiki after all :) let's see what happens. i really appreciate someon else being willing to contribute to the development process in such a large way that helps make the spec "real".
l.
On Sunday, November 3, 2013 11:03:15 luke.leighton wrote:
hi aaron, thanks for joining in here. most welcome.
:)
On Sun, Nov 3, 2013 at 9:34 AM, Aaron J. Seigo aseigo@kde.org wrote:
"The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68."
yes. my concerns here are that the EEPROM would be overwritten by user applications otherwise, potentially destroying the ability of CPU Cards to identify the device.
this will depend on the device. for an engineering board, you almost certainly want this ability. for a security device, you probably don’t.
since being able to write to the eeprom once it leaves the factory is a decision made in the choice of eeprom and the PCB writing, i’d suggest leaving this up to the device and simply note in the spec the pros/cons of each.
the hardware's not going to change, so why would the data representing it change?
the device id could be changed. consider people creating custom solutions using a generic engineering kit as an example. not only can they wire things to the 44 pin DIL, but they may wish to give their project a custom ID.
My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree.
there was some debate about whether device node trees *plural* would be more appropriate - one per "thing". e.g. "GPIO pin 5" would have
yes, this is an entirely other discussion, namely: “What should the device node page(s) format be?"
as well as vendor specific additions would be golden.
ah. right. knowing partly the answer already [and thank you for agreeing to join the list to discuss this!], i have to ask, for the benefit of the list: what _kind_ of vendor-specific additions? specific examples, general examples, doesn't matter.
encryption keys in hardware.
bear in mind that the EEPROM is only 32k in size, it's a $0.10 part, and its main purpose is to store this critical missing identification data that all the other EOMA68 buses don't need because they're self-describing.
it is just far more elegant a solution imho to have one “this is the device information” EEPROM than have multiple ones that are all underutilized. yes, it’s a 0.10 part but i don’t see the point of using more materials, require more space on the PCB, etc.
A simple page based system would suffice afaics. Sth like:
Address Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data 0x06 val 0x02 Page data
Page data would (obviously) be limited to a maximum 64k in size, but that really should not be an issue given the application (and given how much data you can read at a time via i2c_smbus calls). A checksum could be added to the page header if desired to verify the data read in, but that could also be left to the page specific data. I don’t think a checksum is needed for the device ID page, for instance.
i recommend having at least one byte saying "capabilities", as the first byte. then you can read that first byte and go "oh. bit {say} 5 is set! that means we use the new-spangly-expanded-data-format" which happens to be that you use 32-bit addressing not 16-bit for example. 8th bit you set to be "escape sequence".
good point; so we’ll put another 4 byte header at the front of the whole thing. i had such a thing in my first draft, but dropped it as unnecessary overhead .. but a version byte makes lots of sense.
4 bytes for the data header so we can fetch it all with a single i2c_smbus_read_word_data and have a checksum, etc. so:
Address Size Value ====== === ==== 0x00 2 Capabilities byte 0x02 1 Checksum byte 0x03 1 Reserved
We would leave the capabilities bytes as 0x00 for now, and mark all bits reserved. This would give us 16 ‘capabilities’ to twiddle with in future. We have another reserved byte in their for future use and a checksum byte.
I briefly considered using that reserved byte for a page count, but it only saves 2 bytes in total, didn’t seem worth it, especially since that would not give us a “total amount of data to read from the eeprom”.
If we really wanted to get fancypants, we could add another 4 byte word that is the total size of the EOMA68 paged data block and then read the whole thing in one go from the EEPROM. I’m not sure there is really any benefit to this, however.
We can play with this an other options when we try it on actual hardware, of course.
then, yes! you can set one of the bits as "there is a checksum". another way to do this is to have a checksum "page". hmm, so many possibilities...
Page identifiers would be things like: "0x01 Device ID".
originally i was going to follow the principle of USB class : vendor. but now that i think about it this is best reserved for an actual in-page piece of information. so there would be "0x01 Device ID Page Info" then a page with that type would have... oh you describe it below already :)
even the USB standard mandates having all the data described below on the device. only the USB standard is really poorly done: 16 bits for all the USB manufacturers in the world? 16 bits for all the devices any one manufacturer will ever make? meh.
A simple, sequential page ordering would to make it easy to use a function lookup table to parse the data. Page 0x00 would be a special “there are no more pages” id.
... giving a simple linked list in effect. yes. like it.
exactly ...
this would have the nice characteristic of any page id with the high bit set to 1 would be a vendor page.
... but, again, before getting to that, i'd like to determine what those vendor-specific applications are, and to discuss whether it's appropriate to even have them. given the potential risks of having the hardware destroyed by user applications getting it wrong i'm inclined very much towards the "absolutely not" end of the spectrum.
whether or not user applications *write* to the EEPROM is an entirely other matter.
the point is to be able to put device/vendor specific data on the EEPROM that can be read out at runtime. again, use case: encryption keys stored in hardware.
they can then be read at any time during the boot process to do things like create an encrypted tunnel on the network.
by having them in the EEPROM we would:
* avoid another component on the PCB (cost, complexity and ecological benefits) * have this data somewhere we could make non-writable
this NOT, however, about saving random application data generated at runtime.
we have NAND and network for that.
i owned a Motorola A1200. actually i owned two. one of them was already a brick (ebay purchase... *sigh*...) in the end i worked out what happened, after i had the phone switched off over a timezone change. basically when i powered the phone up after a prolonged period of disuse, it tried to overwrite its own firmware, got it wrong, and destroyed itself. that was _two_ $300 costly bricks i owned. both of them out of warranty.
a) i hope we never store *firmware* on the EEPROM b) one hopes we’d provide a way to write to the EEPROM even if the data on it gets messed up. with all the tinkering with uboot we’ve done in the past over the OTG port, i can’t imagine this is out of the realm of reason.
so for safety, even _allowing_ vendors to write to the EEPROM is something that i would like to see *actively* prevented.
writing is a secondary concern and imho is a decision that must be made on device-by-device basis. or would you like mebv2 to not be able to certify as EOMA68 compatible?
if vendors *really* want some non-volatile space, there's a couple of options. 1) some NAND/NOR 2) a second EEPROM [with a different address] 3) other [e.g. a proper crypto-chip].
honestly, requiring more hardware on PCB is ludicrous. let’s assume the vendor is completely incompetent and hoses their data on a theoretical second EEPROM. how good is the device now? you can’t save people from themselves. you can, however, make the specification less attractive and more expensive to use.
these I2C EEPROMs are only $0.10 to $0.15 so it's not a huge deal to put a 2nd one down on any board.
a 64k chip is 2.5-3x the price, it means another address on the i2c bus and more routing on the PCB.
The device ID page data definition might look sth like:
Size in Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring
can i think of anything else here.... no i think you have it covered. the guiding principle here is the USB spec / consortium. and the linux kernel MACHINE_TYPE registry.
yep.
On Mon, Nov 4, 2013 at 9:57 AM, Aaron J. Seigo aseigo@kde.org wrote:
On Sunday, November 3, 2013 11:03:15 luke.leighton wrote:
hi aaron, thanks for joining in here. most welcome.
:)
On Sun, Nov 3, 2013 at 9:34 AM, Aaron J. Seigo aseigo@kde.org wrote:
"The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68."
yes. my concerns here are that the EEPROM would be overwritten by user applications otherwise, potentially destroying the ability of CPU Cards to identify the device.
this will depend on the device. for an engineering board, you almost certainly want this ability.
yes. engineering boards would not be classed as "mass-volume end-user" boards. the requirements are very different. EOMA68 is designed as a mass-volume standard.
for a security device, you probably don’t.
a security device would be an end-user board.
since being able to write to the eeprom once it leaves the factory is a decision made in the choice of eeprom and the PCB writing, i’d suggest leaving this up to the device and simply note in the spec the pros/cons of each.
my feeling is that it has to be stronger than that. the risks of mass-returns in the context of mass-volume distribution are too great. what i think i will do is put in the spec that end-user applications (including the linux kernel and boot software) should assume that the EEPROM has been made write-only, and that methods for updating it for firmware-update should be taken into consideration during the hardware design phase.
engineering boards would be completely exempt from this inasmuch as the engineer-types would be doing much riskier things. and they're a smaller market.
the hardware's not going to change, so why would the data representing it change?
the device id could be changed. consider people creating custom solutions using a generic engineering kit as an example. not only can they wire things to the 44 pin DIL, but they may wish to give their project a custom ID.
yes. not a problem.
My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree.
there was some debate about whether device node trees *plural* would be more appropriate - one per "thing". e.g. "GPIO pin 5" would have
yes, this is an entirely other discussion, namely: “What should the device node page(s) format be?"
ack!
as well as vendor specific additions would be golden.
ah. right. knowing partly the answer already [and thank you for agreeing to join the list to discuss this!], i have to ask, for the benefit of the list: what _kind_ of vendor-specific additions? specific examples, general examples, doesn't matter.
encryption keys in hardware.
then a crypto chip should be used, or a SoC which has TPM, or has a bootloader area or on-board secure PROM - *anything* but an open readable EEPROM.
remember that the difference between the NAND on the CPU Card, the EEPROM on the I/O board and the NAND on the ATSAM4S as far as security is concerned is absolutely zero.
in the case of the flying squirrel, if encryption keys are to be stored anywhere they can be stored in the on-board NAND of the ATSAM4S, which has i think 128k available. if you want me to make it possible at factory-time to disable NAND-erase (via an internal jumper or something) then i need to know very soon. otherwise the NAND could be reset (factory-erased) by simply pulling a GPIO pin high over EOMA68 GPIO and the ATSAM4S will sit waiting in USB-upload mode.
if that's disableable then you have a means to upload a program and have it _stay_ there, with a proper crypto protocol / handshake implemented in c that would prevent and prohibit access to the encryption keys until the correct authorisation had been given.
this would be much more secure, would be zero cost in hardware terms and would also have the benefit of not risking product destruction and destruction of the efforts to create a mass-volume modular standard.
i recommend having at least one byte saying "capabilities", as the first byte. then you can read that first byte and go "oh. bit {say} 5 is set! that means we use the new-spangly-expanded-data-format" which happens to be that you use 32-bit addressing not 16-bit for example. 8th bit you set to be "escape sequence".
good point; so we’ll put another 4 byte header at the front of the whole thing. i had such a thing in my first draft, but dropped it as unnecessary overhead .. but a version byte makes lots of sense.
_capabilities_ byte. there's a big big difference.
4 bytes for the data header so we can fetch it all with a single i2c_smbus_read_word_data and have a checksum, etc. so:
Address Size Value ====== === ==== 0x00 2 Capabilities byte 0x02 1 Checksum byte 0x03 1 Reserved
We would leave the capabilities bytes as 0x00 for now, and mark all bits reserved.
ack.
This would give us 16 ‘capabilities’ to twiddle with in future. We have another reserved byte in their for future use and a checksum byte.
good idea.
I briefly considered using that reserved byte for a page count, but it only saves 2 bytes in total, didn’t seem worth it, especially since that would not give us a “total amount of data to read from the eeprom”.
If we really wanted to get fancypants, we could add another 4 byte word that is the total size of the EOMA68 paged data block and then read the whole thing in one go from the EEPROM. I’m not sure there is really any benefit to this, however.
complexity.
We can play with this an other options when we try it on actual hardware, of course.
agreed.
then, yes! you can set one of the bits as "there is a checksum". another way to do this is to have a checksum "page". hmm, so many possibilities...
Page identifiers would be things like: "0x01 Device ID".
originally i was going to follow the principle of USB class : vendor. but now that i think about it this is best reserved for an actual in-page piece of information. so there would be "0x01 Device ID Page Info" then a page with that type would have... oh you describe it below already :)
even the USB standard mandates having all the data described below on the device. only the USB standard is really poorly done: 16 bits for all the USB manufacturers in the world? 16 bits for all the devices any one manufacturer will ever make? meh.
:)
ok i have to go over the rest later.
l.
On Monday, November 4, 2013 10:56:20 luke.leighton wrote:
this will depend on the device. for an engineering board, you almost certainly want this ability.
yes. engineering boards would not be classed as "mass-volume end-user" boards.
raspberry pi has sold 1.75+ million units so far. people are putting them into products like POS terminals (saw a crowd funding campaign for such a thing the other week).
for the maker community, this concept of “mass volume end-user board” is simply out of touch with reality.
the requirements are very different. EOMA68 is designed as a mass-volume standard.
so then:
* engineering kits that use EOMA68 cards should be assumed to be an invalid method for designing devices that are EOMA68 compliant since they will not adhere to the same standard. any device made with an engineering kit will not be able to pass (future) EOMA68 specification tests and so should not be considered a way to fully prototype an EOMA68 based product.
* EOMA68 is uninterested in powering devices for which there may be only 1000, 100 or even just 10 of them made.
i’d like to know now before i invest more time in this.
for a security device, you probably don’t.
a security device would be an end-user board.
since being able to write to the eeprom once it leaves the factory is a decision made in the choice of eeprom and the PCB writing, i’d suggest leaving this up to the device and simply note in the spec the pros/cons of each.
my feeling is that it has to be stronger than that. the risks of mass-returns in the context of mass-volume distribution are too great.
this is not your risk. i don’t understand why you feel you need to save others from themselves. it is not your responsibility to do so.
what i think i will do is put in the spec that end-user applications (including the linux kernel and boot software) should assume that the EEPROM has been made write-only, and that methods for updating it for firmware-update should be taken into consideration during the hardware design phase.
i agree that it is sane for portable applications to assume that the EEPROM is not writable and that the EOMA68 spec should not require that the EEPROM is writable.
the hardware's not going to change, so why would the data
representing it change?
the device id could be changed. consider people creating custom solutions using a generic engineering kit as an example. not only can they wire things to the 44 pin DIL, but they may wish to give their project a custom ID.
yes. not a problem.
great. so tell me how they do that without a writable eeprom? or is your answer to them “yes, you don’t get to adhere to the EOMA68 standard for your point of sale device because you only made a few hundred of them and you used some off-the-shelf engineering kit to do so”?
encryption keys in hardware.
then a crypto chip should be used, or a SoC which has TPM, or has a bootloader area or on-board secure PROM - *anything* but an open readable EEPROM.
i’m really not looking for advice from you on how to do this, and you’re missing the point:
what to put on the EEPROM is something we need to know for the upcoming MEB. i’d *like* that layout to be compatible with whatever might follow.
so let’s pretend instead of a crypto cert, i want to store a bitmap of a penguin on the eeprom. why? it doesn’t matter. i just do.
so let's define an EEPROM data layout so we can both get back to useful things.
in the case of the flying squirrel,
it has nothing to do with ‘flying squirrel’.
please, say on topic.
On Mon, Nov 4, 2013 at 2:51 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Monday, November 4, 2013 10:56:20 luke.leighton wrote:
this will depend on the device. for an engineering board, you almost certainly want this ability.
yes. engineering boards would not be classed as "mass-volume end-user" boards.
raspberry pi has sold 1.75+ million units so far. people are putting them into products like POS terminals (saw a crowd funding campaign for such a thing the other week).
1.75 million is still one to two orders of magnitude below what EOMA68 is designed for. the considerations are completely different inasmuch as they *encompass* what the rbpi is attempting to do.
anyway - i think later messages cover the gist of this, in a more compact form (number "c") so i'll leave it at that.
l.
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
The Most recent revision MEBs have a 64K EEPROM, perhaps we could split the single eeprom memory into two segments?
On Mon, Nov 4, 2013 at 9:30 PM, Christopher Thomas christopher@firemothindustries.com wrote:
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
Device Tree eats this much:
user$ du -h arch/arm/boot/dts/*.dtb | grep sun 12K arch/arm/boot/dts/sun4i-a10-a1000.dtb 12K arch/arm/boot/dts/sun4i-a10-cubieboard.dtb 12K arch/arm/boot/dts/sun4i-a10-hackberry.dtb 12K arch/arm/boot/dts/sun4i-a10-mini-xplus.dtb 8.0K arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dtb 8.0K arch/arm/boot/dts/sun5i-a13-olinuxino.dtb 8.0K arch/arm/boot/dts/sun6i-a31-colombus.dtb 12K arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb 12K arch/arm/boot/dts/sun7i-a20-cubietruck.dtb 12K arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb
The Most recent revision MEBs have a 64K EEPROM, perhaps we could split the single eeprom memory into two segments?
-- Christopher Thomas Firemoth Industries, LLC - Owner christopher@firemothindustries.com 214-458-5990
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 11/4/2013 3:35 PM, Arokux X wrote:
On Mon, Nov 4, 2013 at 9:30 PM, Christopher Thomas christopher@firemothindustries.com wrote:
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
Device Tree eats this much:
user$ du -h arch/arm/boot/dts/*.dtb | grep sun 12K arch/arm/boot/dts/sun4i-a10-a1000.dtb 12K arch/arm/boot/dts/sun4i-a10-cubieboard.dtb 12K arch/arm/boot/dts/sun4i-a10-hackberry.dtb 12K arch/arm/boot/dts/sun4i-a10-mini-xplus.dtb 8.0K arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dtb 8.0K arch/arm/boot/dts/sun5i-a13-olinuxino.dtb 8.0K arch/arm/boot/dts/sun6i-a31-colombus.dtb 12K arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb 12K arch/arm/boot/dts/sun7i-a20-cubietruck.dtb 12K arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb
The Most recent revision MEBs have a 64K EEPROM, perhaps we could split the single eeprom memory into two segments?
-- Christopher Thomas Firemoth Industries, LLC - Owner christopher@firemothindustries.com 214-458-5990
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
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
...that's 108k.
Also, I like the idea that IIRC Luke had -- two EEPROMs, one writable by the OS (for userspace or config data) and one not (for device data). Unbrickability is a definite virtue :D
On Mon, Nov 4, 2013 at 9:53 PM, Christopher Havel laserhawk64@gmail.com wrote:
On 11/4/2013 3:35 PM, Arokux X wrote:
On Mon, Nov 4, 2013 at 9:30 PM, Christopher Thomas christopher@firemothindustries.com wrote:
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
Device Tree eats this much:
user$ du -h arch/arm/boot/dts/*.dtb | grep sun 12K arch/arm/boot/dts/sun4i-a10-a1000.dtb 12K arch/arm/boot/dts/sun4i-a10-cubieboard.dtb 12K arch/arm/boot/dts/sun4i-a10-hackberry.dtb 12K arch/arm/boot/dts/sun4i-a10-mini-xplus.dtb 8.0K arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dtb 8.0K arch/arm/boot/dts/sun5i-a13-olinuxino.dtb 8.0K arch/arm/boot/dts/sun6i-a31-colombus.dtb 12K arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb 12K arch/arm/boot/dts/sun7i-a20-cubietruck.dtb 12K arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb
The Most recent revision MEBs have a 64K EEPROM, perhaps we could split the single eeprom memory into two segments?
-- Christopher Thomas Firemoth Industries, LLC - Owner christopher@firemothindustries.com 214-458-5990
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
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
...that's 108k.
108K? You need only one of those and for EOMA68-A20. These are just examples of the existing device trees. Sorry for not being clear.
Also, I like the idea that IIRC Luke had -- two EEPROMs, one writable by the OS (for userspace or config data) and one not (for device data). Unbrickability is a definite virtue :D
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 Mon, Nov 4, 2013 at 8:35 PM, Arokux X arokux@gmail.com wrote:
On Mon, Nov 4, 2013 at 9:30 PM, Christopher Thomas christopher@firemothindustries.com wrote:
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
Device Tree eats this much:
user$ du -h arch/arm/boot/dts/*.dtb | grep sun 12K arch/arm/boot/dts/sun4i-a10-a1000.dtb 12K arch/arm/boot/dts/sun4i-a10-cubieboard.dtb 12K arch/arm/boot/dts/sun4i-a10-hackberry.dtb 12K arch/arm/boot/dts/sun4i-a10-mini-xplus.dtb 8.0K arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dtb 8.0K arch/arm/boot/dts/sun5i-a13-olinuxino.dtb 8.0K arch/arm/boot/dts/sun6i-a31-colombus.dtb 12K arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb 12K arch/arm/boot/dts/sun7i-a20-cubietruck.dtb 12K arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb
it's completely unnecessary to store the *entire* devicetree on a per-CPU basis. and it would cause huge problems to do so.
instead i expect the "GPIO 0 devicetree" entry to be about... 200 bytes maximum. i expect the "GPIO 1 devicetree" entry to be about 200 bytes. i expect the "LCD specification devicetree" entry to be about 400 bytes. the total number of entries - even if there were 120 I2C devices hanging off the bus - should be well below 8K.
each of those entries _will_ need to be merged into the devicetree arch/arm/boot/dts/sun7i-eoma68-a28.dtb at runtime (by u-boot and by the running linux kernel). that can be dealt with.
l.
On Wednesday, November 6, 2013 14:17:07 luke.leighton wrote:
instead i expect the "GPIO 0 devicetree" entry to be about... 200 bytes maximum. i expect the "GPIO 1 devicetree" entry to be about 200 bytes. i expect the "LCD specification devicetree" entry to be about 400 bytes. the total number of entries - even if there were 120 I2C devices hanging off the bus - should be well below 8K.
do you have working definitions for each of these 3 devicetrees? (so they can be added to the impending spec)
On Wed, Nov 6, 2013 at 2:22 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Wednesday, November 6, 2013 14:17:07 luke.leighton wrote:
instead i expect the "GPIO 0 devicetree" entry to be about... 200 bytes maximum. i expect the "GPIO 1 devicetree" entry to be about 200 bytes. i expect the "LCD specification devicetree" entry to be about 400 bytes. the total number of entries - even if there were 120 I2C devices hanging off the bus - should be well below 8K.
do you have working definitions for each of these 3 devicetrees? (so they can be added to the impending spec)
no - that's another thing been on the TODO list since EOMA68's inception. still up for grabs is a decision to do purpose-based or "physical-thing-based" devicetree entries. "a reset switch devicetree [which happens to use GPIO0]" vs "a GPIO0 devicetree [which happens to be a reset switch]".
personally i'm leaning towards purpose-based as it's more in line with expectations plus a single pin may have multiple uses even within a same hardware personality [shared IRQ line for example].
l.
joem <joem <at> martindale-electric.co.uk> writes:
I2C eeproms dirt cheap - have two eeproms - one user data (such as
calibration data
for instruments, keys, etc) and one for system data.
Note, you already need 2 eeproms, one on the CPU card and one on the carrier board. I believe they are supposed to be on different I2C busses?
However, any time you're going to put user-data in a location, why not use mass-storage? Why put encryption keys into EEPROM? Either they should be bound to the device (use a ROM seperate from EOMA68 device-tree) or they should be mobile (store on HDD/SSD)
On Monday, November 4, 2013 21:47:51 Derek wrote:
joem <joem <at> martindale-electric.co.uk> writes:
I2C eeproms dirt cheap - have two eeproms - one user data (such as
calibration data
for instruments, keys, etc) and one for system data.
Note, you already need 2 eeproms, one on the CPU card and one on the carrier board. I believe they are supposed to be on different I2C busses?
yes; i2c devices on the card are required to be on an internal-only i2c bus, for the obvious addressing collision problems that would arise otherwise.
However, any time you're going to put user-data in a location, why not use mass-storage?
for the same reason we don’t put the device tree or device id in mass storage :)
2013/11/4 Derek dlahouss@mtu.edu
joem <joem <at> martindale-electric.co.uk> writes:
I2C eeproms dirt cheap - have two eeproms - one user data (such as
calibration data
for instruments, keys, etc) and one for system data.
Note, you already need 2 eeproms, one on the CPU card and one on the carrier board. I believe they are supposed to be on different I2C busses?
However, any time you're going to put user-data in a location, why not use mass-storage? Why put encryption keys into EEPROM? Either they should be bound to the device (use a ROM seperate from EOMA68 device-tree) or they should be mobile (store on HDD/SSD)
I just might being numb here. Why do we need EEPROM's ?
The "Carrier" device needs to identify and advertise itself to the "Card" Device. To do so we need a protocol and some storage on the "Carrier". The protocol was chosen as i2c
A "Carrier" like the "flying squirrel" has a micro controller or a low power SoC, ATSAM4S IIRC,which has on-chip or external storage and i2c capabilities.
Why not let the ATSAM4S provide both functions?
I don't believe the "Card" needs to identify or advertise it self it functions are already defined by the spec and it acts as the Master to the "Carrier"
And what is bad in being able to put the ATSAM4S "ready to receive programming" mode from an EOMA68 card. Pro, Ease updating without the need for extra hardware Con, A virus can upload itself to a carrier.
But how is that any different from any other BIOS et al. Sure M$ has implemented secure boot to prevent such a thing. Which in my IMO is not a solution.
The ability to write the storage on the Carrier board I think is quite usefull. The OS on the card can scan for changes and remove unwanted routines like virusses. And upgrade to original and probably not bug free first programming.
_________________ 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 Tuesday, November 5, 2013 12:12:16 mike.valk@gmail.com wrote:
The "Carrier" device needs to identify and advertise itself to the "Card" Device. To do so we need a protocol and some storage on the "Carrier". The protocol was chosen as i2c
yes, it doesn’t have to strictly be an eeprom; it just needs to be some data that can be read at the given i2c address.
the spec could (probably should) be adjusted to reflect that, with the eeprom solution being perhaps offered as a concrete example.
I don't believe the "Card" needs to identify or advertise it self it functions are already defined by the spec and it acts as the Master to the "Carrier"
no, but the chassis needs to relay information to the cpu card.
The ability to write the storage on the Carrier board I think is quite usefull. The OS on the card can scan for changes and remove unwanted routines like virusses. And upgrade to original and probably not bug free first programming.
this thread was not about firmware, but storage of standardized data for things like device tree and device identification information retrieval.
firmware for things like the microcontroller on the flying squirrel board are afaics not covered by the EOMA68 spec at all, nor should they be: they are a device-specific implementation detail.
it would be good if we could keep this discussion on the original topic :)
On Mon, Nov 4, 2013 at 9:47 PM, Derek dlahouss@mtu.edu wrote:
joem <joem <at> martindale-electric.co.uk> writes:
I2C eeproms dirt cheap - have two eeproms - one user data (such as
calibration data
for instruments, keys, etc) and one for system data.
Note, you already need 2 eeproms, one on the CPU card and one on the carrier board. I believe they are supposed to be on different I2C busses?
correct.
... btw there isn't an EEPROM on the EOMA68-A20 - there is NAND (4gbytes of it).
l.
arm-netbook@lists.phcomp.co.uk
-
Aaron J. Seigo -
Arokux X -
Christopher Havel -
Christopher Thomas -
Derek -
joem -
luke.leighton -
mike.valk＠gmail.com