diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/releases/coreboot-4.17-relnotes.md | 30 | ||||
| -rw-r--r-- | Documentation/releases/coreboot-4.18-relnotes.md | 30 |
2 files changed, 60 insertions, 0 deletions
diff --git a/Documentation/releases/coreboot-4.17-relnotes.md b/Documentation/releases/coreboot-4.17-relnotes.md index 1f868838eb72..eb136f42fc48 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 d4bfa0ee81ca..a77919202fb6 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 |