- Mar 17, 2016
-
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
Make a few minor updates to make the meaning clearer. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
Rather than setting up the pin configuration in the GPIO driver, use the new pinctrl driver to do it. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
At present on x86 machines with use cache-as-RAM, the memory goes away just before board_init_r() is called. This means that serial drivers are no-longer unavailable, until initr_dm() it called, etc. Any attempt to use printf() within this period will cause a hang. To fix this, mark the serial devices as 'unavailable' when it is no-longer available. Bring it back when serial_initialize() is called. This means that the debug UART will be used instead for this period. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Add one more step into the init sequence. This fixes the keyboard on samus, which otherwise does not work. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Tested-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
If the device cannot be probed, syscon_get_by_driver_data() will still return a useful value in its devp parameter. Ensure that it returns NULL instead. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Commit 1057e6cf broke use of the timer with driver model. If the timer is used before relocation, then it becomes broken after relocation. This prevents some x86 boards from booting. Fix it. Fixes: 1057e6cf (timer: Set up the real timer after driver model is available) Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
Add two microcode files for broadwell. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
It is useful to automate the process of converting code from coreboot a little. Add a sed script which performs some common transformations. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Bin Meng <bmeng.cn@gmail.com>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-