[U-Boot] [PATCH 1/9] x86: galileo: Fix boot failure
With latest codes on mainstream master, Intel Galileo board does not boot unfortunately. Git biset leads to b383d6c0 "bootstage: Convert to use malloc()".
Disable bootstage support to make it boot again. The root cause needs to be investigated however.
Fixes: b383d6c0 ("bootstage: Convert to use malloc()") Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
configs/galileo_defconfig | 3 --- 1 file changed, 3 deletions(-)
diff --git a/configs/galileo_defconfig b/configs/galileo_defconfig index c1849e3..f91890c 100644 --- a/configs/galileo_defconfig +++ b/configs/galileo_defconfig @@ -6,8 +6,6 @@ CONFIG_GENERATE_PIRQ_TABLE=y CONFIG_GENERATE_MP_TABLE=y CONFIG_GENERATE_ACPI_TABLE=y CONFIG_FIT=y -CONFIG_BOOTSTAGE=y -CONFIG_BOOTSTAGE_REPORT=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -25,7 +23,6 @@ CONFIG_CMD_DHCP=y # CONFIG_CMD_NFS is not set CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_CMD_BOOTSTAGE=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y
It was observed that when booting Linux kernel on Intel Cherry Hill board, unexpected crash happens quite randomly. Sometimes kernel just oops, while sometimes kernel throws MCE errors and hangs:
mce: [Hardware Error]: Machine check events logged mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: c400000000010151 mce: [Hardware Error]: TSC 0 ADDR 130f3f2c0 mce: [Hardware Error]: PROCESSOR 0:406c3 TIME 1508160686 SOCKET 0 APIC 0 microcode 363
This looks like a hardware error per mcelog. After debugging, it seems turning off turbo mode on the processor does not expose this behavior, although U-Boot runs OK with turbo mode on. Suspect it is related to an errata of Braswell processor.
To fix this, remove the Braswell cpu driver which does the turbo mode configuration, and switch to use the generic cpu-x86 driver. Also there is a configuration option in the FSP that turns on the turbo mode and that has been turned off too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/braswell/Makefile | 2 +- arch/x86/cpu/braswell/cpu.c | 170 ----------------------------------------- arch/x86/dts/cherryhill.dts | 9 +-- 3 files changed, 5 insertions(+), 176 deletions(-) delete mode 100644 arch/x86/cpu/braswell/cpu.c
diff --git a/arch/x86/cpu/braswell/Makefile b/arch/x86/cpu/braswell/Makefile index ddf6d28..4a639b8 100644 --- a/arch/x86/cpu/braswell/Makefile +++ b/arch/x86/cpu/braswell/Makefile @@ -4,4 +4,4 @@ # SPDX-License-Identifier: GPL-2.0+ #
-obj-y += braswell.o cpu.o early_uart.o fsp_configs.o +obj-y += braswell.o early_uart.o fsp_configs.o diff --git a/arch/x86/cpu/braswell/cpu.c b/arch/x86/cpu/braswell/cpu.c deleted file mode 100644 index 6ff9036..0000000 --- a/arch/x86/cpu/braswell/cpu.c +++ /dev/null @@ -1,170 +0,0 @@ -/* - * Copyright (C) 2017, Bin Meng bmeng.cn@gmail.com - * - * SPDX-License-Identifier: GPL-2.0+ - * - * Derived from arch/x86/cpu/baytrail/cpu.c - */ - -#include <common.h> -#include <cpu.h> -#include <dm.h> -#include <asm/cpu.h> -#include <asm/cpu_x86.h> -#include <asm/io.h> -#include <asm/lapic.h> -#include <asm/msr.h> -#include <asm/turbo.h> - -static const unsigned int braswell_bus_freq_table[] = { - 83333333, - 100000000, - 133333333, - 116666666, - 80000000, - 93333333, - 90000000, - 88900000, - 87500000 -}; - -static unsigned int braswell_bus_freq(void) -{ - msr_t clk_info = msr_read(MSR_BSEL_CR_OVERCLOCK_CONTROL); - - if ((clk_info.lo & 0xf) < (ARRAY_SIZE(braswell_bus_freq_table))) - return braswell_bus_freq_table[clk_info.lo & 0xf]; - - return 0; -} - -static unsigned long braswell_tsc_freq(void) -{ - msr_t platform_info; - ulong bclk = braswell_bus_freq(); - - if (!bclk) - return 0; - - platform_info = msr_read(MSR_PLATFORM_INFO); - - return bclk * ((platform_info.lo >> 8) & 0xff); -} - -static int braswell_get_info(struct udevice *dev, struct cpu_info *info) -{ - info->cpu_freq = braswell_tsc_freq(); - info->features = (1 << CPU_FEAT_L1_CACHE) | (1 << CPU_FEAT_MMU); - - return 0; -} - -static int braswell_get_count(struct udevice *dev) -{ - int ecx = 0; - - /* - * Use the algorithm described in Intel 64 and IA-32 Architectures - * Software Developer's Manual Volume 3 (3A, 3B & 3C): System - * Programming Guide, Jan-2015. Section 8.9.2: Hierarchical Mapping - * of CPUID Extended Topology Leaf. - */ - while (1) { - struct cpuid_result leaf_b; - - leaf_b = cpuid_ext(0xb, ecx); - - /* - * Braswell doesn't have hyperthreading so just determine the - * number of cores by from level type (ecx[15:8] == * 2) - */ - if ((leaf_b.ecx & 0xff00) == 0x0200) - return leaf_b.ebx & 0xffff; - - ecx++; - } - - return 0; -} - -static void braswell_set_max_freq(void) -{ - msr_t perf_ctl; - msr_t msr; - - /* Enable speed step */ - msr = msr_read(MSR_IA32_MISC_ENABLES); - msr.lo |= (1 << 16); - msr_write(MSR_IA32_MISC_ENABLES, msr); - - /* Enable Burst Mode */ - msr = msr_read(MSR_IA32_MISC_ENABLES); - msr.hi = 0; - msr_write(MSR_IA32_MISC_ENABLES, msr); - - /* - * Set guaranteed ratio [21:16] from IACORE_TURBO_RATIOS to - * bits [15:8] of the PERF_CTL - */ - msr = msr_read(MSR_IACORE_TURBO_RATIOS); - perf_ctl.lo = (msr.lo & 0x3f0000) >> 8; - - /* - * Set guaranteed vid [22:16] from IACORE_TURBO_VIDS to - * bits [7:0] of the PERF_CTL - */ - msr = msr_read(MSR_IACORE_TURBO_VIDS); - perf_ctl.lo |= (msr.lo & 0x7f0000) >> 16; - - perf_ctl.hi = 0; - msr_write(MSR_IA32_PERF_CTL, perf_ctl); -} - -static int braswell_probe(struct udevice *dev) -{ - debug("Init Braswell core\n"); - - /* - * On Braswell the turbo disable bit is actually scoped at the - * building-block level, not package. For non-BSP cores that are - * within a building block, enable turbo. The cores within the BSP's - * building block will just see it already enabled and move on. - */ - if (lapicid()) - turbo_enable(); - - /* Dynamic L2 shrink enable and threshold, clear SINGLE_PCTL bit 11 */ - msr_clrsetbits_64(MSR_PMG_CST_CONFIG_CONTROL, 0x3f080f, 0xe0008), - msr_clrsetbits_64(MSR_POWER_MISC, - ENABLE_ULFM_AUTOCM_MASK | ENABLE_INDP_AUTOCM_MASK, 0); - - /* Disable C1E */ - msr_clrsetbits_64(MSR_POWER_CTL, 2, 0); - msr_setbits_64(MSR_POWER_MISC, 0x44); - - /* Set this core to max frequency ratio */ - braswell_set_max_freq(); - - return 0; -} - -static const struct udevice_id braswell_ids[] = { - { .compatible = "intel,braswell-cpu" }, - { } -}; - -static const struct cpu_ops braswell_ops = { - .get_desc = cpu_x86_get_desc, - .get_info = braswell_get_info, - .get_count = braswell_get_count, - .get_vendor = cpu_x86_get_vendor, -}; - -U_BOOT_DRIVER(cpu_x86_braswell_drv) = { - .name = "cpu_x86_braswell", - .id = UCLASS_CPU, - .of_match = braswell_ids, - .bind = cpu_x86_bind, - .probe = braswell_probe, - .ops = &braswell_ops, -}; diff --git a/arch/x86/dts/cherryhill.dts b/arch/x86/dts/cherryhill.dts index 1ccb605..840a669 100644 --- a/arch/x86/dts/cherryhill.dts +++ b/arch/x86/dts/cherryhill.dts @@ -37,28 +37,28 @@
cpu@0 { device_type = "cpu"; - compatible = "intel,braswell-cpu"; + compatible = "cpu-x86"; reg = <0>; intel,apic-id = <0>; };
cpu@1 { device_type = "cpu"; - compatible = "intel,braswell-cpu"; + compatible = "cpu-x86"; reg = <1>; intel,apic-id = <2>; };
cpu@2 { device_type = "cpu"; - compatible = "intel,braswell-cpu"; + compatible = "cpu-x86"; reg = <2>; intel,apic-id = <4>; };
cpu@3 { device_type = "cpu"; - compatible = "intel,braswell-cpu"; + compatible = "cpu-x86"; reg = <3>; intel,apic-id = <6>; }; @@ -194,7 +194,6 @@ fsp,pmic-i2c-bus = <0>; fsp,enable-isp; fsp,isp-pci-dev-config = <ISP_PCI_DEV_CONFIG_2>; - fsp,turbo-mode; fsp,pnp-settings = <PNP_SETTING_POWER_AND_PERF>; fsp,sd-detect-chk; };
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
It was observed that when booting Linux kernel on Intel Cherry Hill board, unexpected crash happens quite randomly. Sometimes kernel just oops, while sometimes kernel throws MCE errors and hangs:
mce: [Hardware Error]: Machine check events logged mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: c400000000010151 mce: [Hardware Error]: TSC 0 ADDR 130f3f2c0 mce: [Hardware Error]: PROCESSOR 0:406c3 TIME 1508160686 SOCKET 0 APIC 0 microcode 363
This looks like a hardware error per mcelog. After debugging, it seems turning off turbo mode on the processor does not expose this behavior, although U-Boot runs OK with turbo mode on. Suspect it is related to an errata of Braswell processor.
To fix this, remove the Braswell cpu driver which does the turbo mode configuration, and switch to use the generic cpu-x86 driver. Also there is a configuration option in the FSP that turns on the turbo mode and that has been turned off too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Makefile | 2 +- arch/x86/cpu/braswell/cpu.c | 170 ----------------------------------------- arch/x86/dts/cherryhill.dts | 9 +-- 3 files changed, 5 insertions(+), 176 deletions(-) delete mode 100644 arch/x86/cpu/braswell/cpu.c
Oh dear, what a sad patch.
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
It was observed that when booting Linux kernel on Intel Cherry Hill board, unexpected crash happens quite randomly. Sometimes kernel just oops, while sometimes kernel throws MCE errors and hangs:
mce: [Hardware Error]: Machine check events logged mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: c400000000010151 mce: [Hardware Error]: TSC 0 ADDR 130f3f2c0 mce: [Hardware Error]: PROCESSOR 0:406c3 TIME 1508160686 SOCKET 0 APIC 0 microcode 363
This looks like a hardware error per mcelog. After debugging, it seems turning off turbo mode on the processor does not expose this behavior, although U-Boot runs OK with turbo mode on. Suspect it is related to an errata of Braswell processor.
To fix this, remove the Braswell cpu driver which does the turbo mode configuration, and switch to use the generic cpu-x86 driver. Also there is a configuration option in the FSP that turns on the turbo mode and that has been turned off too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Makefile | 2 +- arch/x86/cpu/braswell/cpu.c | 170 ----------------------------------------- arch/x86/dts/cherryhill.dts | 9 +-- 3 files changed, 5 insertions(+), 176 deletions(-) delete mode 100644 arch/x86/cpu/braswell/cpu.c
Oh dear, what a sad patch.
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
Imply does not work for a Kconfig choice. Update ENV_IS_IN_SPI_FLASH to be the default one for Intel Braswell.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/braswell/Kconfig | 1 - env/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/braswell/Kconfig b/arch/x86/cpu/braswell/Kconfig index 0e214a7..616f228 100644 --- a/arch/x86/cpu/braswell/Kconfig +++ b/arch/x86/cpu/braswell/Kconfig @@ -12,7 +12,6 @@ config INTEL_BRASWELL imply HAVE_INTEL_ME imply HAVE_VBT imply ENABLE_MRC_CACHE - imply ENV_IS_IN_SPI_FLASH imply AHCI_PCI imply ICH_SPI imply MMC diff --git a/env/Kconfig b/env/Kconfig index 024d4d7..3342806 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -17,6 +17,7 @@ choice default ENV_IS_IN_FLASH if SH && !CPU_SH4 default ENV_IS_IN_SPI_FLASH if ARMADA_XP default ENV_IS_IN_SPI_FLASH if INTEL_BAYTRAIL + default ENV_IS_IN_SPI_FLASH if INTEL_BRASWELL default ENV_IS_IN_SPI_FLASH if INTEL_BROADWELL default ENV_IS_IN_SPI_FLASH if NORTHBRIDGE_INTEL_IVYBRIDGE default ENV_IS_IN_SPI_FLASH if INTEL_QUARK
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Imply does not work for a Kconfig choice. Update ENV_IS_IN_SPI_FLASH to be the default one for Intel Braswell.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Kconfig | 1 - env/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Imply does not work for a Kconfig choice. Update ENV_IS_IN_SPI_FLASH to be the default one for Intel Braswell.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Kconfig | 1 - env/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
In an S3 resume path, MRC cache is mandatory. Enforce the dependency in the Kconfig.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c869ae2..b2ae865 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -664,6 +664,7 @@ endmenu
config HAVE_ACPI_RESUME bool "Enable ACPI S3 resume" + select ENABLE_MRC_CACHE help Select this to enable ACPI S3 resume. S3 is an ACPI-defined sleeping state where all system context is lost except system memory. U-Boot
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
In an S3 resume path, MRC cache is mandatory. Enforce the dependency in the Kconfig.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+)
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
In an S3 resume path, MRC cache is mandatory. Enforce the dependency in the Kconfig.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
This reverts commit 1e6ebee667da47fd3a87839a239a7574c66f5659.
It's not appropriate to call the Intel SPI driver specific stuff in the FSP codes. We may add a simple DTS property "intel,spi-lock-down" and let the Intel SPI driver call these stuff instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 9 --------- arch/x86/lib/fsp/fsp_common.c | 24 ------------------------ 2 files changed, 33 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b2ae865..98c56ad 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -402,15 +402,6 @@ config FSP_BROKEN_HOB do not overwrite the important boot service data which is used by FSP, otherwise the subsequent call to fsp_notify() will fail.
-config FSP_LOCKDOWN_SPI - bool - depends on HAVE_FSP - help - Some Intel FSP (like Braswell) does SPI lock-down during the call - to fsp_notify(INIT_PHASE_BOOT). This option should be turned on - for such FSP and U-Boot will configure the SPI opcode registers - before the lock-down. - config ENABLE_MRC_CACHE bool "Enable MRC cache" depends on !EFI && !SYS_COREBOOT diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c index 1714d13..3397bb8 100644 --- a/arch/x86/lib/fsp/fsp_common.c +++ b/arch/x86/lib/fsp/fsp_common.c @@ -19,8 +19,6 @@
DECLARE_GLOBAL_DATA_PTR;
-extern void ich_spi_config_opcode(struct udevice *dev); - int checkcpu(void) { return 0; @@ -51,28 +49,6 @@ void board_final_cleanup(void) { u32 status;
-#ifdef CONFIG_FSP_LOCKDOWN_SPI - struct udevice *dev; - - /* - * Some Intel FSP (like Braswell) does SPI lock-down during the call - * to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, - * it's bootloader's responsibility to configure the SPI controller's - * opcode registers properly otherwise SPI controller driver doesn't - * know how to communicate with the SPI flash device. - * - * Note we cannot do such configuration elsewhere (eg: during the SPI - * controller driver's probe() routine), because: - * - * 1). U-Boot SPI controller driver does not set the lock-down bit - * 2). Any SPI transfer will corrupt the contents of these registers - * - * Hence we have to do it right here before SPI lock-down bit is set. - */ - if (!uclass_first_device_err(UCLASS_SPI, &dev)) - ich_spi_config_opcode(dev); -#endif - /* call into FspNotify */ debug("Calling into FSP (notify phase INIT_PHASE_BOOT): "); status = fsp_notify(NULL, INIT_PHASE_BOOT);
On Thu, Oct 19, 2017 at 9:20 AM, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit 1e6ebee667da47fd3a87839a239a7574c66f5659.
It's not appropriate to call the Intel SPI driver specific stuff in the FSP codes. We may add a simple DTS property "intel,spi-lock-down" and let the Intel SPI driver call these stuff instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 9 --------- arch/x86/lib/fsp/fsp_common.c | 24 ------------------------ 2 files changed, 33 deletions(-)
applied to u-boot-x86, thanks!
Some Intel FSP (like Braswell) does SPI lock-down during the call to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, it's bootloader's responsibility to configure the SPI controller's opcode registers properly otherwise SPI controller driver doesn't know how to communicate with the SPI flash device.
Rather than passively doing the opcode configuration, let's add a simple DTS property "intel,spi-lock-down" and let the driver call the opcode configuration function if required by such FSP.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/spi/ich.c | 22 ++++++++++++++++++++++ drivers/spi/ich.h | 1 + 2 files changed, 23 insertions(+)
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c index 22fc83d..927bbd7 100644 --- a/drivers/spi/ich.c +++ b/drivers/spi/ich.c @@ -184,6 +184,19 @@ static inline void spi_use_in(struct spi_trans *trans, unsigned bytes) trans->bytesin -= bytes; }
+static void spi_lock_down(struct ich_spi_platdata *plat, void *sbase) +{ + if (plat->ich_version == ICHV_7) { + struct ich7_spi_regs *ich7_spi = sbase; + + setbits_le16(&ich7_spi->spis, SPIS_LOCK); + } else if (plat->ich_version == ICHV_9) { + struct ich9_spi_regs *ich9_spi = sbase; + + setbits_le16(&ich9_spi->hsfs, HSFS_FLOCKDN); + } +} + static bool spi_lock_status(struct ich_spi_platdata *plat, void *sbase) { int lock = 0; @@ -592,6 +605,12 @@ static int ich_spi_probe(struct udevice *dev) return ret; }
+ /* Lock down SPI controller settings if required */ + if (plat->lockdown) { + ich_spi_config_opcode(dev); + spi_lock_down(plat, priv->base); + } + priv->cur_speed = priv->max_speed;
return 0; @@ -662,6 +681,9 @@ static int ich_spi_ofdata_to_platdata(struct udevice *dev) plat->ich_version = ICHV_9; }
+ plat->lockdown = fdtdec_get_bool(gd->fdt_blob, node, + "intel,spi-lock-down"); + return ret; }
diff --git a/drivers/spi/ich.h b/drivers/spi/ich.h index c867c57..06b7fb9 100644 --- a/drivers/spi/ich.h +++ b/drivers/spi/ich.h @@ -174,6 +174,7 @@ enum ich_version {
struct ich_spi_platdata { enum ich_version ich_version; /* Controller version, 7 or 9 */ + bool lockdown; /* lock down controller settings? */ };
struct ich_spi_priv {
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Some Intel FSP (like Braswell) does SPI lock-down during the call to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, it's bootloader's responsibility to configure the SPI controller's opcode registers properly otherwise SPI controller driver doesn't know how to communicate with the SPI flash device.
Rather than passively doing the opcode configuration, let's add a simple DTS property "intel,spi-lock-down" and let the driver call the opcode configuration function if required by such FSP.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/spi/ich.c | 22 ++++++++++++++++++++++ drivers/spi/ich.h | 1 + 2 files changed, 23 insertions(+)
Does this go in a binding file somewhere?
Reviewed-by: Simon Glass sjg@chromium.org
Hi Simon,
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Some Intel FSP (like Braswell) does SPI lock-down during the call to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, it's bootloader's responsibility to configure the SPI controller's opcode registers properly otherwise SPI controller driver doesn't know how to communicate with the SPI flash device.
Rather than passively doing the opcode configuration, let's add a simple DTS property "intel,spi-lock-down" and let the driver call the opcode configuration function if required by such FSP.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/spi/ich.c | 22 ++++++++++++++++++++++ drivers/spi/ich.h | 1 + 2 files changed, 23 insertions(+)
Does this go in a binding file somewhere?
Looks there is no binding file for Intel SPI controller driver. We will need create one.
Reviewed-by: Simon Glass sjg@chromium.org
Regards, Bin
On Mon, Oct 23, 2017 at 9:32 AM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Some Intel FSP (like Braswell) does SPI lock-down during the call to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, it's bootloader's responsibility to configure the SPI controller's opcode registers properly otherwise SPI controller driver doesn't know how to communicate with the SPI flash device.
Rather than passively doing the opcode configuration, let's add a simple DTS property "intel,spi-lock-down" and let the driver call the opcode configuration function if required by such FSP.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/spi/ich.c | 22 ++++++++++++++++++++++ drivers/spi/ich.h | 1 + 2 files changed, 23 insertions(+)
Does this go in a binding file somewhere?
Looks there is no binding file for Intel SPI controller driver. We will need create one.
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
Intel Braswell FSP requires SPI controller settings to be locked down, let's do this in the chrryhill.dts and remove previous Kconfig option.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/braswell/Kconfig | 4 ---- arch/x86/dts/cherryhill.dts | 1 + 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/braswell/Kconfig b/arch/x86/cpu/braswell/Kconfig index 616f228..31ac279 100644 --- a/arch/x86/cpu/braswell/Kconfig +++ b/arch/x86/cpu/braswell/Kconfig @@ -31,8 +31,4 @@ config FSP_ADDR hex default 0xfff20000
-config FSP_LOCKDOWN_SPI - bool - default y - endif diff --git a/arch/x86/dts/cherryhill.dts b/arch/x86/dts/cherryhill.dts index 840a669..41e72f3 100644 --- a/arch/x86/dts/cherryhill.dts +++ b/arch/x86/dts/cherryhill.dts @@ -143,6 +143,7 @@ #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich9-spi"; + intel,spi-lock-down;
spi-flash@0 { #address-cells = <1>;
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Intel Braswell FSP requires SPI controller settings to be locked down, let's do this in the chrryhill.dts and remove previous Kconfig option.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Kconfig | 4 ---- arch/x86/dts/cherryhill.dts | 1 + 2 files changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
Intel Braswell FSP requires SPI controller settings to be locked down, let's do this in the chrryhill.dts and remove previous Kconfig option.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/braswell/Kconfig | 4 ---- arch/x86/dts/cherryhill.dts | 1 + 2 files changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
On some platforms (eg: Braswell), the FSP will not produce the graphics info HOB unless you plug some cables to the display interface (eg: HDMI) on the board. Add such notes in the FSP video driver.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/lib/fsp/fsp_graphics.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c index a19b067..af71276 100644 --- a/arch/x86/lib/fsp/fsp_graphics.c +++ b/arch/x86/lib/fsp/fsp_graphics.c @@ -37,6 +37,10 @@ static int save_vesa_mode(struct vesa_mode_info *vesa) /* * If there is no graphics info structure, bail out and keep * running on the serial console. + * + * Note: on some platforms (eg: Braswell), the FSP will not produce + * the graphics info HOB unless you plug some cables to the display + * interface (eg: HDMI) on the board. */ if (!ginfo) { debug("FSP graphics hand-off block not found\n");
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
On some platforms (eg: Braswell), the FSP will not produce the graphics info HOB unless you plug some cables to the display interface (eg: HDMI) on the board. Add such notes in the FSP video driver.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/lib/fsp/fsp_graphics.c | 4 ++++ 1 file changed, 4 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:20, Bin Meng bmeng.cn@gmail.com wrote:
On some platforms (eg: Braswell), the FSP will not produce the graphics info HOB unless you plug some cables to the display interface (eg: HDMI) on the board. Add such notes in the FSP video driver.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/lib/fsp/fsp_graphics.c | 4 ++++ 1 file changed, 4 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
The supported sleep states are generic on Intel processors. Move the ASL definition to the common place.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl | 0 arch/x86/include/asm/arch-baytrail/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/sleepstates.asl | 10 ---------- 4 files changed, 2 insertions(+), 12 deletions(-) rename arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl (100%) delete mode 100644 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl
diff --git a/arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl b/arch/x86/include/asm/acpi/sleepstates.asl similarity index 100% rename from arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl rename to arch/x86/include/asm/acpi/sleepstates.asl diff --git a/arch/x86/include/asm/arch-baytrail/acpi/platform.asl b/arch/x86/include/asm/arch-baytrail/acpi/platform.asl index a80d2c0..cf3de7c 100644 --- a/arch/x86/include/asm/arch-baytrail/acpi/platform.asl +++ b/arch/x86/include/asm/arch-baytrail/acpi/platform.asl @@ -36,4 +36,4 @@ Scope (_SB) }
/* Chipset specific sleep states */ -#include "sleepstates.asl" +#include <asm/acpi/sleepstates.asl> diff --git a/arch/x86/include/asm/arch-quark/acpi/platform.asl b/arch/x86/include/asm/arch-quark/acpi/platform.asl index 1ecf153..db59c46 100644 --- a/arch/x86/include/asm/arch-quark/acpi/platform.asl +++ b/arch/x86/include/asm/arch-quark/acpi/platform.asl @@ -33,4 +33,4 @@ Scope (_SB) }
/* Chipset specific sleep states */ -#include "sleepstates.asl" +#include <asm/acpi/sleepstates.asl> diff --git a/arch/x86/include/asm/arch-quark/acpi/sleepstates.asl b/arch/x86/include/asm/arch-quark/acpi/sleepstates.asl deleted file mode 100644 index 63c82fa..0000000 --- a/arch/x86/include/asm/arch-quark/acpi/sleepstates.asl +++ /dev/null @@ -1,10 +0,0 @@ -/* - * Copyright (C) 2016, Bin Meng bmeng.cn@gmail.com - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -Name(_S0, Package() {0x0, 0x0, 0x0, 0x0}) -Name(_S3, Package() {0x5, 0x0, 0x0, 0x0}) -Name(_S4, Package() {0x6, 0x0, 0x0, 0x0}) -Name(_S5, Package() {0x7, 0x0, 0x0, 0x0})
On 19 October 2017 at 03:21, Bin Meng bmeng.cn@gmail.com wrote:
The supported sleep states are generic on Intel processors. Move the ASL definition to the common place.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl | 0 arch/x86/include/asm/arch-baytrail/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/sleepstates.asl | 10 ---------- 4 files changed, 2 insertions(+), 12 deletions(-) rename arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl (100%) delete mode 100644 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass sjg@chromium.org wrote:
On 19 October 2017 at 03:21, Bin Meng bmeng.cn@gmail.com wrote:
The supported sleep states are generic on Intel processors. Move the ASL definition to the common place.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl | 0 arch/x86/include/asm/arch-baytrail/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/platform.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/sleepstates.asl | 10 ---------- 4 files changed, 2 insertions(+), 12 deletions(-) rename arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl (100%) delete mode 100644 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
On Thu, Oct 19, 2017 at 9:20 AM, Bin Meng bmeng.cn@gmail.com wrote:
With latest codes on mainstream master, Intel Galileo board does not boot unfortunately. Git biset leads to b383d6c0 "bootstage: Convert to use malloc()".
Disable bootstage support to make it boot again. The root cause needs to be investigated however.
Fixes: b383d6c0 ("bootstage: Convert to use malloc()") Signed-off-by: Bin Meng bmeng.cn@gmail.com
configs/galileo_defconfig | 3 --- 1 file changed, 3 deletions(-)
applied to u-boot-x86, thanks!
participants (2)
-
Bin Meng -
Simon Glass