[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org --- Tom, this patch applies on top of u-boot-tegra/master, with the top 4 commits removed and replaced with Simon's latest putc series from last night.
Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to remove the uart_ids parameter and simply call get_uart_ids() internally?
BTW, it seems inconsistent to have all the Tegra code key off CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off CONFIG_SYS_NS16550_COM*. Can the two be unified somehow?
arch/arm/cpu/armv7/tegra2/board.c | 31 +++++++++++++++++++++++++++++-- 1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/board.c b/arch/arm/cpu/armv7/tegra2/board.c index c7ea96b..27831f3 100644 --- a/arch/arm/cpu/armv7/tegra2/board.c +++ b/arch/arm/cpu/armv7/tegra2/board.c @@ -115,7 +115,7 @@ void tegra_setup_uarts(int uart_ids) } }
-void board_init_uart_f(void) +static int get_uart_ids(void) { int uart_ids = 0; /* bit mask of which UART ids to enable */
@@ -128,7 +128,13 @@ void board_init_uart_f(void) #ifdef CONFIG_TEGRA2_ENABLE_UARTD uart_ids |= TEGRA_UARTD; #endif - tegra_setup_uarts(uart_ids); + + return uart_ids; +} + +void board_init_uart_f(void) +{ + tegra_setup_uarts(get_uart_ids()); }
#ifndef CONFIG_SYS_DCACHE_OFF @@ -150,6 +156,27 @@ static const u32 uart_reg_addr[TEGRA_UART_COUNT] = { NV_PA_APB_UARTD_BASE, };
+void arch_preboot_os(void) +{ + int uart_ids, i; + + /* + * The Linux kernel earlyprintk code detects which UART to use by + * searching for one with 'D' in the UART scratch register. This + * is set up here. + */ + uart_ids = get_uart_ids(); + + for (i = 0; i < TEGRA_UART_COUNT; i++) { + if (uart_ids & (1 << i)) { + NS16550_t regs = (NS16550_t)uart_reg_addr[i]; + if (!regs) + continue; + writeb('D', ®s->spr); + } + } +} + void tegra_pre_console_panic(int uart_ids, unsigned clock_freq, unsigned multiplier, const char *str) {
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
Tom, this patch applies on top of u-boot-tegra/master, with the top 4 commits removed and replaced with Simon's latest putc series from last night.
Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to remove the uart_ids parameter and simply call get_uart_ids() internally?
I can't help thinking there is a bit of a misunderstanding here. I suspected it from your comments yesterday, so let's try to clear it up.
This patch is intended (I believe) to signal to Linux which UART is used for the earlyprintk console. This is so when U-Boot cannot decompress the kernel (because we are booting a zImage which has its own decompression wrapper) we can print the 'Uncompressing Linux...' message. Is that correct?
If so, what you want to find out here is exactly which UART is being used for the console. It will be a single UART, it will be know for sure, whether the information comes from CONFIG or the device tree.
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*. So the concept of selecting a particular UART and writing out a message is not really good enough. Sure it works on Seaboard, and I adjusted my patch to only use UARTD, but doesn't work on a Seaboard variant where we don't yet have the device tree and so don't know which UART is used for the console. The device tree specifies the console UART - it cannot be known at compile time. The best we can do is specify the possible and legal options.
Please don't get these two things (asking which is the console UART and asking which UARTs could possible be the console) confused - I realise that this is a bit mess. To be clear, the pre-console panic is NOT:
1. Intended to just print a message on the console - that would be easy if we actually knew which was the console; nor
2. Intended as a general-purpose pre-console message output interface - there is already Graeme's pre-console buffer for that.
BTW, it seems inconsistent to have all the Tegra code key off CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off CONFIG_SYS_NS16550_COM*. Can the two be unified somehow?
arch/arm/cpu/armv7/tegra2/board.c | 31 +++++++++++++++++++++++++++++-- 1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/board.c b/arch/arm/cpu/armv7/tegra2/board.c index c7ea96b..27831f3 100644 --- a/arch/arm/cpu/armv7/tegra2/board.c +++ b/arch/arm/cpu/armv7/tegra2/board.c @@ -115,7 +115,7 @@ void tegra_setup_uarts(int uart_ids) } }
-void board_init_uart_f(void) +static int get_uart_ids(void) { int uart_ids = 0; /* bit mask of which UART ids to enable */
@@ -128,7 +128,13 @@ void board_init_uart_f(void) #ifdef CONFIG_TEGRA2_ENABLE_UARTD uart_ids |= TEGRA_UARTD; #endif
- tegra_setup_uarts(uart_ids);
- return uart_ids;
+}
If you want this, then I suggest tegra_get_console_uart_id() might be a better, to avoid confusion. It can just return an enum.
+void board_init_uart_f(void) +{
- tegra_setup_uarts(get_uart_ids());
}
#ifndef CONFIG_SYS_DCACHE_OFF @@ -150,6 +156,27 @@ static const u32 uart_reg_addr[TEGRA_UART_COUNT] = { NV_PA_APB_UARTD_BASE, };
+void arch_preboot_os(void) +{
- int uart_ids, i;
- /*
- * The Linux kernel earlyprintk code detects which UART to use by
- * searching for one with 'D' in the UART scratch register. This
- * is set up here.
- */
- uart_ids = get_uart_ids();
- for (i = 0; i < TEGRA_UART_COUNT; i++) {
I feel there should only be a single UART here. After all, what is Linux supposed to do in early printk if it seems more than one UART?
- if (uart_ids & (1 << i)) {
- NS16550_t regs = (NS16550_t)uart_reg_addr[i];
- if (!regs)
- continue;
- writeb('D', ®s->spr);
- }
- }
+}
void tegra_pre_console_panic(int uart_ids, unsigned clock_freq, unsigned multiplier, const char *str) { -- 1.7.0.4
Regards, Simon
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
Tom, this patch applies on top of u-boot-tegra/master, with the top 4 commits removed and replaced with Simon's latest putc series from last night.
Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to remove the uart_ids parameter and simply call get_uart_ids() internally?
I can't help thinking there is a bit of a misunderstanding here. I suspected it from your comments yesterday, so let's try to clear it up.
It's not so much a misunderstanding as a disagreement over the right direction.
This patch is intended (I believe) to signal to Linux which UART is used for the earlyprintk console. This is so when U-Boot cannot decompress the kernel (because we are booting a zImage which has its own decompression wrapper) we can print the 'Uncompressing Linux...' message. Is that correct?
That's one thing it affects, yes.
It also affects the DEBUG_LL/earlyprintk output, i.e. all the kernel spew (by the kernel itself, not the decompressor) that happens before the real console device is set up.
(When there's no problem and earlyprintk isn't on, this is all buffered up and sent out the console when it appears, but if there's a panic before the console is initialized, you won't see any messages. If earlyprintk is enabled, the messages aren't buffered, but instead sent immediately using the DEBUG_LL mechanism, and this patch is what tells the DEBUG_LL mechanism which UART to use).
If so, what you want to find out here is exactly which UART is being used for the console. It will be a single UART, it will be know for sure, whether the information comes from CONFIG or the device tree.
True, implementing it that way would also be useful. Right now, that's driven by CONFIG_SYS_NS16550_COM*, but can come from DT too.
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
In other words: While other boards may be similar to Seaboard, they are not Seaboard, and we shouldn't be using the Seaboard board file for them. They are different boards that are simply similar in design. But for example, many use a different UART for their debug console - a clear difference in hardware.
For each one of these derived boards, there is a single static UART that should be used, as determined by the board design.
Thus, I argue that there really is no concept of "which UART do we use" *for a given board*.
I think perhaps the way to clear this up is to make the existing Seaboard and Ventana boards NOT be device-tree-driven, but rather be "board-file" driven. Instead of co-opting Seaboard, introduce a new "tegra2dt" board that is purely DT driven. (This is exactly what's been done in the kernel). Then, it would make a lot more sense to talk about there being multiple possible UARTs to use for the console, since the board you build U-Boot for would then explicitly be for multiple boards, rather than hijacking a particular single board file to work on multiple boards. It'd also allow people to boot U-Boot on Seaboard without using DT if they wanted, at the very least as a temporary transition mechanism.
As an aside, for the tegra2dt board, perhaps we should have a single well-known location in the U-Boot binary that contains the "uart_ids" value. This can be initialized to "all UARTs" by default by the code (or perhaps "no UARTs" for safety). As part of the manual post-processing to convert this common u-boot.bin binary to a particular board prior to flashing, one could both (a) append the .dtb file just like is required now (b) patch that well-known location to set the specific UARTs for the panic putc, if desired. "Well known" could perhaps be determined using "nm" and searching for a specific symbol. A helper script could be provided to make this easy. What do you think of this?
So the concept of selecting a particular UART and writing out a message is not really good enough. Sure it works on Seaboard, and I adjusted my patch to only use UARTD, but doesn't work on a Seaboard variant where we don't yet have the device tree and so don't know which UART is used for the console. The device tree specifies the console UART - it cannot be known at compile time. The best we can do is specify the possible and legal options.
Please don't get these two things (asking which is the console UART and asking which UARTs could possible be the console) confused - I realise that this is a bit mess. To be clear, the pre-console panic is NOT:
- Intended to just print a message on the console - that would be
easy if we actually knew which was the console; nor
- Intended as a general-purpose pre-console message output interface
- there is already Graeme's pre-console buffer for that.
BTW, it seems inconsistent to have all the Tegra code key off CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off CONFIG_SYS_NS16550_COM*. Can the two be unified somehow?
Hi Stephen, Simon,
On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
In the 'normal' boot case, the default console should never have any output sent to it (unless it also happens to be the 'configured' console port) as Both U-Boot and Linux will use a pre console buffer to buffer any output prior to the 'configured' console being available
So I think there is a clear evidence that the 'Board panic no console' and 'Specify debugging serial port at boot' are intrinsicly related - Both U-Boot and Linux should be dumping their 'pre-console' messages to the same port and this port should be specified by the hardware designer
So that being the case, there should be a single CONFIG_ option which both patches should be using
Just my 2% of $1.00 ;)
Regards,
Graeme
Hi Graeme,
On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Stephen, Simon,
On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
We can provide that, but if it is wrong for the board we are using, then there will be no output. Stephen's original complaint was a brick if there is no valid device tree. We need this to work!
In the 'normal' boot case, the default console should never have any output sent to it (unless it also happens to be the 'configured' console port) as Both U-Boot and Linux will use a pre console buffer to buffer any output prior to the 'configured' console being available
So I think there is a clear evidence that the 'Board panic no console' and 'Specify debugging serial port at boot' are intrinsicly related - Both U-Boot and Linux should be dumping their 'pre-console' messages to the same port and this port should be specified by the hardware designer
So that being the case, there should be a single CONFIG_ option which both patches should be using
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
If I had time right now I would send out a proper serial fdt patch series - the previous one was just a WIP. But you can see it here:
https://gerrit.chromium.org/gerrit/#change,18257
Just my 2% of $1.00 ;)
Regards,
Graeme
Regards, Simon
Hi Simon,
On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Stephen, Simon,
On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
We can provide that, but if it is wrong for the board we are using, then there will be no output. Stephen's original complaint was a brick if there is no valid device tree. We need this to work!
In the 'normal' boot case, the default console should never have any output sent to it (unless it also happens to be the 'configured' console port) as Both U-Boot and Linux will use a pre console buffer to buffer any output prior to the 'configured' console being available
So I think there is a clear evidence that the 'Board panic no console' and 'Specify debugging serial port at boot' are intrinsicly related - Both U-Boot and Linux should be dumping their 'pre-console' messages to the same port and this port should be specified by the hardware designer
So that being the case, there should be a single CONFIG_ option which both patches should be using
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
But I don't get it - In your Seaboard patch, you only use UARTD so in this case we could CONFIG_ it?
And it's sounding like for other scenarios you are going to resign yourself to there not being a common UART so you will send the pre-console (panic) message to multiple UARTs - something that should be avoided at all costs...
I know we are dealing with a corner case abnormal situation here, but something does not smell right... Maybe I'm not understanding something obvious yet...
Regards,
Graeme
Hi Graeme,
On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Stephen, Simon,
On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
We can provide that, but if it is wrong for the board we are using, then there will be no output. Stephen's original complaint was a brick if there is no valid device tree. We need this to work!
In the 'normal' boot case, the default console should never have any output sent to it (unless it also happens to be the 'configured' console port) as Both U-Boot and Linux will use a pre console buffer to buffer any output prior to the 'configured' console being available
So I think there is a clear evidence that the 'Board panic no console' and 'Specify debugging serial port at boot' are intrinsicly related - Both U-Boot and Linux should be dumping their 'pre-console' messages to the same port and this port should be specified by the hardware designer
So that being the case, there should be a single CONFIG_ option which both patches should be using
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
But I don't get it - In your Seaboard patch, you only use UARTD so in this case we could CONFIG_ it?
Yes, Stephen specifically asked for this so I changed it. See the other ongoing discussion on this.
And it's sounding like for other scenarios you are going to resign yourself to there not being a common UART so you will send the pre-console (panic) message to multiple UARTs - something that should be avoided at all costs...
Of course - we cannot require the board to use a particular UART. The SOCs have various options and different people will make different decisions. Honestly, if we can't deal with UART selection in the device tree, we aren't going to solve the more difficult problems.
I know we are dealing with a corner case abnormal situation here, but something does not smell right... Maybe I'm not understanding something obvious yet...
I'm not sure. I suspect it could be easily explained with an hour at the whiteboard, but it's hard by email.
The requirement is to output a message that the user can see, and we have a selection of UARTs which *might* be the console UART. For now we don't know exactly which one it is (see my SPL config comment though which might eventually solve this). So we send output to several of them. To protect against any danger, we permit the board file to select which are permitted.
Regards, Simon
Regards,
Graeme
Hi Simon,
On Wed, Mar 21, 2012 at 11:02 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass sjg@chromium.org wrote:
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
But I don't get it - In your Seaboard patch, you only use UARTD so in this case we could CONFIG_ it?
Yes, Stephen specifically asked for this so I changed it. See the other ongoing discussion on this.
And it's sounding like for other scenarios you are going to resign yourself to there not being a common UART so you will send the pre-console (panic) message to multiple UARTs - something that should be avoided at all costs...
Of course - we cannot require the board to use a particular UART. The SOCs have various options and different people will make different decisions. Honestly, if we can't deal with UART selection in the device tree, we aren't going to solve the more difficult problems.
But aren't we dealing in a case where the device tree is probably not available anyway?
And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards.
I know we are dealing with a corner case abnormal situation here, but something does not smell right... Maybe I'm not understanding something obvious yet...
I'm not sure. I suspect it could be easily explained with an hour at the whiteboard, but it's hard by email.
The requirement is to output a message that the user can see, and we have a selection of UARTs which *might* be the console UART. For now we don't know exactly which one it is (see my SPL config comment though which might eventually solve this). So we send output to several of them. To protect against any danger, we permit the board file to select which are permitted.
Again, we are going back to per-board configurations - Why can't this selection be CONFIG_'d? Surely we could define a bitmap of available UARTs in a SoC header (and reserve space for board specific UARTs) which can then be used in the board config.
I'm not really seeing an example of where two boards use exactly the same configuration file and yet one has 'UARTx' plumbed and the other does not
Sorry, I'm not trying to be difficult, just poking all the corners to see what squishes ;)
Regards,
Graeme
Hi Graeme,
On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Mar 21, 2012 at 11:02 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass sjg@chromium.org wrote:
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
But I don't get it - In your Seaboard patch, you only use UARTD so in this case we could CONFIG_ it?
Yes, Stephen specifically asked for this so I changed it. See the other ongoing discussion on this.
And it's sounding like for other scenarios you are going to resign yourself to there not being a common UART so you will send the pre-console (panic) message to multiple UARTs - something that should be avoided at all costs...
Of course - we cannot require the board to use a particular UART. The SOCs have various options and different people will make different decisions. Honestly, if we can't deal with UART selection in the device tree, we aren't going to solve the more difficult problems.
But aren't we dealing in a case where the device tree is probably not available anyway?
Yes.
And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards.
Nope. There is only one u-boot.bin for all boards that use this SOC.
I know we are dealing with a corner case abnormal situation here, but something does not smell right... Maybe I'm not understanding something obvious yet...
I'm not sure. I suspect it could be easily explained with an hour at the whiteboard, but it's hard by email.
The requirement is to output a message that the user can see, and we have a selection of UARTs which *might* be the console UART. For now we don't know exactly which one it is (see my SPL config comment though which might eventually solve this). So we send output to several of them. To protect against any danger, we permit the board file to select which are permitted.
Again, we are going back to per-board configurations - Why can't this selection be CONFIG_'d? Surely we could define a bitmap of available UARTs in a SoC header (and reserve space for board specific UARTs) which can then be used in the board config.
I'm not really seeing an example of where two boards use exactly the same configuration file and yet one has 'UARTx' plumbed and the other does not
Sorry, I'm not trying to be difficult, just poking all the corners to see what squishes ;)
The key point is that they all have the same CONFIG and there is only one u-boot.bin. Once you understand that, the problem will become clearer.
Regards, Simon
Regards,
Graeme
Hi Simon
On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards.
Nope. There is only one u-boot.bin for all boards that use this SOC.
And this is what I simply don't grok - Why have a single board config for a range of boards that are obviously different?
I suppose I haven't dealt with device tree and I imagine that is what this is all about. But to me, device trees are a construct for a higher level of operation (the OS) not the boot loader (although I get that the boot loader can parse the device tree in order to pick up what devices are installed and need some kind of low-level initialisation)
I think at such a low level you really have to say 'hey, these boards are different and need a different configuration' unless you put something in hardware that allows U-Boot to pick up on the difference without needing to initialise _anything_ similar to what Stephen has done to pass the debug UART info to Linux via a scratch register
Regards,
Graeme
Hi Graeme,
On Tue, Mar 20, 2012 at 5:39 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards.
Nope. There is only one u-boot.bin for all boards that use this SOC.
And this is what I simply don't grok - Why have a single board config for a range of boards that are obviously different?
That's the design goal - a single U-Boot binary for all boards that use a particular SOC.
I suppose I haven't dealt with device tree and I imagine that is what this is all about. But to me, device trees are a construct for a higher level of operation (the OS) not the boot loader (although I get that the boot loader can parse the device tree in order to pick up what devices are installed and need some kind of low-level initialisation)
Actually a device tree describes the hardware, and therefore should in principle be just as applicable to the boot loader.
I think at such a low level you really have to say 'hey, these boards are different and need a different configuration' unless you put something in hardware that allows U-Boot to pick up on the difference without needing to initialise _anything_ similar to what Stephen has done to pass the debug UART info to Linux via a scratch register
Well we could do that, but the config is in some sense supposed to be the device tree. We are only dealing here with a little case where there is no device tree and want to output a message.
Regards, Simon
Regards,
Graeme
Hi Stehpen,
On Wed, Mar 21, 2012 at 12:18 PM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 5:39 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards.
Nope. There is only one u-boot.bin for all boards that use this SOC.
And this is what I simply don't grok - Why have a single board config for a range of boards that are obviously different?
That's the design goal - a single U-Boot binary for all boards that use a particular SOC.
I suppose I haven't dealt with device tree and I imagine that is what this is all about. But to me, device trees are a construct for a higher level of operation (the OS) not the boot loader (although I get that the boot loader can parse the device tree in order to pick up what devices are installed and need some kind of low-level initialisation)
Actually a device tree describes the hardware, and therefore should in principle be just as applicable to the boot loader.
I think at such a low level you really have to say 'hey, these boards are different and need a different configuration' unless you put something in hardware that allows U-Boot to pick up on the difference without needing to initialise _anything_ similar to what Stephen has done to pass the debug UART info to Linux via a scratch register
Well we could do that, but the config is in some sense supposed to be the device tree. We are only dealing here with a little case where there is no device tree and want to output a message.
Exactly - Your goal is to create a board configuration which has no concept of the true physical nature of the board and for that true nature to be provided in a configuration file. The configuration file may or may not be valid and if it isn't, you have no idea how to tell the user. Worse, if it is valid but something else happens which means it cannot be loaded then, again, you cannot tell the user what went wrong gracefully
The idea of having a last resort backup plan to spit out a diagnostic message is good, but I think the implementation fallls short of the mark here (I'm actually talking about Simon's patch - this 'mark one port for Linux to use as a fall-back' is, IMHO, pretty neat)
Quite honestly, all boards which use the same UART to output the panic message can have the same U-Boot binary. If two boards use differing ports for the panic message, then they really need to be using different U-Boot binaries unless you have a physical configuration (a jumper for example) which can be detected without any other initialisation
Another option maybe is to read the serial port when 'panic' mode is entered - Cycle through all ports (changing BAUD rate if need be) and if you pick up a preset character, dump the panic message to that port - You could even use the hardware lines (like RI if available) as an additional check
Regards,
Graeme
On 03/20/2012 05:33 PM, Simon Glass wrote: ...
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
I don't agree that all the boards have the same U-Boot binary. At present, there are about 6 Tegra boards in mainline U-Boot all with different binaries.
Even with DT, I don't see anything wrong with having the low-level init code parameterized and built per board (e.g. debug UART), but all the higher level devices initialized/configured from device tree (e.g. I2C, MMC, USB).
Even if the binary result from the boot process is identical, but we did something like I proposed a few emails back to inject the correct UART ID into an initially common binary, you still get left with different binaries per board, in terms of what you're actually flashing onto the board.
(yes, I'd be interested in seeing the SPL code you mentioned)
Hi Stephen,
On Tue, Mar 20, 2012 at 5:42 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 05:33 PM, Simon Glass wrote: ...
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
I don't agree that all the boards have the same U-Boot binary. At present, there are about 6 Tegra boards in mainline U-Boot all with different binaries.
Er, I was referring to all the boards that use the same config, not all the boards in mainline U-Boot. However I agree that we currently have 6 boards, we could fairly easily change this into one board with a device tree selector.
Even with DT, I don't see anything wrong with having the low-level init code parameterized and built per board (e.g. debug UART), but all the higher level devices initialized/configured from device tree (e.g. I2C, MMC, USB).
It doesn't achieve the design goal I mentioned, but yes this is possible.
Even if the binary result from the boot process is identical, but we did something like I proposed a few emails back to inject the correct UART ID into an initially common binary, you still get left with different binaries per board, in terms of what you're actually flashing onto the board.
(yes, I'd be interested in seeing the SPL code you mentioned)
OK. Let me know if we are on the same page on this topic, and I will start a new thread...
Regards, Simon
Dear Simon Glass,
In message CAPnjgZ0jYpHSNG354=f4mDVJ0TT5-6jDCxpEG1Y70v5dwbYxkQ@mail.gmail.com you wrote:
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
We can provide that, but if it is wrong for the board we are using,
Then your board configuration is wrong and needs to be fixed.
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
This is conceptually broken.
If you cannot define a common UART port as debug console, and if there is no other way to find out what the console port should be (*), you must either use static board-specific configuration, or you must accept the fact that there is no console output in certain error situations.
The longer I read about this the less I feel willing to accept warts in the code trying to handle this.
This Tegra code is starting to annoy me.
We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap.
We have a pretty clean concept of dealing with console output for more a decade. Everybody uses it, without any significant problems. The Tegra comes and submits more and more obscure code to fix it's home-made problems.
I don't want to have that. I got better things to do than reading these patches again and again. I don't even see that we are converging on some acceptable solution.
To bring this to a constructive end:
It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works).
OK, there is still a chance that the environment settings are missing or incorrect _and_ the DT cannot be loaded, but the probability for such a double-fault is much, much smaller.
Could this be an acceptable solution for you?
Best regards,
Wolfgang Denk
Hi Stephen, Wolfgang,
On 03/21/2012 08:38 PM, Wolfgang Denk wrote:
Dear Simon Glass,
In message CAPnjgZ0jYpHSNG354=f4mDVJ0TT5-6jDCxpEG1Y70v5dwbYxkQ@mail.gmail.com you wrote:
We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap.
This made me look into the x86 code - There is a command line option 'earlyprintk' which is available stupidly early (even the real-mode code and de-compressor have access to it)
So I do now wonder why Tegra needs to do anything differently
Regards,
Graeme
On 03/21/2012 04:35 AM, Graeme Russ wrote:
Hi Stephen, Wolfgang,
On 03/21/2012 08:38 PM, Wolfgang Denk wrote:
Dear Simon Glass,
In message CAPnjgZ0jYpHSNG354=f4mDVJ0TT5-6jDCxpEG1Y70v5dwbYxkQ@mail.gmail.com you wrote:
We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap.
This made me look into the x86 code - There is a command line option 'earlyprintk' which is available stupidly early (even the real-mode code and de-compressor have access to it)
So I do now wonder why Tegra needs to do anything differently
I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument.
I doubt it will be possible to do this in the ARM zImage decompressor though.
Perhaps the kernel should follow these rules:
If the kernel .config specifies a UART to output the early messages to, then we use that by default (both for the zImage decompressor and earlyprintk if enabled). This option can already include "none" which would be safe across arbitary boards as a default.
The zImage decompressor will always use that UART. If there are issues in the decompressor, rebuild the kernel for the specific UART for the board being tested to see the error spew.
The kernel proper will parse any earlyprintk argument, and override the UART specified in .config if an earlyprintk argument is present.
This makes debugging zImage decmopressor issues slightly more annoying, but (a) we'll probably have to do something like this for multi-SoC kernel images anyway, and (b) zImage decompressor issues are quite rate.
I suppose we could apply the same approach to U-Boot too: Have the U-Boot configuration specify a UART to use for the console, which would have to be "none" by default for maximum safety in a multi-board U-Boot (build) config, but could be the single correct one for a single-board U-Boot config. Then, replace this console with the one from DT once DT is parsed.
This would again make debugging a multi-board U-Boot config's boot hang more annoying, since you'd have to rebuild in order to set a specific "early" UART for the console, but at least it'd be possible.
Then, we just have to make sure that this "early" console is always available before any panic due to missing DT, so that problem would at least be discoverable after setting the UART to use. Hopefully this "early" console would be registered early enough that there are very very few things that can fail before it...
Tom/Simon: Does the U-Boot side of this sound acceptable to you?
Hi Stephen,
On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 04:35 AM, Graeme Russ wrote:
Hi Stephen, Wolfgang,
On 03/21/2012 08:38 PM, Wolfgang Denk wrote:
Dear Simon Glass,
In message CAPnjgZ0jYpHSNG354=f4mDVJ0TT5-6jDCxpEG1Y70v5dwbYxkQ@mail.gmail.com you wrote:
We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap.
This made me look into the x86 code - There is a command line option 'earlyprintk' which is available stupidly early (even the real-mode code and de-compressor have access to it)
So I do now wonder why Tegra needs to do anything differently
I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument.
I doubt it will be possible to do this in the ARM zImage decompressor though.
Perhaps the kernel should follow these rules:
If the kernel .config specifies a UART to output the early messages to, then we use that by default (both for the zImage decompressor and earlyprintk if enabled). This option can already include "none" which would be safe across arbitary boards as a default.
The zImage decompressor will always use that UART. If there are issues in the decompressor, rebuild the kernel for the specific UART for the board being tested to see the error spew.
The kernel proper will parse any earlyprintk argument, and override the UART specified in .config if an earlyprintk argument is present.
This makes debugging zImage decmopressor issues slightly more annoying, but (a) we'll probably have to do something like this for multi-SoC kernel images anyway, and (b) zImage decompressor issues are quite rate.
I suppose we could apply the same approach to U-Boot too: Have the U-Boot configuration specify a UART to use for the console, which would have to be "none" by default for maximum safety in a multi-board U-Boot (build) config, but could be the single correct one for a single-board U-Boot config. Then, replace this console with the one from DT once DT is parsed.
This would again make debugging a multi-board U-Boot config's boot hang more annoying, since you'd have to rebuild in order to set a specific "early" UART for the console, but at least it'd be possible.
Then, we just have to make sure that this "early" console is always available before any panic due to missing DT, so that problem would at least be discoverable after setting the UART to use. Hopefully this "early" console would be registered early enough that there are very very few things that can fail before it...
Tom/Simon: Does the U-Boot side of this sound acceptable to you?
1. I think we have agreed that we cannot and will not (at least for now) solve the problem of trying to get a message to the user during a panic() when we don't even know the console UART.
2. Given (1), it seems reasonable to allow the board config to select an 'early console UART' (which may be NONE) for use for very early panics in U-Boot. If this is not set, or set incorrectly, then no output will be visible.
3. What you propose is actually very easy to implement - it just requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
So yes, I think it is acceptable.
[[[ If I may comment on the Linux side, I think it is worth at least checking whether it is possible to find the UART in the zImage decompressor using the earlyprintk=... setting. It would solve the problem of this patch at least. Even if we need to just look at the number at the end of the setting and use that UART number :-( ]]]
Regards, Simon
On 03/21/2012 10:59 AM, Simon Glass wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option?
Hi Stephen,
On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 10:59 AM, Simon Glass wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option?
These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used.
Regards, Simon
On 03/21/2012 11:13 AM, Simon Glass wrote:
Hi Stephen,
On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 10:59 AM, Simon Glass wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option?
These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used.
Oh.
But in u-boot-tegra/master, both Seaboard and Ventana still set those options even though they have CONFIG_OF_CONTROL turned on. And it looks like board_init_uart_f() both uses those defines irrespective of CONFIG_OF_CONTROL /and/ is called solely based on CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined for Seaboard and Ventana.
I thought the upshot of this discussion was that there wasn't any need for any kind of pre-console stuff, either putc, puts/printf or whatever; instead, the console should simply be registered as early as possible based on the board/config's UART selection?
(and of course the DT parsed after that console was registered; no need for it before)
Hi Stephen,
On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 11:13 AM, Simon Glass wrote:
Hi Stephen,
On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 10:59 AM, Simon Glass wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option?
These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used.
Oh.
But in u-boot-tegra/master, both Seaboard and Ventana still set those options even though they have CONFIG_OF_CONTROL turned on. And it looks like board_init_uart_f() both uses those defines irrespective of CONFIG_OF_CONTROL /and/ is called solely based on CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined for Seaboard and Ventana.
Yes that's true. I have not yet prepared an upstream patch to fix this. I will get to this one we have USB/I2C in, but in the meantime, this series will probably nearly apply. The third patch is the main event.
https://gerrit.chromium.org/gerrit/#change,18256 https://gerrit.chromium.org/gerrit/#change,18255 https://gerrit.chromium.org/gerrit/#change,18257 https://gerrit.chromium.org/gerrit/#change,18259
I thought the upshot of this discussion was that there wasn't any need for any kind of pre-console stuff, either putc, puts/printf or whatever; instead, the console should simply be registered as early as possible based on the board/config's UART selection?
Not quite - going back to your previous message, if there is a panic before the console is ready (and in the event of there being no fdt) I would like to offer a message on a UART selected by a CONFIG.
(and of course the DT parsed after that console was registered; no need for it before)
The DT must be parsed before the console is registered - after all the DT tells us which is the console.
Regards, Simon
On 03/21/2012 11:50 AM, Simon Glass wrote:
Hi Stephen,
On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 11:13 AM, Simon Glass wrote:
Hi Stephen,
On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/21/2012 10:59 AM, Simon Glass wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option?
These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used.
Oh.
But in u-boot-tegra/master, both Seaboard and Ventana still set those options even though they have CONFIG_OF_CONTROL turned on. And it looks like board_init_uart_f() both uses those defines irrespective of CONFIG_OF_CONTROL /and/ is called solely based on CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined for Seaboard and Ventana.
Yes that's true. I have not yet prepared an upstream patch to fix this. I will get to this one we have USB/I2C in, but in the meantime, this series will probably nearly apply. The third patch is the main event.
https://gerrit.chromium.org/gerrit/#change,18256 https://gerrit.chromium.org/gerrit/#change,18255 https://gerrit.chromium.org/gerrit/#change,18257 https://gerrit.chromium.org/gerrit/#change,18259
I thought the upshot of this discussion was that there wasn't any need for any kind of pre-console stuff, either putc, puts/printf or whatever; instead, the console should simply be registered as early as possible based on the board/config's UART selection?
Not quite - going back to your previous message, if there is a panic before the console is ready (and in the event of there being no fdt) I would like to offer a message on a UART selected by a CONFIG.
(and of course the DT parsed after that console was registered; no need for it before)
The DT must be parsed before the console is registered - after all the DT tells us which is the console.
Yes, we can't know what console the DT says to use until the DT is located and parsed. That much is blatantly obvious.
But the last few messages in this thread have all been about the following as far as I'm concerned:
* The U-Boot configuration defines which single UART to use for the initial console.
* This initial console is registered early enough that almost all failures can be reported. In particular, something as non-critical as locating and parsing the DT should happen after this initial console is registered, so that DT existence/parsing problems can be reported to this initial console.
By non-critical here, I mean that there should be no reason to require the DT to be parsed in order for the CPU to boot, and the initial UART-based console to be registered. DT parsing shouldn't be attempted until this basic level of operation is achieved; it should be be required that the DT be parsed for any of that to work.
* When the DT is parsed later, the console specification from DT replaces the initial console.
With this scheme in place, there surely isn't any need for any kind of special-case early putc/puts/printf - wasn't this exactly Wolfgang's point?
Dear Stephen,
In message 4F6A1D1E.2090607@wwwdotorg.org you wrote:
But the last few messages in this thread have all been about the following as far as I'm concerned:
- The U-Boot configuration defines which single UART to use for the
initial console.
- This initial console is registered early enough that almost all
failures can be reported. In particular, something as non-critical as locating and parsing the DT should happen after this initial console is registered, so that DT existence/parsing problems can be reported to this initial console.
By non-critical here, I mean that there should be no reason to require the DT to be parsed in order for the CPU to boot, and the initial UART-based console to be registered. DT parsing shouldn't be attempted until this basic level of operation is achieved; it should be be required that the DT be parsed for any of that to work.
- When the DT is parsed later, the console specification from DT
replaces the initial console.
With this scheme in place, there surely isn't any need for any kind of special-case early putc/puts/printf - wasn't this exactly Wolfgang's point?
Correct, that's what I have in mind.
Actually we already do the same in other situations - for example on systems with console on LCD, whih becomes available pretty late in the boot sequence.
Best regards,
Wolfgang Denk
Dear Simon,
In message CAPnjgZ128xB53b-h-pcPJs1tjLLngRa116D75ysmsWJvofotrw@mail.gmail.com you wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war.
I made my mind up: I want to get rid of all this "pre_console" UART stuff.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Mar 21, 2012 at 3:56 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ128xB53b-h-pcPJs1tjLLngRa116D75ysmsWJvofotrw@mail.gmail.com you wrote:
- What you propose is actually very easy to implement - it just
requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code.
No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war.
I made my mind up: I want to get rid of all this "pre_console" UART stuff.
OK, so revert that commit?
In that case I have a question. How can we get console output in the event of a panic before console_ready() is called?
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid
Dear Simon Glass,
In message CAPnjgZ0jtSioCq+u2yiaDL6cwV711duWW5uT88mE3oHB-nNmjQ@mail.gmail.com you wrote:
No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war.
I made my mind up: I want to get rid of all this "pre_console" UART stuff.
OK, so revert that commit?
It hasn't hit mainline yet, or has it?
In that case I have a question. How can we get console output in the event of a panic before console_ready() is called?
You cannot, by definition. You cannot output anything to the console without initializing it before.
This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Mar 21, 2012 at 4:07 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ0jtSioCq+u2yiaDL6cwV711duWW5uT88mE3oHB-nNmjQ@mail.gmail.com you wrote:
No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war.
I made my mind up: I want to get rid of all this "pre_console" UART stuff.
OK, so revert that commit?
It hasn't hit mainline yet, or has it?
Yes, it is there, sorry.
In that case I have a question. How can we get console output in the event of a panic before console_ready() is called?
You cannot, by definition. You cannot output anything to the console without initializing it before.
This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot.
So if actually you want a pre-console panic() to be silent then that's fine.
It's a little unfriendly though - so would you be interested in keeping board_pre_console_putc() around if we could solve this entirely with code in there? It turns out that Tegra has a setting for console UART in the hardware parameters that we can access.( I won't ask you about how to handle a panic() in SPL yet).
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it.
Dear Simon Glass,
In message CAPnjgZ1u8paSeKxozWz1D5YoJaJ2um_q0dWQo=k5_+HEdKh1AQ@mail.gmail.com you wrote:
OK, so revert that commit?
It hasn't hit mainline yet, or has it?
Yes, it is there, sorry.
Which commit is that?
This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot.
So if actually you want a pre-console panic() to be silent then that's fine.
I do not _want_ it.
This is a simple matter of facts that cannot be avoided. If we cannot initialize the consolem then we cannot print anything.
It's a little unfriendly though - so would you be interested in keeping board_pre_console_putc() around if we could solve this entirely with code in there? It turns out that Tegra has a setting for console UART in the hardware parameters that we can access.( I won't ask you about how to handle a panic() in SPL yet).
If you can initialize the console in a way that allows sending characters, then just do this - do this as part of the recular fconsole init code, so we do have a working console, and we do not need ay "pre-console" stuff.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, Mar 22, 2012 at 6:25 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ1u8paSeKxozWz1D5YoJaJ2um_q0dWQo=k5_+HEdKh1AQ@mail.gmail.com you wrote:
OK, so revert that commit?
It hasn't hit mainline yet, or has it?
Yes, it is there, sorry.
Which commit is that?
It was 295d3942: Add board_pre_console_putc to deal with early console output
The discussion threads are around here:
http://lists.denx.de/pipermail/u-boot/2011-August/099620.html
If you are looking for a revert :-)
http://patchwork.ozlabs.org/patch/147617/
This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot.
So if actually you want a pre-console panic() to be silent then that's fine.
I do not _want_ it.
This is a simple matter of facts that cannot be avoided. If we cannot initialize the consolem then we cannot print anything.
It's a little unfriendly though - so would you be interested in keeping board_pre_console_putc() around if we could solve this entirely with code in there? It turns out that Tegra has a setting for console UART in the hardware parameters that we can access.( I won't ask you about how to handle a panic() in SPL yet).
If you can initialize the console in a way that allows sending characters, then just do this - do this as part of the recular fconsole init code, so we do have a working console, and we do not need ay "pre-console" stuff.
OK, let's leave it for now, I don't see a way of achieving this in the case of an early panic.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt
Dear Simon,
In message CAPnjgZ2EzvwagqKpAwKGgU-=bpSGOSjhSo03o0G8GWoLnyNHZg@mail.gmail.com you wrote:
Yes, it is there, sorry.
Which commit is that?
It was 295d3942: Add board_pre_console_putc to deal with early console outp= ut
The discussion threads are around here:
http://lists.denx.de/pipermail/u-boot/2011-August/099620.html
If you are looking for a revert :-)
Yes, this should be reverted, indeed.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, Mar 22, 2012 at 4:00 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ2EzvwagqKpAwKGgU-=bpSGOSjhSo03o0G8GWoLnyNHZg@mail.gmail.com you wrote:
Yes, it is there, sorry.
Which commit is that?
It was 295d3942: Add board_pre_console_putc to deal with early console outp= ut
The discussion threads are around here:
http://lists.denx.de/pipermail/u-boot/2011-August/099620.html
If you are looking for a revert :-)
Yes, this should be reverted, indeed.
OK, well you have it there.
I am going to have a similar problem in the SPL soon - how to deal with panic(). Advice gratefully accepted.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. - John Keats
Dear Simon Glass,
In message CAPnjgZ1SAGr7iu0EWrtrojiRA9kPPtxz8apLaDiNO0ck1q6o+Q@mail.gmail.com you wrote:
I am going to have a similar problem in the SPL soon - how to deal with panic(). Advice gratefully accepted.
The SPL code is not special in this regard: initialize the console port as soon as possible; then use it.
Best regards,
Wolfgang Denk
Hi Simon,
On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass sjg@google.com wrote:
I am going to have a similar problem in the SPL soon - how to deal with panic(). Advice gratefully accepted.
Take a leaf out of the Linux x86 source....
arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code which is entered by the boot loader (so it's like SPL - IPL being the BIOS/Bootloader combo)
void main(void) { /* First, copy the boot header into the "zeropage" */ copy_boot_params();
/* Initialize the early-boot console */ console_init(); ...
arch/x86/boot/early_serial_console.c
void console_init(void) { parse_earlyprintk();
if (!early_serial_base) parse_console_uart8250(); }
early_serial_base is a global defined in boot.h:
extern int early_serial_base;
You can do the same in SPL, but you are not going to have the luxury of having it configurable unless you can do so in some non-volatile memory or hardware configuration (dedicated GPIO pins etc)
It's a chicken and egg scenario - If you want your default console port to be configurable, you need code to determine the configuration. But you cannot spew out debug messages for the code which determines the console configuration. Linux x86 has the same problem, there is no way to ouput debug messages in copy_boot_params() or console_init()
In U-Boot we kind of 'cheat' - We define a board specific default console in the board config (hard coded in the U-Boot binary) which we use unitl environment variables are available. Linux x86 could do the same - have compile time options which allow the serial console to be enabled before copy_boot_params(), but the amount of code which is 'dark' is so small it's not worth it.
U-Boot is different, the amount of code that is 'dark' before the environment variables are available is rather large. And pre console buffer covers the 'dark' code just prior to the hard-coded console being available (but of course pre console buffer does not help if there is a hang or crash before the hard-coded console is available)
I should check - Is it possible to not have a default console, and therefor pre console buffer is used all the way up to the console defined in the environment being intialised?
Regards,
Graeme
Hi Graeme,
On Thu, Mar 22, 2012 at 4:41 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass sjg@google.com wrote:
I am going to have a similar problem in the SPL soon - how to deal with panic(). Advice gratefully accepted.
Take a leaf out of the Linux x86 source....
arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code which is entered by the boot loader (so it's like SPL - IPL being the BIOS/Bootloader combo)
void main(void) { /* First, copy the boot header into the "zeropage" */ copy_boot_params();
/* Initialize the early-boot console */ console_init(); ...
arch/x86/boot/early_serial_console.c
void console_init(void) { parse_earlyprintk();
if (!early_serial_base) parse_console_uart8250(); }
early_serial_base is a global defined in boot.h:
extern int early_serial_base;
You can do the same in SPL, but you are not going to have the luxury of having it configurable unless you can do so in some non-volatile memory or hardware configuration (dedicated GPIO pins etc)
It's a chicken and egg scenario - If you want your default console port to be configurable, you need code to determine the configuration. But you cannot spew out debug messages for the code which determines the console configuration. Linux x86 has the same problem, there is no way to ouput debug messages in copy_boot_params() or console_init()
In U-Boot we kind of 'cheat' - We define a board specific default console in the board config (hard coded in the U-Boot binary) which we use unitl environment variables are available. Linux x86 could do the same - have compile time options which allow the serial console to be enabled before copy_boot_params(), but the amount of code which is 'dark' is so small it's not worth it.
U-Boot is different, the amount of code that is 'dark' before the environment variables are available is rather large. And pre console buffer covers the 'dark' code just prior to the hard-coded console being available (but of course pre console buffer does not help if there is a hang or crash before the hard-coded console is available)
Thanks very much for your comments.
Yes it is this dark period that bothers me. I think for now the solution is to ignore it and hope that nothing goes wrong, particularly with the revert of even the pre-console putc(). I think for now I will provide an option to check the device tree later in the boot, and later look at having some sort of fallback config for the console.
I should check - Is it possible to not have a default console, and therefor pre console buffer is used all the way up to the console defined in the environment being intialised?
I actually created a patch to delay console init until after relocation, just to see how this might work. It works fine, and does speed things up a little, but is of course not in keeping with the U-Boot design.
Anyway all I am really concerned about is that we might not make it through the dark period. For now I am going to forget about that problem; there are plenty of others.
Regards, Simon
Regards,
Graeme
Stephen,
On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren swarren@wwwdotorg.org wrote:
I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument.
If you're going to look at getting earlyprintk able to take arguments, this bug (and the associated links) might be of interest to you: http://code.google.com/p/chromium-os/issues/detail?id=19185
It would certainly be nice to get earlyprintk able to take arguments on ARM in the kernel. I didn't originally go down that route because it seemed like there were going to be lots of yaks to shave and it would involve changes to some of the core Linux ARM boot code. It also didn't solve the problem where the ARM kernel wants to do prints before translation (as Olof points out in in the discussion thread linked above). ...but it does seem to be the better route.
I doubt it will be possible to do this in the ARM zImage decompressor though.
The "decompressing" part of the kernel wouldn't come for free without a lot of work, but maybe the right answer is to leverage u-boot's ability to decompress the kernel and stop using the zImage anyway. That would make Simon happy, I think.
-Doug
On 03/21/2012 03:38 AM, Wolfgang Denk wrote: ...
To bring this to a constructive end:
It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works).
OK, there is still a chance that the environment settings are missing or incorrect _and_ the DT cannot be loaded, but the probability for such a double-fault is much, much smaller.
Could this be an acceptable solution for you?
I'd prefer to just have a different U-Boot (build) config for each HW configuration, and define the console UART as part of that configuration using the existing defines that are for that purpose.
If we put the UART ID into the environment, then we either need to:
a) Have a different U-Boot configuration anyway, in order to define the different environment during the U-Boot build process.
b) Post-process the U-Boot binary after building it, in order to modify the environment that's contained in that binary.
Neither of those seem better to me that simply putting the UART ID into the U-Boot config directly in the first place.
Dear Stephen Warren,
In message 4F6A01D3.3020506@wwwdotorg.org you wrote:
It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works).
...
I'd prefer to just have a different U-Boot (build) config for each HW configuration, and define the console UART as part of that configuration using the existing defines that are for that purpose.
This is another option - at the cost of maintaining separate binary images.
If we put the UART ID into the environment, then we either need to:
a) Have a different U-Boot configuration anyway, in order to define the different environment during the U-Boot build process.
b) Post-process the U-Boot binary after building it, in order to modify the environment that's contained in that binary.
Not true. In the normal course of events, the board would boot with a working device tree provided, which provides correct console information. This could be used to auto-initialize the correct environment settings. You just have to make sure that board boots a single time with a working DT image - I don't know how production tests and/or software commissioning on these boards is organized, but this seems to be a possible route to me. [Been there, done that before. About 12 years before, IIRC.] You probably also need to program MAC addresses etc. ?
Best regards,
Wolfgang Denk
Hi Stephen,
On Tue, Mar 20, 2012 at 2:17 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/20/2012 02:13 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren swarren@wwwdotorg.org wrote:
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing:
http://www.spinics.net/lists/arm-kernel/msg154633.html
Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein.
Base on work by Doug Anderson dianders@chromium.org, but significantly rewritten.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
Tom, this patch applies on top of u-boot-tegra/master, with the top 4 commits removed and replaced with Simon's latest putc series from last night.
Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to remove the uart_ids parameter and simply call get_uart_ids() internally?
I can't help thinking there is a bit of a misunderstanding here. I suspected it from your comments yesterday, so let's try to clear it up.
It's not so much a misunderstanding as a disagreement over the right direction.
OK
This patch is intended (I believe) to signal to Linux which UART is used for the earlyprintk console. This is so when U-Boot cannot decompress the kernel (because we are booting a zImage which has its own decompression wrapper) we can print the 'Uncompressing Linux...' message. Is that correct?
That's one thing it affects, yes.
It also affects the DEBUG_LL/earlyprintk output, i.e. all the kernel spew (by the kernel itself, not the decompressor) that happens before the real console device is set up.
(When there's no problem and earlyprintk isn't on, this is all buffered up and sent out the console when it appears, but if there's a panic before the console is initialized, you won't see any messages. If earlyprintk is enabled, the messages aren't buffered, but instead sent immediately using the DEBUG_LL mechanism, and this patch is what tells the DEBUG_LL mechanism which UART to use).
Yes that's true also.
If so, what you want to find out here is exactly which UART is being used for the console. It will be a single UART, it will be know for sure, whether the information comes from CONFIG or the device tree.
True, implementing it that way would also be useful. Right now, that's driven by CONFIG_SYS_NS16550_COM*, but can come from DT too.
OK
For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*.
That's where we disagree.
For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design.
In other words: While other boards may be similar to Seaboard, they are not Seaboard, and we shouldn't be using the Seaboard board file for them. They are different boards that are simply similar in design. But for example, many use a different UART for their debug console - a clear difference in hardware.
For each one of these derived boards, there is a single static UART that should be used, as determined by the board design.
Thus, I argue that there really is no concept of "which UART do we use" *for a given board*.
I think perhaps the way to clear this up is to make the existing Seaboard and Ventana boards NOT be device-tree-driven, but rather be "board-file" driven. Instead of co-opting Seaboard, introduce a new "tegra2dt" board that is purely DT driven. (This is exactly what's been done in the kernel). Then, it would make a lot more sense to talk about there being multiple possible UARTs to use for the console, since the board you build U-Boot for would then explicitly be for multiple boards, rather than hijacking a particular single board file to work on multiple boards. It'd also allow people to boot U-Boot on Seaboard without using DT if they wanted, at the very least as a temporary transition mechanism.
Know you of such people? But yes I am thinking beyond Seaboard and yes we do need a 'generic' tegra2 board instead of using Seaboard. I am not sure of the value of having separate boards at all though, since with a the device tree there should be nothing in the board files that is not generic. I suppose that is what has stopped me from actually implementing a generic tegra2 board so far - in my mind it is just Seaboard (or anything else if you prefer, since they are all the same in that all differences are captured by the device tree).
But I agree we should do it.
As an aside, for the tegra2dt board, perhaps we should have a single well-known location in the U-Boot binary that contains the "uart_ids" value. This can be initialized to "all UARTs" by default by the code (or perhaps "no UARTs" for safety). As part of the manual post-processing to convert this common u-boot.bin binary to a particular board prior to flashing, one could both (a) append the .dtb file just like is required now (b) patch that well-known location to set the specific UARTs for the panic putc, if desired. "Well known" could perhaps be determined using "nm" and searching for a specific symbol. A helper script could be provided to make this easy. What do you think of this?
Well it is sort-of similar to the problem we have with SPL. There we are looking at a solution where there is a little table placed in SPL which contains a few critical parameters from the device tree. It is available to C code very early and could include the console UART info. From the code's point of view it is just a global C structure with some useful data. I can point you to this if you like.
So the concept of selecting a particular UART and writing out a message is not really good enough. Sure it works on Seaboard, and I adjusted my patch to only use UARTD, but doesn't work on a Seaboard variant where we don't yet have the device tree and so don't know which UART is used for the console. The device tree specifies the console UART - it cannot be known at compile time. The best we can do is specify the possible and legal options.
Please don't get these two things (asking which is the console UART and asking which UARTs could possible be the console) confused - I realise that this is a bit mess. To be clear, the pre-console panic is NOT:
- Intended to just print a message on the console - that would be
easy if we actually knew which was the console; nor
- Intended as a general-purpose pre-console message output interface
- there is already Graeme's pre-console buffer for that.
BTW, it seems inconsistent to have all the Tegra code key off CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off CONFIG_SYS_NS16550_COM*. Can the two be unified somehow?
Both of these are not used when device trees are enabled, so it doesn't much matter to me. But I'm sure we could do this in the tegra2.h header file or similar.
Regards, Smion
Dear Stephen Warren,
In message 4F68F3D0.6030608@wwwdotorg.org you wrote:
For each board, there is a single fixed UART that should be used for
Thanks for this statement. I agree 100%.
both pre-console panic and the "real" console later. This is fixed by the single static board design.
Here I disagree. The concept of "pre-console panic" as used here is broken.
We should _always_ initialize this "single fixed UART" as debug console as early as possible. Period.
If we have a "pre-console panic" then, we cannot do anything about it, because if "as early as possible" is not sufficient, then it cannot be helped - obviously we cannot initialize the UART before that.
And any panic after that is just anormal thing that can be printed on the debug console port. No need for any special handling.
Best regards,
Wolfgang Denk
participants (6)
-
Doug Anderson -
Graeme Russ -
Simon Glass -
Simon Glass -
Stephen Warren -
Wolfgang Denk