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

[Simon Glass]

Hi Graeme,

On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Graeme,
>>
>> On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>> Hi Stephen, Simon,
>>>
>>> On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>> On 03/20/2012 02:13 PM, Simon Glass wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>> This works together with a kernel change that looks at the scratchpad
>>>>>> register to determine which of the many UARTs it should use for early
>>>>>> printing:
>>>>>>
>>>>>> http://www.spinics.net/lists/arm-kernel/msg154633.html
>>>>>>
>>>>>> Note that this configuration only affects the kernel's decompressor and
>>>>>> earlyprintk code. Once the kernel is initialized far enough to parse the
>>>>>> device tree, the console is initialized using information contained
>>>>>> therein.
>>>>>>
>>>>>> Base on work by Doug Anderson <dianders at chromium.org>, but significantly
>>>>>> rewritten.
>>>>>>
>>>>>> Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
>>>
>>>>
>>>>> For the pre-console panic stuff, the point is that there may well be
>>>>> one UART used for the console, but *we don't know which one it is!*.
>>>>
>>>> That's where we disagree.
>>>>
>>>> For each board, there is a single fixed UART that should be used for
>>>> both pre-console panic and the "real" console later. This is fixed by
>>>> the single static board design.
>>>
>>> I agree - The board designer should specify a 'default' debug port which
>>> is used for all character output prior to the 'configured' console port
>>> being initialised.
>>
>> We can provide that, but if it is wrong for the board we are using,
>> then there will be no output. Stephen's original complaint was a brick
>> if there is no valid device tree. We need this to work!
>>
>>>
>>> In the 'normal' boot case, the default console should never have any output
>>> sent to it (unless it also happens to be the 'configured' console port) as
>>> Both U-Boot and Linux will use a pre console buffer to buffer any output
>>> prior to the 'configured' console being available
>>>
>>> So I think there is a clear evidence that the 'Board panic no console'
>>> and 'Specify debugging serial port at boot' are intrinsicly related - Both
>>> U-Boot and Linux should be dumping their 'pre-console' messages to the
>>> same port and this port should be specified by the hardware designer
>>>
>>> So that being the case, there should be a single CONFIG_ option which
>>> both patches should be using
>>
>> We cannot select the UART via CONFIG - remember that all of these
>> boards have the same U-Boot binary. Please read that again :-) The
>> device tree is the only thing that distinguishes them. All of the
>> CONFIG options are identical for all boards.
>
> But I don't get it - In your Seaboard patch, you only use UARTD so in this
> case we could CONFIG_ it?

Yes, Stephen specifically asked for this so I changed it. See the
other ongoing discussion on this.

>
> And it's sounding like for other scenarios you are going to resign
> yourself to there not being a common UART so you will send the pre-console
> (panic) message to multiple UARTs - something that should be avoided at
> all costs...

Of course - we cannot require the board to use a particular UART. The
SOCs have various options and different people will make different
decisions. Honestly, if we can't deal with UART selection in the
device tree, we aren't going to solve the more difficult problems.

>
> I know we are dealing with a corner case abnormal situation here, but
> something does not smell right... Maybe I'm not understanding something
> obvious yet...

I'm not sure. I suspect it could be easily explained with an hour at
the whiteboard, but it's hard by email.

The requirement is to output a message that the user can see, and we
have a selection of UARTs which *might* be the console UART. For now
we don't know exactly which one it is (see my SPL config comment
though which might eventually solve this). So we send output to
several of them. To protect against any danger, we permit the board
file to select which are permitted.

Regards,
Simon

>
> Regards,
>
> Graeme