[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 at gmail.com> wrote:
> Hi Simon,
>
> On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass <sjg at 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