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@xxxxxxxxxxxxxxxxxxxxxxx [arm-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Peter Robinson [pbrobinson@xxxxxxxxx] Sent: Thursday, February 28, 2013 1:16 AM To: Jon Masters Cc: arm@xxxxxxxxxxxxxxxxxxxxxxx Subject: Re: vexpress 3.8 update On Thu, Feb 28, 2013 at 6:23 AM, Jon Masters <jcm@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
