| Age | Commit message (Collapse) | Author |
|---|
|
This is similar to MCH in that it is used in various drivers. Add it to
the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
There are several blocks of registers that are accessed from all over the
code on Intel CPUs. These don't currently have their own driver and it is
not clear whether having a driver makes sense.
An example is the Memory Controller Hub (MCH). We map it to a known location
on some Intel chips (mostly those without FSP - Firmware Support Package).
Add a new header file for these registers, and move MCH into it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This code is used on several Intel CPUs. Move it into a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This cache-as-RAM (CAR) code is common to several Intel chips. Create a new
intel_common directory and move it in there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
These two identifiers can be useful for drivers which need to adjust their
behaviour depending on the CPU family or stepping (revision).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add two microcode files for broadwell.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The Intel SIPI (start-up inter-processor interrupt) vector is the entry
point for each secondary CPU (also called an AP - applications processor).
The assembler and C code are linked, so add comments to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The timeout step is always 50us. By updating apic_wait_timeout() to print
the debug messages we can simplify the code. Also tidy up a few messages and
comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Two power-on-self-test values are the same. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The Intel GPIO driver can set up the GPIO pin mapping when the first GPIO
is probed. However, it assumes that the first GPIO to be probed is in the
first GPIO bank. If this is not the case then the init will write to the
wrong registers.
Fix this. Also add a note that this code is deprecated. We should move to
using device tree instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
At present the board ID GPIOs are hard-coded. Move them to the device tree
so that we can use general SDRAM init code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The SDRAM SPD (Serial Presence Detect) information should be contained
with the SDRAM controller. This makes it easier for the controller to access
it and removes the need for a separate compatible string.
As a first step, move the information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
In order to use GPIO phandles we need to add some GPIO properties as
specified by the GPIO bindings. Add these for link.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Many of the model-specific indexes are common to several Intel CPUs. Add
some more common ones, and remove them from the ivybridge-specific header
file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This does not need to be modified at run-time, so make it const.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
SeaBIOS is an open source implementation of a 16-bit x86 BIOS.
It can run in an emulator or natively on x86 hardware with the
use of coreboot. With SeaBIOS's help, we can boot some OSes
that require 16-bit BIOS services like Windows/DOS.
As U-Boot, we have to manually create a table where SeaBIOS gets
system information (eg: E820) from. The table unfortunately has
to follow the coreboot table format as SeaBIOS currently supports
booting as a coreboot payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
To prepare generating coreboot table from U-Boot, implement functions
to handle the writing.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
For those secondary bootloaders like SeaBIOS who want to live in
the F segment, which conflicts the configuration table address,
now we allow write_tables() to write the configuration tables in
high area (malloc'ed memory).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Given all table write routines have the same signature, we can
simplify the codes by using a function table.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Change the parameter and return value of write_acpi_tables() to u32
to conform with other table write routines.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Define ROM_TABLE_ALIGN instead of using 1024 directly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add a new variable rom_table_start and pass it to ROM table write
routines. This reads better than previous single rom_table_end.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Clean up this file a little bit:
- Remove inclusion of <linux/compiler.h>
- Use tab in the macro definition
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
coreboot_tables.h should not include sysinfo related stuff.
Move those to asm/arch-coreboot/sysinfo.h.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Move asm/arch-coreboot/tables.h to asm/coreboot_tables.h so that
coreboot table definitions can be used by other x86 builds.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Use this new function in places where it simplifies the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This adds basic support to Intel Cougar Canyon 2 board, a board
based on Chief River platform with an Ivy Bridge processor and
a Panther Point chipset.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Wrap initialization codes with #ifndef CONFIG_HAVE_FSP #endif,
and enable the build for both FSP and non-FSP configurations.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Intel IvyBridge FSP seems to be buggy that it does not report memory
used by FSP itself as reserved in the resource descriptor HOB. The
FSP specification does not describe how resource descriptor HOBs are
generated by the FSP to describe what memory regions. It looks newer
FSPs like Queensbay and BayTrail do not have such issue. This causes
U-Boot relocation overwrites the important boot service data which is
used by FSP, and the subsequent call to fsp_notify() will fail.
To resolve this, we find out the lowest memory base address allocated
by FSP for the boot service data when walking through the HOB list in
fsp_get_usable_lowmem_top(). Check whether the memory top address is
below the FSP HOB list, and if not, use the lowest memory base address
allocated by FSP as the memory top address.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested on link (ivybridge non-FSP)
Tested-by: Simon Glass <sjg@chromium.org>
|
|
IvyBridge FSP package is built with a base address at 0xfff80000,
and does not use UPD data region. This adds basic FSP support.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested on link (ivybridge non-FSP)
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Purely by code inspection, it looks like the parameter order to memalign()
is swapped; its parameters are (align, size). 4096 is a likely desired
alignment, and a variable named size sounds like a size:-)
Fixes: 45b5a37836d5 ("x86: Add multi-processor init")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
|
|
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
|
|
Now that we have converted all x86 codes to DM PCI, drop pci_type1.c
which is only built for legacy PCI. Also per checkpatch.pl warning,
DEFINE_PCI_DEVICE_TABLE is now deprecated so drop that too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Now that all x86 codes have been converted to use proper DM PCI APIs,
it's time to disable the legacy compatible layer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
There are still two places in Quark's MRC codes that use the generic
legacy PCI APIs, but as we are phasing out these legacy APIs, switch
to use Quark's own PCI config routines.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have converted all x86 codes to use DM PCI APIs,
drop those legacy ones.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Drop legacy PCI APIs usage in pci_assign_irqs() as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Use pci_[read|write]_config intead of x86_pci_[read|write]_config.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
With recent DM PCI changes to vesa_fb driver, external graphics
card does not work any more. This is because: after setting the
function disable bit, IGD and SDVO devices will disappear in the
PCI configuration space. This however creates an inconsistent state
from a driver model PCI controller point of view, as these two PCI
devices are still attached to its parent's child device list as
maintained by the driver model. Some driver model PCI APIs like
dm_pci_find_class() used in the vesa_fb driver, are referring to
the list to speed up the finding process instead of re-enumerating
the whole PCI bus, so it gets the stale cached data which is wrong.
To fix this, manually remove these two devices.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Once we get udevice of IGD and SDVO, we can use its udevice to
access PCI configuration space with dm_pci_write_config32().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
So far disable_igd() does not have any return value, but we may need
that in the future.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have irq router's udevice passed as a parameter, it's
time to start using the DM PCI API instead of those legacy ones.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
At present irq_router is declared as a static struct irq_router in
arch/x86/cpu/irq.c. Since it's a driver control block, it makes sense
to move it to a per driver priv. Adjust existing APIs to accept an
additional parameter of irq_router's udevice.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
There is no need to parse PCH's <reg> property as we have already
a DM PCI API dm_pci_get_bdf() that can handle this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
IOBASE is now obtained from PCH driver, drop this <io-base> property.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
asm/arch/gpio.h is not needed anymore as we get the GPIO base from
PCH driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
At present this GPIO driver still uses the legacy PCI API. Now that
we have proper PCH drivers we can use those to obtain the information
we need. While the device tree has nodes for the GPIO peripheral it is
not in the right place. It should be on the PCI bus as a sub-peripheral
of the PCH device.
Update the device tree files to show the GPIO controller within the PCH,
so that PCI access works as expected. This also adds '#address-cells'
and '#size-cells' to the PCH node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Implement get_gpio_base op for bd82x6x, pch7 and pch9 drivers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Spell out 'sbase' to 'spi_base' so that it looks clearer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
