[opensuse-arm] openQA: ARM
Hi, What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod. So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) ) Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console. At the moment I have no idea how many efforts are needed to implement this. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.09.14 10:00, Guillaume Gardet wrote:
Hi,
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. I think the easiest target machine to get working with our setup is the BeagleBoard emulation, as it runs the whole stack including u-boot. Unfortunately, that one is downstream in the Linaro qemu fork [1]. I tried to get it working for that exact use case a while ago and needed the patch below on top of ac0bfdb9c. Good luck :) Alex [1] git://git.linaro.org/qemu/qemu-linaro.git diff --git a/hw/misc/omap3_boot.c b/hw/misc/omap3_boot.c index 9e78cc3..3df9ca1 100644 --- a/hw/misc/omap3_boot.c +++ b/hw/misc/omap3_boot.c @@ -684,8 +684,7 @@ static int omap3_mmc_raw_boot(BlockDriverState *bs, } } - result = (boot->state == done); - free(boot); + result = omap3_boot_finish(boot); } return result; } diff --git a/hw/misc/twl4030.c b/hw/misc/twl4030.c index 56d91cb..56a38f9 100644 --- a/hw/misc/twl4030.c +++ b/hw/misc/twl4030.c @@ -58,7 +58,7 @@ typedef void (*twl4030_write_func)(TWL4030NodeState *s, #define TYPE_TWL4030NODE "twl4030-node" #define TWL4030NODE(obj) OBJECT_CHECK(TWL4030NodeState, (obj), TYPE_TWL4030NODE) -typedef struct TWL4030NodeState { +struct TWL4030NodeState { I2CSlave parent_obj; int firstbyte; uint8_t reg; @@ -68,7 +68,7 @@ typedef struct TWL4030NodeState { TWL4030State *twl4030; uint8 reg_data[256]; -} TWL4030NodeState; +}; struct TWL4030State { qemu_irq irq1; -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 08.09.2014 um 12:46 schrieb Alexander Graf:
On 08.09.14 10:00, Guillaume Gardet wrote:
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. [...]
Yes, I had brought this up at an openQA presentation months ago, but it was never followed up upon. Let's CC Bernhard: What needs to be done to add "qemu-system-arm -machine something" based tests to openQA so that people can add and edit Needles? As I understood Alex, the biggest hurdle inside QEMU is that not every machine (well, hardly any apparently) is able to boot the real U-Boot, whether via -bios directly or via -drive/-pflash from JeOS disk image. For instance, vexpress-a9, vexpress-a15, highbank, midway, xilinx-zynq-a9 and cubieboard are among the -machine options that we might test using -kernel directly, if openQA allows that. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-09-11 um 15:20 schrieb Andreas Färber:
Am 08.09.2014 um 12:46 schrieb Alexander Graf:
On 08.09.14 10:00, Guillaume Gardet wrote:
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. [...]
Yes, I had brought this up at an openQA presentation months ago, but it was never followed up upon. Let's CC Bernhard: What needs to be done to add "qemu-system-arm -machine something" based tests to openQA so that people can add and edit Needles?
As I understood Alex, the biggest hurdle inside QEMU is that not every machine (well, hardly any apparently) is able to boot the real U-Boot, whether via -bios directly or via -drive/-pflash from JeOS disk image. For instance, vexpress-a9, vexpress-a15, highbank, midway, xilinx-zynq-a9 and cubieboard are among the -machine options that we might test using -kernel directly, if openQA allows that.
if you want to test it with qemu and openQA, you would need a working emulated graphics driver, because that is what openQA is expecting to work with (apart from keyboard input, block-storage and network). You can test that with qemu -monitor stdio ... and then issue a screendump /tmp/foo.ppm IIRC the current openQA v3 version can also use VNC to talk to qemu. The other particularity would be that we don't have an installer on arm, but in openQA are already NOINSTALL and KEEPHDDS variables to test booting from pre-existing harddisk images. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlQRp48ACgkQSTYLOx37oWR9ZACglBGvngXMJurAuFcKVa4qUorX oA0An35P9kp3y/nEgkORlHa+EEIWN3gw =3IpA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2014-09-11 17:45 GMT+04:00 Bernhard M. Wiedemann <bwiedemann@suse.de>:
if you want to test it with qemu and openQA, you would need a working emulated graphics driver, because that is what openQA is expecting to work with (apart from keyboard input, block-storage and network). You can test that with qemu -monitor stdio ... and then issue a screendump /tmp/foo.ppm IIRC the current openQA v3 version can also use VNC to talk to qemu.
Why openQA don't like serial console? It is simpler to parse and use. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2014-09-08 14:46 GMT+04:00 Alexander Graf <agraf@suse.de>:
the patch below on top of ac0bfdb9c.
Could you please send the patch to linaro? The patch works just perfect for beagleboard. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, On 8 September 2014 at 11:46, Alexander Graf <agraf@suse.de> wrote:
On 08.09.14 10:00, Guillaume Gardet wrote:
Hi,
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. I think the easiest target machine to get working with our setup is the BeagleBoard emulation, as it runs the whole stack including u-boot.
Unfortunately, that one is downstream in the Linaro qemu fork [1]. I tried to get it working for that exact use case a while ago and needed the patch below on top of ac0bfdb9c.
Good luck :)
Alex
[1] git://git.linaro.org/qemu/qemu-linaro.git
diff --git a/hw/misc/omap3_boot.c b/hw/misc/omap3_boot.c index 9e78cc3..3df9ca1 100644 --- a/hw/misc/omap3_boot.c +++ b/hw/misc/omap3_boot.c @@ -684,8 +684,7 @@ static int omap3_mmc_raw_boot(BlockDriverState *bs, } }
- result = (boot->state == done); - free(boot); + result = omap3_boot_finish(boot); } return result; } diff --git a/hw/misc/twl4030.c b/hw/misc/twl4030.c index 56d91cb..56a38f9 100644 --- a/hw/misc/twl4030.c +++ b/hw/misc/twl4030.c @@ -58,7 +58,7 @@ typedef void (*twl4030_write_func)(TWL4030NodeState *s, #define TYPE_TWL4030NODE "twl4030-node" #define TWL4030NODE(obj) OBJECT_CHECK(TWL4030NodeState, (obj), TYPE_TWL4030NODE)
-typedef struct TWL4030NodeState { +struct TWL4030NodeState { I2CSlave parent_obj; int firstbyte; uint8_t reg; @@ -68,7 +68,7 @@ typedef struct TWL4030NodeState { TWL4030State *twl4030;
uint8 reg_data[256]; -} TWL4030NodeState; +};
struct TWL4030State { qemu_irq irq1; -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not. Many thanks, Andy -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.01.15 16:06, Andrew Wafaa wrote:
Hi,
On 8 September 2014 at 11:46, Alexander Graf <agraf@suse.de> wrote:
On 08.09.14 10:00, Guillaume Gardet wrote:
Hi,
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. I think the easiest target machine to get working with our setup is the BeagleBoard emulation, as it runs the whole stack including u-boot.
Unfortunately, that one is downstream in the Linaro qemu fork [1]. I tried to get it working for that exact use case a while ago and needed the patch below on top of ac0bfdb9c.
Good luck :)
Alex
[1] git://git.linaro.org/qemu/qemu-linaro.git
diff --git a/hw/misc/omap3_boot.c b/hw/misc/omap3_boot.c index 9e78cc3..3df9ca1 100644 --- a/hw/misc/omap3_boot.c +++ b/hw/misc/omap3_boot.c @@ -684,8 +684,7 @@ static int omap3_mmc_raw_boot(BlockDriverState *bs, } }
- result = (boot->state == done); - free(boot); + result = omap3_boot_finish(boot); } return result; } diff --git a/hw/misc/twl4030.c b/hw/misc/twl4030.c index 56d91cb..56a38f9 100644 --- a/hw/misc/twl4030.c +++ b/hw/misc/twl4030.c @@ -58,7 +58,7 @@ typedef void (*twl4030_write_func)(TWL4030NodeState *s, #define TYPE_TWL4030NODE "twl4030-node" #define TWL4030NODE(obj) OBJECT_CHECK(TWL4030NodeState, (obj), TYPE_TWL4030NODE)
-typedef struct TWL4030NodeState { +struct TWL4030NodeState { I2CSlave parent_obj; int firstbyte; uint8_t reg; @@ -68,7 +68,7 @@ typedef struct TWL4030NodeState { TWL4030State *twl4030;
uint8 reg_data[256]; -} TWL4030NodeState; +};
struct TWL4030State { qemu_irq irq1; -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
I'm not sure you really want to base on the Beagle emulation for OpenQA. The "virt" machine in QEMU would make a much nicer target, especially since it also supports KVM properly. The only missing link to get everything properly running is a working virtual PCI host bridge so that we can use PCI VGA adapters and USB for keyboard/mouse. Writing such an emulation is on my todo list, but I'd be more than happy if someone else beats me to it ;). However, as for your original question: Peter, did I ever send you the patch above? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 5 January 2015 at 15:31, Alexander Graf <agraf@suse.de> wrote:
I'm not sure you really want to base on the Beagle emulation for OpenQA. The "virt" machine in QEMU would make a much nicer target, especially since it also supports KVM properly. The only missing link to get everything properly running is a working virtual PCI host bridge so that we can use PCI VGA adapters and USB for keyboard/mouse.
Writing such an emulation is on my todo list, but I'd be more than happy if someone else beats me to it ;).
However, as for your original question:
Peter, did I ever send you the patch above?
It doesn't look familiar, but then I haven't touched the omap3 code in a year or more. (I haven't quite decided whether to let it continue to bitrot into irrelevance or to try to get some subset of it upstream. The problem is that it would probably be three months' work, and the beagle board isn't very interesting any more these days.) thanks -- PMM -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.01.15 16:39, Peter Maydell wrote:
On 5 January 2015 at 15:31, Alexander Graf <agraf@suse.de> wrote:
I'm not sure you really want to base on the Beagle emulation for OpenQA. The "virt" machine in QEMU would make a much nicer target, especially since it also supports KVM properly. The only missing link to get everything properly running is a working virtual PCI host bridge so that we can use PCI VGA adapters and USB for keyboard/mouse.
Writing such an emulation is on my todo list, but I'd be more than happy if someone else beats me to it ;).
However, as for your original question:
Peter, did I ever send you the patch above?
It doesn't look familiar, but then I haven't touched the omap3 code in a year or more. (I haven't quite decided whether to let it continue to bitrot into irrelevance or to try to get some subset of it upstream. The problem is that it would probably be three months' work, and the beagle board isn't very interesting any more these days.)
Would you mind to at least apply the patch in that email to your tree so that it doesn't bitrot into unusability? :) On the PCI front, I assume nobody started with it yet, right? Thanks! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 5 January 2015 at 16:01, Alexander Graf <agraf@suse.de> wrote:
Would you mind to at least apply the patch in that email to your tree so that it doesn't bitrot into unusability? :)
What's the TWL4030 part of the patch for? It looks (a) unrelated and (b) unneeded ?
On the PCI front, I assume nobody started with it yet, right?
Rob Herring sent the original patch set, Alvise from OVS sent a different series based on that in November. I'm currently looking at what the differences are (mostly I prefer the way Rob approached it but I need to see if there are any changes from Alvise's set that need to be extracted form it.) -- PMM -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.01.15 17:32, Peter Maydell wrote:
On 5 January 2015 at 16:01, Alexander Graf <agraf@suse.de> wrote:
Would you mind to at least apply the patch in that email to your tree so that it doesn't bitrot into unusability? :)
What's the TWL4030 part of the patch for? It looks (a) unrelated and (b) unneeded ?
Last time I tried to compile the tree, it simply failed to compile without that hunk.
On the PCI front, I assume nobody started with it yet, right?
Rob Herring sent the original patch set, Alvise from OVS sent a different series based on that in November. I'm currently looking at what the differences are (mostly I prefer the way Rob approached it but I need to see if there are any changes from Alvise's set that need to be extracted form it.)
Phew, I'm not incredibly happy with that code either. It doesn't implement PCIe and seems to happily violate layerings, such as mixing dt and device code. Either way, I've replied to the last patch submission and will keep working on my own PCIe implementation in parallel. Let's see what gets done first ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 5 January 2015 at 17:53, Alexander Graf <agraf@suse.de> wrote:
On 05.01.15 17:32, Peter Maydell wrote:
On 5 January 2015 at 16:01, Alexander Graf <agraf@suse.de> wrote:
Would you mind to at least apply the patch in that email to your tree so that it doesn't bitrot into unusability? :)
What's the TWL4030 part of the patch for? It looks (a) unrelated and (b) unneeded ?
Last time I tried to compile the tree, it simply failed to compile without that hunk.
Builds fine for me, but this is the "some compiler or other doesn't like multiple identical typedefs" issue I think. Anyway, I've folded both fixes into the appropriate patches in the qemu-linaro tree and pushed them out to the git server. -- PMM -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 5 January 2015 at 15:31, Alexander Graf <agraf@suse.de> wrote:
On 05.01.15 16:06, Andrew Wafaa wrote:
Hi,
On 8 September 2014 at 11:46, Alexander Graf <agraf@suse.de> wrote:
On 08.09.14 10:00, Guillaume Gardet wrote:
Hi,
Le 08/09/2014 09:07, Matwey V. Kornilov a écrit :
Hi,
What do you think about adding couple of test cases for ARM to our openQA? I remember two cases when our JeOSes were broken independently of hardware. First one, when u-boot was looking for boot.scr in wrong place, second one, when the kernel 3.14 was broken due to bug in depmod.
So, I think that we could test JeOS-vexpress and JeOS-vexpress64 for armv7 and aarch64 using qemu emulation (I know that it is slow ;) )
Then just check that the image is booted for the first time, and for the second time, controlling the process through serial console.
At the moment I have no idea how many efforts are needed to implement this.
Sounds good to me but I have zero knowledge on openQA.
Yup. Definitely a really good idea. I think the easiest target machine to get working with our setup is the BeagleBoard emulation, as it runs the whole stack including u-boot.
Unfortunately, that one is downstream in the Linaro qemu fork [1]. I tried to get it working for that exact use case a while ago and needed the patch below on top of ac0bfdb9c.
Good luck :)
Alex
[1] git://git.linaro.org/qemu/qemu-linaro.git
diff --git a/hw/misc/omap3_boot.c b/hw/misc/omap3_boot.c index 9e78cc3..3df9ca1 100644 --- a/hw/misc/omap3_boot.c +++ b/hw/misc/omap3_boot.c @@ -684,8 +684,7 @@ static int omap3_mmc_raw_boot(BlockDriverState *bs, } }
- result = (boot->state == done); - free(boot); + result = omap3_boot_finish(boot); } return result; } diff --git a/hw/misc/twl4030.c b/hw/misc/twl4030.c index 56d91cb..56a38f9 100644 --- a/hw/misc/twl4030.c +++ b/hw/misc/twl4030.c @@ -58,7 +58,7 @@ typedef void (*twl4030_write_func)(TWL4030NodeState *s, #define TYPE_TWL4030NODE "twl4030-node" #define TWL4030NODE(obj) OBJECT_CHECK(TWL4030NodeState, (obj), TYPE_TWL4030NODE)
-typedef struct TWL4030NodeState { +struct TWL4030NodeState { I2CSlave parent_obj; int firstbyte; uint8_t reg; @@ -68,7 +68,7 @@ typedef struct TWL4030NodeState { TWL4030State *twl4030;
uint8 reg_data[256]; -} TWL4030NodeState; +};
struct TWL4030State { qemu_irq irq1; -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
I'm not sure you really want to base on the Beagle emulation for OpenQA. The "virt" machine in QEMU would make a much nicer target, especially since it also supports KVM properly. The only missing link to get everything properly running is a working virtual PCI host bridge so that we can use PCI VGA adapters and USB for keyboard/mouse.
OK that works for me, I'm not fussed about what the platform is. All I'm after is getting functional OpenQA tests for ARM. So if that means using a generic platform then great.
Writing such an emulation is on my todo list, but I'd be more than happy if someone else beats me to it ;).
One of the many things I on that growing list I guess? Thanks for the info and I'll see what can happen.
However, as for your original question:
Peter, did I ever send you the patch above?
Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Andrew,
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM. Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Dirk, On 5 January 2015 at 15:32, Dirk Müller <dirk@dmllr.de> wrote:
Hi Andrew,
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM.
Ideally I'd like to have both architectures supported, but I'll settle for just one (at least initially).
Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that.
OK I'll speak to the OpenQA guys and see what can be done. Thanks!
Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 05.01.2015 um 16:54 schrieb Andrew Wafaa:
On 5 January 2015 at 15:32, Dirk Müller <dirk@dmllr.de> wrote:
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM.
Ideally I'd like to have both architectures supported, but I'll settle for just one (at least initially).
Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that.
OK I'll speak to the OpenQA guys and see what can be done.
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.01.15 11:23, Ludwig Nussel wrote:
Am 05.01.2015 um 16:54 schrieb Andrew Wafaa:
On 5 January 2015 at 15:32, Dirk Müller <dirk@dmllr.de> wrote:
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM.
Ideally I'd like to have both architectures supported, but I'll settle for just one (at least initially).
Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that.
OK I'll speak to the OpenQA guys and see what can be done.
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
So I've managed to at least get a penguin up with the virtual PCIe PHB: https://github.com/agraf/qemu/commits/arm-phb However, there is currently no upstream support for the generic PCIe PHB in Linux on AArch64 - it only compiles on 32bit ARM. I've successfully forward-ported a patch from LKML to enable it, but this needs more testing to actually make sure it works correctly. For 32bit ARM we don't have installation images or EFI, so OpenQA will be harder to do. I'd say give me a few days to sort everything out. By then we might have something that's actually testable and has PCI on AArch64 and should make everyone happy. But for now I'm off for bank holiday :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 6 January 2015 at 11:23, Alexander Graf <agraf@suse.de> wrote:
On 06.01.15 11:23, Ludwig Nussel wrote:
Am 05.01.2015 um 16:54 schrieb Andrew Wafaa:
On 5 January 2015 at 15:32, Dirk Müller <dirk@dmllr.de> wrote:
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM.
Ideally I'd like to have both architectures supported, but I'll settle for just one (at least initially).
Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that.
OK I'll speak to the OpenQA guys and see what can be done.
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
So I've managed to at least get a penguin up with the virtual PCIe PHB:
https://github.com/agraf/qemu/commits/arm-phb
However, there is currently no upstream support for the generic PCIe PHB in Linux on AArch64 - it only compiles on 32bit ARM. I've successfully forward-ported a patch from LKML to enable it, but this needs more testing to actually make sure it works correctly.
Excellent news!! I'm fairly certain there are many of us who can at least test for you.
For 32bit ARM we don't have installation images or EFI, so OpenQA will be harder to do.
Not sure how feasible it would be, but could you nest a 32bit guest?
I'd say give me a few days to sort everything out. By then we might have something that's actually testable and has PCI on AArch64 and should make everyone happy.
I'll be waiting :)
But for now I'm off for bank holiday :)
Enjoy!
Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.01.15 12:47, Andrew Wafaa wrote:
On 6 January 2015 at 11:23, Alexander Graf <agraf@suse.de> wrote:
On 06.01.15 11:23, Ludwig Nussel wrote:
Am 05.01.2015 um 16:54 schrieb Andrew Wafaa:
On 5 January 2015 at 15:32, Dirk Müller <dirk@dmllr.de> wrote:
Does anyone know if this patch is still required, and what else needs to be done to get OpenQA to work? I'm being shamed by our illustrious Chairman with regards to OpenQA and as a matter of pride I'd like to get OpenQA working with ARM - also Linaro are discussing whether to use OpenQA or not.
is that regarding AArch64 or 32bit ARM? Regarding 32 bit ARM, the patches are still required, also we're still lacking support for graphics (see Bernhards reply). Also, we don't have an install media for 32bit ARM.
Ideally I'd like to have both architectures supported, but I'll settle for just one (at least initially).
Those are all not an issue for AArch64, and there it is next to trivial to add OpenQA support. I'd love to work on this myself but it would probably be quicker to get someone from the openqa team to implement the couple of missing lines of code for that.
OK I'll speak to the OpenQA guys and see what can be done.
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
So I've managed to at least get a penguin up with the virtual PCIe PHB:
https://github.com/agraf/qemu/commits/arm-phb
However, there is currently no upstream support for the generic PCIe PHB in Linux on AArch64 - it only compiles on 32bit ARM. I've successfully forward-ported a patch from LKML to enable it, but this needs more testing to actually make sure it works correctly.
Excellent news!! I'm fairly certain there are many of us who can at least test for you.
Awesome. The 32bit kernel should work "as is". For 64bit you'd need to use the patched master kernel (3.19-rc2 + my pci patch, master branch in the openSUSE kernel git). In a while, it should get automatically pushed to https://build.opensuse.org/package/show/Kernel:HEAD/kernel-default at which point you should be able to grab a compiled version from OBS. So far I was able to confirm that VGA and XHCI both work just fine, so I don't see any big problems with bringing up OpenQA. Does OpenQA need to see the grub menu? TianoCore doesn't have support for PCI (and thus VGA) yet, so the first thing you'll see on the screen is Linux.
For 32bit ARM we don't have installation images or EFI, so OpenQA will be harder to do.
Not sure how feasible it would be, but could you nest a 32bit guest?
What do you mean by "nest"? In OpenQA, you want to test the installation process, no? If we don't have an installation process there's nothing to test :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 06.01.2015 um 16:24 schrieb Alexander Graf:
Does OpenQA need to see the grub menu? TianoCore doesn't have support for PCI (and thus VGA) yet, so the first thing you'll see on the screen is Linux.
openQA doesn't need to see grub. What it expects depends on how you write the test cases. It makes sense to check for grub to make sure the branding is correct and the menu entries work if there are multiple choices.
For 32bit ARM we don't have installation images or EFI, so OpenQA will be harder to do.
Not sure how feasible it would be, but could you nest a 32bit guest?
What do you mean by "nest"? In OpenQA, you want to test the installation process, no? If we don't have an installation process there's nothing to test :).
Even without installation it still makes senses to test whether a hard disk image boots into the desktop correctly and to check some apps look and behave as expected. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 06.01.2015 um 11:23 schrieb Ludwig Nussel:
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
Ok, with some hints from Dirk and home:algraf:ARM-PCI/qemu I got openQA to boot an aarch64 iso on my workstation. There are still some issues that need to be resolved: - _product:openSUSE-cd-mini-aarch64 lacks installation-images and therefore can't boot - adding installation-images-openSUSE and building the iso manually makes the bootloader apear on ttyS0 \o/. The image has no kernel though. Maybe a kiwi problem? - we need home:algraf:ARM-PCI/qemu in Factory :-) - qemu doesn't like the '-usb' option anymore: qemu-system-aarch64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. - we need a package for QEMU_EFI.fd WIP code: https://github.com/lnussel/os-autoinst/commits/aarch64 https://github.com/lnussel/openQA/commits/master cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 22.01.2015 um 06:08 schrieb Ludwig Nussel:
Am 06.01.2015 um 11:23 schrieb Ludwig Nussel:
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
Ok, with some hints from Dirk and home:algraf:ARM-PCI/qemu I got openQA to boot an aarch64 iso on my workstation. There are still some issues that need to be resolved:
- _product:openSUSE-cd-mini-aarch64 lacks installation-images and therefore can't boot - adding installation-images-openSUSE and building the iso manually makes the bootloader apear on ttyS0 \o/. The image has no kernel though. Maybe a kiwi problem?
Small correction I forgot about. QEMU_EFI.fd doesn't seem to be able to read iso9960. The bootloader is actually the firmware built in one, not the one on the iso image. The EFI shell doesn't list the cd medium. I had to mount the iso image and use the fat:/mnt method to see grub. I guess the iso needs to be made a hybrid image that pretends to contain an EFI boot partition with FAT. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel <ludwig.nussel@suse.de> writes:
- _product:openSUSE-cd-mini-aarch64 lacks installation-images and therefore can't boot - adding installation-images-openSUSE and building the iso manually makes the bootloader apear on ttyS0 \o/. The image has no kernel though. Maybe a kiwi problem?
SR#282364 Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 22.01.2015 um 06:08 schrieb Ludwig Nussel <ludwig.nussel@suse.de>:
Am 06.01.2015 um 11:23 schrieb Ludwig Nussel: openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
Ok, with some hints from Dirk and home:algraf:ARM-PCI/qemu I got openQA to boot an aarch64 iso on my workstation. There are still some issues that need to be resolved:
- _product:openSUSE-cd-mini-aarch64 lacks installation-images and therefore can't boot - adding installation-images-openSUSE and building the iso manually makes the bootloader apear on ttyS0 \o/. The image has no kernel though. Maybe a kiwi problem? - we need home:algraf:ARM-PCI/qemu in Factory :-)
I just submitted v2 to the ML. Once it's accepted upstream I'll add it to our Factory version ;).
- qemu doesn't like the '-usb' option anymore:
-usb is a convenience option that is not implemented for all boards ;). Just use -device xhci and the respective -device option substitutes for -usbdevice. That code should be fully cross architecture then.
qemu-system-aarch64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. - we need a package for QEMU_EFI.fd
Ah, yes. We have one for x86 OVMF already, I suppose it's a matter of enabling the aarch64 (and armv7) qemu targets in the spec file. Hopefully we won't have to update the source file too ;).
WIP code: https://github.com/lnussel/os-autoinst/commits/aarch64 https://github.com/lnussel/openQA/commits/master
Awesome! You're the best ;) Alex
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel schrieb:
Am 06.01.2015 um 11:23 schrieb Ludwig Nussel:
openQA basically needs an iso or hard disk image and a qemu that can boot the image into some GUI. With those two things and an ARM machine with Factory or 13.2 it shouldn't take long to get openQA up.
Ok, with some hints from Dirk and home:algraf:ARM-PCI/qemu I got openQA to boot an aarch64 iso on my workstation. There are still some issues that need to be resolved:
Just a quick update. With the qemu from linaro¹ and the firmware from Laszlo Ersek² I was able to get a graphical grub2 from the installation medium. Just some fixes to installation-images needed: https://github.com/openSUSE/installation-images/pull/45. To make the net iso work also a kiwi fix is needed: https://github.com/openSUSE/kiwi/pull/441 With those bits in place the Factory installation cd proceeds until YaST which still starts in text mode on the serial tty instead of the graphics card. [1] git://git.linaro.org/people/pmaydell/qemu-arm.git, https://build.opensuse.org/package/show/home:lnussel:ARM-PCI/qemu [2] https://github.com/lersek/edk2/commits/armvirt_pci_v1, https://build.opensuse.org/package/show/home:lnussel:ARM-PCI/ovmf -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel schrieb:
With those bits in place the Factory installation cd proceeds until YaST which still starts in text mode on the serial tty instead of the graphics card.
Looks like the built in default console of the kernel is ttyAMA0 instead of the frame buffer. Is that intentional? It's not a problem for openQA actually as it passes console=ttyAMA0 console=tty manually. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel <ludwig.nussel@suse.de> writes:
Looks like the built in default console of the kernel is ttyAMA0 instead of the frame buffer.
That's true for all arm configs. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Andreas Schwab schrieb:
Ludwig Nussel <ludwig.nussel@suse.de> writes:
Looks like the built in default console of the kernel is ttyAMA0 instead of the frame buffer.
That's true for all arm configs.
I guess it make sense to have ttyAMA0 always available as console but why make it the default if there is a frame buffer? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
24.02.2015 14:00, Ludwig Nussel пишет:
I guess it make sense to have ttyAMA0 always available as console but why make it the default if there is a frame buffer?
It doesn't work on every other board. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (10)
-
Alexander Graf -
Andreas Färber -
Andreas Schwab -
Andrew Wafaa -
Bernhard M. Wiedemann -
Dirk Müller -
Guillaume Gardet -
Ludwig Nussel -
Matwey V. Kornilov -
Peter Maydell