Ok, I’ve found one more solution: don’t generate ACPI C-state tables.
In "devicetree.cb" replace all C-states registers with 0, indicating C0 state.
register "c1_battery" = "0" #"2" # ACPI(C1) =
MWAIT(C1E)
register "c2_battery" = "0" #"3" # ACPI(C2) =
MWAIT(C3)
register "c3_battery" = "0" #"9" # ACPI(C3) =
MWAIT(C7S)
register "c1_acpower" = "0" #"2" # ACPI(C1) =
MWAIT(C1E)
register "c2_acpower" = "0" #"3" # ACPI(C2) =
MWAIT(C3)
register "c3_acpower" = "0" #"9" # ACPI(C3) =
MWAIT(C7S)
After this change coreboot wouldn't generate _CST tables for ACPI C-states.
Original BIOSes of two Haswell motherboards that I have, don’t generate _CST
tables, so maybe it is not so bad.
But I don’t quite understand why even without those tables "cpupower idle-info"
and "cpupower monitor -m Idle_Stats" shows that CPU enters and exits all
supported C-states. Btw, Haswell ULT has a lot of C-states: C0, C1, C1E, C2E,
C3, C6, C7, C8, C9, C10.
There are a lot of MSRs to control C-states + two alternative interfaces in
ACPI (_CST and FADT), so it is quite hard for me to check if all of it is done
correctly.
State C3 and lower flush core caches, so maybe this is the reason why commit
about EHCI command solves my issue.
Also I've found interesting part in Haswell BWG:
"
Idle Duration Reporting is the capability for devices to communicate to the
processor
about their planned period of activity or idleness. Based on when the device
would next
interrupt the core, the PCU can place the core in an appropriate idle state.
• On 4th Generation Intel® Core™ processors, cores are expected to report their
Idle
Duration time via the respective APIC timers. Since 4th Generation Intel® Core™
processors support Always running APIC timer (ARAT), the PCU will save this data
when cores are in a deep sleep state and use the closest expiring timer value
as the
Device Idle duration.
"
So, maybe without APIC-timer cores can't report their activity/idleness time
and C-states are not supported?? That is why boot with "noapictimer" doesn't
have problems.
Or maybe all problems are from wrong APIC timer. What do you think? What part
of ACPI code is responsible for APIC timer setting?
One more interesting observation:
"
On previous processors, the chipset was responsible for actually changing the
processor C-state seen by the package. On 4th Generation Intel® Core™
processors,
this logic moves to the System Agent, and the chipset is no longer responsible
for
driving processor package C-state transitions.
"
Can it be that mrc.bin (System Agent blob) just doesn't configured for C-states?
And at the end I want to notice, that according to BWG BIOS should expose
different C-states tables to different OSes by reading _PDC method and coreboot
doesn't do it at all.
P.S.: This issue was also responsible for USB stuck in Windows 7. So this
problem is seems more important than support of some old Linux kernels.
From: Аладышев Константин [mailto:aladys...@nicevt.ru]
Sent: Thursday, October 19, 2017 5:57 PM
To: 'ron minnich'; 'Julius Werner'
Cc: 'Coreboot'
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
No, unfortunately this option by itself doesn’t help.
I guess my minimal hammer is ‘noapictimer’
But I wonder how these 3 boot parameters (‘noapictimer’ ‘nolapic’ and
‘acpi=off’) separately help to solve my issue.
What part is wrong in ACPI and correct in MP-table? Maybe the problem is in
ACPI MADT table? But it doesn’t really have much info that can be wrong. The
one strangeness I found compared to original BIOS is mapping between ProcID and
APIC ID in lapic entries.
Coreboot has straightforward: 0-0, 1-1, 2-2, 3-3.
But original BIOS has: 1-0, 2-2, 3-1, 4-3
I wonder if it means something?
From: ron minnich [mailto:rminn...@gmail.com]
Sent: Thursday, October 19, 2017 5:29 PM
To: Аладышев Константин; Julius Werner
Cc: Coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
we had a similar problem and we set
pci=nocrs
which means 'ignore what ACPI tells you and probe it again"
It's much less of a big hammer than 'acpi=off' :-)
On Thu, Oct 19, 2017 at 7:22 AM Аладышев Константин <aladys...@nicevt.ru> wrote:
I've found one more parameter that helps me boot without USB problem:
'noapictimer'
-----Original Message-----
From: Аладышев Константин [mailto:aladys...@nicevt.ru]
Sent: Wednesday, October 18, 2017 3:58 PM
To: 'Julius Werner'
Cc: 'Coreboot'
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
Ok, I've done some investigations about what can be the source of my problem:
1) last value of COMMAND register from BIOS I've dumped all EHCI registers (pci
and memory) at the beginning of linux kernel EHCI initialization. And to my
surprise pretty all memory registers in original BIOS look like almost
uninitialized compared to my coreboot+seabios image. I don't really know how to
work with EHCI controller, but seabios do it through periodic and async
schedule and their enable bits (in COMMAND register from commit!) aren't active
in original BIOS. I've tried to disable ehci initialization in seabios and
after that registers dump started to look almost the same, compared to original
bios, but it didn't solve my issue. Also without them USB doesn't work in grub.
So it doesn't seem like BIOS last value of COMMAND register really matter.
2) SMI
There are special registers for EHCI controller SMIs in its pci config space:
-USB EHCI Legacy Support Extended
-Intel Specific USB 2.0 SMI
But in both of them SMIs are disabled as in coreboot+seabios image as in
original bios.
3) ACPI
In original BIOS ACPI doesn't do anything to EHCI COMMAND register from commit.
It doesn't have a name for it or declare it in some region. Anyway I've copied
almost all asl EHCI controller code, but it didn't help.
BUT! I've provided MP-table and PIRQ table to coreboot and I can say that the
problem disappears when I boot with 'acpi=off' parameter!
Also it disappears when I boot with 'nolapic' parameter
What do they have in common??
-----Original Message-----
From: jwer...@google.com [mailto:jwer...@google.com] On Behalf Of Julius Werner
Sent: Tuesday, October 10, 2017 5:56 AM
To: Аладышев Константин
Cc: Coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface with bios for me. So how does original IBASE/DFI bios can
> overcome code error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise based on result that I've got?
My gut feeling would be to blame ACPI. The Linux patch is about caching a host
controller register in the kernel, and in some cases (e.g. ehci_reset()), the
patch re-reads the cached version from the hardware whereas the previous code
didn't. If some BIOS ACPI mucks with that register, it's possible that this got
the kernel's cached copy out of sync before this patch, but with the patch the
kernel will re-read it from the hardware at the right time. Maybe only
coreboot's ACPI routines touch the register in that path, or maybe the vendor
BIOS' routines were more careful to restore the original state afterwards.
Besides ACPI this could also be in SMM code, I guess (especially if the problem
occurs around system suspend/resume, although it sounds like it doesn't for
you).
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
