[U-Boot] x86: ACPI support suggestion

[U-Boot] x86: ACPI support suggestion

[Gabriel Huau]

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, ...).

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.

Thanks,
Regards,
Gabriel

[U-Boot] x86: ACPI support suggestion

[Simon Glass]

+Bin

Hi Gabriel,

On 4 February 2015 at 12:22, Gabriel Huau <contact@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.

>
> 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.

Regards,
Simon

[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@chromium.org> wrote:
> +Bin
>
> Hi Gabriel,
>
> On 4 February 2015 at 12:22, Gabriel Huau <contact@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] 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@chromium.org> wrote:
>> +Bin
>>
>> Hi Gabriel,
>>
>> On 4 February 2015 at 12:22, Gabriel Huau <contact@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] x86: ACPI support suggestion

[Simon Glass]

Hi Gabriel,

On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr> wrote:
> 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.

One thing to note is that U-Boot may not currently set up the PCI
interrupts fully. Or perhaps the problem is that ACPI needs to match.
What platform are you using?

[snip]

[U-Boot] x86: ACPI support suggestion

[Gabriel Huau]

Hi Simon,

On 02/06/2015 03:04 PM, Simon Glass wrote:
> Hi Gabriel,
>
> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>> 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.
> One thing to note is that U-Boot may not currently set up the PCI
> interrupts fully. Or perhaps the problem is that ACPI needs to match.
> What platform are you using?
>
> [snip]

MinnowBoard Max (BayTrail).

Actually, you may be right, I didn't check this part.

[U-Boot] x86: ACPI support suggestion

[Simon Glass]

Hi,

On 6 February 2015 at 16:11, Gabriel Huau <contact@huau-gabriel.fr> wrote:
> Hi Simon,
>
>
> On 02/06/2015 03:04 PM, Simon Glass wrote:
>>
>> Hi Gabriel,
>>
>> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>>>
>>> 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.
>>
>> One thing to note is that U-Boot may not currently set up the PCI
>> interrupts fully. Or perhaps the problem is that ACPI needs to match.
>> What platform are you using?
>>
>> [snip]
>
>
> MinnowBoard Max (BayTrail).
>
> Actually, you may be right, I didn't check this part.
>

Actually that uses an FSP so might already be correct, but it is
certainly worth checking.

Regards,
Simon

[U-Boot] x86: ACPI support suggestion

[Gabriel Huau]

Hi Simon,

On 02/06/2015 03:14 PM, Simon Glass wrote:
> Hi,
>
> On 6 February 2015 at 16:11, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>> Hi Simon,
>>
>>
>> On 02/06/2015 03:04 PM, Simon Glass wrote:
>>> Hi Gabriel,
>>>
>>> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>>>> 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.
>>> One thing to note is that U-Boot may not currently set up the PCI
>>> interrupts fully. Or perhaps the problem is that ACPI needs to match.
>>> What platform are you using?
>>>
>>> [snip]
>>
>> MinnowBoard Max (BayTrail).
>>
>> Actually, you may be right, I didn't check this part.
>>
> Actually that uses an FSP so might already be correct, but it is
> certainly worth checking.

I just checked the dmesg again and I didn't see that the first time:

[    0.723098] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 12 14 
15) *0, disabled.
[    0.732328] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 11 12 14 
15) *0, disabled.
[    0.741551] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 12 14 
15) *0, disabled.
[    0.750782] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 11 12 14 
15) *0, disabled.
[    0.760006] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 12 14 
15) *0, disabled.

So I believe the PIRQ routing is missing in u-boot. I checked in the 
source of Coreboot, and actually everything is done in the southcluster 
initialization.
Also, I saw that the GPIO iomap wasn't done and it appeared that the 
USB2 port wasn't powered up (the white one), enabling the port allow us 
to use of both port in the EHCI mode.

I'll give a try to initialize the PIRQ and see how things is going.

> Regards,
> Simon

[U-Boot] x86: ACPI support suggestion

[Simon Glass]

Hi Gabriel,

On 7 February 2015 at 08:07, Gabriel Huau <contact@huau-gabriel.fr> wrote:
> Hi Simon,
>
>
> On 02/06/2015 03:14 PM, Simon Glass wrote:
>>
>> Hi,
>>
>> On 6 February 2015 at 16:11, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> On 02/06/2015 03:04 PM, Simon Glass wrote:
>>>>
>>>> Hi Gabriel,
>>>>
>>>> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr>
>>>> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> One thing to note is that U-Boot may not currently set up the PCI
>>>> interrupts fully. Or perhaps the problem is that ACPI needs to match.
>>>> What platform are you using?
>>>>
>>>> [snip]
>>>
>>>
>>> MinnowBoard Max (BayTrail).
>>>
>>> Actually, you may be right, I didn't check this part.
>>>
>> Actually that uses an FSP so might already be correct, but it is
>> certainly worth checking.
>
>
> I just checked the dmesg again and I didn't see that the first time:
>
> [    0.723098] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
> [    0.732328] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 11 12 14 15)
> *0, disabled.
> [    0.741551] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
> [    0.750782] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 11 12 14 15)
> *0, disabled.
> [    0.760006] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
>
> So I believe the PIRQ routing is missing in u-boot. I checked in the source
> of Coreboot, and actually everything is done in the southcluster
> initialization.
> Also, I saw that the GPIO iomap wasn't done and it appeared that the USB2
> port wasn't powered up (the white one), enabling the port allow us to use of
> both port in the EHCI mode.
>
> I'll give a try to initialize the PIRQ and see how things is going.

