GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/Documentation/releases/coreboot-4.13-relnotes.md

62 lines
3.1 KiB
Markdown
Raw Normal View History

Documentation/releases: Update for 4.12 Fill in some blanks for 4.12, mark it done, add template for 4.13. Also update the list of vboot supported boards. Change-Id: Id6b663f13367eb40e66af30aadd33991c8dd635c Signed-off-by: Patrick Georgi <patrick@georgi.software> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-11 23:46:35 +02:00
Upcoming release - coreboot 4.13
================================
The 4.13 release is planned for November 2020.
Update this document with changes that should be in the release notes.
* Please use Markdown.
* See the past few release notes for the general format.
* The chip and board additions and removals will be updated right
before the release, so those do not need to be added.
Significant changes
-------------------
Documentation: Add section about 'hidden' devices to 4.13 release notes CB:41384 (SHA dbcf7b16219df0c04401b8fcd6a780174a7df305) added some new functionality to devicetree files ("hidden PCI devices"). It's a decent enough semantic change that it should be added to the release notes for the 4.13 release. Change-Id: I52969f63dbc492afd32279176cbcfc2b76d7ac33 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41563 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-20 18:05:08 +02:00
### Hidden PCI devices
This new functionality takes advantage of the existing 'hidden' keyword in the
devicetree. Since no existing boards were using the keyword, its usage was
repurposed to make dealing with some unique PCI devices easier. The particular
case here is Intel's PMC (Power Management Controller). During the FSP-S run,
the PMC device is made hidden, meaning that its config space looks as if there
is no device there (Vendor ID reads as 0xFFFF_FFFF). However, the device does
have fixed resources, both MMIO and I/O. These were previously recorded in
different places (MMIO was typically an SA fixed resource, and I/O was treated
as an LPC resource). With this change, when a device in the tree is marked as
'hidden', it is not probed (`pci_probe_dev()`) but rather assumed to exist so
that its resources can be placed in a more natural location. This also adds the
ability for the device to participate in SSDT generation.
Documentation: Add section about SPD tools for TGL and JSL CB:41612 added a new set of tools for generating SPDs for TGL and JSL based mainboards. This change adds relevant documentation to coreboot-4.13 release notes. Change-Id: I168adad25df9195dec64e8104f2dbe992eebddc6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42092 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-05 09:31:21 +02:00
### Tools for generating SPDs for LP4x memory on TGL and JSL
A set of new tools `gen_spd.go` and `gen_part_id.go` are added to automate the
process of generating SPDs for LP4x memory and assigning hardware strap IDs for
memory parts used on TGL and JSL based boards. The SPD data obtained from memory
part vendors has to be massaged to format it correctly as per JEDEC and Intel MRC
expectations. These tools take a list of memory parts describing their physical
attributes as per their datasheet and convert those attributes into SPD files for
the platforms. More details about the tools are added in
[README.md](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/spd_tools/intel/lp4x/README.md).
cpu/x86/smm: Introduce SMM module loader version 2 Xeon-SP Skylake Scalable Processor can have 36 CPU threads (18 cores). Current coreboot SMM is unable to handle more than ~32 CPU threads. This patch introduces a version 2 of the SMM module loader which addresses this problem. Having two versions of the SMM module loader prevents any issues to current projects. Future Xeon-SP products will be using this version of the SMM loader. Subsequent patches will enable board specific functionality for Xeon-SP. The reason for moving to version 2 is the state save area begins to encroach upon the SMI handling code when more than 32 CPU threads are in the system. This can cause system hangs, reboots, etc. The second change is related to staggered entry points with simple near jumps. In the current loader, near jumps will not work because the CPU is jumping within the same code segment. In version 2, "far" address jumps are necessary therefore protected mode must be enabled first. The SMM layout and how the CPUs are staggered are documented in the code. By making the modifications above, this allows the smm module loader to expand easily as more CPU threads are added. TEST=build for Tiogapass platform under OCP mainboard. Enable the following in Kconfig. select CPU_INTEL_COMMON_SMM select SOC_INTEL_COMMON_BLOCK_SMM select SMM_TSEG select HAVE_SMI_HANDLER select ACPI_INTEL_HARDWARE_SLEEP_VALUES Debug console will show all 36 cores relocated. Further tested by generating SMI's to port 0xb2 using XDP/ITP HW debugger and ensured all cores entering and exiting SMM properly. In addition, booted to Linux 5.4 kernel and observed no issues during mp init. Change-Id: I00a23a5f2a46110536c344254868390dbb71854c Signed-off-by: Rocky Phagura <rphagura@fb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-21 23:48:48 +02:00
### New version of SMM loader
A new version of the SMM loader which accomodates platforms with over 32 CPU
CPU threads. The existing version of SMM loader uses a 64K code/data
segment and only a limited number of CPU threads can fit into one segment
(because of save state, STM, other features, etc). This loader extends beyond
the 64K segment to accomodate additional CPUs and in theory allows as many
CPU threads as possible limited only by SMRAM space and not by 64K. By default
this loader version is disabled. Please see cpu/x86/Kconfig for more info.
Documentation: Update release notes for x86_64 Change-Id: I7d8d39bde3b3364ff6ce93030aa2bab34598acd8 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44781 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2020-08-25 20:59:59 +02:00
### Initial support for x86_64
The x86_64 code support has been revived and enabled for qemu. While it started
as PoC and the only supported platform is an emulator, there's interest in
enabling additional platforms. It would allow to access more than 4GiB of memory
at runtime and possibly brings optimised code for faster execution times.
It still needs changes in assembly, fixed integer to pointer conversions in C,
wrappers for blobs, support for running Option ROMs, among other things.
Documentation/releases: Update for 4.12 Fill in some blanks for 4.12, mark it done, add template for 4.13. Also update the list of vboot supported boards. Change-Id: Id6b663f13367eb40e66af30aadd33991c8dd635c Signed-off-by: Patrick Georgi <patrick@georgi.software> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-11 23:46:35 +02:00
### Add significant changes here