On 2 August 2013 07:38, Peter Maydell peter.maydell@linaro.org wrote:
On 2 August 2013 00:26, Andy Green andy.green@linaro.org wrote:
On 2 August 2013 01:46, Jon Medhurst (Tixy) tixy@linaro.org wrote:
with vexpress we have the added complication thrown into the mix that people use it a lot with QEMU ;-)
...if there's something special needed for QEMU, maybe the fragments are the right answer.
My general aim is that the kernel that works on h/w should also work on the QEMU model. In general it does, though we rely a bit on various driver probe routines gracefully coping with the device not actually being present. "Somebody put
We have a similar situation with a (non-QEMU) simulator, but it's not possible to win on that since just probing an empty address will blow a bus fault. We have to take the approach to knock out the missing device instantiations in the dtsi.
something new into the kernel and exposed a missing bit of QEMU emulation support" is also a periodic event, but those are just bugs that need fixing.
The biggest roadblock I'm seeing at the moment actually is that there's a big class of problems (which generally boil down to "wrong kernel config" or sometimes "wrong QEMU command line arguments") which manifest as "kernel produces no output". 'common and easy user error' + 'zero diagnostics' = 'lots of annoying support email' :-)
Right, I can imagine.
x86 manages to do much better here because the "everything looks like a PC" effect means it's much easier for the kernel to produce output to serial or video very early. It's much easier to configure an ARM kernel so it doesn't look for the serial port in the right place or so it falls over before it gets round to actually being able to output to serial (and earlyprintk is very hit-and-miss especially in a multiplatform kernel). I'm not sure there's really a good solution to this problem, though :-(
The problem is the bootloader being "flexible" and meddling with the dtb chosen line to match its private state (bootargs in U-Boot env for example). I don't know how to stop U-Boot doing that, since if it even gets wind that you loaded a dtb image it's all over it meddling. But if you could stop it, preparing a golden "chosen" commandline in the dts and telling people to disable bootloader dtb meddling would be a nice debugging aid.
We use a stub bootloader instead that always uses the chosen already in the dts.
-Andy
-- PMM