GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/soc/amd/picasso/memmap.c

105 lines
2.1 KiB
C
Raw Normal View History

soc/amd: Use SPDX for GPL-2.0-only files Done with sed and God Lines. Only done for C-like code for now. Change-Id: I22fffa0eab006be2bad4d3dd776b22ad9830faef Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-04-04 18:50:57 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#define __SIMPLE_DEVICE__
#include <assert.h>
#include <stdint.h>
soc/amd/picasso: Place early stages and data buffers at the bottom of DRAM This change updates memlayout.ld for Picasso to place all early stages (bootblock, romstage, FSP-M, verstage) and data buffers (vboot workbuf, APOB, preram-cbmem console, timestamp, early BSP stack) at the bottom of DRAM starting at 32MiB. This uses static allocation for most components by defining Kconfig variables for base and size. It relies on the linker to complain if any of the assumptions are broken. This also allows romstage to use linker symbols for _early_reserved_dram and _eearly_reserved_dram to store information in CBMEM about the early DRAM usage by coreboot before ramstage starts execution. This allows ramstage to reserve this memory region in BIOS tables so that S3 resume can reuse the same space without corrupting OS memory. BUG=b:155322763 TEST=Verified memory reported by coreboot: Writing coreboot table at 0xcc656000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000001ffffff: RAM 4. 0000000002000000-000000000223ffff: RESERVED 5. 0000000002240000-00000000cc512fff: RAM 6. 00000000cc513000-00000000cc6bffff: CONFIGURATION TABLES 7. 00000000cc6c0000-00000000cc7c7fff: RAMSTAGE 8. 00000000cc7c8000-00000000cd7fffff: CONFIGURATION TABLES 9. 00000000cd800000-00000000cfffffff: RESERVED 10. 00000000f8000000-00000000fbffffff: RESERVED 11. 0000000100000000-000000042f33ffff: RAM 12. 000000042f340000-000000042fffffff: RESERVED Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I009e1ea71b5b5a8e65eba16911897b2586ccfdb6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-06-11 01:37:23 +02:00
#include <cbmem.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <console/console.h>
cpu/x86/smm: Promote smm_subregion() No need to limit these declarations to FSP. Both PARALLEL_MP_INIT smm_relocate() and TSEG_STAGE_CACHE can be built on top of this. Change-Id: I7b0b9b8c8bee03aabe251c50c47dc42f6596e169 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34701 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2019-08-04 18:54:32 +02:00
#include <cpu/x86/smm.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <cpu/amd/msr.h>
soc/amd/picasso: Convert BERT reserved region from cbmem Picasso's BERT region should not have been moved to cbmem in commit 901cb9c "soc/amd/picasso: Move BERT region to cbmem". This causes an error of "APEI: Can not request [] for APEI BERT registers. FSP has been modified to set aside a requested region size for BERT, simiar to TSEG. Remove the cbmem reservation and locate the region by searching for the HOB. BUG=b:136987699 TEST=Check that BERT is allocated Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I20e99390141986913dd45c2074aa184e992c8ebb Reviewed-on: https://review.coreboot.org/c/coreboot/+/42530 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-18 17:53:08 +02:00
#include <arch/bert_storage.h>
soc/amd/picasso: Add FSP support for including AGESA AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI build environments. Therefore, unlike the previous Arch2008 (a.k.a. v5), it can't be built without additional source, e.g. by combining with EDK II, and it has no entry points for easily building it into a legacy BIOS. AGESA in coreboot now relies on the FSP 2.0 framework published by Intel and uses the existing fsp2_0 driver. * Add fsp_memory_init() to romstage.c. Although Picasso comes out of reset with DRAM alive, this call is added to maximize compatibility and facilitate internal development. Future work may look at removing it. AGESA reports the memory map to coreboot via HOBs returned from fsp_memory_init(). * AGESA currently sets up MTRRs, as in most older generations. Take ownership back immediately before running ramstage. * Remove cbmem initialization, as the FSP driver handles this. * Add chipset_handle_reset() for compatibility. * Top of memory is determined by the FSP driver checking the HOBs passed from AGESA. Note that relying on the TOM register happens to be misleading when UMA is below 4GB. BUG=b:147042464 TEST=Boot trembyle to payload Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-21 07:05:31 +01:00
#include <memrange.h>
#include <fsp/util.h>
#include <FspGuids.h>
soc/amd/picasso: Place early stages and data buffers at the bottom of DRAM This change updates memlayout.ld for Picasso to place all early stages (bootblock, romstage, FSP-M, verstage) and data buffers (vboot workbuf, APOB, preram-cbmem console, timestamp, early BSP stack) at the bottom of DRAM starting at 32MiB. This uses static allocation for most components by defining Kconfig variables for base and size. It relies on the linker to complain if any of the assumptions are broken. This also allows romstage to use linker symbols for _early_reserved_dram and _eearly_reserved_dram to store information in CBMEM about the early DRAM usage by coreboot before ramstage starts execution. This allows ramstage to reserve this memory region in BIOS tables so that S3 resume can reuse the same space without corrupting OS memory. BUG=b:155322763 TEST=Verified memory reported by coreboot: Writing coreboot table at 0xcc656000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000001ffffff: RAM 4. 0000000002000000-000000000223ffff: RESERVED 5. 0000000002240000-00000000cc512fff: RAM 6. 00000000cc513000-00000000cc6bffff: CONFIGURATION TABLES 7. 00000000cc6c0000-00000000cc7c7fff: RAMSTAGE 8. 00000000cc7c8000-00000000cd7fffff: CONFIGURATION TABLES 9. 00000000cd800000-00000000cfffffff: RESERVED 10. 00000000f8000000-00000000fbffffff: RESERVED 11. 0000000100000000-000000042f33ffff: RAM 12. 000000042f340000-000000042fffffff: RESERVED Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I009e1ea71b5b5a8e65eba16911897b2586ccfdb6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-06-11 01:37:23 +02:00
#include <soc/memmap.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
/*
* For data stored in TSEG, ensure TValid is clear so R/W access can reach
* the DRAM when not in SMM.
*/
static void clear_tvalid(void)
{
msr_t hwcr = rdmsr(HWCR_MSR);
msr_t mask = rdmsr(SMM_MASK_MSR);
int tvalid = !!(mask.lo & SMM_TSEG_VALID);
if (hwcr.lo & SMM_LOCK) {
if (!tvalid) /* not valid but locked means still accessible */
return;
printk(BIOS_ERR, "Error: can't clear TValid, already locked\n");
return;
}
mask.lo &= ~SMM_TSEG_VALID;
wrmsr(SMM_MASK_MSR, mask);
}
cpu/x86/smm: Define single smm_subregion() At the moment we only have two splitting of TSEG, one with and one without IED. They can all use same implementation. Make configuration problems of TSEG region assertion failures. Rename file from stage_cache.c to tseg_region.c to reflect it's purpose. Change-Id: I9daf0dec8fbaaa1f4e6004ea034869f43412d7d5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34776 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: David Guckian Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-05 11:49:09 +02:00
void smm_region(uintptr_t *start, size_t *size)
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
{
amd/stoneyridge,picasso: Open TSEG earlier Don't make assumptions about which subregion will be accessed first. Change-Id: I558fa4acc5068014b3748be6fc1bc34999054c0a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34775 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-06 21:14:34 +02:00
static int once;
soc/amd/picasso: Add FSP support for including AGESA AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI build environments. Therefore, unlike the previous Arch2008 (a.k.a. v5), it can't be built without additional source, e.g. by combining with EDK II, and it has no entry points for easily building it into a legacy BIOS. AGESA in coreboot now relies on the FSP 2.0 framework published by Intel and uses the existing fsp2_0 driver. * Add fsp_memory_init() to romstage.c. Although Picasso comes out of reset with DRAM alive, this call is added to maximize compatibility and facilitate internal development. Future work may look at removing it. AGESA reports the memory map to coreboot via HOBs returned from fsp_memory_init(). * AGESA currently sets up MTRRs, as in most older generations. Take ownership back immediately before running ramstage. * Remove cbmem initialization, as the FSP driver handles this. * Add chipset_handle_reset() for compatibility. * Top of memory is determined by the FSP driver checking the HOBs passed from AGESA. Note that relying on the TOM register happens to be misleading when UMA is below 4GB. BUG=b:147042464 TEST=Boot trembyle to payload Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-21 07:05:31 +01:00
struct range_entry tseg;
int status;
*start = 0;
*size = 0;
status = fsp_find_range_hob(&tseg, AMD_FSP_TSEG_HOB_GUID.b);
if (status < 0) {
printk(BIOS_ERR, "Error: unable to find TSEG HOB\n");
return;
}
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
soc/amd/picasso: Add FSP support for including AGESA AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI build environments. Therefore, unlike the previous Arch2008 (a.k.a. v5), it can't be built without additional source, e.g. by combining with EDK II, and it has no entry points for easily building it into a legacy BIOS. AGESA in coreboot now relies on the FSP 2.0 framework published by Intel and uses the existing fsp2_0 driver. * Add fsp_memory_init() to romstage.c. Although Picasso comes out of reset with DRAM alive, this call is added to maximize compatibility and facilitate internal development. Future work may look at removing it. AGESA reports the memory map to coreboot via HOBs returned from fsp_memory_init(). * AGESA currently sets up MTRRs, as in most older generations. Take ownership back immediately before running ramstage. * Remove cbmem initialization, as the FSP driver handles this. * Add chipset_handle_reset() for compatibility. * Top of memory is determined by the FSP driver checking the HOBs passed from AGESA. Note that relying on the TOM register happens to be misleading when UMA is below 4GB. BUG=b:147042464 TEST=Boot trembyle to payload Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-21 07:05:31 +01:00
*start = (uintptr_t)range_entry_base(&tseg);
*size = range_entry_size(&tseg);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
amd/stoneyridge,picasso: Open TSEG earlier Don't make assumptions about which subregion will be accessed first. Change-Id: I558fa4acc5068014b3748be6fc1bc34999054c0a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34775 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-06 21:14:34 +02:00
if (!once) {
clear_tvalid();
once = 1;
}
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
}
soc/amd/picasso: Place early stages and data buffers at the bottom of DRAM This change updates memlayout.ld for Picasso to place all early stages (bootblock, romstage, FSP-M, verstage) and data buffers (vboot workbuf, APOB, preram-cbmem console, timestamp, early BSP stack) at the bottom of DRAM starting at 32MiB. This uses static allocation for most components by defining Kconfig variables for base and size. It relies on the linker to complain if any of the assumptions are broken. This also allows romstage to use linker symbols for _early_reserved_dram and _eearly_reserved_dram to store information in CBMEM about the early DRAM usage by coreboot before ramstage starts execution. This allows ramstage to reserve this memory region in BIOS tables so that S3 resume can reuse the same space without corrupting OS memory. BUG=b:155322763 TEST=Verified memory reported by coreboot: Writing coreboot table at 0xcc656000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000001ffffff: RAM 4. 0000000002000000-000000000223ffff: RESERVED 5. 0000000002240000-00000000cc512fff: RAM 6. 00000000cc513000-00000000cc6bffff: CONFIGURATION TABLES 7. 00000000cc6c0000-00000000cc7c7fff: RAMSTAGE 8. 00000000cc7c8000-00000000cd7fffff: CONFIGURATION TABLES 9. 00000000cd800000-00000000cfffffff: RESERVED 10. 00000000f8000000-00000000fbffffff: RESERVED 11. 0000000100000000-000000042f33ffff: RAM 12. 000000042f340000-000000042fffffff: RESERVED Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I009e1ea71b5b5a8e65eba16911897b2586ccfdb6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-06-11 01:37:23 +02:00
soc/amd/picasso: Convert BERT reserved region from cbmem Picasso's BERT region should not have been moved to cbmem in commit 901cb9c "soc/amd/picasso: Move BERT region to cbmem". This causes an error of "APEI: Can not request [] for APEI BERT registers. FSP has been modified to set aside a requested region size for BERT, simiar to TSEG. Remove the cbmem reservation and locate the region by searching for the HOB. BUG=b:136987699 TEST=Check that BERT is allocated Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I20e99390141986913dd45c2074aa184e992c8ebb Reviewed-on: https://review.coreboot.org/c/coreboot/+/42530 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-18 17:53:08 +02:00
void bert_reserved_region(void **start, size_t *size)
{
struct range_entry bert;
int status;
*start = NULL;
*size = 0;
status = fsp_find_range_hob(&bert, AMD_FSP_BERT_HOB_GUID.b);
if (status < 0) {
printk(BIOS_ERR, "Error: unable to find BERT HOB\n");
return;
}
*start = (void *)(uintptr_t)range_entry_base(&bert);
*size = range_entry_size(&bert);
}
soc/amd/picasso: Place early stages and data buffers at the bottom of DRAM This change updates memlayout.ld for Picasso to place all early stages (bootblock, romstage, FSP-M, verstage) and data buffers (vboot workbuf, APOB, preram-cbmem console, timestamp, early BSP stack) at the bottom of DRAM starting at 32MiB. This uses static allocation for most components by defining Kconfig variables for base and size. It relies on the linker to complain if any of the assumptions are broken. This also allows romstage to use linker symbols for _early_reserved_dram and _eearly_reserved_dram to store information in CBMEM about the early DRAM usage by coreboot before ramstage starts execution. This allows ramstage to reserve this memory region in BIOS tables so that S3 resume can reuse the same space without corrupting OS memory. BUG=b:155322763 TEST=Verified memory reported by coreboot: Writing coreboot table at 0xcc656000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000001ffffff: RAM 4. 0000000002000000-000000000223ffff: RESERVED 5. 0000000002240000-00000000cc512fff: RAM 6. 00000000cc513000-00000000cc6bffff: CONFIGURATION TABLES 7. 00000000cc6c0000-00000000cc7c7fff: RAMSTAGE 8. 00000000cc7c8000-00000000cd7fffff: CONFIGURATION TABLES 9. 00000000cd800000-00000000cfffffff: RESERVED 10. 00000000f8000000-00000000fbffffff: RESERVED 11. 0000000100000000-000000042f33ffff: RAM 12. 000000042f340000-000000042fffffff: RESERVED Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I009e1ea71b5b5a8e65eba16911897b2586ccfdb6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-06-11 01:37:23 +02:00
void memmap_stash_early_dram_usage(void)
{
struct memmap_early_dram *e;
e = cbmem_add(CBMEM_ID_CB_EARLY_DRAM, sizeof(*e));
if (!e)
die("ERROR: Failed to stash early dram usage!\n");
e->base = (uint32_t)(uintptr_t)_early_reserved_dram;
e->size = REGION_SIZE(early_reserved_dram);
}
const struct memmap_early_dram *memmap_get_early_dram_usage(void)
{
struct memmap_early_dram *e = cbmem_find(CBMEM_ID_CB_EARLY_DRAM);
if (!e)
die("ERROR: Failed to read early dram usage!\n");
return e;
}
Reference in a new issue Copy permalink