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

[Stephen Warren]

On 12/14/2012 02:14 PM, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini <trini at ti.com> 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.
> 
> 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.
> 
>> Yes there is a general problem to be solved here. Assuming that
>> the problem is solved in U-Boot itself with device tree, then:
> 
>> 1. It would be nice to keep a single source for this information
>> so that SPL and U-Boot are consistent. Where we invent a new
>> mechanism for efficiency reasons it would be best if there was a
>> 1-1 mapping from device tree to this new mechanism.

Many (most, I assume) U-Boot builds don't use device tree at all
(yet?). I'm not sure we should tie any new mechanism for low-level
boot information into device tree, since that severely limits where it
can be used.

>> 2. It would be nice if we could write a simple tool which is
>> generic across architectures and configures an SPL given a device
>> tree file. I'm not sure if that is a problem worth solving or
>> not.

I'm not sure the information is generic enough to even represent in
device tree, or that it even makes sense to do so.

After all, what the Tegra ODMDATA2 fields are representing is pinmux
setup. Every piece of hardware does pinmux differently; at the very
least, the pin IDs and available mux selection options are different.
Some SoCs mux pins individually, some in groups. Sometimes more than
just mux options must be selected. Some SoCs don't need pinmux. Some
SoCs would allow the data to be embedded into some boot flash in a
SoC-defined manner, whereas other SoCs' boards might require reading
GPIOs, I2C EEPROMs, ... to get the information, etc. All this means
that the information required, and the format needed to represent it,
really is different in every case. The only way to avoid this would be
to retro-actively redesign every SoC and board to always have the same
requirements for what data needs to represent the UART selection
process, and implement in the same way. That's obviously impossible to
do, and so having any kind of remotely generic tool to handle the
representation of this data also seems quite impossible.

>> 3. From the SPL point of view, the less code required to get at
>> the information, the better.
> 
>> For one possible solution, see:
> 
>> arch/arm/include/asm/arch-exynos/spl.h

A certain amount of that information duplicates what's in the Tegra
BCT, which is essentially part of the HW itself, since it's handled by
the non-modifiable boot ROM code. I really don't think U-Boot should
be mandating some data structure that requires duplication of
information that's already present.