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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
