Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 02:38:56 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/x86/cpu/ivybridge/sdram.c

756 lines
20 KiB
C
Raw Normal View History

x86: Add chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
/*
* Copyright (c) 2011 The Chromium OS Authors.
* (C) Copyright 2010,2011
* Graeme Russ, <graeme.russ@gmail.com>
*
* Portions from Coreboot mainboard/google/link/romstage.c
* Copyright (C) 2007-2010 coresystems GmbH
* Copyright (C) 2011 Google Inc.
*
* SPDX-License-Identifier: GPL-2.0
*/
#include <common.h>
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
#include <errno.h>
#include <fdtdec.h>
#include <malloc.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 <net.h>
#include <rtc.h>
#include <spi.h>
#include <spi_flash.h>
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
#include <asm/processor.h>
#include <asm/gpio.h>
#include <asm/global_data.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: ivybridge: Request MTRRs for DRAM regions We should use MTRRs to speed up execution. Add a list of MTRR requests which will dealt with when we relocate and run from RAM. We set RAM as cacheable (with write-back) and registers as non-cacheable. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-01 23:18:10 +00:00
#include <asm/mtrr.h>
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
#include <asm/pci.h>
#include <asm/arch/me.h>
#include <asm/arch/pei_data.h>
#include <asm/arch/pch.h>
#include <asm/post.h>
#include <asm/arch/sandybridge.h>
DECLARE_GLOBAL_DATA_PTR;
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
#define CMOS_OFFSET_MRC_SEED 152
#define CMOS_OFFSET_MRC_SEED_S3 156
#define CMOS_OFFSET_MRC_SEED_CHK 160
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/*
* This function looks for the highest region of memory lower than 4GB which
* has enough space for U-Boot where U-Boot is aligned on a page boundary.
* It overrides the default implementation found elsewhere which simply
* picks the end of ram, wherever that may be. The location of the stack,
* the relocation address, and how far U-Boot is moved by relocation are
* set in the global data structure.
*/
ulong board_get_usable_ram_top(ulong total_size)
{
struct memory_info *info = &gd->arch.meminfo;
uintptr_t dest_addr = 0;
struct memory_area *largest = NULL;
int i;
/* Find largest area of memory below 4GB */
for (i = 0; i < info->num_areas; i++) {
struct memory_area *area = &info->area[i];
if (area->start >= 1ULL << 32)
continue;
if (!largest || area->size > largest->size)
largest = area;
}
/* If no suitable area was found, return an error. */
assert(largest);
if (!largest || largest->size < (2 << 20))
panic("No available memory found for relocation");
dest_addr = largest->start + largest->size;
return (ulong)dest_addr;
}
void dram_init_banksize(void)
{
struct memory_info *info = &gd->arch.meminfo;
int num_banks;
int i;
for (i = 0, num_banks = 0; i < info->num_areas; i++) {
struct memory_area *area = &info->area[i];
if (area->start >= 1ULL << 32)
continue;
gd->bd->bi_dram[num_banks].start = area->start;
gd->bd->bi_dram[num_banks].size = area->size;
num_banks++;
}
}
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 int read_seed_from_cmos(struct pei_data *pei_data)
{
u16 c1, c2, checksum, seed_checksum;
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
struct udevice *dev;
x86: ivybridge: Use 'ret' instead of 'rcode' For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-18 21:55:32 +00:00
int ret = 0;
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
x86: ivybridge: Use 'ret' instead of 'rcode' For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-18 21:55:32 +00:00
ret = uclass_get_device(UCLASS_RTC, 0, &dev);
if (ret) {
debug("Cannot find RTC: err=%d\n", ret);
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
return -ENODEV;
}
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
/*
* Read scrambler seeds from CMOS RAM. We don't want to store them in
* SPI flash since they change on every boot and that would wear down
* the flash too much. So we store these in CMOS and the large MRC
* data in SPI flash.
*/
x86: ivybridge: Check the RTC return value The RTC can fail, so check the return value for reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-18 21:55:33 +00:00
ret = rtc_read32(dev, CMOS_OFFSET_MRC_SEED, &pei_data->scrambler_seed);
if (!ret) {
ret = rtc_read32(dev, CMOS_OFFSET_MRC_SEED_S3,
&pei_data->scrambler_seed_s3);
}
if (ret) {
debug("Failed to read from RTC %s\n", dev->name);
return ret;
}
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("Read scrambler seed 0x%08x from CMOS 0x%02x\n",
pei_data->scrambler_seed, CMOS_OFFSET_MRC_SEED);
debug("Read S3 scrambler seed 0x%08x from CMOS 0x%02x\n",
pei_data->scrambler_seed_s3, CMOS_OFFSET_MRC_SEED_S3);
/* Compute seed checksum and compare */
c1 = compute_ip_checksum((u8 *)&pei_data->scrambler_seed,
sizeof(u32));
c2 = compute_ip_checksum((u8 *)&pei_data->scrambler_seed_s3,
sizeof(u32));
checksum = add_ip_checksums(sizeof(u32), c1, c2);
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
seed_checksum = rtc_read8(dev, CMOS_OFFSET_MRC_SEED_CHK);
seed_checksum |= rtc_read8(dev, CMOS_OFFSET_MRC_SEED_CHK + 1) << 8;
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 (checksum != seed_checksum) {
debug("%s: invalid seed checksum\n", __func__);
pei_data->scrambler_seed = 0;
pei_data->scrambler_seed_s3 = 0;
return -EINVAL;
}
return 0;
}
static int prepare_mrc_cache(struct pei_data *pei_data)
{
struct mrc_data_container *mrc_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: 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
int ret;
ret = read_seed_from_cmos(pei_data);
if (ret)
return ret;
x86: ivybridge: Use APIs provided in the mrccache lib 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:40 +00:00
ret = mrccache_get_region(NULL, &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
if (ret)
return ret;
mrc_cache = mrccache_find_current(&entry);
if (!mrc_cache)
return -ENOENT;
/*
* 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;
}
debug("%s: at %p, size %x checksum %04x\n", __func__,
pei_data->mrc_input, pei_data->mrc_input_len,
mrc_cache->checksum);
return 0;
}
static int write_seeds_to_cmos(struct pei_data *pei_data)
{
u16 c1, c2, checksum;
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
struct udevice *dev;
x86: ivybridge: Use 'ret' instead of 'rcode' For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-18 21:55:32 +00:00
int ret = 0;
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
x86: ivybridge: Use 'ret' instead of 'rcode' For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-18 21:55:32 +00:00
ret = uclass_get_device(UCLASS_RTC, 0, &dev);
if (ret) {
debug("Cannot find RTC: err=%d\n", ret);
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
return -ENODEV;
}
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
/* Save the MRC seed values to CMOS */
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
rtc_write32(dev, CMOS_OFFSET_MRC_SEED, pei_data->scrambler_seed);
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("Save scrambler seed 0x%08x to CMOS 0x%02x\n",
pei_data->scrambler_seed, CMOS_OFFSET_MRC_SEED);
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
rtc_write32(dev, CMOS_OFFSET_MRC_SEED_S3, pei_data->scrambler_seed_s3);
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("Save s3 scrambler seed 0x%08x to CMOS 0x%02x\n",
pei_data->scrambler_seed_s3, CMOS_OFFSET_MRC_SEED_S3);
/* Save a simple checksum of the seed values */
c1 = compute_ip_checksum((u8 *)&pei_data->scrambler_seed,
sizeof(u32));
c2 = compute_ip_checksum((u8 *)&pei_data->scrambler_seed_s3,
sizeof(u32));
checksum = add_ip_checksums(sizeof(u32), c1, c2);
x86: Enable DM RTC support for all x86 boards Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
2015-07-15 08:23:39 +00:00
rtc_write8(dev, CMOS_OFFSET_MRC_SEED_CHK, checksum & 0xff);
rtc_write8(dev, CMOS_OFFSET_MRC_SEED_CHK + 1, (checksum >> 8) & 0xff);
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 0;
}
/* Use this hook to save our SDRAM parameters */
int misc_init_r(void)
{
int ret;
x86: ivybridge: Use APIs provided in the mrccache lib 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:40 +00:00
ret = mrccache_save();
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)
printf("Unable to save MRC data: %d\n", ret);
return 0;
}
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
static const char *const ecc_decoder[] = {
"inactive",
"active on IO",
"disabled on IO",
"active"
};
/*
* Dump in the log memory controller configuration as read from the memory
* controller registers.
*/
static void report_memory_config(void)
{
u32 addr_decoder_common, addr_decode_ch[2];
int i;
addr_decoder_common = readl(MCHBAR_REG(0x5000));
addr_decode_ch[0] = readl(MCHBAR_REG(0x5004));
addr_decode_ch[1] = readl(MCHBAR_REG(0x5008));
debug("memcfg DDR3 clock %d MHz\n",
(readl(MCHBAR_REG(0x5e04)) * 13333 * 2 + 50) / 100);
debug("memcfg channel assignment: A: %d, B % d, C % d\n",
addr_decoder_common & 3,
(addr_decoder_common >> 2) & 3,
(addr_decoder_common >> 4) & 3);
for (i = 0; i < ARRAY_SIZE(addr_decode_ch); i++) {
u32 ch_conf = addr_decode_ch[i];
debug("memcfg channel[%d] config (%8.8x):\n", i, ch_conf);
debug(" ECC %s\n", ecc_decoder[(ch_conf >> 24) & 3]);
debug(" enhanced interleave mode %s\n",
((ch_conf >> 22) & 1) ? "on" : "off");
debug(" rank interleave %s\n",
((ch_conf >> 21) & 1) ? "on" : "off");
debug(" DIMMA %d MB width x%d %s rank%s\n",
((ch_conf >> 0) & 0xff) * 256,
((ch_conf >> 19) & 1) ? 16 : 8,
((ch_conf >> 17) & 1) ? "dual" : "single",
((ch_conf >> 16) & 1) ? "" : ", selected");
debug(" DIMMB %d MB width x%d %s rank%s\n",
((ch_conf >> 8) & 0xff) * 256,
((ch_conf >> 20) & 1) ? 16 : 8,
((ch_conf >> 18) & 1) ? "dual" : "single",
((ch_conf >> 16) & 1) ? ", selected" : "");
}
}
static void post_system_agent_init(struct pei_data *pei_data)
{
/* If PCIe init is skipped, set the PEG clock gating */
if (!pei_data->pcie_init)
setbits_le32(MCHBAR_REG(0x7010), 1);
}
static asmlinkage void console_tx_byte(unsigned char byte)
{
#ifdef DEBUG
putc(byte);
#endif
}
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 int recovery_mode_enabled(void)
{
return false;
}
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/**
* Find the PEI executable in the ROM and execute it.
*
* @param pei_data: configuration data for UEFI PEI reference code
*/
int sdram_initialise(struct pei_data *pei_data)
{
unsigned version;
const char *data;
uint16_t done;
int ret;
report_platform_info();
/* Wait for ME to be ready */
ret = intel_early_me_init();
if (ret)
return ret;
ret = intel_early_me_uma_size();
if (ret < 0)
return ret;
debug("Starting UEFI PEI System Agent\n");
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
/*
* Do not pass MRC data in for recovery mode boot,
* Always pass it in for S3 resume.
*/
if (!recovery_mode_enabled() ||
pei_data->boot_mode == PEI_BOOT_RESUME) {
ret = prepare_mrc_cache(pei_data);
if (ret)
debug("prepare_mrc_cache failed: %d\n", ret);
}
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/* If MRC data is not found we cannot continue S3 resume. */
if (pei_data->boot_mode == PEI_BOOT_RESUME && !pei_data->mrc_input) {
debug("Giving up in sdram_initialize: No MRC data\n");
x86: ivybridge: Use reset_cpu() Now that reset_cpu() functions correctly, use it instead of directly accessing the port. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-04-29 02:11:30 +00:00
reset_cpu(0);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
}
/* Pass console handler in pei_data */
pei_data->tx_byte = console_tx_byte;
debug("PEI data at %p, size %x:\n", pei_data, sizeof(*pei_data));
x86: Use consistent name XXX_ADDR for binary blob flash address Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-17 07:50:42 +00:00
data = (char *)CONFIG_X86_MRC_ADDR;
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
if (data) {
int rv;
int (*func)(struct pei_data *);
debug("Calling MRC at %p\n", data);
post_code(POST_PRE_MRC);
func = (int (*)(struct pei_data *))data;
rv = func(pei_data);
post_code(POST_MRC);
if (rv) {
switch (rv) {
case -1:
printf("PEI version mismatch.\n");
break;
case -2:
printf("Invalid memory frequency.\n");
break;
default:
printf("MRC returned %x.\n", rv);
}
printf("Nonzero MRC return value.\n");
return -EFAULT;
}
} else {
printf("UEFI PEI System Agent not found.\n");
return -ENOSYS;
}
#if CONFIG_USBDEBUG
/* mrc.bin reconfigures USB, so reinit it to have debug */
early_usbdebug_init();
#endif
version = readl(MCHBAR_REG(0x5034));
debug("System Agent Version %d.%d.%d Build %d\n",
version >> 24 , (version >> 16) & 0xff,
(version >> 8) & 0xff, version & 0xff);
x86: ivybridge: Correct two typos for MRC It should be MRC, not MCR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:47 +00:00
debug("MRC output data length %#x at %p\n", pei_data->mrc_output_len,
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
pei_data->mrc_output);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/*
* Send ME init done for SandyBridge here. This is done inside the
* SystemAgent binary on IvyBridge
*/
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
done = x86_pci_read_config32(PCH_DEV, PCI_DEVICE_ID);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
done &= BASE_REV_MASK;
if (BASE_REV_SNB == done)
intel_early_me_init_done(ME_INIT_STATUS_SUCCESS);
else
intel_early_me_status();
post_system_agent_init(pei_data);
report_memory_config();
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
/* S3 resume: don't save scrambler seed or MRC data */
if (pei_data->boot_mode != PEI_BOOT_RESUME) {
/*
* This will be copied to SDRAM in reserve_arch(), then written
x86: ivybridge: Use APIs provided in the mrccache lib 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:40 +00:00
* to SPI flash in mrccache_save()
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
*/
gd->arch.mrc_output = (char *)pei_data->mrc_output;
gd->arch.mrc_output_len = pei_data->mrc_output_len;
ret = write_seeds_to_cmos(pei_data);
if (ret)
debug("Failed to write seeds to CMOS: %d\n", ret);
}
return 0;
}
int reserve_arch(void)
{
x86: ivybridge: Use APIs provided in the mrccache lib 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> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:40 +00:00
return mrccache_reserve();
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
}
static int copy_spd(struct pei_data *peid)
{
const int gpio_vector[] = {41, 42, 43, 10, -1};
int spd_index;
const void *blob = gd->fdt_blob;
int node, spd_node;
int ret, i;
for (i = 0; ; i++) {
if (gpio_vector[i] == -1)
break;
ret = gpio_requestf(gpio_vector[i], "spd_id%d", i);
if (ret) {
debug("%s: Could not request gpio %d\n", __func__,
gpio_vector[i]);
return ret;
}
}
spd_index = gpio_get_values_as_int(gpio_vector);
debug("spd index %d\n", spd_index);
node = fdtdec_next_compatible(blob, 0, COMPAT_MEMORY_SPD);
if (node < 0) {
printf("SPD data not found.\n");
return -ENOENT;
}
for (spd_node = fdt_first_subnode(blob, node);
spd_node > 0;
spd_node = fdt_next_subnode(blob, spd_node)) {
const char *data;
int len;
if (fdtdec_get_int(blob, spd_node, "reg", -1) != spd_index)
continue;
data = fdt_getprop(blob, spd_node, "data", &len);
if (len < sizeof(peid->spd_data[0])) {
printf("Missing SPD data\n");
return -EINVAL;
}
debug("Using SDRAM SPD data for '%s'\n",
fdt_get_name(blob, spd_node, NULL));
memcpy(peid->spd_data[0], data, sizeof(peid->spd_data[0]));
break;
}
if (spd_node < 0) {
printf("No SPD data found for index %d\n", spd_index);
return -ENOENT;
}
return 0;
}
/**
* add_memory_area() - Add a new usable memory area to our list
*
* Note: @start and @end must not span the first 4GB boundary
*
* @info: Place to store memory info
* @start: Start of this memory area
* @end: End of this memory area + 1
*/
static int add_memory_area(struct memory_info *info,
uint64_t start, uint64_t end)
{
struct memory_area *ptr;
if (info->num_areas == CONFIG_NR_DRAM_BANKS)
return -ENOSPC;
ptr = &info->area[info->num_areas];
ptr->start = start;
ptr->size = end - start;
info->total_memory += ptr->size;
if (ptr->start < (1ULL << 32))
info->total_32bit_memory += ptr->size;
debug("%d: memory %llx size %llx, total now %llx / %llx\n",
info->num_areas, ptr->start, ptr->size,
info->total_32bit_memory, info->total_memory);
info->num_areas++;
return 0;
}
/**
* sdram_find() - Find available memory
*
* This is a bit complicated since on x86 there are system memory holes all
* over the place. We create a list of available memory blocks
*/
static int sdram_find(pci_dev_t dev)
{
struct memory_info *info = &gd->arch.meminfo;
uint32_t tseg_base, uma_size, tolud;
uint64_t tom, me_base, touud;
uint64_t uma_memory_base = 0;
uint64_t uma_memory_size;
unsigned long long tomk;
uint16_t ggc;
/* Total Memory 2GB example:
*
* 00000000 0000MB-1992MB 1992MB RAM (writeback)
* 7c800000 1992MB-2000MB 8MB TSEG (SMRR)
* 7d000000 2000MB-2002MB 2MB GFX GTT (uncached)
* 7d200000 2002MB-2034MB 32MB GFX UMA (uncached)
* 7f200000 2034MB TOLUD
* 7f800000 2040MB MEBASE
* 7f800000 2040MB-2048MB 8MB ME UMA (uncached)
* 80000000 2048MB TOM
* 100000000 4096MB-4102MB 6MB RAM (writeback)
*
* Total Memory 4GB example:
*
* 00000000 0000MB-2768MB 2768MB RAM (writeback)
* ad000000 2768MB-2776MB 8MB TSEG (SMRR)
* ad800000 2776MB-2778MB 2MB GFX GTT (uncached)
* ada00000 2778MB-2810MB 32MB GFX UMA (uncached)
* afa00000 2810MB TOLUD
* ff800000 4088MB MEBASE
* ff800000 4088MB-4096MB 8MB ME UMA (uncached)
* 100000000 4096MB TOM
* 100000000 4096MB-5374MB 1278MB RAM (writeback)
* 14fe00000 5368MB TOUUD
*/
/* Top of Upper Usable DRAM, including remap */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
touud = x86_pci_read_config32(dev, TOUUD+4);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
touud <<= 32;
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
touud |= x86_pci_read_config32(dev, TOUUD);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/* Top of Lower Usable DRAM */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
tolud = x86_pci_read_config32(dev, TOLUD);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/* Top of Memory - does not account for any UMA */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
tom = x86_pci_read_config32(dev, 0xa4);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
tom <<= 32;
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
tom |= x86_pci_read_config32(dev, 0xa0);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
debug("TOUUD %llx TOLUD %08x TOM %llx\n", touud, tolud, tom);
/* ME UMA needs excluding if total memory <4GB */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
me_base = x86_pci_read_config32(dev, 0x74);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
me_base <<= 32;
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
me_base |= x86_pci_read_config32(dev, 0x70);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
debug("MEBASE %llx\n", me_base);
/* TODO: Get rid of all this shifting by 10 bits */
tomk = tolud >> 10;
if (me_base == tolud) {
/* ME is from MEBASE-TOM */
uma_size = (tom - me_base) >> 10;
/* Increment TOLUD to account for ME as RAM */
tolud += uma_size << 10;
/* UMA starts at old TOLUD */
uma_memory_base = tomk * 1024ULL;
uma_memory_size = uma_size * 1024ULL;
debug("ME UMA base %llx size %uM\n", me_base, uma_size >> 10);
}
/* Graphics memory comes next */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
ggc = x86_pci_read_config16(dev, GGC);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
if (!(ggc & 2)) {
debug("IGD decoded, subtracting ");
/* Graphics memory */
uma_size = ((ggc >> 3) & 0x1f) * 32 * 1024ULL;
debug("%uM UMA", uma_size >> 10);
tomk -= uma_size;
uma_memory_base = tomk * 1024ULL;
uma_memory_size += uma_size * 1024ULL;
/* GTT Graphics Stolen Memory Size (GGMS) */
uma_size = ((ggc >> 8) & 0x3) * 1024ULL;
tomk -= uma_size;
uma_memory_base = tomk * 1024ULL;
uma_memory_size += uma_size * 1024ULL;
debug(" and %uM GTT\n", uma_size >> 10);
}
/* Calculate TSEG size from its base which must be below GTT */
x86: Add a x86_ prefix to the x86-specific PCI functions These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-03-05 19:25:15 +00:00
tseg_base = x86_pci_read_config32(dev, 0xb8);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
uma_size = (uma_memory_base - tseg_base) >> 10;
tomk -= uma_size;
uma_memory_base = tomk * 1024ULL;
uma_memory_size += uma_size * 1024ULL;
debug("TSEG base 0x%08x size %uM\n", tseg_base, uma_size >> 10);
debug("Available memory below 4GB: %lluM\n", tomk >> 10);
/* Report the memory regions */
add_memory_area(info, 1 << 20, 2 << 28);
add_memory_area(info, (2 << 28) + (2 << 20), 4 << 28);
add_memory_area(info, (4 << 28) + (2 << 20), tseg_base);
add_memory_area(info, 1ULL << 32, touud);
x86: ivybridge: Request MTRRs for DRAM regions We should use MTRRs to speed up execution. Add a list of MTRR requests which will dealt with when we relocate and run from RAM. We set RAM as cacheable (with write-back) and registers as non-cacheable. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-01 23:18:10 +00:00
/* Add MTRRs for memory */
mtrr_add_request(MTRR_TYPE_WRBACK, 0, 2ULL << 30);
mtrr_add_request(MTRR_TYPE_WRBACK, 2ULL << 30, 512 << 20);
mtrr_add_request(MTRR_TYPE_WRBACK, 0xaULL << 28, 256 << 20);
mtrr_add_request(MTRR_TYPE_UNCACHEABLE, tseg_base, 16 << 20);
mtrr_add_request(MTRR_TYPE_UNCACHEABLE, tseg_base + (16 << 20),
32 << 20);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
/*
* If >= 4GB installed then memory from TOLUD to 4GB
* is remapped above TOM, TOUUD will account for both
*/
if (touud > (1ULL << 32ULL)) {
debug("Available memory above 4GB: %lluM\n",
(touud >> 20) - 4096);
}
return 0;
}
static void rcba_config(void)
{
/*
* GFX INTA -> PIRQA (MSI)
* D28IP_P3IP WLAN INTA -> PIRQB
* D29IP_E1P EHCI1 INTA -> PIRQD
* D26IP_E2P EHCI2 INTA -> PIRQF
* D31IP_SIP SATA INTA -> PIRQF (MSI)
* D31IP_SMIP SMBUS INTB -> PIRQH
* D31IP_TTIP THRT INTC -> PIRQA
* D27IP_ZIP HDA INTA -> PIRQA (MSI)
*
* TRACKPAD -> PIRQE (Edge Triggered)
* TOUCHSCREEN -> PIRQG (Edge Triggered)
*/
/* Device interrupt pin register (board specific) */
writel((INTC << D31IP_TTIP) | (NOINT << D31IP_SIP2) |
(INTB << D31IP_SMIP) | (INTA << D31IP_SIP), RCB_REG(D31IP));
writel(NOINT << D30IP_PIP, RCB_REG(D30IP));
writel(INTA << D29IP_E1P, RCB_REG(D29IP));
writel(INTA << D28IP_P3IP, RCB_REG(D28IP));
writel(INTA << D27IP_ZIP, RCB_REG(D27IP));
writel(INTA << D26IP_E2P, RCB_REG(D26IP));
writel(NOINT << D25IP_LIP, RCB_REG(D25IP));
writel(NOINT << D22IP_MEI1IP, RCB_REG(D22IP));
/* Device interrupt route registers */
writel(DIR_ROUTE(PIRQB, PIRQH, PIRQA, PIRQC), RCB_REG(D31IR));
writel(DIR_ROUTE(PIRQD, PIRQE, PIRQF, PIRQG), RCB_REG(D29IR));
writel(DIR_ROUTE(PIRQB, PIRQC, PIRQD, PIRQE), RCB_REG(D28IR));
writel(DIR_ROUTE(PIRQA, PIRQH, PIRQA, PIRQB), RCB_REG(D27IR));
writel(DIR_ROUTE(PIRQF, PIRQE, PIRQG, PIRQH), RCB_REG(D26IR));
writel(DIR_ROUTE(PIRQA, PIRQB, PIRQC, PIRQD), RCB_REG(D25IR));
writel(DIR_ROUTE(PIRQA, PIRQB, PIRQC, PIRQD), RCB_REG(D22IR));
/* Enable IOAPIC (generic) */
writew(0x0100, RCB_REG(OIC));
/* PCH BWG says to read back the IOAPIC enable register */
(void)readw(RCB_REG(OIC));
/* Disable unused devices (board specific) */
setbits_le32(RCB_REG(FD), PCH_DISABLE_ALWAYS);
}
x86: Add chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
int dram_init(void)
{
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
struct pei_data pei_data __aligned(8) = {
.pei_version = PEI_VERSION,
.mchbar = DEFAULT_MCHBAR,
.dmibar = DEFAULT_DMIBAR,
.epbar = DEFAULT_EPBAR,
x86: Rename MMCONF_BASE_ADDRESS and make it common across x86 This setting will be used by more than just ivybridge so make it common. Also rename it to PCIE_ECAM_BASE which is a more descriptive name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:33 +00:00
.pciexbar = CONFIG_PCIE_ECAM_BASE,
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
.smbusbar = SMBUS_IO_BASE,
.wdbbar = 0x4000000,
.wdbsize = 0x1000,
.hpet_address = CONFIG_HPET_ADDRESS,
.rcba = DEFAULT_RCBABASE,
.pmbase = DEFAULT_PMBASE,
.gpiobase = DEFAULT_GPIOBASE,
.thermalbase = 0xfed08000,
.system_type = 0, /* 0 Mobile, 1 Desktop/Server */
.tseg_size = CONFIG_SMM_TSEG_SIZE,
.ts_addresses = { 0x00, 0x00, 0x00, 0x00 },
.ec_present = 1,
.ddr3lv_support = 1,
/*
* 0 = leave channel enabled
* 1 = disable dimm 0 on channel
* 2 = disable dimm 1 on channel
* 3 = disable dimm 0+1 on channel
*/
.dimm_channel0_disabled = 2,
.dimm_channel1_disabled = 2,
.max_ddr3_freq = 1600,
.usb_port_config = {
/*
* Empty and onboard Ports 0-7, set to un-used pin
* OC3
*/
{ 0, 3, 0x0000 }, /* P0= Empty */
{ 1, 0, 0x0040 }, /* P1= Left USB 1 (OC0) */
{ 1, 1, 0x0040 }, /* P2= Left USB 2 (OC1) */
{ 1, 3, 0x0040 }, /* P3= SDCARD (no OC) */
{ 0, 3, 0x0000 }, /* P4= Empty */
{ 1, 3, 0x0040 }, /* P5= WWAN (no OC) */
{ 0, 3, 0x0000 }, /* P6= Empty */
{ 0, 3, 0x0000 }, /* P7= Empty */
/*
* Empty and onboard Ports 8-13, set to un-used pin
* OC4
*/
{ 1, 4, 0x0040 }, /* P8= Camera (no OC) */
{ 1, 4, 0x0040 }, /* P9= Bluetooth (no OC) */
{ 0, 4, 0x0000 }, /* P10= Empty */
{ 0, 4, 0x0000 }, /* P11= Empty */
{ 0, 4, 0x0000 }, /* P12= Empty */
{ 0, 4, 0x0000 }, /* P13= Empty */
},
};
pci_dev_t dev = PCI_BDF(0, 0, 0);
int ret;
debug("Boot mode %d\n", gd->arch.pei_boot_mode);
x86: ivybridge: Correct two typos for MRC It should be MRC, not MCR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:47 +00:00
debug("mrc_input %p\n", pei_data.mrc_input);
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
pei_data.boot_mode = gd->arch.pei_boot_mode;
ret = copy_spd(&pei_data);
if (!ret)
ret = sdram_initialise(&pei_data);
if (ret)
return ret;
rcba_config();
quick_ram_check();
writew(0xCAFE, MCHBAR_REG(SSKPD));
post_code(POST_DRAM);
ret = sdram_find(dev);
if (ret)
return ret;
gd->ram_size = gd->arch.meminfo.total_32bit_memory;
x86: Add chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
return 0;
}
Reference in a new issue Copy permalink