On 2 August 2013 01:14, Andy Green <andy.gr...@linaro.org> wrote: > On 2 August 2013 07:38, Peter Maydell <peter.mayd...@linaro.org> wrote: >> 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.
That's generally not the problem in my experience (and the kernel's 'chosen' nodes in its device trees don't have any contents anyway, so that would definitely result in a failure-to-boot). Random recent examples: * user passed us a versatilepb kernel but we're emulating vexpress * user passed us 'earlyprintk' but the kernel's selected earlyprintk isn't the right one for the board we're running * user forgot to tell QEMU to emulate enough memory so the kernel stops before it's initialised the serial output * kernel has CONFIG_DEBUG_SEMIHOSTING and user passes 'earlyprintk' on kernel command line but QEMU not run with -semihosting argument * kernel configured to use the "guess which vexpress board this is based on the exact revision-and-patchlevel-of-the-CPU" earlyprintk, and guesses wrongly about where the serial port is because QEMU's CPU isn't the exact revision a h/w TC1 has Actually what would fix this would be if the bootloader had a simple way to say "here is where you will find a serial port" [eg physaddr for output plus physaddr for status register and mask to indicate how to wait for the port to be ready to tx]. Then the kernel would have a reliable way of getting output to the user right from the offset that didn't rely on the kernel being correctly configured, the device tree being the right one for the kernel, etc. And it could just enable earlyprintk by default in that situation. -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
