[U-Boot] x86: ACPI support suggestion

[Bin Meng]

Hi Gabriel,

Thank you for taking the initiative for the U-Boot ACPI support.

On Thu, Feb 5, 2015 at 3:52 AM, Simon Glass <sjg at chromium.org> wrote:
> +Bin
>
> Hi Gabriel,
>
> On 4 February 2015 at 12:22, Gabriel Huau <contact at huau-gabriel.fr> wrote:
>> Hi All,
>>
>> I'm currently thinking on how to integrate the ACPI support in u-boot x86.
>> I've investigated the coreboot implementation. My first thought was to port
>> all the source code over but looking at the source code in more details it
>> doesn't look like an easy option. For example, it involves reading a lot of
>> values over PCI to dynamically fill the tables, and integration a lot of SoC
>> specific headers (IRQ definition, GPIO, ...).
>
> That doesn't sound nice.

If we choose to implement generating ACPI tables by U-Boot, we have to
do that unfortunately. We may port coreboot stuff and fix anything
that is not good.

>>
>> Therefore, as a first implementation I was thinking about the following:
>>     - booting a board with the Intel UEFI + Linux
>>     - extracting all the ACPI tables (/sys/firmware/acpi/ or acpixtract)
>>     - disassembling the binaries tables via iasl to allow people to modify
>> them
>>     - integrating these files into u-boot in board specific folder (for
>> example: board/intel/minnowmax/acpi/*)
>>     - generating one blob per table using iasl during build time which
>> requires iasl tool to be installed if we have the CONFIG_ACPI
>>     - writing at the RSDP location all the ACPI tables previously exported
>>
>> With this flow, the integration would be quite simple. Also this allows the
>> tables to be modified easily when there is a new release or to add some new
>> devices to the DSDT.
>>
>> What are your thoughts about that?
>>
>> Feel free to provide some feedback on this implementation.
>
> It seems reasonable to me. Bin may have some comments so I copied him.
> We have been using the device tree to statically define the hardware,
> so there is some duplication here. I would like to avoid actually
> using ACPI in U-Boot (device tree seems to do everything we need in a
> boot loader), but generating it make sense, and so long as it is
> source code, we can change it, as you say.
>

This sounds a fast way to enable ACPI support. For the first
implementation, I think it's enough. Let's see how it looks like.

Regards,
Bin