public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "xianglai" <lixianglai@loongson.cn>
To: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
	devel@edk2.groups.io, lichao@loongson.cn
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Jiewen Yao <jiewen.yao@intel.com>
Subject: Re: [edk2-devel] [PATCH v1 1/2] OvmfPkg: Add no hardcode version of FtdNorFlashQemuLib
Date: Mon, 27 May 2024 11:17:24 +0800	[thread overview]
Message-ID: <38d4d808-69ed-e6a1-7163-1e82d5905e4a@loongson.cn> (raw)
In-Reply-To: <314a58cc-9add-493e-a3d7-fd77edf77999@linaro.org>

Hi Marcin:
> W dniu 17.05.2024 o 09:17, Chao Li via groups.io pisze:
>> This library is copied from ArmVirtPkg, in the Arm version, the value of
>> PcdFlashNvStorageVariableBase, PcdFlashNvStorageFtwWorkingBase and
>> PcdFlashNvStorageFtwSpareBase are hardcoded in INC file.
>>
>> This version will calculate them from FDT resource and using the set PCD
>> to store when the NorFlashInitialise is called. By default, the first
>> available flash(not used for storage UEFI code) as NV variable storage
>> medium.
>>
>> In this way, UEFI can better handle the change of flash base address,
>> which is suitable for different cpu architecture board implementation.
>>
>> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=4770
>>
>> Cc: Ard Biesheuvel<ardb+tianocore@kernel.org>
>> Cc: Leif Lindholm<quic_llindhol@quicinc.com>
>> Cc: Sami Mujawar<sami.mujawar@arm.com>
>> Cc: Gerd Hoffmann<kraxel@redhat.com>
>> Cc: Jiewen Yao<jiewen.yao@intel.com>
>> Signed-off-by: Chao Li<lichao@loongson.cn>
>> Signed-off-by: Xianglai Li<lixianglai@loongson.cn>
>
> Can you split it into driver itself and part which uses DT data to 
> setup parameters?
>
> This way driver can be used on other platforms as well, despite do 
> they hardcode flash data, read it via Firmware Handoff protocol, SMC 
> calls to embedded controller or have other way to keep flash data.

This lib is provided for resolving pfalsh base addresses for virtual 
machines emulated by qemu.

The pfash base address of the arm and riscv architectures emulated by 
qemu is hardcoded in UEFI.
After this lib is committed, arm and riscv can easily use this lib by 
modifying the dsc and VarStore.fdf.inc files.
Later, we will send out the patch of arm and riscv, then arm and riscv 
will also be realized by resolving the pflash base address through fdt.

So, what other qemu emulation platforms do you think will hard-code fdt 
base addresses?:-)
Or are there specific scenarios that require hard-coded pflash base 
addresses?:-)

I admit that there is more flexibility, but do we really need to do 
that?:-)

Thanks!
Xianglai.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119271): https://edk2.groups.io/g/devel/message/119271
Mute This Topic: https://groups.io/mt/106149595/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-05-27  3:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17  7:17 [edk2-devel] [PATCH v1 0/2] Add a new FdtNorFalshQemuLib and enable it in Chao Li
2024-05-17  7:17 ` [edk2-devel] [PATCH v1 1/2] OvmfPkg: Add no hardcode version of FtdNorFlashQemuLib Chao Li
2024-05-24  9:11   ` Marcin Juszkiewicz
2024-05-27  3:17     ` xianglai [this message]
2024-05-27  6:38     ` Gerd Hoffmann
2024-05-28  1:43       ` Chao Li
2024-05-17  7:17 ` [edk2-devel] [PATCH v1 2/2] ArmVirtPkg: Enable the non-hardcode version FtdNorFlashQemuLib Chao Li
2024-05-17  7:21 ` [edk2-devel] [PATCH v1 0/2] Add a new FdtNorFalshQemuLib and enable it in Ard Biesheuvel
2024-05-17  7:33   ` Chao Li
     [not found]   ` <17D036583CE2D32E.17823@groups.io>
2024-05-24  8:38     ` Chao Li
2024-05-29  9:09       ` Gerd Hoffmann
2024-05-30  3:10         ` Chao Li
2024-05-30 12:35           ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38d4d808-69ed-e6a1-7163-1e82d5905e4a@loongson.cn \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox