<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/11/4 Derek <span dir="ltr"><<a href="mailto:dlahouss@mtu.edu" target="_blank">dlahouss@mtu.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">joem <joem <at> <a href="http://martindale-electric.co.uk" target="_blank">martindale-electric.co.uk</a>> writes:<br>
<br>
> I2C eeproms dirt cheap - have two eeproms - one user data (such as<br>
calibration data<br>
> for instruments, keys, etc) and one for system data.<br>
><br>
><br>
<br>
</div>Note, you already need 2 eeproms, one on the CPU card and one on the carrier<br>
board.  I believe they are supposed to be on different I2C busses?<br>
<br>
However, any time you're going to put user-data in a location, why not use<br>
mass-storage?  Why put encryption keys into EEPROM?  Either they should be<br>
bound to the device (use a ROM seperate from EOMA68 device-tree) or they<br>
should be mobile (store on HDD/SSD)<br></blockquote><div><br></div><div>I just might being numb here. Why do we need EEPROM's ?<br><br></div><div>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<br>
<br></div><div>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. <br><br>Why not let the ATSAM4S provide both functions?<br>
<br></div><div>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"<br><br></div><div>And what is bad in being able to put the ATSAM4S "ready to receive programming" mode from an EOMA68 card.<br>
</div><div>Pro, Ease updating without the need for extra hardware<br></div><div>Con, A virus can upload itself to a carrier.<br></div><div></div><div><br></div><div>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.<br>
<br></div><div class="h5">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.<br>
<br>_________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a><br>
</div></div><br></div></div>