There is a dummy pch driver in the coreboot directory. This causes
drivers of its children fail to function due to empty ops. Remove
the whole file since it is no longer needed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present pinctrl driver gets probed in ich6_gpio driver's probe
routine, which has two issues:
- Pin's PADs only gets configured when GPIO driver is probed, which
is not done by default. This leaves the board in a partially
functional state as we must initialize PADs correctly to get
perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as
normally there are multiple GPIO controllers. It should really
be called just once.
Move the call to syscon_get_by_driver_data() from ich6_gpio driver
to cpu_init_r().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
As of today, the latest version FSP (gold4) for BayTrail misses the
PAD configuration of the SD controller's Card Detect signal. The
default PAD value for the CD pin sets the pin to work in GPIO mode,
which causes card detect status cannot be reflected by the Present
State register in the SD controller (bit 16 & bit 18 are always zero).
Add a configuration for this pin in the pinctrl node.
Note I've checked the PAD configuration for all the pins in all the
3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get
initialized to correct mode by FSP. With fsp,emmc-boot-mode set to
2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set
fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3
which is correct according to datasheet.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present all BayTrail boards configure fsp,emmc-boot-mode to 2,
which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1
only shows up on some early stepping silicon of BayTrail SoC.
Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP
provides a config option fsp,emmc-boot-mode which tells FSP which
eMMC controller it initializes. Instead of hardcoded to 2, now
we change it to 1 which means "auto".
With this change, MinnowMax board (with a D0 stepping BayTrail SoC)
can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot
'pci' command.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Without a 'reg' property, pinctrl driver probe routine fails in
its pre_probe() with a return value of -EINVAL.
Add 'reg' property for all BayTrail boards. Note for BayleyBay,
the pinctrl node is newly added.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
An accumulated length was incorrectly added to current each pass
through the loop. On system with more than 2 cores this caused a
corrupt MADT to be generated.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
So far this is hardcoded to 2, but it should really be read
from the I/O APIC register.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds basic quark platform ASL files. They are intended to be
included in dsdt.asl of any board that is based on this platform.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There is a device.h for quark on-chip devices, mainly for definitions
of internal PCI device numbers, but it's not ready to be included by
ASL files. Update to use hex numbers for PCI dev and __ASSEMBLY__.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The irqroute.asl file is already common enough to all x86 platforms.
Platform ASL files need only provide a irqroute.h to describe how
internal PCI devices and PCIe downstream port devices' INTx pins are
routed to which PIRQ pin.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the irqlinks.asl file currently in the BayTrail directory to
a common place to be shared among all x86 platforms. As the PIRQ
routing control programming interface is common to Intel chipsets,
leave the common part in the common file, and move the platform
specific part to the platform files.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Make use of the newly added Kconfig options of board manufacturer
and product name to write SMBIOS tables.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This introduces two Kconfig options to be used by SMBIOS tables:
board manufacturer and product name.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently ID 2 is assgined to broadwell I/O APIC, however per
chromebook_samus.dts 2 is the core#2 LAPIC ID. Now we change
I/O APIC ID to 4 to avoid conflict.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After power-on, both LAPIC and I/O APIC appear with the same APIC ID
zero, which creates an ID conflict. When generating MP table, U-Boot
reports zero as the LAPIC ID in the processor entry, and zero as the
I/O APIC ID in the I/O APIC as well as the I/O interrupt assignment
entries. Such MP table confuses Linux kernel and finally a kernel
panic is seen during boot:
BUG: unable to handle kernel paging request at ffff9000
IP: [<c101d462>] native_io_apic_write+0x22/0x30
*pdpt = 00000000014fb001 *pde = 00000000014ff067 *pte = 0000000000000000
Oops: 0002 [#1]
Modules linked in:
Pid: 1, comm: swapper Tainted: G W 3.8.7 #3 intel galileo/galileo
EIP: 0060:[<c101d462>] EFLAGS: 00010086 CPU: 0
EIP is at native_io_apic_write+0x22/0x30
...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present LAPIC is enabled and configured as virtual wire mode
in lapic_setup() only when CONFIG_SMP is on. This limitation is
however not necessary as for uniprocessor this is still needed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Intel Quark processor core provides an integrated Local APIC but
does not support the IA32_APIC_BASE MSR. As a result, the Local
APIC is always globally enabled and the Local APIC base address
is fixed at 0xfee00000. Attempting to access the IA32_APIC_BASE
MSR causes a general protection fault.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update board device tree to include latest microcode, and remove
the old no longer needed microcode.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
MRC cache relies on Intel FSP to produce a special GUID that
contains the MRC cache data. Add such information in the
CONFIG_ENABLE_MRC_CACHE help entry.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since BayTrail, Intel starts to use new GPIO IPs in their chipset.
This adds the GPIO ASL, so that OS can load corresponding drivers
for it. On Linux, this is BayTrail pinctrl driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
BayTrail integrates an internal ns15550 compatible UART (PNP0501).
Its IRQ is hardwired to IRQ3 in old revision chipset, but in newer
revision one IRQ4 is being used for ISA compatibility. Handle this
correctly in the ASL file.
Linux does not need this ASL, but Windows need this to correctly
discover a COM port existing in the system so that Windows can
show it in the 'Device Manager' window, and expose this COM port
to any terminal emulation application.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Before moving 'current' pointer during ACPI table writing, we always
check the table length to see if it is larger than the table header.
Since our purpose is to generate valid tables, the check logic is
always true, which can be avoided.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The generated AmlCode[] from IASL already has the calculated DSDT
table checksum in place. No need for us to calculate it again.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Per ACPI spec, during ACPI OS initialization, OSPM can determine
that the ACPI hardware registers are owned by SMI (by way of the
SCI_EN bit in the PM1_CNT register), in which case the ACPI OS
issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit
effectively tracks the ownership of the ACPI hardware registers.
However since U-Boot does not support SMI, we report all 3 fields
in FADT (SMI_CMD, ACPI_ENABLE, ACPI_DISABLE) as zero, by following
the spec who says: these fields are reserved and must be zero on
system that does not support System Management mode.
U-Boot seems to behave in a correct way that the ACPI spec allows,
at least Linux does not complain, but apparently Windows does not
think so. During Windows bring up debugging, it is observed that
even these 3 fields are zero, Windows are still trying to issue SMI
with hardcoded SMI port address and commands, and expecting SCI_EN
to be changed by the firmware. Eventually Windows gives us a BSOD
(Blue Screen of Death) saying ACPI_BIOS_ERROR and refuses to start.
To fix this, turn on the SCI_EN bit by ourselves. With this patch,
now U-Boot can install and boot Windows 8.1/10 successfully with
the help of SeaBIOS using legacy interface (non-UEFI mode).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we already reserved high memory for configuration tables,
call high_table_malloc() to allocate tables from the region.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When SeaBIOS is on, reserve configuration tables in reserve_arch().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of asking each platform to provide reserve_arch(),
supply it in arch/x86/cpu/cpu.c in a unified way.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration
tables via normal malloc(). To simplify, use a dedicated memory
region which is reserved on the stack before relocation for this
purpose. Add functions for reserve and malloc.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
PIRQ routing table checksum is fixed up in copy_pirq_routing_table(),
which is fine if we only write the configuration table once. But with
the SeaBIOS case, when we write the table for the second time, the
checksum will be fixed up to zero per the checksum algorithm, which
is caused by the checksum field not being zero before fix up, since
the checksum has already been calculated in the first run.
To fix this, move the checksum fixup to create_pirq_routing_table(),
so that copy_pirq_routing_table() only does what its function name
suggests: copy the table to somewhere else.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present board_final_cleanup() is called before booting a Linux
kernel. This actually needs to be done before booting anything,
like SeaBIOS, VxWorks or Windows.
Move the call to last_stage_init() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rename qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved
to qfw core, this file only contains code for installing e820 table.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Loading ACPI table from QEMU's fw_cfg interface is not x86 specific
(ARM64 may also make use of it). So move the code to common place.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make file names consistent with CONFIG_QFW and CONFIG_CMD_QFW
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch adds some comments about qfw register endianness for clarity.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The original implementation of qfw includes several x86 specific
operations, like directly calling outb/inb and using some inline
assembly code which prevents it being ported to other architectures.
This patch adds callback functions and moves those to arch/x86/
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch splits qfw command interface and qfw core function into two
files, and introduces a new Kconfig option (CONFIG_QFW) for qfw core.
Now when qfw command interface is enabled, it will automatically select
qfw core. This patch also makes the ACPI table generation select
CONFIG_QFW.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch is part of the qfw refactor work.
The qemu_fwcfg_free_files() function is only used in error handling in
ACPI table generation, let's not make this a core function and move it
to the right place.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_GENENRATE_ACPI_TABLE controls the generation of ACPI table which
uses U-Boot's built-in methods and CONFIG_QEMU_ACPI_TABLE controls whether
to load ACPI table from QEMU's fw_cfg interface.
But with commit "697ec431469ce0a4c2fc2c02d8685d907491af84 x86: qemu: Drop
our own ACPI implementation", there is only one way to support ACPI table
for QEMU targets which is the fw_cfg interface. Having two Kconfig options
for this purpose is not necessary any more, so this patch consolidates
the two.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
- Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into
cmd/qemu_fw_cfg.c
- Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h
- Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
FADT/MADT tables are platform specific. Generate them for BayTrail.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds basic BayTrail platform ASL files. They are intended to be
included in dsdt.asl of any board that is based on this platform.
Note: ACPI mode support for GPIO/LPSS/SCC/LPE are not supported for
now. They will be added in the future.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Like other MADT table write routines, make acpi_create_madt_lapics()
return how many bytes it has written instead of the table end addr.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds several generic ASL libraries that can be included by
other ASL files, which are:
- debug.asl: for debug output using POST I/O port and legacy serial port
- globutil.asl: for string compare routines
- statdef.asl: for _STA status values
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The comment of initializing table header revision says:
/* ACPI 1.0/2.0: 1, ACPI 3.0: 2, ACPI 4.0: 3 */
which might mislead it may increase per ACPI spec revision.
However this is not the case. It's actually a fixed number
as defined in ACPI spec, and in the laest ACPI spec 6.1,
some table header revisions are still 1. Clean these up.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Per ACPI spec, the FACS table address must be aligned to a 64 byte
boundary (Windows checks this, but Linux does not).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
