Merge branch 'master' of git://git.denx.de/u-boot-arm

Merge branch 'master' of git://www.denx.de/git/u-boot-imx

Merge git://git.denx.de/u-boot-dm

Conflicts:
drivers/serial/serial-uclass.c

Signed-off-by: Tom Rini <trini@ti.com>

Merge git://git.denx.de/u-boot-x86

Conflicts:
arch/x86/cpu/Makefile

Signed-off-by: Tom Rini <trini@ti.com>

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

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>

show more ...

x86: ivybridge: Add early init for PCH devices

Many PCH devices are hard-coded to a particular PCI address. Set these
up early in case they are needed.

Signed-off-by: Simon Glas

x86: ivybridge: Add early init for PCH devices

Many PCH devices are hard-coded to a particular PCI address. Set these
up early in case they are needed.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: chromebook_link: Implement CAR support (cache as RAM)

Add support for CAR so that we have memory to use prior to DRAM init.
On link there is a total of 128KB of CAR available, altho

x86: chromebook_link: Implement CAR support (cache as RAM)

Add support for CAR so that we have memory to use prior to DRAM init.
On link there is a total of 128KB of CAR available, although some is
used for the memory reference code.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Emit post codes in startup code for Chromebooks

On x86 it is common to use 'post codes' which are 8-bit hex values emitted
from the code and visible to the user. Traditionally two 7

x86: Emit post codes in startup code for Chromebooks

On x86 it is common to use 'post codes' which are 8-bit hex values emitted
from the code and visible to the user. Traditionally two 7-segment displays
were made available on the motherboard to show the last post code that was
emitted. This allows diagnosis of a boot problem since it is possible to
see where the code got to before it died.

On modern hardware these codes are not normally visible. On Chromebooks
they are displayed by the Embedded Controller (EC), so it is useful to emit
them. We must enable this feature for the EC to see the codes, so add an
option for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...