From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by mx.groups.io with SMTP id smtpd.web11.53013.1688453158597079887 for ; Mon, 03 Jul 2023 23:45:58 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@ventanamicro.com header.s=google header.b=hMe4WiAF; spf=pass (domain: ventanamicro.com, ip: 209.85.208.54, mailfrom: tphan@ventanamicro.com) Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-51de9c2bc77so4280766a12.3 for ; Mon, 03 Jul 2023 23:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1688453157; x=1691045157; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d6kr4tobX/P9P+ZeE0il+LQzQeV3SdZaUqSobMT8h5c=; b=hMe4WiAFO5aGzxpHN+giiGpojrqkiAi75LubkDcnL7OConapmenP/6woasDBi7FJah NjmpeBceckW2J9J0Q1YGtL5M/Q3A3AjnCRIjjWS0GqE2dwA++H77xkF2DdAkBLGx5wMD 8bTjeqWEX/1agEaOQ4M/gsn32chj8z20bYFTiOwxW/N7yJw09nUWlloggeBhqSYxEJOL DqCN6eSs6+Swr1vp1KwiBNxkJi1uZxfOV9bOH6V5TcNWnVM1tPvaarPYTAx4KznCUCxU DCBhdqhyZ2FoQBEZwM0ksvmcbKv8J2gWPaM4G6b8x9ti6jAAhpBf5G0xQ+p2gQBGwvZf 7P5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688453157; x=1691045157; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d6kr4tobX/P9P+ZeE0il+LQzQeV3SdZaUqSobMT8h5c=; b=do+WR4SCtcsYRGCRbaZxULmzchx74Ew/nL0u7jNIV17jBgfRlJivWSFY7ZqeI5aqC3 XaF1MpEKjQ+PTB62CXKYxRUsHsun6eR1PCsbXc2xvJLxdJTmi5GWFpgiDF4xyIazmFAO OrXcsyAOpUde9MFY6QFY322lY0tQvKMTI6ma+ZDxcCoaHlpYilemtocvt5JKTh9Mfrs4 ux1DkzSemyWvaMdrh9bqmujtSwXjUFGoDHbDT1mszom5kCYYpIZqc1ehH0J+DjjYxEO9 eGDvPfONpN2zq2Wm+ksyyKVpPozSUc/IbVYSr2757uZGSM5DEcg3Pbh4Bj14goFrW76h WEMQ== X-Gm-Message-State: ABy/qLbKH6uUPd/DsRLKgyeFKXcdb73KF+drAqesesNHkVS0oEHXTfIo J8MrIwdpJT5lJKyOz6kR/xbuPFI+CH5edFT8YOXwoA== X-Google-Smtp-Source: APBJJlF7bTaQrwn5sKaI0jumMfStsRMVVNlat8MB7ksThlwX75Pw9c82AHeNXsGXVIXMFbfemLf7C6TWPSsbOZcQDYg= X-Received: by 2002:a05:6402:b2d:b0:51e:309:2e15 with SMTP id bo13-20020a0564020b2d00b0051e03092e15mr6126605edb.16.1688453156804; Mon, 03 Jul 2023 23:45:56 -0700 (PDT) MIME-Version: 1.0 References: <20230623183934.23905-1-tphan@ventanamicro.com> <20230623183934.23905-6-tphan@ventanamicro.com> In-Reply-To: From: "Tuan Phan" Date: Mon, 3 Jul 2023 23:45:45 -0700 Message-ID: Subject: Re: [PATCH v4 5/7] OvmfPkg/RiscVVirt: Add VirtNorFlashDxe to APRIORI list To: Sunil V L Cc: andrei.warkentin@intel.com, ardb+tianocore@kernel.org, devel@edk2.groups.io, gaoliming@byosoft.com.cn, git@danielschaefer.me, michael.d.kinney@intel.com, zhiguang.liu@intel.com Content-Type: multipart/alternative; boundary="000000000000a1aa7405ffa3a2a0" --000000000000a1aa7405ffa3a2a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As i said, VirtNorFlashDxe needed to be loaded before VariableRuntimeDxe so your suggestion will not work. On Mon, Jul 3, 2023 at 10:07 PM Sunil V L wrote: > On Wed, Jun 28, 2023 at 02:27:10PM -0700, Tuan Phan wrote: > > On Wed, Jun 28, 2023 at 9:47=E2=80=AFAM Sunil V L > wrote: > > > > > On Fri, Jun 23, 2023 at 11:39:32AM -0700, Tuan Phan wrote: > > > > Make sure VirtNorFlashDxe loaded before VariableRuntimeDxe as it > > > > is the backend flash driver. > > > > > > > > Signed-off-by: Tuan Phan > > > > --- > > > > OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf | 10 ++++++++++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf > > > b/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf > > > > index 21e4ba67379f..9ab8eb3ba7d8 100644 > > > > --- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf > > > > +++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf > > > > @@ -53,6 +53,16 @@ READ_STATUS =3D TRUE > > > > READ_LOCK_CAP =3D TRUE > > > > READ_LOCK_STATUS =3D TRUE > > > > > > > > +APRIORI DXE { > > > > + INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf > > > > + INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf > > > > + INF > > > > MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCode= RouterRuntimeDxe.inf > > > > + INF > > > > MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRunt= imeDxe.inf > > > > + INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf > > > > + INF UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf > > > > + INF OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf > > > > +} > > > > + > > > Hi Tuan, > > > > > > Actually, Ard had recommended not to use APRIORI and hence we avoided > > > it when we upstreamed RiscVVirt. So, I am wondering whether this can = be > > > avoided by using depex in CpuDxe on gEfiVariableArchProtocolGuid? > > > > > > Hi Sunil, > > Not sure what the reason behind avoiding APRIORI besides it is a > workaround > > for broken DEPEX. BTW, what we need is to put VirtNorFlashDxe loaded > before > > VariableRuntimeDxe which doesn't depend on any modules. I don't see any > > other clearer way than modifying VirNorFlashDxe as shown in the first > > version of this series. > > > > The CpuDxeRiscV64 in the aprioriy list as VirNorFlashDxe depends on it. > > > Hi Tuan, > > I couldn't locate old mail from Ard recommending to remove APRIORI in > RISC-V. But here is the recent mail on different context but those > reasons are still valid in any case. > https://edk2.groups.io/g/devel/message/104543 > > IMO, there is no dependency between VirtNorFlashDxe and > VariableRuntimeDxe. I think what we need is CpuDxeRiscV64 loaded after > VariableRuntimeDxe and before VirtNorFlashDxe. A simple depex like I > suggested in previous mail should work. I still prefer this than > introducing APRIORI unless there are other issues I am now aware of. > What do you think? > > Thanks! > Sunil > --000000000000a1aa7405ffa3a2a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As i said,=C2=A0VirtNorFla= shDxe needed to be loaded before VariableRuntimeDxe so your suggestion will= not work.

