summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2020-05-28lib: Add strtok() and strtok_r()harshit
Add strtok() and strtok_r() to the library. Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com> Change-Id: Ic855b31669be1c274cbf247c53ffa6f74ec5bf35 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2020-05-28device: Enable resource allocation above 4G boundary with allocator v4Furquan Shaikh
This change adds back CB:39487 which was reverted as part of CB:41412. Now that the resource allocator is split into old(v3) and new(v4), this change adds support for allocating resources above 4G boundary with the new allocator v4. Original commit message: This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-28Remove new additions of "this file is part of" linesElyes HAOUAS
Change-Id: I6c69dcad82ee217ed4760dea1792dd1a6612cd8b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-26device: Move resource allocation into a separate compilation unitFurquan Shaikh
This change moves the resource allocator functions out of device.c and into two separate files: 1. resource_allocator_v3.c: This is the old implementation of resource allocator that uses a single window for resource allocation. It is required to support some AMD chipsets that do not provide an accurate map of allocated resources by the time the allocator runs. They work fine with the old allocator since it restricts itself to allocations in a single window at the top of the 4G space. 2. resource_allocator_common.c: This file contains the functions that can be shared by the old and new resource allocator. Entry point into the resource allocation is allocate_resources() which can be implemented by both old and new allocators. This change also adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old resource allocator. This config option is enabled by default currently, but in the following CLs this will be enabled only for the broken boards. Reason for this split: Both the old and new resource allocators need to be retained in the tree until the broken chipsets are fixed. Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki
After removal of CAR_MIGRATION there are no more reasons to carry around ENV_STAGE_HAS_BSS_SECTION=n case. Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit zero-initializers. Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-22drivers/soundwire/alc5682: Support Realtek ALC5682 SoundWire deviceDuncan Laurie
The ALC5682 headset codec can be connected over SoundWire and be configured for mainboards to use: - Data Port 0 and Bulk Register Access is supported - Data Ports 1-4 are supported as both source and sink The data port and audio mode properties are filled out as best as possible with the datasheet as a reference. The ACPI address for the codec is calculated with the information in the codec driver combined with the devicetree.cb hierarchy where the link and unique IDs are extracted from the device path. For example this device is connected to master link ID 0 and has strap settings configuring it for unique ID 1: chip drivers/soundwire/alc5682 register "desc" = ""Headset Codec"" device generic 0.1 on end end This driver was tested with the volteer reference design by booting and disassembling the runtime SSDT to ensure that the devices have the expected address and properties. Device (SW01) { Name (_ADR, 0x000021025D568200) Name (_DDN, "Headset Codec") Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-sw-interface-revision", 0x00010000 }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-bra-mode-0", "BRA0" }, Package () { "mipi-sdw-dp-0-subproperties", "DP0" }, Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }, Package () { "mipi-sdw-dp-1-source-subproperties", "SRC1" }, Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" }, [...] } } Name (BRA0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-bra-mode-bus-frequency-configs", Package () { 0x000F4240, [...] } }, [...] } } Name (DP0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-bra-flow-controlled", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-bra-mode-0", "BRA0" } } } Name (MOD0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-audio-mode-bus-frequency-configs", Package () { 0x000F4240, [...] } }, [...] } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } } BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I488dcd81d2e66a6f2c269ab7fa9f7ceaf2cbf003 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40891 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-22drivers/soundwire/max98373: Support MAX98373 SoundWire deviceDuncan Laurie
The MAX98373 smart speaker amp can be connected over SoundWire and be configured for mainboards to use: - Data Port 0 and Bulk Register Access is not supported - Data Port 1 is the 32bit data input for the speaker path - Data Port 3 is the 16bit data output for I/V sense ADC path The data port and audio mode properties are filled out as best as possible with the datasheet as a reference. The ACPI address for the codec is calculated with the information in the codec driver combined with the devicetree.cb hierarchy where the link and unique IDs are extracted from the device path. For example this device is connected to master link ID 1 and has strap settings configuring it for unique ID 3. chip drivers/soundwire/max98373 register "desc" = ""Left Speaker Amp"" device generic 1.3 on end end This driver was tested with the volteer reference design by booting and disassembling the runtime SSDT to ensure that the devices have the expected address and properties. Device (SW13) { Name (_ADR, 0x000123019F837300) Name (_DDN, "Left Speaker Amp") Method (_STA) { Return (0x0F) } Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-sw-interface-revision", 0x00010000 }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }, Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" }, Package () { "mipi-sdw-dp-3-source-subproperties", "SRC3" }, } } Name (MOD0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-audio-mode-bus-frequency-configs", Package () { 0x00753000, [...] } }, [...] } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } Name (SRC3, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } } BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I3f8cb2779ddde98c5df739bd8a1e83a12a305c00 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40890 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-05-21acpi/device: Add a helper function to write SoundWire _ADRDuncan Laurie
This change adds a help function to write a SoundWire ACPI address object that conforms to the SoundWire DisCo Specification Version 1.0 The SoundWire address structure is defined in include/device/soundwire.h and provides the properties that are used to form the _ADR object. BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I6efbf52ce20b53f96d69efe2bf004b98dbe06552 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40885 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-21acpi/soundwire: Add functions to generate SoundWire propertiesDuncan Laurie
This change uses the previously added SoundWire definitions to provide functions that generate ACPI Device Properties for SoundWire controllers and codecs. A SoundWire controller driver should populate `struct soundwire_controller` and pass it to soundwire_gen_controller(). This will add all of the defined master links provided by the controller. A SoundWire codec driver should populate the necessary members in struct soundwire_codec and pass it to soundwire_gen_codec(). Several properties are optional and depend on whether the codec itself supports certain features and behaviors. The goal of this interface is to handle all of the properties defined in the SoundWire Discovery and Configuration Specification Version 1.0 so that controller and codec drivers do not need to all have code for writing standard properties. Both of these functions also provide a callback method for adding custom properties that are not defined by the SoundWire DisCo Specification. These properties may be required by OS drivers but are outside of the scope of the SoundWire specification itself. This code is tested with controller, codec, and mainboard implementations in subsequent commits. BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: Ib185eaacf3c4914087497ed65479a772c155502b Reviewed-on: https://review.coreboot.org/c/coreboot/+/40884 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-05-19device: Add definitions for SoundWire specificationDuncan Laurie
This header implements structures to describe the properties defined in the SoundWire Discovery and Configuration Specification Version 1.0. By itself this just provides the property definitions, it is then used by the code that generates ACPI device properties and by the controller and codec drivers. A new header for MIPI vendor/device IDs is also added, with the MIPI Alliance board members added by default. This will be used in the same way as pci_ids.h to track devices added to coreboot. BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: Ie9901d26d1efe68edad7c049c98a976c4e4f06f4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-05-16Revert "device: Enable resource allocation above 4G boundary"Furquan Shaikh
This reverts commit 44ae0eacb82259243bf844a3fe5ad24a7821e997. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. BUG=b:149186922 Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-13lib/spd_cache: add spd_cache common codeJamie Chen
This patch adds some spd_cache functions. They are for implementing the spd_cache. It's for reducing the SPD fetch time when device uses SODIMMs. The MRC cache also includes SPD data, but there is no public header file available to decode the struct of MRC. So SPD cache is another solution. BUG=b:146457985 BRANCH=None TEST=Build puff successfully and verified below two items. one DIMM save the boot time : 158ms two DIMM save the boot time : 265ms Change-Id: Ia48aa022fabf8949960a50597185c9d821399522 Signed-off-by: Jamie Chen <jamie.chen@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
2020-05-13lib/spd_bin: add get_spd_sn functionJamie Chen
This patch adds the get_spd_sn function. It's for reading SODIMM serial number. In spd_cache implementation it can use to get serial number before reading whole SPD by smbus. BUG=b:146457985 BRANCH=None TEST=Wrote sample code to get the serial number and ran on puff. It can get the serial number correctly. Change-Id: I406bba7cc56debbd9851d430f069e4fb96ec937c Signed-off-by: Jamie Chen <jamie.chen@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40414 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-13Remove new additions of "this file is part of" linesFurquan Shaikh
CB:41194 got rid of "this file is part of" lines. However, there are some changes that landed right around the same time including those lines. This change uses the following command to drop the lines from new files: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ic3c1d717416f6b7e946f84748e2b260552c06a1b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41342 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12util/sconfig: Add LPC and ESPI busesRaul E Rangel
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both be active at the same time. This adds a way to specify which devices belong on which bus. i.e., device pci 14.3 on # - D14F3 bridge device espi 0 on chip ec/google/chromeec device pnp 0c09.0 on end end end device lpc 0 on end end BUG=b:154445472 TEST=Built trembyle and saw static.c contained the espi bus. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12southbridge/intel/common: Add Process CallChristian Walter
Add functionality to use process call cycle. It can be used to write/read data to/from e.g. EEPROM attached to SMBus Controller via I2C. Tested on: * C246 Change-Id: Ifdac6cf70a4ce744601f5d152a83d2125ea88360 Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39875 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12device/pci_device: Extract pci_domain_set_resources from SOCRaul E Rangel
pci_domain_set_resources is duplicated in all the SOCs. This change promotes the duplicated function. Picasso was adding it again in the northbridge patch. I decided to promote the function instead of duplicating it. BUG=b:147042464 TEST=Build and boot trembyle. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12espi: Add support for debug helper to print slave capabilitiesFurquan Shaikh
This change adds a Kconfig option to enable eSPI debugging that pulls in a helper function to print slave capabilities. BUG=b:153675913 Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I8ff250fe85dfa9370bf93ce3c7e2de5c069bf9e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41254 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12espi: Add some helper functions for espi capability checkFurquan Shaikh
This change adds helper functions that can be used to check support for different slave capabilities. BUG=b:153675913 Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ic66b06f9efcafd0eda4c6029fa67489de76bbed4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41253 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-12espi: Add definitions for eSPI VW index messsagesFurquan Shaikh
This change adds eSPI VW index message definitions as per per Enhanced Serial Peripheral Interface Base Specification (document # 327432-004 Revision 1.0) Chapter 5 "Transaction Layer". BUG=b:153675913 Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I5c04d4de222e16d3b8e2a5fb2fc4107ea278a35b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41252 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12espi: Add definitions for eSPI slave registersFurquan Shaikh
This change adds eSPI slave register definitions as per Enhanced Serial Peripheral Interface Base Specification (document # 327432-004 Revision 1.0) Chapter 7 "Slave Registers". BUG=b:153675913 Change-Id: Icee53817476b7d50ff26e64bbc2c3f5afb19a7cd Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41071 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-05-12device: Enable resource allocation above 4G boundaryFurquan Shaikh
This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. BUG=b:149186922 TEST=Verified that resources get allocated above the 4G boundary correctly on volteer. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-08memrange: Update comment to indicate limit is inclusive for memranges_next_entryFurquan Shaikh
This change updates the comment for memranges_next_entry() to indicate that the limit provided by the caller is inclusive. Change-Id: Id40263efcb9417ed31c130996e56c30dbbc82e02 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41103 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-07memrange: constify memranges_is_empty()Aaron Durbin
memranges_is_empty() doesn't need to manipulate the object. Mark the parameter as const. Change-Id: I89f4ec404c144eac8d2900945a1ccaf5cc4f88bb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41102 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-06treewide: replace GPLv2 long form headers with SPDX headerPatrick Georgi
This replaces GPLv2-or-later and GPLv2-only long form text with the short SPDX identifiers. Commands used: perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-06treewide: move copyrights and authors to AUTHORSPatrick Georgi
Also split "this is part of" line from copyright notices. Change-Id: Ibc2446410bcb3104ead458b40a9ce7819c61a8eb Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41067 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-06treewide: Move "is part of the coreboot project" line in its own commentPatrick Georgi
That makes it easier to identify "license only" headers (because they are now license only) Script line used for that: perl -i -p0e 's|/\*.*\n.*This file is part of the coreboot project.*\n.*\*|/* This file is part of the coreboot project. */\n/*|' # ...filelist... Change-Id: I2280b19972e37c36d8c67a67e0320296567fa4f6 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41065 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-06elog: Add new elog types for CSME-initiated host resetderek.huang
Change-Id: Iddae1c7cbc71ce10b126a1e05abf9269e8187a38 Signed-off-by: derek.huang <derek.huang@intel.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40687 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-02acpi: Update sata files to be more aligned with rest of acpi filesFurquan Shaikh
This change moves sata.h to include/acpi/acpi_sata.h to align with the rest of the acpi header files in include/acpi. BUG=b:155428745 Change-Id: I3f97e5c12535a331d7347c0ecad00b07b5f13f37 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-05-02acpi: Make header #ifdefs consistentFurquan Shaikh
Now that all ACPI header files are moved to src/include/acpi, this change updates the #ifdef to __ACPI_${FILENAME}__. BUG=b:155428745 Change-Id: Id24ee35bac318278871a26f98be7092604de01c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40931 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-02acpi: Move ACPI table support out of arch/x86 (3/5)Furquan Shaikh
This change moves all ACPI table support in coreboot currently living under arch/x86 into common code to make it architecture independent. ACPI table generation is not really tied to any architecture and hence it makes sense to move this to its own directory. In order to make it easier to review, this change is being split into multiple CLs. This is change 3/5 which basically is generated by running the following command: $ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g' BUG=b:155428745 Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-02acpi: Move ACPI table support out of arch/x86 (2/5)Furquan Shaikh
This change moves all ACPI table support in coreboot currently living under arch/x86 into common code to make it architecture independent. ACPI table generation is not really tied to any architecture and hence it makes sense to move this to its own directory. In order to make it easier to review, this change is being split into multiple CLs. This is change 2/5 which moves the contents of arch/x86/include/arch/acpi*.h files into include/acpi/acpi*.h and updates the arch header files to include acpi header files. These are just temporary placeholders and will be removed later in the series. BUG=b:155428745 Change-Id: I9acb787770b7f09fd2cbd99cb8d0a6499b9c64b3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40937 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-02cpu: Add a helper function cpu_get_lapic_addrFurquan Shaikh
This change adds a helper function cpu_get_lapic_addr() that returns LOCAL_APIC_ADDR for x86. It also adds a weak default implementation which returns 0 if platform does not support LAPIC. This is being done in preparation to move all ACPI table support in coreboot out of arch/x86. BUG=b:155428745 Change-Id: I4d9c50ee46804164712aaa22be1b434f800871ec Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40929 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-05-01include/device/device.h: Include <smbios.h>Elyes HAOUAS
smbios_slot_{type,data_width,length,designation} used for smbios_type_9 needs "smbios.h" Also use already defined 'smbios_type11' in "smbios.h". This will also include <smbios.h> in "static.c" file, this we can remove indirect includes of <smbios.h> in "chip.h" Change-Id: Id412a504da2fd75648636febd150356569e07935 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40310 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-29device/pci_id: Add Tiger Lake TCSS device IDJohn Zhao
Add Tiger Lake TCSS USB xHCI, xDCI and Thunderbolt DMA device ID. BUG=None TEST=Built and booted image sucessfully. Change-Id: Idef3850666c9f393181e0a13974b9ad79ba258ad Signed-off-by: John Zhao <john.zhao@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40693 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Caveh Jalali <caveh@chromium.org> Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
2020-04-29arch/x86: Implement RESET_VECTOR_IN_RAMFelix Held
Add support for devices with the reset vector pointing into DRAM. This is a specific implementation that assumes a paradigm of AMD Family 17h (a.k.a. "Zen"). Until the first ljmpl for protected mode, the core's state appears to software like other designs, and then the actual physical addressing becomes recognizable. These systems cannot implement cache-as-RAM as in more traditional x86 products. Therefore instead of reusing CAR names and variables, a substitute called "earlyram" is introduced. This change makes adjustments to CAR-aware files accordingly. Enable NO_XIP_EARLY_STAGES. The first stage is already in DRAM, and running subsequent stages as XIP in the boot device would reduce performance. Finally, add a new early_ram.ld linker file. Because all stages run in DRAM, they can be linked with their .data and .bss as normal, i.e. they don't need to rely on storage available only at a fixed location like CAR systems. The primary purpose of the early_ram.ld is to provide consistent locations for PRERAM_CBMEM_CONSOLE, TIMESTAMP regions, etc. across stages until cbmem is brought online. BUG=b:147042464 TEST=Build for trembyle, and boot to ramstage. $ objdump -h cbfs/fallback/bootblock.debug Idx ,Name ,Size ,VMA ,LMA ,File off Algn 0 ,.text ,000074d0 ,08076000 ,08076000 ,00001000 2**12 1 ,.data ,00000038 ,0807d4d0 ,0807d4d0 ,000084d0 2**2 2 ,.bss ,00000048 ,0807d508 ,0807d508 ,00008508 2**2 3 ,.stack ,00000800 ,0807daf0 ,0807daf0 ,00000000 2**0 4 ,.persistent ,00001cfa ,0807e2f0 ,0807e2f0 ,00000000 2**0 5 ,.reset ,00000010 ,0807fff0 ,0807fff0 ,0000aff0 2**0 6 ,.debug_info ,0002659c ,00000000 ,00000000 ,0000b000 2**0 7 ,.debug_abbrev ,000074a2 ,00000000 ,00000000 ,0003159c 2**0 8 ,.debug_aranges,00000dd0 ,00000000 ,00000000 ,00038a40 2**3 9 ,.debug_line ,0000ad65 ,00000000 ,00000000 ,00039810 2**0 10 ,.debug_str ,00009655 ,00000000 ,00000000 ,00044575 2**0 11 ,.debug_loc ,0000b7ce ,00000000 ,00000000 ,0004dbca 2**0 12 ,.debug_ranges ,000029c0 ,00000000 ,00000000 ,00059398 2**3 Change-Id: I9c084ff6fdcf7e9154436f038705e8679daea780 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35035 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-29src/cpu/x86/mtrr/earlymtrr: Add clear_all_var_mtrrRaul E Rangel
Picasso does not define the state of variable MTRRs on boot. Add a helper function to clear all MTRRs. BUG=b:147042464 TEST=Build trembyle Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I21b887ce12849a95ddd8f1698028fb6bbfb4a7f6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40764 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to acpi_inject_dsdtFurquan Shaikh
.acpi_inject_dsdt() does not need to modify the device structure. Hence, this change makes the struct device * parameter to acpi_inject_dsdt as const. Change-Id: I3b096d9a5a9d649193e32ea686d5de9f78124997 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40711 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to acpi_fill_ssdt()Furquan Shaikh
.acpi_fill_ssdt() does not need to modify the device structure. This change makes the struct device * parameter to acpi_fill_ssdt() as const. Change-Id: I110f4c67c3b6671c9ac0a82e02609902a8ee5d5c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40710 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to dev_nameFurquan Shaikh
dev_name() does not need to modify the device structure. Hence, this change makes the struct device * parameter to dev_name() as const. Change-Id: I6a94394385e45fd76f68218bf57914bddd2e2121 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40703 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to write_acpi_tablesFurquan Shaikh
.write_acpi_tables() should not be updating the device structure. This change makes the struct device * argument to it as const. Change-Id: I50d013e83a404e0a0e3837ca16fa75c7eaa0e14a Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40701 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-04-28amd/family17h: Add PCI device IDs for all controllers in AMD Family17hFurquan Shaikh
This change adds all the missing PCI device IDs for AMD Family 17h. IDs that were already present are updated to include _FAM17H_ in the name instead of _PCO_ and _DALI_. This ensures that the PCI IDs match the family and models as per the PPR. In cases where the controller is present only on certain models, _MODEL##H_ is also included in the name. BUG=b:153858769 BRANCH=None TEST=Verified that trembyle and dalboz still build. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ia767d32ec22f5e58827e7531c0d3d3bac90d3425 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40673 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-04-28soc/amd: Update macro name for IOMMU on AMD Family 17hFurquan Shaikh
IOMMU for AMD Family 17h Model 10-20h uses the same PCI device ID 0x15D1. This change updates the name to indicate that the PCI device ID is supported for FP5(Model 18h) and FT5(Model 20h). BUG=b:153858769 BRANCH=None TEST=Trembyle and dalboz still build. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I17c782000ed525075a3e438ed820a22d9af61a26 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40672 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-04-28soc/intel/jasperlake: Add new MCH device idsMaulik V Vaghela
Add new MCH device-ids for jasperlake. Reference is taken from jasperlake EDS volume 1 chapter 13.3. BUG=None BRANCH=None TEST=code compiles and able to boot the platform. Change-Id: I38e09579c9a3681e9168c66085cbb3a092dc30cc Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40589 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Reviewed-by: V Sowmya <v.sowmya@intel.com> Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
2020-04-28security/lockdown: Write-protect WP_ROPatrick Rudolph
Allow to write protect only the WP_RO region in case of enabled VBOOT. One can either lock the boot device in VERSTAGE early if VBOOT is enabled, or late in RAMSTAGE. Both options have their downsides as explained below. Lock early if you don't trust the code that's stored in the writeable flash partition. This prevents write-protecting the MRC cache, which is written in ramstage. In case the contents of the MRC cache are corrupted this can lead to system instability or trigger unwanted code flows inside the firmware. Lock late if you trust the code that's stored in the writeable flash partition. This allows write-protecting the MRC cache, but if a vulnerability is found in the code of the writeable partition an attacker might be able to overwrite the whole flash as it hasn't been locked yet. Change-Id: I72c3e1a0720514b9b85b0433944ab5fb7109b2a2 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32705 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2020-04-28security: Add common boot media write protectionPatrick Rudolph
Introduce boot media protection settings and use the existing boot_device_wp_region() function to apply settings on all platforms that supports it yet. Also remove the Intel southbridge code, which is now obsolete. Every platform locks the SPIBAR in a different stage. For align up with the common mrc cache driver and lock after it has been written to. Tested on Supermicro X11SSH-TF. The whole address space is write-protected. Change-Id: Iceb3ecf0bde5cec562bc62d1d5c79da35305d183 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32704 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-04-25include/device/azalia: Add enums and MACROsPatrick Rudolph
Instead of only using magic values add enums and defines to allow writing the codec init sequence in human readable form. This will replace the magic numbers in mainboards HDA verb tables. Change-Id: Icad07c2b550657b879ad9328a70ba44629a0c939 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39694 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-04-23rules.h: Rename ENV_VERSTAGE to ENV_SEPARATE_VERSTAGEJulius Werner
When CONFIG_SEPARATE_VERSTAGE=n, all verstage code gets linked into the appropriate calling stage (bootblock or romstage). This means that ENV_VERSTAGE is actually 0, and instead ENV_BOOTBLOCK or ENV_ROMSTAGE are 1. This keeps tripping up people who are just trying to write a simple "are we in verstage (i.e. wherever the vboot init logic runs)" check, e.g. for TPM init functions which may run in "verstage" or ramstage depending on whether vboot is enabled. Those checks will not work as intended for CONFIG_SEPARATE_VERSTAGE=n. This patch renames ENV_VERSTAGE to ENV_SEPARATE_VERSTAGE to try to clarify that this macro can really only be used to check whether code is running in a *separate* verstage, and clue people in that they may need to cover the linked-in verstage case as well. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I2ff3a3c3513b3db44b3cff3d93398330cd3632ea Reviewed-on: https://review.coreboot.org/c/coreboot/+/40582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-22device: Add helper function to find matching device on busFurquan Shaikh
This change adds a helper function dev_find_matching_device_on_bus() which scans all the child devices on the given bus and calls a match function provided by the caller. It returns the first device that the match function returns true for, else NULL if no such device is found. Change-Id: I2e3332c0a175ab995c523f078f29a9f498f17931 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40543 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 00:22:46 +0000