[Arm-netbook] defining the eoma68 eeprom usage

[Aaron J. Seigo]

On Tuesday, November 5, 2013 12:12:16 mike.valk at 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 :)

-- 
Aaron J. Seigo