summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2013-03-15Google Link: Add remaining code to support native graphicsRonald G. Minnich
The Link native graphics commit 49428d84 [1] Add support for Google's Chromebook Pixel was missing some of the higher level bits, and hence could not be used. This is not new code -- it has been working since last August -- so the effort now is to get it into the tree and structure it in a way compatible with upstream coreboot. 1. Add options to src/device/Kconfig to enable native graphics. 2. Export the MTRR function for setting variable MTRRs. 3. Clean up some of the comments and white space. While I realize that the product name is Pixel, the mainboard in the coreboot tree is called Link, and that name is what we will use in our commits. [1] http://review.coreboot.org/2482 Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2531 Tested-by: build bot (Jenkins)
2013-03-15AMD Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2735 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Super I/O W83627DHG: Enable UART B by redirecting pinsWolfgang Kamp
Pins 78-85 are set to GPIO after power on or reset. To enable UART B the pins must be redirected to it. Look at W83627DHG databook version 1.4 page 185 Chip (global) Control Register CR2C. Change-Id: I12b094a60d9c5cb2447a553be4679a4605e19845 Signed-off-by: Wolfgang Kamp <wmkamp@datakamp.de> Reviewed-on: http://review.coreboot.org/2626 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-15Persimmon DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts Change-Id: If8d86f959822d528c44ab011a851659d486289b5 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2726 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Persimmon DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2684 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Drop CHIP_NAME from intel/baskingridgeStefan Reinauer
It's no longer required. Change-Id: I621226a3bdfba9bc8edfd6e511a5337ae603ae19 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2723 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-15haswell: Fix BDSM and BGSM indicies in memory mapAaron Durbin
This wasn't previously spotted because the printk's were correct. However if one needed to get the value of the BDSM or BGSM register the value would reflect the other register's value. Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2689 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: reserve default SMRAM spaceAaron Durbin
Currently the OS is free to use the memory located at the default SMRAM space because it is not marked reserved in the e820. This can lead to memory corruption on S3 resume because SMM setup doesn't save this range before using it to relocate SMRAM. Resulting tables: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-00000000acebffff: RAM 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 9. 00000000ad000000-00000000af9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 13 items: 0: 0000000000000000 - 0000000000030000 = 1 RAM 1: 0000000000030000 - 0000000000040000 = 2 RESERVED 2: 0000000000040000 - 000000000009f400 = 1 RAM 3: 000000000009f400 - 00000000000a0000 = 2 RESERVED 4: 00000000000f0000 - 0000000000100000 = 2 RESERVED 5: 0000000000100000 - 0000000000f00000 = 1 RAM 6: 0000000000f00000 - 0000000001000000 = 2 RESERVED 7: 0000000001000000 - 00000000acec0000 = 1 RAM 8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 12: 0000000100000000 - 000000018f600000 = 1 RAM Booted and checked e820 as well as coreboot table information. Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2688 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: resource allocationAaron Durbin
The previous code w.r.t. resource allocation was getting lucky based on the way fixed mmio resources on the system were being chosen. Namely, PCIEXBAR was the lowest mmio space and the other fixed non-standar BARs were above it. The resource allocator would then start allocating standard BARs below that. On top of that other resources were being added when dev_ops->set_resources() was being called on the PCI domain. At that point the PCI range limit were already picked for where to start allocating from. To ensure we no longer get lucky during resource allocation add the fixed resources in the host bridge and add the memory controller cacheable memory areas. With those resources added the range limit for standard PCI BARs is chosen properly. Depending on haswell board configurations we may need to adjust and pass in the size of physical address space needed for PCI resources to the reference code. For the time being the CRBs appear to be OK. Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB. Output from 6GiB memory configuration: MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000018f600000 = 1 RAM Output from 4GiB memory configuration: MC MAP: TOM: 0x100000000 MC MAP: TOUUD: 0x14f600000 MC MAP: MESEG_BASE: 0xff000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x14f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000014f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000014f600000 = 1 RAM Output from 2GiB memory configuration: MC MAP: TOM: 0x40000000 MC MAP: TOUUD: 0x100600000 MC MAP: MESEG_BASE: 0x3f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x1005fffff MC MAP: TOLUD: 0x3ea00000 MC MAP: BDSM: 0x3ca00000 MC MAP: BGSM: 0x3c800000 MC MAP: TESGMB: 0x3c000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-000000003bebffff: RAM 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES 7. 000000003c000000-000000003e9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 000000003bec0000 = 1 RAM 6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 0000000100600000 = 1 RAM Verified through debug messages that range limits as well as resources were being properly honored. Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2687 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-14lynxpoint: lpc resource reservationsAaron Durbin
This commit updates the Lynx Point resource reservations before the coreboot allocator assigns resources. There is no need to mark anything as subtractive decode because there are no devices/buses linked to the LPC device. The I/O range reservations consists of claiming the first 4KiB of I/O space. The PMBASE, GPIOBASE, and LPC generic I/O decode ranges are checked against the default claimed range. If those ranges overlap or fall outside of the default range then those resources are added. The MMIO range reservations consist of claiming everything from the I/O APIC to 4GiB. The RCBA and the LPC Generic Memory range register are then conditionally added if they fall outside of the default MMIO range. Change-Id: I0f560a03814a2b15961fdbe61e4164cd54cff7a5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2682 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: more ULT/LP support and minor tweaksDuncan Laurie
- Add ME device ID for Lynxpoint LP - Add GPU device IDs for ULT - SATA init tweaks from checking against DXE reference code - Remove the ICH7 from the SPI driver so it works on all lynxpoint without having to add more LPC device ID checks - Add function disable for audio dsp and xhci, remove PCI bridge - Add interrupt route registers for new devices (needs romstage setup) Change-Id: Idb48f50d0bacb6bf90531c3834542b9abb54fb8a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2680 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14baskingridge: Report static temperature in _TMPDuncan Laurie
The current code is attempting to convert from an invalid starting temperature. Since we aren't sure where the temperature will come from yet just return a static value. This stops the kernel from going to S5 on boot because it thinks the temperature is too high. Change-Id: I433fa407e545458344af5842b353df5bc71bfdad Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2679 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: remove CONFIG_GFXUMAAaron Durbin
This option is not required for haswell. Enabling the option doesn't do anything aside from complicate mtrr calculation. Therefore, remove it. Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2678 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14x86: improve lb_cleanup_memory_rangesAaron Durbin
There are 2 issues in lb_cleanup_memory_ranges(). The first is that during sort there is a neighbor comparison that initially starts with the current entry. The second issue is that merging has an off by one comparison for adjacent entries. Before: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM After: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed19fff: RESERVED 10. 00000000fed84000-00000000fed84fff: RESERVED 11. 0000000100000000-000000018f5fffff: RAM Change-Id: I656aab61b0ed4711c9dceaedb81c290d040ffdec Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2671 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14baskingridge: dev, recovery, and WP switch supportAaron Durbin
This commit adds support for the deveveloper, recovery, and write protect querying. It just uses jumpers on the Basking Ridge board. Noted ability to togggle jumpers results in toggling the respective modes. Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2676 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14baskingridge: update gpio map documentationAaron Durbin
While looking at the Basking Ridge schematic I noticed some changes and wanted to make sure they were reflected in the GPIO map. Change-Id: I686653c164314ae9f68c42331d2f950751411d4a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2675 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add VGA PCI ID mappingsAaron Durbin
Needed to map VGA OPROM IDs to actual device IDs Change-Id: I6743905c3db52519bf18f4bcc1a972aec43d3e9d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2674 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14baskingridge: zero out alt_gp_smi_en in devicetreeAaron Durbin
The baskingridge has a non-zero alt_gp_smi_en value in the devicetree.cb file. It has just to be determined which GPI pins should trigger an SMI on basking ridge. Without this change the board would hang during boot (presumably through a SMI flood). No more hangs once the value is zero. Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2673 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14baskingridge: rename graysreef to baskingridgeStefan Reinauer
The Grays Reef CRB is deprecated by order of Intel. Basking Ridge is the new hotness. Therefore, rename graysreef to basking ridge. Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I203497e165d8efc99d3438c4c548140a6e9cc649 Reviewed-on: http://review.coreboot.org/2672 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14lynxpoint: Update device IDs and clock gating setupDuncan Laurie
- Add device IDs for lynxpoint mobile and LP variants. - Update the clock gating setup based on BWG - Update the SATA programming based on BWG - Add a DEVSLP0 mux config register Change-Id: Icf4d7bab7f3df7adef5eb7c5e310a6995227a0e5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2649 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14lynxpoint: Add new GPIO interface for Lynxpoint-LPDuncan Laurie
The low power variant of the chipset introduces a completely new interface to the GPIOs. This is a 1KB region and so needs to be moved as well so it does not conflict with other IO regions. Also expose the gpio_get functions to ramstage and move the prototypes to pch.h so they can be used for both GPIO interfaces. Change-Id: I20bc18669525af16de8cdf99f0ccfa9612be63ad Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2648 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add ULT CPUID and updated microcodeDuncan Laurie
This adds microcode ffff000a and the CPUIDs for ULT. Change-Id: I341c1148a355d8373b31032b9f209232bd03230a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2647 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add ULT device IDsDuncan Laurie
Device IDs for northbridge and GPU. Also mask off the lock bit in the memory map registers. Change-Id: I9a4955d4541b938285712e82dd0b1696fa272b63 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2646 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14lynxpoint: Add Kconfig entry for Low Power chipsetDuncan Laurie
There are enough subtle differences that it is useful to have a Kconfig entry to differentiate the ULT/LP chipet from the desktop/mobile versions. Change-Id: I04ca1bc6f90bcf9e6994ea7125c98347e8def898 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2645 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14lynxpoint: ME to BIOS Payload UpdatesAaron Durbin
This commit contains a bevy of updates: - PCI device id is updated to match Lynx Point EDS in the ME driver. - Allocate the memory to store the consumption of the MBP. - me_bios_payload structure is now a structure of pointers that point into the allocated memory. - The ICC profile structure was updated to correctly reflect the documentation. Verfied that output of MBP reading can handle unknown items. Change-Id: I43cc45e6b797444c105e7c842eb5684e9c104687 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2641 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14lynx point: add new ME status informationAaron Durbin
According to the 0.8.0 ME BWG this is a new state. It's not very clear what exactly it entails, but the Basking Ridge CRB was tripping it when MRC_DEBUG was enabled (presumably because of a DID timeout). Instead of 0x17 one can now see the proper message for this state. Change-Id: I5bda1de7d3d957d38a4760a02dcd170ec48782e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2640 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14graysreef: update platform informationAaron Durbin
Some of the Lynx Point ids were off. Correct those and make the pei data BAR fields consistent with the others. Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2622 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14OT200: reset MFGTP7 (backlight pwm)Christian Gmeiner
The CS5536 companion device has three different power domains. * working domain * standby domain * RTC domain When the system is "off" only the standby domain is powered. MFGPT[7:6] are member of the standby power domain. MFGPT7 is used to control the backlight of the device and so the timer gets used and configured during system boot. If the system does a reboot the timer stays configured and the Linux driver can not use it: "ot200-backlight: ot200-backlight.0: MFGPT 7 not availale" The cs5535-mfgpt has a function to hard-reset all MFGPTs but the system hangs after the first access to a MFGPT register - cause unknown. /* * This is a sledgehammer that resets all MFGPT timers. This is required by * some broken BIOSes which leave the system in an unstable state * (TinyBIOS 0.98, for example; fixed in 0.99). It's uncertain as to * whether or not this secret MSR can be used to release individual timers. * Jordan tells me that he and Mitch once played w/ it, but it's unclear * what the results of that were (and they experienced some instability). */ static void reset_all_timers(void) { uint32_t val, dummy; /* The following undocumented bit resets the MFGPT timers */ val = 0xFF; dummy = 0; wrmsr(MSR_MFGPT_SETUP, val, dummy); } After playing around with this undocumented MSR it looks like I only need to set bit 7 to free the MFGPT7. BTW, all MFGPT[0:5] will be reset during pll_reset(). Change-Id: I54a8d479ce495b0fc2f54db766a8d793bbb5d704 Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/2527 Tested-by: build bot (Jenkins) Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: remove GPIO60 memory reset gate on S3 transitionDuncan Laurie
This is no longer tied to a GPIO but has a proper chipset pin. Change-Id: Iba70338e8c67e3c3c1cb32e69bfea1282fda8cb5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2643 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: remove explicit pcie config accessesAaron Durbin
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove the pcie explicit accesses. The default config accesses use MMIO. Change-Id: I8406cec16c1ee1bc205b657a0c90beb2252df061 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2618 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14lynxpoint: PMIR register renameAaron Durbin
The register that controls global reset is named the Power Mangement Initialization Regiser (PMIR). Update the defines to reflect the documentation. Additionally, there is no core well reset control according to the EDS. There is, however, a CF9 lock field to lock this register down. Change-Id: I773c33bec63a06cdb869eb9f94553d476e492798 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2619 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14lynxpoint: Management Engine UpdatesAaron Durbin
The ME9 requirements have added some registers and changed some of the MBP state machine. Implement the changes found so far in the ME9 BWG. There were a couple of reigster renames, but the majority of th churn in the me.h header file is just introducing the data structures in the same order as the ME9 BWG. Change-Id: I51b0bb6620eff4979674ea99992ddab65a8abc18 Signed-Off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2620 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Properly Guard Engergy Policy by CPUIDAaron Durbin
The IA32_ENERGY_PERFORMANCE_BIAS MSR can only be read or written to if the CPU supports it. The support is indicated by ECX[3] for cpuid(6). Without this guard, some Haswell parts would GP# fault in this routine. No more GP# while running on haswell CRBs. Change-Id: If41e1e133e5faebb3ed578cba60743ce7e1c196f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2639 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-14haswell: add PCI id supportAaron Durbin
In order for coreboot to assign resources properly the pci drivers need to have th proper device ids. Add the host controller and the LPC device ids for Lynx Point. Resource assignment works correctly now w/o odd behavior because of conflicts. Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2638 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-14haswell: Remove logic to send dram init done to MEAaron Durbin
The reference code sends the dram init done command to the ME. Therefore, there is no need for coreboot to do this. Change-Id: I6837d6c50bbb7db991f9d21fc9cdba76252c1b7b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2633 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14basking ridge: update gpio, spd addresses, and OCAaron Durbin
Even though this is under the graysreef board it really applies to the Basking Ridge board. A subsequent patch will rename graysreef to baskingridge. The GPIO pins were updated to reflect the Basking Ridge schematics as well as the DIMM spd addresses and USB over current pins. Change-Id: Ice4e05f5203de3024cd463dfccf0bcfec1e247c1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2632 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: notes and updates.Aaron Durbin
Add a FIXME about checking a MCHBAR register that isn't setup yet. Also, remove revision updating because I can't find anything in the docs that suggest this is required for haswell. Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2631 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: align pei_data structure with intel-frameworkAaron Durbin
The intel-framework code has an updated pei_data structure. Use the new structure and revision. Also, remove the scrambler seed saving in CMOS since that appears to be handled in the saved data from the reference code. Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2630 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: use #defines for constants in udelay.cAaron Durbin
Change the hard coded values in udelay.c to use the #defines for MSRs and BCLK. Change-Id: I2bbeb0b478d2e3ca155e8f82006df86c29a4f018 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2629 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14Mainboard: Add support for Grays ReefAaron Durbin
Grays Reef is one of Intel's CRBs for the Haswell processor. The platform is named Shark Bay. GPIOs were the main focus so IRQ routing and ACPI still needs to be further looked at. Change-Id: Ie94b7af66f772714992a92612c76ca93b9b27088 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2621 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Add LPT LP device IDs to platform reportDuncan Laurie
Boot haswell ULT and see LPT reported properly. Change-Id: I48344a8dde6adbbf331c91231342de45b1b6c32a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2697 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Update GPU power management setupDuncan Laurie
This is the steps outlined in the BWG. It seems this is a lot simpler now (so far) which is good. To test, boot to chromeos with 3.7 kernel + i915.preliminary_hw_support=1 and see that the i915 driver complains a lot less than before and that a splashscreen is displayed. Change-Id: I722c90ecd351860949cedab24533f6c10e5b90e5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2696 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14lynxpoint: Update IOBP programming methodDuncan Laurie
This follows the new method outlined in the LPT BWG. It is also very pedantic about its operation so it is easier to read and compare against the docs and the reference code implementation. Change-Id: I235d634cded0c75ec0e9f53488f5b366107a18fa Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2694 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14x86: SMM Module SupportAaron Durbin
Add support for SMM modules by leveraging the RMODULE lib. This allows for easier dynamic SMM handler placement. The SMM module support consists of a common stub which puts the executing CPU into protected mode and calls into a pre-defined handler. This stub can then be used for SMM relocation as well as the real SMM handler. For the relocation one can call back into coreboot ramstage code to perform relocation in C code. The handler is essentially a copy of smihandler.c, but it drops the TSEG differences. It also doesn't rely on the SMM revision as the cpu code should know what processor it is supported. Ideally the CONFIG_SMM_TSEG option could be removed once the existing users of that option transitioned away from tseg_relocate() and smi_get_tseg_base(). The generic SMI callbacks are now not marked as weak in the declaration so that there aren't unlinked references. The handler has default implementations of the generic SMI callbacks which are marked as weak. If an external compilation module has a strong symbol the linker will use that instead of the link one. Additionally, the parameters to the generic callbacks are dropped as they don't seem to be used directly. The SMM runtime can provide the necessary support if needed. Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2693 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14Support ITE IT8518 embedded controller running Quanta's firmwareStefan Reinauer
Change-Id: Ib406b9d5005243d79eea5d2c0c6c86b5aa949891 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2721 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: always use MMIO PCI config accessesAaron Durbin
Add a bootblock.c file for the northbridge and setup the PCIEXBAR as the first thing using IO PCI config acceses. After that all PCI config accesses can use MMIO. Change-Id: I51d229c626c45705dda1757c2f14265cbc0e6183 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2617 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Add initial support for Haswell platformsAaron Durbin
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore, the southbridge support is included as well. The basis for this code is the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires more attention, but this is a good starting point. This code partially gets up through the romstage just before training memory on a Haswell reference board. Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2616 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14exynos5250: add RAM resource beginning at physical addressDavid Hendricks
The original code attempted to reserve a space in RAM for coreboot to remain resident. This turns out not to be needed, and breaks things for the kernel since the exynos5250-smdk5250 kernel device tree starts RAM at 0x40000000. (This patch was originally by Gabe, I'm just uploading it) Change-Id: I4536edaf8785d81a3ea008216a2d57549ce5edfb Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2698 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-13Eagleheights DSDT: Grant OS control through OSCMike Loptien
Change the OSC method to actually grant control of PCIe capabilities to the OS instead of granting no control. I believe the logic was backwards in the original commit. Bits should be set when granting control and cleared when not granting control. By setting the return value to 0x00, we effectively tell the OS that it cannot control any PCIe capability. See section 6.2.9 of the ACPI spec version 3.0 for more information. This edit is a duplication of the OSC method that is in the src/southbridge/intel/bd82x6x/pch.asl file. Change-Id: Id2462ab12203afceb9033f24d06b4dfbf2236d2e Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2714 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13exynos5250/snow: enable branch predictionDavid Hendricks
This enables branch prediction. We can probably find a better place to do this, but for now we'll do it in snow's romstage main(). Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2701 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13src/mainboard: Drop redundant `CHIP_NAME` again for new portsPaul Menzel
Since commit »Drop redundant CHIP_NAME in mainboard.c« (a93c3fe7) [1] `CHIP_NAME` is unneeded for mainboards as the name is composed automatically in `src/devices/root_device.c` from the strings in Kconfig. Unfortunately the ports for Google Butterfly, Link and Parrot as as well as IEI PM-LX2-800-R10 introduced CHIP_NAME again. So drop it again too. [1] http://review.coreboot.org/1635 Change-Id: Ice7577a2a5c6070e196f2647c440b7a8e140e27e Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2708 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13exynos5250: Don't set PS_HOLD in bootblock_cpu_initDavid Hendricks
PS_HOLD gets set in exynos' power_init(). Change-Id: Ib08e0afcad23cbd07dc7e3727fd958a1bc868b5a Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2700 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13exynos5250/snow: call PMIC's power_init() functionDavid Hendricks
Call the power_init() function. We appear to have forgotten about it when deprecating lowlevel_init_subsystems(), but it didn't seem to cause problems until we got to doing more interesting stuff recently. There are some clean-ups to do from the original code, such as not attempting to configure I2C from PMIC code, which we'll get around to in follow-up patches. (Credit to Gabe for spotting this) Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2699 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-12AMD CIMx SB800: Enable AHCI mode for SATA controller by defaultPaul Menzel
The current default is IDE mode which is slower compared to AHCI mode. Therefore use AHCI mode by default. A similar change was made for AMD Persimmon in commit »Enable SATA AHCI for faster boot with SeaBIOS.« (96be74c7) [1] but was indirectly reverted by »sb800: Add sata ahci/raid mode kconfig option« (d4a0e7d0) [2]. [1] http://review.coreboot.org/220 [2] http://review.coreboot.org/225 Change-Id: I4fa31b0a3280891e7a3f37675ae8415205818947 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2661 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-12watchdog.h: Fix compile time error on disabling watchdog handlingPatrick Georgi
There's a compile time error that we didn't catch since the board defaults as used by the build bot won't expose it. Just make watchdog_off() a no-op statement so there aren't any stray semicolons in the preprocessor output. Change-Id: Ib5595e7e8aa91ca54bc8ca30a39b72875c961464 Reported-by: 'lautriv' on irc.freenode.net/#coreboot Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2627 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-11pci.h: Drop unused `mainboard_pci_subsystem*` prototypesPatrick Georgi
We used to allow mainboards to override subsystems using mainboard_pci_subsystem_vendor_id and mainboard_pci_subsystem_device_id. Mechanisms have changed and the only occurrence of these names is in the header. Change-Id: Ic2ab13201a2740c98868fdf580140b7758b62263 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2625 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-11ASUS M5A88-V: Kconfig: Fix mainboard model namePaul Menzel
Despite everywhere the model name M5A88-V is used, in Kconfig the string M5A88PM-V is used. Searching for that model string on the WWW does not return anything which is unrelated to coreboot, so change that string to M5A88-V. Change-Id: I25cf9d4a5fc3f9b9356e8616452066ebf873f44c Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2613 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: QingPei Wang <wangqingpei@gmail.com>
2013-03-09Add Intel Panther Point USB3 initializationMarc Jones
Add PEI updates and ACPI updates for supporting EHCI to XHCI USB port support. Change-Id: I9ace68a1b3950771aefb96c1319b8899291edd9a Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2519 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-08Persimmon DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This change will apply to other AMD mainboards and will be in a different commit. Change-Id: I44f22bc03a0dcbcd2594d4291508826cc2146860 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2592 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-08Eliminate do_div().David Hendricks
This eliminates the use of do_div() in favor of using libgcc functions. This was tested by building and booting on Google Snow (ARMv7) and Qemu (x86). printk()s which use division in vtxprintf() look good. Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2606 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-08AMD Inagua: Use SPD read code from F14 wrapperKimarie Hoot
Changes: - Get rid of the inagua mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: Id05227fcf18c6ab94ffe1beb50b533ab7b0535db Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2607 Reviewed-by: Martin Roth <martin.roth@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-08AMD CIMx SB800 boards: platform_cfg.h: Integrate Kconfig SATA Mode choicePaul Menzel
Currently for Advansus A785E-I, ASRock E350M1 and ASUS M5A88-V despite what is chosen in Kconfig »Chipset« menu item, $ more .config […] # CONFIG_ENABLE_IDE_COMBINED_MODE is not set CONFIG_IDE_COMBINED_MODE=0x1 # CONFIG_SB800_SATA_IDE is not set CONFIG_SB800_SATA_AHCI=y # CONFIG_SB800_SATA_RAID is not set CONFIG_SB800_SATA_MODE=0x2 […] the SATA controller is put into IDE mode. $ lspci -nn | grep SATA 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40) Commit »sb800: Add sata ahci/raid mode kconfig option« (d4a0e7d0) [1] added the options above to configure the mode using Kconfig and some SB800 boards were adapted already. For example commit »persimmon: sb800 sata mode configure update« (1386fa74) [2] did so for AMD Persimmon. Doing the same by assigning the Kconfig variable to the value in `platform_cfg.h` integrates this with the three remaining boards listed above. The patch is successfully tested with the ASRock E350M1. $ lspci -nn | grep SATA 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) [1] http://review.coreboot.org/225 [2] http://review.coreboot.org/227 Change-Id: I227257e2c8f04f18c27ff00fe62d42e372de67e4 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2610 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-08AMD Persimmon: mainboard.c: Make comment generic to reduce differencePaul Menzel
Replace »persimmon« by »board« in comment to keep `diff` output between boards small. Change-Id: Ieae2a63782c488ae35f22eb30f5b1049200d12c8 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2611 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-08AMD Union Station: Use SPD read code from F14 wrapperKimarie Hoot
Changes: - Get rid of the union_station mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: I19d6b0d674b67294519383f80928471b37da1e14 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2609 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-08AMD South Station: Use SPD read code from F14 wrapperKimarie Hoot
Changes: - Get rid of the south_station mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: If4291d25ea81bf375f55b64c07c223a847a211d0 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2608 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-08ARMV7 and Google/Snow: Add exception support code to the ramstageRonald G. Minnich
This is previously used exception code from libpayload. On startup it installs and then tests an exception handler. The test is an unaligned memory operation. Yes, we've seen what might be exceptions in the ramstage, and it makes sense to handle them. This code is identical in structure and operation to the previously committed payload exception handler, though we reserve the right to change it as circumstances require. The remaining question is whether we need it in romstage. Change-Id: I24484686c33c9757af8ba171ebae9773828fb69d Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2614 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-08AGESA: Fix CR0_PE bit defineKonstantin Aladyshev
AGESA code has wrong definition of CR0_PE bit (1 instead of 0). PE [Protected Mode Enable] is 0 bit in CR0 register (If PE=1, system is in protected mode, else system is in real mode) Bit 1 is MP [Monitor co-processor] (Controls interaction of WAIT/FWAIT instructions with TS flag in CR0) System uses CR0_PE define, but I didn't expect any consequences because of this bug. Change-Id: I54d9a8c0ee3af0a2e0267777036f227a9e05f3e1 Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru> Reviewed-on: http://review.coreboot.org/2591 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-08Supermicro H8QGI: set up right frequency limits for memory controllerKonstantin Aladyshev
According to BKDG: "Memory controller (MCT) and DRAM controllers (DCTs) additions: • Support for 933 MHz (1866 MT/s) MEMCLK frequency." Change-Id: I6f307ce3fcb355d5445f1ea86def73a41b928a57 Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru> Reviewed-on: http://review.coreboot.org/2589 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-08AGESA: Fix bug in AMD_DISABLE_STACK_FAMILY_HOOK_F15Konstantin Aladyshev
_RDMSR instruction loads the contents of a 64-bit model specific register (MSR) specified in the ECX register into registers EDX:EAX. The EDX register is loaded with the high-order 32 bits of the MSR and the EAX register is loaded with the low-order 32 bits. EDX:EAX = MSR[ECX] So bit 49 will be contained in EDX register. Buggy code instead of bit 49 (CombineCr0Cd) sets bit [49-32=17] (PfcStrideDis). PfcStrideDis bit disables stride prefetch generation. This leads to memory bandwidth loss. _________ Supermicro H8QGI board After applying this change i observed huge memory bandwidth increase in tests that runs on small amount of cores. But unfortunately it doesn't affect overall bandwidth results on 4P system with 48 cores. So i think that in this system leading limiting factor is AMD HT-ASSIST feature (Probe filter). But right now it is not working. System stucks in Linux boot. I have done some experiments and figured out that stuck happens when system have cores in compute unit (CU) other than CU with BSC (boot strap core). CU is two cores (primary and seconary) that shares some things (L2 cache, FPU ...) So with probe filter i can boot Linux with one (BSC) or two (BSC + secondary core in its CU) cores. And with this configuration i can see memory bandwidth on 1 core (or two cores) close to original bios. Change-Id: I5a95f5b753d600c70d3c93d36fecc687610c61cd Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru> Reviewed-on: http://review.coreboot.org/2588 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-08FrontRunner/Toucan-AF: lower SPI speed to 22 MHzJens Rottmann
The Hudson-E1's default SPI speed for normal i.e. non-fast reads is 66 MHz, but the SST 25VF032B datasheet allows max. 25. Lower the speed to 22 MHz, otherwise BIOS flashing fails. Change-Id: I22e87d833a3ebd316b6e873595a2480831533ab1 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2605 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-07AMD Persimmon: Use SPD read code from F14 wrapperMartin Roth
Changes: - Get rid of the persimmon mainboard specific code which has been moved into the wrapper as a platform generic function in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: I5f017dbb8dee5a09ec19734a6069ff9b71a6ab50 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/2500 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-07AMD Fam14: Add SPD read functions to wrapper codeMartin Roth
Change: This is the initial step for moving the AMD F14 & HUDSON1,2,3 SPD-read callout out of the mainboard directories and into the wrapper. The next step is to update the platforms to use this routine in BiosCallouts.c and to delete the code from the mainboard directories. The DIMM addresses should be moved into devicetree.cb. If there are significant differences or reasons that the mainboard needs to override this code, it's perfectly reasonable to keep using the version in the mainboard, but this allows us to remove duplicated code and simplify the mainboard directories. Notes: This started by duplicating what was in Persimmon, and was changed to use the devicetree.cb structures. The ASF setup was also removed from the persimmon copy (PMIO writes to 0x28 & 0x29) as that's not needed for the SPD access and doesn't make sense to initialize here. Significant cleanup and magic number reduction was done as well. It is intended that this file will not be included in ramstage as the DIMM init is all done in romstage. This is similar to what was done for Parmer/Thatcher in commit 7fb692bd - http://review.coreboot.org/#/c/2190/ Fam15tn: Move SPD read from mainboards into wrapper Yes, it would make sense to split this into two separate files and move the SMBUS initialization and access into the southbridge wrapper. Maybe that can come next. Change-Id: I1e106d3912c160b0015bf02158d9faba4f578ee3 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/2497 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-07Remove UTF-8 characters from commentsRonald G. Minnich
I've used an operating system for over 10 years now that makes UTF-8 easy. It's not called Linux or OSX. When UTF-8 is needed, of course, then we can look again. I can't think of a single redeeming feature of placing it in the comment in this manner. It's certainy not needed. The inclusion of UTF-8 characters is inconvenient, especially from a text terminal. I don't really want to start using compose in CROSH shell terminals on chromeos. We might want to incorporate "no UTF-8" as a commit filter. For now, get rid of these characters. Change-Id: If94cc657bae1dbd282bec8de6c5309b1f8da5659 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2604 Reviewed-by: Bernhard Urban <lewurm@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-07Revert "ARMv7: Simplify div64"David Hendricks
This reverts commit 1cd616082100f47dc2d6d73669c6aa2e5eb039ad Division bites us again. I don't know how or why, but printk() seems to break (again) with this patch. I'm surprised we didn't encounter problems earlier on... Change-Id: I81cb9f20879f5eb73a76e1af47b96a68d1e81dc8 TODO: Find a better solution for div64. This one is too painful, but seems necessary for now (and sort-of works with our vtxprintf hack). Reviewed-on: http://review.coreboot.org/2600 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-07snow: add real values for GPIOs in fill_lb_gpios()David Hendricks
This adds some real GPIO mappings where virtual GPIOs were used before. Change-Id: I25d4be45f986c8d622b97151f8bdae2651baf3e6 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2603 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-07exynos5: add GPIO port enumsDavid Hendricks
This adds an enum for GPIO ports on the Exynos5. To make them useful, they are assigned the absolute MMIO address where a s5p_gpio_bank struct can point to. Change-Id: Ia539ba52d7393501d434ba8fecde01da37b0d8aa Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2602 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-07google/snow: fix coding styleStefan Reinauer
cosmetics Change-Id: Iea33768d901641861aa7b2c76af8753a848f584d Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2601 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-07src/arch/x86/boot/acpigen.c: Small coding style and comment fixesPaul Menzel
While reading through the file fix some spotted errors like indentation, locution(?), capitalization and missing full stops. Change-Id: Id435b4750e329b06a9b36c1df2c39d2038a09b18 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2484 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-07Fix build by adding `cbmem.c` to `COLLECT_TIMESTAMPS`Kyösti Mälkki
A board without HAVE_ACPI_RESUME did not build with COLLECT_TIMESTAMPS enabled as `cbmem.c` was not built. Change-Id: I9c8b575d445ac566a2ec533d73080bcccc3dfbca Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2549 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-07Intel e7505: provide get_top_of_ramKyösti Mälkki
This is required to enable EARLY_CBMEM_INIT. Change-Id: I6d8caf382aa48eded81c1e94bbbcd3975ea88a1a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2550 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-07Fix socket LGA775Kyösti Mälkki
Models 6ex and 6fx select UDELAY_LAPIC so cannot select contradicting UDELAY_TSC here. Model 1067x requires speedstep. Change-Id: I69d3ec8085912dfbe5fe31c81fa0a437228fa48f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2525 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-07ASRock E350M1: Let `BiosGnbPcieSlotReset()` return `AGESA_UNSUPPORTED`Paul Menzel
Quoting Jens Rottmann [1]: Nevertheless I still think this whole function is bogus for the E350M1. The function assumes GPIO21 is wired to reset APU PCIe lane 0+1 (PCIe x8, port 4+5 as Coreboot/AGESA calls it), GPIO25 resets lane 2 (PCIe x4) and GPIO02 lane 3. But the E350M1 has PCIe x16 i.e. probably APU lanes 0-3 bundled, completely different layout. They could have chosen GPIO21 to force resets, or 25 - or maybe 50 like on the Persimmon or any other they fancied or - and this is the most probable - none at all. Having BiosGnbPcieSlotReset() toggle some GPIOs without knowing what they do on the E350M1 (if anything at all) is nonsense. In my opinion this whole function should just "return AGESA_UNSUPPORTED" and good riddance. [1] http://review.coreboot.org/#/c/2445/ Change-Id: Iac66da41182e838c7e6925250cc3982adbb3e4ec Reported-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2489 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
2013-03-06samsung/exynos5: add display port and framebuffer defines and initializationRonald G. Minnich
These are essential functions for setting up the display port and framebuffer, and also enable such things as aux channel communications. We do some very simple initialization in romstage, mainly set a GPIO so that the graphics is powering up, but the complex parts are done in the ramstage. This mirrors the way in which graphics is done in the x86 size. I've added a first pass at a real device, and put it in the mainboard Kconfig, hoping for corrections. Because startup is so complex, depending on device type, I've created a 'displayport' device that removes some of the complexity and makes the flow *much* clearer. You can actually follow the flow by looking at the code, which is not true on other implementations. Since display port is perhaps the main port used on these chips, that's a reasonable compromise. All parameters of importance are now in the device tree. Change-Id: I56400ec9016ecb8716ec5a5dae41fdfbfff4817a Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2570 Tested-by: build bot (Jenkins)
2013-03-06ASRock E350M1: mainboard.c: Add declarations for `set_pcie_{,de}reset`Paul Menzel
Since the merg of the ASRock E350M1 port (a649a96e) the compiler warns about the following [1]. mainboard.c:35, GNU Compiler 4 (gcc), Priorität: Normal no previous prototype for 'set_pcie_reset' [-Wmissing-prototypes] mainboard.c:43, GNU Compiler 4 (gcc), Priorität: Normal no previous prototype for 'set_pcie_dereset' [-Wmissing-prototypes] Adding the function prototypes to the beginning of the file as done in commit »Persimmon updates for AMD F14 rev C0« (d7a696d0) addresses the warning. [1] http://qa.coreboot.org/job/coreboot-gerrit/4975/warnings13Result/package.-139448264/file.-1544928473/ [2] http://review.coreboot.org/137 Change-Id: Iad2e62ec37c3a2f749a264974b61ac7c226e9b83 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2590 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-06Google/Snow: enable sound hardware clocksRonald G. Minnich
Set up the clocks used for sound and turn on the sound clock. Change-Id: Ic59bfa9ae87116299503e6d25aeefba98c842fb8 Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2587 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-06google/snow: Change MMC0 to work in 8 bit mode.Ronald G. Minnich
The MMC0 on google/snow can run in 8 bit mode. To simplify driver development, we thought disabling it (using zero, which runs in 1-bit / 4-bit mode) may help. However, after some experiments in payload drivers, setting pinmux to 8 bit mode can still allow MMC to run in 1-bit / 4-bit mode, so it's pretty safe to enable 8 bit mode by default for better performance. Verified to boot on google/snow, and got MMC0 working. Change-Id: Ic0acc723fe6a8aecf373429d3801beadd70815d9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2585 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-06AMD SB800: don't switch clock from 14 to 48 MHz for smscsuperioJens Rottmann
The power up default for the 14M_25M_48M_OSC switchable clock output ball of the SB800 chipset is 14 MHz. sb800/bootblock.c changes this to 48 MHz, which is the correct value for almost all SIOs. However, not for 'smscsuperio' (SMSC SCH311x), which needs the original 14 MHz and is not configurable for other clock speeds. A wrong SIO clock supply results in funny RS232 output (wrong bit speed) and non-working PS/2. We could switch back to 14 MHz in the mainboard's romstage.c, but then the clock frequency would change twice. The resulting short 48 MHz burst causes a handful of rubbish characters on RS232 on every boot until the SIO clock has stabilized again. This patch skips the SB800 clock switch if the SIO Kconfig requests 14 MHz. This does not affect any boards currently in the repository (yet). Change-Id: Icff41fd88dc41c08f3700ab4f786852f04eff2a4 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2454 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-04FrontRunner/Toucan-AF: drop unnecessary compile time CPU model selectionJens Rottmann
The first reason for selecting the CPU model at compile time was a multi-second pause if booting a single core Fusion T40R with MAX_CPUS=2. Recent tests show the pause has disappeared, someone must have fixed it. The second reason was me not knowing how to make a single vgabios image work with two different PCI IDs. Many thanks to Martin Roth for educating me! Quote: "The way to make coreboot use the same vbios for different video device IDs is through the map_oprom_vendev function. In family 14 it's in northbridge/amd/agesa/family14/amdfam14_conf.c You would name your video bios 1002,9802 in the config and all the other device/vendor IDs for the family 14h processors will fall through the initial check for the video bios and will get remapped to use that vbios. This only works if you're initializing the vbios inside coreboot. I don't know if you're using SeaBios as a payload, but if you are you can add the vbios to cbfs as vgaroms/vbios.rom and the rom will always be initialized." I'd like to add the vgabios is added as type 'optionrom' when Coreboot make adds it, however to work with SeaBios it has to be added manually with cbfstool and with type 'raw', or it will hang. Change-Id: I8190d0c3202a60dfccb77dde232f9ba7ce5ce318 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2584 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-04ARM: remove code that is IMHO a dangerous designRonald G. Minnich
OK, this is tl;dr. But I need to write this in hopes we make sure we don't put code like this into coreboot. Ever. Our excuse in this case is that it was imported, not obviously wrong, and easily changed. It made sense to get it in, make it work, then do a cleanup pass, because changing everything up front is almost impossible to debug. The exynos code has bunch of base register values, e.g. These are base addresses of things that look like a memory-mapped struct. To get these to a pointer, they created the following macro, which creates an inline function. static inline unsigned int samsung_get_base_##device(void) \ { \ return cpu_is_exynos5() ? EXYNOS5_##base : 0; \ } And then invoke it 31 times in a .h file, e.g.: SAMSUNG_BASE(clock, CLOCK_BASE) to create 31 functions. And then use it: struct exynos5_clock *clk = (struct exynos5_clock *)samsung_get_base_clock(); OK, what's wrong with this? It's easier to ask what's right with it. Answer: nothing. I have a long list of what's wrong, and I may leave some things out, but here goes: 1. the "function" can return a NULL if we're not on exynos5. Most uses of the code don't check the return value. 2. And why would this function be running, if we're not on an exynos5? Why compile it in? 3. Note the cast everywhere a samsung_get_base_xxx is used. The function returns an untyped variable, requiring the *user* to get two things right: the cast, and the function invocation. One can replace that _clock(); with _power(); in the code above, and they will be referencing the wrong registers, and they'll never get an error! We have a C compiler; use it to type data. 4. You're generating 31 functions using cpp each and every time the file is included. The C compiler has to parse these each time. It's not at all like a simple cpp macro which is only generated on use. 5. You can't tags or etags this code 6. In fact, any kind of analysis tool will be unable to do anything with this cpp magic. That's only a partial list. So what's the right way to do it? Just make typed constants, viz: Or, since I expect people will want the lower case function syntax, I've left it that way: Now we've got something that is efficient, and we don't even need to protect with any more. Hence this change. We've got something that is type checked, does not require users to cast on each use, will catch simple programming errors, can be analyzed with standard tools, and builds faster. So if we make a mistake: struct exynos5_clock *clk = samsung_get_base_adc(); We'll see it: src/cpu/samsung/exynos5250/clock.c: In function 'get_pll_clk': src/cpu/samsung/exynos5250/clock.c:183:3: error: initialization from incompatible pointer type [-Werror] which we would not have seen before. As a minor benefit, it shaves most of a second off the compilation. Change-Id: Ie67bc4bc038a8dd1837b977d07332d7d7fd6be1f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2582 Tested-by: build bot (Jenkins)
2013-03-04bump SeaBIOS to 1.7.2.1Idwer Vollering
Update coreboot to use SeaBIOS' tag rel-1.7.2.1 Change-Id: I01969407964a7cf64f7c4800b59c6aed845b24f9 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/2575 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-03-03AMD Persimmon, LiPPERT Fam14: Fix typo code*c* in commentPaul Menzel
Commit f154c018 Author: Marc Jones <marcj303@gmail.com> Date: Wed Dec 14 11:24:00 2011 -0700 Persimmon audio codec verb patch. Reviewed-on: http://review.coreboot.org/490 has a typo code*c* in the comments for `AZALIA_OEM_VERB_TABLE`. As this was copied over to the LiPPERT Fam14 boards, use the following command to fix the typo. $ git grep -l cocec | xargs sed -i s,cocec,codec, Change-Id: I1525b0445edab81ab136b3adece52b78ba7abc71 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2576 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-02ASRock E350M1: Remove non-existing PCI devices 12.1 and 13.1Paul Menzel
Looking at the coreboot log […] PCI: 00:12.0 [1002/4397] enabled sb800_enable() PCI: Static device PCI: 00:12.1 not found, disabling it. sb800_enable() PCI: 00:12.2 [1002/4396] ops PCI: 00:12.2 [1002/4396] enabled sb800_enable() PCI: 00:13.0 [1002/4397] ops PCI: 00:13.0 [1002/4397] enabled sb800_enable() PCI: Static device PCI: 00:13.1 not found, disabling it. sb800_enable() PCI: 00:13.2 [1002/4396] ops PCI: 00:13.2 [1002/4396] enabled […] and the `lspci -tnvv` output running the proprietary vendor BIOS attached to the Wiki page of the ASRock E350M1 [1][2] -[0000:00]-+-00.0 1022:1510 +-01.0 1002:9802 +-01.1 1002:1314 +-04.0-[01]-- +-11.0 1002:4391 +-12.0 1002:4397 +-12.2 1002:4396 +-13.0 1002:4397 +-13.2 1002:4396 […] both PCI devices do not exist, so remove them from `devicetree.cb`. Commit 48918f7 [3] Persimmon, Inagua: PCI devs 12.1, 13.1 (USB) don't exist, but 14.6 (GEC) does did the same for AMD Inagua and AMD Persimmon. [1] http://www.coreboot.org/ASRock_E350M1 [2] http://www.coreboot.org/File:ASRock_E350M1_info_dump.tar.bz2 [3] http://review.coreboot.org/2463 Change-Id: Ief6de1bda093d1f29d5925985e5c3839cdded537 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2536 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-02FrontRunner/Toucan-AF: work around AGESA RAM init crashing on rebootJens Rottmann
If you try to reset the system with outb(3,0x92), outb(4,0xcf9) or a triple-fault it will instead crash with a messy screen. As the more common outb(0xFE, 0x64) doesn't work with our setup, Linux will crash whenever you ask it to reboot. Closer inspection shows that on a warm boot of Coreboot agesawrapper_amdinitpost() always fails with error code 7. Looks like DDR3 re-init goes wrong somehow. I tried find the reason for this but was unable to. I am convinced this is not board specific but a bug in AGESA. In the end I had to settle for a workaround: if amdinitpost returns 7 this patch resets the system harder with outb(0x06, 0x0cf9), after that RAM init will succeed. As amdinitpost is early in POST this automatic reset is quick enough not to be noticable. I'd perfer a real fix, but that's all I have. Change-Id: I4763254b489f42a135232e45328ecf0d5c4d961a Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2573 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-02LiPPERT Toucan-AF [2/2]: actually implement mainboard supportJens Rottmann
Step 2: change the Persimmon code to adapt it to the new board's hardware. The Toucan-AF is a COM Express Compact Type 6 form factor embedded board: - AMD Fusion G-T56N (1.65 GHz dual core) or T40R (1 GHz single core) APU - 1-4 GB DDR3 memory down - 1x VGA, 2x DisplayPort (1 switchable to LVDS) - AMD A55E (Hudson-E1) southbridge - 8x USB 2.0 - 4x SATA - HD Audio (with codec on baseboard) - NEC uPD78F0532 microcontroller on I2C ("SEMA") - 7x PCIe2.0 x1 (1 on PEG) - Intel I210 GbE (on APU PCIe x1, can be disabled for additional PCIe) - 2x SST 25VF032B (SO8, soldered) 4 MB SPI flash (BIOS and failsafe BIOS) The Toucan-AF has no SIO on board. This patch includes basic support for a Winbond W83627DHG (PS/2, 2x RS232), because the ADLINK ExpressBase-6 used for evaluation happens to have one. The code may have to be adapted to the actual baseboard of the application. http://www.adlinktech.com/PD/web/PD_detail.php?pid=1132 Change-Id: I9041b905bad45852ac9b402fcbd5decbc98b377b Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2572 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-02LiPPERT Toucan-AF [1/2]: create board by forking AMD PersimmonJens Rottmann
Step 1: copy all files unmodified from Persimmon. This makes it much easier later to see how the two boards actually and deliberately differ when porting bugfixes from one to the other. Git's copy detection is imperfect (and slow). Change-Id: I1ff02913479c07679f8c3ae5e6dd7876e6000b55 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2571 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-02LiPPERT FrontRunner-AF [2/2]: actually implement mainboard supportJens Rottmann
Step 2: change the Persimmon code to adapt it to the new board's hardware. The FrontRunner-AF is a PC/104+ form factor embedded board: - AMD Fusion G-T56N (1.65 GHz dual core) or T40R (1 GHz single core) APU - DDR3 SO-DIMM socket (1.5 or 1.35V) - VGA and LVDS (via Analogix ANX3110) - AMD A55E (Hudson-E1) southbridge - 6x USB 2.0 - 1x SATA, 1x CFast socket - HD Audio (via Realtek ALC886) - PCI and ISA (via ITE IT8888) - NEC uPD78F0532 microcontroller on I2C ("SEMA") - Intel I210 GbE (on APU PCIe x1) - SMSC SCH3112 SIO - PS/2 - 2x RS232/485 - 2x SST 25VF032B (SO8, soldered) 4 MB SPI flash (BIOS and failsafe BIOS) http://www.adlinktech.com/PD/web/PD_detail.php?pid=1131 Change-Id: Id55f89d224ad669b351c36128b12299802b721ba Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2553 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-02LiPPERT FrontRunner-AF [1/2]: create board by forking AMD PersimmonJens Rottmann
Step 1: copy all files unmodified from Persimmon. This makes it much easier later to see how the two boards actually and deliberately differ when porting bugfixes from one to the other. Git's copy detection is imperfect (and slow). Change-Id: I2fd1bf8428fc8a1e7becee888b6182b9bd8166a0 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2552 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-01GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«Paul Menzel
In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-01armv7/snow: Add S5P MSHC initialization in ROM stage.Hung-Te Lin
The SD/MMC interface on Exynos 5250 must be first configured with, GPIO, and pinmux settings before it can be detected and used in ramstage / payload. Verified on armv7/snow and successfully boot into ramstage. Change-Id: I26669eaaa212ab51ca72e8b7712970639a24e5c5 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2561 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-28Revert "ARMv7: drop special handling for stages.c"Ronald G. Minnich
This breaks booting, and in fact stages.c is always going to be special: for it to work it has to be compiled for arm only, no thumb allowed. It's probably better to leave the stages.o target in explicitly so it's clear that it has to be compiled with a particular set of flags, rather than try to remember that we must always have the default rules no break stages.c compilation. That would be a mess. I will be pushing a CL to get rid of the assembly dump, but will be a trivial fix. This reverts commit 8f4647a24bf19a96531af9905b23ae8a2fc2675a Change-Id: I5e3d8e5b991f6ccf4d49078378cd4615fb230ca0 Reviewed-on: http://review.coreboot.org/2554 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 07:45:59 +0000