[U-Boot] [PATCH] ns16550: allow UART address to be set dynamically

[Simon Glass]

Hi Stephen,

On Thu, Dec 13, 2012 at 1:07 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 12/13/2012 01:53 PM, Tom Rini wrote:
>> On 12/13/12 15:45, Stephen Warren wrote:
>>> On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
>>>> Dear Stephen Warren,
>>>>
>>>> In message <50CA1BB8.4000704 at wwwdotorg.org> you wrote:
>>>>>
>>>>>> Arghh... Do we really, really have to invent yet another
>>>>>> way to pass hardware configuration information?  Especially
>>>>>> one totally incompatible to any other system?
>>>>>
>>>>> This is a special case for the console UART. The idea is to
>>>>> get that up and running well before device tree is parsed in
>>>>> any way. For example, Tegra's SPL doesn't touch the device
>>>>> tree in any way (or even know one exists) but does want to
>>>>> print (possibly error) messages in a generic fashion.
>>>>> Similarly, many problems could occur before the device tree
>>>>> is parsed (e.g. the user forgets to provide one...), and
>>>>> having specifically the console UART set up before that
>>>>> allows those errors to be reported, rather than requiring a
>>>>> JTAG or similar debugger.
>>>>>
>>>>> My intent is that ODMDATA will definitely only be used for
>>>>> the console UART, and will NOT be used for anything else like
>>>>> LCD, RTC, ... Those other devices will certainly be
>>>>> configured via device tree.
>>>>
>>>> We've been there before, you know.
>>
>>> I'm not quite sure what the implication is here.
>>
>>>> OK - what is the scope of visibility of such code?  Will it be
>>>>  strictly board specific only?  Or SoC specific? Arch? Global?
>>
>>> It's partially SoC-specific, partially global.
>>
>> Right.  I see what Wolfgang was saying before, and I get it now.
>> This is not how we want to open the can of worms for "lets do
>> dynamic locations of stuff".  We should start with being able to
>> parse (some form of the normal) device tree, and be able to say "I
>> now know I have a UART $HERE and $THERE".
>
> So if Tegra were to statically define the location of all 5 on-SoC
> UARTs, by defining CONFIG_SYS_NS16550_COM*, and then use the ODMDATA
> to select which UART to use for the console, rather than using the
> ODMDATA to dynamically change the value that CONFIG_SYS_NS16550_COM1
> sets up, would that remove the objection? I haven't look into coding
> that up, but I imagine it could be made to work...

Seems good to me.

>
>> And yes, that's too late for initial console being in the right
>> spot, at first, probably.  But now we've moved in the direction of
>> being able to dynamically assign things.
>
> I'm not sure about "at first"; on Tegra, I don't imagine the SPL would
> ever use device tree. The only HW- (board-) specific thing that's
> relevant to it is the UART and UART-pinmux, since the SPL only exists
> to boot the main A9 cores, and doesn't ever access any kind of storage
> device.

On Tegra, yes. On some chips, SPL accesses devices to read U-Boot.

In extremis we could use a very simple table (a C structure with a
couple of members) which is filled in by a tool from the device tree
as part of image creation, just to avoid the FDT overhead. However,
given that many of the SOCs I seem to be using have >100KB of SRAM,
it's not clear that we shouldn't just use FDT eventually.

>
>> And from there we can move on and say "On ${SoC} we get a device
>> tree (that we can't quite parse as we don't have enough resources)
>> AND $some-data (OMDATA or an abbreviated device tree or $whatever),
>> lets translate that into something we can make use of very early
>> rather than a hard-coded initial console location"
>
> It seems like you're saying that once we have dynamic serial port
> assignment working based on DT, you'll be fine using ODMDATA to
> initialize the early console, but not before then? If so, I'm having a
> hard time understanding why enabling the DT-based support blocks using
> ODMDATA, since the code would be pretty orthogonal.

Yes well dynamic console selection sounds find to me, ODMDATA or
otherwise. To me it is a Tegra feature that should be supported as
such. Perhaps we can allow the FDT console alias to specify "odmdata"
to mean that, and/or (as you suggest I think) set the console to
USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.

Regards,
Simon