On Wed, Feb 22, 2017 at 10:55 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi,
Le Wed, 22 Feb 2017 11:46:07 +0100 dumblob dumblob@gmail.com a écrit:
Hi Luke,
speaking of commitments, timeframes and the equipment price, it appears to me we could develop and provide a fully working QEMU image to break the current dependecy on EOMA HW (of course, in the end it will be tested on a real HW, but the global parallel development of anything regarding EOMA will be much easier and faster using QEMU).
Would it make sense to you?
I may be mistaken, but I suspect that would require allwinner SoC, and current qemu-system-arm does not support any AW SoC, so for every device used by the code we'd run under QEMU we would have to developed some emulation. Probably such a QEMU addition would be done and sufficiently stable way after the hardware is available.
a generic u-boot (arm) and generic arm linux kernel would be sufficient (one that supports at least a generic 16550 uart would do)
that would be enough to test the devicetree overlay code in a *generic* way (which it has to be anyway).
reading the EEPROM *has* to be a generic processor-independent action, because you can have literally any processor type (or not even a processor - even an FPGA) reading the I2C 0x51 addressed EEPROM.
l.