From d7e84521feed2d2a45912b47a82c4700ee3c164a Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 2 Sep 2018 17:02:25 -0600 Subject: [PATCH 01/17] chromebook_samus: Increase pre-relocation memory With bootstage now allocating pre-relocation memory the current amount available is insufficient. Increase it a little. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- configs/chromebook_samus_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/chromebook_samus_defconfig b/configs/chromebook_samus_defconfig index 8f2336c..e5483c5 100644 --- a/configs/chromebook_samus_defconfig +++ b/configs/chromebook_samus_defconfig @@ -1,6 +1,6 @@ CONFIG_X86=y CONFIG_SYS_TEXT_BASE=0xFFE00000 -CONFIG_SYS_MALLOC_F_LEN=0x1800 +CONFIG_SYS_MALLOC_F_LEN=0x1a00 CONFIG_DEBUG_UART_BOARD_INIT=y CONFIG_DEBUG_UART_BASE=0x3f8 CONFIG_DEBUG_UART_CLOCK=1843200 From 27fb0cf1f0dd061f5a902928417656488db6301f Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 2 Sep 2018 17:02:26 -0600 Subject: [PATCH 02/17] binman: Add support for Intel reference code Some platforms use this instead of FSP to set up the platform, including memory. Add support for this in binman. This is needed for chromebook_samus, for example. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- tools/binman/etype/intel_refcode.py | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 tools/binman/etype/intel_refcode.py diff --git a/tools/binman/etype/intel_refcode.py b/tools/binman/etype/intel_refcode.py new file mode 100644 index 0000000..045db58 --- /dev/null +++ b/tools/binman/etype/intel_refcode.py @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (c) 2016 Google, Inc +# Written by Simon Glass +# +# Entry-type module for Intel Memory Reference Code binary blob +# + +from entry import Entry +from blob import Entry_blob + +class Entry_intel_refcode(Entry_blob): + """Entry containing an Intel Reference Code file + + Properties / Entry arguments: + - filename: Filename of file to read into entry + + This file contains code for setting up the platform on some Intel systems. + This is executed by U-Boot when needed early during startup. A typical + filename is 'refcode.bin'. + + See README.x86 for information about x86 binary blobs. + """ + def __init__(self, section, etype, node): + Entry_blob.__init__(self, section, etype, node) + + def GetDefaultFilename(self): + return 'refcode.bin' From 97d20f69f53e7586394e48805f25f23d9a3ebaa8 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 2 Sep 2018 17:02:24 -0600 Subject: [PATCH 03/17] Enable CONFIG_TIMER_EARLY with bootstage In initr_bootstage() we call bootstage_mark_name() which ends up calling timer_get_us(). This call happens before initr_dm(), which inits driver model. On x86 we set gd->timer to NULL in the transition from board_init_f() to board_init_r(). See board_init_f_r() for this assignment. So U-Boot knows there is no timer available in the period immediately after relocation. On x86 the timer_get_us() call is implemented as calls to get_ticks() and get_tbclk(). Both of these call dm_timer_init() to set up the timer, if gd->timer is NULL and the early timer is not available. However dm_timer_init() cannot succeed before initr_dm() is called. So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable CONFIG_TIMER_EARLY. Update the Kconfig to handle this. Note: On most architectures we can rely on the pre-relocation memory still being available, so that gd->timer pointers to a valid timer device and everything works correctly. Admittedly this is not strictly correct since the timer device is set up by pre-relocation U-Boot, but normally this is fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot disappears in board_init_f_r() and any attempt to access it will hang. This is the reason why we must mark the timer as invalid when we get to board_init_f_r(). Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- drivers/timer/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index a7d600b..45a256a 100644 --- a/drivers/timer/Kconfig +++ b/drivers/timer/Kconfig @@ -30,6 +30,9 @@ config TPL_TIMER config TIMER_EARLY bool "Allow timer to be used early in U-Boot" depends on TIMER + # initr_bootstage() requires a timer and is called before initr_dm() + # so only the early timer is available + default y if X86 && BOOTSTAGE help In some cases the timer must be accessible before driver model is active. Examples include when using CONFIG_TRACE to trace U-Boot's From c74e3295ae4a5338f91e971aee1638fa08a9b97d Mon Sep 17 00:00:00 2001 From: Hannes Schmelzer Date: Thu, 11 Oct 2018 07:44:42 +0200 Subject: [PATCH 04/17] x86/bootm: fix error handling in boot_prep_linux(...) Once we get a zero pointer from load_zimage(...) we must bunch out instead of continue boot. Signed-off-by: Hannes Schmelzer Reviewed-by: Bin Meng --- arch/x86/lib/bootm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c index 54c22fe..832b1f9 100644 --- a/arch/x86/lib/bootm.c +++ b/arch/x86/lib/bootm.c @@ -116,6 +116,10 @@ static int boot_prep_linux(bootm_headers_t *images) char *base_ptr; base_ptr = (char *)load_zimage(data, len, &load_address); + if (!base_ptr) { + puts("## Kernel loading failed ...\n"); + goto error; + } images->os.load = load_address; cmd_line_dest = base_ptr + COMMAND_LINE_OFFSET; images->ep = (ulong)base_ptr; From a139cc1865aa7dd14e896596fa23938b303d7052 Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:01 -0700 Subject: [PATCH 05/17] x86: Specify -march=core2 to build 64-bit U-Boot proper With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image built for qemu-x86_64 target does not boot. It keeps resetting soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows that the reset happens inside env_callback_init(). 000000000113dd85 : 113dd85: 41 54 push %r12 113dd87: 55 push %rbp 113dd88: 31 c0 xor %eax,%eax 113dd8a: 53 push %rbx 113dd8b: 0f 57 c0 xorps %xmm0,%xmm0 Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) does not generate such instructions that utilizes SSE for this function - env_callback_init() and U-Boot boots without any issue. Explicitly specifying -march=core2 for newer GCC allows U-Boot proper to boot again. Examine assembly codes of env_callback_init and there is no SSE instruction in that function hence U-Boot continues to boot. core2 seems to be the oldest arch in GCC that supports 64-bit. Like 32-bit U-Boot build we use -march=i386 which is the most conservative cpu type so that the image can run on any x86 processor, let's do the same for the 64-bit U-Boot build. Signed-off-by: Bin Meng Reviewed-by: Heinrich Schuchardt Reviewed-by: Simon Glass --- arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index cc94071..576501e 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -23,7 +23,7 @@ endif ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64 +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64 endif PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden From dd4611dea435d77dcc8f695c35b15c4a2cc1e55f Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:02 -0700 Subject: [PATCH 06/17] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build 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 Reviewed-by: Heinrich Schuchardt Reviewed-by: Simon Glass --- 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 From 6feb2ff502882c687727e2f3e96dd40cb4284007 Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:03 -0700 Subject: [PATCH 07/17] x86: doc: Mention qemu-x86_64 support Currently only 32-bit U-Boot for QEMU x86 is documented. Mention the 64-bit support. Signed-off-by: Bin Meng Reviewed-by: Heinrich Schuchardt Reviewed-by: Simon Glass --- doc/README.x86 | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index 8cc4672..22bfbab 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 + +A 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 the 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 From 0e028bf970b4f99d10970f3fa851caf1783a3c34 Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:04 -0700 Subject: [PATCH 08/17] x86: doc: Remove stale sections of 64-bit support 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 Reviewed-by: Heinrich Schuchardt --- doc/README.x86 | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index 22bfbab..fa49cb8 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 194924d88184ed90fcbd5903404794ef60a84f9a Mon Sep 17 00:00:00 2001 From: Heinrich Schuchardt Date: Sat, 13 Oct 2018 20:52:05 -0700 Subject: [PATCH 09/17] x86: qemu: enable CONFIG_SPL_DM_RTC 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 Signed-off-by: Bin Meng --- 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 80df194f0165cb540a2a984f95dd2b37948f54d7 Mon Sep 17 00:00:00 2001 From: Heinrich Schuchardt Date: Sat, 13 Oct 2018 20:52:06 -0700 Subject: [PATCH 10/17] x86: detect unsupported relocation types 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 Reviewed-by: Bin Meng Signed-off-by: Bin Meng --- 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; From 2c78a79ec7fc0b3729e9f16214cf8e08e4664a0b Mon Sep 17 00:00:00 2001 From: Heinrich Schuchardt Date: Sat, 13 Oct 2018 20:52:07 -0700 Subject: [PATCH 11/17] x86: put global data pointer into the .data section On x86_64 the field global_data_ptr is assigned before relocation. As sections for uninitialized global data (.bss) overlap with the relocation sections (.rela) this destroys the relocation table and leads to spurious errors. Initialization forces the global_data_ptr into a section for initialized global data (.data) which cannot overlap any .rela section. Fixes: a160092a610f ("x86: Support global_data on x86_64") Signed-off-by: Heinrich Schuchardt Reviewed-by: Bin Meng Tested-by: Bin Meng Signed-off-by: Bin Meng --- arch/x86/cpu/x86_64/cpu.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c index 18b3e94..ef5e812 100644 --- a/arch/x86/cpu/x86_64/cpu.c +++ b/arch/x86/cpu/x86_64/cpu.c @@ -7,8 +7,14 @@ #include #include -/* Global declaration of gd */ -struct global_data *global_data_ptr; +/* + * Global declaration of gd. + * + * As we write to it before relocation we have to make sure it is not put into + * a .bss section which may overlap a .rela section. Initialization forces it + * into a .data section which cannot overlap any .rela section. + */ +struct global_data *global_data_ptr = (struct global_data *)~0; void arch_setup_gd(gd_t *new_gd) { From 49d5ff439c9ddc0ac124ea117fd33b194dca3142 Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:09 -0700 Subject: [PATCH 12/17] x86: Fix the mystery of printch() during 64-bit boot 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 Reviewed-by: Heinrich Schuchardt --- 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) From 6ce383640cf09d0fff9d6bddccf81dd37b2f344f Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:10 -0700 Subject: [PATCH 13/17] x86: tsc: Introduce config option for early timer frequency 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 in MHz 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 Reviewed-by: Simon Glass --- drivers/timer/Kconfig | 10 ++++++++++ drivers/timer/tsc_timer.c | 6 +++--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 45a256a..d012cf7 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 in MHz when used as the early timer" + depends on X86_TSC_TIMER + default 1000 + help + Sets the estimated CPU frequency in MHz when TSC is used as the + early 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..da7c812 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,8 +362,8 @@ static void tsc_timer_ensure_setup(bool stop) if (fast_calibrate) goto done; - if (stop) - panic("TSC frequency is ZERO"); + if (early) + fast_calibrate = CONFIG_X86_TSC_TIMER_EARLY_FREQ; else return; From a39f0554f4e9742bf99b8d1c30c2085889c0988d Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:11 -0700 Subject: [PATCH 14/17] x86: quark: Specify X86_TSC_TIMER_EARLY_FREQ Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as the early timer can be supported. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- arch/x86/cpu/quark/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/cpu/quark/Kconfig b/arch/x86/cpu/quark/Kconfig index 76f1592..3a18cb0 100644 --- a/arch/x86/cpu/quark/Kconfig +++ b/arch/x86/cpu/quark/Kconfig @@ -130,4 +130,8 @@ config SYS_CAR_SIZE Space in bytes in eSRAM used as Cache-As-ARM (CAR). Note this size must not exceed eSRAM's total size. +config X86_TSC_TIMER_EARLY_FREQ + int + default 400 + endif From 66a3a9cfd4a27d623a6d47be4a2d0379a9141ff6 Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:12 -0700 Subject: [PATCH 15/17] travis: Generate grub_x64.efi for qemu-x86_64 grub_x86.efi is for 32-bit QEMU. Generate the 64-bit one. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- .travis.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.travis.yml b/.travis.yml index 6697664..36c0f90 100644 --- a/.travis.yml +++ b/.travis.yml @@ -26,6 +26,7 @@ addons: - libpython-dev - iasl - grub-efi-ia32-bin + - grub-efi-amd64-bin - rpm2cpio - wget - device-tree-compiler @@ -49,6 +50,7 @@ install: - pip install pytest - pip install python-subunit - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd + - grub-mkimage -o ~/grub_x64.efi -O x86_64-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd - mkdir ~/grub2-arm - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di ) - mkdir ~/grub2-arm64 @@ -128,6 +130,7 @@ script: # value. - export UBOOT_TRAVIS_BUILD_DIR=`cd .. && pwd`/.bm-work/${TEST_PY_BD}; cp ~/grub_x86.efi $UBOOT_TRAVIS_BUILD_DIR/; + cp ~/grub_x64.efi $UBOOT_TRAVIS_BUILD_DIR/; cp ~/grub2-arm/usr/lib/grub2/arm-efi/grub.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm.efi; cp ~/grub2-arm64/usr/lib/grub2/arm64-efi/grub.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm64.efi; if [[ "${TEST_PY_BD}" != "" ]]; then From 68b89128110c2572688bb63963018de0d5289aaa Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:13 -0700 Subject: [PATCH 16/17] travis: Update to use QEMU 3.0.0 for testing This updates travis-ci to use QEMU 3.0.0 for testing. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 36c0f90..5714bb3 100644 --- a/.travis.yml +++ b/.travis.yml @@ -97,7 +97,7 @@ before_script: git clone git://git.qemu.org/qemu.git /tmp/qemu; pushd /tmp/qemu; git submodule update --init dtc && - git checkout v2.8.0-rc3 && + git checkout v3.0.0 && ./configure --prefix=/tmp/qemu-install --target-list=${QEMU_TARGET} && make -j4 all install; popd; From 3fdfca7a782e7d84bc14cd5d316b4894ec20dcec Mon Sep 17 00:00:00 2001 From: Bin Meng Date: Sat, 13 Oct 2018 20:52:14 -0700 Subject: [PATCH 17/17] travis: Add qemu-x86_64 target for test.py testing Add qemu-x86_64 to the list of targets we use for test.py runs. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- .travis.yml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/.travis.yml b/.travis.yml index 5714bb3..03ab70f 100644 --- a/.travis.yml +++ b/.travis.yml @@ -424,6 +424,14 @@ matrix: BUILDMAN="^qemu-x86$" TOOLCHAIN="i386" BUILD_ROM="yes" + - name: "test/py qemu-x86_64" + env: + - TEST_PY_BD="qemu-x86_64" + TEST_PY_TEST_SPEC="not sleep" + QEMU_TARGET="x86_64-softmmu" + BUILDMAN="^qemu-x86_64$" + TOOLCHAIN="i386" + BUILD_ROM="yes" - name: "test/py zynq_zc702" env: - TEST_PY_BD="zynq_zc702"