[opensuse-arm] ARM auto tests
Hi ARM guys! I think current openQA AArch64 tests are done using qemu (at least virtualization). 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. 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? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 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 ;). 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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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?
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? A HDMI frame grabber could be replaced with a serial link as a first step, maybe? Some USB work has been done by someone (Bernhard Wiedemann?) during hackweek (2015?), if I remember correctly. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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)?
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.
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? Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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/Document... 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Guillaume Gardet