Hi Mike,
On Thu, Feb 09, 2023 at 01:43:57AM +, Kinney, Michael D wrote:
> Hi Sunil,
>
> Just a formatting comment below.
>
> Mike
>
> > -Original Message-
> > From: Sunil V L
> > Sent: Saturday, January 28, 2023 11:18 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ;
Hi Mike,
On Thu, Feb 09, 2023 at 01:45:48AM +, Michael D Kinney wrote:
> One comment below.
>
> Mike
>
> > -Original Message-
> > From: Sunil V L
> > Sent: Saturday, January 28, 2023 11:18 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang
On Wed, Feb 08, 2023 at 09:43:39PM -0800, Ni, Ray wrote:
> Since there is nothing shared between RiscV and X86, can you put the driver
> in a different folder such as RiscVCpuDxe?
Thank you very much Ray. Mike had given similar feedback. I am fine with
your suggestion. Let me update the series
Since there is nothing shared between RiscV and X86, can you put the driver in
a different folder such as RiscVCpuDxe?
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99864): https://edk2.groups.io/g/devel/message/99864
Mute This Topic:
Acked-by: Ray Ni
> -Original Message-
> From: Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann ;
> Abner Chang
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 09/20]
>
Can you rename CpuTimerLib to RiscVTimerLib or something else that's more
specific?
RiscV64 sub-directory might not be necessary.
> -Original Message-
> From: Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ;
I don't prefer to mix the RiscV64 CpuExceptionHandlerLib instance code with x86
one in
the same directory because they share nothing.
Can you use name such as "RiscVCpuExceptionHandlerLib" as the directory name?
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
>
I am curious if this module will support other arch as well? If it's RiscV
specific, there is no need for creating the RiscV64 folder.
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong,
Acked-by: Ray Ni
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer
> ; Gerd Hoffmann ; Abner
> Chang ; Heinrich Schuchardt
>
>
[AMD Official Use Only - General]
Hi Jiewen and Sunil,
Sorry, I am not allowed to keep working on RISC-V stuff, at least at the
moment. Maybe later in the future.
Abner
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 9, 2023 1:07 PM
> To: Sunil V L ;
Platform may implement Other NVS variable region following Regular
variable region and in this case SpiFvbService should include both
region size when calculating the total NVS region size.
One usage model is EventLog NVS region and there could be others.
Cc: Ashraf Ali S
Cc: Isaac Oram
Cc:
[AMD Official Use Only - General]
Hi Miki,
Here is a submission waiting for maintainer/reviewer's review.
https://edk2.groups.io/g/devel/message/98927 (Adds AmdSmmCpuFeaturesLib for AMD
Family)
Thanks
Abner
> -Original Message-
> From: disc...@edk2.groups.io On Behalf Of Demeter,
>
Thanks.
I agree to add Sunil V L to be a reviewer.
Reviewed-by: Jiewen Yao
> -Original Message-
> From: Sunil V L
> Sent: Thursday, February 9, 2023 12:34 PM
> To: devel@edk2.groups.io; Yao, Jiewen
> Cc: Kinney, Michael D ; abner.ch...@amd.com;
> Andrew Fish ; Leif Lindholm
>
Hi Jiewen,
On Thu, Feb 09, 2023 at 03:32:20AM +, Yao, Jiewen wrote:
> Hello
> I have not tracked all discussion. Sorry for that.
> May I know if we have discussed the option to create RiscVVirtPkg ? similar
> to https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that is
>
Hello
I have not tracked all discussion. Sorry for that.
May I know if we have discussed the option to create RiscVVirtPkg ? similar to
https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that is more
natural place.
For the new content on RiscVVirt, I recommend to add one more
If you are asking how to do that best *at this moment*, I suggest we create a
branch in https://github.com/tianocore/edk2-staging and continue the research
work. Before September 2023, we need community's help to resolve openssl-3 size
issue, before check in.
If you are asking how to do that
Since BIOS should work with different BMC implementation
chunked requests as well as Expect header should be optional.
One PCD is used to enable/disable Expect header.
Another PCD is used to enable/disable chunked requests.
Reviewed-by: Abner Chang
Cc: Abner Chang
Cc: Nickle Wang
Pushed as bc0b6bf..bd07ad3
-Original Message-
From: devel@edk2.groups.io On Behalf Of Isaac Oram
Sent: Wednesday, February 8, 2023 5:59 PM
To: devel@edk2.groups.io; tommy_hu...@aspeedtech.com
Cc: a...@kernel.org; Desimone, Nathaniel L ;
quic_llind...@quicinc.com; Kinney, Michael D ;
Hi Rebecca,
We will modify it in next patch.
Thanks,
Richard
-Original Message-
From: Rebecca Cran
Sent: 2023年2月8日 12:14 AM
To: devel@edk2.groups.io; Richard Ho (何明忠)
Cc: Andrew Fish ; Leif Lindholm ;
Michael D Kinney ; Michael Kubacki
; Zhiguang Liu ; Liming
Gao ; Tony Lo (羅金松)
Hi Tinh,
Thanks for your response. We will do more test in this patch.
Thanks,
Richard
-Original Message-
From: Tinh Nguyen OS
Sent: 2023年2月8日 10:46 AM
To: Michael Brown ; devel@edk2.groups.io; Tinh Nguyen OS
; Richard Ho (何明忠)
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v2 1/3]
Given the comment above it, I was looking in the 2.3 specification:
mention of UINT32 was only introduced in UEFI 2.3.1 Errata C.
The revision history states:
913 Enum definition does not match what our current compilers implement.
I'll send a patch to fix it.
--
Rebecca Cran
On 2/8/23
Hi Rebecca,
Great catch!!! I think the static assert verifier is incorrect.
The UEFI Spec does clearly state in Section 2.3.1 that enum values
can be type INT32 or UINT32. The use of 0x assumes use of
only UINT32. I agree that the correct value to assign to the 32-bit
enum value for
In commit 6440385b17def888544c2454ffba58384b929a22
(https://github.com/tianocore/edk2/commit/6440385b17def888544c2454ffba58384b929a22)
enum size checks were added.
However, according to gcc, ISO C restricts the size of enum values to
int; building with -std=c11 -pedantic results in the error:
[AMD Official Use Only - General]
> -Original Message-
> From: Igor Kulchytskyy
> Sent: Thursday, February 9, 2023 7:57 AM
> To: Chang, Abner ; devel@edk2.groups.io
> Cc: Nickle Wang
> Subject: RE: [EXTERNAL] RE: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe:
> Two PCDs for
Reviewed-by: Isaac Oram
-Original Message-
From: devel@edk2.groups.io On Behalf Of Tommy Huang
Sent: Wednesday, February 1, 2023 3:14 AM
To: devel@edk2.groups.io
Cc: a...@kernel.org; Desimone, Nathaniel L ;
Oram, Isaac W ; quic_llind...@quicinc.com; Kinney,
Michael D ; Chen, Ryan ;
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ;
> Kinney, Michael D
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add
> entry
Reviewed-by: Michael D Kinney
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Ard Biesheuvel
> ; Abner Chang ; Daniel
> Schaefer
> Subject: [edk2-devel]
Reviewed-by: Michael D Kinney
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann
> ; Abner Chang
> Subject: [edk2-devel]
Bug fix patch has been merged:
https://github.com/tianocore/edk2-platforms/commit/e95c7988994c73918ffa282e2d2f5af11f8addc4
Thanks,
Chasel
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Chiu, Chasel
> Sent: Wednesday, February 8, 2023 2:17 PM
> To:
Thanks Isaac!
> -Original Message-
> From: Oram, Isaac W
> Sent: Wednesday, February 8, 2023 5:39 PM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Chiu, Chasel
>
> Cc: S, Ashraf Ali ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael
> Subject: RE: [edk2-devel]
One comment below.
Mike
> -Original Message-
> From: Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> Abner Chang
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add
>
Pushed as 615afc82db..ab4ddecb12
-Original Message-
From: devel@edk2.groups.io On Behalf Of Rebecca Cran
Sent: Thursday, January 19, 2023 7:56 AM
To: Oram, Isaac W ; devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Desimone, Nathaniel L
; Gao, Liming ;
Rebecca Cran
Subject: Re:
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Daniel Schaefer ; Kinney, Michael D
> ; Gao, Liming ;
> Liu, Zhiguang ; Abner Chang
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7
Hi Sunil,
Just a formatting comment below.
Mike
> -Original Message-
> From: Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> Daniel Schaefer ; Abner Chang
> Subject:
Reviewed-by: Isaac Oram
At some point, we should work to comment the related flows better so that code
is clear on the different responsibilities for the different paths through
first boots, normal scenarios, reclaims, and error remediation. For now
though, this is fine.
Regards,
Isaac
Thanks Michael! I will apply the change during merging!
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Michael
> Kubacki
> Sent: Wednesday, February 8, 2023 4:41 PM
> To: devel@edk2.groups.io; Chiu, Chasel
> Cc: S, Ashraf Ali ; Oram, Isaac W
> ; Chaganty, Rangasai V
>
Thank you Liming. Ray has completed the review and I have pushed the PR branch
with the Rb. I will add push label after CI passes.
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of gaoliming via
> groups.io
> Sent: Wednesday, February 8, 2023 5:07 PM
> To:
Mike:
This fix is OK to me. I am OK to merge it for this stable tag.
Thanks
Liming
> -邮件原件-
> 发件人: Kinney, Michael D
> 发送时间: 2023年2月9日 7:17
> 收件人: devel@edk2.groups.io; Kinney, Michael D
> ; Gao, Liming
> 抄送: Cole, Deric ; Andrew Fish ;
> Ni, Ray ; Kinney, Michael D
> 主题: RE:
Reviewed-by: Ray Ni
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, February 9, 2023 7:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D ;
> Gao, Liming
> Cc: Cole, Deric ; Andrew Fish ; Ni,
> Ray ; Kinney, Michael D
> Subject: RE: [edk2-devel] [Patch 1/1]
Reviewed-by: Michael Kubacki
On the following lines, I recommend moving the assignment until after
the if block. It seems unnecessary to assign a potentially invalid value
to a local variable before checking the validation result.
Status = SafeUint64ToUint32 (BaseAddress,
[0].FvBase);
Hi Abner,
Thank you for your comments.
See my comments on your comments below.
Igor
-Original Message-
From: Chang, Abner
Sent: Wednesday, February 8, 2023 4:13 PM
To: Igor Kulchytskyy ; devel@edk2.groups.io
Cc: Nickle Wang
Subject: [EXTERNAL] RE: [PATCH V2 RESEND] RedfishPkg:
Hi Liming,
This is a significant behavior bug in EmulatorPkg PeiTimerLib that was
discovered during the soft freeze evaluation period.
I would like to request this patch be included in the edk2-stable202302 release.
Thanks,
Mike
> -Original Message-
> From: devel@edk2.groups.io On
From: Marcin Juszkiewicz
Update the TF-A binaries with SVE/SME enablement.
This support was merged into TF-A:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17825
This allows to test SBSA Reference Platform to boot Linux 6.x kernels
with "max" cpu.
Signed-off-by: Marcin
Any idea why the below error comes?
Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0
Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
From: Deric Cole
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339
Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.
Cc: Andrew Fish
Cc: Ray Ni
Signed-off-by: Deric Cole
Reviewed-by: Michael D Kinney
---
EmulatorPkg/Include/Protocol/EmuThunk.h | 2 +-
On Wed, 8 Feb 2023 at 19:57, Taylor Beebe wrote:
>
>
>
> On 2/8/2023 10:49 AM, Ard Biesheuvel wrote:
> > On Wed, 8 Feb 2023 at 19:32, Marvin Häuser wrote:
> >>
> >> Thanks!! :) Comments inline.
> >>
> >>> On 8. Feb 2023, at 18:58, Ard Biesheuvel wrote:
> >>>
> >>> The DXE core implementation of
Thanks for reviewing Michael.
Please see my reply below inline and help to review V4 patch again.
Thanks,
Chasel
> -Original Message-
> From: Michael Kubacki
> Sent: Tuesday, February 7, 2023 12:22 PM
> To: devel@edk2.groups.io; Chiu, Chasel
> Cc: S, Ashraf Ali ; Oram, Isaac W
> ;
On 2/8/2023 2:08 PM, Ard Biesheuvel wrote:
On Wed, 8 Feb 2023 at 20:12, Taylor Beebe wrote:
I ran some tests and did some quick napkin math. Based on the time it
takes to perform the SetMemoryAttributes() routine on QEMU, as long as
<79% of the calls to ApplyMemoryProtectionPolicy()
When invalid VariableStore FV header detected, current SpiFvbService
will erase both FV and VariableStore headers from flash, however,
it will only rewrite FV header back and cause invalid VariableStore
header.
This patch adding the support for rewriting both FV header and
VariableStore header
On Wed, 8 Feb 2023 at 20:12, Taylor Beebe wrote:
>
> I ran some tests and did some quick napkin math. Based on the time it
> takes to perform the SetMemoryAttributes() routine on QEMU, as long as
> <79% of the calls to ApplyMemoryProtectionPolicy() actually require a
> subsequent call to
[AMD Official Use Only - General]
Hi Igor,
Few comments in below.
> -Original Message-
> From: Igor Kulchytskyy
> Sent: Thursday, February 9, 2023 1:23 AM
> To: devel@edk2.groups.io
> Cc: Igor Kulchytskyy ; Chang, Abner
> ; Nickle Wang
> Subject: [PATCH V2 RESEND] RedfishPkg:
Merged
https://github.com/tianocore/edk2/pull/4018
Commit:
https://github.com/tianocore/edk2/commit/b59e6fdae2545b45c36c8c5373f4b858fb83c8cd
Mike
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, February 7, 2023 11:33 PM
> To: devel@edk2.groups.io; mhaeu...@posteo.de
I ran some tests and did some quick napkin math. Based on the time it
takes to perform the SetMemoryAttributes() routine on QEMU, as long as
<79% of the calls to ApplyMemoryProtectionPolicy() actually require a
subsequent call to SetMemoryAttributes(), it is more efficient to walk
the
On 2/8/2023 10:49 AM, Ard Biesheuvel wrote:
On Wed, 8 Feb 2023 at 19:32, Marvin Häuser wrote:
Thanks!! :) Comments inline.
On 8. Feb 2023, at 18:58, Ard Biesheuvel wrote:
The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that
> On 8. Feb 2023, at 19:49, Ard Biesheuvel wrote:
>
> This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
:(
>
> The ordering here is a bit tricky. As soon as the CPU arch protocol is
> exposed, every allocation will be remapped individually, resulting in
> page table
On Wed, 8 Feb 2023 at 19:32, Marvin Häuser wrote:
>
> Thanks!! :) Comments inline.
>
> > On 8. Feb 2023, at 18:58, Ard Biesheuvel wrote:
> >
> > The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
> > contains an assertion that EfiConventionalMemory and EfiBootServicesData
> >
Thanks!! :) Comments inline.
> On 8. Feb 2023, at 18:58, Ard Biesheuvel wrote:
>
> The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
> contains an assertion that EfiConventionalMemory and EfiBootServicesData
> are subjected to the same policy when it comes to the use of NX
>
On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel wrote:
>
> Instead of relying on a questionable heuristic that avoids calling into
> the SetMemoryAttributes () DXE service when the old memory type and the
> new one are subjected to the same NX memory protection policy, make this
> call
On Wed, Feb 08, 2023 at 06:02:44PM +, Kinney, Michael D wrote:
> Hi Sunil,
>
> One comment on the name of this module. CpuTimerDxe is a very generic name,
> but the
> Implementation is for RISCV only and depends on SBL services. Correct?
>
> If I look at other TimerDxe modules, they have
Hi Sunil,
One comment on the name of this module. CpuTimerDxe is a very generic name,
but the
Implementation is for RISCV only and depends on SBL services. Correct?
If I look at other TimerDxe modules, they have in their name some indication of
the timer hardware/software dependencies in
+Liming at his correct email address.
Sorry, I used the email address from the DDR4 commit back in 2016.
On 2/8/23 10:47, Rebecca Cran wrote:
Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
SpdDdr5.h per JEDEC JESD400-5A.01 specification
Allow users to build OVMF then run QEMU by moving the build block above
the run block and removing the exit line.
Signed-off-by: Rebecca Cran
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
---
OvmfPkg/build.sh | 13 +
1 file changed, 5 insertions(+), 8
Instead of relying on a questionable heuristic that avoids calling into
the SetMemoryAttributes () DXE service when the old memory type and the
new one are subjected to the same NX memory protection policy, make this
call unconditionally. This avoids corner cases where memory region
attributes are
The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion
This fixes an issue reported by Marvin, where NX memory protections are
applied in a rather unreliable manner, resulting in the possibility that
memory mappings may exist that are using different attributes than
intended.
The reason for this approach was that applying memory protections
eagerly
Currently, the AArch64 MMU page table logic will break down any block
entry that overlaps with the region being mapped, even if the block
entry in question is using the same attributes as the new region.
This means that creating a non-executable mapping inside a region that
is already mapped
Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
SpdDdr5.h per JEDEC JESD400-5A.01 specification
(https://www.jedec.org/standards-documents/docs/jesd400-5a01).
Signed-off-by: Rebecca Cran
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Zhiguang Liu
---
Since BIOS should work with different BMC implementation
chunked requests as well as Expect header should be optional.
One PCD is used to enable/disable Expect header.
Another PCD is used to enable/disable chunked requests.
Cc: Abner Chang
Cc: Nickle Wang
Signed-off-by: Igor Kulchytskyy
---
Reviewed-by: Guo Dong
-Original Message-
From: Xie, Yuanhao
Sent: Tuesday, February 7, 2023 6:50 AM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean
; Lu, James ; Guo, Gua
Subject: [PATCH 4/5] UefiPayloadPkg: Add CpuPageTableLib required by MpInitLib
Add
With some minor fixups[1], for the series:
Reviewed-by: Pedro Falcato
and pushed to edk2-platforms HEAD.
Thanks,
Pedro
[1] Fixed up some commit messages to be imperative, added my Rb, fixed
a status return in Extents.c for ("Ext4Pkg: Correct integer overflow
check logic in DiskUtil"), and
Hi,
> 3. If 1 or 2 can success, we can replace openssl 1.1 with one crypto lib.
> If both 1 and 2 fail, we may use *dual-crypto module*. For example: mbedtls
> for PEI and openssl3.0 for DXE.
> The source code size will become larger, more time to download the tree.
Suggestions how to do that
> + AllocSize = EFI_PAGES_TO_SIZE (
> +EFI_SIZE_TO_PAGES (
> + CpuMpData->CpuCount * AP_SAFE_STACK_SIZE + ApLoopFuncSize
> + )
> +);
> + Status = gBS->AllocatePages (
> + AllocateMaxAddress,
> +
On Tue, Feb 07, 2023 at 09:49:37PM +0800, Yuanhao Xie wrote:
> Add CpuPageTableLib required by MpInitLib in OvmfPkg.
>
> Cc: Ard Biesheuvel
> Cc: Jiewen Yao
> Cc: Jordan Justen
> Cc: Gerd Hoffmann
> Signed-off-by: Yuanhao Xie
Acked-by: Gerd Hoffmann
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io
Hi Marvin,
Thanks for the feedbacks.
The corrected implementation is in patch 5.
The stacks are located high and the function is located low. With padding, it
ensures page alignment.
I'll resend the patch to make sure the changes are included in patch 2.
Best Regards,
Yuanhao
From: Marvin
On 08/02/2023 09:55, Alireza Banejad wrote:
As my previous email, I mentioned that I am able to find the protocol
since the LocateProtocol returns 0 (EFI_SUCCESS) (using the exact code
you wrote) . But when I want to open it either with OpenProtocol or
HandleProtocol I get a
As my previous email, I mentioned that I am able to find the protocol since
the LocateProtocol returns 0 (EFI_SUCCESS) (using the exact code you wrote)
. But when I want to open it either with OpenProtocol or HandleProtocol I
get a RETURN_UNSUPPORTED. Are you implying that by calling
On 08/02/2023 08:03, Alireza Banejad wrote:
Below is how I use the HandleProtocol function:
Status = gBS->HandleProtocol (
gST->ConsoleOutHandle,
,
(VOID **)
);
You are querying only the ConsoleOutHandle, which is
Hi Bill,
Yes, I have the graphics window with the logo showing and I see the setup
menu.
In fact, I have designed a HII form with my specific applications. The
problem is that it just uses the SimpleTextOutput. It doesn't use the GOP
or UgaDraw libraries.
Plus, I am able to locate the protocol
78 matches
Mail list logo
