summaryrefslogtreecommitdiff
path: root/arch/x86/cpu
Commit message (Collapse)AuthorAgeLines
* x86: tsc: Remove legacy timer codesBin Meng2015-12-01-6/+0
| | | | | | | | | | | 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>
* x86: Convert to use driver model timerBin Meng2015-12-01-39/+0
| | | | | | | Convert all x86 boards to use driver model tsc timer. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Remove MIN_PORT80_KCLOCKS_DELAYBin Meng2015-12-01-18/+0
| | | | | | | | | | 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>
* x86: Remove legacy pci codesBin Meng2015-11-13-45/+0
| | | | | | | | 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>
* x86: qemu: Convert to use driver model pciBin Meng2015-11-13-50/+0
| | | | | | | Move to driver model for pci on QEMU. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: qemu: Move chipset-specific codes from pci.c to qemu.cBin Meng2015-11-13-72/+82
| | | | | | | | 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>
* x86: qemu: Remove call to vgabios executionBin Meng2015-11-13-18/+1
| | | | | | | | 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>
* x86: queensbay: Really disable IGDBin Meng2015-11-13-6/+20
| | | | | | | | | | | | | | | | | | | | | | 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>
* x86: Rename pcat_ to i8254 and i8259 accordinglyBin Meng2015-11-13-1/+1
| | | | | | | | 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>
* x86: ivybridge: Enable the MRC cacheBin Meng2015-10-21-8/+2
| | | | | | | | | 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>
* x86: ivybridge: Measure the MRC code execution timeSimon Glass2015-10-21-0/+3
| | | | | | | | 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>
* x86: ivybridge: Fix car_uninit() to correctly set run stateSimon Glass2015-10-21-1/+1
| | | | | | | | 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>
* x86: ivybridge: Check the RTC return valueSimon Glass2015-10-21-3/+10
| | | | | | | The RTC can fail, so check the return value for reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Use 'ret' instead of 'rcode'Simon Glass2015-10-21-8/+8
| | | | | | | For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: chromebook_link: Enable the debug UARTSimon Glass2015-10-21-0/+7
| | | | | | | 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>
* x86: Init the debug UART if enabledSimon Glass2015-10-21-8/+3
| | | | | | | | | 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>
* x86: Pass correct cpu_index to ap_init()Bin Meng2015-10-21-2/+2
| | | | | | | | 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>
* x86: quark: Implement mrc cacheBin Meng2015-10-21-7/+64
| | | | | | | | 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>
* x86: ivybridge: Correct two typos for MRCBin Meng2015-10-21-2/+2
| | | | | | | It should be MRC, not MCR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Issue full system reset in reset_cpu()Bin Meng2015-10-21-0/+6
| | | | | | | | | | | | | | | | | | | 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>
* x86: baytrail: Save mrc cache to spi flashBin Meng2015-10-21-0/+19
| | | | | | | Save MRC cache to SPI flash in arch_misc_init(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Use struct mrc_region to describe a mrc regionBin Meng2015-10-21-1/+1
| | | | | | | | | | | | | | | | 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>
* x86: ivybridge: Use APIs provided in the mrccache libBin Meng2015-10-21-108/+4
| | | | | | | | 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>
* x86: Move mrccache.[c|h] to a common placeBin Meng2015-10-21-159/+1
| | | | | | | | 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>
* x86: Initialize GDT entry 1 to be the 32-bit CS as wellBin Meng2015-10-21-1/+6
| | | | | | | | 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>
* x86: Allow disabling IGD on Intel QueensbayBin Meng2015-10-21-0/+27
| | | | | | | | | | 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>
* x86: ivybridge: Remove the dead codes that programs pci bridgeBin Meng2015-10-21-32/+0
| | | | | | | 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>
* x86: quark: Configure MTRR to enable cacheBin Meng2015-09-16-0/+67
| | | | | | | | | | | | | | | | | 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>
* x86: quark: Initialize thermal sensor properlyBin Meng2015-09-16-0/+40
| | | | | | | | | | | | | | 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>
* x86: quark: Lock HMBOUND register before jumping to kernelBin Meng2015-09-16-0/+3
| | | | | | | | | | | | | | 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>
* x86: quark: Convert to use clrbits, setbits, clrsetbits macrosBin Meng2015-09-16-51/+21
| | | | | | | 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>
* x86: quark: Add PCIe/USB static register programming after memory initBin Meng2015-09-16-0/+64
| | | | | | | | | 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>
* x86: Convert to use driver model eth on quark/galileoBin Meng2015-09-16-19/+0
| | | | | | | | 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>
* x86: quark: Add USB PHY initialization supportBin Meng2015-09-09-0/+41
| | | | | | | | 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>
* x86: Convert to use driver model pci on quark/galileoBin Meng2015-09-09-76/+0
| | | | | | | Move to driver model pci for Intel quark/galileo. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Enable PCIe controller on quark/galileoBin Meng2015-09-09-0/+63
| | | | | | | | | | | | | 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>
* x86: quark: Avoid chicken and egg problemBin Meng2015-09-09-15/+15
| | | | | | | | | | | | | | | | | | | | 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>
* x86: quark: Optimize MRC execution timeBin Meng2015-09-09-22/+22
| | | | | | | | | | | | | | | | | 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>
* x86: coreboot: Convert to use more dm driversBin Meng2015-09-09-6/+0
| | | | | | | Move to driver model for RTC, USB and ETH on coreboot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add DSDT table for supporting ACPI on QEMUSaket Sinha2015-08-26-1/+712
| | | | | | | | 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>
* x86: Add ACPI table support to QEMUSaket Sinha2015-08-26-0/+177
| | | | | | | | | 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>
* x86: baytrail: Remove the fsp_init_phase_pci() callBin Meng2015-08-26-7/+1
| | | | | | | | | 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>
* x86: queensbay: Move unprotect_spi_flash() to arch_misc_init()Bin Meng2015-08-26-2/+2
| | | | | | | | | | 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>
* x86: fsp: Add comments about U-Boot entering start.S twiceBin Meng2015-08-26-2/+4
| | | | | | | | | 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>
* x86: fsp: Enlarge the size of malloc() pool before relocationBin Meng2015-08-26-0/+8
| | | | | | | | | | 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>
* x86: coreboot: Allow >=4GiB memory bank sizeBin Meng2015-08-26-5/+4
| | | | | | | 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>
* x86: Remove calculate_relocation_address()Bin Meng2015-08-26-8/+1
| | | | | | | 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>
* x86: coreboot: Correctly report E820 typesBin Meng2015-08-26-2/+13
| | | | | | | 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>
* x86: Return -1 when reading a PCI config register failsSimon Glass2015-08-14-3/+6
| | | | | | | | 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>
* x86: Set APs' req_seq to the reg number from device treeBin Meng2015-08-14-0/+7
| | | | | | | | | 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>
generated by cgit v1.1 at 2024-11-10 03:53:50 +0000