Docs/releases: Update coreboot-4.18 release notes

Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5cf38463e44f9abaadb4dc47dbf48ef0f0514bc9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>

Documentation/releases/coreboot-4.18-relnotes.md

@@ -1,29 +1,128 @@
-Upcoming release - coreboot 4.18
+Upcoming release - coreboot 4.18 release
-================================
+========================================================================
 
-The 4.18 release is planned for August 2022.
+The 4.18 release is quite late, but is now planned for October 16, 2022.
 
-Update this document with changes that should be in the release notes.
+In the past 4 months since the 4.17 release, the coreboot project has
+merged more than 1800 commits from over 200 different authors. Over 50
+of those authors submitted their first patches.
 
-* Please use Markdown.
+Welcome and thank you to all of our new contributors, and of course the
-* See the past few release notes for the general format.
+work of all of the seasoned contributors is greatly appreciated.
-* The chip and board additions and removals will be updated right
-  before the release, so those do not need to be added.
 
-Significant changes
--------------------
 
-### Add significant changes here
+Significant or interesting changes
-### edk2 (Tianocore)
+----------------------------------
+
+### sconfig: Allow to specify device operations
+
+Currently we only have runtime mechanisms to assign device operations to
+a node in our devicetree (with one exception: the root device). The most
+common method is to map PCI IDs to the device operations with a `struct
+pci_driver`. Another accustomed way is to let a chip driver assign them.
+
+For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI
+ID lists grew very large and are incredibly error-prone. Often, IDs are
+missing and sometimes IDs are added almost mechanically without checking
+the code for compatibility. Maintaining these lists in a central place
+also reduces flexibility.
+
+Now, for onboard devices it is actually unnecessary to assign the device
+operations at runtime. We already know exactly what operations should be
+assigned. And since we are using chipset devicetrees, we have a perfect
+place to put that information.
+
+This patch adds a simple mechanism to `sconfig`. It allows us to speci-
+fy operations per device, e.g.
+
+device pci 00.0 alias system_agent on
+	ops system_agent_ops
+end
+
+The operations are given as a C identifier. In this example, we simply
+assume that a global `struct device_operations system_agent_ops` exists.
+
+
+### Set touchpads to use detect (vs probed) flag
+
+Historically, ChromeOS devices have worked around the problem of OEMs
+using several different parts for touchpads/touchscreens by using a
+ChromeOS kernel-specific 'probed' flag (rejected by the upstream kernel)
+to indicate that the device may or may not be present, and that the
+driver should probe to confirm device presence.
+
+Since release 4.18, coreboot  supports detection for i2c devices at
+runtime when creating the device entries for the ACPI/SSDT tables,
+rendering the 'probed' flag obsolete for touchpads. Switch all touchpads
+in the tree from using the 'probed' flag to the 'detect' flag.
+
+Touchscreens require more involved power sequencing, which will be done
+at some future time, after which they will switch over as well.
+
+
+### Add SBOM (Software Bill of Materials) Generation
+
+Firmware is typically delivered as one large binary image that gets
+flashed. Since this final image consists of binaries and data from a
+vast number of different people and companies, it's hard to determine
+what all the small parts included in it are. The goal of the software
+bill of materials (SBOM) is to take a firmware image and make it easy to
+find out what it consists of and where those pieces came from.
+
+Basically, this answers the question, who supplied the code that's
+running on my system right now? For example, buyers of a system can use
+an SBOM to perform an automated vulnerability check or license analysis,
+both of which can be used to evaluate risk in a product. Furthermore,
+one can quickly check to see if the firmware is subject to a new
+vulnerability included in one of the software parts (with the specified
+version) of the firmware.
+
+Further reference:
+https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
+
+- Add Makefile.inc to generate and build coswid tags
+- Add templates for most payloads, coreboot, intel-microcode,
+  amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
+  intel ME and compiler (gcc,clang,other)
+- Add Kconfig entries to optionally supply a path to CoSWID tags
+  instead of using the default CoSWID tags
+- Add CBFS entry called SBOM to each build via Makefile.inc
+- Add goswid utility tool to generate SBOM data
+
+
+Additional coreboot changes
+---------------------------
+
+The following are changes across a number of patches, or changes worth
+noting, but not needing a full description.
+
+* Allocator v4 is not yet ready, but received significant work.
+* Console: create an [smbus console driver](https://doc.coreboot.org/technotes/console.html)
+* pciexp_device: Numerous updates and fixes
+* Update checkpatch to match Linux v5.19
+* Continue updating ACPI to ASL 2.0 syntax
+* arch/x86: Add a common romstage entry point
+* Documentation: Add a list of [acronyms](https://doc.coreboot.org/acronyms.html)
+* Start hooking up ops in devicetree
+* Large amounts of general code cleanup and improvement, as always
+* Work to make sure all files have licenses
+
+
+Payloads
+--------
+
+### EDK II (TianoCore)
+
 coreboot uses TianoCore interchangeably with EDK II, and whilst the
-meaning is generally clear, it's not the payload it uses. Consequentially,
+meaning is generally clear, it's not the payload it uses.
-Tianocore has been renamed to EDK II (2).
+Consequentially, TianoCore has been renamed to EDK II (2).
 
 The option to use the already deprecated CorebootPayloadPkg has been
 removed.
 
-Recent changes to both coreboot and edk2 means that UefiPayloadPkg
+Recent changes to both coreboot and EDK means that UefiPayloadPkg seems
-seems to work on all hardware. It has been tested on:
+to work on all hardware. It has been tested on:
+
 * Intel Core 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, 8th, 9th, 10th,
   11th and 12th generation processors
 * Intel Small Core BYT, BSW, APL, GLK and GLK-R processors
@@ -34,39 +133,58 @@ CorebootPayloadPkg can still be found [here](https://github.com/MrChromebox/edk2
 The recommended option to use is `EDK2_UEFIPAYLOAD_MRCHROMEBOX` as
 `EDK2_UEFIPAYLOAD_OFFICIAL` will no longer work on any SoC.
 
+
+New Mainboards
+--------------
+
+* AMD Birman
+* AMD Pademelon renamed from Padmelon
+* Google Evoker
+* Google Frostflow
+* Google Gaelin4ADL
+* Google Geralt
+* Google Joxer
+* Google Lisbon
+* Google Magikarp
+* Google Morthal
+* Google Pujjo
+* Google Rex 0
+* Google Shotzo
+* Google Skolas
+* Google Tentacruel
+* Google Winterhold
+* Google Xivu
+* Google Yaviks
+* Google Zoglin
+* Google Zombie
+* Google Zydron
+* MSI PRO Z690-A WIFI DDR4
+* Siemens MC APL7
+
+
+Removed Mainboards
+------------------
+
+* Google Brya4ES
+
+
+Updated SoCs
+------------
+
+* Added Intel Meteor Lake
+* Added Mediatek Mt8188
+* Renamed AMD Sabrina to Mendocino
+* Added AMD Morgana
+
+
 Plans for Code Deprecation
 --------------------------
 
-
-### Intel Icelake
-
-Intel Icelake code will be removed with the release 4.19. This consists
-of the Intel Icelake SoC and Intel Icelake RVP mainboard.
-
-Intel Icelake is unmaintained. Also, the only user of this platform ever
-was the Intel CRB (Customer Reference Board). From the looks of it the
-code was never ready for production as only engineering sample CPUIDs are
-supported. This reduces the maintanence overhead for the coreboot project.
-
-
-### Intel Quark
-
-The SoC Intel Quark is unmaintained and different efforts to revive it failed.
-Also, the only user of this platform ever was the Galileo board.
-
-Thus, to reduce the maintanence overhead for the community, it is deprecated
-from this release on and support for the following components will be dropped
-with the release 4.20.
-
-  * Intel Quark SoC
-  * Intel Galileo mainboard
-
-
 ### LEGACY_SMP_INIT
 
 Legacy SMP init will be removed from the coreboot master branch
 immediately following this release. Anyone looking for the latest
-version of the code should find it on the 4.18 branch.
+version of the code should find it on the 4.18 branch or tag.
 
 This also includes the codepath for SMM_ASEG. This code is used to start
 APs and do some feature programming on each AP, but also set up SMM.
@@ -75,3 +193,44 @@ cover all use cases of LEGACY_SMP_INIT, with little code changes. The
 reason for deprecation is that having 2 codepaths to do the virtually
 the same increases maintenance burden on the community a lot, while also
 being rather confusing.
+
+
+### Intel Icelake SoC & Icelake RVP mainboard
+
+Intel Icelake is unmaintained. Also, the only user of this platform ever
+was the Intel CRB (Customer Reference Board). From the looks of it the
+code was never ready for production as only engineering sample CPUIDs
+are supported. This reduces the maintanence overhead for the coreboot
+project.
+
+Intel Icelake code will be removed with release 4.19 and any maintenence
+will be done on the 4.19 branch. This consists of the Intel Icelake SoC
+and Intel Icelake RVP mainboard.
+
+
+### Intel Quark SoC & Galileo mainboard
+
+The SoC Intel Quark is unmaintained and different efforts to revive it
+failed.  Also, the only user of this platform ever was the Galileo
+board.
+
+Thus, to reduce the maintanence overhead for the community, support for
+the following components will be removed from the master branch and will
+be maintained on the release 4.20 branch.
+
+  * Intel Quark SoC
+  * Intel Galileo mainboard
+
+
+Statistics
+----------
+
+- Total Commits: 1819
+- Average Commits per day: 13.44
+- Total lines added: 150195
+- Average lines added per commit: 82.57
+- Number of patches adding more than 100 lines: 127
+- Average lines added per small commit: 38.38
+- Total lines removed: 33788
+- Average lines removed per commit: 18.58
+- Total difference between added and removed: 116407