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

[Simon Glass]

Hi Stephen,

On Fri, Dec 14, 2012 at 2:03 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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.

Perhaps I can make the point another way. Assuming that the SOC in
question is ARM-based and has Linux support it either supports FDT now
or presumably will fairly soon. We found that some of the things we
want to know about at the low level are hardware properties that are
already sit in a node in the FDT. For example the memory controller
may have information about the memory type attached to it.

Given this, my suggestion is that this hardware information be kept in
one place (FDT) where possible, even if it unfortunately temporarily
needs to be translated into some simpler format as part of the SPL
build for efficiency reasons.

As to platforms that support FDT, that is true, only a few. Adding
basic support for a new board is very easy though.

But looking at your comments below, I worry that this might be a
sledgehammer to crack a nut. As I understand it, you really just have
a 32-word which selects the console UART and a few other things. It
seems like you solved that problem a few emails back.

>
>>> 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.

No certainly not. But I think Tom is concerned that each SOC will do
it differently and we might end up with a mess. SPL configuration is a
slightly different problem to what you talk about here, but in a sense
the BCT is an SOC-specific binary config blob attached to SPL. Other
SOCs might do a similar thing but in their own format and in their own
tools. Is it possible to unify these at all? Perhaps not?

Regards,
Simon