PEI-less flow dispatch DXE twice in VF2

[John Chew]

Hi everyone,

Good day!

In the past few weeks, LiYong and I have been working closely to bring up PEI-less flow in Vision Five 2 SBC. 

During the porting process, we notice that all the DXE packages defined in "APRIORI DXE" section will be dispatched twice (refer to the image below).  However, this behavior is not seen in Qemu.


Below are some findings for this issue:

During DXE driver dispatch, firmware volume is not found in HobFv2.

So, the dispatcher proceeds to call “CoreProcessFvImageFile” in "..edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c". On the first "Fv->ReadSection", Qemu returns "EFI_PROTOCOL_ERROR" in CoreSectionExtraction.c:1107, while, VF2 returns "SUCCESS". If "SUCCESS", the code will proceed to produce "FVB Protocol On Buffer" which result in multiple "NotifyFwVolBlock".   

Questions:
1. Is it normal that Fv2Hob GUID name is "0000...0000" ?
Using the existing SEC -> PEI -> DXE flow, the Fv2Hob GUID name is "27A72E80-3118-4c0c-8673-AA5B4EFA9613"


2. Is there any issue with "Fv->ReadSection" in "..edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c" returns "EFI_PROTOCOL_ERROR" in Qemu?

Project repository:
edk2: https://github.com/johnchewyy/edk2/tree/vf2_jh7110_devel_peiless_multiarch
edk2-platform: https://github.com/johnchewyy/edk2-platforms/tree/vf2_jh7110_devel_peiless_multiarch

Please let me know if any of you have any thoughts on this.

Thank you! =D

- John -

[Li, Yong]

Hi,

 

Some background here is that StarFive has ported and enabled EDK2 to their VF2 platform,  but that enablement is based on original Sifive U5 port which takes opensbi as a lib of edk2.

By following Sunil proposal attached,  Yuinyee from StarFive is trying to clean-up the code and transferring the edk2 implementation to follow new proposal based on RIscVVirt flow.

 

I guess this is the first RISC-V real platform to follow the edk2 implementation proposal.  Currently the basic function of this new implementation on VF2 board is working,  but still some tricky issues to be solved like below.

Thanks so much if you can give some feedback.

 

Thanks,

Yong Li

 

From: John Chew <yuinye...@starfivetech.com>
Sent: Wednesday, August 2, 2023 2:29 PM
To: RISC-V Firmware Exchange <fw-ex...@riscv.org>
Cc: Li, Yong <yon...@intel.com>
Subject: PEI-less flow dispatch DXE twice in VF2

 

Hi everyone,

Good day!

In the past few weeks, LiYong and I have been working closely to bring up PEI-less flow in Vision Five 2 SBC. 

During the porting process, we notice that all the DXE packages defined in "APRIORI DXE" section will be dispatched twice (refer to the image below).  However, this behavior is not seen in Qemu.

Below are some findings for this issue:

During DXE driver dispatch, firmware volume is not found in HobFv2.

So, the dispatcher proceeds to call “CoreProcessFvImageFile” in "..edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c". On the first "Fv->ReadSection", Qemu returns "EFI_PROTOCOL_ERROR" in CoreSectionExtraction.c:1107, while, VF2 returns "SUCCESS". If "SUCCESS", the code will proceed to produce "FVB Protocol On Buffer" which result in multiple "NotifyFwVolBlock".   

Questions:
1. Is it normal that Fv2Hob GUID name is "0000...0000" ?
Using the existing SEC -> PEI -> DXE flow, the Fv2Hob GUID name is "27A72E80-3118-4c0c-8673-AA5B4EFA9613"

2. Is there any issue with "Fv->ReadSection" in "..edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c" returns "EFI_PROTOCOL_ERROR" in Qemu?

Project repository:
edk2: https://github.com/johnchewyy/edk2/tree/vf2_jh7110_devel_peiless_multiarch
edk2-platform: https://github.com/johnchewyy/edk2-platforms/tree/vf2_jh7110_devel_peiless_multiarch

Please let me know if any of you have any thoughts on this.

Thank you! =D

- John -

--
You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/f8e4e681-c198-4c14-a92b-adddce6b9c39n%40riscv.org.

[Sunil V L]

Hi John, Yong,

My guess if it is probably getting into to an compressed DXE. Are you booting EDK2 from flash or RAM? I see you have flash support but I am confused with FW_BASE_ADDRESS looking like RAM address since temporary stack is at 0x43FF0000.  If your intention is to boot from SPI flash, can you try changing FW_BASE_ADDRESS? Do you mind sharing complete boot log as text file?

Happy to see you are moving to payload option!

Thanks,

Sunil

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/BY5PR11MB386186CB2744D69BFB969A57FB0BA%40BY5PR11MB3861.namprd11.prod.outlook.com.

[Sunil V L]

Also, APRIORI is not recommended in general. See if you can avoid it.

[Tuan Phan]

Hi Yong/John,

I am seeing some issues based on your writing. Not that this is my observation

1. QEMU creates FV with zero name because it is missing define FV name in FDT that should be fixed. You can check your FDT if FvNameGuid exists in each FV.

[FV.DXEFV]

FvNameGuid         = 27A72E80-3118-4c0c-8673-AA5B4EFA9614

2. QEMU returns PROTOCOL_ERROR as it has guided section (compressed) that processed nicely in PEI.

 

To your issue, I think it can be fixed by:

-  Remove FVMAIN_COMPACT as you are not using PEI. Also it may help BuildFv2Hob picks up correct FvName for FV.DXEFV instead of FVMAIN_COMPACT in your case.

 

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/c85c7369-a971-b78e-d496-0361fd793cd2%40ventanamicro.com.