On 06/09/2016 14:15, Guillaume Gardet wrote:
Le 06/09/2016 à 12:54, Alexander Graf a écrit :
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 ;).
Interesting. Do you have some code available (github or something)?
I find it terribly hard to integrate git and eclipse workflows. But I've
uploaded the current source state here:
http://csgraf.de/tmp2/pru-20161121.txz
You also need a patch on top of the TI WIP Linux tree that enables
remoteproc:
https://github.com/agraf/linux-2.6.git rproc-linux-4.4.y-plus-sdemu
Neither of them are anywhere close to pretty.
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.
Remote power switches are hand made or from reseller? If you have any
good item, please share the name.
The ones I'm using at home are from this company:
http://www.anel-elektronik.de/
But I'm sure you can find others :).
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.
Is there any repo where we can get code or build step, configs, or
something?
I've CC'ed Bernhard. IIRC it's really as simple as following the in-tree
documentation:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/usb/gadget_hid.txt
Alex
(Sorry for the late reply. I thought I would be able to get the code
prettier. I gave up on that now, so you just get the state that I had
back then anyway)
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
