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?
Cheers,
-- Jan
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.
Cheers,
-- Jan
Amicalement,
Hi there,
of course, we would use the most similar SoC/CPU currently available in QEMU. Most of the work will not be SoC specific, but EOMA specific (beginning with I2C communication and ending with kernel stuff, which, as Luke pointed out, must not be implementation-specific if possible).
This way it should be manageable in my opinion.
Cheers,
-- Jan
As much as I would love to help, I don't have the low-level Linux experience for it to be worth sending me any hardware. That said, I'd love to learn - if anyone knows, what hardware already out there is closest to what the A20 card will have? One of the A20 Cubieboards maybe?
On Wed, Feb 22, 2017 at 1:22 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
As much as I would love to help, I don't have the low-level Linux experience for it to be worth sending me any hardware. That said, I'd love to learn - if anyone knows, what hardware already out there is closest to what the A20 card will have? One of the A20 Cubieboards maybe?
the cubietruck's about the closest if you can get it - reason is: the price of 96FBGA DDR3x16 RAM ICs @ 8 gigabit are INSANE ($USD 10 **EACH**) and in the 2x DDR3x16 configuration you'd need *$20* worth of RAM with your $4 processor to get 2GBYTES.
so instead the cubietruck went with the 4x DDR3x8 78FGBA RAM ICs, which are a mere $3 each, and you get the 2GB of RAM that way, as 4x DDR3x8 4 gigabit ICs.
this is the configuration that i copied for the EOMA68-A20, by looking at the schematic and copying the addition of the (undocumentded) 15th address line. it was a hell of a risk ($2,000) but it worked: that's what the 2.4.1 announcement was about, back in december 2016.
anyway so yes: cubietruck is the closest you'll get to an EOMA68-A20, if you can get hold of them.
l.
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.
On Wed, Feb 22, 2017 at 10:46 AM, dumblob dumblob@gmail.com wrote:
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?
oo that's a great idea.
does u-boot start up in qemu-arm? it should do, shouldn't it...
ttps://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/
ha! yes it does! coool.
arm-netbook@lists.phcomp.co.uk
-
Albert ARIBAUD -
dumblob -
Jonathan Frederickson -
Luke Kenneth Casson Leighton