[U-Boot] [PATCH v2 3/4] tegra: Implement pre-console putc() for fdt warning

Simon Glass sjg at chromium.org
Sun Mar 11 01:48:57 CET 2012


Hi Wolfgang,

On Sat, Mar 10, 2012 at 2:49 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ1GzD3KJeaA1LLdYPQsoOLWJPxmX=FHFeUthkdPrUYt2g at mail.gmail.com> you wrote:
>>
>> > I think outputting data to all "potential" console ports is a really
>> > bad thing, as you cannot know how your users are using the hardware.
>> > They may have attached hardware to the UARTs, and the data you send to
>> > the port causes a mis-function of the device. =A0I guess you don't add
>> > to your documentation a warning like: select one port as console, and
>> > leave allother ports unused, because we may send random date to all
>> > ports any time?
>>
>> Only on a fatal error. Unfortunately this idea of 'fatal error' was
>> lost in the conversion from board_panic_no_console() to
>
> This "fatal error" might become a fatal accident in some cases if you
> send random data to some port that controls some kind of machinery or
> whatever.  Never ever do that!

Yes I see that. Scary.

>
>> board_pre_console_putc(). I would be keen to move back to that
>> original plan, so that the idea of a fatal error is captured. In a
>> fatal error situation there is no prospect of the board working and
>> the only hope is that we can alert the user.
>
> Agreed.  But you must not do this by performing random actions on
> random (potentially otherwise used [by the end user]) interfaces.

OK I will come up with a patch along these lines. See below for thoughts.

>
>> > If you do not know which UART port to use, then the only consequence
>> > can be not to use any UART prt at all.  Use a LED with blink codes or
>> > whatever your hardwar ehas, but do not mess with random ports.
>>
>> I agres with the sentiment and this is a very ugly corner case, but in
>> practice people want to know what happened, not just be presented with
>> a brick.
>
> Yes, I understand this.  But please try to find another way to signal
> failure.  Do not perform random actions on a device - you could as
> well always output all data on all UART ports because with this
> codeyou cannot use the other ports for any serious purpose anyway.

OK so I think the first step is to move this function out of generic
Tegra code and into board-specific code.

Presumably the board owner will know what is safe for that board. In
many cases there is only one possible console UART. If there is an LED
available then the board could flash that, but it isn't hugely useful.
We already know the board is a brick - turning on a light to tell us
that it is a brick doesn't help much. So I do want to provide a way to
get a message out on boards where it is safe to do so.

In the case of the Tegra board there are four possible UARTs. I wonder
whether we could do something like provide a Tegra panic function
which is told which UARTs it can use.

Then the board can decide how to implement a board_pre_console_panic()
function, which could be a weak function, perhaps by just hanging,
perhaps by toggling a few GPIOs to flash LEDs, or perhaps by calling
this Tegra panic function asking for a message on UARTs it knows are
safe to use.

This would alleviate the concern that we might turn off someone's live
support system by mistake.

>
>> > I also cannot understand why you think you must init() and drain() the
>> > UART for each character printed - ok, the latter is probably a
>> > consequence of re-initializing the port for each character.
>> > Eventually this will be not needed once you get rid of the re-init.
>>
>> OK so how about moving to a puts()-type interface? Then I can remove this.
>
> Sorry, but I don't have enough context - pts() interface where or for
> what?

I just meant that this would be much easier if we had a panic function
instead of this putc() stuff. We can (for example) flash lights
indefinitely and never return.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Each honest calling, each walk of life, has its own  elite,  its  own
> aristocracy based on excellence of performance. - James Bryant Conant


More information about the U-Boot mailing list