Your ROOT_URL in app.ini is https://src.whiteboxsystems.nl/ but you are visiting http://src.whiteboxsystems.nl/Whitebox/u-boot/commits/commit/f1249119bfc2e11f6c65f21d62e85f70aca46887/arch/x86
You should set ROOT_URL correctly, otherwise the web may not work correctly.
This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Our own ACPI implementation (when CONFIG_QEMU_ACPI_TABLE is not set)
does not build anymore after x86 has been fully converted to DM PCI.
Instead of trying to fix the build errors, given we now have the ACPI
support via QEMU's fw_cfg interface, which is a more reliable way to
generate correct ACPI tables than by ourselves, hence drop our own
ACPI implementation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the link script to drop this code when not needed. This is only done
for two architectures at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch adds support for the congatec conga-QA3/E3845-4G eMMC8 SoM,
installed on the congatec Qseven 2.0 evaluation carrier board
(conga-QEVAL).
Its port is very similar to the MinnowboardMAX port and also uses
the Intel FSP as described in doc/README.x86.
Currently supported are the following interfaces / devices:
- UART (via Winbond legacy SuperIO chip on carrier board)
- Ethernet (PCIe Intel I210 / E1000)
- SPI including SPI NOR as boot-device
- USB 2.0
- SATA via U-Boot SCSI IF
- eMMC
- Video (HDMI output @ 800x600)
- PCIe
Not supported yet is:
- I2C
- USB 3.0
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This adds basic support for chromebook_samus. This is the 2015 Pixel and
is based on an Intel broadwell platform.
Supported so far are:
- Serial
- SPI flash
- SDRAM init (with MRC cache)
- SATA
- Video (on the internal LCD panel)
- Keyboard
Various less-visible drivers are provided to make the above work (e.g. PCH,
power control and LPC).
The platform requires various binary blobs which are documented in the
README. The major missing feature is USB3 since the existing U-Boot support
does not work correctly with Intel XHCI controllers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is not needed now that the memory controller driver has the SPD data
in its own node.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust the existing implementation to use the new common SDRAM init code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The code to call the memory reference code is common to several Intel CPUs.
Add common code for performing this init. Intel calls this 'Pre-EFI-Init'
(PEI), where EFI stands for Extensible Firmware Interface.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The SATA indexed register write functions are common to several Intel PCHs.
Move this into a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Provide a way to determine the HSIO (high-speed I/O) version supported by
the Intel Management Engine (ME) implementation on the platform.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell uses a binary blob called the memory reference code (MRC) to start
up its SDRAM. This is similar to ivybridge so we can mostly use common code
for running this blob.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell requires quite a bit of power-management setup. Add code to set
this up correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598373/]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell needs a special binary blob to set up the PCH. Add code to run
this on start-up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell LPC (low-pin-count peripheral). This mostly
uses common code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell northbridge. This sets up the location of
several blocks of registers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a SATA driver for broadwell. This supports connecting an SSD and the
usual U-Boot commands to read and write data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
GPIO pins need to be set up on start-up. Add a driver to provide this,
configured from the device tree.
The binding is slightly different from the existing ICH6 binding, since that
is quite verbose. The new binding should be just as extensible.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell low-power platform controller hub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
This adds the broadwell architecture, with the CPU driver and some useful
header files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Intel has invented yet another binary blob which firmware is required to
run. This is run after SDRAM is ready. It is linked to load at a particular
address, typically 0, but is a relocatable ELF so can be moved if required.
Add support for this in the build system. The file should be placed in the
board directory, and called refcode.elf.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver which sets up the pin configuration on x86 devices with an ICH6
(or later) Platform Controller Hub.
The driver is not in the pinctrl uclass due to some oddities of the way x86
devices work:
- The GPIO controller is not present in I/O space until it is set up
- This is done by writing a register in the PCH
- The PCH has a driver which itself uses PCI, another driver
- The pinctrl uclass requires that a pinctrl device be available before any
other device can be probed
It would be possible to work around the limitations by:
- Hard-coding the GPIO address rather than reading it from the PCH
- Using special x86 PCI access to set the GPIO address in the PCH
However it is not clear that this is better, since the pin configuration
driver does not actually provide normal pin configuration services - it
simply sets up all the pins statically when probed. While this remains the
case, it seems better to use a syscon uclass instead. This can be probed
whenever it is needed, without any limitations.
Also add an 'invert' property to support inverting the input.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present pin configuration on link does not use the standard mechanism,
but some rather ugly custom code. As a first step to resolving this, add the
pin configuration to the device tree.
Four of the GPIOs must be available before relocation (for SDRAM pin
strapping).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Each CPU needs to have its microcode loaded. Add support for this so that
all CPUs will have the same version.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable the microcode feature so that the microcode version is shown with the
'cpu detail' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As each core starts up, record its microcode version and CPU ID so these can
be presented with the 'cpu detail' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the MRC options are private to ivybridge. Other Intel CPUs also
use these settings. Move them to a common place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is common with memory-mapped I/O to use the address of a structure member
to access memory, as in:
struct some_regs {
u32 ctrl;
u32 data;
}
struct some_regs *regs = (struct some_regs *)BASE_ADDRESS;
writel(1, ®->ctrl);
writel(2, ®->data);
This does not currently work with inl(), outl(), etc. Add a cast to permit
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The clrsetbits_...() macros are useful for working with memory mapped I/O.
But they do not work with I/O space, as used on x86 machines.
Add some macros to provide similar features for I/O.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function was removed in the previous clean-up. Drop it from the header
file also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the Intel ME code is common to several Intel CPUs. Move it into a
common location. Add a header file for report_platform.c also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598372/]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This same name is used in USB. Add a prefix to distinguish it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the Intel CPU code is common to several Intel CPUs. Move it into a
common location along with required declarations.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the LPC code is common to several Intel LPC devices. Move it into a
common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
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>
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>
Simon Glass
Bin Meng
Stefan Roese