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 :)