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

[Simon Glass]

Hi Stephen,

On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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?

1. I think we have agreed that we cannot and will not (at least for
now) solve the problem of trying to get a message to the user during a
panic() when we don't even know the console UART.

2. Given (1), it seems reasonable to allow the board config to select
an 'early console UART' (which may be NONE) for use for very early
panics in U-Boot. If this is not set, or set incorrectly, then no
output will be visible.

3. What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or
CONFIG_PRE_CONSOLE_UART to be defined, and used in the
board_pre_console_putc() code.

So yes, I think it is acceptable.

[[[ If I may comment on the Linux side, I think it is worth at least
checking whether it is possible to find the UART in the zImage
decompressor using the earlyprintk=... setting. It would solve the
problem of this patch at least. Even if we need to just look at the
number at the end of the setting and use that UART number :-( ]]]

Regards,
Simon