u-boot.git/arch/x86/include/asm/global_data.h, branch v2015.07

x86: Store the GDT pointer in global_data

2015-04-30T03:02:34Z

When we start up additional CPUs we want them to use the same Global Descriptor Table. Store the address of this in global_data so we can reference it later. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Implement a cache for Memory Reference Code parameters

2015-01-24T13:13:45Z

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

x86: Save mtrr support flag in global data

2015-01-24T00:24:55Z

CPUID (EAX 01H) returns MTRR support flag in EDX bit 12. Probe this flag in x86_cpu_init_f() and save it in global data. Signed-off-by: Bin Meng Acked-by: Simon Glass

x86: Add support for MTRRs

2015-01-13T15:25:00Z

Memory Type Range Registers are used to tell the CPU whether memory is cacheable and if so the cache write mode to use. Clean up the existing header file to follow style, and remove the unneeded code. These can speed up booting so should be supported. Add these to global_data so they can be requested while booting. We will apply the changes during relocation (in a later commit). Signed-off-by: Simon Glass

pci: Make pci apis usable before relocation

2015-01-13T01:03:41Z

Introduce a gd->hose to save the pci hose in the early phase so that apis in drivers/pci/pci.c can be used before relocation. Architecture codes need assign a valid gd->hose in the early phase. Some variables are declared as static so change them to be either stack variable or global data member so that they can be used before relocation, except the 'indent' used by CONFIG_PCI_SCAN_SHOW which just affects some print format. Signed-off-by: Bin Meng Acked-by: Simon Glass

x86: Support Intel FSP initialization path in start.S

2014-12-14T05:32:05Z

Per Intel FSP architecture specification, FSP provides 3 routines for bootloader to call. The first one is the TempRamInit (aka Cache-As-Ram initialization) and the second one is the FspInit which does the memory bring up (like MRC for other x86 targets) and chipset initialization. Those two routines have to be called before U-Boot jumping to board_init_f in start.S. The FspInit() will return several memory blocks called Hand Off Blocks (HOBs) whose format is described in Platform Initialization (PI) specification (part of the UEFI specication) to the bootloader. Save this HOB address to the U-Boot global data for later use. Signed-off-by: Bin Meng Acked-by: Simon Glass

x86: ivybridge: Implement SDRAM init

2014-11-21T06:34:15Z

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

x86: ivybridge: Add support for early GPIO init

2014-11-21T06:34:14Z

When not relying on Coreboot for GPIO init the GPIOs must be set up correctly. This is currently done statically through a rather ugly method. As the GPIOs are figured out they can be moved to the device tree and set up as needed rather than all at the start. In this implementation, board files should call ich_gpio_set_gpio_map() before the GPIO driver is used in order to provide the GPIO information. We use the early PCI interface so that this driver can now be used before relocation. Signed-off-by: Simon Glass

x86: ivybridge: Add early init for PCH devices

2014-11-21T06:34:14Z

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

x86: Support use of PCI before relocation

2014-11-21T06:34:12Z

Add support for using PCI before SDRAM is available, using early malloc() and global_data. Signed-off-by: Simon Glass Reviewed-by: Bin Meng