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

[Graeme Russ]

Hi Stehpen,

On Wed, Mar 21, 2012 at 12:18 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Graeme,
>
> On Tue, Mar 20, 2012 at 5:39 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Simon
>>
>> On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Graeme,
>>>
>>> On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>>> Hi Simon,
>>
>>>> And we are talking about one board vendor taking a SoC and using UARTA
>>>> for the panic output and another board vendor deciding to use UARTB - But
>>>> surely these vendors will create a separate config file for their boards.
>>>
>>> Nope. There is only one u-boot.bin for all boards that use this SOC.
>>
>> And this is what I simply don't grok - Why have a single board config for
>> a range of boards that are obviously different?
>
> That's the design goal - a single U-Boot binary for all boards that
> use a particular SOC.
>
>>
>> I suppose I haven't dealt with device tree and I imagine that is what this
>> is all about. But to me, device trees are a construct for a higher level
>> of operation (the OS) not the boot loader (although I get that the boot
>> loader can parse the device tree in order to pick up what devices are
>> installed and need some kind of low-level initialisation)
>
> Actually a device tree describes the hardware, and therefore should in
> principle be just as applicable to the boot loader.
>
>>
>> I think at such a low level you really have to say 'hey, these boards are
>> different and need a different configuration' unless you put something in
>> hardware that allows U-Boot to pick up on the difference without needing
>> to initialise _anything_ similar to what Stephen has done to pass the
>> debug UART info to Linux via a scratch register
>
> Well we could do that, but the config is in some sense supposed to be
> the device tree. We are only dealing here with a little case where
> there is no device tree and want to output a message.

Exactly - Your goal is to create a board configuration which has no concept
of the true physical nature of the board and for that true nature to be
provided in a configuration file. The configuration file may or may not be
valid and if it isn't, you have no idea how to tell the user. Worse, if it
is valid but something else happens which means it cannot be loaded then,
again, you cannot tell the user what went wrong gracefully

The idea of having a last resort backup plan to spit out a diagnostic
message is good, but I think the implementation fallls short of the mark
here (I'm actually talking about Simon's patch - this 'mark one port for
Linux to use as a fall-back' is, IMHO, pretty neat)

Quite honestly, all boards which use the same UART to output the panic
message can have the same U-Boot binary. If two boards use differing
ports for the panic message, then they really need to be using different
U-Boot binaries unless you have a physical configuration (a jumper for
example) which can be detected without any other initialisation

Another option maybe is to read the serial port when 'panic' mode is
entered - Cycle through all ports (changing BAUD rate if need be) and if
you pick up a preset character, dump the panic message to that port - You
could even use the hardware lines (like RI if available) as an additional
check

Regards,

Graeme