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

[Graeme Russ]

Hi Wolfgang,

On Dec 15, 2012 6:30 PM, "Wolfgang Denk" <wd at denx.de> wrote:
>
> Dear Graeme Russ,
>
> In message <50CBD313.60508 at gmail.com> you wrote:
> >
> > I can give you an example - Remote Telemetry Units (RTUs). They usually
> > have a number of serial ports. The number of ports may vary based on the
> > sub-model. Some ports may be RS-232, some may be RS-485 or RS-422.
> > Depending on what additional devices you want to communicate with, you
may
> > need to use the 'console/diag' port to connect to a real device. So what
> > you want to do is route console to another port (if available) or even
> > netconsole.
>
> Netconsole is always an option, and I think we also support switching
> to other serial ports here and there (after relocation, that is).
>
> But if you need console output before relocation (i. e. during
> debugging), then I do not see why we cannot demand that the console
> port is statically configured, and that you need corectly configured
> images to have an early working console.

I have seen situations where console output by the bootloader messes up
attached serial devices hence effectively dropping the serial port count by
one. Pre-console buffer helps a lot (no console output until we know where
to send it to). But that kills early debug.

>
> > I do get your point of view. But I think a combination of storing the
> > dynamic console info in a DT format, the pre-console buffer and getting
DT
> > available as early as possible can yield a 'non-cludgy' solution. For
board
> > or SoC vendors who, for whatever reason, have implemented non-DT
storage of
> > hardware enumeration data they will be stuck with the penalty of having
to
> > translate that data into DT format before it can be parsed by U-Boot.
Maybe
> > this could be done in SPL. Yes, it's a hack, but if it can't be worked
> > around, push it as low as possible and as far away from the U-Boot core
as
> > possible
>
> I mostly agree here.  But I still fail to see why we havet os upport
> this combination of early and dynamic - and only this is what causes
> some issues.

The situations I have seen can be resolved by pre-console buffer and
console configured in env. If the hardware is playing up,  a factory reset
to default console (without using pre-console buffer) suffices (the device
is on the bench with nothing attached). But then we are back to the board
specific/pre-DT problem.

Regards,

Graeme