
Hi Stephen,
On Wed, Dec 12, 2012 at 3:52 PM, Stephen Warren swarren@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@wwwdotorg.org wrote:
From: Stephen Warren swarren@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@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