Re: [edk2-devel] [RFC PATCH v1 00/20] DynamicTablesPkg: Prepare to add RISC-V support

["Sami Mujawar" <sami.mujawar@arm.com>]

Hi All,

DynamicTablesPkg currently supports Arm architecture, and we welcome the adoption by other architectures.

Following is my proposal for moving forward.

Goals:
- reuse common code
- streamline the adoption by other architectures
- minimise the impact on migration of the existing platforms
- maintain flexibility across architectural components
- use this opportunity to integrate Dynamic SMBIOS support
  (Ref: https://edk2.groups.io/g/devel/message/107254)

The following steps would help in achieving the goals:
1.  Create an edk2 staging branch. For the edk2-platforms updates, I will create a branch on my Github fork (note this is required as there is no staging repo for edk2-platforms).
2. The design aspects and changes shall be discussed on the mailing list with patches to support the details.
3. A new section in DynamicTablesPkg\Readme.md shall be added to reflect the design updates, e.g. changes to CM Objects, Namespace definitions, etc.
4.  The design changes should typically be supported by patches for the DynamicTables core framework and demonstrate the impact on the existing platform code by typically providing patches for at least one existing platform (possibly edk2-platforms/Platform/ARM/[Juno | FVP]).
5. The design changes should be small and typically be reflected in separate patch series.
6. The first phase would be to partition the codebase into common code vs architectural specific code. This would involve moving files and reflecting the associated changes such that the build does not break.
7. Define a new namespace e.g. “ArchCommon” for the common architectural components.
8. Identify the CM_ARM_OBJECTs that can be moved to the “ArchCommon” namespace. As part of this identify if any object needs to be dropped, e.g. EArmObjReserved29
9. Identify overlap of SMBIOS objects with existing CM Objects.
10. Submit patches to move CM objects from Arm Namespace to ArchCommon Namespace. Ideally one object (and any dependencies) should be moved at a time.
11. Submit patches to migrate upstream platforms that use DynamicTablesPkg
12. Define a new namespace for RISCV specific objects
13. Submit patches for enabling RISCV
14. In the next phase support for Dynamic SMBIOS can be enabled.

Notes: 
a. Periodically rebase with edk2 & edk2-platforms master branch to sync with latest changes.
b. We can decide to merge the updates after point 11 above to edk2 & edk2-platforms master branch.
c. Similarly, the RISCV support can be merged after point 13.

I will send out a request for creating the staging branch shortly.

Regards,

Sami Mujawar

On 10/01/2024, 21:56, "Jeshua Smith" <jeshuas@nvidia.com <mailto:jeshuas@nvidia.com>> wrote:


> > It looks like instead of moving the common code to
> EObjNameSpaceStandard namespace or a new (Arch? Common?) namespace,
> you're renaming the entire EObjNameSpaceArm namespace to
> EObjNameSpaceArch. It seems to me that if ARM code vs. common code is
> being separated out, then the EObjNameSpaceArm namespace should
> continue to be used for the ARM-specific code and a common namespace
> should be used for the common code.
> 
> I agree. I started with separating common things into new common space and
> create one for risc-v. However, I dropped that approach for two reasons.
> 
> 1) The commit "b2bbe3df5470 DynamicTablesPkg: Remove PPTT ID structure
> from ACPI 6.4 generator" when removed one of the enums from
> ArmObjectID, didn't change the other values for other enums but reserved the
> removed one. So, I thought there may be some assumptions which will break
> if the enum value changes.


I'm not familiar with why that was done. Hopefully someone else can comment. I do know that edk2/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c has arrays (StdNamespaceObjectParser and ArmNamespaceObjectParser) that need to be kept in sync with all of the namespace enums, but other than that I'm not aware of any places that need to be changes when the enums are changed.


> 2) DynamicPlatformRepositoryInfo structure has ArmCmObjList and
> ArmCmObjArray. With separate spaces for Arm, RiscV and Common, list
> management needs some redesign and I was not sure it is worth it.
> 
> Hence, I thought a single list of all possible Obj Ids for all architectures and
> common things would be a good trade off. But I can go back to that approach
> in v2 if above issues are fine.


Hopefully ARM can give input on the best direction before you make more changes. The DynamicPlatRepo currently only supports the ARM namespace, but comments such as "only Arm objects are supported for now." (line 144) seem to imply that support for more namespaces was considered.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114142): https://edk2.groups.io/g/devel/message/114142
Mute This Topic: https://groups.io/mt/103622702/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-