leandrof/u-boot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
37a508f8b7
u-boot/arch/x86/lib/mrccache.c

302 lines
7.3 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
/*
x86: Add various minor tidy-ups in mrccache codes Fix some nits, improve some comments and reorder some codes a little bit. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:38 +00:00
* From coreboot src/southbridge/intel/bd82x6x/mrccache.c
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
*
* Copyright (C) 2014 Google Inc.
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
* Copyright (C) 2015 Bin Meng <bmeng.cn@gmail.com>
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
*/
#include <common.h>
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
#include <dm.h>
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
#include <errno.h>
#include <fdtdec.h>
#include <net.h>
#include <spi.h>
#include <spi_flash.h>
x86: Move mrccache.[c|h] to a common place 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:36 +00:00
#include <asm/mrccache.h>
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
#include <dm/device-internal.h>
#include <dm/uclass-internal.h>
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
DECLARE_GLOBAL_DATA_PTR;
x86: Add a function to find the size of an mrccache record Move the code to determine the size of a cache record into a function so we can use it elsewhere in this file. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:04 +00:00
static uint mrc_block_size(uint data_size)
{
uint mrc_size = sizeof(struct mrc_data_container) + data_size;
return ALIGN(mrc_size, MRC_DATA_ALIGN);
}
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
static struct mrc_data_container *next_mrc_block(
x86: Add various minor tidy-ups in mrccache codes Fix some nits, improve some comments and reorder some codes a little bit. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:38 +00:00
struct mrc_data_container *cache)
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
{
/* MRC data blocks are aligned within the region */
x86: Add various minor tidy-ups in mrccache codes Fix some nits, improve some comments and reorder some codes a little bit. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:38 +00:00
u8 *region_ptr = (u8 *)cache;
x86: Add a function to find the size of an mrccache record Move the code to determine the size of a cache record into a function so we can use it elsewhere in this file. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:04 +00:00
region_ptr += mrc_block_size(cache->data_size);
x86: Add various minor tidy-ups in mrccache codes Fix some nits, improve some comments and reorder some codes a little bit. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:38 +00:00
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
return (struct mrc_data_container *)region_ptr;
}
static int is_mrc_cache(struct mrc_data_container *cache)
{
return cache && (cache->signature == MRC_DATA_SIGNATURE);
}
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
struct mrc_data_container *mrccache_find_current(struct mrc_region *entry)
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
{
struct mrc_data_container *cache, *next;
ulong base_addr, end_addr;
uint id;
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
base_addr = entry->base + entry->offset;
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
end_addr = base_addr + entry->length;
cache = NULL;
/* Search for the last filled entry in the region */
for (id = 0, next = (struct mrc_data_container *)base_addr;
is_mrc_cache(next);
id++) {
cache = next;
next = next_mrc_block(next);
if ((ulong)next >= end_addr)
break;
}
if (id-- == 0) {
debug("%s: No valid MRC cache found.\n", __func__);
return NULL;
}
/* Verify checksum */
if (cache->checksum != compute_ip_checksum(cache->data,
cache->data_size)) {
printf("%s: MRC cache checksum mismatch\n", __func__);
return NULL;
}
debug("%s: picked entry %u from cache block\n", __func__, id);
return cache;
}
/**
* find_next_mrc_cache() - get next cache entry
*
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
* This moves to the next cache entry in the region, making sure it has enough
* space to hold data of size @data_size.
*
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
* @entry: MRC cache flash area
* @cache: Entry to start from
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
* @data_size: Required data size of the new entry. Note that we assume that
* all cache entries are the same size
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
*
* @return next cache entry if found, NULL if we got to the end
*/
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
static struct mrc_data_container *find_next_mrc_cache(struct mrc_region *entry,
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
struct mrc_data_container *prev, int data_size)
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
{
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
struct mrc_data_container *cache;
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
ulong base_addr, end_addr;
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
base_addr = entry->base + entry->offset;
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
end_addr = base_addr + entry->length;
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
/*
* We assume that all cache entries are the same size, but let's use
* data_size here for clarity.
*/
cache = next_mrc_block(prev);
if ((ulong)cache + mrc_block_size(data_size) > end_addr) {
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
/* Crossed the boundary */
cache = NULL;
debug("%s: no available entries found\n", __func__);
} else {
debug("%s: picked next entry from cache block at %p\n",
__func__, cache);
}
return cache;
}
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
int mrccache_update(struct udevice *sf, struct mrc_region *entry,
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
struct mrc_data_container *cur)
{
struct mrc_data_container *cache;
ulong offset;
ulong base_addr;
int ret;
x86: mrccache: Add more debugging When the MRC cache fails to save it is useful to have some debugging info to indicate what when wrong. Add some more debug() calls. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:59 +00:00
if (!is_mrc_cache(cur)) {
debug("%s: Cache data not valid\n", __func__);
x86: Do sanity test on the cache record in mrccache_update() 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:37 +00:00
return -EINVAL;
x86: mrccache: Add more debugging When the MRC cache fails to save it is useful to have some debugging info to indicate what when wrong. Add some more debug() calls. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:59 +00:00
}
x86: Do sanity test on the cache record in mrccache_update() 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:37 +00:00
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
/* Find the last used block */
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
base_addr = entry->base + entry->offset;
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
debug("Updating MRC cache data\n");
cache = mrccache_find_current(entry);
if (cache && (cache->data_size == cur->data_size) &&
(!memcmp(cache, cur, cache->data_size + sizeof(*cur)))) {
debug("MRC data in flash is up to date. No update\n");
return -EEXIST;
}
/* Move to the next block, which will be the first unused block */
if (cache)
x86: Correct mrccache find_next_mrc_cache() calculation This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:02 +00:00
cache = find_next_mrc_cache(entry, cache, cur->data_size);
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
/*
* If we have got to the end, erase the entire mrc-cache area and start
* again at block 0.
*/
if (!cache) {
debug("Erasing the MRC cache region of %x bytes at %x\n",
entry->length, entry->offset);
dm: x86: spi: Convert ICH SPI driver to driver model Convert this driver over to use driver model. Since all x86 platforms use it, move x86 to use driver model for SPI and SPI flash. Adjust all dependent code and remove the old x86 spi_init() function. Note that this does not make full use of the new PCI uclass as yet. We still scan the bus looking for the device. It should move to finding its details in the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-26 15:29:26 +00:00
ret = spi_flash_erase_dm(sf, entry->offset, entry->length);
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
if (ret) {
debug("Failed to erase flash region\n");
return ret;
}
cache = (struct mrc_data_container *)base_addr;
}
/* Write the data out */
offset = (ulong)cache - base_addr + entry->offset;
debug("Write MRC cache update to flash at %lx\n", offset);
dm: x86: spi: Convert ICH SPI driver to driver model Convert this driver over to use driver model. Since all x86 platforms use it, move x86 to use driver model for SPI and SPI flash. Adjust all dependent code and remove the old x86 spi_init() function. Note that this does not make full use of the new PCI uclass as yet. We still scan the bus looking for the device. It should move to finding its details in the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-26 15:29:26 +00:00
ret = spi_flash_write_dm(sf, offset, cur->data_size + sizeof(*cur),
cur);
x86: Implement a cache for Memory Reference Code parameters The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-20 05:16:14 +00:00
if (ret) {
debug("Failed to write to SPI flash\n");
return ret;
}
return 0;
}
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
x86: Support saving MRC data from SPL When SPL is used to set up the memory controller we want to save the MRC data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a function to handle that. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:57 +00:00
static void mrccache_setup(void *data)
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
{
x86: Support saving MRC data from SPL When SPL is used to set up the memory controller we want to save the MRC data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a function to handle that. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:57 +00:00
struct mrc_data_container *cache = data;
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
u16 checksum;
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);
x86: Add a new global_data member for the cache record At present we reuse the mrc_output char * to also point to the cache record after it has been set up. This is confusing and doesn't save much data space. Add a new mrc_cache member instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:05 +00:00
gd->arch.mrc_cache = cache;
x86: Support saving MRC data from SPL When SPL is used to set up the memory controller we want to save the MRC data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a function to handle that. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:57 +00:00
}
int mrccache_reserve(void)
{
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);
mrccache_setup((void *)gd->start_addr_sp);
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
gd->start_addr_sp &= ~0xf;
return 0;
}
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
int mrccache_get_region(struct udevice **devp, struct mrc_region *entry)
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
{
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
struct udevice *dev;
ofnode mrc_node;
x86: Adjust mrccache_get_region() to support get_mmap() It is now possible to obtain the memory map for a SPI controllers instead of having it hard-coded in the device tree. Update the code to support this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:04 +00:00
ulong map_base;
uint map_size;
uint offset;
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
u32 reg[2];
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
int ret;
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
/*
* Find the flash chip within the SPI controller node. Avoid probing
* the device here since it may put it into a strange state where the
* memory map cannot be read.
*/
ret = uclass_find_first_device(UCLASS_SPI_FLASH, &dev);
if (ret)
return log_msg_ret("Cannot find SPI flash\n", ret);
x86: Adjust mrccache_get_region() to support get_mmap() It is now possible to obtain the memory map for a SPI controllers instead of having it hard-coded in the device tree. Update the code to support this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:04 +00:00
ret = dm_spi_get_mmap(dev, &map_base, &map_size, &offset);
if (!ret) {
entry->base = map_base;
} else {
ret = dev_read_u32_array(dev, "memory-map", reg, 2);
if (ret)
return log_msg_ret("Cannot find memory map\n", ret);
entry->base = reg[0];
}
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
/* Find the place where we put the MRC cache */
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
mrc_node = dev_read_subnode(dev, "rw-mrc-cache");
if (!ofnode_valid(mrc_node))
return log_msg_ret("Cannot find node", -EPERM);
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
ret = ofnode_read_u32_array(mrc_node, "reg", reg, 2);
if (ret)
return log_msg_ret("Cannot find address", ret);
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
entry->offset = reg[0];
entry->length = reg[1];
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
if (devp)
*devp = dev;
x86: Adjust mrccache_get_region() to support get_mmap() It is now possible to obtain the memory map for a SPI controllers instead of having it hard-coded in the device tree. Update the code to support this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:04 +00:00
debug("MRC cache in '%s', offset %x, len %x, base %x\n",
dev->name, entry->offset, entry->length, entry->base);
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
return 0;
}
int mrccache_save(void)
{
x86: Add a new global_data member for the cache record At present we reuse the mrc_output char * to also point to the cache record after it has been set up. This is confusing and doesn't save much data space. Add a new mrc_cache member instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:05 +00:00
struct mrc_data_container *cache;
x86: Use struct mrc_region to describe a mrc region 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:41 +00:00
struct mrc_region entry;
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
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);
x86: Adjust mrccache_get_region() to use livetree Change the algorithm to first find the flash device then read the properties using the livetree API. With this change the device is not probed so this needs to be done in mrccache_save(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:03 +00:00
if (ret)
goto err_entry;
ret = device_probe(sf);
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
if (ret)
goto err_entry;
x86: Add a new global_data member for the cache record At present we reuse the mrc_output char * to also point to the cache record after it has been set up. This is confusing and doesn't save much data space. Add a new mrc_cache member instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:05 +00:00
cache = gd->arch.mrc_cache;
ret = mrccache_update(sf, &entry, cache);
x86: Don't show an error when the MRC cache is up to date When the final MRC cache record is the same as the one we want to write, we skip writing since there is no point. This is normal behaviour. Avoiding printing an error when this happens. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:29 +00:00
if (!ret) {
x86: Add a new global_data member for the cache record At present we reuse the mrc_output char * to also point to the cache record after it has been set up. This is confusing and doesn't save much data space. Add a new mrc_cache member instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:05 +00:00
debug("Saved MRC data with checksum %04x\n", cache->checksum);
x86: Don't show an error when the MRC cache is up to date When the final MRC cache record is the same as the one we want to write, we skip writing since there is no point. This is normal behaviour. Avoiding printing an error when this happens. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:29 +00:00
} else if (ret == -EEXIST) {
debug("MRC data is the same as last time, skipping save\n");
ret = 0;
}
x86: Add more common routines to manipulate mrc cache 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:39 +00:00
err_entry:
if (ret)
debug("%s: Failed: %d\n", __func__, ret);
return ret;
}
x86: Support saving MRC data from SPL When SPL is used to set up the memory controller we want to save the MRC data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a function to handle that. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:57 +00:00
int mrccache_spl_save(void)
{
void *data;
int size;
size = gd->arch.mrc_output_len + MRC_DATA_HEADER_SIZE;
data = malloc(size);
if (!data)
return log_msg_ret("Allocate MRC cache block", -ENOMEM);
mrccache_setup(data);
gd->arch.mrc_output = data;
return mrccache_save();
}
Reference in New Issue Copy Permalink