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

[Wolfgang Denk]

Dear Stephen,

In message <50CFA394.40901 at wwwdotorg.org> you wrote:
>
> > Yes, there are.  But your console port cannot be compred against
> > dynamically populated and scannable bus interfaces like USB or PCI,
> > and I think you are aware of that.
> 
> I honestly don't know why you couldn't have a PCI-based console UART.

This is actually another question.

You cannot compare a statically configured UART port (where all
configuration information you need is the index into the table of
possible UARTs) to a dynamic bus scan where you cannot know in advance
whether you detect any devices at all, or how many, or which types.

You will have hard times using a PCI or USB based console port
for early console output because the majority of the PCI and USB
related code will only be runnable after relocation.

> > Not any dynamic device registration.  But here, it actually AIN'T
> > dynamic - it is fully static, just board dependent.
> 
> If you want to run the same U-Boot binary on multiple different boards,
> then that does make the UART selection dynamic. There's no conceptual
> difference between dynamic information coming from a DT passed to U-Boot
> at runtime, SoC-defined enumeration/selection mechanisms such as Tegra's
> ODMDATA, or scanning a PCI bus.

Maybe there is no conceptual difference - but only if you chose to
look at things at a relatively high abstraction level.

Implementation-wise the difference it between passing a single integer
variable (the UART index) and performing a dynamic bus scan, detecting
number and type of devices and selecting appropriate drivers.

> Or, is U-Boot going to ban addressing TI's case where the UART selection
> is stored in an I2C EEPROM that can be read at run-time, since instead
> during flashing that information could be extracted and hard-coded into
> the board's device tree instead?

Here again we are talking about a UART, which is statically confgured
per board, and we just need this specific piece of board information.

And yes, this piece of information should be encoded in the device
tree.  Note that the "hard-coded" you mantion has never been made a
requirement.  For simplicity of design it might make sense to actually
use the DT format for such information right away.  But as your own
example shows, not all chip / board vendors do that.  Simon and Tom
already commented on what to do in such situations.

It seems Simon, Tom and me mostly agree on what to do.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You have the capacity to learn from  mistakes.  You'll  learn  a  lot
today.