[fedora-arm] vexpress 3.8 update

[Mark Langsdorf]

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 at lists.fedoraproject.org [arm-bounces at lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson at gmail.com]
Sent: Thursday, February 28, 2013 1:16 AM
To: Jon Masters
Cc: arm at lists.fedoraproject.org
Subject: Re: [fedora-arm] vexpress 3.8 update

On Thu, Feb 28, 2013 at 6:23 AM, Jon Masters <jcm at 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 at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm