Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C files

["PierreGondois" <pierre.gondois@arm.com>]

Hello Ard,

> So this is for making changes at runtime, right? And are you only
> using the char[] array in its entirety?
Yes, this is to make changes at runtime on SSDT tables.
If we consider that the SSDT table contained in the char[] array is in two parts: the header, and the AML blob; what we effectively need is the AML blob. However, the header is still very useful to have the size of the AML blob and other information as the name of the table, a checksum etc. Not having the SSDT header would mean that we would need get the size of the table by another mean.

> You could look at SynQuacer or Overdrive platforms: those also load
> SSDT tables from FFS sections at runtime.
I think the arm FVP and Juno platforms where also loading ACPI tables (DSDT/SSDT included) from FFS sections previous to the dynamic tables framework.
The FVP is loading its ACPI tables (DSDT/SSDT included) with the MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf module. The module uses this function to find the ACPI tables:
/**
  Locate the first instance of a protocol.  If the protocol requested is an
  FV protocol, then it will return the first FV that contains the ACPI table
  storage file.

  @param  Instance      Return pointer to the first instance of the protocol

  @return EFI_SUCCESS           The function completed successfully.
  @return EFI_NOT_FOUND         The protocol could not be located.
  @return EFI_OUT_OF_RESOURCES  There are not enough resources to find the protocol.

**/
EFI_STATUS
LocateFvInstanceWithTables (
  OUT EFI_FIRMWARE_VOLUME2_PROTOCOL **Instance
  )

The Juno is loading its ACPI tables (DSDT/SSDT included) with the edk2-platforms/Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c module, using this function:
/**
  Locate and Install the ACPI tables from the Firmware Volume

  @param  AcpiFile              Guid of the ACPI file into the Firmware Volume

  @return EFI_SUCCESS           The function completed successfully.
  @return EFI_NOT_FOUND         The protocol could not be located.
  @return EFI_OUT_OF_RESOURCES  There are not enough resources to find the protocol.

**/
EFI_STATUS
LocateAndInstallAcpiFromFv (
  IN CONST EFI_GUID* AcpiFile
  )


About the platform you pointed, what I understood:
- Overdrive platform:
  This platform loads ACPI tables from FFS sections. Depending on PCD values, the driver at edk2-platforms/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe decides which tables to install.
  The code I am describing in the following paragraph is available at edk2-platforms/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c:

  When finding the SSDT table generated from SsdtXgbe.asl, the driver patches the two MAC addresses described in the SSDT table.
  To do so, it parses the AML bytecode, looking for the pattern mDefaultMacPackageA (resp mDefaultMacPackageB for the second MAC address).
  It then updates the value with a mix of the pattern (mDefaultMacPackageA) and a PCD value (PcdEthMacA).

- SynQuacer platform:
  This platform installs ACPI tables (DSDT/SSDT included) with the MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf module.
  I think the FVP was using the same module before using the dynamic tables.
  The only particularity that I can find is for the SSDT table generated from edk2-platforms/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.asl.
  This table is fetched from FFS, like the other tables of the platform available at edk2-platforms/Silicon/Socionext/SynQuacer/AcpiTables. It is however installed
  under certain conditions, and by sending an event to the gEfiAcpiTableProtocolGuid. When the gEfiAcpiTableProtocolGuid is installed, the emmc table is installed aswell.

To answer your remark, I think this is effectively possible to retrieve our SSDT templates from the FFS. However, these templates are not meant to be installed as such. Each SSDT template needs to be patched by a piece of '.c' code before being installed. As each piece of '.c' code is specific to an ASL template (and vice versa), they form a couple. I think it would be better bind this couple in a same unique module.

To compare with what is done on the Overdrive platform, in order to install the SsdtXgbe SSDT table, the platform needs to:
- Compile all its ASL files
- Pack them in a Firmware Volume
- Look in the FFS for the SsdtXgbe SSDT table
- Once found, update the MAC addresses
- Install the SsdtXgbe SSDT table

Except if other modules want to access the SsdtXgbe SSDT table, it doesn't seem to me that the table needs to go through the FFS to end in the source code updating the MAC address. Effectively, the code making the modification and the table are in the same module. Plus, making the table available to other modules could be a threat.

What we would like to do is:
- Compile each template/generator couple (the generator is the '.c' file) as a module
- For each couple, when executing the generator, update some values in the corresponding SSDT table. As the SSDT table is available in the generator as an array (included from the '.hex' file), there is no need to look in the FFS
- For each couple, install the template SSDT table

Regards,
Pierre