diff options
author | Simon Glass <sjg@chromium.org> | 2014-11-12 22:42:28 -0700 |
---|---|---|
committer | Simon Glass <sjg@chromium.org> | 2014-11-21 07:34:15 +0100 |
commit | 65dd74a674d636afcc14594c8308ff516e95a445 (patch) | |
tree | d102344ed0785567597dbd84aee6da20652531fd /arch/x86/cpu/start.S | |
parent | 3eafce05278f867678a66efd867f398cc055359a (diff) | |
download | u-boot-imx-65dd74a674d636afcc14594c8308ff516e95a445.zip u-boot-imx-65dd74a674d636afcc14594c8308ff516e95a445.tar.gz u-boot-imx-65dd74a674d636afcc14594c8308ff516e95a445.tar.bz2 |
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>
Diffstat (limited to 'arch/x86/cpu/start.S')
-rw-r--r-- | arch/x86/cpu/start.S | 10 |
1 files changed, 6 insertions, 4 deletions
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 1b738f9..b0d0ac0 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -78,20 +78,22 @@ car_init_ret: * We now have CONFIG_SYS_CAR_SIZE bytes of Cache-As-RAM (or SRAM, * or fully initialised SDRAM - we really don't care which) * starting at CONFIG_SYS_CAR_ADDR to be used as a temporary stack - * and early malloc area. + * and early malloc area. The MRC requires some space at the top. * * Stack grows down from top of CAR. We have: * * top-> CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE + * MRC area * global_data * x86 global descriptor table * early malloc area * stack * bottom-> CONFIG_SYS_CAR_ADDR */ - - /* Stack grows down from top of CAR */ - movl $(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE), %esp + movl $(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE - 4), %esp +#ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE + subl $CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %esp +#endif /* Reserve space on stack for global data */ subl $GENERATED_GBL_DATA_SIZE, %esp |