summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-03-17haswell platforms: restructure romstage mainAaron Durbin
There was a mix of setup code sprinkled across the various components: southbridge code in the northbridge, etc. This commit reorganizes the code so that northbridge code doesn't initialize southbridge components. Additionally, the calling dram initialization no longer calls out to ME code. The main() function in the mainboard calls the necessary ME functions before and after dram initialization. The biggest change is the addition of an early_pch_init() function which initializes the BARs, GPIOs, and RCBA configuration. It is also responsible for reporting back to the caller if the board is being woken up from S3. The one sequence difference is that the RCBA config is performed before claling the reference code. Lastly the rcba configuration was changed to be table driven so that different board/configurations can use the same code. It should be possible to have board/configuration specific gpio and rcba configuration while reusing the romstage code. Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2681 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add Intel Whitetip Mountain 1 mainboardDuncan Laurie
Lots of things are still placeholder and need work. Due to the useful GPIOs being run to either the EC or the SIO1007 I have hard coded developer mode on and recovery mode off. Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2724 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17bd82x6x: Add config option to force SATA link to different speeds.Shawn Nematbakhsh
Certain SATA devices claim to support SATA 6 Gbps, but in fact have bugs. For these devices, add a config option to force the SATA link speed to something other than default. Change-Id: I2dc1793cd58771298a392345162d39d20eb0afbb Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2765 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Pantherpoint: Add XHCI device initDuncan Laurie
This enables power management and clock gating on XHCI. Change-Id: I124ea6c5aca034b7ec4b5286d971c2adfce25c88 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2761 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17bd82x6x: don't use absolute symbolsAaron Durbin
objcopy -B provides symbols of the form _binary_<name>_(start|end|size). However, the _size variant is an absoult symbol. If one wants to relocate the smi loading the _size symbol will be relocated which is wrong since it is suppose to be a fixed size. There is no way to distinguish symbols that shouldn't be relocated vs ones that can. Instead use the _start and _end variants to determine the size. Change-Id: I55192992cf36f62a9d8dd896e5fb3043a3eacbd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2760 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x XHCI(USB3) S3/S4 workaroundMarc Jones
The bd82x6x requires some additional setting on S3/S4 entry. Change-Id: I24489ab94dd7cd5a4a64044f25153f5b01a45b77 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2759 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x PCH functions to SMMMarc Jones
Add the PCH function to SMM for follow-on SMM patches that require these functions. Change-Id: I7f3a512c5e98446e835b59934d63a99e8af15280 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2758 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell: include TSEG region in cacheable memoryAaron Durbin
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG region is setup as cacheable through the MTTRs, accesses to the TSEG region before SMM relocation are cached. This allows for the setup of SMM relocation to be faster by caching accesses to the future TSEG (SMRAM) memory. 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: BGSM: 0xad800000 MC MAP: BDSM: 0xada00000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 TSEG->BGSM: PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4 BGSM->TOLUD: PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB Adding hole at 2776MB-2816MB Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC Zero-sized MTRR range @0KB Allocate an msr - basek = 00400000, sizek = 0023d800, Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB Adding hole at 6390MB-6400MB Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC MTRR translation from MB to addresses: MTRR 0: 0x00000000 -> 0x80000000 WB MTRR 1: 0x80000000 -> 0xa0000000 WB MTRR 2: 0xa0000000 -> 0xb0000000 WB MTRR 3: 0xad800000 -> 0xae000000 UC MTRR 4: 0xae000000 -> 0xb0000000 UC I'm not a fan of the marking physical address space with MTRRs as being UC which is PCI space, but it is technically correct. Lastly, drop a comment describing AP startup flow through coreboot. Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17i945: Replace some two magic values by defined namesPatrick Georgi
Devoutly to be wish'd. To die,—to sleep;— To sleep! perchance to dream:—ay, there's the rub; For in that sleep of death what dreams may come, (Since who could argue with William Shakespeare?) Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/2733 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-17ASROCK 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: I5184df8deb7b5d2e15404d689c16c00493eb01aa Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2736 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 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 This is the same chagne as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2741 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 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 This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 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 This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2743 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert 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: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2737 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 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. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2738 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 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. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: I2701d915338294bdade2ad334b22a51db980892e Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 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. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2740 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17lynxpoint: Add support for disabling ULT devicesDuncan Laurie
These enables are hidden behind IOBP for some reason. Boot to linux with SDIO disabled and see that the SDIO driver does not load and crash the system. Change-Id: Icfbfa117e9e57a51d32db7f6366a9d0d790adcf0 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2695 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16stddef.h: Add standard defines for KiB, MiB, GiB, and TiBRonald G. Minnich
Paul points out that some people like 1024*1024, others like 1048576, but in any case these are all open to typos. Define KiB, MiB, GiB, and TiB as in the standard so people can use them. Change-Id: Ic1b57e70d3e9b9e1c0242299741f71db91e7cd3f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2769 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-16haswell: don't add a 0-sized memory range resourceAaron Durbin
It's possible that TOUUD can be 4GiB in a small physical memory configuration. Therefore, don't add a 0-size memory range resouce in that case. Change-Id: I016616a9d9d615417038e9c847c354db7d872819 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2691 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16Show the device tree.Ronald G. Minnich
This is a bit of a hack but it's very handy. It compiles in your static.c and then shows what coreboot would see when it is run. It uses your static.c and functions pulled from src/device/device_util.c. I've already used it to debug problems with the snow device tree. I'm waiting someone to tell me this is already written :-) Change-Id: Ia8c8a5d08d8757bec49eaf70473efa701bc56581 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2767 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16google/snow: rename a file so that it is clear what board it is forRonald G. Minnich
One might wonder what a board named 'build' does. Rename the file to build-snow. The fact that it is in a directory with google in the name should be enough to identify the vendor. Change-Id: I0b473cdce67d56fc6b92032b55180523eb337d66 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2766 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16gitmodules: Ignore 3rdparty in "diff family"Patrick Georgi
This should help avoid wrong 3rdparty commit ids creeping in. Change-Id: I2134ad1d3ad0237ef3f12baf4d4aafb02009e7bc Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2768 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
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-15Update 3rdparty mark to latest repositoryStefan Reinauer
For google/stout binaries Apparently the actual marker got lost in the rebase / change of the commit message. Change-Id: I4f18b9ddba326988b58f2595c0025a113feb0d68 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2734 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-14libpayload: add support for vboot_handoffAaron Durbin
The vboot_handoff structure needs to be parsed from the coreboot tables. Add a placeholder in sysinfo as well as the ability to parse the coreboot table entry concering the vboot_handoff structure. Built with unified boot loader and ebuild changes. Can find and use the VbInitParams for doing kernel selection. Change-Id: If40a863b4a445fa5f7814325add03355fd0ac647 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2720 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14libpayload: Turn the endian conversion macros into functions.Gabe Black
In their current macro form, any arguments that are expressions will be evaluated multiple times. That can cause problems if they have side effects, and might not even compile if the overall expression is ambiguous, for instance if you pass in foo++. Built with code that previously wouldn't compile because the macros expanded to ambiguous expressions. Change-Id: I378c04d7aff5b4ad40581930ce90e49ba7df1d3e Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2719 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-14libpayload: Generalize and redistribute timekeeping codeGabe Black
The timekeeping code in libpayload was dependent on rdtsc, and when it was split up by arch, that code was duplicated even though it was mostly the same. This change factors out actually reading the count from the timer and the speed of the timer and puts the definitions of ndelay, udelay, mdelay and delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value functions which used to be in depthcharge were moved over to libpayload's arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those functions are omitted with the intention that they'll be implemented by a specific timer driver chosen elsewhere. Change-Id: I9c919bed712ace941f417c1d58679d667b2d8269 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2717 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14libpayload: Put dump_td/dump_ed in ohci.c behind #ifdef USB_DEBUGGabe Black
This function is static and not used in that file. To avoid the compiler complaining about that fact, put the two functions and the call to dump_ed (currently #if 0) behind #ifdef USB_DEBUG Change-Id: Ic373313b5fff81f09800f286b32238350ab699c6 Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2716 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-14libpayload: Don't declare the loop counter within the for loopGabe Black
'for' loop initial declarations are only allowed in C99 mode I didn't realize we don't enable 14 year old features when building libpayload, and I must have accidentally not rebuilt everything when making my final tweaks to my earlier change. Change-Id: I6caeeffad177b6d61fa30175f767e85084c061f4 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2718 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
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-13libpayload: Don't do unaligned accesses during LZMA decompressionGabe Black
Use memcpy to access a uint32_t that's inherently unaligned due to the layout of the LZMA header format. Built and booted on Daisy and saw a data abort go away. Built and booted into developer mode on Link and verified that bitmaps were decompressed/displayed correctly. Change-Id: Id3ae746c04d23bcb0345cb71797bfa219479cc8f Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2670 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Add size_t and ssize_t types for ARM and x86Gabe Black
Some new TPM drivers in depthcharge require that type. I added it to arch/types.h which seemed appropriate, but I'm not sure that's exactly the right header to use, or in other words if you'd get that type from libpayload the same way you'd get it if you were building a standard Linux program. Also, I attempted to determine what underlying types gcc would use, and while I think I picked the right ones I'm not 100% certain of that either. Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2669 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Move over to the payload's stack during startupGabe Black
Don't keep using the coreboot stack on ARMv7. Change-Id: I734c5d77f8584e30ee0c720d41e21e3040f56db4 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2668 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> 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-13libpayload: ARCH-$(CONFIG_ARCH_ARMV7) was defined twice, make one POWERPCGabe Black
Change-Id: Ia85a7cd6a0b85119cce6b2f9c42a7fc31ffd9f97 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2654 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Add usb_generic_(create|remove) functions for unrecognized devicesGabe Black
It might be useful to provide a USB driver in the payload itself instead of in libpayload. For example there are multiple payloads being built and linked against the same libpayload, and they might not need or even want to have the same set of drivers installed. This change adds two new functions, usb_generic_create and usb_generic_remove, which behave like the usbdisk_create and usbdisk_remove functions which are defined for USB mass storage devices. If a USB device isn't recognized and claimed by one of the built in USB class drivers (currently hub, hid, and msc) and the create function is defined, then it will be called to give the payload a chance to use the device. Once it's removed, if usb_generic_remove is defined it will be called, effectively giving the payload notice. Built and booted depthcharge on Link. Built depthcharge for Daisy. Built a netbooting payload, called usb_poll() with those functions implemented, and verified that they were called and that the devices they were told about were reasonable and the same as what was reported by lsusb in the booted system. Change-Id: Ief7c0a513b60849fbf2986ef4ae5c9e7825fef16 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2666 Tested-by: build bot (Jenkins) Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Split EHCI bulk transfers on packet boundaries over qTDsJulius Werner
EHCI controllers see transfers as a queue of transfer descriptors (qTDs), each of which can represent an aligned area of up to 20KB. Each qTD is processed separately, which means that a single USB packet cannot span multiple qTDs. While this should not be a problem according to the specification, some USB storage devices seem to get confused when a packet in the middle of a transfer is smaller than the maximum packet size (512 bytes) due to falling on a qTD boundary. This patch aligns the total transfer length per qTD to 512 bytes to avoid that problem (any excess bytes will simply roll over to the next qTD). Change-Id: I0b5db07507699a3861b30c1a5ee774c45dda7fdd Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/2651 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: add support for 64-bit EHCI controllersVincent Palatin
Initialize the high part of the address and use 64-bit compatible descriptors. (waste a few bytes on 32-bit but should be harmless) Read USB stick on a SandyBridge system which has 64-bit EHCI. Change-Id: I59cc842459acecdde8f8bdd4795ebfeccb842c8f Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2650 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Stub out time keeping functions for ARM as wellGabe Black
These were currently stubbed out for PowerPC but not for ARM. Change-Id: I08f45174877bf5751d972078b8c53d82898b7f2b Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2655 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: If no video drivers initialize in video_init, return 1.Gabe Black
Change-Id: I56f810dfa6654ac1e9d1696ad15e7f1b8bfe59bd Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2652 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-13libpayload: If there's no IO address space, don't try to use it for serialGabe Black
Change-Id: I01b1fa42139af925716cd5d57f96dc24da6df5a7 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2660 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: If there's no IO space, complain if the serial claims to use itGabe Black
Change-Id: I36c750d520ff034c9ca9b9af46bd99bd49af7355 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2659 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Consolidate io vs. mem mapped serial into accessor functionsGabe Black
This way we won't have two copies of the hardware init function, and three copies of the putchar, havechar, and getchar functions. Change-Id: Ifda7fec5d582244b0e163ee93ffeedeb28ce48da Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2657 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Make whether or not there's an IO address space configurableGabe Black
Default it to no to be consistent with the other architecture wide options (endianness), and turn it on explicitly for x86 and PowerPC. Change-Id: Idda26d580156bbbf08ea11b28abe75cfa6b594b2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2658 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13Update 3rdparty mark to latest repositoryStefan Reinauer
For google/stout binaries Change-Id: I4ef3f9cc35dfb6d27e1c9f074759f0e3ddee73c4 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2635 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13libpayload: Start using only internal and compiler headers.Ronald G. Minnich
When building other payloads with lpgcc the -nostdinc flag was injected into CFLAGS, but when building libpayload itself some headers were being used from the host system. This change puts -nostdinc into the Makefile and xcompile script, fixes up one include path in include/inttypes.h, adds the compiler provided include directory to the include search path, and deletes the two now redundant stdint.h files. BUG=None TEST=With this and other changes, built libpayload and depthcharge for Daisy, Link, and Fox. BRANCH=None Change-Id: Ia7817fceab5297cd82ccc0d392330de0df61980e Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2710 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-13libpayload: Add more parenthesis to the endian conversion macrosGabe Black
There weren't enough parenthesis in the macros so operations might only apply to the last part of an expression passed in as an argument. Change-Id: I5afb406f9409986e45bbbc598bcbd0dd8507ed35 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2665 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-13libpayload: Make the source for lzma decompression constGabe Black
Change-Id: I9a16331dedc97f17af94bf2cf535a9c93d1729a0 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2667 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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-13libpayloads: Provide BSD/glibc style endian functions.Hung-Te Lin
The functions in endian.h (betoh{l,w,ll} and others) were named differently from the well-known BSD/glibc style endian functions (ex, betoh{16,32,64}). We should provide the BSD/glibc style functions to prevent confusion. Change-Id: Ia3bee481ba7989ac25b79ddb89bc6819d52fd8c3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2705 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> 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>