On Mon, Jul 3, 2023 at 10:07 PM Sunil V L <sunilvl@ventanamicro.com> wrote= :
On Wed, Jun 28, 2023 at 02:27:10PM -0700, Tuan = Phan wrote:
> On Wed, Jun 28, 2023 at 9:47=E2=80=AFAM Sunil V L <sunilvl@ventanamicro.com&= gt; wrote:
>
> > On Fri, Jun 23, 2023 at 11:39:32AM -0700, Tuan Phan wrote:
> > > Make sure VirtNorFlashDxe loaded before VariableRuntimeDxe a= s it
> > > is the backend flash driver.
> > >
> > > Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
> > > ---
> > >=C2=A0 OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf | 10 ++++++++++ > > >=C2=A0 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf
> > b/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf
> > > index 21e4ba67379f..9ab8eb3ba7d8 100644
> > > --- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf
> > > +++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf
> > > @@ -53,6 +53,16 @@ READ_STATUS=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =3D TRUE
> > >=C2=A0 READ_LOCK_CAP=C2=A0 =C2=A0 =C2=A0 =3D TRUE
> > >=C2=A0 READ_LOCK_STATUS=C2=A0 =C2=A0=3D TRUE
> > >
> > > +APRIORI DXE {
> > > +=C2=A0 INF=C2=A0 MdeModulePkg/Universal/DevicePathDxe/Devic= ePathDxe.inf
> > > +=C2=A0 INF=C2=A0 MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > > +=C2=A0 INF
> > MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportSt= atusCodeRouterRuntimeDxe.inf
> > > +=C2=A0 INF
> > MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan= dlerRuntimeDxe.inf
> > > +=C2=A0 INF=C2=A0 EmbeddedPkg/Drivers/FdtClientDxe/FdtClient= Dxe.inf
> > > +=C2=A0 INF=C2=A0 UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf=
> > > +=C2=A0 INF=C2=A0 OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.in= f
> > > +}
> > > +
> > Hi Tuan,
> >
> > Actually, Ard had recommended not to use APRIORI and hence we avo= ided
> > it when we upstreamed RiscVVirt. So, I am wondering whether this = can be
> > avoided by using depex in CpuDxe on gEfiVariableArchProtocolGuid?=
> >
> > Hi Sunil,
> Not sure what the reason behind avoiding APRIORI besides it is a worka= round
> for broken DEPEX. BTW, what we need is to put VirtNorFlashDxe loaded b= efore
> VariableRuntimeDxe which doesn't depend on any modules. I don'= t see any
> other clearer way than modifying VirNorFlashDxe as shown in the first<= br> > version of this series.
>
> The CpuDxeRiscV64 in the aprioriy list as VirNorFlashDxe depends on it= .
>
Hi Tuan,

I couldn't locate old mail from Ard recommending to remove APRIORI in RISC-V. But here is the recent mail on different context but those
reasons are still valid in any case.
https://edk2.groups.io/g/devel/message/104543

IMO, there is no dependency between VirtNorFlashDxe and
VariableRuntimeDxe. I think what we need is CpuDxeRiscV64 loaded after
VariableRuntimeDxe and before VirtNorFlashDxe. A simple depex like I
suggested in previous mail should work. I still prefer this than
introducing APRIORI unless there are other issues I am now aware of.
What do you think?

Thanks!
Sunil
--000000000000a1aa7405ffa3a2a0--