This commit cleans up the lapic codes:
- Delete arch/x86/include/asm/lapic_def.h, and move register and bit
defines into arch/x86/include/asm/lapic.h
- Use MSR defines from msr-index.h in enable_lapic() and disable_lapic()
- Remove unnecessary stuff like NEED_LAPIC, X86_GOOD_APIC and
CONFIG_AP_IN_SIPI_WAIT
- Move struct x86_cpu_priv defines to asm/arch-ivybridge/bd82x6x.h, as
it is not apic related and only used by ivybridge
- Fix coding convention issues
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Most modern x86 CPUs include more than one CPU core. The OS normally requires
that these 'Application Processors' (APs) be brought up by the boot loader.
Add the required support to U-Boot to init additional APs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
The PCH (Platform Controller Hub) is on the PCI bus, so show it as such.
The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the
right place also.
Rename the compatible strings to be more descriptive since this board is the
only user. Once we are using driver model fully on x86, these will be
dropped.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple uclass for this chip which is often found in x86 systems
where the CPU is a separate device.
The device can have children, so make it scan the device tree for these.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Move chromebook_link over to driver model for PCI.
This involves:
- adding a uclass for platform controller hub
- removing most of the existing PCI driver
- adjusting how CPU init works to use driver model instead
- rename the lpc compatible string (it will be removed later)
This does not really take advantage of driver model fully, but it does work.
Furture work will improve the code structure to remove many of the explicit
calls to init the board.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we do more in this function than we should. Split out the
post-driver-model part into a separate function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
If the BIOS emulator is not available, allow use of native execution if
available, and vice versa. This can be controlled by the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
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>
At present the normal update (which happens much later) does not work. This
seems to have something to do with the 'no eviction' mode in the CAR, or at
least moving the microcode update after that causes it not to work.
For now, do an update early on so that it definitely works. Also refuse to
continue unless the microcode update check (later in boot) is successful.
Signed-off-by: Simon Glass <sjg@chromium.org>
Cache-as-RAM should be turned off when we relocate since we want to run from
RAM. Add a function to perform this task.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Set the frame buffer to write-combining. This makes it faster, although for
scrolling write-through is even faster for U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
This is set up along with CAR (Cache-as-RAM) anyway. When we relocate we
don't really need ROM caching (we read the VGA BIOS from ROM but that is
about it)
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
This takes about about 700ms on link when running natively and 900ms when
running using the emulator. It is a waste of time if video is not enabled,
so don't bother running the video BIOS in that case.
We could add a command to run the video BIOS later when needed, but this is
not considered at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are several problems in the code. The device tree decode is incorrect
in ways that are masked due to a matching bug. Both are fixed. Also
microcode_read_rev() should be inline and called before the microcode is
written.
Note: microcode writing does not work correctly on ivybridge for me. Further
work is needed to resolve this. But this patch tidies up the existing code
so that will be easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are new microcode revisions available. Update them. Also change
the format so that the first 48 bytes are not omitted from the device tree
data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Intel's Graphics Media Accelerator (GMA) is a generic name for a wide range
of video devices. Add code to set up the hardware on ivybridge. Part of the
init happens in native code, part of it happens in a 16-bit option ROM for
those nostalgic for the 1970s.
Signed-off-by: Simon Glass <sjg@chromium.org>
Set up all the remaining pieces of the LPC (low-pin-count) peripheral in
PCH (Peripheral Controller Hub).
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
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>
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>
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>
Bin Meng
Simon Glass