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

[Simon Glass]

Hi Stephen,

On Wed, Dec 12, 2012 at 3:52 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 12/12/2012 04:38 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Wed, Dec 12, 2012 at 3:23 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> A single U-Boot binary may support multiple very similar boards. These
>>> boards may use different UARTs for the main debug console. Hence, it is
>>> impossible to #define CONFIG_SYS_NS16550_COM1 to some static UART
>>> address, since the true value may only be determined at run-time, after
>>> identifying the actual hardware. Provide an API for boards to call to
>>> set the actual address of the UART, e.g. from spl_board_init() or
>>> board_early_init_f().
>>>
>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>>
>> This seems reasonable in the interim while we are hard-coding things
>> but needing more flexibility. How do you plan to configure the actual
>> address - is it with the ODM data or FDT?
>
> I intend to use the ODMDATA. This already includes a field that
> specifies which UART to use. I'm working on some patches (to
> BCT-generation tools and U-Boot) that define an ODMDATA2 value, which
> will indicate the complete pinmux configuration required for the UART,
> so everything can be self-contained. I'm fairly close to publishing
> these patches.

Yes actually I remember you mentioning that before, sounds good.

>
>> One question though - is it not possible to select the correct port
>> number using environment (say) rather than changing the address of an
>> existing port? After all, I think we can assume that all available
>> ports are in the array. Or can we?
>
> Right now, we only define one of CONFIG_SYS_NS16550_COMn (n==1..6). I
> suppose we could define 5 of these, to represent the 5 different UARTs
> on Tegra, so that all ports are always available, irrespective of what,
> if anything, they're pinmuxed out to and hooked up to in HW.
>
> The question would then become: how to tell U-Boot which to use? The
> answer might be to put "eserial0" or "eserial1", etc. into the stdin
> environment variable rather than plain "serial". However, the question
> then becomes: what do we put into the default environment? The default
> environment would then need to vary depending on which board you were
> running on (since the serial port number might be different), and I
> really want "env default -f -a" to leave the user with a working system.
> How would that work?

Well I suppose U-Boot could have plain "serial" and its meaning would
be determined by the board at init. I don't think we have a way of
doing that.

But looking forward if we use the FDT to specify the console (as we
did in the Chromium Tegra tree) then it becomes a case of selecting
between available ports using /alias/console, rather than changing
port 0 to point to the selected port.

I don't see this as a big deal, particularly while we still have
everything in serial so hard-coded. Perhaps we should run with what
you have hear until the device model stuff lands, and then a new
solution will present itself.

Regards,
Simon