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

[Simon Glass]

Hi Tom,

On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini <trini at ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.

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.

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

Basically it works (for a small number of parameters) by giving each a
letter, and listing the required parameters in the structure. An
external tool can then fairly easily fill in the values it needs from
the device tree, without worrying about the format being wrong, etc.

I'm not sure that it scales to all SOCs though.

Personally I would like to see the simplest option possible and avoid
inventing a new infrastructure just for SPL.

Regards,
Simon

>
> - --
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQy47RAAoJENk4IS6UOR1W/wIP/1CyXg8ShiITZAS6/R52Aj89
> X7mhTHWUg3m+BtEN8TGkI8foznHjpv5JK7Exlf8XgKuoH6idBYd/5eF6nRXGfePY
> rQAad+hHeBYSBfvaP6GIaSTMm5x6KDMILExDkxue0mNcdkRL568ac0oR/HsVPM/N
> d75PVHsK77dAIzm9DbT3m2zilHC6balbplG1LtnKx0+sKb/PGpfXT5GYCZUUc9es
> R2Uzkyx+f25ZTlVRzdrh+h8SDhNzuACszJtqY11SxhLUZevvkja0jm6LykBsyJGH
> wh1wydRRPN6LKWRVQgUAHBJBEebf6Olck+PPBBA3+LypN5kSuj+bKixoyNxTQHIf
> E8qJb59rB7bnXLVb43AudcbUWe/PqdwZ8Yha3dmMrT/r8k0eXfNLBXlIP8BDXPis
> 4ssoH/DZXqv0+QvsmX+NPoF/3pBSy/Uc1g13w20xbdy12ovGEVgOWwioOPKgWgCR
> b34CvOT7MR+8zMixCHP287ITyTrpY/K7gxo2rF8EQ+o6QW1JCphTJFpVqlTVWEAT
> 5vPMnt7y7w9WtImCxUpa7itMfeVOgnbv+2bB2Ipxj6VjOZcIvdqB405wN39bGYux
> fzatCFurtbdaSQ7aFR1ZFRp51rjl/rC7QxODD0H84Ip7AbVO2qLPOTri2wwYfaPN
> EXPCI+T8YtDbI2/RW92B
> =DR6s
> -----END PGP SIGNATURE-----