.checkpatch.conf

@@ -20,6 +20,8 @@
 --ignore SPDX_LICENSE_TAG
 --ignore UNDOCUMENTED_DT_STRING
 --ignore PRINTK_WITHOUT_KERN_LEVEL
+--ignore ASSIGN_IN_IF
+--ignore UNNECESSARY_ELSE
 
 # FILE_PATH_CHANGES seems to not be working correctly. It will
 # choke on added / deleted files even if the MAINTAINERS file
@@ -30,5 +32,8 @@
 # some commits unnecessarily.
 --ignore EXECUTE_PERMISSIONS
 
-# Exclude the vendorcode directory
---exclude src/vendorcode
+# Exclude vendorcode directories that don't follow coreboot's coding style.
+--exclude src/vendorcode/amd
+--exclude src/vendorcode/cavium
+--exclude src/vendorcode/intel
+--exclude src/vendorcode/mediatek

CHANGELOG.md

@@ -13,6 +13,10 @@ Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
 
+## [v4.13.0.6] - 2021-04-29
+### Changed
+- rebased with official coreboot repository commit a4c09c5
+
 ## [v4.13.0.5] - 2021-04-07
 ### Changed
 - rebased with official coreboot repository commit e7a68ec
@@ -492,7 +496,8 @@ redundant code which was similar for APU2/3/5 boards.
 - turn off D4 and D5 leds on boot
 - enable power on after power failure
 
