[Arm-netbook] defining the eoma68 eeprom usage

[Aaron J. Seigo]

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?

-- 
Aaron J. Seigo