From d15bda4fab01977eb8d7de3aad6bd3d02261a291 Mon Sep 17 00:00:00 2001 From: Martin Roth Date: Fri, 30 Dec 2022 16:13:19 -0700 Subject: [PATCH] Docs/releases: Update 4.17 & 4.18 notes to remove RESOURCE_ALLOCATOR_V3 This removal was announced in 4.16, but didn't make it into the 4.17 or 4.18 release notes. Those platforms have now been removed. Signed-off-by: Martin Roth Change-Id: I35607a86242c37e1578874b3a79ff0387a55b146 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71581 Tested-by: build bot (Jenkins) Reviewed-by: Felix Singer --- .../releases/coreboot-4.17-relnotes.md | 30 +++++++++++++++++++ .../releases/coreboot-4.18-relnotes.md | 30 +++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/Documentation/releases/coreboot-4.17-relnotes.md b/Documentation/releases/coreboot-4.17-relnotes.md index 1f868838eb..eb136f42fc 100644 --- a/Documentation/releases/coreboot-4.17-relnotes.md +++ b/Documentation/releases/coreboot-4.17-relnotes.md @@ -296,6 +296,36 @@ noting, but not needing a full description. * sandybridge & gm45: Support setting PCI bars above 4G +Plans to move platform support to a branch: +------------------------------------------- +After the 4.18 release in November 2022, we plan to move support for any +boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch. V4 was +introduced more than a year ago and with minor changes most platforms +were able to work just fine with it. A major difference is that V3 uses +just one continuous region below 4G to allocate all PCI memory BAR's. V4 +uses all available space below 4G and if asked to, also above 4G too. +This makes it important that SoC code properly reports all fixed +resources. + +Currently only AGESA platforms have issues with it. On Gerrit both +attempts to fix AMD AGESA codebases to use V4 and compatibility modes +inside the V4 allocator have been proposed, but both efforts seem +stalled. See the (not yet merged) documentation +[CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's +details. It looks like properly reporting all fixed resources is the +issue. + +At this point, we are not specifying which platforms this will include +as there are a number of patches to fix these issues in flight. +Hopefully, all platforms will end up being migrated to the V4 resource +allocator so that none of the platforms need to be supported on the +branch. + +Additionally, even if the support for the platform is moved to a branch, +it can be brought back to ToT if they're fixed to support the V4 +allocator. + + Plans for Code Deprecation -------------------------- diff --git a/Documentation/releases/coreboot-4.18-relnotes.md b/Documentation/releases/coreboot-4.18-relnotes.md index d4bfa0ee81..a77919202f 100644 --- a/Documentation/releases/coreboot-4.18-relnotes.md +++ b/Documentation/releases/coreboot-4.18-relnotes.md @@ -195,6 +195,36 @@ the same increases maintenance burden on the community a lot, while also being rather confusing. +Plans to move platform support to a branch: +------------------------------------------- +After the 4.18 release in November 2022, we plan to move support for any +boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch. V4 was +introduced more than a year ago and with minor changes most platforms +were able to work just fine with it. A major difference is that V3 uses +just one continuous region below 4G to allocate all PCI memory BAR's. V4 +uses all available space below 4G and if asked to, also above 4G too. +This makes it important that SoC code properly reports all fixed +resources. + +Currently only AGESA platforms have issues with it. On Gerrit both +attempts to fix AMD AGESA codebases to use V4 and compatibility modes +inside the V4 allocator have been proposed, but both efforts seem +stalled. See the (not yet merged) documentation +[CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's +details. It looks like properly reporting all fixed resources is the +issue. + +At this point, we are not specifying which platforms this will include +as there are a number of patches to fix these issues in flight. +Hopefully, all platforms will end up being migrated to the v4 resource +allocator so that none of the platforms need to be supported on the +branch. + +Additionally, even if the support for the platform is moved to a branch, +it can be brought back to ToT if they're fixed to support the v4 +allocator. + + ### Intel Icelake SoC & Icelake RVP mainboard Intel Icelake is unmaintained. Also, the only user of this platform ever