summaryrefslogtreecommitdiff
path: root/arch/x86/cpu
Commit message (Collapse)AuthorAgeLines
* Kconfig: Move CONFIG_BOOTSTAGE to KconfigSimon Glass2015-04-18-1/+1
| | | | | | | Move CONFIG_BOOT_STAGE and its associated options to Kconfig. Adjust existing users and code. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: chromebook_link: dts: Add PCH and LPC devicesSimon Glass2015-04-18-2/+13
| | | | | | | | | | | | The PCH (Platform Controller Hub) is on the PCI bus, so show it as such. The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the right place also. Rename the compatible strings to be more descriptive since this board is the only user. Once we are using driver model fully on x86, these will be dropped. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: Add a uclass for a Platform Controller HubSimon Glass2015-04-18-9/+0
| | | | | | | | | Add a simple uclass for this chip which is often found in x86 systems where the CPU is a separate device. The device can have children, so make it scan the device tree for these. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: spi: Convert ICH SPI driver to driver modelSimon Glass2015-04-18-10/+14
| | | | | | | | | | | | Convert this driver over to use driver model. Since all x86 platforms use it, move x86 to use driver model for SPI and SPI flash. Adjust all dependent code and remove the old x86 spi_init() function. Note that this does not make full use of the new PCI uclass as yet. We still scan the bus looking for the device. It should move to finding its details in the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Convert chromebook_link to use driver model for pciSimon Glass2015-04-18-65/+57
| | | | | | | | | | | | | | | | Move chromebook_link over to driver model for PCI. This involves: - adding a uclass for platform controller hub - removing most of the existing PCI driver - adjusting how CPU init works to use driver model instead - rename the lpc compatible string (it will be removed later) This does not really take advantage of driver model fully, but it does work. Furture work will improve the code structure to remove many of the explicit calls to init the board. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Convert coreboot to use driver model for pciSimon Glass2015-04-18-47/+16
| | | | | | Move coreboot-x86 over to driver model for PCI. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Add a PCI driver for driver modelSimon Glass2015-04-18-0/+40
| | | | | | | Add a simple x86 PCI driver which uses standard functions provided by the architecture. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Split up arch_cpu_init()Simon Glass2015-04-16-0/+8
| | | | | | | | At present we do more in this function than we should. Split out the post-driver-model part into a separate function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Add a x86_ prefix to the x86-specific PCI functionsSimon Glass2015-04-16-175/+179
| | | | | | | | | | | | These functions currently use a generic name, but they are for x86 only. This may introduce confusion and prevents U-Boot from using these names more widely. In fact it should be possible to remove these at some point and use generic functions, but for now, rename them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Support machines with >4GB of RAMSimon Glass2015-04-16-2/+4
| | | | | | | | | | | | | Some systems have more than 4GB of RAM. U-Boot can only place things below 4GB so any memory above that should not be used. Ignore any such memory so that the memory size will not exceed the maximum. This prevents gd->ram_size exceeding 4GB which causes problems for PCI devices which use DMA. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
* x86: quark: Enable on-chip ethernet controllersBin Meng2015-03-24-0/+19
| | | | | | | | | | Intel Quark SoC integrates two 10/100 ethernet controllers which can be connected to an external RMII PHY. The MAC IP is from Designware. Enable this support with the existing U-Boot Designware MAC driver so that the ethernet port on Intel Galileo board can be used. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* arch/x86/cpu/quark/mrc.c: Switch to U_BOOT_DATE / U_BOOT_TIMETom Rini2015-03-24-1/+2
| | | | | | | | | | | Using __DATE__ and __TIME__ results in an error due to -Werror=date-time with gcc-4.9 (__DATE__ / __TIME__ might prevent reproducible builds) so switch these over to U_BOOT_DATE / U_BOOT_TIME Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: MRC codes clean upBin Meng2015-03-24-1049/+955
| | | | | | | | | | | | This patch cleans up the quark MRC codes coding style by: - Remove BIT0/1../31 defines from mrc_util.h - Create names for the documented BITs and use them - For undocumented single BITs, use (1 << n) directly - For undocumented ORed BITs, use the hex number directly - Remove redundancy parenthesis all over the codes - Replace to use lower case hex numbers Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* remove unnecessary version.h includesRob Herring2015-03-24-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Various files are needlessly rebuilt every time due to the version and build time changing. As version.h is not actually needed, remove the include. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Stefano Babic <sbabic@denx.de> Cc: Minkyu Kang <mk7.kang@samsung.com> Cc: Marek Vasut <marex@denx.de> Cc: Tom Warren <twarren@nvidia.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Macpaul Lin <macpaul@andestech.com> Cc: Wolfgang Denk <wd@denx.de> Cc: York Sun <yorksun@freescale.com> Cc: Stefan Roese <sr@denx.de> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Cc: Simon Glass <sjg@chromium.org> Cc: Philippe Reynes <tremyfr@yahoo.fr> Cc: Eric Jarrige <eric.jarrige@armadeus.org> Cc: "David Müller" <d.mueller@elsoft.ch> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Robert Baldyga <r.baldyga@samsung.com> Cc: Torsten Koschorrek <koschorrek@synertronixx.de> Cc: Anatolij Gustschin <agust@denx.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Łukasz Majewski <l.majewski@samsung.com>
* x86: Add SD/MMC support to quark/galileoBin Meng2015-02-06-0/+11
| | | | | | | | Intel Galileo board has a microSD slot which is routed from Quark SoC SDIO controller. Enable SD/MMC support so that we can use an SD card. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add SPI support to quark/galileoBin Meng2015-02-06-0/+17
| | | | | | | | | | The Quark SoC contains a legacy SPI controller in the legacy bridge which is ICH7 compatible. Like Tunnel Creek and BayTrail, the BIOS control register offset in the ICH SPI driver is wrong for the Quark SoC too, unprotect_spi_flash() is added to enable the flash write. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Initialize non-standard BARsBin Meng2015-02-06-0/+46
| | | | | | | | | Quark SoC has some non-standard BARs (excluding PCI standard BARs) which need be initialized with suggested values. This includes GPIO, WDT, RCBA, PCIe ECAM and some ACPI register block base addresses. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Call MRC in dram_init()Bin Meng2015-02-06-2/+97
| | | | | | | | Now that we have added Quark MRC codes, call MRC in dram_init() so that DRAM can be initialized on a Quark based board. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Enable the Memory Reference Code buildBin Meng2015-02-06-0/+1
| | | | | | | Turn on the Memory Reference code build in the quark Makefile. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add System Memory Controller supportBin Meng2015-02-06-0/+3210
| | | | | | | The codes are actually doing the memory initialization stuff. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add utility codes needed for MRCBin Meng2015-02-06-0/+2068
| | | | | | | Add various utility codes needed for Quark MRC. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add Memory Reference Code (MRC) main routinesBin Meng2015-02-06-0/+204
| | | | | | | Add the main routines for Quark Memory Reference Code (MRC). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Bypass TSC calibrationBin Meng2015-02-06-0/+5
| | | | | | | | | For some unknown reason, the TSC calibration via PIT does not work on Quark. Enable bypassing TSC calibration and override TSC_FREQ_IN_MHZ to 400 per Quark datasheet in the Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Enable the Intel quark/galileo buildBin Meng2015-02-06-0/+1
| | | | | | | | | Make the Intel quark/galileo support avaiable in Kconfig and Makefile. With this patch, we can generate u-boot.rom for Intel galileo board. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add basic Intel Quark processor supportBin Meng2015-02-06-0/+282
| | | | | | | | Add minimum codes to support Intel Quark SoC. DRAM initialization is not ready yet so a hardcoded gd->ram_size is assigned. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add Cache-As-RAM initializationBin Meng2015-02-06-0/+105
| | | | | | | | | Quark SoC contains an embedded 512KiB SRAM (eSRAM) that is initialized by hardware. eSRAM is the ideal place to be used for Cache-As-RAM (CAR) before system memory is available. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add routines to access message bus registersBin Meng2015-02-06-0/+77
| | | | | | | | | | | In the Quark SoC, some chipset commands are accomplished by utilizing the internal message network within the host bridge (D0:F0). Accesses to this network are accomplished by populating the message control register (MCR), Message Control Register eXtension (MCRX) and the message data register (MDR). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add support for Intel Minnowboard MaxSimon Glass2015-02-06-0/+337
| | | | | | | | | | | | | | This is a relatively low-cost x86 board in a small form factor. The main peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800 series CPU. So far only the dual core 2GB variant is supported. This uses the existing FSP support. Binary blobs are required to make this board work. The microcode update is included as a patch (all 3000 lines of it). Change-Id: I0088c47fe87cf08ae635b343d32c332269062156 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Allow FSP Kconfig settings for all x86Simon Glass2015-02-06-38/+0
| | | | | | | | While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: mmc: Move common FSP functions into a common fileSimon Glass2015-02-06-72/+3
| | | | | | | | | | | | Since these board functions seem to be the same for all boards which use FSP, move them into a common file. We can adjust this later if future FSPs need more flexibility. This creates a generic PCI MMC device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Make CAR and DRAM FSP code commonSimon Glass2015-02-05-206/+1
| | | | | | | | | For now this code seems to be the same for all FSP platforms. Make it common until we see what differences are required. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Move common FSP code into a common locationSimon Glass2015-02-05-413/+5
| | | | | | Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: video: Allow video ROM execution to fall back to the other methodSimon Glass2015-02-05-1/+2
| | | | | | | | If the BIOS emulator is not available, allow use of native execution if available, and vice versa. This can be controlled by the caller. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Rename MMCONF_BASE_ADDRESS and make it common across x86Simon Glass2015-02-05-1/+1
| | | | | | | | | This setting will be used by more than just ivybridge so make it common. Also rename it to PCIE_ECAM_BASE which is a more descriptive name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Drop the Kconfig MRC cache informationSimon Glass2015-01-24-28/+0
| | | | | | This is now stored in the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: config: Enable hook for saving MRC configurationSimon Glass2015-01-24-0/+5
| | | | | | | Add a hook to ensure that this information is saved. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Implement a cache for Memory Reference Code parametersSimon Glass2015-01-24-0/+410
| | | | | | | | | | | The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Use ipchecksum from net/Simon Glass2015-01-24-60/+4
| | | | | | | The existing IP checksum function is only accessible to the 'coreboot' cpu. Drop it in favour of the new code in the network subsystem. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Fix various code format issues in start16.SBin Meng2015-01-23-10/+10
| | | | | | | | | | | Various minor code format issues are fixed in start16.S: - U-boot -> U-Boot - 32bit -> 32-bit - Use TAB instead of SPACE to indent - Move the indention location of the GDT comment block Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Test mtrr support flag before accessing mtrr msrBin Meng2015-01-23-0/+12
| | | | | | | | | | On some x86 processors (like Intel Quark) the MTRR registers are not supported. This is reflected by the CPUID (EAX 01H) result EDX[12]. Accessing the MTRR registers on such processors will cause #GP so we must test the support flag before accessing MTRR MSRs. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Save mtrr support flag in global dataBin Meng2015-01-23-0/+7
| | | | | | | | CPUID (EAX 01H) returns MTRR support flag in EDX bit 12. Probe this flag in x86_cpu_init_f() and save it in global data. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add missing DECLARE_GLOBAL_DATA_PTR for mtrr.cBin Meng2015-01-23-0/+2
| | | | | | | | arch/x86/cpu/mtrr.c has access to the U-Boot global data thus DECLARE_GLOBAL_DATA_PTR is needed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Configure pci memory regionsBin Meng2015-01-13-2/+28
| | | | | | | | Configure coreboot pci memory regions so that pci device drivers could work correctly. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Move coreboot-specific defines from coreboot.h to KconfigBin Meng2015-01-13-0/+15
| | | | | | | | | | | | There are many places in the U-Boot source tree which refer to CONFIG_SYS_COREBOOT, CONFIG_CBMEM_CONSOLE and CONFIG_VIDEO_COREBOOT that is currently defined in coreboot.h. Move them to arch/x86/cpu/coreboot/Kconfig so that we can switch to board configuration file to build U-Boot later. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Set up timer base correctlyBin Meng2015-01-13-13/+20
| | | | | | | | | | | | | | If coreboot is built with CONFIG_COLLECT_TIMESTAMPS, use the value of base_time in coreboot's timestamp table as our timer base, otherwise TSC counter value will be used. Sometimes even coreboot is built with CONFIG_COLLECT_TIMESTAMPS, the value of base_time in the timestamp table is still zero, so we must exclude this case too (this is currently seen on booting coreboot in qemu). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: fsp: Drop get_hob_type() and get_hob_length()Bin Meng2015-01-13-7/+7
| | | | | | | | | | | These two are not worth having separate inline functions as they are really simple, so drop them. Also changed 'type' parameter of fsp_get_next_hob() from u16 to uint. Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Update microcode early in bootSimon Glass2015-01-13-10/+34
| | | | | | | | | | | At present the normal update (which happens much later) does not work. This seems to have something to do with the 'no eviction' mode in the CAR, or at least moving the microcode update after that causes it not to work. For now, do an update early on so that it definitely works. Also refuse to continue unless the microcode update check (later in boot) is successful. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Disable CAR before relocation on platforms that need itSimon Glass2015-01-13-0/+8
| | | | | | | For platforms with CAR we should disable it before relocation. Check if this function is available and call it if so. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Add a way to turn off the CARSimon Glass2015-01-13-0/+46
| | | | | | | Cache-as-RAM should be turned off when we relocate since we want to run from RAM. Add a function to perform this task. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Request MTRRs for DRAM regionsSimon Glass2015-01-13-0/+10
| | | | | | | | | We should use MTRRs to speed up execution. Add a list of MTRR requests which will dealt with when we relocate and run from RAM. We set RAM as cacheable (with write-back) and registers as non-cacheable. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-12-30 23:35:25 +0000