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

54 lines
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
#include <arch/io.h>
src: Add missing 'include <console/console.h>' "printk()" needs <console/console.h>. Change-Id: Iac6b7000bcd8b1335fa3a0ba462a63aed2dc85b8 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2020-09-19 09:32:36 +02:00
#include <console/console.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 <reset.h>
soc/amd/picasso: Extract reset flags from northbridge.h These are not northbridge functions. BUG=b:147042464 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ia9e7d4c7554788a9fdbfdb90e6ead60060cc4c30 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41264 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-07 23:16:15 +02:00
#include <soc/reset.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 <soc/southbridge.h>
#include <amdblocks/acpimmio.h>
#include <amdblocks/reset.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 <fsp/util.h>
#include <assert.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
void set_warm_reset_flag(void)
{
src/amd/picasso: Update reset code Remove the scratch register indicators. Per AMD, AGESA no longer uses these. Use a new IO register to determine whether a warm reset should occur. Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I0ff7935004b3d1ac5204d3ef575cfa98116a57fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/33989 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-26 00:06:12 +02:00
uint8_t ncp = inw(NCP_ERR);
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
src/amd/picasso: Update reset code Remove the scratch register indicators. Per AMD, AGESA no longer uses these. Use a new IO register to determine whether a warm reset should occur. Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I0ff7935004b3d1ac5204d3ef575cfa98116a57fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/33989 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-26 00:06:12 +02:00
outb(NCP_ERR, ncp | NCP_WARM_BOOT);
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
}
src/amd/picasso: Update reset code Remove the scratch register indicators. Per AMD, AGESA no longer uses these. Use a new IO register to determine whether a warm reset should occur. Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I0ff7935004b3d1ac5204d3ef575cfa98116a57fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/33989 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-26 00:06:12 +02:00
int is_warm_reset(void)
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
{
src/amd/picasso: Update reset code Remove the scratch register indicators. Per AMD, AGESA no longer uses these. Use a new IO register to determine whether a warm reset should occur. Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: I0ff7935004b3d1ac5204d3ef575cfa98116a57fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/33989 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-26 00:06:12 +02:00
return !!(inb(NCP_ERR) & NCP_WARM_BOOT);
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
}
void do_cold_reset(void)
{
/* De-assert and then assert all PwrGood signals on CF9 reset. */
pm_write16(PWR_RESET_CFG, pm_read16(PWR_RESET_CFG) |
TOGGLE_ALL_PWR_GOOD);
outb(RST_CMD | SYS_RST, SYS_RESET);
}
void do_warm_reset(void)
{
set_warm_reset_flag();
/* Assert reset signals only. */
outb(RST_CMD | SYS_RST, SYS_RESET);
}
void do_board_reset(void)
{
/* TODO: Would a warm_reset() suffice? */
do_cold_reset();
}
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
void chipset_handle_reset(uint32_t status)
{
printk(BIOS_ERR, "Error: unexpected call to %s(0x%08x). Doing cold reset.\n",
__func__, status);
Change all assert(0) to BUG() I would like to make assertions evaluate at compile time where possible, but sometimes people used a literal assert(0) to force an assertion in a certain code path. We already have BUG() for that so let's just replace those instances with that. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I674e5f8ec7f5fe8b92b1c7c95d9f9202d422ce32 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44047 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-30 02:39:21 +02:00
BUG();
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
do_cold_reset();
}
Reference in a new issue Copy permalink