On Thu, 18 Jan 2024 at 21:28, Laszlo Ersek wrote:
>
> On 1/16/24 18:10, Gerd Hoffmann wrote:
> > This is a little series containing the flash corruption fix sent
> > yesterday with an slightly improved commit message and some small
> > improvements on top of this.
> >
> > v3:
> > - fix diagram
>
Third parameter of AsciiStrToUnicodeStrS is the number of character in
destination buffer, not the size in byte of destination buffer. This
creates failure of converting ASCII string to Unicode string in Redfish
application while getting Location field in HTTP header.
Signed-off-by: Nickle Wang
C
On Thu, Jan 18, 2024 at 03:20:18PM +0530, Dhaval wrote:
> Some platforms do not implement cache management operations. Especially
> for DMA drivers have code to manage data cache. The code seem to depend
> on the underlying CPU/cache drivers to enact functionality and simply
> return if such functi
On Thu, Jan 18, 2024 at 03:58:04PM +, Pedro Falcato wrote:
> On Thu, Jan 18, 2024 at 9:50 AM Dhaval wrote:
> >
> > Some platforms do not implement cache management operations. Especially
> > for DMA drivers have code to manage data cache. The code seem to depend
> > on the underlying CPU/cache
From: Laszlo Ersek
The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.
Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remo
On 1/18/2024 9:49 PM, Laszlo Ersek wrote:
but I'd prefer to just remove this
optimization from standalone MM, given that not only a) it shouldn't
have to deal with a large number of protocol GUIDs, but also b) the
driver dispatch is much more straight-forward. (Typically, StMM
drivers can be disp
Merged: https://github.com/tianocore/edk2/pull/5274
Mike
From: Ashish Singhal
Sent: Thursday, January 18, 2024 5:55 PM
To: Kinney, Michael D ; Kasbekar, Saloni
; devel@edk2.groups.io; Clark-williams, Zachary
; Jeff Brasen ; Gao,
Liming
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Def
Replied too soon. I saw you had already closed mine.
Thanks
Ashish
From: Ashish Singhal
Sent: Friday, January 19, 2024 7:23 AM
To: Kinney, Michael D ; Kasbekar, Saloni
; devel@edk2.groups.io ;
Clark-williams, Zachary ; Jeff Brasen
; Gao, Liming
Subject: Re: [
Hi Michael,
If you are going to create a new PR yourself instead of using the one I already
created (https://github.com/tianocore/edk2/pull/5150), should I close this one?
Thanks
Ashish
From: Kinney, Michael D
Sent: Friday, January 19, 2024 4:57 AM
To: Kasbekar,
hi Pedro,
Thanks for the comments.
I will describe more about how to fix it in the commit message.
About the renaming, I hesitate about it, since there may be other usage about
this param. However, I don't think it is a big concern. I will keep it as is
for now.
Thanks
Zhiguang
> -Original
On 1/5/2024 1:26 AM, Ard Biesheuvel wrote:
@@ -91,7 +88,8 @@ WatchdogExitBootServicesEvent (
)
{
WatchdogDisable ();
- mNumTimerTicks = 0;
+ mTimerPeriod= 0;
+ mExitedBootServices = TRUE;
Where is this declared/defined?
Oh, it's defined in the 3rd patch - which obviously
On 1/5/2024 4:12 AM, Sami Mujawar wrote:
- // if TimerPeriod is 0, this is a request to stop the watchdog.
+ // If we've exited Boot Services but TimerPeriod isn't zero, this
+ // indicates that the caller is doing something wrong.
+ if (mExitedBootServices && (TimerPeriod != 0)) {
[SAMI] Thanks
Acked-by: Michael D Kinney
I will prepare PR for merge
From: Kasbekar, Saloni
Sent: Wednesday, January 17, 2024 9:27 AM
To: Ashish Singhal ; devel@edk2.groups.io;
Clark-williams, Zachary ; Jeff Brasen
; Kinney, Michael D ; Gao,
Liming
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To
Reviewed-by: Michael D Kinney
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Xu, Wei6
> Sent: Wednesday, January 17, 2024 10:12 AM
> To: devel@edk2.groups.io
> Cc: Xu, Wei6 ; Abner Chang ;
> Desimone, Nathaniel L
> Subject: [edk2-devel] [PATCH edk2-platforms 1/1]
> Ipmi
Hi Tom,
I do not see any harm in zeroing ECX in AsmCpuid().
If it is not zeroed, then it would have an undefined value.
However, calling AsmCpuid() for any Index that evaluates ECX
(including a check for 0) should never be done. If ECX is
evaluated for a given Index, then AsmCpuIdEx() must be u
Acked-by: Michael D Kinney
> -Original Message-
> From: Abdul Lateef Attar
> Sent: Wednesday, January 17, 2024 7:54 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Kinney, Michael D
> ; Liming Gao ;
> Liu, Zhiguang ; Ni, Ray ;
> Kumar, Rahul R ; Gerd Hoffmann
>
> Subject: [PATC
Hi Madhan,
There are 2 additional files that need function header updates:
* SignedCapsulePkg\Universal\SystemFirmwareUpdate\SystemFirmwareCommonDxe.c
* SignedCapsulePkg\Universal\SystemFirmwareUpdate\SystemFirmwareDxe.h
In addition, there are function headers in the edk2-platforms repo that
al
Hi Madhan,
The patch you provided does fix the logic in the .c file, but the update is
incomplete.
* FmpDevicePkg/FmpDxe/FmpDxe.c - Update GetTheImageInfo() function header
to match the UEFI 2.10 specification that includes all the conditions to
return EFI_INVALID_PARAMETER.
* FmpDevicePkg/
On 1/17/24 23:47, Doug Flick via groups.io wrote:
> OVMF is failing because it includes both DxeTpm2MeasureBootLib and
> DxeTpm2MeasureBootLib which makes the symbols collide. This patch
> renames the function names to be unique to avoid symbol collision.
>
> Cc: Jiewen Yao
> Cc: Rahul Kumar
>
On 1/16/24 18:10, Gerd Hoffmann wrote:
> This is a little series containing the flash corruption fix sent
> yesterday with an slightly improved commit message and some small
> improvements on top of this.
>
> v3:
> - fix diagram
> - fix DoErase control flow
> - pick up reviewed-by tags
> v2:
>
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Pethaiyan, Madhan
> Sent: Thursday, January 18, 2024 12:57 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Kinney, Michael D
> ; Xu, Wei6 ; Tan, Ming
> ; S, Ashraf Ali
> Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add
On 1/18/2024 10:38 AM, Oliver Smith-Denny wrote:
I am suspicious that we are checking for the alignment before we
adjust the memory for the guard. I'm wondering if we actually
should do AdjustMemoryF (recalling function from memory) before
we check the alignment.
Following up on this, this is
On 1/18/2024 12:04 PM, Oliver Smith-Denny wrote:
On 1/18/2024 10:45 AM, Rebecca Cran via groups.io wrote:
No, I mean SbsaQemu from edk2-platforms:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Qemu/SbsaQemu
Sure, if you can repro there that is helpful.
I've realized it w
On 1/18/2024 10:45 AM, Rebecca Cran via groups.io wrote:
No, I mean SbsaQemu from edk2-platforms:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Qemu/SbsaQemu
Sure, if you can repro there that is helpful.
Oliver
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all mes
On 1/17/24 15:12, Gerd Hoffmann wrote:
>> This patch is good:
>>
>> Reviewed-by: Laszlo Ersek
>>
>> but the series shouldn't stop here. In "OvmfPkg/Tcg/Tcg2Config", we're
>> left with an INF file (Tcg2ConfigPei.inf) that still references
>> "Tpm12Support.h", and the common C source file "Tcg2Confi
On 1/18/2024 11:38 AM, Oliver Smith-Denny wrote:
Yeah, if you can get it running there, that would be a good data point.
I assume you mean the Project Mu QemuSbsaPkg? If so that is great, but
you will need to update the RUNTIME_PAGE_ALLOCATION_GRANULARITY back to
0x1. It was set to 0x1000 fo
On 1/18/2024 9:42 AM, Rebecca Cran via groups.io wrote:
On 1/18/2024 9:48 AM, Oliver Smith-Denny via groups.io wrote:
Are you including this commit:
https://github.com/tianocore/edk2/commit/00b51e0d78a547dd78119ec44fcc74a01b6f79c8?
Can you share some more details on where this is failing? I.e
On 1/18/2024 9:48 AM, Oliver Smith-Denny via groups.io wrote:
Are you including this commit:
https://github.com/tianocore/edk2/commit/00b51e0d78a547dd78119ec44fcc74a01b6f79c8?
Can you share some more details on where this is failing? I.e. what
assert is getting tripped? Presumably without Heap
On 1/18/2024 7:27 AM, Rebecca Cran via groups.io wrote:
I've been debugging an assert failure when using HeapGuard on AArch64. A
call to FreePages in SmbiosDxe is failing because the memory is aligned
to 0x1000 instead of 0x1 as defined by
RUNTIME_PAGE_ALLOCATION_GRANULARITY.
I'm enabling
What's very confusing about the current situation is that we have a Pcd that
can set whether I support CMO instructions. When I correctly set up my platform
to not support CMO instructions and hope that everything goes well, I will
trigger Assert in the debug version. But I also can't set the Pc
Hi Pedro,
Agree Assert is slightly more enforcing over logs, but you could still get
away with even Assert in release mode.
One alternative is to convert VERBOSE into WARNING?
=D
On Thu, Jan 18, 2024 at 9:28 PM Pedro Falcato
wrote:
> On Thu, Jan 18, 2024 at 9:50 AM Dhaval wrote:
> >
> > Some pl
On Thu, Jan 18, 2024 at 2:21 AM Liu, Zhiguang wrote:
>
> Thanks Laszlo for the comment, I will send a new version of patch to fix this.
>
> Also include Pedro to see if Pedro have more comments.
The patch's subject really doesn't describe the fix (describe what you
did in the patch/commit, don't
On Thu, Jan 18, 2024 at 9:50 AM Dhaval wrote:
>
> Some platforms do not implement cache management operations. Especially
> for DMA drivers have code to manage data cache. The code seem to depend
> on the underlying CPU/cache drivers to enact functionality and simply
> return if such functionality
On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
> Disabling cache by default results in violation of BTG protections (if BTG
> enabled).
>
> BIOS cannot assume that cache is disabled before it executes as ACM may be
> required to enable NEM.
>
> Whatever solution needs to be d
I've been debugging an assert failure when using HeapGuard on AArch64. A
call to FreePages in SmbiosDxe is failing because the memory is aligned
to 0x1000 instead of 0x1 as defined by
RUNTIME_PAGE_ALLOCATION_GRANULARITY.
I'm enabling HeapGuard by setting the PCDs to the following values:
On 1/18/24 07:00, Nhi Pham wrote:
> Hi Laszlo,
>
> On 1/16/2024 2:00 AM, Laszlo Ersek wrote:
>> On 1/15/24 15:04, Ard Biesheuvel wrote:
>>> On Mon, 15 Jan 2024 at 14:07, Nhi Pham
>>> wrote:
On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
> (Independently: I think that's a valid thing to d
On 1/18/24 10:50, Dhaval wrote:
> Some platforms do not implement cache management operations. Especially
> for DMA drivers have code to manage data cache. The code seem to depend
> on the underlying CPU/cache drivers to enact functionality and simply
> return if such functionality is not implement
Greetings everyone,
I am developing a module that must not be skipped during boot. In my test
laptop, it seems to be randomly skipped, so I figured it had to do with fast
boot and indeed disabling it seems to do trick.
How can I learn more about fast boot? Perhaps there's a specification I haven'
Hi, Ard
Could I process with this way?
Many thanks!
On 11/01/2024 09:05, levi.yun via groups.io wrote:
Hi Brian.
Ard didn't want a SerialPortInitialize() call directly in the
all-platform StandaloneMmCore _ModuleEntryPoint() function, which is
understandable. So perhaps you could either
Some platforms do not implement cache management operations. Especially
for DMA drivers have code to manage data cache. The code seem to depend
on the underlying CPU/cache drivers to enact functionality and simply
return if such functionality is not implemented. However this causes
issue with CMO i
Some platforms do not implement cache management operations. i.e DMA drivers
seem to depend on the underlying CPU/cache functions to simply return if such
functionality is not implemented. However this causes issue with CMO
implementation which has an assert, causing flow to hang within debug
envir
Hi Laszlo,
Thanks,
Chao
On 2024/1/16 22:41, Laszlo Ersek wrote:
On 1/16/24 12:54, Chao Li wrote:
On 2024/1/15 16:46, Laszlo Ersek wrote:
On 1/12/24 09:25, Chao Li wrote:
@@ -29,7 +29,6 @@
QemuKernel.c
[Packages]
- ArmVirtPkg/ArmVirtPkg.dec
MdeModulePkg/MdeModulePkg.dec
Mde
Hi Ray and Sunil,
Sorry, I'm late, I have very busy these days.
I created two PRs in my private repo.
*Plan A:*
Moved most of LoongArch libraries and drivers to current matching
folders, removed LoongArch private INF, adjusted common INF.
URL: https://github.com/kilaterlee/edk2/pull/8
*Pl
43 matches
Mail list logo
