With the '-march=core2' fix, it seems that we have some luck that the 64-bit U-Boot boots again. However if we examine the disassembly codes there are still SSE instructions elsewhere which means passing cpu type to GCC is not enough to prevent it from generating these instructions. A simple test case is doing a 'bootefi selftest' from the U-Boot shell and it leads to a reset too.

The 'bootefi selftest' reset is even seen with the image created by the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.

The reset actually originates from undefined instruction exception caused by these SSE instructions. To keep U-Boot as a bootloader as simple as possible, we don't want to handle such advanced SIMD stuff. To make sure no MMX/SSE instruction sets are generated, tell GCC not to do this. Note AVX is out of the question as CORE2 is old enough to support AVX yet.

Signed-off-by: Bin Meng bmeng.cn@gmail.com

--- Changes in this version: - revise the commit message for the reason of turning off MMX/SSE

arch/x86/config.mk | 1 + 1 file changed, 1 insertion(+)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 576501e..8151e47 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64 +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse endif

PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden

Currently only 32-bit U-Boot for QEMU x86 is documented. Mention the 64-bit support.

Signed-off-by: Bin Meng bmeng.cn@gmail.com

--- Changes in this version: - add more information about 64-bit support

doc/README.x86 | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86 index 8cc4672..64da4ac 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -32,7 +32,7 @@ are supported: - Link (Chromebook Pixel) - Minnowboard MAX - Samus (Chromebook Pixel 2015) - - QEMU x86 + - QEMU x86 (32-bit & 64-bit)

As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:

To build u-boot.rom for QEMU x86 targets, just simply run

-$ make qemu-x86_defconfig +$ make qemu-x86_defconfig (for 32-bit) +or +$ make qemu-x86_64_defconfig (for 64-bit) $ make all

Note this default configuration will build a U-Boot for the QEMU x86 i440FX @@ -479,6 +481,19 @@ Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then,

=> zboot 01000000 - 04000000 1b1ab50

+To run 64-bit U-Boot, qemu-system-x86_64 should be used instead, e.g.: +$ qemu-system-x86_64 -nographic -bios path/to/u-boot.rom + +Specific CPU can be specified via the '-cpu' parameter but please make +sure the specified CPU supports 64-bit like '-cpu core2duo'. Conversely +'-cpu pentium' won't work for obvious reasons that the processor only +supports 32-bit. + +Note 64-bit support is very preliminary at this point. Lots of features +are missing in the 64-bit world. One notable feature is VGA console +support which is currently missing, so that you must specify '-nographic' +to get 64-bit U-Boot up and running. + Updating U-Boot on Edison ------------------------- By default Intel Edison boards are shipped with preinstalled heavily

There are some sections in current doc saying 64-bit is unsupported. This apparently is out of date. Remove it.

Signed-off-by: Bin Meng bmeng.cn@gmail.com ---

doc/README.x86 | 17 ----------------- 1 file changed, 17 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86 index 64da4ac..fe47221 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1160,27 +1160,10 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU.

See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.

-64-bit Support --------------- -U-Boot supports booting a 64-bit kernel directly and is able to change to -64-bit mode to do so. However, U-Boot itself is currently always built -in 32-bit mode. Some access to the full memory range is provided with -arch_phys_memset(). - -The development work to make U-Boot itself run in 64-bit mode has not yet -been attempted. The best approach would likely be to build a 32-bit SPL -image for U-Boot, with CONFIG_SPL_BUILD. This could then handle the early CPU -init in 16-bit and 32-bit mode, running the FSP and any other binaries that -are needed. Then it could change to 64-bit model and jump to U-Boot proper. - -Given U-Boot's extensive 64-bit support this has not been a high priority, -but it would be a nice addition. - TODO List --------- - Audio - Chrome OS verified boot -- Building U-Boot to run in 64-bit mode

References ----------

From: Heinrich Schuchardt xypron.glpk@gmx.de

Since commit 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL") qemu-x86_64_defconfig does not boot anymore.

Fixes: 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL") Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de Signed-off-by: Bin Meng bmeng.cn@gmail.com ---

configs/qemu-x86_64_defconfig | 1 + 1 file changed, 1 insertion(+)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index cf1ba8e..32922b8 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -63,6 +63,7 @@ CONFIG_SPL_REGMAP=y CONFIG_SYSCON=y CONFIG_SPL_SYSCON=y CONFIG_CPU=y +CONFIG_SPL_DM_RTC=y CONFIG_SPI=y CONFIG_SPL_TIMER=y CONFIG_USB_STORAGE=y

