summaryrefslogtreecommitdiff
path: root/arch/x86/cpu/ivybridge/sdram.c
Commit message (Collapse)AuthorAgeLines
* x86: link: Correct a failure in DRAM initSimon Glass2016-07-12-0/+5
| | | | | | | | | | With the change to set up pinctrl after relocation, link fails to boot. Add a special case in the link code to handle this. Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r()) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Unify reserve_arch() for all x86 boardsBin Meng2016-05-23-5/+0
| | | | | | | | Instead of asking each platform to provide reserve_arch(), supply it in arch/x86/cpu/cpu.c in a unified way. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Convert to use the common SDRAM codeSimon Glass2016-03-17-311/+83
| | | | | | | Adjust the existing implementation to use the new common SDRAM init code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Move Intel Management Engine code to a common placeSimon Glass2016-03-17-1/+2
| | | | | | | | | | Some of the Intel ME code is common to several Intel CPUs. Move it into a common location. Add a header file for report_platform.c also. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [squashed in http://patchwork.ozlabs.org/patch/598372/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Create a common header for Intel register accessSimon Glass2016-03-17-1/+2
| | | | | | | | | | | | | | There are several blocks of registers that are accessed from all over the code on Intel CPUs. These don't currently have their own driver and it is not clear whether having a driver makes sense. An example is the Memory Controller Hub (MCH). We map it to a known location on some Intel chips (mostly those without FSP - Firmware Support Package). Add a new header file for these registers, and move MCH into it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: Use uclass_first_device_err() where it is usefulSimon Glass2016-03-14-3/+1
| | | | | | Use this new function in places where it simplifies the code. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Set up a shared syscon numbering schemaSimon Glass2016-01-24-3/+3
| | | | | | | | | Each system controller can have a number to identify it. It can then be accessed using syscon_get_by_driver_data(). Put this in a shared header file and update the only current user. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert report_platform to DM PCI APISimon Glass2016-01-24-1/+1
| | | | | | | Convert these functions to use the driver model PCI API. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert SDRAM init to use driver modelSimon Glass2016-01-24-7/+13
| | | | | | | | | SDRAM init needs access to the Northbridge controller and the Intel Management Engine device. Add the latter to the device tree and convert all of this code to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert sdram_initialise() to use DM PCI APISimon Glass2016-01-24-9/+10
| | | | | | | | Convert this function to use the the driver model PCI API. We just need to pass in the northbridge device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert dram_init() to use DM PCI APISimon Glass2016-01-24-14/+25
| | | | | | | | Convert the top part of the DRAM init to use the driver model PCI API. Further work will complete the transformation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Enable the MRC cacheBin Meng2015-10-21-8/+2
| | | | | | | | | This works correctly now, so enable it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Dropped malloc() and adjusted commit message: Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Measure the MRC code execution timeSimon Glass2015-10-21-0/+3
| | | | | | | | This code takes about 450ms without the MRC cache and about 27ms with the cache. Add a debug timer so that this time can be displayed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Check the RTC return valueSimon Glass2015-10-21-3/+10
| | | | | | | 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>
* x86: ivybridge: Use 'ret' instead of 'rcode'Simon Glass2015-10-21-8/+8
| | | | | | | 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>
* x86: ivybridge: Correct two typos for MRCBin Meng2015-10-21-2/+2
| | | | | | | It should be MRC, not MCR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Use struct mrc_region to describe a mrc regionBin Meng2015-10-21-1/+1
| | | | | | | | | | | | | | | | 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>
* x86: ivybridge: Use APIs provided in the mrccache libBin Meng2015-10-21-108/+4
| | | | | | | | 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>
* x86: Move mrccache.[c|h] to a common placeBin Meng2015-10-21-1/+1
| | | | | | | | 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>
* x86: Enable DM RTC support for all x86 boardsBin Meng2015-07-28-8/+24
| | | | | | | | 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')
* x86: ivybridge: Use reset_cpu()Simon Glass2015-04-29-2/+1
| | | | | | | | 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>
* dm: x86: spi: Convert ICH SPI driver to driver modelSimon Glass2015-04-18-7/+10
| | | | | | | | | | | | 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>
* x86: Add a x86_ prefix to the x86-specific PCI functionsSimon Glass2015-04-16-10/+10
| | | | | | | | | | | | 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>
* x86: Rename MMCONF_BASE_ADDRESS and make it common across x86Simon Glass2015-02-05-1/+1
| | | | | | | | | 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>
* x86: Implement a cache for Memory Reference Code parametersSimon Glass2015-01-24-0/+253
| | | | | | | | | | | 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>
* x86: ivybridge: Request MTRRs for DRAM regionsSimon Glass2015-01-13-0/+10
| | | | | | | | | 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>
* x86: Use consistent name XXX_ADDR for binary blob flash addressBin Meng2014-12-18-1/+1
| | | | | Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Implement SDRAM initSimon Glass2014-11-21-1/+552
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86: Add chromebook_link boardSimon Glass2014-11-21-0/+20
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>
generated by cgit v1.1 at 2024-09-04 16:59:40 +0000