- Nov 21, 2014
-
-
Simon Glass authored
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>
-
Simon Glass authored
The local advanced programmable interrupt controller is not used much in U-Boot but we do need to set it up. Add basic support for this, which will be extended as needed. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This function can probably be used on all x86 boards, so move it into the common file. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Enable GPIO support and provide the required GPIO setup information to the driver. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
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 <sjg@chromium.org>
-
Simon Glass authored
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>
-
Simon Glass authored
Add two microcode updates that are provided for this CPU. The updates have been converted to a device tree form. Note: SPDX submission has been done. If this license is approved I will convert the files to use SPDX. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Microcode updates are stored in the device tree. Work through these and apply any that are needed. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
The built-in self test value should be checked before we continue booting. Refuse to continue if there is something wrong. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Set up the flex ratio (controls speed versus heat output) and a few other very early things. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
It is convenient to be able to adjust MSRs with a structure that splits the two 32-bit halves into separate fields, as they are often dealt with separately. Add a few functions to support this. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
These are available on other architectures. Make them available on x86 also. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
There is no need to explicitly write 'arch-coreboot' when including headers, as when the arch directory points to coreboot the correct files will be used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
The PCH (Platform Controller Hub) includes an LPC (Low Pin Count) device which provides a serial port. This is accessible on Chromebooks, so enable it early in the boot process. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add simple PCI access routines for x86 which permit use before relocation. The normal PCI stack is still used, but for pre-relocation use there can only ever be a single hose. After relocation, fall back to the normal access, although even then on x86 machines there is normally only a single PCI bus. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Enable PCI so we can access devices that need to be set up before relocation. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add support for using PCI before SDRAM is available, using early malloc() and global_data. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
We want access PCI earlier in the init sequence, so refactor the code so that it does not require use of a BSS variable to work. This will allow us to use early malloc() to store information about a PCI hose. Common PCI code moves to arch/x86/cpu/pci.c and a new board_pci_setup_hose() function is provided by boards to set up the (single) hose used by that board. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
On x86 machines U-Boot needs to be added to a large ROM image which is then flashed onto the target board. The ROM has a particular format so it makes sense for U-Boot to build this image automatically. Unfortunately it relies on binary blobs so we cannot require this for the default build as yet. Create a u-boot.rom output file for this purpose. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
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>
-
Simon Glass authored
Allow an empty ROM to be created, without needing to provide a descriptor. The descriptor is not needed on some x86 boards. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Unfortunately MSR_FSB_FREQ is not available on this CPU, and the PIT method seems to take up to 50ms which is much too long. For this CPU we know the frequency, so add another special case for now. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Masahiro Yamada authored
The references of CONFIG_SYS_COREBOOT in arch/x86/cpu/coreboot/Makefile are redundant because the build system descends into the directory only when CONFIG_SYS_COREBOOT is defined. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Acked-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This implementation has a 'cpu' prefix and returns a pointer to the string, avoiding the need for copying. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
These are no-longer needed so drop them. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Add a function to get the stack pointer and another to halt the CPU. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Many of the x86 CONFIG options will be common across different boards. Move them to a common file. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Newer Intel chips require a Management Engine which requires a particular format for the SPI flash that contains the boot loader. Add a tool that supports creating and modifying these ROM images. This tool is from Chrome OS but has been cleaned up to use U-Boot style and to add comments. A few features have been added also. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
For board IDs a common approach is to set aside several GPIOs for use in determining the board ID. This can provide information about board features and the revision. Add a function that turns a list of GPIOs into an integer by assigning each GPIO to a single bit. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
In general we can't store things in the data section until we have inited SDRAM. Some platforms allow this (e.g. those with SPL) but some don't. Move the pointer to global_data so that it will work on all platforms. Without this fix the serial port will not work prior to relocation with driver model on some platforms. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Sometimes an array can be of variable size up to a maximum. Add a helper function to decode this. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
For some CPUs, having malloc() available very early is useful. There is no reason to delay this since early malloc is allocated before board_init_f() is called. Move early malloc() init nearer to the start of the init sequence. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This warning appears even though it seems that the compiler could work it out. Fix it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Bin Meng authored
Return the saved TSC frequency in get_tbclk_mhz(). Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Acked-by:
Simon Glass <sjg@chromium.org> Tested-by:
Simon Glass <sjg@chromium.org>
-
Bin Meng authored
Use the same way that Linux does for quick TSC calibration via PIT when calibration via MSR fails. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Bin Meng authored
Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on processors which do not have this MSR. Instead only doing the MSR calibration for known/supported CPUs. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Acked-by:
Simon Glass <sjg@chromium.org> Tested-by:
Simon Glass <sjg@chromium.org>
-
Bin Meng authored
The CPU identification happens in x86_cpu_init_f() and corresponding fields are saved in the global data for later use. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
The built in self test value is available in register eax on start-up. Save it so that it can be accessed later. Unfortunately we must wait until the global_data is available before we can do this, so there is a little bit of shuffling to keep it around. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-