On 05/21/2013 08:47 AM, Sascha Hauer wrote:
On Tue, May 21, 2013 at 08:38:26AM +0200, Sebastian Hesselbarth wrote:
On 05/21/2013 08:33 AM, Sascha Hauer wrote:
On Tue, May 21, 2013 at 08:28:10AM +0200, Sascha Hauer wrote:
+ armada_370_xp_add_uart();
How do you want to support a board which uses another UART instead of
uart0 when you call this from SoC code?
Ok, I see. You use CONFIG_MVEBU_CONSOLE_UART to determine an UART base.
What's the rationale for doing this? We don't want to have compile time
decisions for things we know at runtime.
How do you know the UART console by runtime? It can be on any UART
possible.
Well ok, you can't really know it at runtime, but you could use multiple
consoles or maybe you could register a specific uart based on a
configuration option in the environment or some bootstrap pin. These
are all not very common examples, but I think you shouldn't prevent them
in your SoC code.
Anyway, as we are moving to DT with the next patches, all
enabled uarts will be registered.
But leaves the question, how to get the correct UART for console?
Using the linux,stdout-path property in the chosen node.
Well, okay then consider the above a temporary compile time config
option that will be removed as soon as DT patches come. ;)
Sebastian
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
