From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C files To: Gao, Liming ,devel@edk2.groups.io From: "PierreGondois" X-Originating-Location: Cambridge, England, GB (217.140.106.49) X-Originating-Platform: Windows Firefox 69 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 31 Oct 2019 04:12:09 -0700 References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E53510B@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E53510B@SHSMSX104.ccr.corp.intel.com> Message-ID: <23836.1572520329018772641@groups.io> Content-Type: multipart/alternative; boundary="HGxs1ILWtfYjz6hFNj77" --HGxs1ILWtfYjz6hFNj77 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Liming, Please find my answers marked [PIERRE] inline. >> Can you give the whole solution for this usage model? [Pierre] We are planning to modify specific values in pre-compiled AML definition b= locks at run-time, and then install these AML definition blocks as SSDT tab= les. Instead of having multiple ASL describing the same kind of device (e.g.: a= serial port), we would have one template describing this kind of device (e= .g.: an ASL description of a serial port). This template would be generic for the type of device it is describing, an= d compiled as one standalone AML definition block. Platform specific values of this template would then be modified at run-ti= me. >> Does it mean C source file depends on ASL file? [Pierre] Yes. To do this, we need to embed these pre-compiled AML definition blocks= . The .c file doing the fix-up needs to include this template. Thus this te= mplate needs to be compiled first. The '.inf' file responsible of the fix-up looks like: [SOURCES] SsdtSerialPortTemplate.asl SerialPortFixup.c Compilation of 'SsdtSerialPortTemplate.asl' with the '-tc' option outputs = a 'SsdtSerialPortTemplate.hex' file. '.hex' file's content looks like: unsigned char ssdtserialtemplate_aml_code[] =3D { 0x53,0x53,0x44,0x54,0xC8,0x00,0x00,0x00,=C2=A0 /* 00000000=C2=A0=C2=A0=C2= =A0 "SSDT...." */ ... } The 'SerialPortFixup.c' includes the '.hex' file as shown below: #include "SsdtSerialPortTemplate.hex" >> This is related to the priority of source file type. [Pierre] Yes, the 'SsdtSerialPortTemplate.asl' needs to be compiled (so that the 'S= sdtSerialPortTemplate.hex' is generated) prior to the compilation of 'Seria= lPortFixup.c'. >> Now, there is no method to let user configure them. I suggest to introd= uce the generic way instead of the specific handle. [Pierre] I agree that we should have a generic way to configure the order in which = the files should be compiled. A new "SourceOrder" section could be introduced. This section would descri= be file extensions to compile first, and their order. Unreferenced file ext= ensions would be compiled at the end, unordered. e.g.: [SourceOrder] asl c Here, '.asl' files would be compiled first, then '.c' files. '.asl' files = would remain unordered in among all '.asl' files. '.c' files would remain u= nordered in among all '.c' files. Any remaining files in the "Sources" sect= ion would be compiled at the end, unordered. Regards, Pierre --HGxs1ILWtfYjz6hFNj77 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Liming,
Please find my answers marked [PIERRE] inline.

>> Can you give the whole solution for this usage model?
[Pier= re]
We are planning to modify specific values in pre-compiled AML defi= nition blocks at run-time, and then install these AML definition blocks as = SSDT tables.
Instead of having multiple ASL describing the same kind o= f device (e.g.: a serial port), we would have one template describing this = kind of device (e.g.: an ASL description of a serial port).
This templ= ate would be generic for the type of device it is describing, and compiled = as one standalone AML definition block.
Platform specific values of th= is template would then be modified at run-time.

>> Does it= mean C source file depends on ASL file?
[Pierre]
Yes. To do this= , we need to embed these pre-compiled AML definition blocks. The .c file do= ing the fix-up needs to include this template. Thus this template needs to = be compiled first.

The '.inf' file responsible of the fix-up loo= ks like:
[SOURCES]
  SsdtSerialPortTemplate.asl
  = SerialPortFixup.c

Compilation of 'SsdtSerialPortTemplate.asl' wi= th the '-tc' option outputs a 'SsdtSerialPortTemplate.hex' file. '.hex' fil= e's content looks like:
unsigned char ssdtserialtemplate_aml_code[] = =3D
{
    0x53,0x53,0x44,0x54,0xC8,0x00,0x00,0x00= ,  /* 00000000    "SSDT...." */
   = ...
}

The 'SerialPortFixup.c' includes the '.hex' file as = shown below:
#include "SsdtSerialPortTemplate.hex"

>>= This is related to the priority of source file type.
[Pierre]
Ye= s, the 'SsdtSerialPortTemplate.asl' needs to be compiled (so that the 'Ssdt= SerialPortTemplate.hex' is generated) prior to the compilation of 'SerialPo= rtFixup.c'.

>> Now, there is no method to let user configu= re them. I suggest to introduce the generic way instead of the specific han= dle.
[Pierre]
I agree that we should have a generic way to config= ure the order in which the files should be compiled.
A new "SourceOrde= r" section could be introduced. This section would describe file extensions= to compile first, and their order. Unreferenced file extensions would be c= ompiled at the end, unordered.
e.g.:
  [SourceOrder]
&n= bsp;   asl
    c

Here, '.asl' file= s would be compiled first, then '.c' files. '.asl' files would remain unord= ered in among all '.asl' files. '.c' files would remain unordered in among = all '.c' files. Any remaining files in the "Sources" section would be compi= led at the end, unordered.

Regards,
Pierre --HGxs1ILWtfYjz6hFNj77--