From: Heinrich Schuchardt xypron.glpk@gmx.de

Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.

This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.

Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com ---

arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)

diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755..4d09e4d 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, Elf64_Addr *offset_ptr_ram;

do { + unsigned long long type = ELF64_R_TYPE(re_src->r_info); + + if (type != R_X86_64_RELATIVE) { + printf("%s: unsupported relocation type 0x%llx " + "at %p, ", __func__, type, re_src); + printf("offset = 0x%llx\n", re_src->r_offset); + continue; + } + /* Get the location from the relocation entry */ offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;

@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size, Elf32_Addr *offset_ptr_ram;

do { + unsigned int type = ELF32_R_TYPE(re_src->r_info); + + if (type != R_386_RELATIVE) { + printf("%s: unsupported relocation type 0x%x " + "at %p, ", __func__, type, re_src); + printf("offset = 0x%x\n", re_src->r_offset); + continue; + } + /* Get the location from the relocation entry */ offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;

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 ---

arch/x86/cpu/start64.S | 1 + arch/x86/cpu/x86_64/cpu.c | 18 ------------------ 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/x86/cpu/start64.S b/arch/x86/cpu/start64.S index a473fd1..a78a331 100644 --- a/arch/x86/cpu/start64.S +++ b/arch/x86/cpu/start64.S @@ -20,6 +20,7 @@ _start:

call board_init_f_init_reserve

+ xor %rdi, %rdi call board_init_f call board_init_f_r

diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c index ef5e812..6c063e8 100644 --- a/arch/x86/cpu/x86_64/cpu.c +++ b/arch/x86/cpu/x86_64/cpu.c @@ -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)

So far the TSC timer driver supports trying hardware calibration first and using device tree as last resort for its running frequency as the normal timer.

However when it is used as the early timer, it only supports hardware calibration and if it fails, the driver just panics. This introduces a new config option to specify the early timer frequency and it should be equal to the value described in the device tree.

Without this patch, the travis-ci testing on QEMU x86_64 target fails each time after it finishes the 'bootefi selftest' as the test.py see an error was emitted on the console like this:

TSC frequency is ZERO resetting ... ### ERROR ### Please RESET the board ###

It's strange that this error is consistently seen on the travis-ci machine, but only occasionally seen on my local machine (maybe 1 out of 10). Since QEMU x86_64 target enables BOOTSTAGE support which uses early timer, with this fix it should work without any failure.

Signed-off-by: Bin Meng bmeng.cn@gmail.com ---

drivers/timer/Kconfig | 10 ++++++++++ drivers/timer/tsc_timer.c | 10 ++++++---- 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 45a256a..f300f87 100644 --- a/drivers/timer/Kconfig +++ b/drivers/timer/Kconfig @@ -82,6 +82,16 @@ config X86_TSC_TIMER help Select this to enable Time-Stamp Counter (TSC) timer for x86.

+config X86_TSC_TIMER_EARLY_FREQ + int "x86 TSC timer frequency when it is used as the early timer" + depends on X86_TSC_TIMER + default 1000000000 + help + Sets the TSC timer frequency when TSC is used as the ealy timer + and the frequency can neither be calibrated via some hardware + ways, nor got from device tree at the time when device tree is + not available yet. + config OMAP_TIMER bool "Omap timer support" depends on TIMER diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c index 6473de2..5dc6f9e 100644 --- a/drivers/timer/tsc_timer.c +++ b/drivers/timer/tsc_timer.c @@ -341,7 +341,7 @@ static int tsc_timer_get_count(struct udevice *dev, u64 *count) return 0; }

-static void tsc_timer_ensure_setup(bool stop) +static void tsc_timer_ensure_setup(bool early) { if (gd->arch.tsc_base) return; @@ -362,10 +362,12 @@ static void tsc_timer_ensure_setup(bool stop) if (fast_calibrate) goto done;

- if (stop) - panic("TSC frequency is ZERO"); - else + if (early) { + gd->arch.clock_rate = CONFIG_X86_TSC_TIMER_EARLY_FREQ; + return; + } else { return; + }

done: gd->arch.clock_rate = fast_calibrate * 1000000;