x86: Fix the mystery of printch() during 64-bit boot
authorBin Meng <bmeng.cn@gmail.com>
Sun, 14 Oct 2018 03:52:09 +0000 (20:52 -0700)
committerBin Meng <bmeng.cn@gmail.com>
Mon, 22 Oct 2018 09:51:45 +0000 (17:51 +0800)
At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot just does not boot at all.

In fact this is due to the bug that board_init_f() was called with
boot_flags not being set. Hence whatever value being there in the
rdi register becomes the boot_flags if without such magic call.
With a printch(' ') call the rdi register is initialized as 0x20
and this value seems to be sane enough for the whole boot process.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
arch/x86/cpu/start64.S
arch/x86/cpu/x86_64/cpu.c

index a473fd166d3412c9af49e135034388c4e3104c5a..a78a3316b6d64ccddff9024ba18088c5951e9bd8 100644 (file)
@@ -20,6 +20,7 @@ _start:
 
        call    board_init_f_init_reserve
 
+       xor     %rdi, %rdi
        call    board_init_f
        call    board_init_f_r
 
index ef5e812510e7d0d33adf0e3dd1a40db534d4977b..6c063e82009bf9e092d61c5cec95de8a953db82b 100644 (file)
@@ -19,24 +19,6 @@ struct global_data *global_data_ptr = (struct global_data *)~0;
 void arch_setup_gd(gd_t *new_gd)
 {
        global_data_ptr = new_gd;
-
-       /*
-        * TODO(sjg@chromium.org): For some reason U-Boot does not boot
-        * without this line. It fails to start up U-Boot proper and instead
-        * restarts SPL. Need to figure out why:
-        *
-        * U-Boot SPL 2017.01
-        *
-        * U-Boot SPL 2017.01
-        * CPU:   Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
-        * Trying to boot from SPIJumping to 64-bit U-Boot: Note many
-        * features are missing
-        *
-        * U-Boot SPL 2017.01
-        */
-#ifdef CONFIG_DEBUG_UART
-       printch(' ');
-#endif
 }
 
 int cpu_has_64bit(void)