OK, sounds good.

Regards,
Simon

[U-Boot] x86: ACPI support suggestion

[Bin Meng]

Hi Gabriel,

On Sat, Feb 7, 2015 at 11:07 PM, Gabriel Huau <contact@huau-gabriel.fr> wrote:
> Hi Simon,
>
>
> On 02/06/2015 03:14 PM, Simon Glass wrote:
>>
>> Hi,
>>
>> On 6 February 2015 at 16:11, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> On 02/06/2015 03:04 PM, Simon Glass wrote:
>>>>
>>>> Hi Gabriel,
>>>>
>>>> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr>
>>>> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> One thing to note is that U-Boot may not currently set up the PCI
>>>> interrupts fully. Or perhaps the problem is that ACPI needs to match.
>>>> What platform are you using?
>>>>
>>>> [snip]
>>>
>>>
>>> MinnowBoard Max (BayTrail).
>>>
>>> Actually, you may be right, I didn't check this part.
>>>
>> Actually that uses an FSP so might already be correct, but it is
>> certainly worth checking.
>
>
> I just checked the dmesg again and I didn't see that the first time:
>
> [    0.723098] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
> [    0.732328] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 11 12 14 15)
> *0, disabled.
> [    0.741551] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
> [    0.750782] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 11 12 14 15)
> *0, disabled.
> [    0.760006] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 12 14 15)
> *0, disabled.
>
> So I believe the PIRQ routing is missing in u-boot. I checked in the source
> of Coreboot, and actually everything is done in the southcluster
> initialization.
> Also, I saw that the GPIO iomap wasn't done and it appeared that the USB2
> port wasn't powered up (the white one), enabling the port allow us to use of
> both port in the EHCI mode.
>
> I'll give a try to initialize the PIRQ and see how things is going.
>

Did you manage to get PIRQ work on MinnowMax? If not, I think you may
try to implement PIRQ routing support first to see how things go. You
can look at Intel Crown Bay device tree to add the PIRQ routing for
MinnowMax.

As for ACPI support, we have already started the work as part of GSoC 2015.

Regards,
Bin

[U-Boot] x86: ACPI support suggestion

[Gabriel Huau]

Hi Bin,

On 06/23/2015 04:30 AM, Bin Meng wrote:
> Hi Gabriel,
>
> On Sat, Feb 7, 2015 at 11:07 PM, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>> Hi Simon,
>>
>>
>> On 02/06/2015 03:14 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 6 February 2015 at 16:11, Gabriel Huau <contact@huau-gabriel.fr> wrote:
>>>> Hi Simon,
>>>>
>>>>
>>>> On 02/06/2015 03:04 PM, Simon Glass wrote:
>>>>> Hi Gabriel,
>>>>>
>>>>> On 6 February 2015 at 16:01, Gabriel Huau <contact@huau-gabriel.fr>
>>>>> wrote:
>>>>>> 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.
>>>>> One thing to note is that U-Boot may not currently set up the PCI
>>>>> interrupts fully. Or perhaps the problem is that ACPI needs to match.
>>>>> What platform are you using?
>>>>>
>>>>> [snip]
>>>>
>>>> MinnowBoard Max (BayTrail).
>>>>
>>>> Actually, you may be right, I didn't check this part.
>>>>
>>> Actually that uses an FSP so might already be correct, but it is
>>> certainly worth checking.
>>
>> I just checked the dmesg again and I didn't see that the first time:
>>
>> [    0.723098] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 12 14 15)
>> *0, disabled.
>> [    0.732328] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 11 12 14 15)
>> *0, disabled.
>> [    0.741551] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 12 14 15)
>> *0, disabled.
>> [    0.750782] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 11 12 14 15)
>> *0, disabled.
>> [    0.760006] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 12 14 15)
>> *0, disabled.
>>
>> So I believe the PIRQ routing is missing in u-boot. I checked in the source
>> of Coreboot, and actually everything is done in the southcluster
>> initialization.
>> Also, I saw that the GPIO iomap wasn't done and it appeared that the USB2
>> port wasn't powered up (the white one), enabling the port allow us to use of
>> both port in the EHCI mode.
>>
>> I'll give a try to initialize the PIRQ and see how things is going.
>>
> Did you manage to get PIRQ work on MinnowMax? If not, I think you may
> try to implement PIRQ routing support first to see how things go. You
> can look at Intel Crown Bay device tree to add the PIRQ routing for
> MinnowMax.
>
> As for ACPI support, we have already started the work as part of GSoC 2015.
>
> Regards,
> Bin

No, actually I will try to run some tests this week end, I'll keep you 
posted.

This is good news for the ACPI support, I just saw the projects for the 
minnowboard, I'm really excited to see the first patches.

Regards,
Gabriel