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

[Stephen Warren]

On 12/14/2012 01:40 PM, Tom Rini wrote:
> On 12/13/12 16:51, Simon Glass wrote:
> 
> [snip]
>>>> 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.
> 
> There's two parts to it.  One part is that sure, Tegra and only
> Tegra has ODMDATA.  But on am33xx if we poke the i2c eeprom (on
> platforms that do the eeprom) we can then know ...  And I bet other
> SoCs have other tricks for this or that.  So it's not just tegra
> that can tell us the initial console is $here or $there if we just
> ...something.

That's certainly true.

I personally view the method of retrieving this kind of information as
part of an SoC's boot architecture, or as part of a board's design. As
you have mentioned above, different SoCs/boards already have
mechanisms to represent/determine this information. These mechanisms
are already in-place and defined by the SoC or board designers.

> The other part is, take a look at the Allwinner thread from a week
> or so ago.  We really need to define how we want early board
> specific data to come in because if we start saying we'll accept
> per-SoC solutions we'll be drowning in them in short time.  We want
> to say here's our preferred way to pass this information in.

I don't understand why you think U-Boot is in a position to mandate
that the existing solutions that are already in place are incorrect,
and must be replaced with some alternative.