[coreboot] [coreboot - Bug #388] denverton_ns: crash when starting postcar
Issue #388 has been updated by King Sumo. King Sumo wrote: > Postcar is crashing when using configured to teardown the CAR using FSP. > Therefore the bug may occur in other platforms than denverton as well. > See also the discussion here: > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3GNJSGXUD6DRVUY7O2O3W6OM3E2MY/ > The bug was instroduced by the following change: > * 5315e96abf arch/x86/postcar: Use a separate stack for C execution > Attached is a patch with the bug fix. Fixed (master): https://review.coreboot.org/c/coreboot/+/65716 Bug #388: denverton_ns: crash when starting postcar https://ticket.coreboot.org/issues/388#change-1037 * Author: King Sumo * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2022-06-15 * Affected versions: 4.17, master * Affected hardware: intel harcuvar * Affected OS: all Postcar is crashing when using configured to teardown the CAR using FSP. Therefore the bug may occur in other platforms than denverton as well. See also the discussion here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3GNJSGXUD6DRVUY7O2O3W6OM3E2MY/ The bug was instroduced by the following change: * 5315e96abf arch/x86/postcar: Use a separate stack for C execution Attached is a patch with the bug fix. ---Files fix-postcar-crash.patch (822 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #388] (New) denverton_ns: crash when starting postcar
Issue #388 has been reported by King Sumo. Bug #388: denverton_ns: crash when starting postcar https://ticket.coreboot.org/issues/388 * Author: King Sumo * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2022-06-15 * Affected versions: 4.17, master * Affected hardware: intel harcuvar * Affected OS: all Postcar is crashing when using configured to teardown the CAR using FSP. Therefore the bug may occur in other platforms than denverton as well. See also the discussion here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3GNJSGXUD6DRVUY7O2O3W6OM3E2MY/ The bug was instroduced by the following change: * 5315e96abf arch/x86/postcar: Use a separate stack for C execution Attached is a patch with the bug fix. ---Files fix-postcar-crash.patch (822 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #318] denverton_ns: Fix MRC cache write
Issue #318 has been updated by King Sumo. King Sumo wrote in #note-1: > Fixed: > > ommit 3990da0bfe18e3b76751fd35fef9e5ec55c2fd29 > Author: Kyösti Mälkki > Date: Mon Nov 15 17:25:54 2021 +0200 > > soc/intel/denverton_ns: Fix MRC_RW_CACHE > > It is required to set WPD (Write Protect Disable) bit > to make it possible to use MRC_RW_CACHE region with > CACHE_MRC_SETTINGS=y. > > Change-Id: Iacab44b00d08c9bdc18bc3bdcb88833634c0b02e > Signed-off-by: Kyösti Mälkki > Reviewed-on: https://review.coreboot.org/c/coreboot/+/60091 > Tested-by: build bot (Jenkins) > Reviewed-by: Angel Pons Please someone close this ticked, I guess only may developers can do this. Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-960 * Author: King Sumo * Status: Response Needed * Priority: Normal * Start date: 2021-09-02 The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26YJ22Z64DZXPAK2VMT6L3FNANNLHMDQ/ https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #318] (Response Needed) denverton_ns: Fix MRC cache write
Issue #318 has been updated by King Sumo. Status changed from New to Response Needed Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-959 * Author: King Sumo * Status: Response Needed * Priority: Normal * Start date: 2021-09-02 The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26YJ22Z64DZXPAK2VMT6L3FNANNLHMDQ/ https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: denverton: crash when using coreboot 4.17
Hi Arthur, After adding a '$' sign now we are reaching the main() and then the TempRamExit is called. diff --git a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S index 4d35447a56..37644c3e5f 100644 --- a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S +++ b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S @@ -17,7 +17,7 @@ chipset_teardown_car: /* Set up new stack. */ - mov _estack, %esp + mov $_estack, %esp /* Align the stack. */ andl$0xfff0, %esp Notice in src/arch/x86/exit_car.S we have a $ sign... The fsp1_1/exit_car.S module must be fixed as well Thanks, Sumo On Tue, Jun 14, 2022 at 3:25 PM Arthur Heymans wrote: > > So basically Temp RAM Exit is broken, since we need to use >> NO_FSP_TEMP_RAM_EXIT which selects >> "./src/soc/intel/common/block/cpu/car/exit_car.S" which is doing nothing >> besides disabling MTTRs (as all INTEL_CAR_* defines are unset) and then >> returning. Therefore, we have no CAR teardown. > > That is why I'm recommending to select INTEL_CAR_NEM_ENHANCED as it will > do the right CAR teardown. > > I doubt that it's not reaching the main call but rather that something bad > happens when calling the TempRamExit API... > Is it worth investigating if we can make the native coreboot CAR teardown > work? > > Arthur > > On Tue, Jun 14, 2022 at 8:11 PM Sumo wrote: > >> Hi Arthur, >> >> So basically Temp RAM Exit is broken, since we need to use >> NO_FSP_TEMP_RAM_EXIT which selects >> "./src/soc/intel/common/block/cpu/car/exit_car.S" which is doing nothing >> besides disabling MTTRs (as all INTEL_CAR_* defines are unset) and then >> returning. Therefore, we have no CAR teardown. >> >> Without NO_FSP_TEMP_RAM_EXIT, we are using >> "./src/soc/intel/common/block/cpu/car/exit_car_fsp.S" which it is crashing >> without reaching the main() function to invoke the TempRamExit API. This >> was working before the commit #5315e96abf - we have the following changes >> in exit_cat_fsp.S: >> >> diff --git a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S >> b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S >> index 4b906280e6..4d35447a56 100644 >> --- a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S >> +++ b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S >> @@ -10,16 +10,16 @@ >> * to tear down the CAR and set up caching which can be overwritten >> * after the API call. More info can be found in the FSP Integration >> * Guide included with the FSP binary. >> */ >> >> .text >> .global chipset_teardown_car >> chipset_teardown_car: >> >> /* Set up new stack. */ >> - mov post_car_stack_top, %esp >> + mov _estack, %esp >> /* Align the stack. */ >> andl$0xfff0, %esp >> >> /* Call C code */ >> callmain >> >> The question is why we can't reach main() anymore. Any clues? >> >> Kind regards, >> Sumo >> >> >> >> >> On Tue, Jun 14, 2022 at 6:27 AM Arthur Heymans >> wrote: >> >>> Hi >>> >>> 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? >>>> >>> 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/+/55519 >>> >>> On Mon, Jun 13, 2022 at 9:55 PM Sumo 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
[coreboot] Re: denverton: crash when using coreboot 4.17
Hi Arthur, So basically Temp RAM Exit is broken, since we need to use NO_FSP_TEMP_RAM_EXIT which selects "./src/soc/intel/common/block/cpu/car/exit_car.S" which is doing nothing besides disabling MTTRs (as all INTEL_CAR_* defines are unset) and then returning. Therefore, we have no CAR teardown. Without NO_FSP_TEMP_RAM_EXIT, we are using "./src/soc/intel/common/block/cpu/car/exit_car_fsp.S" which it is crashing without reaching the main() function to invoke the TempRamExit API. This was working before the commit #5315e96abf - we have the following changes in exit_cat_fsp.S: diff --git a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S index 4b906280e6..4d35447a56 100644 --- a/src/soc/intel/common/block/cpu/car/exit_car_fsp.S +++ b/src/soc/intel/common/block/cpu/car/exit_car_fsp.S @@ -10,16 +10,16 @@ * to tear down the CAR and set up caching which can be overwritten * after the API call. More info can be found in the FSP Integration * Guide included with the FSP binary. */ .text .global chipset_teardown_car chipset_teardown_car: /* Set up new stack. */ - mov post_car_stack_top, %esp + mov _estack, %esp /* Align the stack. */ andl$0xfff0, %esp /* Call C code */ callmain The question is why we can't reach main() anymore. Any clues? Kind regards, Sumo On Tue, Jun 14, 2022 at 6:27 AM Arthur Heymans wrote: > Hi > > 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? >> > 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/+/55519 > > On Mon, Jun 13, 2022 at 9:55 PM Sumo 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, >> Sumo >> >> On Mon, Jun 13, 2022 at 1:38 PM Arthur Heymans >> wrote: >> >>> Hi >>> >>> Can 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). >&g
[coreboot] Re: denverton: crash when using coreboot 4.17
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, Sumo On Mon, Jun 13, 2022 at 1:38 PM Arthur Heymans wrote: > Hi > > Can 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). > > Kind regards > Arthur > > On Mon, Jun 13, 2022 at 4:46 PM Sumo wrote: > >> Hi, >> >> Update: I found the bad commit: >> >> commit 5315e96abfa5b45fcd53149df5ebaa069a830558 >> Author: Arthur Heymans >> 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 :D >> >> So 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 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, >>> Sumo >>> >>> >>> On Sat, Jun 11, 2022 at 3:15 AM Paul Menzel >>> 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 >&
[coreboot] Re: denverton: crash when using coreboot 4.17
Hi, Update: I found the bad commit: commit 5315e96abfa5b45fcd53149df5ebaa069a830558 Author: Arthur Heymans 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 :D So 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 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, > Sumo > > > On Sat, Jun 11, 2022 at 3:15 AM Paul Menzel 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-le...@coreboot.org
[coreboot] Re: denverton: crash when using coreboot 4.17
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, Sumo On Sat, Jun 11, 2022 at 3:15 AM Paul Menzel 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-le...@coreboot.org
[coreboot] denverton: crash when using coreboot 4.17
Hi, 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? Thanks, Sumo coreboot-4.17.log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Denverton: NVMe not detected when serial console logs are disabled
Hi, Anything else can be tried instead of using simple delays? Perhaps during the enumeration for some devices a delay is really required, for the NVMe case the vendor/device ID pair isn't detected at all... I'm not sure if the PCIe link is still training (I don't have an analyzer) or if the device is still booting... Kind regards, Sumo On Tue, Aug 17, 2021 at 8:34 AM Sumo wrote: > Hi, > > I have managed to disable the UART console and collect the logs via cbmem > tool. Therefore it will not add any additional delay even with debug logs > enabled so we can compare the logs with and without the delay. > > Here are my findings: > - without the delay in dev_enumerate() the NVMe because isn't detected at > all (i.e. the PCIe device isn't shown in the bus): > PCI: 00:0b.0 scanning... > do_pci_scan_bridge for PCI: 00:0b.0 > PCI: 00:0b.0: Enabled LTR > PCI: pci_scan_bus for bus 04 > POST: 0x24 > > *PCI: Static device PCI: 04:00.0 not found, disabling it.*POST: 0x25 > PCI: Leftover static devices: > PCI: 04:00.0 > PCI: Check your devicetree.cb. > POST: 0x55 > scan_bus: bus PCI: 00:0b.0 finished in 0 msecs > > - by adding the delay the device is detected and initialized: > PCI: 00:0b.0 scanning... > do_pci_scan_bridge for PCI: 00:0b.0 > PCI: 00:0b.0: Enabled LTR > PCI: pci_scan_bus for bus 04 > POST: 0x24 > > *PCI: 04:00.0 [1987/5012] enabled*POST: 0x25 > POST: 0x55 > Enabling Common Clock Configuration > PCIE CLK PM is not supported by endpoint > L1 Sub-State supported from root port 11 > L1 Sub-State Support = 0xf > CommonModeRestoreTime = 0x28 > Power On Value = 0x6, Power On Scale = 0x1 > ASPM: Enabled L1 > PCIe: Max_Payload_Size adjusted to 256 > PCI: 04:00.0: Enabled LTR > PCI: 04:00.0: Programmed LTR max latencies > scan_bus: bus PCI: 00:0b.0 finished in 0 msecs > > Also, another device is failing if I remove the delay - it's a I211 > gigabit ethernet controller: > PCI: 00:0f.0 scanning... > do_pci_scan_bridge for PCI: 00:0f.0 > PCI: 00:0f.0: Enabled LTR > PCI: pci_scan_bus for bus 05 > POST: 0x24 > > *PCI: Static device PCI: 05:00.0 not found, disabling it.*POST: 0x25 > PCI: Leftover static devices: > PCI: 05:00.0 > PCI: Check your devicetree.cb. > POST: 0x55 > scan_bus: bus PCI: 00:0f.0 finished in 0 msecs > > With the delay the I211 is detected: > PCI: 00:0f.0 scanning... > do_pci_scan_bridge for PCI: 00:0f.0 > PCI: 00:0f.0: Enabled LTR > PCI: pci_scan_bus for bus 05 > POST: 0x24 > > *PCI: 05:00.0 [8086/1539] enabled*POST: 0x25 > POST: 0x55 > Enabling Common Clock Configuration > PCIE CLK PM is not supported by endpoint > ASPM: Enabled L1 > PCIe: Max_Payload_Size adjusted to 256 > PCI: 05:00.0: No LTR support > scan_bus: bus PCI: 00:0f.0 finished in 0 msecs > > Full logs are attached. > > Kind regards, > Sumo > > On Mon, Aug 16, 2021 at 8:01 PM Sumo wrote: > >> Hi Paul, >> >> When logs are (almost) disabled the error isn't shown, so if I add the >> delay with logs disabled the log output will have almost no difference at >> all. >> >> Following are the logs, including a log with Coreboot debug enabled + no >> delay. For all logs FSP loglevel is set to NoDebug: >> - nvme-err.log : no delay; coreboot debug_level=Error; NVMe error: at the >> end of the log is shown the error in the UEFI FW: >> ERROR: C4002:V02010007 I0 93B80004-9FB3-11D4-9A3A-0090273FC14D >> 7E90A998; >> - nvme-ok-delay.log : 20ms delay; coreboot debug_level=Error; NVMe ok; >> - nvme-ok.log : no delay; coreboot debug_level=Spew; NVMe ok: the >> coreboot log output is enough to make NVMe work properly; >> >> The NVMe is in the root port 00:0b.0, it is shown as 04:00.0 >> >> Thanks, >> Sumo >> >> On Mon, Aug 16, 2021 at 2:57 PM Paul Menzel >> wrote: >> >>> Dear Sumo, >>> >>> >>> Am 16.08.21 um 18:38 schrieb Sumo: >>> >>> > The NVMe is not detected when serial console logs are disabled, I mean >>> by >>> > setting both Coreboot log_level=Error (or less) and FSP >>> > PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails >>> then >>> > further on the device is not listed in the UEFI FW (same issue shown in >>> > either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the >>> device >>> > appears normally. >>> > >>> > The problem is fixed by adding a small delay inside dev_enumerate() - a >>> > 20ms delay at the very beginning of the function is enough. I'm >>> wondering >>> > if there is a better solution for this, the device is already defined >>> in >>> > the devicetree.cb (set as on). Maybe coreboot is too fast and the NVMe >>> is >>> > still booting up - or the PCIe link is still training, not sure. >>> Coreboot >>> > doesn't retry if the device is not detected right away? >>> >>> Please share the logs without and with the delay. >>> >>> >>> Kind regards, >>> >>> Paul >>> >> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
Hi Furquan,
I can confirm your proposal is working, could you please submit the patch
for review?
Thanks,
Sumo
On Fri, Aug 20, 2021 at 9:52 PM Szafranski, MariuszX <
mariuszx.szafran...@intel.com> wrote:
> Hi Furquan,
>
> Thanks for pointing. I`ve missed this patch series.
> Yeah omitting the `device lapic` line from the devicetree and adding this
> patch looks like correct (common) way to handle this issue.
>
> BR,
> Mariusz
>
> > > have you tried omitting the `device lapic` line from the devicetree?
> >
> > I have tested this, in this case Linux shows only one processor core.
> Therefore the 'device lapic' line is really needed...
>
> Can you please try dropping `device lapic` from the devicetree along with
> this patch:
>
> diff --git a/src/soc/intel/denverton_ns/cpu.c
> b/src/soc/intel/denverton_ns/cpu.c
> index 1dc0830d86..ecefd3a987 100644
> --- a/src/soc/intel/denverton_ns/cpu.c
> +++ b/src/soc/intel/denverton_ns/cpu.c
> @@ -287,6 +287,9 @@ static const struct mp_ops mp_ops = {
>
> void denverton_init_cpus(struct device *dev) {
> + if (!dev->link_list)
> + add_more_links(dev, 1);
> +
> /* Clear for take-off */
> if (mp_init_with_smm(dev->link_list, _ops) < 0)
> printk(BIOS_ERR, "MP initialization failure.\n");
>
> I think once you drop the device from device tree, dev->link_list would be
> NULL and so MP initialization failed for you. This problem is not really
> unique to denverton and was fixed just a few days back for other Intel SoCs
> using common/block/cpu/mp_init too:
>
> https://review.coreboot.org/c/coreboot/+/56758
> https://review.coreboot.org/c/coreboot/+/56852
>
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the
> sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
> the
> sender and delete all copies.
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE
Hi Mariusz, The proposal of calling fast_spi_early_init() in bootblock is working. Other Intel processors are already doing the same way, probably this was missing in Denverton. Also, it works better than using BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES as we don't have the other issue I have pointed out. The patch was submitted for review: https://review.coreboot.org/c/coreboot/+/57033 Thanks, Sumo On Fri, Jun 11, 2021 at 9:05 AM Szafranski, MariuszX < mariuszx.szafran...@intel.com> wrote: > Hi Sumo, > > > > It should be simple as adding SPI early init to bootblock. > > You could try to add call to > > fast_spi_early_init(DEFAULT_SPI_BASE); > > at the end of bootblock_soc_early_init function from > src/soc/intel/denverton_ns/bootblock/bootblock.c > > I suspect that after that MRC writing should also work in earlier stage if > there will be no address conflict (can`t verify that myself for now☹ ) > > Please try and let us know. > > > > Mariusz > > > > *From:* Sumo > *Sent:* Friday, June 11, 2021 12:11 AM > *To:* mariusz.szafran...@akumat.pl > *Cc:* Coreboot > *Subject:* [coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE > > > > Hi Mariusz, > > > > Setting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES solved the problem, thanks! > > > The only drawback of saving MRC CACHE in later state are the additional > resets which are requested by FSP_S (silicon init) - for each additional > reset the DDR4 training data is lost and this delays the startup a little > bit, but this was also occurring in old coreboot-4.8.1. > > Basically those additional resets happens when the CMOS is cleared (when > RTC-power-well settings are lost also) so FSP_S resets the system to > reconfigure peripherals (ie. SATA, HSIO changes, etc) - and for each reset > DDR4 training must be performed again. > > > > For coreboot-4.8.1 in the past I have successfully implemented a change to > save MRC CACHE before calling FSP_S to fix this, it worked well but I never > used that change in production to not take any risk since I was unsure > about side effects. But this improvement can save some time during > manufacturing as some resets can't be avoided (here at least 1 reset always > happens). It would be good if this can be implemented somehow in coreboot > latest... > > > > Hopefully this info could be useful to someone ;) > > > > Kind regards, > > Sumo > > > > On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via coreboot < > coreboot@coreboot.org> wrote: > > Hi Sumo, > > Please try to additionally select MRC_WRITE_NV_LATE or > BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to push MRC writing to later state > > W dniu 10.06.2021 o 16:58, Sumo pisze: > > Hi, > > > > I'm stuck in a problem where coreboot fails to write the MRC cache in the > SPI Flash. > > Below is the log output: > > > > FMAP: area RW_MRC_CACHE found @ 81 (65536 bytes) > MRC: Checking cached data update for 'RW_MRC_CACHE'. > SF: Detected 00 with sector size 0x1000, total 0x100 > MRC: no data in 'RW_MRC_CACHE' > MRC: cache data 'RW_MRC_CACHE' needs update. > SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003 > REGF metadata allocation failed: 1949 data blocks 4096 total blocks > MRC: failed to update 'RW_MRC_CACHE'. > > > > Any clues? > > > > Thanks, > > Sumo > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > > -- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Fwd: Denverton: NVMe not detected when serial console logs are disabled
Hi Paul, When logs are (almost) disabled the error isn't shown, so if I add the delay with logs disabled the log output will have almost no difference at all. Following are the logs, including a log with Coreboot debug enabled + no delay. For all logs FSP loglevel is set to NoDebug: - nvme-err.log : no delay; coreboot debug_level=Error; NVMe error: at the end of the log is shown the error in the UEFI FW: ERROR: C4002:V02010007 I0 93B80004-9FB3-11D4-9A3A-0090273FC14D 7E90A998; - nvme-ok-delay.log : 20ms delay; coreboot debug_level=Error; NVMe ok; - nvme-ok.log : no delay; coreboot debug_level=Spew; NVMe ok: the coreboot log output is enough to make NVMe work properly; The NVMe is in the root port 00:0b.0, it is shown as 04:00.0 Thanks, Sumo On Mon, Aug 16, 2021 at 2:57 PM Paul Menzel wrote: > Dear Sumo, > > > Am 16.08.21 um 18:38 schrieb Sumo: > > > The NVMe is not detected when serial console logs are disabled, I mean by > > setting both Coreboot log_level=Error (or less) and FSP > > PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails then > > further on the device is not listed in the UEFI FW (same issue shown in > > either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the device > > appears normally. > > > > The problem is fixed by adding a small delay inside dev_enumerate() - a > > 20ms delay at the very beginning of the function is enough. I'm wondering > > if there is a better solution for this, the device is already defined in > > the devicetree.cb (set as on). Maybe coreboot is too fast and the NVMe is > > still booting up - or the PCIe link is still training, not sure. Coreboot > > doesn't retry if the device is not detected right away? > > Please share the logs without and with the delay. > > > Kind regards, > > Paul > nvme-ok.log Description: Binary data nvme-err.log Description: Binary data nvme-ok-delay.log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
Hi Jay, > ... It’s also possible (but not confirmed) that for a particular SKU (other than 16-core SKUs), it might not be consistent between parts I can confirm this, I have two C3558 SoC's with first core different APID ID's... Do you think I can submit my patch (see previous discussions) or do we have a better solution? Kind regards, Sumo On Mon, Aug 16, 2021 at 1:45 PM Jay Talbott wrote: > Unfortunately, for the Denverton SoC (C3000 series), the APIC ID of the > first core is not always the same. For 16-core SKUs, it’s always 0, but for > SKUs with a lower number of cores, it may be a different number. It’s also > possible (but not confirmed) that for a particular SKU (other than 16-core > SKUs), it might not be consistent between parts. The solution is to > basically ignore the value in devicetree and use the actual APIC ID from > the first core. > > > > - Jay > > > > *From:* Sumo [mailto:kingsu...@gmail.com] > *Sent:* Monday, August 16, 2021 9:15 AM > *To:* Nico Huber > *Cc:* Дмитрий Понаморев; Coreboot > *Subject:* [coreboot] Re: A different lapic number in devicetree.cb > needed for CPU with the same SKU and steping (Intel Atom C3538). > > > > Hi, > > > > > have you tried omitting the `device lapic` line from the devicetree? > > I have tested this, in this case Linux shows only one processor core. > Therefore the 'device lapic' line is really needed... > > > > I can submit that Local APIC Fixup patch to gerrit but I'm not sure if > this is really the best solution. > > > > Kind regards, > > Sumo > > > > > > On Wed, Oct 7, 2020 at 6:35 PM Nico Huber wrote: > > Hi, > > have you tried omitting the `device lapic` line from the devicetree? > It would only matter if there is configuration associated with it, but > I can't see anything like that for `intel/harcuvar`. > > What happens is that this `device lapic` line in the devicetree becomes > an entry in a list at runtime. This list is later filled with the actual > cores present. If any of the actual cores has the same APIC id as given > in the devicetree, no additional entry is added for this core. However > if none of the actual cores has that id, the original entry is left > blindly in the list, causing coreboot to report the spurious, fifth > core. > > On 07.10.20 21:27, dponamo...@gmail.com wrote: > > Thank you so much Javier Galindo! > > > > Sorry for not finding this case myself ... > > I checked it on the motherboard with lapic #4 - everything works as it > should. > > Tomorrow I'll check it on the motherboard with lapic #0. > > I wish I could understand how this magic works :)! lapic 0xbeef . > > It's kind of a wildcard that gets replaced with the number found in the > hardware. Nothing too special but probably unnecessary. > > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Denverton: NVMe not detected when serial console logs are disabled
Hi, The NVMe is not detected when serial console logs are disabled, I mean by setting both Coreboot log_level=Error (or less) and FSP PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails then further on the device is not listed in the UEFI FW (same issue shown in either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the device appears normally. The problem is fixed by adding a small delay inside dev_enumerate() - a 20ms delay at the very beginning of the function is enough. I'm wondering if there is a better solution for this, the device is already defined in the devicetree.cb (set as on). Maybe coreboot is too fast and the NVMe is still booting up - or the PCIe link is still training, not sure. Coreboot doesn't retry if the device is not detected right away? Kind regards, Sumo ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
Hi, > have you tried omitting the `device lapic` line from the devicetree? I have tested this, in this case Linux shows only one processor core. Therefore the 'device lapic' line is really needed... I can submit that Local APIC Fixup patch to gerrit but I'm not sure if this is really the best solution. Kind regards, Sumo On Wed, Oct 7, 2020 at 6:35 PM Nico Huber wrote: > Hi, > > have you tried omitting the `device lapic` line from the devicetree? > It would only matter if there is configuration associated with it, but > I can't see anything like that for `intel/harcuvar`. > > What happens is that this `device lapic` line in the devicetree becomes > an entry in a list at runtime. This list is later filled with the actual > cores present. If any of the actual cores has the same APIC id as given > in the devicetree, no additional entry is added for this core. However > if none of the actual cores has that id, the original entry is left > blindly in the list, causing coreboot to report the spurious, fifth > core. > > On 07.10.20 21:27, dponamo...@gmail.com wrote: > > Thank you so much Javier Galindo! > > > > Sorry for not finding this case myself ... > > I checked it on the motherboard with lapic #4 - everything works as it > should. > > Tomorrow I'll check it on the motherboard with lapic #0. > > I wish I could understand how this magic works :)! lapic 0xbeef . > > It's kind of a wildcard that gets replaced with the number found in the > hardware. Nothing too special but probably unnecessary. > > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE
Hi Mariusz, Setting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES solved the problem, thanks! The only drawback of saving MRC CACHE in later state are the additional resets which are requested by FSP_S (silicon init) - for each additional reset the DDR4 training data is lost and this delays the startup a little bit, but this was also occurring in old coreboot-4.8.1. Basically those additional resets happens when the CMOS is cleared (when RTC-power-well settings are lost also) so FSP_S resets the system to reconfigure peripherals (ie. SATA, HSIO changes, etc) - and for each reset DDR4 training must be performed again. For coreboot-4.8.1 in the past I have successfully implemented a change to save MRC CACHE before calling FSP_S to fix this, it worked well but I never used that change in production to not take any risk since I was unsure about side effects. But this improvement can save some time during manufacturing as some resets can't be avoided (here at least 1 reset always happens). It would be good if this can be implemented somehow in coreboot latest... Hopefully this info could be useful to someone ;) Kind regards, Sumo On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via coreboot < coreboot@coreboot.org> wrote: > Hi Sumo, > > Please try to additionally select MRC_WRITE_NV_LATE or > BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to push MRC writing to later state > W dniu 10.06.2021 o 16:58, Sumo pisze: > > Hi, > > I'm stuck in a problem where coreboot fails to write the MRC cache in the > SPI Flash. > Below is the log output: > > FMAP: area RW_MRC_CACHE found @ 81 (65536 bytes) > MRC: Checking cached data update for 'RW_MRC_CACHE'. > SF: Detected 00 with sector size 0x1000, total 0x100 > MRC: no data in 'RW_MRC_CACHE' > MRC: cache data 'RW_MRC_CACHE' needs update. > SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003 > REGF metadata allocation failed: 1949 data blocks 4096 total blocks > MRC: failed to update 'RW_MRC_CACHE'. > > Any clues? > > Thanks, > Sumo > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] denverton_ns: failed to write RW_MRC_CACHE
Hi, I'm stuck in a problem where coreboot fails to write the MRC cache in the SPI Flash. Below is the log output: FMAP: area RW_MRC_CACHE found @ 81 (65536 bytes) MRC: Checking cached data update for 'RW_MRC_CACHE'. SF: Detected 00 with sector size 0x1000, total 0x100 MRC: no data in 'RW_MRC_CACHE' MRC: cache data 'RW_MRC_CACHE' needs update. SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003 REGF metadata allocation failed: 1949 data blocks 4096 total blocks MRC: failed to update 'RW_MRC_CACHE'. Any clues? Thanks, Sumo ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot not starting on denverton_ns
Hi Arthur, It works, thanks! Kind regards, Sumo On Thu, Jun 10, 2021 at 10:36 AM Arthur Heymans wrote: > Hi > > Try with https://review.coreboot.org/c/coreboot/+/55389 applied. > > Kind regards > Arthur > > On Thu, Jun 10, 2021 at 3:16 PM Sumo wrote: > >> Hi, >> >> Coreboot is not starting on denverton due to this commit: >> * 0f068a600e drivers/intel/fsp2_0: Fix the FSP-T position >> (found this by doing a manual git bisect using an old commit as >> reference, everything was working good around november 2020) >> Basically it crashes, nothing is shown in the console output. >> Any advice? >> >> Kind regards, >> Sumo >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] coreboot not starting on denverton_ns
Hi, Coreboot is not starting on denverton due to this commit: * 0f068a600e drivers/intel/fsp2_0: Fix the FSP-T position (found this by doing a manual git bisect using an old commit as reference, everything was working good around november 2020) Basically it crashes, nothing is shown in the console output. Any advice? Kind regards, Sumo ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Regarding Intel CPU frequency (Intel Denverton based)
Hi Jay,
Regarding the APIC ID problem, besides updating devicetree.cb with the
correct value do you think something else is required?
I have created a patch to make the APIC ID of devicetree.cb "dynamic" for
Denverton SoC, so it can be updated during runtime, see below:
diff --git a/src/device/device.c b/src/device/device.c
index 02209d9e..8852270b 100644
--- a/src/device/device.c
+++ b/src/device/device.c
@@ -50,6 +50,9 @@
#include
#endif
#include
+#if IS_ENABLED(CONFIG_SOC_INTEL_DENVERTON_NS)
+#include
+#endif
/** Linked list of ALL devices */
struct device *all_devices = _root;
@@ -983,6 +986,16 @@ void dev_enumerate(void)
{
struct device *root;
+#if IS_ENABLED(CONFIG_SOC_INTEL_DENVERTON_NS)
+ /* Bootstrap processor Local APIC fixup */
+ struct device *t = dev_find_lapic(0xbeef);
+ if (t) {
+ unsigned int apic_id = lapicid();
+ printk(BIOS_INFO, "Denverton-NS BSP Local APIC fixup:
lapic=%u\n", apic_id);
+ t->path.apic.apic_id = apic_id;
+ }
+#endif
+
printk(BIOS_INFO, "Enumerating buses...\n");
root = _root;
diff --git a/src/mainboard/intel/harcuvar/devicetree.cb
b/src/mainboard/intel/harcuvar/devicetree.cb
index 2e463c09..18654d42 100644
--- a/src/mainboard/intel/harcuvar/devicetree.cb
+++ b/src/mainboard/intel/harcuvar/devicetree.cb
@@ -45,7 +45,7 @@ chip soc/intel/denverton_ns
register "ipc3" = "0x" # IPC3
device cpu_cluster 0 on
- device lapic 4 on end
+ device lapic 0xbeef on end # NOTE: correct Local APIC ID is
set in in dev_enumerate()
end
device domain 0 on
Thanks,
Sumo
On Fri, Apr 24, 2020 at 12:50 PM Jay Talbott <
jaytalb...@sysproconsulting.com> wrote:
> Nitin,
>
> We have encountered both of these issues and have corrected them in our own
> code base for a particular client. We are not in a position to upstream our
> changes, but I can tell you the source of each problem.
>
> 1. CPU frequency: For Denverton SKUs that do NOT support turbo mode (like
> the one you are using), the code does not properly enable speedstep. The
> code needs to be modified to correctly enable speedstep in the case of a
> SKU
> that does not support turbo mode.
>
> 2. Linux log: For Denverton SKUs with less than 16 cores, processor 0 is
> not
> guaranteed to have an APIC ID of 0 (as specified in devicetree). If you
> know the APIC ID of processor 0 and change devicetree to match, the problem
> you are seeing will go away. However, that's not a generalized solution, as
> the APIC ID can be different from SKU to SKU and, I believe, even between
> different parts of the same SKU (other than 16-core SKUs). So the code
> needs
> to be modified to use the actual APIC ID of processor 0 instead of the
> fixed
> value specified in devicetree.
>
> The original code developed by Intel was tested using a Harcuvar CRB with a
> 16-core SKU that supports turbo mode, and that's why neither of these
> issues
> were discovered in the original implementation.
>
> Without actually looking at the code, I believe both of these can be fixed
> in src/soc/intel/denverton_ns/cpu.c.
>
> - Jay
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> Gilbert, AZ 85298
> (480) 704-8045
> (480) 445-9895 (FAX)
> jaytalb...@sysproconsulting.com
> http://www.sysproconsulting.com
>
> > -Original Message-
> > From: nitin.ramesh.si...@gmail.com [mailto:nitin.ramesh.si...@gmail.com]
> > Sent: Friday, April 24, 2020 5:35 AM
> > To: coreboot@coreboot.org
> > Subject: [coreboot] Re: Regarding Intel CPU frequency (Intel Denverton
> > based)
> >
> > Hi Paul,
> >
> > As far as cpu init is concerned, I haven't modified the cpu
> initialization
> > sequence for the given board. The code is located under following sub-
> > folder "src/soc/intel/denverton_ns/cpu.c".
> >
> > The given CPU (CPU C3558) has 4 cores, and I am noticing the following
> logs
> > while booting up,
> > which I am trying to debug in parallel by inserting some delays.
> >
> > The wakeup fails for cpu (core) 1, but it continues and passes for 2,3,4.
> > So at the end, cores are getting recognized as CPU 0,2,3,4 respectively.
> >
> > There are few records available for the same sort of cases:
> > https://lore.kernel.org/lkml/0bc26e9524533c38fdbdc95eed2b1448@teksavv
> > y.com/T/
> >
> >
> > " 1.620879] x86: Booting SMP configuration:
> > [1.624592] node #0, CPUs: #1
> > [ 11.624587] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> > [ 11.632919] #2 #3
[coreboot] Re: Regarding Intel CPU frequency.
Hi,
Looks like for this SoC turbo state is not available, so try the following
(enable speedstep regardless if turbo state is available or not, as you
need speedstep!) :
--- a/src/soc/intel/denverton_ns/cpu.c
+++ b/src/soc/intel/denverton_ns/cpu.c
@@ -71,11 +71,11 @@ static void denverton_core_init(struct device *cpu)
enable_turbo();
/* Enable speed step. */
- if (get_turbo_state() == TURBO_ENABLED) {
+// if (get_turbo_state() == TURBO_ENABLED) {
msr = rdmsr(IA32_MISC_ENABLE);
msr.lo |= SPEED_STEP_ENABLE_BIT;
wrmsr(IA32_MISC_ENABLE, msr);
- }
+// }
}
King regards,
Sumo
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Atom Denverton processor and memory are very slow.
Hi, One additional thing happening in your system (not sure if this is related to the slowdown): during the kernel boot there is a delay of about six seconds while kernel is waiting for CPU1: [0.487263] Booting Node 0, Processors #1 [6.543573] CPU1: Not responding. See in the /proc/cpuinfo the core 1 is not listed. This issue is caused by a different processor LAPIC ID of the bootstrap processor... Changing the LAPIC ID in the devicetree.cb file from 0 to 4 will fix this issue, see also: https://mail.coreboot.org/pipermail/coreboot/2018-June/086874.html But my guess is that this is not changing the system performance at all. Probably the only side effect is the bad cpu enumeration... Kind regards, Sumo On Tue, Feb 19, 2019 at 6:56 AM Дмитрий Понаморев wrote: > The processor and memory are very slow. Compiling the ixgbe network card > driver takes 10 minutes. The maximum read speed of DDR4 2133 SODIMM is > 742 MB / sec. > Custom motherboard with Atom Denverton C3538 processor, quad cores 2.1 GHz. > SODIMM module: Crucial DDR4 8Gb 2400MHz CT8G4SFS824A. > BIOS: coreboot 4.9 + intel FSP + seabios. WD Blue WDS250G2B0B 250GB, M.2 > 2280, SATA III Hard Drive. Debian 7 (Linux version 3.2.0-4-amd64 ( > debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 > SMP Debian 3.2.96-2). > > Why the slow operation of the processor and memory is possible? What > settings can be changed in Intel FSP and coreboot to speed up the processor > and memory? > > Full boot log in attached file: putty_com5_coreboot_seabios_debian.zip > > Bandwidth64 memory test: > > This is bandwidth version 1.5.1. > Copyright (C) 2005-2017 by Zack T Smith. > > This software is covered by the GNU Public License. > It is provided AS-IS, use at your own risk. > See the file COPYING for more information. > > CPU family: GenuineIntel > CPU features: MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AES XD Intel64 > > Cache 0: L1 data cache,line size 64, 6-ways,64 sets, size 24k > Cache 1: L1 instruction cache, line size 64, 8-ways,64 sets, size 32k > Cache 2: L2 unified cache, line size 64, 16-ways, 2048 sets, size > 2048k > > Notation: B = byte, kB = 1024 B, MB = 1048576 B. > > CPU speed is 2099.99 MHz. > > Sequential read (64-bit), size = 128 B, loops = 30408704, 741.4 MB/s > Sequential read (64-bit), size = 256 B, loops = 15204352, 741.2 MB/s > Sequential read (64-bit), size = 384 B, loops = 10136196, 741.4 MB/s > Sequential read (64-bit), size = 512 B, loops = 7602176, 740.9 MB/s > Sequential read (64-bit), size = 640 B, loops = 6186563, 742.6 MB/s > Sequential read (64-bit), size = 768 B, loops = 5155479, 742.7 MB/s > Sequential read (64-bit), size = 896 B, loops = 4418982, 742.7 MB/s > Sequential read (64-bit), size = 1024 B, loops = 3866624, 742.7 MB/s > Sequential read (64-bit), size = 1280 B, loops = 3040824, 742.3 MB/s > Sequential read (64-bit), size = 2 kB, loops = 1933312, 742.7 MB/s > Sequential read (64-bit), size = 3 kB, loops = 1288855, 742.5 MB/s > Sequential read (64-bit), size = 4 kB, loops = 966656, 742.6 MB/s > Sequential read (64-bit), size = 6 kB, loops = 644398, 742.6 MB/s > Sequential read (64-bit), size = 8 kB, loops = 475136, 742.4 MB/s > Sequential read (64-bit), size = 12 kB, loops = 316738, 735.7 MB/s > Sequential read (64-bit), size = 16 kB, loops = 237568, 736.2 MB/s > Sequential read (64-bit), size = 20 kB, loops = 190008, 734.7 MB/s > Sequential read (64-bit), size = 24 kB, loops = 152880, 708.7 MB/s > Sequential read (64-bit), size = 28 kB, loops = 70200, 374.0 MB/s > Sequential read (64-bit), size = 32 kB, loops = 61440, 371.4 MB/s > Sequential read (64-bit), size = 34 kB, loops = 57810, 371.2 MB/s > Sequential read (64-bit), size = 36 kB, loops = 52780, 371.1 MB/s > Sequential read (64-bit), size = 40 kB, loops = 49140, 371.2 MB/s > Sequential read (64-bit), size = 48 kB, loops = 40950, 371.3 MB/s > Sequential read (64-bit), size = 64 kB, loops = 30720, 371.3 MB/s > Sequential read (64-bit), size = 128 kB, loops = 14848, 368.6 MB/s > Sequential read (64-bit), size = 192 kB, loops = 9889, 368.9 MB/s > Sequential read (64-bit), size = 256 kB, loops = 7424, 368.9 MB/s > Sequential read (64-bit), size = 320 kB, loops = 5916, 369.6 MB/s > Sequential read (64-bit), size = 384 kB, loops = 4930, 369.6 MB/s > Sequential read (64-bit), size = 512 kB, loops = 3712, 369.6 MB/s > Sequential read (64-bit), size = 768 kB, loops = 2465, 369.6 MB/s > Sequential read (64-bit), size = 1 MB, loops = 1856, 369.6 MB/s > Sequential read (64-bit), size = 1.25 MB, loops = 1479, 369.5 MB/s > Sequential read (64-bit), size = 1.5 MB, loops = 1260, 369.4 MB/s > Sequential read (64-bit), size = 1.75 MB, loops = 1080, 366.9 MB/s > Sequential read (64-bit), size = 2 MB, loop
[coreboot] Re: Refactor tianocore payload
Hi, It seems the Tianocore Coreboot payload (CorebootPayloadPkg/CorebootModulePkg) will be replaced in future by UefiPayloadPkg... See also: https://firmwaresecurity.com/2018/09/14/uefipayloadpkg-uefi-payload-project-supports-coreboot-and-slim-bootloader/ The preliminary implementation is available in: https://github.com/tianocore/edk2-staging/tree/UEFIPayload Kind regards, Sumo On Thu, Feb 14, 2019 at 8:09 PM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote: > Also, there may be users interested in the "whole" UEFI experience, > with secure boot validating binaries loaded from a https server via > their infiniband controllers and IPoIB implemented by on-PCIe firmware > delivered as EBC bytecode. I don't see yabits providing support for > that. > > > Patrick > > Am Do., 14. Feb. 2019 um 23:05 Uhr schrieb Matt DeVillier > : > > > > On Thu, Feb 14, 2019 at 3:11 PM Nico Huber wrote: > >> > >> On 14.02.19 09:28, Patrick Rudolph wrote: > >> > On Wed, 2019-02-13 at 10:15 +0100, Nico Huber wrote: > >> >> On 13.02.19 09:45, Patrick Rudolph wrote: > >> >>> With UEFI the defactor standard it seems reasonable to improve the > >> >>> tianocore payload integration. > >> >> > >> >> I agree that UEFI may seem ubiquitous (we've slept too long, never > pro- > >> >> vided an alternative), but why should we focus on tianocore? > >> >> > >> >> Tianocore isn't the only UEFI implementation. There is Yabits and, > IIRC, > >> >> somebody was working on a Boot-Services implementation for Linux > (don't > >> >> know the state of it, though). So why not put the effort into > something > >> >> that benefits our infrastructure more? Yabits uses libpayload, afaik. > >> >> Would be nice to have more payloads upstream that use it. And if > core- > >> >> boot developers would put as much effort into Yabits as they put into > >> >> merely getting tiano to compile, it would likely flourish much > >> >> better. > >> >> > >> > There's yabits as payload integration in coreboot already. > >> > > >> > Yabits didn't receive updates in the last few month. Looking at the > >> > code base it's more a Proof-of-Concept. > >> > >> I fear it'll stay this way if everybody interested in UEFI runs after > >> Tianocore. Open-source development isn't about waiting for somebody > >> else to do the job. At least, it wasn't always. > > > > > > I think these are completely separate issues however: one being > providing a > > working Tianocore implementation to users who need a payload with EFI > > boot support, and the other being the best place to focus development > effort. > > > > I've gone ahead and created a new 'coreboot' branch based on my fbgop > branch, > > with a little bit of cleanup. We can offer that as a working (or even > default) option, > > and then figure out the best path forward. But it's pretty minimal > effort to offer a > > better working default option > > > >> > >> > >> Nico > >> ___ > >> coreboot mailing list -- coreboot@coreboot.org > >> To unsubscribe send an email to coreboot-le...@coreboot.org > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] USB cannot work
USB works a charm using CorebootPayloadPkg from Tianocore/EDK2 instead of using GRUB2 as payload (you can use grub anyway to load linux later on, or use any other bootloader without sticking this in the SPI flash image). Em qua, 22 de ago de 2018 às 07:45, Hilbert Tu(杜睿哲_Pegatron) < hilbert...@pegatroncorp.com> escreveu: > Hi Nico, > > Confused. > 1. I saw " pch: usb_xhci_init" in the boot up log and I think xHCI > controller was initialized by coreboot > 2. I have used coreboot with grub for Intel Rangeley and BDX-DE platform, > the USB interface were working with xHCI controller. That means grub has > its own xHCI driver. > 3. I am trying u-boot as payload now. > > Sorry I really don't well understand coreboot and grub :P > > -Hilbert > > -Original Message- > From: Nico Huber [mailto:nico.hu...@secunet.com] > Sent: Wednesday, August 22, 2018 4:38 PM > To: Hilbert Tu(杜睿哲_Pegatron); coreboot@coreboot.org > Subject: Re: [coreboot] USB cannot work > > Hi Hilbert, > > Am 22.08.18 um 03:24 schrieb Hilbert Tu(杜睿哲_Pegatron): > > Maybe you are right. But as I know, CRB Harcuvar is one of supported > > board of Coreboot and it includes xHCI controller and USB interfaces. > > Harcuvar is indeed supported by coreboot. But coreboot only initializes > the hardware up to a point where an OS or bootloader can use it. The OS > or bootloader still needs its own driver for the hardware. This is very > different as in the legacy BIOS/UEFI case (a BIOS would provide a driver > but coreboot doesn't). > > So if you want to use GRUB as a coreboot payload and use USB, GRUB needs > its own driver for the xHCI. I would first try to confirm if or if not > the xHCI works with other payloads (e.g. SeaBIOS, Tianocore, libpayload > based) or an OS. > > Nico > This e-mail and its attachment may contain information that is > confidential or privileged, and are solely for the use of the individual to > whom this e-mail is addressed. If you are not the intended recipient or > have received it accidentally, please immediately notify the sender by > reply e-mail and destroy all copies of this email and its attachment. > Please be advised that any unauthorized use, disclosure, distribution or > copying of this email or its attachment is strictly prohibited. > > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。 > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Enabling SpeedStep for all Denverton SoC variants
Thanks Julien! I´ll submit a patch to Gerrit soon. BTW, have you noticed that Linux is always showing an additional CPU in the /sys/devices/system/cpu/ folder? Here, for a quad-core CPU I have the following: pinelake:~ # ll /sys/devices/system/cpu/cpu* total 0 drwxr-xr-x 9 root root0 May 29 22:46 cpu0 drwxr-xr-x 4 root root0 May 29 22:46 cpu1 drwxr-xr-x 9 root root0 May 29 22:46 cpu2 drwxr-xr-x 9 root root0 May 29 22:46 cpu3 drwxr-xr-x 9 root root0 May 29 22:46 cpu4 pinelake:~ # cat /sys/devices/system/node/node0/cpumap 1d pinelake:~ # cat /sys/devices/system/node/node0/cpulist 0,2-4 And during the Linux boot I see the following error: [ 10.116007] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1 Looks like the issue in my case is caused by a wrong LAPIC value for the BSP CPU in the devicetree.cb... The coreboot log shows: IOAPIC: Bootstrap Processor Local APIC = 0x04 But in the devicetree.cb we have: device cpu_cluster 0 on device lapic 0 on end end If I change the lapic value from 0 to 4 then Linux is not complaining about do_boot_cpu failed... and sysfs shows the correct amount of CPU´s: pinelake:~ # ll /sys/devices/system/cpu/cpu* total 0 drwxr-xr-x 9 root root0 May 29 22:46 cpu0 drwxr-xr-x 4 root root0 May 29 22:46 cpu1 drwxr-xr-x 9 root root0 May 29 22:46 cpu2 drwxr-xr-x 9 root root0 May 29 22:46 cpu3 linux-80my:~ # cat /sys/devices/system/node/node0/cpumap f linux-80my:~ # cat /sys/devices/system/node/node0/cpulist 0-3 Please let me know if this happens to you and if the same fix can be applied! Thanks, Sumo 2018-06-04 9:46 GMT-03:00 Julien Viard de Galbert < jviarddegalb...@online.net>: > > > Le 29 mai 2018 à 16:48, Sumo a écrit : > > Hi, > > Today denverton_core_init() is enabling the Intel SpeedStep only if turbo > mode is available. As a result, the SpeedStep is not enable for the C3558 > variant (and others). Any clues of why it was implemented this way? > > I think it is safe to remove the "if (get_turbo_state() == TURBO_ENABLED)" > test and always enable the SpeedStep technology. > > > You are right, I also think it’s safe. (The variant I have access to have > Turbo so I can’t test it). > I also have no clue, but it was like this since the first denverton > commit… > So please test and submit a patch ;) > > Best Regads > Julien > > > Thanks, > Sumo > > > > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > Julien Viard de Galbert - jviarddegalb...@online.net > Online / Scaleway > Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ > > > > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Enabling SpeedStep for all Denverton SoC variants
Hi, Today denverton_core_init() is enabling the Intel SpeedStep only if turbo mode is available. As a result, the SpeedStep is not enable for the C3558 variant (and others). Any clues of why it was implemented this way? I think it is safe to remove the "if (get_turbo_state() == TURBO_ENABLED)" test and always enable the SpeedStep technology. Thanks, Sumo -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Missing ACPI ASL code for Denverton GPIO controller
Hi Julien, Yes, I'm interested. But no need to hurry up, do it in your own time. ;) Thanks, Sumo 2018-03-27 6:54 GMT-03:00 Julien Viard de Galbert < jviarddegalb...@online.net>: > > > Le 26 mars 2018 à 21:24, Sumo <kingsu...@gmail.com> a écrit : > > Hi all, > > > Hi Sumo, > > > We have a kernel patch which adds pinctrl/GPIO support for Intel Denverton > SoC (https://patchwork.kernel.org/patch/9879473/) to make possible to > access the GPIO from user space (via sysfs, i.e. > /sys/kernel/debug/pinctrl/), however this patch is expects a "INTC3000" > GPIO controller definition in the ACPI tables. > I want to add/implement the INTC3000 in the ASL code, but since I don´t > want to reinvent the wheel I´m asking if such ASL code is already available > somewhere (at least in the Intel Pine Lake CRB there´s no such reference to > INTC3000 in the ACPI tables). > > I have a set of patches that still need some work ( > https://review.coreboot.org/c/coreboot/+/24928) that enable some shared > code for GPIO; following I also have more patches to use the ACPI code from > common block too (not published yet). I didn’t check but probably > apollolake or cannonlake has the ACPI code for GPIO (using common block). > If you are interested I can probably work on adding the ACPI > implementation to Gerrit sooner. > > Best Regards, > > Julien > > Thanks, > Sumo > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > Julien Viard de Galbert - jviarddegalb...@online.net > Online / Scaleway > Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ > > > > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Missing ACPI ASL code for Denverton GPIO controller
Hi all, We have a kernel patch which adds pinctrl/GPIO support for Intel Denverton SoC (https://patchwork.kernel.org/patch/9879473/) to make possible to access the GPIO from user space (via sysfs, i.e. /sys/kernel/debug/pinctrl/), however this patch is expects a "INTC3000" GPIO controller definition in the ACPI tables. I want to add/implement the INTC3000 in the ASL code, but since I don´t want to reinvent the wheel I´m asking if such ASL code is already available somewhere (at least in the Intel Pine Lake CRB there´s no such reference to INTC3000 in the ACPI tables). Thanks, Sumo -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Atom c3000 Harcuvar and Intel ME
> When configuring CB with menuconfig you have to select your platform > and type in the path to your ME-binary-blob. For the Harcuvar CRB there is no such configuration. This conf. is available to other mainboards (e.g. Intel "Little Plains" mainboard: menu "Chipset"->"Intel Firmware"->"Add Intel descriptor.bin file"->"Add Intel ME/TXE firmware"->"Path to management engine firmware"). Maybe for the Harcuvar CRB the Intel ME FW is installed in the second SPI flash, therefore there is no need to add the ME blob in the coreboot build? I´m not sure about this, some board maintainer can confirm this? Do we have any documentation regarding the coreboot port for Harcuvar? Thanks, Sumo 2018-02-26 19:42 GMT-03:00 Philipp Stanner <stan...@posteo.de>: > Am Montag, den 26.02.2018, 17:14 -0300 schrieb Sumo: > > Hi, > > > > In the coreboot build menu there is no option regarding the Intel ME > > integration. > > The 'coreboot.rom' file is the full SPI flash image or this file is > > suitable to > > replace the BIOS region of the SPI flash (0x0080--0x00ff)? > > (i.e. in the SPI flash we already have a region for Intel ME > > firmware) > > I'm not sure what the question is. > > When configuring CB with menuconfig you have to select your platform > and type in the path to your ME-binary-blob. The later has to be > provided by you; meaning you have to extract the BIOS from the flash, > extract the ME-binary using coreboot/utils, clean it with ME-cleaner > (optional) and then build coreboot with your blob. > > The toolchain takes care automatically about the correct placement of > the ME in the right address-ranges. > > I hope this was helpful. > > > Thanks, > > Sumo > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Atom c3000 Harcuvar and Intel ME
Hi, In the coreboot build menu there is no option regarding the Intel ME integration. The 'coreboot.rom' file is the full SPI flash image or this file is suitable to replace the BIOS region of the SPI flash (0x0080--0x00ff)? (i.e. in the SPI flash we already have a region for Intel ME firmware) Thanks, Sumo -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
