Hi, Lersek:
Got it!
Thanks
At 2023-10-19 19:58:52, "Laszlo Ersek" wrote:
>On 10/19/23 03:51, Yoshinoya wrote:
>> Hi,
>> I findd qemu supports cxl emulation, but it uses seabios as virtual
>> machine firmware.
>>
>> Does UEFI OvmfPackage have a plan to support CXL device
On Thu, Oct 19, 2023 at 3:16 PM Laszlo Ersek wrote:
>
> On 10/19/23 15:50, Pedro Falcato wrote:
> > On Wed, Oct 18, 2023 at 6:24 PM Laszlo Ersek wrote:
> >>
> >> Referring to a file relative to a regular file makes no sense (or at least
> >> it cannot be implemented consistently with how a file
On Fri, Oct 20, 2023 at 3:04 PM Jayaprakash, N wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4570
>
> This commit is for processing the below PR on edk2-libc repo
> https://github.com/tianocore/edk2-libc/pull/3
> These are the changes introduced to StdLib to build
> an
+Ard
+Leif
> -Original Message-
> From: Jayaprakash, N
> Sent: Friday, October 20, 2023 7:04 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D ;
> Tyler Erickson
> Subject: [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting
> Aarch64 and
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4570
This commit is for processing the below PR on edk2-libc repo
https://github.com/tianocore/edk2-libc/pull/3
These are the changes introduced to StdLib to build
an application for the UEFI shell.
Added format macros for int types to Aarch64,
This patch request contains enhancements made to StdLibc
through BZ https://bugzilla.tianocore.org/show_bug.cgi?id=4570
Jayaprakash N (1):
ek2-libc: Enhance StdLib for supporting Aarch64 and ARM
StdLib/Include/Aarch64/machine/int_fmtio.h | 211 +
On 10/20/23 14:25, Ard Biesheuvel wrote:
> On Fri, 20 Oct 2023 at 11:49, Laszlo Ersek wrote:
>>
>> On 10/18/23 10:57, Ard Biesheuvel wrote:
>>> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
>>> wrote:
Dear Maintainers,
Just a friendly reminder to ask if you could take a look at
From: Abner Chang
Currently all PLDM functions inside the PLDM_SMBIOS_TRANSFER_PROTOCOL
use PLDM terminus PCDs for the MCTP addressing.
Add additional function to the protocol API to provide user a way to
use custom TIDs.
Signed-off-by: Abner Chang
Signed-off-by: Konstantin Aladyshev
---
Currently PldmSubmit command returns EFI_SUCCESS even if the response
header checks have failed.
Correct the code to return errors in such cases.
Signed-off-by: Konstantin Aladyshev
---
.../Universal/PldmProtocol/Common/PldmProtocolCommon.c | 9 ++---
1 file changed, 6 insertions(+), 3
From: Abner Chang
In case of the PLDM/MCTP communication response size doesn't have to be
known beforehand, the caller just need to provide the buffer big enough
to accomodate the response.
Remove PLDM command table for retrieving the response payload size and
correct the code to fix the
From: Abner Chang
Currently the PLDM source/destination TID arguments for the PldmSubmit
function are not actually used in any way in the underlying MCTP
communication. The code just uses MCTP source/destination EID PCDs. So
we have to restructure code to actually use provided PLDM TIDs.
On the
From: Abner Chang
Add PLDM source and destination terminus IDs for transmiting PLDM
message.
Signed-off-by: Abner Chang
Signed-off-by: Konstantin Aladyshev
---
Features/ManageabilityPkg/ManageabilityPkg.dec | 6 ++
1 file changed, 6 insertions(+)
diff --git
Since the current driver doesn't yet support handling of
multiple-packet MCTP responses, return EFI_UNSUPPORTED error in such
cases.
Signed-off-by: Konstantin Aladyshev
---
.../MctpProtocol/Common/MctpProtocolCommon.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
Currently PldmProtocol code uses magic numbers in the PLDM header
checks. Since PLDM headers have all the necessary definitions replace
magic numbers with the appropriate defines.
Signed-off-by: Konstantin Aladyshev
---
.../Universal/PldmProtocol/Common/PldmProtocolCommon.c| 8
1
If MCTP KCS communication has failed we need to abort MCTP transfer
function before checking any MCTP header data.
Signed-off-by: Konstantin Aladyshev
---
.../MctpProtocol/Common/MctpProtocolCommon.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git
Currently the MCTP TAG_OWNER bit is checked against 1 both in MTCP
request and response.
According to the MTCP Base specification in case of the MCTP response
the TAG_OWNER bit should be equal to 0.
Correct MCTP_MESSAGE_TAG_OWNER_RESPONSE flag value to fix the issue.
Signed-off-by: Konstantin
Although MtcpSubmit function receives source and destination MCTP EID
arguments these value are not used in any way currently. Instead the
code always uses EID values from the PCDs.
To correct this issue modify function interface to receive source and
destination MCTP EIDs via pointers and use PCD
Add checks for the MCTP header fields in the MCTP response.
Signed-off-by: Konstantin Aladyshev
---
.../MctpProtocol/Common/MctpProtocolCommon.c | 82 +++
1 file changed, 82 insertions(+)
diff --git
Correct wrong structure member used for MCTP destination EID.
Signed-off-by: Abner Chang
Signed-off-by: Konstantin Aladyshev
---
.../Universal/PldmProtocol/Common/PldmProtocolCommon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The Manageability KCS transport library needs to support requests both
from MCTP and IPMI transports. Currently the code only handles IPMI
case correctly.
In the MCTP case the communication should be based on the MCTP-over-KCS
specification (DSP0254). This specification defines a special KCS
MTCP base specification marks EIDs 1-7 as reserved. Therefore return
EFI_INVALID_PARAMETER if such EIDs were provided to the
MctpSubmitMessage function.
Signed-off-by: Konstantin Aladyshev
Signed-off-by: Abner Chang
---
.../Universal/MctpProtocol/Dxe/MctpProtocol.c | 17 +
1
The Manageability KCS transport library needs to support requests both
from MCTP and IPMI transports. Currently the code only handles IPMI
case correctly.
In the MCTP case the communication should be based on the MCTP-over-KCS
specification (DSP0254). This specification defines a special KCS
Currently there is only a definition for the MCTP KCS HEADER structure.
Add definition for the MCTP KCS TRAILER structure as well.
Signed-off-by: Konstantin Aladyshev
Signed-off-by: Abner Chang
---
.../Library/ManageabilityTransportMctpLib.h| 5 +
On 10/20/23 14:25, Laszlo Ersek wrote:
> On 10/20/23 13:30, John Chew wrote:
>> Hi Heinrich, Laszlo,
>>
>> Thank you very much for your support! Really appreciate it =D
>>
>> My account just approved few days ago, so original patch (submit few weeks
>> back) is not in the mailing list.
>
> Let
On Fri, 20 Oct 2023 at 14:17, Laszlo Ersek wrote:
>
> RealTimeClockLib instances are consumed by edk2's
> EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
> InitializeRealTimeClock(), the driver:
>
> (1) calls LibRtcInitialize(),
>
> (2) sets the GetTime(), SetTime(),
On Fri, 20 Oct 2023 at 14:19, Laszlo Ersek wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=4565
>
> RealTimeClockLib instances should neither set gRT fields nor install
> EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL in LibRtcInitialize();
> EmbeddedPkg/RealTimeClockRuntimeDxe already performs
On 20.10.23 11:49, Laszlo Ersek wrote:
On 10/18/23 10:57, Ard Biesheuvel wrote:
On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
wrote:
Dear Maintainers,
Just a friendly reminder to ask if you could take a look at my patch. I'd
really appreciate your feedback and help.
Thanks for the reminder.
On Fri, 20 Oct 2023 at 11:49, Laszlo Ersek wrote:
>
> On 10/18/23 10:57, Ard Biesheuvel wrote:
> > On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
> > wrote:
> >>
> >> Dear Maintainers,
> >>
> >> Just a friendly reminder to ask if you could take a look at my patch. I'd
> >> really appreciate your
On 10/20/23 13:30, John Chew wrote:
> Hi Heinrich, Laszlo,
>
> Thank you very much for your support! Really appreciate it =D
>
> My account just approved few days ago, so original patch (submit few weeks
> back) is not in the mailing list.
Let me rectify that in a minute.
Laszlo
>
>
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
https://bugzilla.tianocore.org/show_bug.cgi?id=4565
RealTimeClockLib instances should neither set gRT fields nor install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL in LibRtcInitialize();
EmbeddedPkg/RealTimeClockRuntimeDxe already performs those actions.
Cc: Ard Biesheuvel
Cc: Bibo Mao
Cc: Chao Li
Cc:
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own
Hi Heinrich, Laszlo,
Thank you very much for your support! Really appreciate it =D
My account just approved few days ago, so original patch (submit few weeks
back) is not in the mailing list.
Regards,
John
-Original Message-
From: Heinrich Schuchardt
Sent: Friday, October 20, 2023
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4567
ACPI_Spec_6_5_Aug29 Table 5.1, add 0x0B/Platform Runtime Mechanism (PRM)
in Address Space ID of Generic Address Structure (GAS)
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Jinlong Xu
---
MdePkg/Include/IndustryStandard/Acpi65.h
On 10/18/23 10:57, Ard Biesheuvel wrote:
> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
> wrote:
>>
>> Dear Maintainers,
>>
>> Just a friendly reminder to ask if you could take a look at my patch. I'd
>> really appreciate your feedback and help.
>>
>
> Thanks for the reminder. I don't have time
Hi Sunil,
Actually, we can use:
Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
I think there is no need for us to have our own PlatformBootManager library.
This library is here for debugging and development.
I will update this in patch v2.
Thanks! =)
@Liming,
The CI looks good (see https://github.com/tianocore/edk2/pull/4932), and this
v5 patch only contains space adjustment compared with v4 to make CI happy.
Kindly help merge this patch. Thanks a lot!
--
On Thu, Oct 19, 2023 at 08:34 PM, Sunil V L wrote:
>
> The patch should have commit message more than one liner. Same comment
> for PATCH 1/6 and 2/6
Hi Sunil,
Okay sure. I will remove the commented code.
Let me improve the commit message and include all maintainers in patch V2.
Thanks =)
Hi Sunil,
Okay, thanks for reminding me. I will include Leif and Mike for all coming
patches in Patch V2.
Thanks.
John
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109828): https://edk2.groups.io/g/devel/message/109828
Mute This
Hi Ard
Thanks for your reply.
I wonder if anyone have time to review this patch?
Thanks!
John
-Original Message-
From: devel@edk2.groups.io On Behalf Of Ard Biesheuvel
Sent: Wednesday, October 18, 2023 4:58 PM
To: YuinYee Chew
Cc: devel@edk2.groups.io; Sunil V L ; Li Yong
;
Hi Sunil,
You're right.
The MMC DMA destination buffer (64-bit) actually allocated in EDK2 code and
passed into the EDK2-platform MMC driver.
Now that you mention it, I think I can allocate another buffer (force to use
32-bit) in the MMC driver and use that buffer for tx/rx.
Then, copy the
On Thu, Oct 19, 2023 at 09:48:15PM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379
>
> This "Platform/Sophgo/Maintainers.md" file format is useless with
> edk2's "BaseTools/Scripts/GetMaintainer.py" utility, so delete this
> file. Add add the maintainers to the "Maintainers.txt" file.
>
Add Standalone Mm Generic Impi driver. And add type 'PcdsFixedAtBuild'
for PcdIpmiSmmIoBaseAddress to access in StandaloneMm driver
Cc: Isaac Oram
Cc: Nate DeSimone
Signed-off-by: Lixia Huang
---
49 matches
Mail list logo
