summaryrefslogtreecommitdiff
path: root/src/drivers
AgeCommit message (Collapse)Author
2016-07-31Remove extra newlines from the end of all coreboot files.Martin Roth
This removes the newlines from all files found by the new int-015-final-newlines script. Change-Id: I65b6d5b403fe3fa30b7ac11958cc0f9880704ed7 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/15975 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-31intel/wifi: Include conditionally in the buildKyösti Mälkki
Keep this enabled by default as most x86 platforms could have PCI-e slots equipped with one of these Intel WiFi adapters. The Kconfig entries under google boards had no function previously, the variable was never referenced. Change-Id: I728ce3fd83d51d4e5e32b848a2079c5fcee29349 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15931 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2016-07-28drivers/intel/fsp2_0: Update the copyrightsLee Leahy
Update the copyright dates in the FSP 2.0 files. Add a copyright to Kconfig. TEST=Build and run on Galileo Gen2 Change-Id: I0ad0c5650bde0e31d01a04bcc7d22a19273fe29b Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15852 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-07-28intel/fsp1_1: Add C entry support to locate FSP Temp RAM InitSubrata Banik
FSP temp ram init was getting called earlier from ROMCC bootblock. Now with C entry boot block, it is needed to locate FSP header and call FspTempRamInit. Hence add fsp 1_1 driver code to locate FSP Temp ram and execute. BUG=chrome-os-partner:55357 BRANCH=none TEST=Built kunimitsu and ensure FSP Temp Ram Init return success Change-Id: If40b267777a8dc5c473d1115b19b98609ff3fd74 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/15787 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-28i2c/ww_ring: Add ww_ring files to ramstageFurquan Shaikh
These files are required by storm and gale boards for enabling elog support in ramstage. BUG=chrome-os-partner:55639 Change-Id: I2bbfee2acf2bfe2f896a8619b1276dcea1b87f16 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15893 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-07-28bootmode: Get rid of CONFIG_BOOTMODE_STRAPSFurquan Shaikh
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and developer mode check functions to vboot. Thus, get rid of the BOOTMODE_STRAPS option which controlled these functions under src/lib. BUG=chrome-os-partner:55639 Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15868 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-27drivers/intel/fsp2_0: Update MRC cache with dead version in recoveryFurquan Shaikh
If the system is in recovery, store the newly generated MRC data using a dummy version which is not legit. This ensures that on next normal boot, new MRC data will be generated and stored. BUG=chrome-os-partner:55699 Change-Id: Ib13e8c978dc1b4fc8817fab16d0e606f210f2586 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15828 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-27cpu/x86: Support CPUs without rdmsr/wrmsr instructionsLee Leahy
Quark does not support the rdmsr and wrmsr instructions. In this case use a SOC specific routine to support the setting of the MTRRs. Migrate the code from FSP 1.1 to be x86 CPU common. Since all rdmsr/wrmsr accesses are being converted, fix the build failure for quark in lib/reg_script.c. Move the soc_msr_x routines and their depencies from romstage/mtrr.c to reg_access.c. TEST=Build and run on Galileo Gen2 Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15839 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-26drivers/intel/fsp2_0/header_util: Convert UPD headersLee Leahy
Convert the FSP 2.0 UPD headers from typedef to struct: * FSP_UPD_HEADER * FSPM_ARCH_UPD TEST=Build and run on Galileo Gen2 Change-Id: Iab241ea07c955e95ff988a4a30103d2a112179b6 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15856 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-26drivers/elog: put back 4KiB limitAaron Durbin
The removal of ELOG_FLASH_BASE and ELOG_FLASH_SIZE resulted in the FMAP region for the eventlog to be honored. However, certain systems seem to have a large eventlog region that wasn't being used in practice. Because of the malloc() in the eventlog init sequence a large allocation was now being requested that can exhaust the heap. Put back the 4KiB capacity until the resource usage is fixed. BUG=chrome-os-partner:55593 Change-Id: Ib54b396b48e5be80f737fc3feb0d58348c0d2844 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15835 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-26drivers/intel/fsp2_0: Enable XIP romstage with loaded FSP-MLee Leahy
Separate NO_XIP_EARLY_STAGES from loading FSP-M into cache-as-RAM. Quark executes romstage directly from the SPI flash part (in-place), but loads FSP-M into ESRAM. This split occurs because ESRAM is too small to hold everything while debugging. Platforms executing FSP-M directly from the SPI flash need to select FSP_M_XIP. TEST=Build and run on Galileo Gen2. Change-Id: Ib5313ae96dcec101510e82438b1889d315569696 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15848 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-25drivers/uart: Enable debug serial output during postcarLee Leahy
Build the UART drivers for the postcar stage. TEST=Build and run on Galileo Gen2 Change-Id: I8bf51135ab7e62fa4bc3e8d45583f2feac56942f Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15843 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-24drivers/elog: remove elog Kconfig variablesAaron Durbin
Now that FMAP is a first class citizen in coreboot there's no reason to have alternate locations for ELOG. If one wants eventlog support they need to specify the ELOG entry in the FMAP. The one side effect is that the code was previously limiting the size to 4KiB because the default ELOG_AREA_SIZE was 4KiB. However, that's no longer the case as the FMAP region size is honored. Change-Id: I4ce5f15032387155d2f56f0de61f2d85271ba606 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15814 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2016-07-19drivers/intel/fsp2_0: Split reset handling logicAndrey Petrov
FSP 2.0 spec only defines 2 reset request (COLD, WARM) exit codes. The rest 6 codes are platform-specific and may vary. Modify helper function so that only basic resets are handled and let SoC deal with the rest. Change-Id: Ib2f446e0449301407b135933a2088bcffc3ac32a Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/15730 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-07-19drivers/intel/fsp2_0: handle reset requests from FSPSAaron Durbin
The FSPS component can request resets. Handle those generically. BUG=chrome-os-partner:52679 Change-Id: I41c2da543420102d864e3c5e039fed13632225b4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15748 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-19drivers/intel/fsp2_0: handle reset requests from FSPMAaron Durbin
The FSPM component can request resets. Properly handle those. BUG=chrome-os-partner:52679 Change-Id: If21245443761cb993e86c0e383c8bca87f460a85 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15747 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-07-19drivers/intel/fsp2_0: range check stack provided to FSPMAaron Durbin
Ensure that the stack provided to FSPM doesn't overlap the current program which is loading the FSPM component. If there is a conflict that's an error since it could cause the current program to crash. BUG=chrome-os-partner:52679 Change-Id: Ifff465266e5bb3cb3cf9b616d322a46199f802c7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15746 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-07-19drivers/intel/fsp2_0: don't use saved memory data in recovery modeAaron Durbin
If the system is in recovery mode force a full retrain. BUG=chrome-os-partner:52679 Change-Id: I4e87685600880d815fe3198b820a10aa269baf37 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15745 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-07-19drivers/intel/fsp2_0: honor FSP revision for memory training dataAaron Durbin
Utilizing the FSP revision while saving the memory training data is important because it means when the FSP is updated the memory training is redone. The previous implementation was just using '0' as a revision. Because of that behavior a retrain would not have been done on an FSP upgrade. BUG=chrome-os-partner:52679 Change-Id: I1430bd78c770a840d2deff2476f47150c02cf27d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15744 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-19drivers/intel/fsp2_0: remove unused fsp_load_binary()Aaron Durbin
Remove the now unused fsp_load_binary() function. BUG=chrome-os-partner:52679 Change-Id: I5667eb71689a69a9e05f7be05cb0c7e7795a55d3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15743 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-19drivers/intel/fsp2_0: load and relocate FSPS in cbmemAaron Durbin
The FSPS component loading was just loading to any memory address listed in the header. That could be anywhere in the address space including ramstage itself -- let alone corrupting the OS memory on S3 resume. Remedy this by loading and relocating FSPS into cbmem. The UEFI 2.4 header files include path are selected to provide the types necessary for FSP relocation. BUG=chrome-os-partner:52679 Change-Id: Iaba103190731fc229566a3b0231cf967522040db Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15742 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: John Zhao <john.zhao@intel.com>
2016-07-19drivers/intel/fsp2_0: handle XIP and non-XIP for FSPM componentAaron Durbin
The previously implementation for loading the FSPM component didn't handle platforms which expects FSPM to be XIP. For the non-XIP case, romstage's address space wasn't fully being checked for overlaps. Lastly, fixup the API as the range_entry isn't needed any longer. This API change requires a apollolake to be updated as well. BUG=chrome-os-partner:52679 Change-Id: I24d0c7d123d12f15a8477e1025bf0901e2d702e7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15741 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-19drivers/intel/fsp2_0: separate component validation from loadingAaron Durbin
The current FSP component loading mechanism doesn't handle all the requirements actually needed. Two things need to be added: 1. XIP support for MemoryInit component 2. Relocating SiliconInit component to not corrupt OS memory. In order to accommodate those requirements the validation and header initialization needs to be a separate function. Therefore, provide fsp_validate_component() to help achieve those requirements. BUG=chrome-os-partner:52679 Change-Id: I53525498b250033f3187c05db248e07b00cc934d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15740 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-19drivers/intel/fsp2_0: implement common memory_init() tasksAaron Durbin
Instead of performing the same tasks in the chipset code move the common sequences into the FSP 2.0 driver. This handles the S3 paths as well as saving and restoring the memory data. The chipset code can always override the settings if needed. BUG=chrome-os-partner:52679 Change-Id: I098bf95139a0360f028a50aa50d16d264bede386 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15739 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-19drivers/intel/fsp2_0: set BootLoaderTolumSize genericallyAaron Durbin
The amount of reserved memory just below the DRAM limit in 32-bit space is defined in the FSP 2.0 specification within the FSPM_ARCH_UPD structure. There's no need to make the chipset code set the same value as needed for coreboot. The chipset code can always change the value if it needs after the common setting being applied. Remove the call in soc/intel/apollolake as it's no longer needed. BUG=chrome-os-partner:52679 Change-Id: I69a1fee7a7b53c109afd8ee0f03cb8506584d571 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15738 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-07-19drivers/intel/fsp2_0: fix hand-off-block types and sizeAaron Durbin
The gcc compiler treats sizeof(void) == 1. Therefore requesting a 1 byte reservation in cbmem and writing a pointer into the buffer returned is wrong. Fix the size of the request to be 32-bits because FSP 2.0 is in 32-bit space by definition. Also, since the access to the field happens across stage boundaries it's important to ensure fixed widths are used in case a later stage has a different pointer bit width. BUG=chrome-os-partner:52679 Change-Id: Ib4efc7d5369d44a995318aac6c4a7cfdc73e4a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15737 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-18elog: Use rdev_mmap to find offset of ELOGFurquan Shaikh
In case of elog not being stored in CBMEM, calculate flash offset by using rdev_mmap instead of assuming that the entire flash is mapped just below 4GiB. This allows custom mappings of flash to correctly convert the flash offset to mmap address. BUG=chrome-os-partner:54186 TEST=Verified behavior on reef. mosys able to read out the elog correctly. Change-Id: I3eacd2c9266ecc3da1bd45c86ff9d0e8153ca3f2 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15722 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-15drivers/intel/fsp1_1: align on using ACPI_Sx definitionsAaron Durbin
The SLEEP_STATE_x definitions in the chipsets utilizing FSP 1.1. driver have the exact same values as the ACPI_Sx definitions. The chipsets will be moved over subsequently, but updating this first allows the per-chipset patches to be isolated. BUG=chrome-os-partner:54977 Change-Id: I383a9a732ef68bf2276f6149ffa5360bcdfb70b3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15665 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com>
2016-07-14drivers/i2c: Add new driver for RTC type PCF8523Werner Zeh
This driver enables the usage of an external RTC chip PCF8523 which is connected to the I2C bus. The I2C address of this device is fixed. One can change parameters in device tree so that the used setup can be adapted in device tree to match the configuration of the device on the mainboard. Change-Id: I2d7e161c9e12b720ec4925f1acfd1dd8ee6ee5f5 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/15641 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-07-12tpm: report firmware versionVadim Bendebury
Some devices allow to retrieve firmware version by reading the same 4 byte register repeatedly until the entire version string is read. Let's print out TPM firmware version when available. Just in case something goes wrong limit the version string length to 200 bytes. CQ-DEPEND=CL:355701 BRANCH=none BUG=chrome-os-partner:54723 TEST=built the new firmware and ran it on Gru, observed the following in the coreboot console log: Connected to device vid:did:rid of 1ae0:0028:00 Firmware version: cr50_v1.1.4792-7a44484 Original-Commit-Id: 1f54a30cebe808abf1b09478b47924bb722a0ca6 Original-Change-Id: Idb069dabb80d34a0efdf04c3c40a42ab0c8a3f94 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/355704 Original-Reviewed-by: Scott Collyer <scollyer@chromium.org> Squashed with: tpm: use 4 byte quantities when retrieving firmware version The CR50 device is capable of reporting its firmware version in 4 byte quantities, but the recently introduced code retrieves the version one byte at a time. With this fix the version is retrieved in 4 byte chunks. BRANCH=none BUG=none TEST=the version is still reported properly, as reported by the AP firmware console log: localhost ~ # grep cr50 /sys/firmware/log Firmware version: cr50_v1.1.4804-c64cf24 localhost ~ # Original-Commit-Id: 3111537e7b66d8507b6608ef665e4cde76403818 Original-Change-Id: I04116881a30001e35e989e51ec1567263f9149a6 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/356542 Original-Reviewed-by: Andrey Pronin <apronin@chromium.org> Change-Id: Ia9f13a5bf1c34292b866f57c0d14470fe6ca9853 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15573 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-07-11tpm: use proper locality zero SPI bus addressesVadim Bendebury
The "PC Client Protection Profile for TPM 2.0" document defines SPI bus addresses for different localities. That definition is not honored in the cr50 implementation, this patch fixes it: locality zero register file is based off 0xd40000. BRANCH=none BUG=chrome-os-partner:54720 TEST=with the fixed cr50 image and the rest of TPM2 initialization patches applied factory initialization sequence on Gru succeeds. Change-Id: I49b7ed55f0360448b9a6602ebd31a3a531608da3 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 43344fff5d58ec235e50030413fc38c98dd0a9a1 Original-Change-Id: I2de6fa6c05d3eca989d6785228d5adde1f2a7ab7 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/355620 Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://review.coreboot.org/15568 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-07-10intel post-car: Consolidate choose_top_of_stack()Kyösti Mälkki
Change-Id: I2c49d68ea9a8f52737b6064bc4fa703bdb1af1df Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15463 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-08drivers/i2c/da7219: Add driver for generating device in SSDTDuncan Laurie
Add a device driver to generate the device and required properties into the SSDT. This driver uses the ACPI Device Property interface to generate the required parameters into the _DSD table format expected by the kernel. This was tested on the reef mainboard to ensure that the SSDT contained the equivalent parameters that are provided by the current DSDT object. Change-Id: Ia809e953932a7e127352a7ef193974d95e511565 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/15538 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-08acpi: Change device properties to work as a treeDuncan Laurie
There is a second ACPI _DSD document from the UEFI Forum that details how _DSD style tables can be nested, creating a tree of similarly formatted tables. This document is linked from acpi_device.h. In order to support this the device property interface needs to be more flexible and build up a tree of properties to write all entries at once instead of writing each entry as it is generated. In the end this is a more flexible solution that can support drivers that need child tables like the DA7219 codec, while only requiring minor changes to the existing drivers that use the device property interface. This was tested on reef (apollolake) and chell (skylake) boards to ensure that there was no change in the generated SSDT AML. Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/15537 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-06siemens/nc_fpga: Add driver for Siemens NC FPGAWerner Zeh
Add driver code to initialize Siemens NC FPGA as PCI device. Beside some glue logic it contains a FAN controller and temperature monitor. Change-Id: I2cb722a60081028ee5a8251f51125f12ed38d824 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/15543 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-07-05intel/i210: Change API for function mainboard_get_mac_address()Werner Zeh
The function mainboard_get_mac_address() is used to get a MAC address for a given i210 PCI device. Instead of passing pure numbers for PCI bus, device and function pass the device pointer to this function. In this way the function can retrieve the needed values itself as well as have the pointer to the device tree so that PCI path can be evaluated there. Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/15516 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-07-02drivers/generic/max98357a: Fix naming and ACPI path handlingDuncan Laurie
The upstream kernel driver is not using the of-style naming for sdmode-gpio so remove the maxim prefix, and remove the duplicate entry for the sdmode-delay value as well. Also fix the usage of the path variable, since the device path uses a static variable it can't be assigned that early or it will be overwritten by later calls. This results in the following output for the _DSD when tested on reef mainboard: Name (_DSD, Package (0x02) { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") Package (0x02) { Package (0x02) { "sdmode-gpio", Package (0x04) { \_SB.PCI0.HDAS.MAXM, Zero, Zero, Zero } }, Package (0x02) { "sdmode-delay", Zero } } }) Change-Id: Iab33182a5f64c89151966f5e79f4f7c30840c46f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/15514 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-29intel romstage: Use run_ramstage()Kyösti Mälkki
Change-Id: I22a33e6027a4e807f7157a0dfafbd6377bc1285d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15461 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-24drivers/intel/fsp2_0: Add simple reset handlerAndrey Petrov
Any FSP API call may request a reset. This is indicated in API function return code. Add trivial reset handler code. BUG=chrome-os-partner:54149 BRANCH=none TEST=none Change-Id: Ieb5e2d52ffdaf3c3ed416603f6dbb4f9c25a1a7b Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/15334 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-23kconfig: add missing SPI TPM CS config definitionVadim Bendebury
To fully define TPM attachment to a SPI interface both bus and CS (chip select) settings are required. Add the missing CS configuration option. BRANCH=none BUG=chrome-os-partner:50645 TEST=with the rest of the patches applied it is possible to compile in and run TPM2 SPI driver. Change-Id: If297df8e5b9526f156ed1414eb9db317d6af5b33 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/353913 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15299 Tested-by: build bot (Jenkins) Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-06-23tpm2: add SPI TPM driverVadim Bendebury
This introduces a SPI TPM driver compliant with the TCG issued "TPM Profile (PTP) Specification Revision 00.43" which can be found by googling its title. The driver implements both the hardware flow control protocol and the TPM state machine. The hardware flow control allows to map SPI based TPM devices to the LPC address space on x86 platforms, on all other platforms it needs to be implemented in the driver software. The tis layer is somewhat superficial, it might have to be expanded later. A lot more implementation details can be found in the code comments. Also, it is worth mentioning that this is not a complete version of the driver: its robustness needs to be improved, delay loops need to be bound, error conditions need to propagate up the call stack. BRANCH=none BUG=chrome-os-partner:52132, chrome-os-partner:50645, chrome-os-partner:54141 TEST=with the rest of the patches applied coreboot is able complete Chrome OS factory initialization of the TPM2 device. Change-Id: I967bc5c689f6e6f345755f08cb088ad37abd5d1c Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5611c6f7d7fe6d37da668f337f0e70263913d63e Original-Change-Id: I17d732e66bd231c2289ec289994dd819c6276855 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/350124 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15298 Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com> Tested-by: build bot (Jenkins)
2016-06-23kconfig: allow various tpm type and interface permutationsVadim Bendebury
Until now it was assumed that all TPM devices were of the same type (TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs and all other boards had I2C connected TPMs. With the advent of TPM2 specification there is a need to be able to configure different combinations of TPM types (TPM or TPM2) and interfaces (LPC, I2C and SPI). This patch allows to do it. Picking Chrome OS still assumes that the board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's Kconfig will trigger including of TPM2 instead. MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding SPI_TPM to the board config switches interface choice to SPI, and if neither of the two is defined, the interface is assumed to be I2C. BRANCH=none BUG=chrome-os-partner:50645 TEST=verified that none of the generated board configurations change as a result of this patch. With the rest of the stack in place it is possible to configure different combinations of TPM types and interfaces for ARM and x86 boards. Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1 Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349850 Original-Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15294 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-06-22drivers/i2c/generic: Fix compile failureDuncan Laurie
This variable name was changed in chip.h but not the consumer and it was submitted before it was caught. Change-Id: I7c492b588b2fd854a9eeac36029a46da324a7b1b Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/15109 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-06-22Ignore RAMTOP for MTRRsKyösti Mälkki
Without RELOCATABLE_RAMSTAGE have WB cache large enough to cover the greatest ramstage needs, as there is no benefit of trying to accurately match the actual need. Choose this to be bottom 16MiB. With RELOCATABLE_RAMSTAGE write-back cache of low ram is only useful for bottom 1MiB of RAM as a small part of this gets used during SMP initialisation before proper MTRR setup. Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15249 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-17Fix some cbmem.h includesKyösti Mälkki
Change-Id: I36056af9f2313eff835be805c8479e81d0b742bf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15196 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-06-14drivers/intel/fsp2_0: Add FSP return types for resetAndrey Petrov
FSP methods may require reset under certain conditions. That is indicated by returning specific return code. Add the missing return status codes. BUG=chrome-os-partner:54149 BRANCH=none TEST=none Change-Id: I460353c5f835548a98255bd3e11dbfd08260ea52 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/15185 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-06-09soc/intel/apollolake: Update FSP header filesBora Guvendik
Update autogenerated FSP 2.0 generic header files based on FSP release 136_30. Changes were made to avoid duplicating some of the structs for every SoC. BUG=chrome-os-partner:50765 TEST=Build coreboot Change-Id: I6f3c9270fb67210d6ea87e17ccf52d203fa64b4b Signed-off-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-on: https://chromium.devtools.intel.com/7145 Reviewed-by: Petrov, Andrey <andrey.petrov@intel.com> Tested-by: Petrov, Andrey <andrey.petrov@intel.com> Reviewed-on: https://chromium.devtools.intel.com/7584 Reviewed-on: https://review.coreboot.org/15081 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-08drivers/intel/fsp2.0: Add semantic patch for FspUpdVpd.h headerAlexandru Gagniuc
Previous FSP implementations in coreboot have included FspUpdVpd.h directly, along with with efi headers. Instead of taking that approach in FSP 2.0, we provide a semantic patch that, with minimal modifications, makes FspUpdVpd.h easier to include in coreboot, and eliminates reliance on external headers and definitions. Change-Id: I0c2a6f7baf6fb50ae22b64e08e653cfe1aefdaf9 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/13331 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-03drivers/intel/fsp1_1: Make weak routines quietLee Leahy
Now that there is a better way of finding optional routines, make the weak routines quiet so that it may be used for the optional implementation. TEST=Build and run on Galileo Gen2 Change-Id: Ic58c7de216394f80aee3a78dd08bd4682783be42 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15043 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-03Add Board Checklist SupportLee Leahy
Build the <board>_checklist.html file which contains a checklist table for each stage of coreboot. This processing builds a set of implemented (done) routines which are marked green in the table. The remaining required routines (work-to-do) are marked red in the table and the optional routines are marked yellow in the table. The table heading for each stage contains a completion percentage in terms of count of routines (done .vs. required). Add some Kconfig values: * CREATE_BOARD_CHECKLIST - When selected creates the checklist file * MAKE_CHECKLIST_PUBLIC - Copies the checklist file into the Documenation directory * CHECKLIST_DATA_FILE_LOCATION - Location of the checklist data files: * <stage>_complete.dat - Lists all of the weak routines * <stage>_optional.dat - Lists weak routines which may be optionally implemented TEST=Build with Galileo Gen2. Change-Id: Ie056f8bb6d45ff7f3bc6390b5630b5063f54c527 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15011 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 20:03:23 +0000