I am using a PCEngines APU2 system and I noticed that its HPET timers do not advertise FSB (MSI) interrupt delivery capability. That is despite the fact that BKDG for family 16h models 30h - 3Fh says that those capability bits are hardwired to 1. I took a quick look through coreboot sources (APU2 firmware is coreboot) and noticed something interesting. It seems that the repository includes code for AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be turned on / off via a special PM I/O register. It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE, // HpetMsiDis src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c: TRUE, // HpetMsiDis
Does anyone know what is a reason for that? Are there any hardware errata related to that feature? I think that MSI delivery is more efficient and "sexy" than the traditional delivery via IO-APIC (although everything is integrated).
Also, is there a way to override that default in a mainboard configuration?
Thank you.
On 01.07.2019 14:53, Andriy Gapon wrote:
I am using a PCEngines APU2 system and I noticed that its HPET timers do not advertise FSB (MSI) interrupt delivery capability.
Any logs pointing to the statement?
That is despite the fact that BKDG for family 16h models 30h - 3Fh says that those capability bits are hardwired to 1. I took a quick look through coreboot sources (APU2 firmware is coreboot) and noticed something interesting. It seems that the repository includes code for AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be turned on / off via a special PM I/O register. It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE, // HpetMsiDis src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c: TRUE, // HpetMsiDis
Does anyone know what is a reason for that? Are there any hardware errata related to that feature? I think that MSI delivery is more efficient and "sexy" than the traditional delivery via IO-APIC (although everything is integrated).
Also, is there a way to override that default in a mainboard configuration?
In the BIosCallOuts.c for the platform You could try explicitly set the HpetMsiDis to FALSE. In function Fch_Oem_config in the AMD_INIT_ENV try to add:
FchParams->Hpet.HpetEnable = TRUE; FchParams->Hpet.HpetMsiDis = FALSE;
Maybe it will change anything. Regarding the reasons, it may not be any particular reason. PC Engines apu2 is initialized with AGESA binary blob not built from source code, so the code is not fully auditable. It is likely that the AGESA is not initializing the MSI for HPET. Neither it is documented in BKDG.
Thank you.
Michal Zygowski:
On 01.07.2019 14:53, Andriy Gapon wrote:
It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE, // HpetMsiDis
FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my f15tn. It caused Qubes to run about half as fast. I checked the logs and didn't see any errors to explain why. I then changed it back to TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed came back, XEN Platform timer changed from HPET to ACPI, and MSI is still enabled for some of the PCI devices. For example, the video controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
On 03.07.2019 04:30, awokd via coreboot wrote:
Michal Zygowski:
On 01.07.2019 14:53, Andriy Gapon wrote:
It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
TRUE, // HpetMsiDis
FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my f15tn. It caused Qubes to run about half as fast. I checked the logs and didn't see any errors to explain why. I then changed it back to TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed came back, XEN Platform timer changed from HPET to ACPI, and MSI is still enabled for some of the PCI devices. For example, the video controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
Yes, for PCI devices it can be checked by verbose lspci. However I still wonder how did You determine that HPET is not using MSI? When You set the HPET option to FALSE, it probably did not touch HPET in AGESA, that is why the speed came back. I would check whether HPET is operable for this processor family. For example on Intel Braswell platform HPET was not guaranteed operable in certain conditions.
BTW have You tried with family 16h (i.e. PC Engines APU2)?
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Michal Zygowski:
On 03.07.2019 04:30, awokd via coreboot wrote:
Michal Zygowski:
On 01.07.2019 14:53, Andriy Gapon wrote:
It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
TRUE, // HpetMsiDis
FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my f15tn. It caused Qubes to run about half as fast. I checked the logs and didn't see any errors to explain why. I then changed it back to TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed came back, XEN Platform timer changed from HPET to ACPI, and MSI is still enabled for some of the PCI devices. For example, the video controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
Yes, for PCI devices it can be checked by verbose lspci. However I still wonder how did You determine that HPET is not using MSI?
Apologies, omitted that part. With the original default of HPET enabled and HpetMsiDis TRUE, the speed was fine. Xen platform timer indicated HPET in this case. Devices also still seemed to be using MSI, so I'm not sure what that option is supposed to do except slow down my system.
When You set the HPET option to FALSE, it probably did not touch HPET in AGESA, that is why the speed came back. I would check whether HPET is operable for this processor family. For example on Intel Braswell platform HPET was not guaranteed operable in certain conditions.
BTW have You tried with family 16h (i.e. PC Engines APU2)?
Don't have one of those, but wanted to give a (possibly useless) data point of my experience at least.
On 03.07.2019 15:13, awokd via coreboot wrote:
Michal Zygowski:
On 03.07.2019 04:30, awokd via coreboot wrote:
Michal Zygowski:
On 01.07.2019 14:53, Andriy Gapon wrote:
It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
TRUE, // HpetMsiDis
FWIW, I hardcoded the above to FALSE, recompiled, and reflashed my f15tn. It caused Qubes to run about half as fast. I checked the logs and didn't see any errors to explain why. I then changed it back to TRUE and HPET itself to FALSE (and recompiled/reflashed). Normal speed came back, XEN Platform timer changed from HPET to ACPI, and MSI is still enabled for some of the PCI devices. For example, the video controller on 00:01.0 is IRQ 57 and capability [a0] is MSI: Enable+.
Yes, for PCI devices it can be checked by verbose lspci. However I still wonder how did You determine that HPET is not using MSI?
Apologies, omitted that part. With the original default of HPET enabled and HpetMsiDis TRUE, the speed was fine. Xen platform timer indicated HPET in this case. Devices also still seemed to be using MSI, so I'm not sure what that option is supposed to do except slow down my system.
If timer interrupts are not handled properly for some reason (in this case HPET timer), it is only natural that it will dramatically slow down the system. The MSI can be working, but may also require some IOAPIC configuration. Can't say much without any logs from firmware/OS.
When You set the HPET option to FALSE, it probably did not touch HPET in AGESA, that is why the speed came back. I would check whether HPET is operable for this processor family. For example on Intel Braswell platform HPET was not guaranteed operable in certain conditions.
BTW have You tried with family 16h (i.e. PC Engines APU2)?
Don't have one of those, but wanted to give a (possibly useless) data point of my experience at least.
Sorry, I have mistakenly taken You as the initiator of the thread, who stated he has an APU2 platform. Should have checked the email address first.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 01.07.19 14:53, Andriy Gapon wrote:
Hi,
speaking w/ my linux apu2/3 platform driver maintainer hat on:
I am using a PCEngines APU2 system and I noticed that its HPET timers do not advertise FSB (MSI) interrupt delivery capability.
That is interesting. Can you give us something to reproduce the problem (test-cases, etc) ? Could you test whether it's just
I was under the impression that the g412's x86 cores are pretty straightforward, but maybe I'm wrong. So another 2do on my list ...
That is despite the fact that BKDG for family 16h models 30h - 3Fh says that those capability bits are hardwired to 1. I took a quick look through coreboot sources (APU2 firmware is coreboot) and noticed something interesting. It seems that the repository includes code for AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be turned on / off via a special PM I/O register. It appears that HPET MSI support is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE, // HpetMsiDis src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c: TRUE, // HpetMsiDis
Does anyone know what is a reason for that?
Maybe the HPET core can be attached in different ways inside the SoC. The name "disable" sounds like the standard behaviour is enabled, but can be disabled if really needed.
On my Box, Linux reports using IO-APIC. I think because cpuid has arat flag (always running apic timer). My wild guess is that HPET isn't used at all in this case. (perhaps because using it seems not very efficient)
--mtx
On 03.07.19 12:57, Michal Zygowski wrote:
I would check whether HPET is operable for> this processor family. For example on Intel Braswell platform HPET
was> not guaranteed operable in certain conditions.
The linux kernel doesn't use the hpet on at least some ATI board. Maybe for exactly that reason. (see: arch/x86/kernel/quirks.c)
--mtx
-
Andriy Gapon -
awokd -
Enrico Weigelt, metux IT consult -
Michal Zygowski