-[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.13.0.5...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.13.0.6...develop
+[v4.13.0.6]: https://github.com/pcengines/coreboot/compare/v4.13.0.5...v4.13.0.6
 [v4.13.0.5]: https://github.com/pcengines/coreboot/compare/v4.13.0.4...v4.13.0.5
 [v4.13.0.4]: https://github.com/pcengines/coreboot/compare/v4.13.0.3...v4.13.0.4
 [v4.13.0.3]: https://github.com/pcengines/coreboot/compare/v4.13.0.2...v4.13.0.3

Documentation/RFC/intel-gpio-cleanup.md

@@ -0,0 +1,98 @@
+# Background
+
+CB:31250 ("soc/intel/cannonlake: Configure GPIOs again after FSP-S is
+done") introduced a workaround in coreboot for `soc/intel/cannonlake`
+platforms to save and restore GPIO configuration performed by
+mainboard across call to FSP Silicon Init (FSP-S). This workaround was
+required because FSP-S was configuring GPIOs differently than
+mainboard resulting in boot and runtime issues because of
+misconfigured GPIOs. This issue was observed on `google/hatch`
+mainboard and was raised with Intel to get the FSP behavior
+fixed. Until the fix in FSP was available, this workaround was used to
+ensure that the mainboards can operate correctly and were not impacted
+by the GPIO misconfiguration in FSP-S.
+
+The issues observed on `google/hatch` mainboard were fixed by adding
+(if required) and initializing appropriate FSP UPDs. This UPD
+initialization ensured that FSP did not configure any GPIOs
+differently than the mainboard configuration. Fixes included:
+ * CB:31375 ("soc/intel/cannonlake: Configure serial debug uart")
+ * CB:31520 ("soc/intel/cannonlake: Assign FSP UPDs for HPD and Data/CLK of DDI ports")
+ * CB:32176 ("mb/google/hatch: Update GPIO settings for SD card and SPI1 Chip select")
+ * CB:34900 ("soc/intel/cnl: Add provision to configure SD controller write protect pin")
+
+With the above changes merged, it was verified on `google/hatch`
+mainboard that the workaround for GPIO reconfiguration was not
+needed. However, at the time, we missed dropping the workaround in
+'soc/intel/cannonlake`. Currently, this workaround is used by the
+following mainboards:
+ * `google/drallion`
+ * `google/sarien`
+ * `purism/librem_cnl`
+ * `system76/lemp9`
+
+As verified on `google/hatch`, FSP v1263 included all UPD additions
+that were required for addressing this issue.
+
+# Proposal
+
+* The workaround can be safely dropped from `soc/intel/cannonlake`
+  only after the above mainboards have verified that FSP-S does not
+  configure any pads differently than the mainboard in coreboot. Since
+  the fix included initialization of FSP UPDs correctly, the above
+  mainboards can use the following diff to check what pads change
+  after FSP-S has run:
+
+```
+diff --git a/src/soc/intel/common/block/gpio/gpio.c b/src/soc/intel/common/block/gpio/gpio.c
+index 28e78fb366..0cce41b316 100644
+--- a/src/soc/intel/common/block/gpio/gpio.c
++++ b/src/soc/intel/common/block/gpio/gpio.c
+@@ -303,10 +303,10 @@ static void gpio_configure_pad(const struct pad_config *cfg)
+                /* Patch GPIO settings for SoC specifically */
+                soc_pad_conf = soc_gpio_pad_config_fixup(cfg, i, soc_pad_conf);
+ 
+-               if (CONFIG(DEBUG_GPIO))
++               if (soc_pad_conf != pad_conf)
+                        printk(BIOS_DEBUG,
+-                       "gpio_padcfg [0x%02x, %02zd] DW%d [0x%08x : 0x%08x"
+-                       " : 0x%08x]\n",
++                       "%d: gpio_padcfg [0x%02x, %02zd] DW%d [0x%08x : 0x%08x"
++                       " : 0x%08x]\n", cfg->pad,
+                        comm->port, relative_pad_in_comm(comm, cfg->pad), i,
+                        pad_conf,/* old value */
+                        cfg->pad_config[i],/* value passed from gpio table */
+```
+
+Depending upon the pads that are misconfigured by FSP-S, these
+mainboards will have to set UPDs appropriately. Once this is verified
+by the above mainboards, the workaround implemented in CB:31250 can be
+dropped.
+
+* The fix implemented in FSP/coreboot for `soc/intel/cannonlake`
+  platforms is not really the right long term solution for the
+  problem. Ideally, FSP should not be touching any GPIO configuration
+  and letting coreboot configure the pads as per mainboard
+  design. This recommendation was accepted and implemented by Intel
+  starting with Jasper Lake and Tiger Lake platforms using a single
+  UPD `GpioOverride` that coreboot can set so that FSP does not change
+  any GPIO configuration. However, this implementation is not
+  backported to any older platforms. Given the issues that we have
+  observed across different platforms, the second proposal is to:
+
+  - Add a Kconfig `CHECK_GPIO_CONFIG_CHANGES` that enables checks
+    in coreboot to stash GPIO pad configuration before various calls
+    to FSP and compares the configuration on return from FSP.
+  - This will have to be implemented as part of
+    drivers/intel/fsp/fsp2_0/ to check for the above config selection
+    and make callbacks `gpio_snapshot()` and `gpio_verify_snapshot()`
+    to identify and print information about pads that have changed
+    configuration after calls to FSP.
+  - This config can be kept disabled by default and mainboard
+    developers can enable them as and when required for debug.
+  - This will be helpful not just for the `soc/intel/cannonlake`
+    platforms that want to get rid of the above workaround, but also
+    for all future platforms using FSP to identify and catch any GPIO
+    misconfigurations that might slip in to any platforms (in case the
+    `GpioOverride` UPD is not honored by any code path within FSP).
+

Documentation/community/forums.md

@@ -16,3 +16,20 @@ read its
 We also have a
 [real time chat](https://webchat.freenode.net?channels=%23coreboot)
 on the Freenode IRC network's #coreboot channel.
+
+## Fortnightly coreboot leadership meeting
+
+There's a leadership meeting held every 14 days (currently every other
+Wednesday at 10am Pacific Time, usually 18:00 UTC with some deviation
+possible due to daylight saving time related shifts). The meeting
+is open to everyone and provides a forum to discuss general coreboot
+topics, including community and technical matters that benefit from
+an official decision.
+
+We tried a whole lot of different tools, but so far the meetings worked
+best with [Google Meet](https://meet.google.com/syn-toap-agu),
+using [Google Docs](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit)
+for the agenda and meeting minutes. Neither the video conference nor
+the document require a Google account to participate, although editing
+access to the document is limited to adding comments - any desired
+agenda item added that way will be approved in time before the meeting.

Documentation/mainboard/lenovo/t420.md

@@ -18,6 +18,40 @@ the general [flashing tutorial].
 
 Steps to access the flash IC are described here [T4xx series].
 
+## Working
+ * CPU: Sandy Bridge i5-2520M, i7-2670QM
+ * RAM module combinations of 2G+0, 2G+2G, 4G+0
+ * mSATA
+ * USB
+ * Video (Intel integrated)
+ * Sound (integrated speakers, integrated mic, external headphones, external mic)
+ * LAN
+ * Mini-PCIe slots (WLAN)
+ * Bluetooth
+ * Linux
+ * Windows 10 (through SeaBIOS as payload, using a VGA BIOS)
+ * DVD-ROM drive
+ * SD card slot
+ * TrackPoint
+ * Touchpad
+ * Webcam
+ * Fn hotkeys (backlight control, thinklight)
+ * Thinklight
+ * Mute button (Speaker only)
+ * Mini Jack audio (headphones)
+ * Suspend (Linux)
+
+## Not tested
+ * DSub (VGA) out
+ * DisplayPort out
+ * eSATA
+ * ExpressCard
+ * WWAN
+
+## Not working/TODOs
+ * Mutemic button doesn't mute
+ * Suspend (Windows 10)
+
 [T4xx series]: t4xx_series.md
 [flashing tutorial]: ../../flash_tutorial/ext_power.md
 [T420 / T520 / X220 / T420s / W520 common]: Sandy_Bridge_series.md

Documentation/mainboard/ocp/deltalake.md

@@ -1,8 +1,7 @@
 # OCP Delta Lake
 
 This page describes coreboot support status for the [OCP] (Open Compute Project)
-Delta Lake server platform. This page is updated following each 4-weeks
-build/test/release cycle.
+Delta Lake server platform.
 
 ## Introduction
 
@@ -12,22 +11,23 @@ Yosemite-V3. Both were announced by Facebook and Intel in [OCP virtual summit 20
 Delta Lake server is a single socket Cooper Lake Scalable Processor (CPX-SP) server.
 
 Yosemite-V3 has multiple configurations. Depending on configurations, it may
-host up to 4 Delta Lake servers in one sled.
+host up to 4 Delta Lake servers (blades) in one sled.
 
-The Yosemite-V3 program is in PVT phase. Facebook, Intel and partners
-jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative
-solution. This development reached EVT exit equivalent status.
+The Yosemite-V3 system is in mass production. Facebook, Intel and partners
+jointly develop Open System Firmware (OSF) solution on Delta Lake as an alternative
+solution. The OSF solution is based on FSP/coreboot/LinuxBoot stack. The
+OSF solution reached DVT exit equivalent status.
 
 ## Required blobs
 
-This board currently requires:
+Delta Lake server OSF solution requires:
 - FSP blob: The blob (Intel Cooper Lake Scalable Processor Firmware Support Package)
-  is not yet available to the public. It will be made public some time after the MP
-  (Mass Production) of CPX-SP.
+  is not yet available to the public. It will be made public soon by Intel 
+  with redistributable license.
 - Microcode: Available through github.com:otcshare/Intel-Generic-Microcode.git.
-- ME binary: Ignition binary will be made public some time after the MP
-  of CPX-SP.
-- ACM binaries: only required for CBnT enablement.
+- ME binary: Ignition binary will be made public soon by Intel with
+  redistributable license.
+- ACM binaries: only required for CBnT enablement. Available under NDA with Intel.
 
 ## Payload
 - LinuxBoot: This is necessary only if you use LinuxBoot as coreboot payload.
@@ -61,13 +61,13 @@ VPD variables supported are:
 - bmc_bootorder_override: When it's set to 1 IPMI OEM command can override boot
   order. The boot order override is done in the u-root LinuxBoot payload.
 - systemboot_log_level: u-root package systemboot log levels, would be mapped to
-  quiet/verbose in systemboot as that is all we have for now. 5 to 8 would be mapped
-  to verbose, 0 to 4 and 9 would be mapped to quiet.
-- DeltaLake specific VPDs: check mb/ocp/deltalake/vpd.h.
+  quiet/verbose in systemboot as that is all we have for now. 5 to 8 would be
+  mapped to verbose, 0 to 4 and 9 would be mapped to quiet.
+- VPDs affecting coreboot are listed/documented in src/mainboard/ocp/deltalake/vpd.h.
 
 ## Working features
-The solution is developed using LinuxBoot payload with Linux kernel 5.2.9, and [u-root]
-as initramfs.
+The solution is developed using LinuxBoot payload with Linux kernel 5.2.9,
+and [u-root] as initramfs.
 - SMBIOS:
     - Type 0 -- BIOS Information
     - Type 1 -- System Information
@@ -96,11 +96,14 @@ as initramfs.
     - TPM
     - Bootguard profile 0T
     - TXT
-    - SRTM (verified through tboot)
-    - memory secret clearance upon ungraceful shutdown
+    - SRTM
+    - DRTM (verified through tboot)
+		- unsigned KM/BPM generation
+		- KM/BPM signing
+		- memory secret clearance upon ungraceful shutdown
 - Early serial output
 - port 80h direct to GPIO
-- ACPI tables: APIC/DMAR/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
+- ACPI tables: APIC/DMAR/DSDT/EINJ/FACP/FACS/HEST/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
 - Skipping memory training upon subsequent reboots by using MRC cache
 - BMC crash dump
 - Error injection through ITP
@@ -109,13 +112,13 @@ as initramfs.
     - Check Microcode version: cat /proc/cpuinfo | grep microcode
 - Devices:
     - Boot drive
-    - NIC card
     - All 5 data drives
+    - NIC card
 - Power button
 - localboot
 - netboot from IPv6
-- basic memory hardware error injection/detection (SMI handler not upstreamed)
-- basic PCIe hardware error injection/detection (SMI handler not upstreamed)
+- basic memory hardware error injection/detection (SMI handlers not upstreamed)
+- basic PCIe hardware error injection/detection (SMI handlers not upstreamed)
 
 ## Stress/performance tests passed
 - OS warm reboot (1000 cycles)
@@ -125,27 +128,32 @@ as initramfs.
 - StressAppTest (6 hours)
 - Ptugen (6 hours)
 
-## Performance tests on par with traditional firmware
+## Performance on par with traditional firmware
 - coremark
-- SpecCPU
-- Linkpack
-- Iperf(IPv6)
 - FIO
+- Iperf(IPv6)
+- Linpack
+- Intel MLC (memory latency and bandwidth)
+- SpecCPU
+- stream
 
 ## Other tests passed
 - Power
 - Thermal
+- coreboot address sanitizer (both romstage and ramstage)
+- Intel selftest tool (all errors analyzed; applicable errors clean)
 
 ## Known issues
-- MLC (Intel Memory Latency Check) and stream performance issue
 - HECI access at OS run time:
     - spsInfoLinux64 command fail to return ME version
     - ptugen command fail to get memory power
+- CLTT (Closed Loop Thermal Throttling, eg. thermal protection for DIMMs)
+- ProcHot (thermal protection for processors)
 
 ## Feature gaps
 - flashrom command not able to update ME region
-- ACPI APEI tables
-- PCIe hotplug, Virtual Pin Ports
+- ACPI BERT table
+- PCIe hotplug through VPP (Virtual Pin Ports)
 - PCIe Live Error Recovery
 - RO_VPD region as well as other RO regions are not write protected
 - Not able to selectively enable/disable core

Documentation/mainboard/supermicro/flashing_on_vendorbmc.md

@@ -30,3 +30,15 @@ You can use the *SMCIPMITool* to remotely flash the BIOS:
 
 Make sure that the ME isn't in recovery mode, otherwise you get an error
 message on updating the BIOS.
+
+## Flashing with disabled ME
+
+If ME is disabled via `me_cleaner` or the ME recovery jumper, it is still
+possible to flash remotely with the [`Supermicro Update Manager`](SUM) (`SUM`).
+
+```sh
+./sum -i <remote BMC IP> -u <user> -p <password> -c UpdateBios --reboot \
+  --force_update --file build/coreboot.rom
+```
+
+[SUM]: https://www.supermicro.com/SwDownload/SwSelect_Free.aspx?cat=SUM

Documentation/soc/qualcomm/index.md

@@ -5,3 +5,4 @@ This section contains documentation about coreboot on specific Qualcomm SOCs.
 ## Platforms
 
 - [SC7180 series](sc7180/index.md)
+- [SC7280 series](sc7280/index.md)

Documentation/soc/qualcomm/sc7280/index.md

@@ -0,0 +1,17 @@
+# Qualcomm SC7280 documentation
+
+## SOC code
+
+The SOC folder contains functions for:
+* MMU
+* CLOCK
+* GPIO
+* QUPv3 FW (provides a bridge to serial interfaces)
+* UART
+* SPI-NOR
+* AOP FW
+* USB
+
+## Notes about the hardware
+
+The timer is used from the ARMv8 architecture specific code.