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

[Stephen Warren]

On 03/21/2012 11:50 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 03/21/2012 11:13 AM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>> On 03/21/2012 10:59 AM, Simon Glass wrote:
>>>>> 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.
>>>>
>>>> One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and
>>>> CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those
>>>> is appropriate for this, rather than inventing yet another config option?
>>>
>>> These will only exist when CONFIG_OF_CONTROL is not defined. It might
>>> confusing to use the same CONFIGs for the pre-console panic() case,
>>> knowing that they will in fact be ignored in a normal boot. I would
>>> suggest a new option, at least in the CONFIG_OF_CONTROL case where the
>>> two options you mention will not be used.
>>
>> Oh.
>>
>> But in u-boot-tegra/master, both Seaboard and Ventana still set those
>> options even though they have CONFIG_OF_CONTROL turned on. And it looks
>> like board_init_uart_f() both uses those defines irrespective of
>> CONFIG_OF_CONTROL /and/ is called solely based on
>> CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined
>> for Seaboard and Ventana.
> 
> Yes that's true. I have not yet prepared an upstream patch to fix
> this. I will get to this one we have USB/I2C in, but in the meantime,
> this series will probably nearly apply. The third patch is the main
> event.
> 
> https://gerrit.chromium.org/gerrit/#change,18256
> https://gerrit.chromium.org/gerrit/#change,18255
> https://gerrit.chromium.org/gerrit/#change,18257
> https://gerrit.chromium.org/gerrit/#change,18259
> 
>>
>> I thought the upshot of this discussion was that there wasn't any need
>> for any kind of pre-console stuff, either putc, puts/printf or whatever;
>> instead, the console should simply be registered as early as possible
>> based on the board/config's UART selection?
> 
> Not quite - going back to your previous message, if there is a panic
> before the console is ready (and in the event of there being no fdt) I
> would like to offer a message on a UART selected by a CONFIG.
> 
>>
>> (and of course the DT parsed after that console was registered; no need
>> for it before)
> 
> The DT must be parsed before the console is registered - after all the
> DT tells us which is the console.

Yes, we can't know what console the DT says to use until the DT is
located and parsed. That much is blatantly obvious.

But the last few messages in this thread have all been about the
following as far as I'm concerned:

* The U-Boot configuration defines which single UART to use for the
initial console.

* This initial console is registered early enough that almost all
failures can be reported. In particular, something as non-critical as
locating and parsing the DT should happen after this initial console is
registered, so that DT existence/parsing problems can be reported to
this initial console.

By non-critical here, I mean that there should be no reason to require
the DT to be parsed in order for the CPU to boot, and the initial
UART-based console to be registered. DT parsing shouldn't be attempted
until this basic level of operation is achieved; it should be be
required that the DT be parsed for any of that to work.

* When the DT is parsed later, the console specification from DT
replaces the initial console.

With this scheme in place, there surely isn't any need for any kind of
special-case early putc/puts/printf - wasn't this exactly Wolfgang's point?