Hi Stephen, On Wed, Dec 12, 2012 at 3:52 PM, Stephen Warren <swar...@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 <swar...@wwwdotorg.org> >> wrote: >>> From: Stephen Warren <swar...@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 <swar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot