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