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.
Show replies by date