From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 20B5D941CDE for ; Tue, 30 Jan 2024 17:14:29 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=KH8vZiWfFkhgOGAyyOgzFXLcC5bBn26fT2giLwyz7bk=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706634868; v=1; b=SVEcmJiU6JkyrhRHRg+ifmnaaLfRDNcQtDjCNiAF23+BVNSWd7OcYUe9rmV5h1Mv4arKdBdx CHcIEnNo4KHMpEMUHjcwjTkJia3X/n2pCxbagiBzd3lWvA17xA/DYNcGeUFFJuwpweGEAv+NRgl 5r7EVxzWuE8cBOndh1goQUm0= X-Received: by 127.0.0.2 with SMTP id zYCtYY7687511xTVeSJ6feah; Tue, 30 Jan 2024 09:14:28 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.1797.1706634867901463251 for ; Tue, 30 Jan 2024 09:14:28 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-558-N-JsgWKYMJWyzlITLKhTvQ-1; Tue, 30 Jan 2024 12:14:23 -0500 X-MC-Unique: N-JsgWKYMJWyzlITLKhTvQ-1 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 25D6B85A58F; Tue, 30 Jan 2024 17:14:21 +0000 (UTC) X-Received: from [10.39.192.28] (unknown [10.39.192.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 907A0202DCC8; Tue, 30 Jan 2024 17:14:18 +0000 (UTC) Message-ID: <80197829-818f-6d6f-cca0-567392010503@redhat.com> Date: Tue, 30 Jan 2024 18:14:17 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [staging/dynamictables-reorg PATCH v1 1/1] Branch to reorg Dynamic Tables & support other arch To: Sami Mujawar , devel@edk2.groups.io Cc: michael.d.kinney@intel.com, quic_llindhol@quicinc.com, ardb+tianocore@kernel.org, pierre.gondois@arm.com, YeoReum.Yun@arm.com, Akanksha.Jain2@arm.com, Sibel.Allinson@arm.com, sunilvl@ventanamicro.com, andrei.warkentin@intel.com, AbdulLateef.Attar@amd.com, gmahadevan@nvidia.com, jeshuas@nvidia.com, jbrasen@nvidia.com, meenakshi.aggarwal@nxp.com, nd@arm.com References: <20240130145035.24760-1-sami.mujawar@arm.com> From: "Laszlo Ersek" In-Reply-To: <20240130145035.24760-1-sami.mujawar@arm.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 4nUtIwxtmgOWuGGE9sZPNYOix7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=SVEcmJiU; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 1/30/24 15:50, Sami Mujawar wrote: > Dynamic Tables Framework currently supports Arm Architecture. > This patch introduces a new staging branch for Dynamic Tables > Framework to: > - Reorganise the code to streamline adoption by other architectures > - Introduce Dynamic Tables support for RISC-V architecture > - Integrate Dynamic SMBIOS support. >=20 > The description is in the Readme.md file. >=20 > Please create the following branches: > 1. edk2-staging Repo > URL: https://github.com/tianocore/edk2-staging.git > Branch Name: dynamictables-reorg >=20 > 2. edk2-platforms Repo > URL: https://github.com/tianocore/edk2-platforms.git > Branch Name: devel-dynamictables-reorg >=20 > Signed-off-by: Sami Mujawar > --- > Readme.md | 237 ++++++++++++++++++++ > 1 file changed, 237 insertions(+) Not sure if there's a specific reason for CC'ing me on this, but it looks very nice to me. Reviewed-by: Laszlo Ersek NB: I'm not familiar with the staging tree / branches. I guess the perceived risk here is that some patches might prove a "dead-end" ultimately, and then undoing those on a staging branch could be easier -- potentially non-fast-forward merges could be permitted there; is that right? Personally I'd just start the work on the edk2 master branch (because your goal, very correctly, is to keep the tree buildable at any stage), and then advance in very small steps. The roadmap seems to be carefully constructed anyway, and then you could avoid any big jumps with the periodic rebases. But, again, I'm not familiar with the staging stuff; so I'm sure there are serious reasons (expectation of chaos, temporarily? :) ), for going about the feature like this. Thanks Laszlo >=20 > diff --git a/Readme.md b/Readme.md > new file mode 100644 > index 0000000000000000000000000000000000000000..3031a8967785a2ef90f05b5b0= d77053aa82364d3 > --- /dev/null > +++ b/Readme.md > @@ -0,0 +1,237 @@ > +# Introduction > + > +**DynamicTablesPkg** currently supports Arm architecture, and we welcome= the > +adoption by other architectures. > + > +This branch will be used to: > + - Reorganise the code to streamline adoption by other architectures. > + - Introduce Dynamic Tables support for RISC-V architecture > + - Integrate Dynamic SMBIOS support > + () > + > +## Goals > + - Streamline adoption by other architectures. > + - Minimise the impact of migration for existing platforms > + - Reuse common code > + - Maintain flexibility across architectural components > + > +# Dynamic Tables Framework > + > +The dynamic tables framework is designed to generate standardised > +firmware tables that describe the hardware information at > +run-time. A goal of standardised firmware is to have a common > +firmware for a platform capable of booting both Windows and Linux > +operating systems. > + > +Traditionally the firmware tables are handcrafted using ACPI > +Source Language (ASL), Table Definition Language (TDL) and > +C-code. This approach can be error prone and involves time > +consuming debugging. In addition, it may be desirable to configure > +platform hardware at runtime such as: configuring the number of > +cores available for use by the OS, or turning SoC features ON or > +OFF. > + > +The dynamic tables framework simplifies this by providing a set > +of standard table generators, that are implemented as libraries. > +These generators query a platform specific component, the > +'Configuration Manager', to collate the information required > +for generating the tables at run-time. > + > +The framework also provides the ability to implement custom/OEM > +generators; thereby facilitating support for custom tables. The > +custom generators can also utilize the existing standard generators > +and override any functionality if needed. > + > +The framework currently implements a set of standard ACPI table > +generators for Arm architecture, these include both data tables > +and ASL tables. The ASL generation includes support for both > +fixup, where a template AML code is patched, and additionally > +provides an API to parse, search, generate and serialise the > +AML bytecode. > + > +Although, the set of standard generators implement the functionality > +required for Arm architecture; the framework is extensible, and > +support for other architectures can be added. > + > +## Branch Owners > + > + - Sami Mujawar > + - Pierre Gondois > + > +## Feature Summary > + > +### Dynamic Tables framework supports > + - ACPI data tables > + - AML tables > + * AML Template Fixup > + * AML Code Generation > + > +The framework currently supports the following table generators for Arm: > + * DBG2 - Debug Port Table 2 > + * DSDT - Differentiated system description table. This is essentially > + a RAW table generator. > + * FADT - Fixed ACPI Description Table > + * GTDT - Generic Timer Description Table > + * IORT - IO Remapping Table > + * MADT - Multiple APIC Description Table > + * MCFG - PCI Express memory mapped configuration space base address > + Description Table > + * SPCR - Serial Port Console Redirection Table > + * SSDT - Secondary System Description Table. This is essentially > + a RAW table generator. > + * PCCT - Platform Communications Channel Table. > + * PPTT - Processor Properties Topology Table. > + * SRAT - System Resource Affinity Table. > + * SSDT-CMN600 - SSDT Table for Arm CoreLink CMN-600 Coherent Mesh Net= work. > + * SSDT-Cpu-Topology - SSDT Table for describing the CPU hierarchy. > + * SSDT-PCIe - SSDT Table describing the PCIe. > + * SSDT-Serial-Port - SSDT Table describing the Serial ports. > + > +## SMBIOS Support > + - A SMBIOS String table helper library has been provided. > + - Initial patches to add SMBIOS support are available at: > + * SMBIOS Dispatcher () > + * SMBIOS Table generation (). > + > +# Roadmap > + > +1. See [Related Modules](#related-modules) section below for details of > + staging repositories and branches to be used for prototyping. > +2. The design aspects and changes shall be discussed on the mailing lis= t > + with patches to support the details. > +3. A new section in DynamicTablesPkg\Readme.md shall be added to reflec= t > + the design updates, e.g. changes to CM Objects, Namespace definition= s, etc. > +4. The design changes should typically be supported by patches for the > + DynamicTables core framework and demonstrate the impact on the platf= orm > + 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 sep= arate > + 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 *ArchCommon* for the common architectural com= ponents. > +8. Identify the CM_ARM_OBJECTs that can be moved to the *ArchCommon* na= mespace. > + 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 DynamicTablesP= kg > +12. Define a new namespace for RISC-V specific objects > +13. Submit patches for enabling RISC-V > +14. In the next phase support for Dynamic SMBIOS can be enabled. > + > +## Note: > +- Periodically rebase with edk2 & edk2-platforms master branch to sync > + with latest changes. > +- Merge *reorg* updates after point 11 above to edk2 & edk2-platforms ma= ster > + branch. > +- Similarly, the RISC-V support can be merged after point 13. > + > +# Related Modules > + > +## edk2-staging > +The *dynamictables-reorg* branch in the **edk2-staging** repository > +contains the updates to streamline the adoption of Dynamic Tables > +Framework by other architectures. > + > +## edk2-platforms > +The *devel-dynamictables-reorg* branch in the **edk2-platforms** reposit= ory > +contains the platform specific changes. > + > +# Related Links > + > +Source Code Repositories for staging:
> + > +### 1. edk2 codebase
> + Repo:
> + Branch: *dynamictables-reorg* > + > +### 2. edk2-platforms codebase
> + Repo:
> + Branch: *devel-dynamictables-reorg* > + > +# Impacted Platforms > + > +| Platform | Location | = Description | Migration Status | Known I= ssues | > +| :---- | :----- | = :---- | :--- | :--- = | > +| Arm Virt Kvmtool | edk2/ArmVirtPkg/KvmtoolCfgMgrDxe | = Arm Kvmtool Guest firmware | | = | > +| FVP | edk2-platforms/Platform/ARM/VExpressPkg | = Arm Fixed Virtual Platform | | = | > +| Juno | edk2-platforms/Platform/ARM/JunoPkg | = Arm Juno Software Development Platform | | = | > +| N1SDP | edk2-platforms/Platform/ARM/N1Sdp | = Arm Neoverse N1 Software Development Platform | | = | > +| Morello FVP | edk2-platforms/Platform/ARM/Morello | = Arm Morello Fixed Virtual Platform | | = | > +| Morello | edk2-platforms/Platform/ARM/Morello | = Arm Morello Software Development Platform | | = | > +| LX2160A | edk2-platforms/Silicon/NXP/LX2160A | = NXP LX2160A | | = | > + > + > +# Prerequisites > + > +Ensure that the latest ACPICA iASL compiler is used for building *Dynami= c Tables Framework*.
> +*Dynamic Tables Framework* has been tested using the following iASL comp= iler version:
> +ACPICA iASL compiler [Version 20230628](https://www.acpica.org/node/183)= , dated 28 June, 2023. > + > +# Build Instructions > + > +1. Set path for the iASL compiler. > + > +2. Set PACKAGES_PATH to point to the locations of the following reposito= ries: > + > +Example: > + > +> set PACKAGES_PATH=3D%CD%\edk2;%CD%\edk2-platforms;%CD%\edk2-non-osi > + > + or > + > +> export PACKAGES_PATH=3D$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi > + > +3. To enable Dynamic tables framework the *'DYNAMIC_TABLES_FRAMEWORK'* > +option must be defined for some platforms that support both traditional > +ACPI tables as well as Dynamic Table generation. This can be passed as > +a command line parameter to the edk2 build system. > + > +Example: > + > +Juno supports both traditional and dynamic ACPI tables. > +>build -a AARCH64 -p Platform\ARM\JunoPkg\ArmJuno.dsc > + -t GCC5 **-D DYNAMIC_TABLES_FRAMEWORK** > + > +or > +FVP only supports dynamic ACPI table generation, so the preprocessor > +flag is not required for the build. > +>build -a AARCH64 -p Platform\ARM\VExpressPkg\ArmVExpress-FVP-AArch64.ds= c > + -t GCC5 > + > +# Documentation > + > +The documentation for the Dynamic Tables Framework is available at > +DynamicTablesPkg\Readme.md. Additionally, Doxygen style documentation > +is used in the code. > + > +# Guidelines for submitting patches > + > +1. Follow the standard edk2 coding guidelines for preparing patches. > + The edk2-staging guidelines can be found at > + > + > +2. To submit a patch for edk2-staging repo include the branch name in > + the subject line of the commit message.
> + e.g. **[staging/dynamictables-reorg PATCH v<*n*> ]: Package/Modu= le: Subject** > + > +3. To submit a patch for edk2-platforms staging repo include the branch > + name in the subject line of the commit message.
> + e.g. **[platforms/devel-dynamictables-reorg PATCH v<*n*> ]: Pack= age/Module: Subject** > + > + > +# Stakeholders/Distribution List > + > + Please send a patch if you wished to be added/removed from the distrib= ution > + list below. > + > + - Sami Mujawar > + - Pierre Gondois > + - Yeo Reum Yun > + > +# Miscellaneous > + -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114805): https://edk2.groups.io/g/devel/message/114805 Mute This Topic: https://groups.io/mt/104054584/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-