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 <s...@chromium.org> wrote:
+Bin
Hi Gabriel,
On 4 February 2015 at 12:22, Gabriel Huau <cont...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
