On 2 August 2013 07:38, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 2 August 2013 00:26, Andy Green <andy.gr...@linaro.org> wrote: >> On 2 August 2013 01:46, Jon Medhurst (Tixy) <t...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
