[U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
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 --- Note: I have a Tegra patch that will depend on this functionality. I'd like to see the patch applied through the Tegra tree if possible, or if not, quickly pushed into u-boot/master or u-boot/next so Tom Warren can base a Tegra branch on top of it easily without delay.
drivers/serial/serial_ns16550.c | 5 +++++ include/ns16550.h | 1 + 2 files changed, 6 insertions(+)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c index fc01a3c..fc8253b 100644 --- a/drivers/serial/serial_ns16550.c +++ b/drivers/serial/serial_ns16550.c @@ -166,6 +166,11 @@ static int calc_divisor (NS16550_t port) (MODE_X_DIV * gd->baudrate); }
+void NS16550_set_dynamic_address(int port, NS16550_t com_port) +{ + PORT = com_port; +} + void _serial_putc(const char c,const int port) { diff --git a/include/ns16550.h b/include/ns16550.h index 51cb5b4..6d7483f 100644 --- a/include/ns16550.h +++ b/include/ns16550.h @@ -171,6 +171,7 @@ typedef struct NS16550 *NS16550_t; /* useful defaults for LCR */ #define UART_LCR_8N1 0x03
+void NS16550_set_dynamic_address(int port, NS16550_t com_port); void NS16550_init(NS16550_t com_port, int baud_divisor); void NS16550_putc(NS16550_t com_port, char c); char NS16550_getc(NS16550_t com_port);
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?
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?
Regards, Simon
Note: I have a Tegra patch that will depend on this functionality. I'd like to see the patch applied through the Tegra tree if possible, or if not, quickly pushed into u-boot/master or u-boot/next so Tom Warren can base a Tegra branch on top of it easily without delay.
drivers/serial/serial_ns16550.c | 5 +++++ include/ns16550.h | 1 + 2 files changed, 6 insertions(+)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c index fc01a3c..fc8253b 100644 --- a/drivers/serial/serial_ns16550.c +++ b/drivers/serial/serial_ns16550.c @@ -166,6 +166,11 @@ static int calc_divisor (NS16550_t port) (MODE_X_DIV * gd->baudrate); }
+void NS16550_set_dynamic_address(int port, NS16550_t com_port) +{
PORT = com_port;+}
void _serial_putc(const char c,const int port) { diff --git a/include/ns16550.h b/include/ns16550.h index 51cb5b4..6d7483f 100644 --- a/include/ns16550.h +++ b/include/ns16550.h @@ -171,6 +171,7 @@ typedef struct NS16550 *NS16550_t; /* useful defaults for LCR */ #define UART_LCR_8N1 0x03
+void NS16550_set_dynamic_address(int port, NS16550_t com_port); void NS16550_init(NS16550_t com_port, int baud_divisor); void NS16550_putc(NS16550_t com_port, char c); char NS16550_getc(NS16550_t com_port); -- 1.7.10.4
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.
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?
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
Dear Stephen Warren,
In message 50C918A5.6090207@wwwdotorg.org you wrote:
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.
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
I think I will be objecting against such an approach. Please use the device tree instead.
Best regards,
Wolfgang Denk
On 12/13/2012 03:29 AM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50C918A5.6090207@wwwdotorg.org you wrote:
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.
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
Dear Stephen Warren,
In message 50CA1BB8.4000704@wwwdotorg.org you wrote:
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
Best regards,
Wolfgang Denk
On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CA1BB8.4000704@wwwdotorg.org you wrote:
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Note that by "all" and "global" here, I'm talking relative to all Tegra SoCs, not about anything non-Tegra. "SoC-specific" means different for Tegra20, Tegra30, Tegra114, etc.
In every Tegra SoC, the boot ROM reads a BCT (Boot Configuration Table) at boot. The BCT contains e.g. SDRAM controller configuration and other low-level boot information. The BCT is stored within the boot flash. The ODMDATA fields are stored within the BCT. The offset of the ODMDATA within the BCT is SoC-specific since the BCT structure is SoC-specific.
The ODMDATA for all Tegra SoCs includes fields that define (a) which UART to use (so far, identical across all SoCs) (b) the pinmux configuration to use, and other information (mainly SDRAM size at the moment). Since the pinmux HW is SoC-specific, so is the exact format of the UART pinmux configuration data.
For more details on Tegra BCTs, you may refer to: ftp://download.nvidia.com/tegra-public-appnotes/index.html http://nv-tegra.nvidia.com/gitweb/?p=tools/cbootimage.git;a=summary
Note that in the latter case, I haven't pushed out the patches which document the UART pinmux fields yet, but will very soon; most likely as soon as we've resolved this conversation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/12 15:45, Stephen Warren wrote:
On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CA1BB8.4000704@wwwdotorg.org you wrote:
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Right. I see what Wolfgang was saying before, and I get it now. This is not how we want to open the can of worms for "lets do dynamic locations of stuff". We should start with being able to parse (some form of the normal) device tree, and be able to say "I now know I have a UART $HERE and $THERE". And yes, that's too late for initial console being in the right spot, at first, probably. But now we've moved in the direction of being able to dynamically assign things. And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
In other words, we want to (re)start the conversation around lets get device tree going. Then we can deal with other things.
- -- Tom
On 12/13/2012 01:53 PM, Tom Rini wrote:
On 12/13/12 15:45, Stephen Warren wrote:
On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CA1BB8.4000704@wwwdotorg.org you wrote:
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Right. I see what Wolfgang was saying before, and I get it now. This is not how we want to open the can of worms for "lets do dynamic locations of stuff". We should start with being able to parse (some form of the normal) device tree, and be able to say "I now know I have a UART $HERE and $THERE".
So if Tegra were to statically define the location of all 5 on-SoC UARTs, by defining CONFIG_SYS_NS16550_COM*, and then use the ODMDATA to select which UART to use for the console, rather than using the ODMDATA to dynamically change the value that CONFIG_SYS_NS16550_COM1 sets up, would that remove the objection? I haven't look into coding that up, but I imagine it could be made to work...
And yes, that's too late for initial console being in the right spot, at first, probably. But now we've moved in the direction of being able to dynamically assign things.
I'm not sure about "at first"; on Tegra, I don't imagine the SPL would ever use device tree. The only HW- (board-) specific thing that's relevant to it is the UART and UART-pinmux, since the SPL only exists to boot the main A9 cores, and doesn't ever access any kind of storage device.
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Hi Stephen,
On Thu, Dec 13, 2012 at 1:07 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/13/2012 01:53 PM, Tom Rini wrote:
On 12/13/12 15:45, Stephen Warren wrote:
On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CA1BB8.4000704@wwwdotorg.org you wrote:
Arghh... Do we really, really have to invent yet another way to pass hardware configuration information? Especially one totally incompatible to any other system?
This is a special case for the console UART. The idea is to get that up and running well before device tree is parsed in any way. For example, Tegra's SPL doesn't touch the device tree in any way (or even know one exists) but does want to print (possibly error) messages in a generic fashion. Similarly, many problems could occur before the device tree is parsed (e.g. the user forgets to provide one...), and having specifically the console UART set up before that allows those errors to be reported, rather than requiring a JTAG or similar debugger.
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Right. I see what Wolfgang was saying before, and I get it now. This is not how we want to open the can of worms for "lets do dynamic locations of stuff". We should start with being able to parse (some form of the normal) device tree, and be able to say "I now know I have a UART $HERE and $THERE".
So if Tegra were to statically define the location of all 5 on-SoC UARTs, by defining CONFIG_SYS_NS16550_COM*, and then use the ODMDATA to select which UART to use for the console, rather than using the ODMDATA to dynamically change the value that CONFIG_SYS_NS16550_COM1 sets up, would that remove the objection? I haven't look into coding that up, but I imagine it could be made to work...
Seems good to me.
And yes, that's too late for initial console being in the right spot, at first, probably. But now we've moved in the direction of being able to dynamically assign things.
I'm not sure about "at first"; on Tegra, I don't imagine the SPL would ever use device tree. The only HW- (board-) specific thing that's relevant to it is the UART and UART-pinmux, since the SPL only exists to boot the main A9 cores, and doesn't ever access any kind of storage device.
On Tegra, yes. On some chips, SPL accesses devices to read U-Boot.
In extremis we could use a very simple table (a C structure with a couple of members) which is filled in by a tool from the device tree as part of image creation, just to avoid the FDT overhead. However, given that many of the SOCs I seem to be using have >100KB of SRAM, it's not clear that we shouldn't just use FDT eventually.
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
Regards, Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
- -- Tom
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that the problem is solved in U-Boot itself with device tree, then:
1. It would be nice to keep a single source for this information so that SPL and U-Boot are consistent. Where we invent a new mechanism for efficiency reasons it would be best if there was a 1-1 mapping from device tree to this new mechanism.
2. It would be nice if we could write a simple tool which is generic across architectures and configures an SPL given a device tree file. I'm not sure if that is a problem worth solving or not.
3. From the SPL point of view, the less code required to get at the information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
Basically it works (for a small number of parameters) by giving each a letter, and listing the required parameters in the structure. An external tool can then fairly easily fill in the values it needs from the device tree, without worrying about the format being wrong, etc.
I'm not sure that it scales to all SOCs though.
Personally I would like to see the simplest option possible and avoid inventing a new infrastructure just for SPL.
Regards, Simon
Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQy47RAAoJENk4IS6UOR1W/wIP/1CyXg8ShiITZAS6/R52Aj89 X7mhTHWUg3m+BtEN8TGkI8foznHjpv5JK7Exlf8XgKuoH6idBYd/5eF6nRXGfePY rQAad+hHeBYSBfvaP6GIaSTMm5x6KDMILExDkxue0mNcdkRL568ac0oR/HsVPM/N d75PVHsK77dAIzm9DbT3m2zilHC6balbplG1LtnKx0+sKb/PGpfXT5GYCZUUc9es R2Uzkyx+f25ZTlVRzdrh+h8SDhNzuACszJtqY11SxhLUZevvkja0jm6LykBsyJGH wh1wydRRPN6LKWRVQgUAHBJBEebf6Olck+PPBBA3+LypN5kSuj+bKixoyNxTQHIf E8qJb59rB7bnXLVb43AudcbUWe/PqdwZ8Yha3dmMrT/r8k0eXfNLBXlIP8BDXPis 4ssoH/DZXqv0+QvsmX+NPoF/3pBSy/Uc1g13w20xbdy12ovGEVgOWwioOPKgWgCR b34CvOT7MR+8zMixCHP287ITyTrpY/K7gxo2rF8EQ+o6QW1JCphTJFpVqlTVWEAT 5vPMnt7y7w9WtImCxUpa7itMfeVOgnbv+2bB2Ipxj6VjOZcIvdqB405wN39bGYux fzatCFurtbdaSQ7aFR1ZFRp51rjl/rC7QxODD0H84Ip7AbVO2qLPOTri2wwYfaPN EXPCI+T8YtDbI2/RW92B =DR6s -----END PGP SIGNATURE-----
On 12/14/2012 02:14 PM, Simon Glass wrote:
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini trini@ti.com wrote: On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that the problem is solved in U-Boot itself with device tree, then:
- It would be nice to keep a single source for this information
so that SPL and U-Boot are consistent. Where we invent a new mechanism for efficiency reasons it would be best if there was a 1-1 mapping from device tree to this new mechanism.
Many (most, I assume) U-Boot builds don't use device tree at all (yet?). I'm not sure we should tie any new mechanism for low-level boot information into device tree, since that severely limits where it can be used.
- It would be nice if we could write a simple tool which is
generic across architectures and configures an SPL given a device tree file. I'm not sure if that is a problem worth solving or not.
I'm not sure the information is generic enough to even represent in device tree, or that it even makes sense to do so.
After all, what the Tegra ODMDATA2 fields are representing is pinmux setup. Every piece of hardware does pinmux differently; at the very least, the pin IDs and available mux selection options are different. Some SoCs mux pins individually, some in groups. Sometimes more than just mux options must be selected. Some SoCs don't need pinmux. Some SoCs would allow the data to be embedded into some boot flash in a SoC-defined manner, whereas other SoCs' boards might require reading GPIOs, I2C EEPROMs, ... to get the information, etc. All this means that the information required, and the format needed to represent it, really is different in every case. The only way to avoid this would be to retro-actively redesign every SoC and board to always have the same requirements for what data needs to represent the UART selection process, and implement in the same way. That's obviously impossible to do, and so having any kind of remotely generic tool to handle the representation of this data also seems quite impossible.
- From the SPL point of view, the less code required to get at
the information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
A certain amount of that information duplicates what's in the Tegra BCT, which is essentially part of the HW itself, since it's handled by the non-modifiable boot ROM code. I really don't think U-Boot should be mandating some data structure that requires duplication of information that's already present.
Hi Stephen,
On Fri, Dec 14, 2012 at 2:03 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/14/2012 02:14 PM, Simon Glass wrote:
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini trini@ti.com wrote: On 12/13/12 16:51, Simon Glass wrote:
[snip]
> And from there we can move on and say "On ${SoC} we get > a device tree (that we can't quite parse as we don't have > enough resources) AND $some-data (OMDATA or an > abbreviated device tree or $whatever), lets translate > that into something we can make use of very early rather > than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that the problem is solved in U-Boot itself with device tree, then:
- It would be nice to keep a single source for this information
so that SPL and U-Boot are consistent. Where we invent a new mechanism for efficiency reasons it would be best if there was a 1-1 mapping from device tree to this new mechanism.
Many (most, I assume) U-Boot builds don't use device tree at all (yet?). I'm not sure we should tie any new mechanism for low-level boot information into device tree, since that severely limits where it can be used.
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon. We found that some of the things we want to know about at the low level are hardware properties that are already sit in a node in the FDT. For example the memory controller may have information about the memory type attached to it.
Given this, my suggestion is that this hardware information be kept in one place (FDT) where possible, even if it unfortunately temporarily needs to be translated into some simpler format as part of the SPL build for efficiency reasons.
As to platforms that support FDT, that is true, only a few. Adding basic support for a new board is very easy though.
But looking at your comments below, I worry that this might be a sledgehammer to crack a nut. As I understand it, you really just have a 32-word which selects the console UART and a few other things. It seems like you solved that problem a few emails back.
- It would be nice if we could write a simple tool which is
generic across architectures and configures an SPL given a device tree file. I'm not sure if that is a problem worth solving or not.
I'm not sure the information is generic enough to even represent in device tree, or that it even makes sense to do so.
After all, what the Tegra ODMDATA2 fields are representing is pinmux setup. Every piece of hardware does pinmux differently; at the very least, the pin IDs and available mux selection options are different. Some SoCs mux pins individually, some in groups. Sometimes more than just mux options must be selected. Some SoCs don't need pinmux. Some SoCs would allow the data to be embedded into some boot flash in a SoC-defined manner, whereas other SoCs' boards might require reading GPIOs, I2C EEPROMs, ... to get the information, etc. All this means that the information required, and the format needed to represent it, really is different in every case. The only way to avoid this would be to retro-actively redesign every SoC and board to always have the same requirements for what data needs to represent the UART selection process, and implement in the same way. That's obviously impossible to do, and so having any kind of remotely generic tool to handle the representation of this data also seems quite impossible.
- From the SPL point of view, the less code required to get at
the information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
A certain amount of that information duplicates what's in the Tegra BCT, which is essentially part of the HW itself, since it's handled by the non-modifiable boot ROM code. I really don't think U-Boot should be mandating some data structure that requires duplication of information that's already present.
No certainly not. But I think Tom is concerned that each SOC will do it differently and we might end up with a mess. SPL configuration is a slightly different problem to what you talk about here, but in a sense the BCT is an SOC-specific binary config blob attached to SPL. Other SOCs might do a similar thing but in their own format and in their own tools. Is it possible to unify these at all? Perhaps not?
Regards, Simon
On 12/14/2012 03:22 PM, Simon Glass wrote:
Hi Stephen,
...
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon.
Sure, but I'm *explicitly* avoiding relying on DT for this, because there are plenty of things that happen before DT can or should be touched that might warrant serial port output.
The kernel has exactly the same kind of feature; log messages can be sent out through an SoC-specific earlyprintk mechanism. In the U-Boot case though, I don't plan on replacing the serial port based on information from DT, but simply setting it up much much earlier via a simpler mechanism.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/14/12 17:45, Stephen Warren wrote:
On 12/14/2012 03:22 PM, Simon Glass wrote:
Hi Stephen,
...
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon.
Sure, but I'm *explicitly* avoiding relying on DT for this, because there are plenty of things that happen before DT can or should be touched that might warrant serial port output.
Also totally true and valid. But what I'd like to see is: parse_odmdata(void *ptr) { if (ptr->console) device_tree_register_uart(... fake it ...); }
In other words, if we add the register a port call now, there's a history of adding just one more thing, by someone else (say am335x and our EVMs that differ on where primary UART is, and only need a little different logic to say 'oh! this one.') and making a mess of things. Once we deal with device trees in some manner, then we can just fake their existence at this point and pass in the console information from ODMDATA.
- -- Tom
On 12/17/2012 02:09 PM, Tom Rini wrote:
On 12/14/12 17:45, Stephen Warren wrote:
On 12/14/2012 03:22 PM, Simon Glass wrote:
Hi Stephen,
...
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon.
Sure, but I'm *explicitly* avoiding relying on DT for this, because there are plenty of things that happen before DT can or should be touched that might warrant serial port output.
Also totally true and valid. But what I'd like to see is: parse_odmdata(void *ptr) { if (ptr->console) device_tree_register_uart(... fake it ...); }
Sorry, I'm having a hard time parsing:
In other words, if we add the register a port call now, there's a
By "register a port call", do you mean the device_tree_register_uart() you're proposing above, or the NS16550_set_dynamic_address() I'd implemented in my patch?
Below, you appear to be pointing out problems with adding the "register a port call now" which seems like you're arguing against your own example?
history of adding just one more thing, by someone else (say am335x and our EVMs that differ on where primary UART is, and only need a little different logic to say 'oh! this one.') and making a mess of things.
Once we deal with device trees in some manner, then we can just fake their existence at this point and pass in the console information from ODMDATA.
There are many ways besides device tree to enumerate hardware. For example, consider PCI or USB (albeit USB isn't memory mapped). I don't think we should tie any new U-Boot dynamic device registration API to device tree, since that would seem to prevent (or imply against) usage of that API with PCI for example.
Perhaps this is just bike-shedding over naming?
So, perhaps:
int device_register_uart(enum uart_type, u32 base_address)
So that all of the following cases could call that:
* DT parsing. * PCI device enumeration. * ODMDATA parsing.
(and where enum uart_type is some internal U-Boot identifier for the UART drivers it supports)
Presumably the implementation would validate if the (uart_type, base_address) combination had been seen already, and then do nothing. that would allow for ODMDATA parsing to set up the UART, and then DT parsing to avoid any special cases to skip handling DT nodes for serial devices that were already registered.
Dear Stephen Warren,
In message 50CF9BAA.3050504@wwwdotorg.org you wrote:
There are many ways besides device tree to enumerate hardware. For example, consider PCI or USB (albeit USB isn't memory mapped). I don't
Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that.
think we should tie any new U-Boot dynamic device registration API to device tree, since that would seem to prevent (or imply against) usage of that API with PCI for example.
Not any dynamic device registration. But here, it actually AIN'T dynamic - it is fully static, just board dependent.
Perhaps this is just bike-shedding over naming?
No.
So that all of the following cases could call that:
- DT parsing.
- PCI device enumeration.
- ODMDATA parsing.
NAK. This is totally wrong. ODMDATA is just a different representation of information that could as well be encoded in a DT. PCI or USB bus scanning gives information which cannot be encoded in a DT passed to U-Boot (at least not unless you dynamically generate that DT using some other softeware performing such a bus scan).
Best regards,
Wolfgang Denk
On 12/17/2012 03:37 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CF9BAA.3050504@wwwdotorg.org you wrote:
There are many ways besides device tree to enumerate hardware. For example, consider PCI or USB (albeit USB isn't memory mapped). I don't
Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that.
I honestly don't know why you couldn't have a PCI-based console UART.
think we should tie any new U-Boot dynamic device registration API to device tree, since that would seem to prevent (or imply against) usage of that API with PCI for example.
Not any dynamic device registration. But here, it actually AIN'T dynamic - it is fully static, just board dependent.
If you want to run the same U-Boot binary on multiple different boards, then that does make the UART selection dynamic. There's no conceptual difference between dynamic information coming from a DT passed to U-Boot at runtime, SoC-defined enumeration/selection mechanisms such as Tegra's ODMDATA, or scanning a PCI bus.
Or, is U-Boot going to ban addressing TI's case where the UART selection is stored in an I2C EEPROM that can be read at run-time, since instead during flashing that information could be extracted and hard-coded into the board's device tree instead?
Dear Stephen,
In message 50CFA394.40901@wwwdotorg.org you wrote:
Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that.
I honestly don't know why you couldn't have a PCI-based console UART.
This is actually another question.
You cannot compare a statically configured UART port (where all configuration information you need is the index into the table of possible UARTs) to a dynamic bus scan where you cannot know in advance whether you detect any devices at all, or how many, or which types.
You will have hard times using a PCI or USB based console port for early console output because the majority of the PCI and USB related code will only be runnable after relocation.
Not any dynamic device registration. But here, it actually AIN'T dynamic - it is fully static, just board dependent.
If you want to run the same U-Boot binary on multiple different boards, then that does make the UART selection dynamic. There's no conceptual difference between dynamic information coming from a DT passed to U-Boot at runtime, SoC-defined enumeration/selection mechanisms such as Tegra's ODMDATA, or scanning a PCI bus.
Maybe there is no conceptual difference - but only if you chose to look at things at a relatively high abstraction level.
Implementation-wise the difference it between passing a single integer variable (the UART index) and performing a dynamic bus scan, detecting number and type of devices and selecting appropriate drivers.
Or, is U-Boot going to ban addressing TI's case where the UART selection is stored in an I2C EEPROM that can be read at run-time, since instead during flashing that information could be extracted and hard-coded into the board's device tree instead?
Here again we are talking about a UART, which is statically confgured per board, and we just need this specific piece of board information.
And yes, this piece of information should be encoded in the device tree. Note that the "hard-coded" you mantion has never been made a requirement. For simplicity of design it might make sense to actually use the DT format for such information right away. But as your own example shows, not all chip / board vendors do that. Simon and Tom already commented on what to do in such situations.
It seems Simon, Tom and me mostly agree on what to do.
Best regards,
Wolfgang Denk
On 12/17/2012 11:39 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 50CFA394.40901@wwwdotorg.org you wrote:
Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that.
I honestly don't know why you couldn't have a PCI-based console UART.
This is actually another question.
You cannot compare a statically configured UART port (where all configuration information you need is the index into the table of possible UARTs)
That's not the only piece of information that is required. At least on Tegra (and I imagine on most SoCs with a pinmux) you need to fully describe the UART-related pinmux programming, so that the UART signals actually get routed out of the SoC.
to a dynamic bus scan where you cannot know in advance whether you detect any devices at all, or how many, or which types.
A board could have a PCI UART soldered onto the board, and hence be physically static and known ahead of time, yet still require (at least part of) the PCI bus to be correctly probed and programmed.
It seems Simon, Tom and me mostly agree on what to do.
To be honest, that's not remotely the impression I get.
Hi Stephen,
On Tue, Dec 18, 2012 at 8:37 AM, Stephen Warren swarren@wwwdotorg.orgwrote:
On 12/17/2012 11:39 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 50CFA394.40901@wwwdotorg.org you wrote:
Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that.
I honestly don't know why you couldn't have a PCI-based console UART.
This is actually another question.
You cannot compare a statically configured UART port (where all configuration information you need is the index into the table of possible UARTs)
That's not the only piece of information that is required. At least on Tegra (and I imagine on most SoCs with a pinmux) you need to fully describe the UART-related pinmux programming, so that the UART signals actually get routed out of the SoC.
Is that information in the ODM data also? I thought ODM data was just a 32-bit word with a UART number in it. It seemed equivalent to the console alias to me.
to a dynamic bus scan where you cannot know in advance whether you detect any devices at all, or how many, or which types.
A board could have a PCI UART soldered onto the board, and hence be physically static and known ahead of time, yet still require (at least part of) the PCI bus to be correctly probed and programmed.
It seems Simon, Tom and me mostly agree on what to do.
To be honest, that's not remotely the impression I get.
Well anyway, to your problem, we did in fact have the Chromium tree working with an FDT. This is available very early (before console_init_f()) so it was no trouble to get the information from there. Two of the devices we booting on had different console UARTs, and we just changed the alias property to deal with that: serial = "/serial@xxx", or serial = "/serial@yyy". We didn't use ODM data to select the console (perhaps because we didn't know about this feature).
I believe with Tegra the ODM data is more useful, so there is an overlap between some of the fields in ODM data (and perhaps BCT) and FDT. That's why I suggested something like a setting in the FDT to say that the console UART number comes from ODM data. I'm not sure how to specify that with an alias.
Regards, Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/14/12 17:22, Simon Glass wrote:
[snip]
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon. We found that some of the things we want to know about at the low level are hardware properties that are already sit in a node in the FDT. For example the memory controller may have information about the memory type attached to it.
Given this, my suggestion is that this hardware information be kept in one place (FDT) where possible, even if it unfortunately temporarily needs to be translated into some simpler format as part of the SPL build for efficiency reasons.
Exactly. The fewer places we have to write down the details the better.
- -- Tom
Dear Stephen Warren,
In message 50CBA217.3070202@wwwdotorg.org you wrote:
Many (most, I assume) U-Boot builds don't use device tree at all (yet?). I'm not sure we should tie any new mechanism for low-level boot information into device tree, since that severely limits where it can be used.
We're talking about ways to pass hardware cosnfiguration information to the boot loader. From the software engineering point of view, there should be just one implementation for this feature, which is then used everywhere. The de-factor satndard for this functionaity is the device tree. Which means that any other approaches either need very strong reasons to exist, or should be adapted.
I'm not sure the information is generic enough to even represent in device tree, or that it even makes sense to do so.
The DT is as good a place for such information as any other.
A certain amount of that information duplicates what's in the Tegra BCT, which is essentially part of the HW itself, since it's handled by
There is more SoCs around than just Tegra, and a solution that fits all is definitely better than everybody implementing hos own private thingy.
Best regards,
Wolfgang Denk
On 12/14/2012 01:40 PM, Tom Rini wrote:
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
That's certainly true.
I personally view the method of retrieving this kind of information as part of an SoC's boot architecture, or as part of a board's design. As you have mentioned above, different SoCs/boards already have mechanisms to represent/determine this information. These mechanisms are already in-place and defined by the SoC or board designers.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
I don't understand why you think U-Boot is in a position to mandate that the existing solutions that are already in place are incorrect, and must be replaced with some alternative.
Dear Stephen Warren,
In message 50CB9F9F.5010402@wwwdotorg.org you wrote:
I don't understand why you think U-Boot is in a position to mandate that the existing solutions that are already in place are incorrect, and must be replaced with some alternative.
There will always be times when common agreement on a new, superior solution will enforce adaption of the existing implementations, or they will break and drop out of mainline.
I don't claim this is such a case, but it could well be so.
Best regards,
Wolfgang Denk
Dear Tom Rini,
In message 50CB8ED1.7020503@ti.com you wrote:
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
ACK!
And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 15/12/12 09:26, Wolfgang Denk wrote:
Dear Tom Rini,
In message 50CB8ED1.7020503@ti.com you wrote:
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
ACK!
And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully.
I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format).
The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)?
But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT)
Am I understanding this right?
Regards,
Graeme
Dear Graeme Russ,
In message 50CBB346.30208@gmail.com you wrote:
And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully.
I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format).
Yes, this may, and will, happen. And we will have to support it. The question is, how to do that. I definitely do not want to see any uncontrolled growth of more and more such board or SoC specific code.
The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot
We cannot dictate, but we can encourage and discourage such decisions. If we communicate a clear position, we may even prevent ugly things from happening.
instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)?
Do you want to see each board grow it's own code to do that? Because this is the extreme that could result from such a decision, and I seriously dislike any such thought. Which is why I'm questioning the general approach when I see it first.
But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT)
Why do we have to support such dynamic hardware configuration for a very basic thing as the console port at all?
If the hardware designers cannot fix their minds and use a fixed console port, they should be willing to suffer fromthe penalty that they will have to use board specific board configurations that match the actual consoles settings. Why should we bend and do ugly stuff? Just because software is so much easier to change than hardware? I'm not going to buy this argument.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 15/12/12 11:32, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 50CBB346.30208@gmail.com you wrote:
And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully.
I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format).
Yes, this may, and will, happen. And we will have to support it. The question is, how to do that. I definitely do not want to see any uncontrolled growth of more and more such board or SoC specific code.
The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot
We cannot dictate, but we can encourage and discourage such decisions. If we communicate a clear position, we may even prevent ugly things from happening.
Understood, but in the end, board and SoC vendors will do what is most expedient for them, and that may well be a raw binary data format buried in some reserved ROM area (either on-time-writable or EEPROM)
instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)?
Do you want to see each board grow it's own code to do that? Because this is the extreme that could result from such a decision, and I seriously dislike any such thought. Which is why I'm questioning the general approach when I see it first.
Well if the SoC or board (but more likely SoC) has already defined the data structure, you a bit stuck. I fully agree that board developers that choose U-Boot as their primary bootloader should be following U-Boot conventions.
But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT)
Why do we have to support such dynamic hardware configuration for a very basic thing as the console port at all?
You may not find as much in consumer devices (set-top-boxes, mobile phones, tablets etc.) but you will in industrial devices.
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.
If the hardware designers cannot fix their minds and use a fixed console port, they should be willing to suffer fromthe penalty that they will have to use board specific board configurations that match the actual consoles settings. Why should we bend and do ugly stuff? Just because software is so much easier to change than hardware? I'm not going to buy this argument.
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
Regards,
Graeme
Dear Graeme Russ,
In message 50CBD313.60508@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 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.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Dec 15, 2012 6:30 PM, "Wolfgang Denk" wd@denx.de wrote:
Dear Graeme Russ,
In message 50CBD313.60508@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/14/12 17:26, Wolfgang Denk wrote:
Dear Tom Rini,
In message 50CB8ED1.7020503@ti.com you wrote:
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
ACK!
And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully.
Exactly. We are not yet making as much use of the device tree as we can/should, which is where at least part of the hurdle is.
- -- Tom
Dear Stephen Warren,
In message 50CA3E7A.8020407@wwwdotorg.org you wrote:
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
What I mean is: there have been a number of times before when we decided to do something more or less ugly because it appeared to be the easiest / fastest / most simple approacht at that time,and we were sure we would it need for this one special case only. Then it gor reused, and again, and it spread...
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Which exact parts would be global?
I am aware that the capability to set the UART is obviously part of the global code.
But the actual implementation of such setting would be not global at all, right?
Note that by "all" and "global" here, I'm talking relative to all Tegra SoCs, not about anything non-Tegra. "SoC-specific" means different for Tegra20, Tegra30, Tegra114, etc.
OK.
Note that in the latter case, I haven't pushed out the patches which document the UART pinmux fields yet, but will very soon; most likely as soon as we've resolved this conversation.
You guarantee that this all will remain strictly within Tegra specific areas, only? And only for the UART?
Best regards,
Wolfgang Denk
On 12/13/2012 04:11 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50CA3E7A.8020407@wwwdotorg.org you wrote:
My intent is that ODMDATA will definitely only be used for the console UART, and will NOT be used for anything else like LCD, RTC, ... Those other devices will certainly be configured via device tree.
We've been there before, you know.
I'm not quite sure what the implication is here.
What I mean is: there have been a number of times before when we decided to do something more or less ugly because it appeared to be the easiest / fastest / most simple approacht at that time,and we were sure we would it need for this one special case only. Then it gor reused, and again, and it spread...
OK - what is the scope of visibility of such code? Will it be strictly board specific only? Or SoC specific? Arch? Global?
It's partially SoC-specific, partially global.
Which exact parts would be global?
I guess by global you meant for any SoC/CPU/... U-Boot supports, whereas I was treating global as across all Tegras.
So given that, the only global part would be the NS16550 patch I sent out already. Anything else would be contained entirely within the Tegra common board file.
I am aware that the capability to set the UART is obviously part of the global code.
Right.
But the actual implementation of such setting would be not global at all, right?
Right; it'd be part of that Tegra common board.c file, shared by all Tegra boards, but should have zero impact outside any Tegra-specific code.
Note that by "all" and "global" here, I'm talking relative to all Tegra SoCs, not about anything non-Tegra. "SoC-specific" means different for Tegra20, Tegra30, Tegra114, etc.
OK.
Note that in the latter case, I haven't pushed out the patches which document the UART pinmux fields yet, but will very soon; most likely as soon as we've resolved this conversation.
You guarantee that this all will remain strictly within Tegra specific areas, only? And only for the UART?
Yes. I don't have any intention to use it for anything other than console UART. I don't know of anyone else who wants to use it for anything other than console UART. If anyone else tries to use it for anything else, I'll give review comments not to, and direct them towards device tree.
Of course, I can't predict the future, but that's just science, not my trying to weasel out of a promise.
Dear Stephen Warren,
In message 1355354590-10023-1-git-send-email-swarren@wwwdotorg.org you 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
As is, this is just adding dead code.
Where would the device addresses come from - out of the device tree?
Best regards,
Wolfgang Denk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/12 05:27, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 1355354590-10023-1-git-send-email-swarren@wwwdotorg.org you 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
As is, this is just adding dead code.
Where would the device addresses come from - out of the device tree?
Board specific knowledge. I'd be tempted to add UART3 (iirc) into the am335x_evm default build so that we can support the Industrial DevKit variant out of the box, rather than needing one of the other _uartN builds. We can tell which board we're on at run-time already.
- -- Tom
Dear Tom Rini,
In message 50C9D41B.7010800@ti.com you wrote:
Where would the device addresses come from - out of the device tree?
Board specific knowledge. I'd be tempted to add UART3 (iirc) into the am335x_evm default build so that we can support the Industrial DevKit variant out of the box, rather than needing one of the other _uartN builds. We can tell which board we're on at run-time already.
I'm afraid this doesn't scale. You are opening a can of worms here. The UART port may seem simple enough, but you set a precedent. Next comes some netowrk interface configuration, then if we have a RTC, followed by LCD properties, and so on.
We have two ways to configure hardware properties: - static configuration in the board config file - dynamic configuration through the device tree
Please do not start adding other methods.
Best regards,
Wolfgang Denk
participants (5)
-
Graeme Russ -
Simon Glass -
Stephen Warren -
Tom Rini -
Wolfgang Denk