[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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-6jDCxpEG1Y70v5dwbYxkQ at 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?