Convert this function to use the the driver model PCI API. We just need
to pass in the northbridge device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Convert the top part of the DRAM init to use the driver model PCI API.
Further work will complete the transformation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Convert this function over to use the driver model PCI API. In this case
we want to avoid using the real PCI devices since they have not yet been
probed. Instead, write directly to their PCI configuration address.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move the init code into the I2C driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust this code to use the driver model PCI API. This is all called through
lpc_init_extra().
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is nothing special about the ivybridge pci driver now, so just use
the generic one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Drop the lpc_init_extra() function and just use the post-relocation LPC
probe() instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This graphics init code is best placed in the gma init code. Move the code
and drop the function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust the functions in this file to use the driver model PCI API.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Instead of manually initing the device, probe the SATA device and move the
init there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The SATA device needs to set itself up so that it appears correctly on the
PCI bus. The easiest way to do this is to set it up to probe before
relocation. This can do the early setup.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust most of the remaining functions in this file to use the driver model
PCI API. The one remaining function is bridge_silicon_revision() which will
need a little more work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Instead of calling the northbridge and PCH init from bd82x6x_init_extra()
when the PCI bus is probed, call it from the respective drivers. Also drop
the Northbridge init as it has no effect. The registers it touches appear to
be read-only.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These devices currently need to be inited early in boot. Once we have the
init in the right places (with each device doing its own init and no
problems with ordering) we should be able to remove this. For now it is
needed to keep things working.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are no other implementations of this function, and boards that need it
can implement a CPU driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is now part of the northbridge driver, so move it into the same
place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This uses a non-existent node at present. It should use the first CPU node.
The referenced property does not exist (the correct value is the default of
0), but this allows the follow-on init to complete.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use the CPU driver's probe() method to perform the CPU init. This will happen
automatically when the first CPU is probed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The existing ivybridge code predates the normal multi-core CPU init, and
it is not used. Remove it and add CPU nodes to the device tree so that all
four CPUs are set up. Also enable the 'cpu' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The watchdog can be reset later when probing the LPC after relocation.
Move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't need to init the graphics controller so early. Move it alongside
the other graphics setup, just before we run the ROM.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We can drop the explicit probe of the PCH since the LPC is a child device
and this will happen automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In preparation for adding an init() method to the LPC uclass, rename this
existing function so that it will not conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now that we have a proper driver for the nortbridge, set it up in by probing
it, and move the early init code into the probe() method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver with an empty probe function where we can move init code in
follow-on patches.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rename the existing bd82x6x_init() to bd82x6x_init_extra(). We will remove
this in a later patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move SPI and port80 init to lpc_early_init(), called from the LPC's probe()
method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move this code to the LPC's probe() method so that it will happen
automatically when the LPC is probed before relocation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Find the LPC device in arch_cpu_init_dm() as a first step to converting
this code to use driver model. Probing the LPC will probe its parent (the
PCH) automatically, so make sure that probing the PCH does nothing before
relocation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are no callers now. Platforms which need to set up interrupts their
own way can implement an interrupt driver. Drop this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for interrupts on queensbay and move the code currently in
cpu_irq_init() into its probe() method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for interrupts on quark and move the code currently in
cpu_irq_init() into its probe() method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Instead of searching for the device tree node, use the IRQ device which has
a record of it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Most x86 interrupt drivers will want to use the standard PIRQ routing and
table setup. Put this code in a common function so it can be used by those
drivers that want it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present interrupt routing is set up from arch_misc_init(). We can do it
a little later instead, in interrupt_init().
This removes the manual pirq_init() call. Where the platform does not have
an interrupt router defined in its device tree, no error is generated. Some
platforms do not have this.
Drop pirq_init() since it is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
It seems likely that at some point we will want a generic interrupt uclass.
But this is a big undertaking as it involves unifying code across multiple
architectures.
As a first step, create a simple IRQ uclass and a driver for x86. This can
be generalised later as required.
Adjust pirq_init() to probe this driver, which has the effect of creating
routing tables and setting up the interrupt routing. This is a start
towards making interrupts fit better with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present this SPI driver works by searching the PCI buses for its
peripheral. It also uses the legacy PCI API.
In addition the driver has code to determine the type of Intel PCH that is
used (version 7 or version 9). Now that we have proper PCH drivers we can
use those to obtain the information we need.
While the device tree has a node for the SPI peripheral it is not in the
right place. It should be on the PCI bus as a sub-peripheral of the LPC
device.
Update the device tree files to show the SPI controller within the PCH, so
that PCI access works as expected.
This patch includes Bin's fix-up patch from here:
https://patchwork.ozlabs.org/patch/569478/
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
With driver model timer conversion, quark based board does not boot
any more as mdelay() is called during quark_pcie_early_init() which
is before driver model gets initialized. Fix this breakage.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.
Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>
Currently, when booting with more that one CPU enabled, U-Boot scans
'cpu' node in device tree and calculates CPU number. This does not scale
well as changing CPU number also requires modifying .dts and re-compiling
U-Boot.
This patch uses fw_cfg interface provided by QEMU to detect online CPU
number at runtime, and dynamically adds 'cpu' device to U-Boot's driver
model.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Use actual CPU number, instead of maximum cpu configured, to allocate
stack memory in 'load_sipi_vector'
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Rename 'find_cpu_by_apid_id' to 'find_cpu_by_apic_id'. This should be a
typo.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a cpu uclass driver for qemu. Previously, the qemu target gets cpu
number from board dts files, which are manually created at compile time.
This does not scale when more cpus are assigned to guest as the dts files
must be modified as well.
This patch adds a cpu uclass driver for qemu targets to directly read
online cpu number from firmware.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
The QEMU fw_cfg interface allows the guest to retrieve various data
information from QEMU. For example, APCI/SMBios tables, number of online
cpus, kernel data and command line, etc.
This patch adds support for QEMU fw_cfg interface.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Do not set HAVE_INTEL_ME by default as for some cases Intel ME
firmware even does not reside on the same SPI flash as U-Boot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
fsp_init() runtime buffer parameter might be different across
different platforms. Move this to update_fsp_configs().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Those comments in update_fsp_configs() are not correct. Remove them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
To support platform-specific configurations (might not always be
UPD on some platform), use a better name update_fsp_configs() and
accepct struct fsp_config_data as its parameter so that platform
codes can handle whatever configuration data for that FSP.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
At present pci_mmc_init() does not correctly use the PCI function since the
list it passes is not terminated. The array size passed to pci_mmc_init() is
actually not used correctly. Fix this and adjust the pci_mmc_init() to scan
all available MMC devices.
Adjust this code to use the new driver model PCI API.
This should move over to the new MMC uclass at some point.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust these files to use the driver-model PCI API instead of the legacy
functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Use the driver-model PCI functions here where possible. For now we have to
search for the device with pci_bus_find_bdf() but at some point we can put
this in a proper driver and avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These are currently dead codes. Until we have complete ACPI support,
we don't know if it works or not. Remove to avoid confusion.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
This Kconfig option name indicates it has something to do with cpu
socket, however it is actually not the case. Remove it and move
options inside it to NORTHBRIDGE_INTEL_IVYBRIDGE.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
There are some options which are never used, and also some options
which are selected by others but have never been a Kconfg option.
Clean these up.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
NORTHBRIDGE_INTEL_SANDYBRIDGE is for sandybridge, not ivybridge.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Right now i8254_init() is called from timer_init() in the tsc timer
driver. But actually i8254 and tsc are completely different things.
Since tsc timer has been converted to driver model, we should find
a new place that is appropriate for U-Boot to call i8254_init(),
which is now x86_cpu_init_f().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Now that we have converted all x86 boards to use driver model timer,
remove these legacy timer codes in the tsc driver.
Note this also removes the TSC_CALIBRATION_BYPASS Kconfig option,
as it is not needed with driver model.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This is not referenced anywhere. Remove it, as well as
tsc_base_kclocks and tsc_prev in the global data.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Fix 'Reomve' typo:
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we have converted all x86 boards to use driver model pci,
remove these legacy pci codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Move chipset-specific codes such as PAM init, PCIe ECAM and MP table
from pci.c to qemu.c, to prepare for DM PCI conversion.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The call to pci_run_vga_bios() is not needed as this is handled
in the vesa_fb driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
According to Atom E6xx datasheet, setting VGA Disable (bit17)
of Graphics Controller register (offset 0x50) prevents IGD
(D2:F0) from reporting itself as a VGA display controller
class in the PCI configuration space, and should also prevent
it from responding to VGA legacy memory range and I/O addresses.
However test result shows that with just VGA Disable bit set and
a PCIe graphics card connected to one of the PCIe controllers on
the E6xx, accessing the VGA legacy space still causes system hang.
After a number of attempts, it turns out besides VGA Disable bit,
the SDVO (D3:F0) device should be disabled to make it work.
To simplify, use the Function Disable register (offset 0xc4)
to disable both IGD (D2:F0) and SDVO (D3:F0) devices. Now these
two devices will be completely disabled (invisible in the PCI
configuration space) unless a system reset is performed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Rename pcat_timer.c to i8254.c and pcat_interrupts.c to i8259.c,
to match their header file names (i8254.h and i8259.h).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This works correctly now, so enable it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Dropped malloc() and adjusted commit message:
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code takes about 450ms without the MRC cache and about 27ms with the
cache. Add a debug timer so that this time can be displayed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present a missing $ causes this code to hang when using the MRC cache/
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support for the debug UART on link. This is useful for early debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If the debug UART is enabled, get it ready for use at the earliest possible
opportunity. This is not actually very early, but until we have a stack it
is difficult to make it work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In sipi_vector.S, cpu_index (passed as %eax) is wrongly overwritten
by the ap_init() function address. Correct it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Using existing mrccache library to implement mrc cache support
for Intel Quark.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
With MRC cache enabled, when typing 'reset' in the U-Boot shell,
BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0
Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
About to call MrcInit();
BayleyBay Platform Type
CurrentMrcData.BootMode = 4
Taking Fastboot path!
Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Currently struct fmap_entry is used to describe a mrc region.
However this structure contains some other fields that are not
related to mrc cache and causes confusion. Besides, it does not
include a base address field to store SPI flash's base address.
Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to
calculate the SPI flash base address, which unfortunately is
not 100% correct as CONFIG_ROM_SIZE may not match the whole
SPI flash size.
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Remove the call to custom mrc cache APIs, and use the ones
provided in the mrccache lib.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
mrccache implementation can be common for all boards. Move it
from ivybridge cpu directory to the common lib directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
Add a Kconfig option to disable the Integrated Graphics Device (IGD)
so that it does not show in the PCI configuration space as a VGA
disaplay controller. This gives a chance for U-Boot to run PCI/PCIe
based graphics card's VGA BIOS and use that for the graphics console.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Remove bd82x6x_pci_bus_enable_resources() that is not called anywhere.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Quark SoC does not support MSR MTRRs. Fixed and variable range MTRRs
are accessed indirectly via the message port and not the traditional
MSR mechanism. Only UC, WT and WB cache types are supported.
We configure all the fixed range MTRRs with common values (VGA RAM
as UC, others as WB) and 3 variable range MTRRs for ROM/eSRAM/RAM as
WB, which significantly improves the boot time performance.
With this commit, it takes only 2 seconds for U-Boot to boot to shell
on Intel Galileo board. Previously it took about 6 seconds.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Thermal sensor on Quark SoC needs to be properly initialized per
Quark firmware writer guide, otherwise when booting Linux kernel,
it triggers system shutdown because of wrong temperature in the
thermal sensor is detected by the kernel driver (see below):
[ 5.119819] thermal_sys: Critical temperature reached(206 C),shutting down
[ 5.128997] Failed to start orderly shutdown: forcing the issue
[ 5.135495] Emergency Sync complete
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When Linux kernel boots, it hangs at:
[ 0.829408] Intel Quark side-band driver registered
This happens when Quark kernel Isolated Memory Region (IMR) driver
tries to lock an IMR register to protect kernel's text and rodata
sections. However in order to have IMR function correctly, HMBOUND
register must be locked otherwise the system just hangs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Change existing codes to use clrbits, setbits, clrsetbits macros.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This adds static register programming for PCIe and USB after memory
init as required by Quark firmware writer guide. Although not doing
this did not cause any malfunction, just do it for safety.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Convert to use DM version of Designware ethernet driver on Intel
quark/galileo.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
USB PHY needs to be properly initialized per Quark firmware writer
guide, otherwise the EHCI controller on Quark SoC won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Quark SoC holds the PCIe controller in reset following a power on.
U-Boot needs to release the PCIe controller from reset. The PCIe
controller (D23:F0/F1) will not be visible in PCI configuration
space and any access to its PCI configuration registers will cause
system hang while it is held in reset.
Enable PCIe controller per Quark firmware writer guide.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
If we convert to use driver model pci on quark, we will encounter
some chicken and egg problems like below:
- To enable PCIe root ports, we need program some registers on the
message bus via pci bus. With driver model, the first time to
access pci bus, the pci enumeration process will be triggered.
But without first enabling PCIe root ports, pci enumeration
just hangs when scanning PCIe root ports.
- Similar situation happens when trying to access GPIO from the
PCIe enabling codes, as GPIO requires its block base address
to be assigned via a pci configuration register in the bridge.
To avoid such dilemma, replace all pci calls in the quark codes
to use the local version which does not go through driver model.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Intel Quark SoC has a low end x86 processor with only 400MHz
frequency. Currently it takes about 15 seconds for U-Boot to
boot to shell and the most time consuming part is with MRC,
which is about 12 seconds. MRC programs lots of registers on
the SoC internal message bus indirectly accessed via pci bus.
To speed up the boot, create an optimized version of pci config
read/write dword routines which directly operate on PCI I/O ports.
These two routines are inlined to provide better performance too.
Now it only takes about 3 seconds to finish MRC, which is really
fast (4 times faster than before).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The DSDT table contains a bytecode that is executed by a driver in the kernel.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com>
Tested with QEMU '-M q35'
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This patch mainly adds ACPI support to QEMU.
Verified by booting Linux kernel on QEMU Q35.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com>
Minor whitespace fixes and dropped mention of i440FX in commit message:
Signed-off-by: Simon Glass <sjg@chromium.org>
It turns out that calling fsp_init_phase_pci() in arch_misc_init()
is subject to break pci device drivers as with driver model, when
the bus enumeration happens is not deterministic.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
With dm pci conversion, pci config read/write in unprotect_spi_flash()
silently fails as at that time dm pci is not ready and bus enumeration
is not done yet. Actually we don't need to do this in that early phase,
hence we delay this call to arch_misc_init().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add some comments in start.S for the fact that with FSP U-Boot
actually enters the code twice. Also change to use fsp_init()
and fsp_continue for accuracy.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Some platforms may have >=4GiB memory, so we need make U-Boot report
such configuration correctly when booting as the coreboot payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Now that we have generic routine to calculate relocation address,
remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
coreboot has some extensions (type 6 & 16) to the E820 types.
When we detect this, mark it as E820_RESERVED.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This can fail for internal reasons, so return a sensible value rather than
a random one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Multiple APs are brought up simultaneously and they may get the same
seq num in the uclass_resolve_seq() during device_probe(). To avoid
this, set req_seq to the reg number in the device tree in advance.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When trying to figure out where an exception has occured, the relocated
address is not a lot of help. Its value depends on various factors. Show
the un-relocated IP as well. This can be looked up in System.map directly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.
Drop the unneeded code and adjust the hooks in board_f.c to cope.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rather than keeping track of the Global Descriptor Table in its own memory
we may as well put it in global_data with everything else. As a first step,
stop using the separately allocated GDT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should not fiddle with interrupts or the FSP when running as an EFI
payload. Detect this and skip this code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should signal to the FSP that PCI enumeration is complete. Perform this
task in a suitable place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function can fail. In this case we should return the error rather than
swallowing it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code could use a little tightening up. There is some repetition and
an odd use of fdtdec_get_int_array().
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself.
Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
settings from the Intel FSPv4 Gold release to the respective dts files,
with the condition that the memory-down parameters for MinnowMax are
also used.
Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Removed fsp,mrc-debug-msg and fsp,enable-xhci for minnowmax, bayleybay
Fixed lines >80col
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.
Unfortunately the debug UART implementation needs a stack to work. I cannot
seem to remove this limitation as the absolute 'jmp %eax' instruction goes
off into the weeds.
So this means that the character output cannot be any earlier than
car_init_ret, where memory is available for a stack.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Disable a few things which interfere with the EFI init. This allows QEMU to
to boot into EFI, load a U-Boot payload then boot to the U-Boot prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Disable a few things which interfere with the EFI init. This allows the
Minnowboard MAX to boot into EFI, load a U-Boot payload then boot to the
U-Boot prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When U-Boot runs as an EFI payload it needs to avoid setting up the CPU
again. Also U-Boot currently does not handle interrupts for many devices, so
run with interrupts disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.
Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The procedure to drop from 64-bit mode to 32-bit is a bit messy. Add a
function to take care of it. It requires identity-mapped pages and that
the calling code is running below 4GB.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a linker script and relocation code for building 64-bit EFI
applications. This can be used for the EFI stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add the required x86 glue code. This includes the initial start-up,
relocation and jumping to efi_main(). We also need to avoid fiddling with
interrupts.
Signed-off-by: Ben Stoltz <stoltz@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix a typo, remove an unused field and make sure to use existing #define
constants instead of open-coded values.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The GDT works but technically the length is incorrect. Fix this and add a
comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find the 32-bit cold reset entry point. Previously this was at a
fixed offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix a typo, improve some comments and add a little more detail in some
cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add PCI IRQ routing information in the board device tree and enable
writing PIRQ routing table and MP table.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Currently cpu-x86 driver is probed only for SMP. We add the same
support for UP when there is only one cpu node in the deive tree.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The PIIX3 chipset does not integrate an I/O APIC, instead it supports
connecting to an external I/O APIC which needs to be enabled manually.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
We need walk through all functions within a PCI device and assign
their IRQs accordingly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add a RTC node in the device tree to enable DM RTC support.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
(Squashed in 'x86: Fix RTC build error on ivybridge')
Turn on cache on the pci option rom area to improve the performance.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Instead of using switch..case for architecture defined exceptions,
simply unify the handling by printing a message of exception name,
followed by registers dump then halt the CPU.
With this unification, it also fixes the wrong exception numbers
for #MF/#AC/#MC/#XM which should be 16/17/18/19 not 15/16/17/18.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Some exceptions cause an error code to be saved on the current stack
after the EIP value. We should extract CS/EIP/EFLAGS from different
position on the stack based on the exception number.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Because the top-level Makefile forces all the source files
to include include/linux/kconfig.h (see the UBOOTINCLUDE define),
these includes are redundant.
By the way, there are exceptions for the statement above; host
programs. In fact, host tools in U-Boot depend on a particular
board configuration, although I think they should not. So, some
files still include <linux/config.h> to work around build errors
on host tools.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Commit afbbd413a fixed this for non-driver-model. Make sure that the driver
model code handles this also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust minnowmax to use driver model for PCI. This requires adding a device
tree node to specify the ranges, removing the board-specific PCI code and
ensuring that the host bridge is configured.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
This driver should use the x86 PCI configuration functions. Also adjust its
compatible string to something generic (i.e. without a vendor name).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>