[U-Boot] x86: ACPI support suggestion

[Gabriel Huau]

Hi Bin,

Actually I was able to try with a quick&dirty code the integration of 
the ACPI tables (aml files) and it doesn't seem to be possible.
The boot to Linux is working fine, all the ACPI tables are loaded 
correctly, but the system is unstable and it seems to have some issue 
with the interrupts handler.

As debugging this kind of issues could be really tricky and involve also 
a lot of modification, I think we are stuck to port the ACPI support 
from coreboot to u-boot.

I will try to work on a first draft and see how things look like.

Regards,
Gabriel

On 02/06/2015 07:41 AM, Bin Meng wrote:
> 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