Hi Sunil,
Thank you for the review.
> +EFI_STATUS
> +EFIAPI
> +FdtGetIntcAddressCells (
> + IN CONST VOID *Fdt,
> + IN INT32 Node,
> + OUT INT32 *AddressCells, OPTIONAL
> + OUT INT32 *SizeCells OPTIONAL
NIT: I might be wrong but alignment doesn't look correct.
[SAMI] I wonder if this is an artifa
Hi Pierre,
Overall, this patch series looks good to me.
I have some minor comments regarding the return value for the Arch hook
functions their placement in Common folder.
e.g. in Patch "DynamicTablesPkg: AcpiFadtLib: Prepare to support other archs"
The file
DynamicTablesPkg/Library/Acpi/Common
Hi Pierre, Sami,
Thanks a lot again for this work!.
The series looks good to me as well. I agree with Sami's suggestions.
However, I have a request for an additional change. The common ACPI
tables still use ARMH/ARMLTD as the CREATOR_ID/OEM_ID. Can they be made
architecture specific?
Reviewed-b
Hi Sunil,
I think we can look into that. My initial thoughts are that this can be solved
using a Pcd. However, we need a bit of investigation.
Is it ok if we address that in a separate patch?
Regards,
Sami Mujawar
On 03/07/2024, 10:37, "Sunil V L" mailto:suni...@ventanamicro.com>> wrote:
Hi
On Wed, Jul 03, 2024 at 09:39:22AM +, Sami Mujawar wrote:
> Hi Sunil,
>
> I think we can look into that. My initial thoughts are that this can be
> solved using a Pcd. However, we need a bit of investigation.
> Is it ok if we address that in a separate patch?
>
Sure!.
Thanks,
Sunil
> Regard
Small fixes reported while running the CI.
These patches should be applied on top of:
- [staging/dynamictables-reorg PATCH 00/15] Prepare libraries to support other
archs
https://edk2.groups.io/g/devel/message/119632
Cc: AbdulLateef Attar
Cc: Girish Mahadevan
Cc: Jeff Brasen
Cc: Jeshua Smit
Some CM objects fields are wider than the targeted field in ACPI
tables. Some assignments are also subject to data loss and
trigger the following warnings:
- '<': signed/unsigned mismatch
- '=': conversion from 'UINTxx' to 'UINTyy', possible loss of data
with xx > yy.
Add checks/cast to remove the
For X64 builds, the EFIAPI is replaced by '(__attribute__((ms_abi))'.
This might lead to build error for some ACPI tablte generators
due to function prototype mismatch.
Add the EFIAPI to ACPI table generator hooks:
- ACPI_TABLE_GENERATOR_BUILD_TABLEEX
- ACPI_TABLE_GENERATOR_FREE_TABLEEX
Signed-of
Hello Sami,
On 7/3/24 11:08, Sami Mujawar wrote:
Hi Pierre,
Overall, this patch series looks good to me.
I have some minor comments regarding the return value for the Arch hook
functions their placement in Common folder.
e.g. in Patch "DynamicTablesPkg: AcpiFadtLib: Prepare to support other a
Hi Pierre,
Thank you for these patches.
On 03/07/2024, 10:54, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Some CM objects fields are wider than the targeted field in ACPI
tables. Some assignments are also subject to data loss and
trigger the following warnings:
- '<': signed/unsig
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 03/07/2024, 10:54, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
For X64 builds, the EFIAPI is replaced by '(__attribute__((ms_abi))'.
This might lead to build
Hi Sami,
On 7/3/24 12:35, Sami Mujawar wrote:
Hi Pierre,
Thank you for these patches.
On 03/07/2024, 10:54, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Some CM objects fields are wider than the targeted field in ACPI
tables. Some assignments are also subject to data loss and
tr
Hi,
So I've a SBL+EDK2 customized firmware. This firmware enters the BIOS menu in
approximately 17 seconds. I haven't seen this as a problem for a long time, but
I've seen some CFL motherboards boot up the OS in 17 seconds. The motherboard I
use is CFL-H. Is there a solution that will allow me
# FAT filesystem + GPT/MBR partitioning + UDF filesystem
---
base-commit: c7ed8deaa8c1d7ee83af994b2c90d4490ef27bdc
change-id: 20240703-efi-rng-protocol-be991536709a
Best regards,
--
Marcin Juszkiewicz
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Re
*Reminder: TianoCore edk2-test Bug Triage Meeting*
*When:*
Thursday, July 4, 2024
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai
*Where:*
https://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2JFaU5jdWUxc1FnaGdyUT09&from=addon
*Organizer:*
Edhaya Chandran
edhaya.chand...@arm.com (
edhaya.chand...@arm
On 7/1/24 13:16, Rebecca Cran via groups.io wrote:
Now that edk2 has been using PRs for a few weeks, I'd like to propose
enabling the same workflow for edk2-platfoms.
As maintainers or reviewers of platforms in the edk2-platforms repo, I'd
like to get any feedback on moving from email-based re
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Rebecca,
Having GitHub CODEOWNERS to assign reviewers for the PR is fine to me, as well
as only maintainers have the privilege to set "Push" label. I would suggest we
use only one CODEOWNERS file on the repo so we can easily find the co
17 matches
Mail list logo
