[U-Boot] [PATCH 00/13] x86: Provide a common MRC cache library and enable it for FSP
This series moves existing MRC cache codes in the ivybridge cpu diretory to a common place and makes some changes so that every x86 board benefits from it. It also updates FSP support codes to pass MRC cache data to fsp_init() to speed up boot time.
Currently tested on Intel Bayley Bay board. Minnow Max board should work as it uses the same FSP that Bayley Bay uses. For Chromebook I cannot test that, but I see Simon added a TODO in the codes below:
/* * TODO(sjg@chromium.org): Skip this for now as it causes boot * problems */ if (0) { pei_data->mrc_input = mrc_cache->data; pei_data->mrc_input_len = mrc_cache->data_size; }
I have no idea what breaks the MRC cache on the Chromebook board. Simon, you may retest this on top of this series to see if things go better.
Bin Meng (13): x86: Add ENABLE_MRC_CACHE Kconfig option x86: Move mrccache.[c|h] to a common place x86: Do sanity test on the cache record in mrccache_update() x86: Add various minor tidy-ups in mrccache codes x86: Add more common routines to manipulate mrc cache x86: ivybridge: Use APIs provided in the mrccache lib x86: Use struct mrc_region to describe a mrc region x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init() x86: baytrail: Save mrc cache to spi flash x86: Enable mrc cache for bayleybay and minnowmax x86: baytrail: Issue full system reset in reset_cpu() x86: Remove unused rw-mrc-cache properties in the link and panther dts files x86: ivybridge: Correct two typos for MRC
arch/x86/Kconfig | 8 ++ arch/x86/cpu/baytrail/valleyview.c | 25 +++++ arch/x86/cpu/ivybridge/Makefile | 1 - arch/x86/cpu/ivybridge/sdram.c | 120 ++--------------------- arch/x86/dts/bayleybay.dts | 6 ++ arch/x86/dts/chromebook_link.dts | 2 - arch/x86/dts/chromebox_panther.dts | 3 - arch/x86/dts/minnowmax.dts | 6 ++ arch/x86/include/asm/arch-ivybridge/mrccache.h | 51 ---------- arch/x86/include/asm/mrccache.h | 107 +++++++++++++++++++++ arch/x86/lib/Makefile | 1 + arch/x86/lib/fsp/fsp_common.c | 30 +++++- arch/x86/lib/fsp/fsp_dram.c | 6 ++ arch/x86/{cpu/ivybridge => lib}/mrccache.c | 128 +++++++++++++++++++++---- configs/bayleybay_defconfig | 1 + configs/chromebook_link_defconfig | 1 + configs/chromebox_panther_defconfig | 1 + configs/minnowmax_defconfig | 1 + doc/README.x86 | 1 + 19 files changed, 313 insertions(+), 186 deletions(-) delete mode 100644 arch/x86/include/asm/arch-ivybridge/mrccache.h create mode 100644 arch/x86/include/asm/mrccache.h rename arch/x86/{cpu/ivybridge => lib}/mrccache.c (51%)
Create a Kconfig option for enabling MRC cache.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index bf09b21..f92082d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -239,6 +239,14 @@ config FSP_SYS_MALLOC_F_LEN help Additional size of malloc() pool before relocation.
+config ENABLE_MRC_CACHE + bool "Enable MRC cache" + depends on !EFI && !SYS_COREBOOT + help + Enable this feature to cause MRC data to be cached in NV storage + to be used for speeding up boot time on future reboots and/or + power cycles. + config SMP bool "Enable Symmetric Multiprocessing" default n
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Create a Kconfig option for enabling MRC cache.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Create a Kconfig option for enabling MRC cache.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
mrccache implementation can be common for all boards. Move it from ivybridge cpu directory to the common lib directory.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/ivybridge/Makefile | 1 - arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/{arch-ivybridge => }/mrccache.h | 0 arch/x86/lib/Makefile | 1 + arch/x86/{cpu/ivybridge => lib}/mrccache.c | 3 +-- configs/chromebook_link_defconfig | 1 + configs/chromebox_panther_defconfig | 1 + 7 files changed, 5 insertions(+), 4 deletions(-) rename arch/x86/include/asm/{arch-ivybridge => }/mrccache.h (100%) rename arch/x86/{cpu/ivybridge => lib}/mrccache.c (98%)
diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile index 3576b83..0c7efae 100644 --- a/arch/x86/cpu/ivybridge/Makefile +++ b/arch/x86/cpu/ivybridge/Makefile @@ -14,7 +14,6 @@ obj-y += lpc.o obj-y += me_status.o obj-y += model_206ax.o obj-y += microcode_intel.o -obj-y += mrccache.o obj-y += northbridge.o obj-y += pch.o obj-y += pci.o diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c index 7f3b13d..10fbe5f 100644 --- a/arch/x86/cpu/ivybridge/sdram.c +++ b/arch/x86/cpu/ivybridge/sdram.c @@ -21,10 +21,10 @@ #include <asm/processor.h> #include <asm/gpio.h> #include <asm/global_data.h> +#include <asm/mrccache.h> #include <asm/mtrr.h> #include <asm/pci.h> #include <asm/arch/me.h> -#include <asm/arch/mrccache.h> #include <asm/arch/pei_data.h> #include <asm/arch/pch.h> #include <asm/post.h> diff --git a/arch/x86/include/asm/arch-ivybridge/mrccache.h b/arch/x86/include/asm/mrccache.h similarity index 100% rename from arch/x86/include/asm/arch-ivybridge/mrccache.h rename to arch/x86/include/asm/mrccache.h diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index fa95944..2f82a21 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -17,6 +17,7 @@ obj-y += init_helpers.o obj-y += interrupts.o obj-y += lpc-uclass.o obj-y += mpspec.o +obj-$(CONFIG_ENABLE_MRC_CACHE) += mrccache.o obj-y += cmd_mtrr.o obj-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o obj-$(CONFIG_SYS_PCAT_TIMER) += pcat_timer.o diff --git a/arch/x86/cpu/ivybridge/mrccache.c b/arch/x86/lib/mrccache.c similarity index 98% rename from arch/x86/cpu/ivybridge/mrccache.c rename to arch/x86/lib/mrccache.c index 9205494..ec0d2cb 100644 --- a/arch/x86/cpu/ivybridge/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -12,8 +12,7 @@ #include <net.h> #include <spi.h> #include <spi_flash.h> -#include <asm/arch/mrccache.h> -#include <asm/arch/sandybridge.h> +#include <asm/mrccache.h>
static struct mrc_data_container *next_mrc_block( struct mrc_data_container *mrc_cache) diff --git a/configs/chromebook_link_defconfig b/configs/chromebook_link_defconfig index 21e85f3..fbecf8b 100644 --- a/configs/chromebook_link_defconfig +++ b/configs/chromebook_link_defconfig @@ -4,6 +4,7 @@ CONFIG_VENDOR_GOOGLE=y CONFIG_DEFAULT_DEVICE_TREE="chromebook_link" CONFIG_TARGET_CHROMEBOOK_LINK=y CONFIG_HAVE_MRC=y +CONFIG_ENABLE_MRC_CACHE=y CONFIG_HAVE_VGA_BIOS=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set diff --git a/configs/chromebox_panther_defconfig b/configs/chromebox_panther_defconfig index 70a22a9..663aab0 100644 --- a/configs/chromebox_panther_defconfig +++ b/configs/chromebox_panther_defconfig @@ -3,6 +3,7 @@ CONFIG_VENDOR_GOOGLE=y CONFIG_DEFAULT_DEVICE_TREE="chromebox_panther" CONFIG_TARGET_CHROMEBOX_PANTHER=y CONFIG_HAVE_MRC=y +CONFIG_ENABLE_MRC_CACHE=y CONFIG_HAVE_VGA_BIOS=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
mrccache implementation can be common for all boards. Move it from ivybridge cpu directory to the common lib directory.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/Makefile | 1 - arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/{arch-ivybridge => }/mrccache.h | 0 arch/x86/lib/Makefile | 1 + arch/x86/{cpu/ivybridge => lib}/mrccache.c | 3 +-- configs/chromebook_link_defconfig | 1 + configs/chromebox_panther_defconfig | 1 + 7 files changed, 5 insertions(+), 4 deletions(-) rename arch/x86/include/asm/{arch-ivybridge => }/mrccache.h (100%) rename arch/x86/{cpu/ivybridge => lib}/mrccache.c (98%)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
mrccache implementation can be common for all boards. Move it from ivybridge cpu directory to the common lib directory.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/Makefile | 1 - arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/{arch-ivybridge => }/mrccache.h | 0 arch/x86/lib/Makefile | 1 + arch/x86/{cpu/ivybridge => lib}/mrccache.c | 3 +-- configs/chromebook_link_defconfig | 1 + configs/chromebox_panther_defconfig | 1 + 7 files changed, 5 insertions(+), 4 deletions(-) rename arch/x86/include/asm/{arch-ivybridge => }/mrccache.h (100%) rename arch/x86/{cpu/ivybridge => lib}/mrccache.c (98%)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
For the cache record to write in mrccache_update(), we should perform a sanity test to see if it is a valid one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/include/asm/mrccache.h | 2 +- arch/x86/lib/mrccache.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mrccache.h b/arch/x86/include/asm/mrccache.h index 1d50ebb..ff41b8a 100644 --- a/arch/x86/include/asm/mrccache.h +++ b/arch/x86/include/asm/mrccache.h @@ -43,7 +43,7 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); * @entry: Position and size of MRC cache in SPI flash * @cur: Record to write * @return 0 if updated, -EEXIST if the record is the same as the latest - * record, other error if SPI write failed + * record, -EINVAL if the record is not valid, other error if SPI write failed */ int mrccache_update(struct udevice *sf, struct fmap_entry *entry, struct mrc_data_container *cur); diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c index ec0d2cb..6dd3b5e 100644 --- a/arch/x86/lib/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -112,6 +112,9 @@ int mrccache_update(struct udevice *sf, struct fmap_entry *entry, ulong base_addr; int ret;
+ if (!is_mrc_cache(cur)) + return -EINVAL; + /* Find the last used block */ base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset; debug("Updating MRC cache data\n");
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
For the cache record to write in mrccache_update(), we should perform a sanity test to see if it is a valid one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 2 +- arch/x86/lib/mrccache.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
For the cache record to write in mrccache_update(), we should perform a sanity test to see if it is a valid one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 2 +- arch/x86/lib/mrccache.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Fix some nits, improve some comments and reorder some codes a little bit.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/include/asm/mrccache.h | 20 ++++++++++---------- arch/x86/lib/mrccache.c | 14 ++++++-------- 2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/mrccache.h b/arch/x86/include/asm/mrccache.h index ff41b8a..2fd9082 100644 --- a/arch/x86/include/asm/mrccache.h +++ b/arch/x86/include/asm/mrccache.h @@ -1,17 +1,17 @@ /* - * Copyright (c) 2014 Google, Inc + * Copyright (C) 2014 Google, Inc * * SPDX-License-Identifier: GPL-2.0+ */
-#ifndef _ASM_ARCH_MRCCACHE_H -#define _ASM_ARCH_MRCCACHE_H +#ifndef _ASM_MRCCACHE_H +#define _ASM_MRCCACHE_H
#define MRC_DATA_ALIGN 0x1000 -#define MRC_DATA_SIGNATURE (('M' << 0) | ('R' << 8) | ('C' << 16) | \ - ('D'<<24)) +#define MRC_DATA_SIGNATURE (('M' << 0) | ('R' << 8) | \ + ('C' << 16) | ('D'<<24))
-__packed struct mrc_data_container { +struct __packed mrc_data_container { u32 signature; /* "MRCD" */ u32 data_size; /* Size of the 'data' field */ u32 checksum; /* IP style checksum */ @@ -28,7 +28,7 @@ struct udevice; * This searches the MRC cache region looking for the latest record to use * for setting up SDRAM * - * @entry: Information about the position and size of the MRC cache + * @entry: Position and size of MRC cache in SPI flash * @return pointer to latest record, or NULL if none */ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); @@ -36,8 +36,8 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); /** * mrccache_update() - update the MRC cache with a new record * - * This writes a new record to the end of the MRC cache. If the new record is - * the same as the latest record then the write is skipped + * This writes a new record to the end of the MRC cache region. If the new + * record is the same as the latest record then the write is skipped * * @sf: SPI flash to write to * @entry: Position and size of MRC cache in SPI flash @@ -48,4 +48,4 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); int mrccache_update(struct udevice *sf, struct fmap_entry *entry, struct mrc_data_container *cur);
-#endif +#endif /* _ASM_MRCCACHE_H */ diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c index 6dd3b5e..1c4b5a8 100644 --- a/arch/x86/lib/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -1,5 +1,5 @@ /* - * From Coreboot src/southbridge/intel/bd82x6x/mrccache.c + * From coreboot src/southbridge/intel/bd82x6x/mrccache.c * * Copyright (C) 2014 Google Inc. * @@ -15,17 +15,19 @@ #include <asm/mrccache.h>
static struct mrc_data_container *next_mrc_block( - struct mrc_data_container *mrc_cache) + struct mrc_data_container *cache) { /* MRC data blocks are aligned within the region */ - u32 mrc_size = sizeof(*mrc_cache) + mrc_cache->data_size; + u32 mrc_size = sizeof(*cache) + cache->data_size; + u8 *region_ptr = (u8 *)cache; + if (mrc_size & (MRC_DATA_ALIGN - 1UL)) { mrc_size &= ~(MRC_DATA_ALIGN - 1UL); mrc_size += MRC_DATA_ALIGN; }
- u8 *region_ptr = (u8 *)mrc_cache; region_ptr += mrc_size; + return (struct mrc_data_container *)region_ptr; }
@@ -34,10 +36,6 @@ static int is_mrc_cache(struct mrc_data_container *cache) return cache && (cache->signature == MRC_DATA_SIGNATURE); }
-/* - * Find the largest index block in the MRC cache. Return NULL if none is - * found. - */ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry) { struct mrc_data_container *cache, *next;
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Fix some nits, improve some comments and reorder some codes a little bit.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 20 ++++++++++---------- arch/x86/lib/mrccache.c | 14 ++++++-------- 2 files changed, 16 insertions(+), 18 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Fix some nits, improve some comments and reorder some codes a little bit.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 20 ++++++++++---------- arch/x86/lib/mrccache.c | 14 ++++++-------- 2 files changed, 16 insertions(+), 18 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
This adds mrccache_reserve(), mrccache_get_region() and mrccache_save() APIs to the mrccache codes. They are ported from the ivybridge implementation, but with some changes. For example, in the mrccache_reserve(), ivybridge version only reserves the pure MRC data, which causes additional malloc() when saving the cache as the save API needs some meta data. Now we change it to save the whole MRC date plus the meta data to elinimate the need for the malloc() later.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/include/asm/mrccache.h | 51 +++++++++++++++++++++++ arch/x86/lib/mrccache.c | 89 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+)
diff --git a/arch/x86/include/asm/mrccache.h b/arch/x86/include/asm/mrccache.h index 2fd9082..bcf7117 100644 --- a/arch/x86/include/asm/mrccache.h +++ b/arch/x86/include/asm/mrccache.h @@ -1,5 +1,6 @@ /* * Copyright (C) 2014 Google, Inc + * Copyright (C) 2015 Bin Meng bmeng.cn@gmail.com * * SPDX-License-Identifier: GPL-2.0+ */ @@ -11,6 +12,8 @@ #define MRC_DATA_SIGNATURE (('M' << 0) | ('R' << 8) | \ ('C' << 16) | ('D'<<24))
+#define MRC_DATA_HEADER_SIZE 32 + struct __packed mrc_data_container { u32 signature; /* "MRCD" */ u32 data_size; /* Size of the 'data' field */ @@ -48,4 +51,52 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); int mrccache_update(struct udevice *sf, struct fmap_entry *entry, struct mrc_data_container *cur);
+/** + * mrccache_reserve() - reserve MRC data on the stack + * + * This copies MRC data pointed by gd->arch.mrc_output to a new place on the + * stack with length gd->arch.mrc_output_len, and updates gd->arch.mrc_output + * to point to the new place once the migration is done. + * + * This routine should be called by reserve_arch() before U-Boot is relocated + * when MRC cache is enabled. + * + * @return 0 always + */ +int mrccache_reserve(void); + +/** + * mrccache_get_region() - get MRC region on the SPI flash + * + * This gets MRC region whose offset and size are described in the device tree + * as a subnode to the SPI flash. If a non-NULL device pointer is supplied, + * this also probes the SPI flash device and returns its device pointer for + * the caller to use later. + * + * Be careful when calling this routine with a non-NULL device pointer: + * - driver model initialization must be complete + * - calling in the pre-relocation phase may bring some side effects during + * the SPI flash device probe (eg: for SPI controllers on a PCI bus, it + * triggers PCI bus enumeration during which insufficient memory issue + * might be exposed and it causes subsequent SPI flash probe fails). + * + * @devp: Returns pointer to the SPI flash device + * @entry: Position and size of MRC cache in SPI flash + * @return 0 if success, -ENOENT if SPI flash node does not exist in the + * device tree, -EPERM if MRC region subnode does not exist in the device + * tree, -EINVAL if MRC region properties format is incorrect, other error + * if SPI flash probe failed. + */ +int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry); + +/** + * mrccache_save() - save MRC data to the SPI flash + * + * This saves MRC data stored previously by gd->arch.mrc_output to a proper + * place within the MRC region on the SPI flash. + * + * @return 0 if saved to SPI flash successfully, other error if failed + */ +int mrccache_save(void); + #endif /* _ASM_MRCCACHE_H */ diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c index 1c4b5a8..0efae6d 100644 --- a/arch/x86/lib/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -2,11 +2,13 @@ * From coreboot src/southbridge/intel/bd82x6x/mrccache.c * * Copyright (C) 2014 Google Inc. + * Copyright (C) 2015 Bin Meng bmeng.cn@gmail.com * * SPDX-License-Identifier: GPL-2.0 */
#include <common.h> +#include <dm.h> #include <errno.h> #include <fdtdec.h> #include <net.h> @@ -14,6 +16,8 @@ #include <spi_flash.h> #include <asm/mrccache.h>
+DECLARE_GLOBAL_DATA_PTR; + static struct mrc_data_container *next_mrc_block( struct mrc_data_container *cache) { @@ -155,3 +159,88 @@ int mrccache_update(struct udevice *sf, struct fmap_entry *entry,
return 0; } + +int mrccache_reserve(void) +{ + struct mrc_data_container *cache; + u16 checksum; + + if (!gd->arch.mrc_output_len) + return 0; + + /* adjust stack pointer to store pure cache data plus the header */ + gd->start_addr_sp -= (gd->arch.mrc_output_len + MRC_DATA_HEADER_SIZE); + cache = (struct mrc_data_container *)gd->start_addr_sp; + + cache->signature = MRC_DATA_SIGNATURE; + cache->data_size = gd->arch.mrc_output_len; + checksum = compute_ip_checksum(gd->arch.mrc_output, cache->data_size); + debug("Saving %d bytes for MRC output data, checksum %04x\n", + cache->data_size, checksum); + cache->checksum = checksum; + cache->reserved = 0; + memcpy(cache->data, gd->arch.mrc_output, cache->data_size); + + /* gd->arch.mrc_output now points to the container */ + gd->arch.mrc_output = (char *)cache; + + gd->start_addr_sp &= ~0xf; + + return 0; +} + +int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry) +{ + const void *blob = gd->fdt_blob; + int node, mrc_node; + int ret; + + /* Find the flash chip within the SPI controller node */ + node = fdtdec_next_compatible(blob, 0, COMPAT_GENERIC_SPI_FLASH); + if (node < 0) + return -ENOENT; + + /* Find the place where we put the MRC cache */ + mrc_node = fdt_subnode_offset(blob, node, "rw-mrc-cache"); + if (mrc_node < 0) + return -EPERM; + + if (fdtdec_read_fmap_entry(blob, mrc_node, "rm-mrc-cache", entry)) + return -EINVAL; + + if (devp) { + ret = uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node, + devp); + debug("ret = %d\n", ret); + if (ret) + return ret; + } + + return 0; +} + +int mrccache_save(void) +{ + struct mrc_data_container *data; + struct fmap_entry entry; + struct udevice *sf; + int ret; + + if (!gd->arch.mrc_output_len) + return 0; + debug("Saving %d bytes of MRC output data to SPI flash\n", + gd->arch.mrc_output_len); + + ret = mrccache_get_region(&sf, &entry); + if (ret) + goto err_entry; + data = (struct mrc_data_container *)gd->arch.mrc_output; + ret = mrccache_update(sf, &entry, data); + if (!ret) + debug("Saved MRC data with checksum %04x\n", data->checksum); + +err_entry: + if (ret) + debug("%s: Failed: %d\n", __func__, ret); + return ret; +}
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
This adds mrccache_reserve(), mrccache_get_region() and mrccache_save() APIs to the mrccache codes. They are ported from the ivybridge implementation, but with some changes. For example, in the mrccache_reserve(), ivybridge version only reserves the pure MRC data, which causes additional malloc() when saving the cache as the save API needs some meta data. Now we change it to save the whole MRC date plus the meta data to elinimate the need for the malloc() later.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 51 +++++++++++++++++++++++ arch/x86/lib/mrccache.c | 89 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
This adds mrccache_reserve(), mrccache_get_region() and mrccache_save() APIs to the mrccache codes. They are ported from the ivybridge implementation, but with some changes. For example, in the mrccache_reserve(), ivybridge version only reserves the pure MRC data, which causes additional malloc() when saving the cache as the save API needs some meta data. Now we change it to save the whole MRC date plus the meta data to elinimate the need for the malloc() later.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/mrccache.h | 51 +++++++++++++++++++++++ arch/x86/lib/mrccache.c | 89 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Remove the call to custom mrc cache APIs, and use the ones provided in the mrccache lib.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/ivybridge/sdram.c | 112 ++--------------------------------------- 1 file changed, 4 insertions(+), 108 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c index 10fbe5f..20c2e68 100644 --- a/arch/x86/cpu/ivybridge/sdram.c +++ b/arch/x86/cpu/ivybridge/sdram.c @@ -89,42 +89,6 @@ void dram_init_banksize(void) } }
-static int get_mrc_entry(struct udevice **devp, struct fmap_entry *entry) -{ - const void *blob = gd->fdt_blob; - int node, spi_node, mrc_node; - int upto; - int ret; - - /* Find the flash chip within the SPI controller node */ - upto = 0; - spi_node = fdtdec_next_alias(blob, "spi", COMPAT_INTEL_ICH_SPI, &upto); - if (spi_node < 0) - return -ENOENT; - node = fdt_first_subnode(blob, spi_node); - if (node < 0) - return -ECHILD; - - /* Find the place where we put the MRC cache */ - mrc_node = fdt_subnode_offset(blob, node, "rw-mrc-cache"); - if (mrc_node < 0) - return -EPERM; - - if (fdtdec_read_fmap_entry(blob, mrc_node, "rm-mrc-cache", entry)) - return -EINVAL; - - if (devp) { - debug("getting sf\n"); - ret = uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node, - devp); - debug("ret = %d\n", ret); - if (ret) - return ret; - } - - return 0; -} - static int read_seed_from_cmos(struct pei_data *pei_data) { u16 c1, c2, checksum, seed_checksum; @@ -180,7 +144,7 @@ static int prepare_mrc_cache(struct pei_data *pei_data) ret = read_seed_from_cmos(pei_data); if (ret) return ret; - ret = get_mrc_entry(NULL, &entry); + ret = mrccache_get_region(NULL, &entry); if (ret) return ret; mrc_cache = mrccache_find_current(&entry); @@ -202,32 +166,6 @@ static int prepare_mrc_cache(struct pei_data *pei_data) return 0; }
-static int build_mrc_data(struct mrc_data_container **datap) -{ - struct mrc_data_container *data; - int orig_len; - int output_len; - - orig_len = gd->arch.mrc_output_len; - output_len = ALIGN(orig_len, 16); - data = malloc(output_len + sizeof(*data)); - if (!data) - return -ENOMEM; - data->signature = MRC_DATA_SIGNATURE; - data->data_size = output_len; - data->reserved = 0; - memcpy(data->data, gd->arch.mrc_output, orig_len); - - /* Zero the unused space in aligned buffer. */ - if (output_len > orig_len) - memset(data->data + orig_len, 0, output_len - orig_len); - - data->checksum = compute_ip_checksum(data->data, output_len); - *datap = data; - - return 0; -} - static int write_seeds_to_cmos(struct pei_data *pei_data) { u16 c1, c2, checksum; @@ -262,42 +200,12 @@ static int write_seeds_to_cmos(struct pei_data *pei_data) return 0; }
-static int sdram_save_mrc_data(void) -{ - struct mrc_data_container *data; - struct fmap_entry entry; - struct udevice *sf; - int ret; - - if (!gd->arch.mrc_output_len) - return 0; - debug("Saving %d bytes of MRC output data to SPI flash\n", - gd->arch.mrc_output_len); - - ret = get_mrc_entry(&sf, &entry); - if (ret) - goto err_entry; - ret = build_mrc_data(&data); - if (ret) - goto err_data; - ret = mrccache_update(sf, &entry, data); - if (!ret) - debug("Saved MRC data with checksum %04x\n", data->checksum); - - free(data); -err_data: -err_entry: - if (ret) - debug("%s: Failed: %d\n", __func__, ret); - return ret; -} - /* Use this hook to save our SDRAM parameters */ int misc_init_r(void) { int ret;
- ret = sdram_save_mrc_data(); + ret = mrccache_save(); if (ret) printf("Unable to save MRC data: %d\n", ret);
@@ -476,7 +384,7 @@ int sdram_initialise(struct pei_data *pei_data) if (pei_data->boot_mode != PEI_BOOT_RESUME) { /* * This will be copied to SDRAM in reserve_arch(), then written - * to SPI flash in sdram_save_mrc_data() + * to SPI flash in mrccache_save() */ gd->arch.mrc_output = (char *)pei_data->mrc_output; gd->arch.mrc_output_len = pei_data->mrc_output_len; @@ -490,19 +398,7 @@ int sdram_initialise(struct pei_data *pei_data)
int reserve_arch(void) { - u16 checksum; - - checksum = compute_ip_checksum(gd->arch.mrc_output, - gd->arch.mrc_output_len); - debug("Saving %d bytes for MRC output data, checksum %04x\n", - gd->arch.mrc_output_len, checksum); - gd->start_addr_sp -= gd->arch.mrc_output_len; - memcpy((void *)gd->start_addr_sp, gd->arch.mrc_output, - gd->arch.mrc_output_len); - gd->arch.mrc_output = (char *)gd->start_addr_sp; - gd->start_addr_sp &= ~0xf; - - return 0; + return mrccache_reserve(); }
static int copy_spd(struct pei_data *peid)
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Remove the call to custom mrc cache APIs, and use the ones provided in the mrccache lib.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 112 ++--------------------------------------- 1 file changed, 4 insertions(+), 108 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Remove the call to custom mrc cache APIs, and use the ones provided in the mrccache lib.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 112 ++--------------------------------------- 1 file changed, 4 insertions(+), 108 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size.
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/mrccache.h | 13 +++++++++---- arch/x86/lib/mrccache.c | 27 +++++++++++++++++---------- 3 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c index 20c2e68..9121426 100644 --- a/arch/x86/cpu/ivybridge/sdram.c +++ b/arch/x86/cpu/ivybridge/sdram.c @@ -138,7 +138,7 @@ static int read_seed_from_cmos(struct pei_data *pei_data) static int prepare_mrc_cache(struct pei_data *pei_data) { struct mrc_data_container *mrc_cache; - struct fmap_entry entry; + struct mrc_region entry; int ret;
ret = read_seed_from_cmos(pei_data); diff --git a/arch/x86/include/asm/mrccache.h b/arch/x86/include/asm/mrccache.h index bcf7117..e35b5ed 100644 --- a/arch/x86/include/asm/mrccache.h +++ b/arch/x86/include/asm/mrccache.h @@ -22,7 +22,12 @@ struct __packed mrc_data_container { u8 data[0]; /* Variable size, platform/run time dependent */ };
-struct fmap_entry; +struct mrc_region { + u32 base; + u32 offset; + u32 length; +}; + struct udevice;
/** @@ -34,7 +39,7 @@ struct udevice; * @entry: Position and size of MRC cache in SPI flash * @return pointer to latest record, or NULL if none */ -struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); +struct mrc_data_container *mrccache_find_current(struct mrc_region *entry);
/** * mrccache_update() - update the MRC cache with a new record @@ -48,7 +53,7 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry); * @return 0 if updated, -EEXIST if the record is the same as the latest * record, -EINVAL if the record is not valid, other error if SPI write failed */ -int mrccache_update(struct udevice *sf, struct fmap_entry *entry, +int mrccache_update(struct udevice *sf, struct mrc_region *entry, struct mrc_data_container *cur);
/** @@ -87,7 +92,7 @@ int mrccache_reserve(void); * tree, -EINVAL if MRC region properties format is incorrect, other error * if SPI flash probe failed. */ -int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry); +int mrccache_get_region(struct udevice **devp, struct mrc_region *entry);
/** * mrccache_save() - save MRC data to the SPI flash diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c index 0efae6d..53a1259 100644 --- a/arch/x86/lib/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -40,13 +40,13 @@ static int is_mrc_cache(struct mrc_data_container *cache) return cache && (cache->signature == MRC_DATA_SIGNATURE); }
-struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry) +struct mrc_data_container *mrccache_find_current(struct mrc_region *entry) { struct mrc_data_container *cache, *next; ulong base_addr, end_addr; uint id;
- base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset; + base_addr = entry->base + entry->offset; end_addr = base_addr + entry->length; cache = NULL;
@@ -85,12 +85,12 @@ struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry) * * @return next cache entry if found, NULL if we got to the end */ -static struct mrc_data_container *find_next_mrc_cache(struct fmap_entry *entry, +static struct mrc_data_container *find_next_mrc_cache(struct mrc_region *entry, struct mrc_data_container *cache) { ulong base_addr, end_addr;
- base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset; + base_addr = entry->base + entry->offset; end_addr = base_addr + entry->length;
cache = next_mrc_block(cache); @@ -106,7 +106,7 @@ static struct mrc_data_container *find_next_mrc_cache(struct fmap_entry *entry, return cache; }
-int mrccache_update(struct udevice *sf, struct fmap_entry *entry, +int mrccache_update(struct udevice *sf, struct mrc_region *entry, struct mrc_data_container *cur) { struct mrc_data_container *cache; @@ -118,7 +118,7 @@ int mrccache_update(struct udevice *sf, struct fmap_entry *entry, return -EINVAL;
/* Find the last used block */ - base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset; + base_addr = entry->base + entry->offset; debug("Updating MRC cache data\n"); cache = mrccache_find_current(entry); if (cache && (cache->data_size == cur->data_size) && @@ -189,10 +189,11 @@ int mrccache_reserve(void) return 0; }
-int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry) +int mrccache_get_region(struct udevice **devp, struct mrc_region *entry) { const void *blob = gd->fdt_blob; int node, mrc_node; + u32 reg[2]; int ret;
/* Find the flash chip within the SPI controller node */ @@ -200,13 +201,19 @@ int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry) if (node < 0) return -ENOENT;
+ if (fdtdec_get_int_array(blob, node, "memory-map", reg, 2)) + return -FDT_ERR_NOTFOUND; + entry->base = reg[0]; + /* Find the place where we put the MRC cache */ mrc_node = fdt_subnode_offset(blob, node, "rw-mrc-cache"); if (mrc_node < 0) return -EPERM;
- if (fdtdec_read_fmap_entry(blob, mrc_node, "rm-mrc-cache", entry)) - return -EINVAL; + if (fdtdec_get_int_array(blob, mrc_node, "reg", reg, 2)) + return -FDT_ERR_NOTFOUND; + entry->offset = reg[0]; + entry->length = reg[1];
if (devp) { ret = uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node, @@ -222,7 +229,7 @@ int mrccache_get_region(struct udevice **devp, struct fmap_entry *entry) int mrccache_save(void) { struct mrc_data_container *data; - struct fmap_entry entry; + struct mrc_region entry; struct udevice *sf; int ret;
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size.
I'm still not comfortable with CONFIG_ROM_SIZE not being the size of the SPI flash. It just seems wrong. Maybe we should have a u-boot.rom.min with a minimal images?
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/mrccache.h | 13 +++++++++---- arch/x86/lib/mrccache.c | 27 +++++++++++++++++---------- 3 files changed, 27 insertions(+), 15 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:26, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size.
I'm still not comfortable with CONFIG_ROM_SIZE not being the size of the SPI flash. It just seems wrong. Maybe we should have a u-boot.rom.min with a minimal images?
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/mrccache.h | 13 +++++++++---- arch/x86/lib/mrccache.c | 27 +++++++++++++++++---------- 3 files changed, 27 insertions(+), 15 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Hi Simon,
On Mon, Oct 19, 2015 at 4:26 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size.
I'm still not comfortable with CONFIG_ROM_SIZE not being the size of the SPI flash. It just seems wrong. Maybe we should have a u-boot.rom.min with a minimal images?
As we discussed before, we can just document this in README.x86?
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/mrccache.h | 13 +++++++++---- arch/x86/lib/mrccache.c | 27 +++++++++++++++++---------- 3 files changed, 27 insertions(+), 15 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Regards, Bin
Hi Bin,
On 18 October 2015 at 19:58, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 19, 2015 at 4:26 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size.
I'm still not comfortable with CONFIG_ROM_SIZE not being the size of the SPI flash. It just seems wrong. Maybe we should have a u-boot.rom.min with a minimal images?
As we discussed before, we can just document this in README.x86?
Yes although it irks me when I see a commit message suggesting that it is causing problems!
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/include/asm/mrccache.h | 13 +++++++++---- arch/x86/lib/mrccache.c | 27 +++++++++++++++++---------- 3 files changed, 27 insertions(+), 15 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Regards, Bin
Regards, Simon
fsp_init() call has a parameter nvs_buf which is used by FSP as the MRC cache but currently is blindly set to NULL. Retreive the MRC cache from SPI flash and pass it to fsp_init() call. After the call, save FSP produced MRC cache to SPI flash too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/lib/fsp/fsp_common.c | 30 +++++++++++++++++++++++++++++- arch/x86/lib/fsp/fsp_dram.c | 6 ++++++ 2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c index 658f32d..c78df94 100644 --- a/arch/x86/lib/fsp/fsp_common.c +++ b/arch/x86/lib/fsp/fsp_common.c @@ -7,6 +7,7 @@ #include <common.h> #include <errno.h> #include <asm/io.h> +#include <asm/mrccache.h> #include <asm/post.h> #include <asm/processor.h> #include <asm/fsp/fsp_support.h> @@ -54,15 +55,42 @@ void board_final_cleanup(void) return; }
+static __maybe_unused void *fsp_prepare_mrc_cache(void) +{ + struct mrc_data_container *cache; + struct mrc_region entry; + int ret; + + ret = mrccache_get_region(NULL, &entry); + if (ret) + return NULL; + + cache = mrccache_find_current(&entry); + if (!cache) + return NULL; + + debug("%s: mrc cache at %p, size %x checksum %04x\n", __func__, + cache->data, cache->data_size, cache->checksum); + + return cache->data; +} + int x86_fsp_init(void) { + void *nvs; + if (!gd->arch.hob_list) { +#ifdef CONFIG_ENABLE_MRC_CACHE + nvs = fsp_prepare_mrc_cache(); +#else + nvs = NULL; +#endif /* * The first time we enter here, call fsp_init(). * Note the execution does not return to this function, * instead it jumps to fsp_continue(). */ - fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, NULL); + fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, nvs); } else { /* * The second time we enter here, adjust the size of malloc() diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c index e51ca96..fcfe693 100644 --- a/arch/x86/lib/fsp/fsp_dram.c +++ b/arch/x86/lib/fsp/fsp_dram.c @@ -7,6 +7,7 @@ #include <common.h> #include <asm/fsp/fsp_support.h> #include <asm/e820.h> +#include <asm/mrccache.h> #include <asm/post.h>
DECLARE_GLOBAL_DATA_PTR; @@ -32,6 +33,11 @@ int dram_init(void) gd->ram_size = ram_size; post_code(POST_DRAM);
+#ifdef CONFIG_ENABLE_MRC_CACHE + gd->arch.mrc_output = fsp_get_nvs_data(gd->arch.hob_list, + &gd->arch.mrc_output_len); +#endif + return 0; }
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
fsp_init() call has a parameter nvs_buf which is used by FSP as the MRC cache but currently is blindly set to NULL. Retreive the MRC cache from SPI flash and pass it to fsp_init() call. After the call, save FSP produced MRC cache to SPI flash too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/lib/fsp/fsp_common.c | 30 +++++++++++++++++++++++++++++- arch/x86/lib/fsp/fsp_dram.c | 6 ++++++ 2 files changed, 35 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
fsp_init() call has a parameter nvs_buf which is used by FSP as the MRC cache but currently is blindly set to NULL. Retreive the MRC cache from SPI flash and pass it to fsp_init() call. After the call, save FSP produced MRC cache to SPI flash too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/lib/fsp/fsp_common.c | 30 +++++++++++++++++++++++++++++- arch/x86/lib/fsp/fsp_dram.c | 6 ++++++ 2 files changed, 35 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Save MRC cache to SPI flash in arch_misc_init().
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/baytrail/valleyview.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 4baaae6..215e0d0 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -8,6 +8,7 @@ #include <mmc.h> #include <pci_ids.h> #include <asm/irq.h> +#include <asm/mrccache.h> #include <asm/post.h>
static struct pci_device_id mmc_supported[] = { @@ -43,6 +44,24 @@ int arch_misc_init(void) if (!ll_boot_init()) return 0;
+#ifdef CONFIG_ENABLE_MRC_CACHE + /* + * We intend not to check any return value here, as even MRC cache + * is not saved successfully, it is not a severe error that will + * prevent system from continuing to boot. + */ + mrccache_save(); +#endif + return pirq_init(); } + +int reserve_arch(void) +{ +#ifdef CONFIG_ENABLE_MRC_CACHE + return mrccache_reserve(); +#else + return 0; +#endif +} #endif
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Save MRC cache to SPI flash in arch_misc_init().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Save MRC cache to SPI flash in arch_misc_init().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Now that we have added MRC cache for Intel FSP and BayTrail codes, enable it for all BayTrail boards (Bayley Bay and Minnow Max).
Note it turns out that FSP for Intel Atom E6xx does not produce the HOB for NV storage, so we don't have such functionality on Intel Crown Bay board.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/dts/bayleybay.dts | 6 ++++++ arch/x86/dts/minnowmax.dts | 6 ++++++ configs/bayleybay_defconfig | 1 + configs/minnowmax_defconfig | 1 + doc/README.x86 | 1 + 5 files changed, 15 insertions(+)
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts index d646987..52d0999 100644 --- a/arch/x86/dts/bayleybay.dts +++ b/arch/x86/dts/bayleybay.dts @@ -68,9 +68,15 @@ #size-cells = <0>; compatible = "intel,ich-spi"; spi-flash@0 { + #address-cells = <1>; + #size-cells = <1>; reg = <0>; compatible = "winbond,w25q64dw", "spi-flash"; memory-map = <0xff800000 0x00800000>; + rw-mrc-cache { + label = "rw-mrc-cache"; + reg = <0x006e0000 0x00010000>; + }; }; };
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts index e917f0f..b03f987 100644 --- a/arch/x86/dts/minnowmax.dts +++ b/arch/x86/dts/minnowmax.dts @@ -273,9 +273,15 @@ #size-cells = <0>; compatible = "intel,ich-spi"; spi-flash@0 { + #address-cells = <1>; + #size-cells = <1>; reg = <0>; compatible = "stmicro,n25q064a", "spi-flash"; memory-map = <0xff800000 0x00800000>; + rw-mrc-cache { + label = "rw-mrc-cache"; + reg = <0x006f0000 0x00010000>; + }; }; };
diff --git a/configs/bayleybay_defconfig b/configs/bayleybay_defconfig index 56316ee..fc40da8 100644 --- a/configs/bayleybay_defconfig +++ b/configs/bayleybay_defconfig @@ -3,6 +3,7 @@ CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE="bayleybay" CONFIG_TARGET_BAYLEYBAY=y CONFIG_HAVE_INTEL_ME=y +CONFIG_ENABLE_MRC_CACHE=y CONFIG_SMP=y CONFIG_HAVE_VGA_BIOS=y CONFIG_VGA_BIOS_ADDR=0xfffa0000 diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig index 0d5bd4e..8f99f0e 100644 --- a/configs/minnowmax_defconfig +++ b/configs/minnowmax_defconfig @@ -3,6 +3,7 @@ CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE="minnowmax" CONFIG_TARGET_MINNOWMAX=y CONFIG_HAVE_INTEL_ME=y +CONFIG_ENABLE_MRC_CACHE=y CONFIG_SMP=y CONFIG_HAVE_VGA_BIOS=y CONFIG_GENERATE_PIRQ_TABLE=y diff --git a/doc/README.x86 b/doc/README.x86 index a9d0e0f..1271e5e 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -190,6 +190,7 @@ Offset Description Controlling config 000000 descriptor.bin Hard-coded to 0 in ifdtool 001000 me.bin Set by the descriptor 500000 <spare> +6f0000 MRC cache CONFIG_ENABLE_MRC_CACHE 700000 u-boot-dtb.bin CONFIG_SYS_TEXT_BASE 790000 vga.bin CONFIG_VGA_BIOS_ADDR 7c0000 fsp.bin CONFIG_FSP_ADDR
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have added MRC cache for Intel FSP and BayTrail codes, enable it for all BayTrail boards (Bayley Bay and Minnow Max).
Note it turns out that FSP for Intel Atom E6xx does not produce the HOB for NV storage, so we don't have such functionality on Intel Crown Bay board.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/bayleybay.dts | 6 ++++++ arch/x86/dts/minnowmax.dts | 6 ++++++ configs/bayleybay_defconfig | 1 + configs/minnowmax_defconfig | 1 + doc/README.x86 | 1 + 5 files changed, 15 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have added MRC cache for Intel FSP and BayTrail codes, enable it for all BayTrail boards (Bayley Bay and Minnow Max).
Note it turns out that FSP for Intel Atom E6xx does not produce the HOB for NV storage, so we don't have such functionality on Intel Crown Bay board.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/bayleybay.dts | 6 ++++++ arch/x86/dts/minnowmax.dts | 6 ++++++ configs/bayleybay_defconfig | 1 + configs/minnowmax_defconfig | 1 + doc/README.x86 | 1 + 5 files changed, 15 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif + +void reset_cpu(ulong addr) +{ + /* cold reset */ + x86_full_reset(); +}
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif
+void reset_cpu(ulong addr) +{
/* cold reset */x86_full_reset();+}
1.8.2.1
Actually on Minnowmax this doesn't fix the hang.
Also I don't see any speed-up from using the cache on Minnowmax.
Regards, Simon
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif
+void reset_cpu(ulong addr) +{
/* cold reset */x86_full_reset();+}
1.8.2.1
Actually on Minnowmax this doesn't fix the hang.
That's strange. As full reset indicates a complete power cycle. Does MinnowMax boot with MRC cache enabled?
Also I don't see any speed-up from using the cache on Minnowmax.
On Galileo, I did not see any speed-up either. I think it is because on MinnowMax and Galileo they both uses memory-down configuration. The speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
Regards, Simon
Regards, Bin
Hi Bin,
On 18 October 2015 at 20:01, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif
+void reset_cpu(ulong addr) +{
/* cold reset */x86_full_reset();+}
1.8.2.1
Actually on Minnowmax this doesn't fix the hang.
That's strange. As full reset indicates a complete power cycle. Does MinnowMax boot with MRC cache enabled?
It's hard to tell because the UART does not work that early. I wish we could fix that. I thought I did have it running at one point, but I may have imagined it.
Re the hang, I'm not sure - it seems to have stopped happening, so let's not worry about it for now.
Also I don't see any speed-up from using the cache on Minnowmax.
On Galileo, I did not see any speed-up either. I think it is because on MinnowMax and Galileo they both uses memory-down configuration. The speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
So what is the point of enabling the MRC cache?
Regards, Simon
Hi Simon,
On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 18 October 2015 at 20:01, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif
+void reset_cpu(ulong addr) +{
/* cold reset */x86_full_reset();+}
1.8.2.1
Actually on Minnowmax this doesn't fix the hang.
That's strange. As full reset indicates a complete power cycle. Does MinnowMax boot with MRC cache enabled?
It's hard to tell because the UART does not work that early. I wish we could fix that. I thought I did have it running at one point, but I may have imagined it.
We need figure out where the hang happens. Is it in FSP, or in U-Boot? You can use a debug version of FSP (the gold4 release includes a debug version FSP) to see where the FSP hangs if it is the FSP hang case.
Re the hang, I'm not sure - it seems to have stopped happening, so let's not worry about it for now.
Also I don't see any speed-up from using the cache on Minnowmax.
On Galileo, I did not see any speed-up either. I think it is because on MinnowMax and Galileo they both uses memory-down configuration. The speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
So what is the point of enabling the MRC cache?
On Bayley Bay it indeed improves the boot time. So, maybe we can just leave this option unselected by the defconfig files for Chromebook and Galileo?
One thing I noticed that on Chromebook the memory SPD is passed by device tree. Is there any DIMM on the Chromebook and the SPD in device tree is just a short-cut for the MRC? If we let MRC reads the SPD, does MRC cache help?
Regards, Bin
Hi Bin,
On 18 October 2015 at 20:31, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 18 October 2015 at 20:01, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 215e0d0..a009c14 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -65,3 +65,9 @@ int reserve_arch(void) #endif } #endif
+void reset_cpu(ulong addr) +{
/* cold reset */x86_full_reset();+}
1.8.2.1
Actually on Minnowmax this doesn't fix the hang.
That's strange. As full reset indicates a complete power cycle. Does MinnowMax boot with MRC cache enabled?
It's hard to tell because the UART does not work that early. I wish we could fix that. I thought I did have it running at one point, but I may have imagined it.
We need figure out where the hang happens. Is it in FSP, or in U-Boot? You can use a debug version of FSP (the gold4 release includes a debug version FSP) to see where the FSP hangs if it is the FSP hang case.
Ah yes, that's a good idea.
Re the hang, I'm not sure - it seems to have stopped happening, so let's not worry about it for now.
Also I don't see any speed-up from using the cache on Minnowmax.
On Galileo, I did not see any speed-up either. I think it is because on MinnowMax and Galileo they both uses memory-down configuration. The speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
So what is the point of enabling the MRC cache?
On Bayley Bay it indeed improves the boot time. So, maybe we can just leave this option unselected by the defconfig files for Chromebook and Galileo?
OK. It does speed up link.
One thing I noticed that on Chromebook the memory SPD is passed by device tree. Is there any DIMM on the Chromebook and the SPD in device tree is just a short-cut for the MRC? If we let MRC reads the SPD, does MRC cache help?
Yes there are DIMMs but we know exactly what they are. The MRC cache does seem to help on this platform.
Regards, Simon
"type" and "wipe-value" are never used by the mrccache codes. Remove them to avoid confusion. This also removes the alignment comment in the panther dts file.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/dts/chromebook_link.dts | 2 -- arch/x86/dts/chromebox_panther.dts | 3 --- 2 files changed, 5 deletions(-)
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts index 4291141..f27263a 100644 --- a/arch/x86/dts/chromebook_link.dts +++ b/arch/x86/dts/chromebook_link.dts @@ -208,8 +208,6 @@ rw-mrc-cache { label = "rw-mrc-cache"; reg = <0x003e0000 0x00010000>; - type = "wiped"; - wipe-value = [ff]; }; }; }; diff --git a/arch/x86/dts/chromebox_panther.dts b/arch/x86/dts/chromebox_panther.dts index c60ab71..61e8f2f 100644 --- a/arch/x86/dts/chromebox_panther.dts +++ b/arch/x86/dts/chromebox_panther.dts @@ -64,10 +64,7 @@ memory-map = <0xff800000 0x00800000>; rw-mrc-cache { label = "rw-mrc-cache"; - /* Alignment: 4k (for updating) */ reg = <0x003e0000 0x00010000>; - type = "wiped"; - wipe-value = [ff]; }; }; };
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
"type" and "wipe-value" are never used by the mrccache codes. Remove them to avoid confusion. This also removes the alignment comment in the panther dts file.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/chromebook_link.dts | 2 -- arch/x86/dts/chromebox_panther.dts | 3 --- 2 files changed, 5 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
These are used by the cros_bundle_firmware tool in Chrome OS, which builds the image. But it does not matter for upstream.
Regards, Simon
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
"type" and "wipe-value" are never used by the mrccache codes. Remove them to avoid confusion. This also removes the alignment comment in the panther dts file.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/chromebook_link.dts | 2 -- arch/x86/dts/chromebox_panther.dts | 3 --- 2 files changed, 5 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
These are used by the cros_bundle_firmware tool in Chrome OS, which builds the image. But it does not matter for upstream.
Regards, Simon
Applied to u-boot-x86, thanks!
It should be MRC, not MCR.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
arch/x86/cpu/ivybridge/sdram.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c index 9121426..fc66a3c 100644 --- a/arch/x86/cpu/ivybridge/sdram.c +++ b/arch/x86/cpu/ivybridge/sdram.c @@ -363,7 +363,7 @@ int sdram_initialise(struct pei_data *pei_data) debug("System Agent Version %d.%d.%d Build %d\n", version >> 24 , (version >> 16) & 0xff, (version >> 8) & 0xff, version & 0xff); - debug("MCR output data length %#x at %p\n", pei_data->mrc_output_len, + debug("MRC output data length %#x at %p\n", pei_data->mrc_output_len, pei_data->mrc_output);
/* @@ -723,7 +723,7 @@ int dram_init(void) int ret;
debug("Boot mode %d\n", gd->arch.pei_boot_mode); - debug("mcr_input %p\n", pei_data.mrc_input); + debug("mrc_input %p\n", pei_data.mrc_input); pei_data.boot_mode = gd->arch.pei_boot_mode; ret = copy_spd(&pei_data); if (!ret)
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
It should be MRC, not MCR.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
On 18 October 2015 at 14:27, Simon Glass sjg@chromium.org wrote:
On 11 October 2015 at 22:37, Bin Meng bmeng.cn@gmail.com wrote:
It should be MRC, not MCR.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/ivybridge/sdram.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!
Hi Simon,
On Mon, Oct 12, 2015 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
This series moves existing MRC cache codes in the ivybridge cpu diretory to a common place and makes some changes so that every x86 board benefits from it. It also updates FSP support codes to pass MRC cache data to fsp_init() to speed up boot time.
Currently tested on Intel Bayley Bay board. Minnow Max board should work as it uses the same FSP that Bayley Bay uses. For Chromebook I cannot test that, but I see Simon added a TODO in the codes below:
/* * TODO(sjg@chromium.org): Skip this for now as it causes boot * problems */ if (0) { pei_data->mrc_input = mrc_cache->data; pei_data->mrc_input_len = mrc_cache->data_size; }I have no idea what breaks the MRC cache on the Chromebook board. Simon, you may retest this on top of this series to see if things go better.
Can you please try this patch on Chromebook? http://patchwork.ozlabs.org/patch/528970/
I suspect this patch fixes the boot failures you saw before.
[snip]
Regards, Bin
Hi Bin,
On 12 October 2015 at 02:30, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 12, 2015 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
This series moves existing MRC cache codes in the ivybridge cpu diretory to a common place and makes some changes so that every x86 board benefits from it. It also updates FSP support codes to pass MRC cache data to fsp_init() to speed up boot time.
Currently tested on Intel Bayley Bay board. Minnow Max board should work as it uses the same FSP that Bayley Bay uses. For Chromebook I cannot test that, but I see Simon added a TODO in the codes below:
/* * TODO(sjg@chromium.org): Skip this for now as it causes boot * problems */ if (0) { pei_data->mrc_input = mrc_cache->data; pei_data->mrc_input_len = mrc_cache->data_size; }I have no idea what breaks the MRC cache on the Chromebook board. Simon, you may retest this on top of this series to see if things go better.
Can you please try this patch on Chromebook? http://patchwork.ozlabs.org/patch/528970/
I suspect this patch fixes the boot failures you saw before.
[snip]
Thanks for the prod - actually the problem turns out to be in car_uninit() so I will send a series to fix that, and some RTC problems.
Regards, Simon
participants (2)
-
Bin Meng -
Simon Glass