On 09/06/2016 11:54 AM, Guillaume Gardet wrote:
Le 06/09/2016 à 11:15, Alexander Graf a écrit :
On 09/06/2016 10:53 AM, Guillaume Gardet wrote:
Hi ARM guys!
I think current openQA AArch64 tests are done using qemu (at least
virtualization).
Correct, and even they keep failing :).
But, how far is ARM tests on real hardware? It seems os-autoinst
support real hardware and I remember that some people worked on it
during hackweeks.
Are you interested in embedded or server style hardware? For server
style hardware with proper BMC, I don't think there'd be much apart
from hardware availability keeping us from doing it. For embedded
style hardware, the biggest hurdle is that we need to test JeOS
images rather than the installation, because we need to provide
firmware as well.
I have only embedded style boards here, no BMC server. ;)
Indeed, the idea is to test JeOS images.
I would like to collect all information in order to maybe work on it
a bit. For example, which devices do you use to power on/off boards.
Did you use os-autoinst or some other tests tools?
One thing I've been working on is an SD card simulator using the BBB.
Unfortunately my EE skills are abysmal, so I get up to the point
where the SD host switches to 25Mhz mode and then the line collapses ;).
Can you send me details about what you did and what worked/failed,
please?
I wrote PRU programs that handle the SD traffic and route read/write
operations to Linux. It's all based on the new remoteproc stuff that TI
is working on (but hasn't upstreamed yet fwiw).
The main problem I think it the wiring. I currently have free floating
cables from the SD slot of a rpi3 to the pins of my BBB. Instead, I
probably just need to design a PCB to route things properly and invest a
few more weeks into making the PRU and Linux host code fully stable ;).
With a working SD card simulator, remote power / reset GPIO, an HDMI
frame grabber and USB OTG for keyboard/tablet simulation, we should
be able to create a generic OpenQA test bed for any embedded device
out there.
A remote power (or reset) should not be too difficult to buy or build.
Have you some working around?
I have remote power switches around and there is also always the CPU
reset line on the ARM JTAG interface that you can probably just wire up
using GPIOs on an ARM system.
A HDMI frame grabber could be replaced with a serial link as a first
step, maybe?
I have an HDMI USB3 frame grabber around as well ;). But yes, serial is
another option.
Some USB work has been done by someone (Bernhard Wiedemann?) during
hackweek (2015?), if I remember correctly.
Yes, it's pretty straight forward. All the components are in Linux already.
Alex
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
