HiAdding NO_FSP_TEMP_RAM_EXIT in src/soc/intel/denverton_ns/Kconfig fixes the issue, which seems pretty odd since I haven't enabled INTEL_CAR_NEM_ENHANCED. According to your explanation INTEL_CAR_NEM_ENHANCED is required right?That's right. So FSP-T still sets up the cache as ram but I have no idea how it does that (it could be similar to INTEL_CAR_NEM or INTEL_CAR_NEM_ENHANCED).
Selecting INTEL_CAR_NEM_ENHANCED in this case only makes sure that the enhanced NEM msr are cleared.
Even if FSP-T does not use that, it's fine.By configuring coreboot this way, the Temp RAM FSP is not used? So for the coreboot latest Temp RAM FSP support is broken right?Actually the native coreboot CAR init is broken... I send a patch to remove it:https://review.coreboot.org/c/coreboot/+/55519On Mon, Jun 13, 2022 at 9:55 PM Sumo <kingsumos@gmail.com> wrote:Hi Arthur,Adding NO_FSP_TEMP_RAM_EXIT in src/soc/intel/denverton_ns/Kconfig fixes the issue, which seems pretty odd since I haven't enabled INTEL_CAR_NEM_ENHANCED. According to your explanation INTEL_CAR_NEM_ENHANCED is required right?But I have also tried adding INTEL_CAR_NEM_ENHANCED which worked as well. However when selecting CONFIG_USE_DENVERTON_NS_CAR_NEM_ENHANCED the makefile complained about the FSP_CAR dependency which I have then enabled in Kconfig also.(INTEL_CAR_NEM_ENHANCED is enabled only when USE_DENVERTON_NS_CAR_NEM_ENHANCED is set)
diff --git a/src/soc/intel/denverton_ns/Kconfig b/src/soc/intel/denverton_ns/Kconfig
index 92fc065a..cd5e13b8 100644
--- a/src/soc/intel/denverton_ns/Kconfig
+++ b/src/soc/intel/denverton_ns/Kconfig
@@ -20,6 +20,7 @@ config CPU_SPECIFIC_OPTIONS
select CPU_INTEL_FIRMWARE_INTERFACE_TABLE
select CPU_SUPPORTS_PM_TIMER_EMULATION
select DEBUG_GPIO
+ select NO_FSP_TEMP_RAM_EXIT
select FSP_M_XIP
select FSP_T_XIP if FSP_CAR
select HAVE_INTEL_FSP_REPO
@@ -163,6 +164,7 @@ config USE_DENVERTON_NS_CAR_NEM_ENHANCED
bool "Enhanced Non-evict mode"
select SOC_INTEL_COMMON_BLOCK_CAR
select INTEL_CAR_NEM_ENHANCED
+ select FSP_CAR
help
A current limitation of NEM (Non-Evict mode) is that code and data sizes
are derived from the requirement to not write out any modified cache line.
The log output of both tries are almost the same...By configuring coreboot this way, the Temp RAM FSP is not used? So for the coreboot latest Temp RAM FSP support is broken right?Thanks,SumoOn Mon, Jun 13, 2022 at 1:38 PM Arthur Heymans <arthur@aheymans.xyz> wrote:ArthurKind regardsHiCan you try selecting "NO_FSP_TEMP_RAM_EXIT" in the denverton_ns Kconfig?
That way coreboot uses native code to tear down CAR (so without FSP TempRamExit)
INTEL_CAR_NEM_ENHANCED also needs to be select in the FSP_CAR option for that to work (so it knows how to tear down CAR).On Mon, Jun 13, 2022 at 4:46 PM Sumo <kingsumos@gmail.com> wrote:Hi,Update: I found the bad commit:commit 5315e96abfa5b45fcd53149df5ebaa069a830558
Author: Arthur Heymans <arthur@aheymans.xyz>
Date: Fri May 14 11:22:31 2021 +0200
arch/x86/postcar: Use a separate stack for C execution
Add a stack in .bss for C execution. This will make it easier to move
the setup of MTRRs in C code.Hehehe, this confirmed my suspicion that the problem was in the POSTCAR...should have done a grep for postcar in git log instead of the painful bisect :DSo denverton_ns is broken due to this commit, how can we proceed? I guess a git revert is not an option right, since this change looks like a base for future implementations... Please let me know if you need more tests.Kind regards,Sumo_______________________________________________On Mon, Jun 13, 2022 at 9:37 AM Sumo <kingsumos@gmail.com> wrote:Thanks Paul, I'll try bisect.Do we have any instructions of how to use the normal/fallback coreboot stage prefixes? During the bisect it will be painful always bricking the board and having to use a flash programmer for restoring instead of using flashrom.Should I build setting BOOTBLOCK_NORMAL + normal prefix, and then reuse a prebuilt coreboot.rom with fallback stages included? Anything else needed besides having a cmos layout?Kind regards,SumoOn Sat, Jun 11, 2022 at 3:15 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:Dear Suma,
Am 11.06.22 um 00:16 schrieb Sumo:
> My denverton system is crashing after the FSM memory init, probably when
> jumping to POSTCAR. The following lines are shown before the crash:
>
> [DEBUG] TPM: Digest of `CBFS: fallback/postcar` to PCR 2 logged
> [DEBUG] Loading module at 0x7f7ce000 with entry 0x7f7ce031. filesize:
> 0x6060 memsize: 0xc358
> [DEBUG] Processing 246 relocs. Offset value of 0x7d7ce000
> [DEBUG] BS: romstage times (exec / console): total (unknown) / 1350 ms
>
> Below are my CAR settings:
> # CONFIG_USE_DENVERTON_NS_CAR_NEM_ENHANCED is not set
> CONFIG_USE_DENVERTON_NS_FSP_CAR=y
> CONFIG_ARCH_POSTCAR_X86_32=y
> CONFIG_POSTCAR_STAGE=y
> CONFIG_CARDBUS_PLUGIN_SUPPORT=y
> CONFIG_FSP_CAR=y
> CONFIG_POSTCAR_CONSOLE=y
>
> Everything is fine when using coreboot v4.14.
>
> I have tried using CONFIG_USE_DENVERTON_NS_CAR_NEM_ENHANCED but things got
> even worse - in this case nothing is shown in the console output.
>
> Any suggestions?
It’d be great if you could bisect.
Kind regards,
Paul
PS: In your address book please spell coreboot lowercase. ;-)
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org