On Mon, Nov 4, 2013 at 8:35 PM, Arokux X arokux@gmail.com wrote:
On Mon, Nov 4, 2013 at 9:30 PM, Christopher Thomas christopher@firemothindustries.com wrote:
On Mon, Nov 4, 2013 at 2:05 PM, joem joem@martindale-electric.co.uk wrote:
: yes. my concerns here are that the EEPROM would be overwritten by :user applications otherwise, potentially destroying the ability of CPU :Cards to identify the device.
I2C eeproms dirt cheap - have two eeproms - one user data (such as calibration data for instruments, keys, etc) and one for system data.
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
Given the need for device-tree info, and RID, etc etc, presumably, how large of an EEPROM would we technically need?
Device Tree eats this much:
user$ du -h arch/arm/boot/dts/*.dtb | grep sun 12K arch/arm/boot/dts/sun4i-a10-a1000.dtb 12K arch/arm/boot/dts/sun4i-a10-cubieboard.dtb 12K arch/arm/boot/dts/sun4i-a10-hackberry.dtb 12K arch/arm/boot/dts/sun4i-a10-mini-xplus.dtb 8.0K arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dtb 8.0K arch/arm/boot/dts/sun5i-a13-olinuxino.dtb 8.0K arch/arm/boot/dts/sun6i-a31-colombus.dtb 12K arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb 12K arch/arm/boot/dts/sun7i-a20-cubietruck.dtb 12K arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb
it's completely unnecessary to store the *entire* devicetree on a per-CPU basis. and it would cause huge problems to do so.
instead i expect the "GPIO 0 devicetree" entry to be about... 200 bytes maximum. i expect the "GPIO 1 devicetree" entry to be about 200 bytes. i expect the "LCD specification devicetree" entry to be about 400 bytes. the total number of entries - even if there were 120 I2C devices hanging off the bus - should be well below 8K.
each of those entries _will_ need to be merged into the devicetree arch/arm/boot/dts/sun7i-eoma68-a28.dtb at runtime (by u-boot and by the running linux kernel). that can be dealt with.
l.