diff mbox

[U-Boot,v3,7/8] zynq: Move SPL console init out of board_init_f()

Message ID 1445116021-27296-8-git-send-email-sjg@chromium.org
State Superseded
Delegated to: Tom Rini
Headers show

Commit Message

Simon Glass Oct. 17, 2015, 9:07 p.m. UTC
We should not init the console this early and there is no need to. If we want
to do early init it can be done in spl_board_init(). Move the
preloader_console_init() call from board_init_f() to board_init_r().

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
---

Changes in v3:
- Rebase to master

Changes in v2: None

 arch/arm/mach-zynq/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Albert ARIBAUD Oct. 18, 2015, 4:36 p.m. UTC | #1
Hello Simon,

On Sat, 17 Oct 2015 15:07:00 -0600, Simon Glass <sjg@chromium.org>
wrote:
> We should not init the console this early and there is no need to. If we want
> to do early init it can be done in spl_board_init(). Move the
> preloader_console_init() call from board_init_f() to board_init_r().
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Tested-by: Michal Simek <michal.simek@xilinx.com>

I personally think that we should, almost must in fact, initialize the
console as early as possible.

What exactly is the drawaback of initializing the console here?

Amicalement,
Simon Glass Oct. 18, 2015, 8:37 p.m. UTC | #2
Hi Albert,

On 18 October 2015 at 10:36, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> On Sat, 17 Oct 2015 15:07:00 -0600, Simon Glass <sjg@chromium.org>
> wrote:
>> We should not init the console this early and there is no need to. If we want
>> to do early init it can be done in spl_board_init(). Move the
>> preloader_console_init() call from board_init_f() to board_init_r().
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Tested-by: Michal Simek <michal.simek@xilinx.com>
>
> I personally think that we should, almost must in fact, initialize the
> console as early as possible.
>
> What exactly is the drawaback of initializing the console here?

This is described in the README now for SPL. The console is not
available until driver model is ready, which cannot be before
global_data is ready.

My second zynq series removes the next few lines from board_init_f(),
so in effect there is very little difference in timing - the console
still is set up very early. It is just that we must not set it up
before driver model is running.

There is also a debug UART which can be used to make printf() work
before global_data is available. But I'm trying to remove the
global_data hacks that exist in early board code.

Regards,
Simon
Albert ARIBAUD Oct. 19, 2015, 5:15 a.m. UTC | #3
Hello Simon,

On Sun, 18 Oct 2015 14:37:03 -0600, Simon Glass <sjg@chromium.org>
wrote:
> Hi Albert,
> 
> On 18 October 2015 at 10:36, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> > Hello Simon,
> >
> > On Sat, 17 Oct 2015 15:07:00 -0600, Simon Glass <sjg@chromium.org>
> > wrote:
> >> We should not init the console this early and there is no need to. If we want
> >> to do early init it can be done in spl_board_init(). Move the
> >> preloader_console_init() call from board_init_f() to board_init_r().
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >> Tested-by: Michal Simek <michal.simek@xilinx.com>
> >
> > I personally think that we should, almost must in fact, initialize the
> > console as early as possible.
> >
> > What exactly is the drawaback of initializing the console here?
> 
> This is described in the README now for SPL. The console is not
> available until driver model is ready, which cannot be before
> global_data is ready.

Makes sense now.

Maybe the commit message could explicitly mention that the cause of the
"should not" is the driver model? This commit might be viewed in
isolation and the reader may need a clue on how to relate that commit
to the driver model or the README.

> My second zynq series removes the next few lines from board_init_f(),
> so in effect there is very little difference in timing - the console
> still is set up very early. It is just that we must not set it up
> before driver model is running.
> 
> There is also a debug UART which can be used to make printf() work
> before global_data is available. But I'm trying to remove the
> global_data hacks that exist in early board code.

Then my initial concern is address (and again, maybe a small note in
the commit message could remind the reader about the debug UART not
being affected by the commit). Thanks!

> Regards,
> Simon

Amicalement,
diff mbox

Patch

diff --git a/arch/arm/mach-zynq/spl.c b/arch/arm/mach-zynq/spl.c
index e7df6d3..7bdac3b 100644
--- a/arch/arm/mach-zynq/spl.c
+++ b/arch/arm/mach-zynq/spl.c
@@ -20,7 +20,6 @@  void board_init_f(ulong dummy)
 	/* Clear the BSS. */
 	memset(__bss_start, 0, __bss_end - __bss_start);
 
-	preloader_console_init();
 	arch_cpu_init();
 	board_init_r(NULL, 0);
 }
@@ -28,6 +27,7 @@  void board_init_f(ulong dummy)
 #ifdef CONFIG_SPL_BOARD_INIT
 void spl_board_init(void)
 {
+	preloader_console_init();
 	board_init();
 }
 #endif