Hi Folks,
I've done a bunch of tests against the qemu vexpress model (based upon a local backport rebuild of F18 qemu on F17 - can't be doing with the hit to upgrading to F18 on this laptop this week) with the 3.8 scratch kernel Peter built last Friday morning. The Fedora kernel as built doesn't boot because the emulated PL011 UART IP in the qemu model is generating a kernel backtrace. It's possible to get beyond that, at which point the emulated PL181 MMCI trigers another backtrace as the kernel can't determine the voltages supported by the emulated SD Card.
Additionally, I'll want to supply a vexpress-jcm.dtb that removes a bunch of devices that are not provided by qemu in the emulated machine so as to avoid stuff breaking in the future. Really, qemu ought to provide the dtb directly (and be builtin) but folks still haven't got the memo that Linux has no business owning the platform and we'll have to wait until we get to ACPI on v8 before that message starts going in. Until then, if we're providing a dtb, let's make sure it actually describes the hardware that is "present" in the qemu machine.
The bottom line is that vexpress qemu model isn't getting tested upstream. That testing that is happening is obviously on real hardware, not the qemu emulated machine. So we have a choice here. I can fix it (but I can't do everything, not enough time) or we can tell people not to upgrade to 3.8 on vexpress. Initial areas that will need work will be the PL011 driver (to avoid a divide by zero) and the MMCI. Can we prioritize and strategize around this soon, please?
Mark Langsdorf and I met in person yesterday and he has a link to the same kernel, which he will test on highbank today. I will assist. Once I get to Hong Kong, I can do some more poking next week but it's going to be another week until we have a 3.8 plan.
Jon.
On Thu, Feb 28, 2013 at 6:23 AM, Jon Masters jcm@redhat.com wrote:
Hi Folks,
I've done a bunch of tests against the qemu vexpress model (based upon a local backport rebuild of F18 qemu on F17 - can't be doing with the hit to upgrading to F18 on this laptop this week) with the 3.8 scratch kernel Peter built last Friday morning. The Fedora kernel as built doesn't boot because the emulated PL011 UART IP in the qemu model is generating a kernel backtrace. It's possible to get beyond that, at which point the emulated PL181 MMCI trigers another backtrace as the kernel can't determine the voltages supported by the emulated SD Card.
Additionally, I'll want to supply a vexpress-jcm.dtb that removes a bunch of devices that are not provided by qemu in the emulated machine so as to avoid stuff breaking in the future. Really, qemu ought to provide the dtb directly (and be builtin) but folks still haven't got the memo that Linux has no business owning the platform and we'll have to wait until we get to ACPI on v8 before that message starts going in. Until then, if we're providing a dtb, let's make sure it actually describes the hardware that is "present" in the qemu machine.
The bottom line is that vexpress qemu model isn't getting tested upstream. That testing that is happening is obviously on real hardware, not the qemu emulated machine. So we have a choice here. I can fix it (but I can't do everything, not enough time) or we can tell people not to upgrade to 3.8 on vexpress. Initial areas that will need work will be the PL011 driver (to avoid a divide by zero) and the MMCI. Can we prioritize and strategize around this soon, please?
Mark Langsdorf and I met in person yesterday and he has a link to the same kernel, which he will test on highbank today. I will assist. Once I get to Hong Kong, I can do some more poking next week but it's going to be another week until we have a 3.8 plan.
Speaking of Calxeda, don't they have a qemu model for their HW, is it upstream? If so can we just tell people to use that model for qemu or is it in a similar state of qemu disrepair?
Peter
The highbank model is upstream but I haven't used it in a while. The midway model is being used right now and is known to work, so I suspect the highbank model is mostly working. I can fix bugs that people report to me.
--Mark Langsdorf Calxeda, Inc. ________________________________________ From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson@gmail.com] Sent: Thursday, February 28, 2013 1:16 AM To: Jon Masters Cc: arm@lists.fedoraproject.org Subject: Re: [fedora-arm] vexpress 3.8 update
On Thu, Feb 28, 2013 at 6:23 AM, Jon Masters jcm@redhat.com wrote:
Hi Folks,
I've done a bunch of tests against the qemu vexpress model (based upon a local backport rebuild of F18 qemu on F17 - can't be doing with the hit to upgrading to F18 on this laptop this week) with the 3.8 scratch kernel Peter built last Friday morning. The Fedora kernel as built doesn't boot because the emulated PL011 UART IP in the qemu model is generating a kernel backtrace. It's possible to get beyond that, at which point the emulated PL181 MMCI trigers another backtrace as the kernel can't determine the voltages supported by the emulated SD Card.
Additionally, I'll want to supply a vexpress-jcm.dtb that removes a bunch of devices that are not provided by qemu in the emulated machine so as to avoid stuff breaking in the future. Really, qemu ought to provide the dtb directly (and be builtin) but folks still haven't got the memo that Linux has no business owning the platform and we'll have to wait until we get to ACPI on v8 before that message starts going in. Until then, if we're providing a dtb, let's make sure it actually describes the hardware that is "present" in the qemu machine.
The bottom line is that vexpress qemu model isn't getting tested upstream. That testing that is happening is obviously on real hardware, not the qemu emulated machine. So we have a choice here. I can fix it (but I can't do everything, not enough time) or we can tell people not to upgrade to 3.8 on vexpress. Initial areas that will need work will be the PL011 driver (to avoid a divide by zero) and the MMCI. Can we prioritize and strategize around this soon, please?
Mark Langsdorf and I met in person yesterday and he has a link to the same kernel, which he will test on highbank today. I will assist. Once I get to Hong Kong, I can do some more poking next week but it's going to be another week until we have a 3.8 plan.
Speaking of Calxeda, don't they have a qemu model for their HW, is it upstream? If so can we just tell people to use that model for qemu or is it in a similar state of qemu disrepair?
Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 02/28/2013 12:29 PM, Mark Langsdorf wrote:
The highbank model is upstream but I haven't used it in a while. The midway model is being used right now and is known to work, so I suspect the highbank model is mostly working. I can fix bugs that people report to me.
Like I said the other day, I think we might need to consider moving to an A15 model just because that's what people are playing with. Meanwhile, what's the consensus on A9 qemu as a priority?
Jon.
On Thu, Feb 28, 2013 at 6:05 PM, Jon Masters jcm@redhat.com wrote:
On 02/28/2013 12:29 PM, Mark Langsdorf wrote:
The highbank model is upstream but I haven't used it in a while. The midway model is being used right now and is known to work, so I suspect the highbank model is mostly working. I can fix bugs that people report to me.
Like I said the other day, I think we might need to consider moving to an A15 model just because that's what people are playing with. Meanwhile, what's the consensus on A9 qemu as a priority?
Like I've said previously A15 at a later point in time.
A9 qemu priority is low .... well below a working OMAP, tegra and highbank 3.8 kernel....
P
On 02/28/2013 12:03 PM, Peter Robinson wrote:
On Thu, Feb 28, 2013 at 6:05 PM, Jon Masters jcm@redhat.com wrote:
On 02/28/2013 12:29 PM, Mark Langsdorf wrote:
The highbank model is upstream but I haven't used it in a while. The midway model is being used right now and is known to work, so I suspect the highbank model is mostly working. I can fix bugs that people report to me.
Like I said the other day, I think we might need to consider moving to an A15 model just because that's what people are playing with. Meanwhile, what's the consensus on A9 qemu as a priority?
Like I've said previously A15 at a later point in time.
A9 qemu priority is low .... well below a working OMAP, tegra and highbank 3.8 kernel....
Since VExpress (QEMU) is a release blocker, and tegra is not, I would think it would be a higher priority, or we need to adjust our release criteria to match our new priorities.
d.marlin =========
P _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Good call. I think Highbank might be good for 3.8 on F18 (but we have other F19 issues) however I have asked Peter to specifically confirm with Mark, who can turn around a test faster than I can this week. I will poke OMAP and vexpress more from Linaro Connect. Just arrived in Hong Kong. Let me know if specific additional stuff comes up - I have a bunch of oopses and other issues already on the list.
-
d.marlin -
Jon Masters -
Mark Langsdorf -
Peter Robinson