Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Hi Ard, Thanks, Chao On 2024/5/6 18:24, Ard Biesheuvel wrote: On Mon, 6 May 2024 at 12:02, Chao Li wrote: Hi Gerd, Thanks, Chao On 2024/3/19 16:03, Gerd Hoffmann wrote: Hi, I can't tell the implementation scheme of the current lib and existing lib implementation scheme which one is better, Could you give we some advice? I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as it is not really loongarch-specific. If you want try switch aarch64 to use the same code that'll be great, but sorting that out later is also fine with me. If you think this design is looks better, then I'm prepare to commit this change under the OvmfPkg/Library as a public library. And I will enable it in aarch64 after merging this change, because I think it may be tweaked and validated in aarch64 for many platforms. Do you think that is good? The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to avoid switching between read and write mode much, because that operation has a significant overhead in virtualization. So it's really only used by ArmVirtPkg and not lots of other arm platforms. I'm moving the ARM version of the library to OvmfPkg and adding the set PCD method, I have verified successfully on ArmVirtQemu.dsc(both -bios and pflash), but I found that the ArmVirtQemuKernel.dsc also depends this library, so what's the difference between the two platforms? When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bios option, I use the command line "qemu-system-aarch64 -M virt -cpu cortex-a57 -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb /home/lichao/Software/Qemu/SctPkg/share.imag -device ramfb -device nec-usb-xhci -device usb-mouse -device usb-kbd", and it tells me "Could not open option rom 'vgabios-ramfb.bin': No such file or directory", I tried removing the option "-device ramfb", it looks like can't work. How does ArmVirtQemuKernel.dsc work? It uses the -kernel QEMU command line argument, not the -bios one. This uses the Linux/arm64 kernel boot protocol (and runs the firmware entirely from RAM) rather than booting from NOR flash. Alright, I got it. Does this mean that after this change, I just verify that the -kernel command line can boot the OS and that it can load/store some variables via the Linux OS? If so, I have some plans: 1. Port the ARM version to OvmfPkg and add the setting PCD method. *Done*. 2. Enable the new library on ArmVirtQemu.dsc and remove the hardcode in INC file, verify this platform. *Done*. 3. Enable the new library on ArmVirtQemuKernel.dsc and verify this platform. *Just verfiy booting OS and load/store some variables via Linux kernel. In progress.* 4. Remove the ARM NorFlashQemuLib. *Pending.* Is the plans mentioned above possible? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118625): https://edk2.groups.io/g/devel/message/118625 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
On Mon, 6 May 2024 at 12:02, Chao Li wrote: > > Hi Gerd, > > > Thanks, > Chao > On 2024/3/19 16:03, Gerd Hoffmann wrote: > > Hi, > > I can't tell the implementation scheme of the current lib and existing > lib implementation scheme which one is better, Could you give we some > advice? > > I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as > it is not really loongarch-specific. > > If you want try switch aarch64 to use the same code that'll be great, > but sorting that out later is also fine with me. > > If you think this design is looks better, then I'm prepare to commit this > change under the OvmfPkg/Library as a public library. And I will enable it > in aarch64 after merging this change, because I think it may be tweaked and > validated in aarch64 for many platforms. Do you think that is good? > > The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to > avoid switching between read and write mode much, because that operation > has a significant overhead in virtualization. So it's really only used > by ArmVirtPkg and not lots of other arm platforms. > > I'm moving the ARM version of the library to OvmfPkg and adding the set PCD > method, I have verified successfully on ArmVirtQemu.dsc(both -bios and > pflash), but I found that the ArmVirtQemuKernel.dsc also depends this > library, so what's the difference between the two platforms? > > When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bios > option, I use the command line "qemu-system-aarch64 -M virt -cpu cortex-a57 > -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb > /home/lichao/Software/Qemu/SctPkg/share.imag -device ramfb -device > nec-usb-xhci -device usb-mouse -device usb-kbd", and it tells me "Could not > open option rom 'vgabios-ramfb.bin': No such file or directory", I tried > removing the option "-device ramfb", it looks like can't work. > > How does ArmVirtQemuKernel.dsc work? > It uses the -kernel QEMU command line argument, not the -bios one. This uses the Linux/arm64 kernel boot protocol (and runs the firmware entirely from RAM) rather than booting from NOR flash. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118595): https://edk2.groups.io/g/devel/message/118595 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Hi Gerd, Thanks, Chao On 2024/3/19 16:03, Gerd Hoffmann wrote: Hi, I can't tell the implementation scheme of the current lib and existing lib implementation scheme which one is better, Could you give we some advice? I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as it is not really loongarch-specific. If you want try switch aarch64 to use the same code that'll be great, but sorting that out later is also fine with me. If you think this design is looks better, then I'm prepare to commit this change under the OvmfPkg/Library as a public library. And I will enable it in aarch64 after merging this change, because I think it may be tweaked and validated in aarch64 for many platforms. Do you think that is good? The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to avoid switching between read and write mode much, because that operation has a significant overhead in virtualization. So it's really only used by ArmVirtPkg and not lots of other arm platforms. I'm moving the ARM version of the library to OvmfPkg and adding the set PCD method, I have verified successfully on ArmVirtQemu.dsc(both -bios and pflash), but I found that the ArmVirtQemuKernel.dsc also depends this library, so what's the difference between the two platforms? When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bios option, I use the command line "qemu-system-aarch64 -M virt -cpu cortex-a57 -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb /home/lichao/Software/Qemu/SctPkg/share.imag -device ramfb -device nec-usb-xhci -device usb-mouse -device usb-kbd", and it tells me "Could not open option rom 'vgabios-ramfb.bin': No such file or directory", I tried removing the option "-device ramfb", it looks like can't work. How does ArmVirtQemuKernel.dsc work? Doing it separate from this patch series makes sense nevertheless. Speaking of this series: maybe split it into two? The first part of this series with the Mde*Pkg + UefiPkg changes looks almost ready to merge to me, so maybe we can get that in while still sorting out the remaining issues in the OvmfPkg patches ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118594): https://edk2.groups.io/g/devel/message/118594 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
On Tue, Mar 19, 2024 at 05:10:39PM +0800, Chao Li wrote: > He Gerd, > > > Speaking of this series: maybe split it into two? The first part > > of this series with the Mde*Pkg + UefiPkg changes looks almost ready > > to merge to me, so maybe we can get that in while still sorting out > > the remaining issues in the OvmfPkg patches ... > > This series does not include changes to Mde*Pkg , so if the patches are > separated, Oh, right, Mde*Pkg was splitted before and is merged already. > I think it might be two series, one is the UefiCpuPkg series, and > other is OvmfPkg. Agree. > I tend to split patches into two series. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116889): https://edk2.groups.io/g/devel/message/116889 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
He Gerd, Thanks, Chao On 2024/3/19 16:03, Gerd Hoffmann wrote: Hi, I can't tell the implementation scheme of the current lib and existing lib implementation scheme which one is better, Could you give we some advice? I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as it is not really loongarch-specific. If you want try switch aarch64 to use the same code that'll be great, but sorting that out later is also fine with me. If you think this design is looks better, then I'm prepare to commit this change under the OvmfPkg/Library as a public library. And I will enable it in aarch64 after merging this change, because I think it may be tweaked and validated in aarch64 for many platforms. Do you think that is good? The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to avoid switching between read and write mode much, because that operation has a significant overhead in virtualization. So it's really only used by ArmVirtPkg and not lots of other arm platforms. Doing it separate from this patch series makes sense nevertheless. Speaking of this series: maybe split it into two? The first part of this series with the Mde*Pkg + UefiPkg changes looks almost ready to merge to me, so maybe we can get that in while still sorting out the remaining issues in the OvmfPkg patches ... This series does not include changes to Mde*Pkg , so if the patches are separated, I think it might be two series, one is the UefiCpuPkg series, and other is OvmfPkg. Just like you saied, if this series is split into two, and the series 1 finds some bugs when we sorting out the OvmfPkg, then we have to submit other pathes to fix them. So what do you think? I think each plan has it's own benefits. I tend to split patches into two series. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116882): https://edk2.groups.io/g/devel/message/116882 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Hi, > > > I can't tell the implementation scheme of the current lib and existing > > > lib implementation scheme which one is better, Could you give we some > > > advice? > > I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as > > it is not really loongarch-specific. > > > > If you want try switch aarch64 to use the same code that'll be great, > > but sorting that out later is also fine with me. > > If you think this design is looks better, then I'm prepare to commit this > change under the OvmfPkg/Library as a public library. And I will enable it > in aarch64 after merging this change, because I think it may be tweaked and > validated in aarch64 for many platforms. Do you think that is good? The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to avoid switching between read and write mode much, because that operation has a significant overhead in virtualization. So it's really only used by ArmVirtPkg and not lots of other arm platforms. Doing it separate from this patch series makes sense nevertheless. Speaking of this series: maybe split it into two? The first part of this series with the Mde*Pkg + UefiPkg changes looks almost ready to merge to me, so maybe we can get that in while still sorting out the remaining issues in the OvmfPkg patches ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116879): https://edk2.groups.io/g/devel/message/116879 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Hi Gerd,
Thanks,
Chao
On 2024/3/18 23:21, Gerd Hoffmann wrote:
On Sat, Mar 16, 2024 at 06:19:00PM +0800, lixianglai wrote:
Hi Gerd:
On Mon, Mar 11, 2024 at 02:39:24AM -0700, Chao Li wrote:
Add NorFlashQemuLib for LoongArch, it is referenced from ArmVirtPkg.
What are the differences to the ArmVirtPkg version?
In this lib we have assigned the following three pcd variables:
PcdFlashNvStorageVariableBase
PcdFlashNvStorageFtwWorkingBase
PcdFlashNvStorageFtwSpareBase
Instead of hardcoding these three variables in the VarStore.fdf.inc file as arm
does,
the benefit is that when the flash base address changes in the qemu
implementation,
there is no need to re-adapt and compile UEFI.
The flash memory layout (address + size) for the aarch64 virt machine
has never changed. So while it sounds nice in theory to have that
option it could very well be that this will never ever needed in
practice.
Having sayed that I'd also note that I think it should also be possible
to switch the aarch64 builds to set the PCDs at runtime instead of
compile time.
When I tried to implement the current patch scheme on aarch64,
I found that the FaultTolerantWriteDxe driver loaded earlier than
VirtNorFlashDxe.
And It requires the PcdFlashNvStorageFtwWorkingSize and
PcdFlashNvStorageFtwSpareSize variables for initialization,
However the initialization of these two variables is completed in
VirtNorFlashDxe,
The fdf file specifies that VirtNorFlashDxe is loaded first and then
FaultTolerantWriteDxe is loaded in loongarch64.
So this is going to be a problem if we want to apply the current solution to
aarch64 or risc-v.
There is a non-obvious twist:
VirtNorFlashDxe registers the gEdkiiNvVarStoreFormattedGuid protocol.
There is the
EmbeddedPkg/Library/NvVarStoreFormattedLib/NvVarStoreFormattedLib.inf
library, which only purpose is to add a dependency to
gEdkiiNvVarStoreFormattedGuid to depex.
NvVarStoreFormattedLib.inf is used this way ...
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
A
[ ... ]
NULL|EmbeddedPkg/Library/NvVarStoreFormattedLib/NvVarStoreFormattedLib.inf
[ ... ]
}
... to make sure VariableRuntimeDxe is scheduled after VirtNorFlashDxe.
I think you can apply the same idea to FaultTolerantWriteDxe.
I can't tell the implementation scheme of the current lib and existing
lib implementation scheme which one is better, Could you give we some
advice?
I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
it is not really loongarch-specific.
If you want try switch aarch64 to use the same code that'll be great,
but sorting that out later is also fine with me.
If you think this design is looks better, then I'm prepare to commit
this change under the OvmfPkg/Library as a public library. And I will
enable it in aarch64 after merging this change, because I think it may
be tweaked and validated in aarch64 for many platforms. Do you think
that is good?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116875): https://edk2.groups.io/g/devel/message/116875
Mute This Topic: https://groups.io/mt/104859896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
On Sat, Mar 16, 2024 at 06:19:00PM +0800, lixianglai wrote:
> Hi Gerd:
> > On Mon, Mar 11, 2024 at 02:39:24AM -0700, Chao Li wrote:
> >> Add NorFlashQemuLib for LoongArch, it is referenced from ArmVirtPkg.
> > What are the differences to the ArmVirtPkg version?
> In this lib we have assigned the following three pcd variables:
> PcdFlashNvStorageVariableBase
> PcdFlashNvStorageFtwWorkingBase
> PcdFlashNvStorageFtwSpareBase
> Instead of hardcoding these three variables in the VarStore.fdf.inc file as
> arm does,
> the benefit is that when the flash base address changes in the qemu
> implementation,
> there is no need to re-adapt and compile UEFI.
The flash memory layout (address + size) for the aarch64 virt machine
has never changed. So while it sounds nice in theory to have that
option it could very well be that this will never ever needed in
practice.
Having sayed that I'd also note that I think it should also be possible
to switch the aarch64 builds to set the PCDs at runtime instead of
compile time.
> When I tried to implement the current patch scheme on aarch64,
> I found that the FaultTolerantWriteDxe driver loaded earlier than
> VirtNorFlashDxe.
> And It requires the PcdFlashNvStorageFtwWorkingSize and
> PcdFlashNvStorageFtwSpareSize variables for initialization,
> However the initialization of these two variables is completed in
> VirtNorFlashDxe,
> The fdf file specifies that VirtNorFlashDxe is loaded first and then
> FaultTolerantWriteDxe is loaded in loongarch64.
> So this is going to be a problem if we want to apply the current solution to
> aarch64 or risc-v.
There is a non-obvious twist:
VirtNorFlashDxe registers the gEdkiiNvVarStoreFormattedGuid protocol.
There is the
EmbeddedPkg/Library/NvVarStoreFormattedLib/NvVarStoreFormattedLib.inf
library, which only purpose is to add a dependency to
gEdkiiNvVarStoreFormattedGuid to depex.
NvVarStoreFormattedLib.inf is used this way ...
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
A
[ ... ]
NULL|EmbeddedPkg/Library/NvVarStoreFormattedLib/NvVarStoreFormattedLib.inf
[ ... ]
}
... to make sure VariableRuntimeDxe is scheduled after VirtNorFlashDxe.
I think you can apply the same idea to FaultTolerantWriteDxe.
> I can't tell the implementation scheme of the current lib and existing
> lib implementation scheme which one is better, Could you give we some
> advice?
I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
it is not really loongarch-specific.
If you want try switch aarch64 to use the same code that'll be great,
but sorting that out later is also fine with me.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116842): https://edk2.groups.io/g/devel/message/116842
Mute This Topic: https://groups.io/mt/104859896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Hi Gerd: > On Mon, Mar 11, 2024 at 02:39:24AM -0700, Chao Li wrote: >> Add NorFlashQemuLib for LoongArch, it is referenced from ArmVirtPkg. > What are the differences to the ArmVirtPkg version? In this lib we have assigned the following three pcd variables: PcdFlashNvStorageVariableBase PcdFlashNvStorageFtwWorkingBase PcdFlashNvStorageFtwSpareBase Instead of hardcoding these three variables in the VarStore.fdf.inc file as arm does, the benefit is that when the flash base address changes in the qemu implementation, there is no need to re-adapt and compile UEFI. Other small differences are in the BIOS base address using different PCD variables, and this library only parse a flash rather than more pieces which handles arm Libs better. It is necessary to point out that the original NV variable address space is specified by the bios, and then look for flash in the NV variable address space, while the current lib implementation is given the flash base address as the NV variable address space The former implementation should theoretically be able to map multiple pieces of flash into the NV variable address space, but we currently only add a piece of flash as an NV variable storage space when using it. When I tried to implement the current patch scheme on aarch64, I found that the FaultTolerantWriteDxe driver loaded earlier than VirtNorFlashDxe. And It requires the PcdFlashNvStorageFtwWorkingSize and PcdFlashNvStorageFtwSpareSize variables for initialization, However the initialization of these two variables is completed in VirtNorFlashDxe, The fdf file specifies that VirtNorFlashDxe is loaded first and then FaultTolerantWriteDxe is loaded in loongarch64. So this is going to be a problem if we want to apply the current solution to aarch64 or risc-v. I can't tell the implementation scheme of the current lib and existing lib implementation scheme which one is better, Could you give we some advice? Thanks, Xianglai. > Is it possible to have a FdtNorFlashQemuLib which is shared > between arm and loongarch? And maybe risc-v too? > > take care, > Gerd > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116821): https://edk2.groups.io/g/devel/message/116821 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
On Mon, Mar 11, 2024 at 02:39:24AM -0700, Chao Li wrote: > Add NorFlashQemuLib for LoongArch, it is referenced from ArmVirtPkg. What are the differences to the ArmVirtPkg version? Is it possible to have a FdtNorFlashQemuLib which is shared between arm and loongarch? And maybe risc-v too? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116795): https://edk2.groups.io/g/devel/message/116795 Mute This Topic: https://groups.io/mt/104859896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib
Add NorFlashQemuLib for LoongArch, it is referenced from ArmVirtPkg.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Cc: Bibo Mao
Cc: Dongyan Qian
Signed-off-by: Chao Li
Co-authored-by: Xianglai Li
Co-authored-by: Bibo Mao
Reviewed-by: Bibo Mao
---
.../Library/NorFlashQemuLib/NorFlashQemuLib.c | 140 ++
.../NorFlashQemuLib/NorFlashQemuLib.inf | 43 ++
2 files changed, 183 insertions(+)
create mode 100644
OvmfPkg/LoongArchVirt/Library/NorFlashQemuLib/NorFlashQemuLib.c
create mode 100644
OvmfPkg/LoongArchVirt/Library/NorFlashQemuLib/NorFlashQemuLib.inf
diff --git a/OvmfPkg/LoongArchVirt/Library/NorFlashQemuLib/NorFlashQemuLib.c
b/OvmfPkg/LoongArchVirt/Library/NorFlashQemuLib/NorFlashQemuLib.c
new file mode 100644
index 00..ae9af09c4c
--- /dev/null
+++ b/OvmfPkg/LoongArchVirt/Library/NorFlashQemuLib/NorFlashQemuLib.c
@@ -0,0 +1,140 @@
+/** @file
+
+ Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define QEMU_NOR_BLOCK_SIZE SIZE_128KB
+
+EFI_STATUS
+VirtNorFlashPlatformInitialization (
+ VOID
+ )
+{
+ return EFI_SUCCESS;
+}
+
+STATIC VIRT_NOR_FLASH_DESCRIPTION mNorFlashDevices;
+
+EFI_STATUS
+VirtNorFlashPlatformGetDevices (
+ OUT VIRT_NOR_FLASH_DESCRIPTION **NorFlashDescriptions,
+ OUT UINT32 *Count
+ )
+{
+ FDT_CLIENT_PROTOCOL *FdtClient;
+ INT32Node;
+ EFI_STATUS Status;
+ EFI_STATUS FindNodeStatus;
+ CONST UINT32 *Reg;
+ UINT32 PropSize;
+ UINT64 Base;
+ UINT64 Size;
+
+ Status = gBS->LocateProtocol (
+ ,
+ NULL,
+ (VOID **)
+ );
+ ASSERT_EFI_ERROR (Status);
+
+ FindNodeStatus = FdtClient->FindCompatibleNode (
+FdtClient,
+"cfi-flash",
+
+);
+ ASSERT_EFI_ERROR (FindNodeStatus);
+
+ Status = FdtClient->GetNodeProperty (
+FdtClient,
+Node,
+"reg",
+(CONST VOID **),
+
+);
+ if (EFI_ERROR (Status)) {
+DEBUG ((
+ DEBUG_ERROR,
+ "%a: GetNodeProperty () failed (Status == %r)\n",
+ __func__,
+ Status
+ ));
+return Status;
+ }
+
+ ASSERT ((PropSize % (4 * sizeof (UINT32))) == 0);
+
+ if (PropSize < (4 * sizeof (UINT32))) {
+DEBUG ((
+ DEBUG_ERROR,
+ "%a: reg node size(%d) is too small \n",
+ __func__,
+ PropSize
+ ));
+return EFI_NOT_FOUND;
+ }
+
+ Base = SwapBytes64 (ReadUnaligned64 ((VOID *)[0]));
+ Size = SwapBytes64 (ReadUnaligned64 ((VOID *)[2]));
+
+ mNorFlashDevices.DeviceBaseAddress = (UINTN)Base;
+ mNorFlashDevices.RegionBaseAddress = (UINTN)Base;
+ mNorFlashDevices.Size = (UINTN)Size;
+ mNorFlashDevices.BlockSize = QEMU_NOR_BLOCK_SIZE;
+
+ Status = PcdSet32S (PcdFlashNvStorageVariableBase, Base);
+ ASSERT_EFI_ERROR (Status);
+
+ /*
+ * Base is the value of PcdFlashNvStorageVariableBase,
+ * PcdFlashNvStorageFtwWorkingBase can be got by
+ * PcdFlashNvStorageVariableBase + PcdFlashNvStorageVariableSize
+ */
+ Base += PcdGet32 (PcdFlashNvStorageVariableSize);
+ Status = PcdSet32S (PcdFlashNvStorageFtwWorkingBase, Base);
+ ASSERT_EFI_ERROR (Status);
+
+ /*
+ * Now,Base is the value of PcdFlashNvStorageFtwWorkingBase,
+ * PcdFlashNvStorageFtwSpareBase can be got by
+ * PcdFlashNvStorageFtwWorkingBase + PcdFlashNvStorageFtwWorkingSize.
+ */
+ Base += PcdGet32 (PcdFlashNvStorageFtwWorkingSize);
+ Status = PcdSet32S (PcdFlashNvStorageFtwSpareBase, Base);
+ ASSERT_EFI_ERROR (Status);
+
+ //
+ // UEFI takes ownership of the NOR flash, and exposes its functionality
+ // through the UEFI Runtime Services GetVariable, SetVariable, etc. This
+ // means we need to disable it in the device tree to prevent the OS from
+ // attaching its device driver as well.
+ // Note that this also hides other flash banks, but the only other flash
+ // bank we expect to encounter is the one that carries the UEFI executable
+ // code, which is not intended to be guest updatable, and is usually backed
+ // in a readonly manner by QEMU anyway.
+ //
+ Status = FdtClient->SetNodeProperty (
+FdtClient,
+Node,
+"status",
+"disabled",
+sizeof ("disabled")
+);
+ if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "Failed to set NOR flash status to 'disabled'\n"));
+ }
+
+ *NorFlashDescriptions =
+ *Count
