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