[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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', &regs->spr);
+		}
+	}
+}
+
 void tegra_pre_console_panic(int uart_ids, unsigned clock_freq,
 			     unsigned multiplier, const char *str)
 {
-- 
1.7.0.4

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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', &regs->spr);
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> +}
> +
> ?void tegra_pre_console_panic(int uart_ids, unsigned clock_freq,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned multiplier, const char *str)
> ?{
> --
> 1.7.0.4
>

Regards,
Simon

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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:
> 
> 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?

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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:
>>
>> 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?

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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)

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenst?n-
de (Mausbewegung) und "ga" sagen  (Mausklick)  abzukommen,  zugunsten
eines  m?chtigeren  und langwierig zu erlernenden Tools (Sprache).
                             -- Achim Linder in de.comp.os.linux.misc

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
[Braddock:] Mr. Churchill, you are drunk.
[Churchill:] And you madam, are ugly.  But I shall be sober tomorrow.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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?

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

On 03/21/2012 10:59 AM, Simon Glass wrote:
> 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.

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?

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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:
>> 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.
>
> 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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:
>>> 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.
>>
>> 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)

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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:
>>>> 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.
>>>
>>> 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Stephen Warren]

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:
>>>>> 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.
>>>>
>>>> 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?

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
"Pardon me for breathing, which I never do anyway so I don't know why
I bother to say it, oh God, I'm so depressed. Here's another of those
self-satisfied doors. Life! Don't talk to me about life."
                                        - Marvin the Paranoid Android

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ128xB53b-h-pcPJs1tjLLngRa116D75ysmsWJvofotrw@mail.gmail.com> you wrote:
> 
> 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.

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

-- 
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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
They weren't that important. They were merely at the top. The  people
who  really  run organizations are usually found several levels down,
where it's still possible to get things done.
                                      - Terry Pratchett, _Small Gods_

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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:
>>
>> 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.
>
> 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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
There are three ways to get something  done:  do  it  yourself,  hire
someone, or forbid your kids to do it.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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 at denx.de
> There are three ways to get something ?done: ?do ?it ?yourself, ?hire
> someone, or forbid your kids to do it.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Doug Anderson]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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 :-)
> 
> http://patchwork.ozlabs.org/patch/147617/

Yes, this should be reverted, indeed.

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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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 :-)
>>
>> http://patchwork.ozlabs.org/patch/147617/
>
> 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 at 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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Wolfgang Denk]

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

-- 
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 at denx.de
A Stanford research group advertised for participants in a  study  of
obsessive-compulsive  disorder. They were looking for therapy clients
who had been diagnosed with this disorder. The  response  was  grati-
fying;  they  got  3,000 responses about three days after the ad came
out. All from the same person.

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Graeme Russ]

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

[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

[Simon Glass]

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