Hi Graeme, On Thu, Mar 22, 2012 at 4:41 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > Hi Simon, > > On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot