[U-Boot] x86: ACPI support suggestion
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
+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
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
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
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]
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.
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
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
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
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
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
participants (3)
-
Bin Meng -
Gabriel Huau -
Simon Glass