On 03/21/2012 04:35 AM, Graeme Russ wrote: > Hi Stephen, Wolfgang, > > On 03/21/2012 08:38 PM, Wolfgang Denk wrote: >> Dear Simon Glass, >> >> In message >> <CAPnjgZ0jYpHSNG354=f4mdvj0tt5-6jdcxpeg1y70v5dwby...@mail.gmail.com> you >> wrote: > >> We have standard ways of telling the Linux kernel what the console >> port is - the "console=" boot argument has been working fine for many, >> many years and many, many boards and systems. But Tegra needs to >> invent it's own hackinsh implementation of putting special data in >> some special registers. What a crap. > > This made me look into the x86 code - There is a command line option > 'earlyprintk' which is available stupidly early (even the real-mode code > and de-compressor have access to it) > > So I do now wonder why Tegra needs to do anything differently
I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument. I doubt it will be possible to do this in the ARM zImage decompressor though. Perhaps the kernel should follow these rules: If the kernel .config specifies a UART to output the early messages to, then we use that by default (both for the zImage decompressor and earlyprintk if enabled). This option can already include "none" which would be safe across arbitary boards as a default. The zImage decompressor will always use that UART. If there are issues in the decompressor, rebuild the kernel for the specific UART for the board being tested to see the error spew. The kernel proper will parse any earlyprintk argument, and override the UART specified in .config if an earlyprintk argument is present. This makes debugging zImage decmopressor issues slightly more annoying, but (a) we'll probably have to do something like this for multi-SoC kernel images anyway, and (b) zImage decompressor issues are quite rate. I suppose we could apply the same approach to U-Boot too: Have the U-Boot configuration specify a UART to use for the console, which would have to be "none" by default for maximum safety in a multi-board U-Boot (build) config, but could be the single correct one for a single-board U-Boot config. Then, replace this console with the one from DT once DT is parsed. This would again make debugging a multi-board U-Boot config's boot hang more annoying, since you'd have to rebuild in order to set a specific "early" UART for the console, but at least it'd be possible. Then, we just have to make sure that this "early" console is always available before any panic due to missing DT, so that problem would at least be discoverable after setting the UART to use. Hopefully this "early" console would be registered early enough that there are very very few things that can fail before it... Tom/Simon: Does the U-Boot side of this sound acceptable to you? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
