On 01. 10. 21 21:08, Devin Steffler wrote:
You're correct. Simply writing 0xa0 to 0xb2 will cause this.
Great. (or not so).
I'm having a hard time figuring out what 0xb2 is. It seems like
an I/O port that causes an SMI and sets APMC_EN=1. That's all that I could find so
far. I have no idea yet what the bits in 0xa0 do.
This is a software API to perform various functions not by ACPICA bytecode but by the
machine code. It is kind of "backdoor" for BIOS programmers often
misused. It was heavily used during APM era, but remained there. The whole system
managemement mode is another mess. The SMI is more privileged than os,
so it is ring -1 (OS is ring 0). Basically this allows BIOS to do "behind the
scene" operation. 0xA0 is just API, it is invoke command "A0" in BIOS.
And by a convention this command is to instruct BIOS that ACPICA aware OS is being used.
To figure out what is really done, you would need to
1) get support for Mr. Lenovo - but not the ordinary support
2) unpack and disassemble/reverse engineer the BIOS to see what 0xA0 is really doing
Is this telling the BIOS that I have an APM aware OS (not ACPI)? If
that's the case, then I have a feeling that my ACPICA should be instead doing
something to say "I'm not APM aware" so that it doesn't try to do this.
Or is being "APM aware" required for ACPI functionality since it's the
successor to APM? On this system reading battery information works fine without this write
to 0xb2. I would have to test on other devices as well to check if that's always the
case or not.
The A0 command tels the contrary it says to OS, I'm ACPI aware OS. And someone at Mr.
Lenovo probably was clever to realize that they can maybe switch off something
because legacy OS is not in use...
As a side note, in case it's relevant, I am setting the following
in my ACPICA:
#define ACPI_OS_NAME "Microsoft Windows NT"
That was done arbitrarily or perhaps out of laziness/lack of testing support. The comment
above ACPI_OS_NAME suggests that it's obsolete anyways.
Yes there are another horror stories for this. Basically BIOS programmers were testing on
what ACPICA/OS they run with and do different things.Depending
what OS was told.
Unfortunately, I don't see any option in the BIOS relating to
clock gating or C11 power states.
Thats bad. Try some more general power saving options. Does the behavior change if laptop
is plugged to AC?
Should I pursue allowing the write but then disable the clock gating
separately? I'm not sure how to do that yet.
Yes you can try it out. But it is tricky.
I started to learn about clock gating. I wanted to see if I could confirm that clock
gating happens when 0xa0 is written to 0xb2. I stumbled on the following information from
30.2.20 ITSS Power Reduction Control (ITSSPRC)—Offset 3300h
Power controls for the entire interrupt and timer subsystem.
"8254 Static Clock Gating Enable (CGE8254): When set, the 8254 timer is
disabled statically. This bit shall be set by BIOS if the 8254 feature is not needed in
the system or before BIOS hands off the system that supports C11. Normal operation
of 8254 requires this bit to 0."
Yes this is it. Unfortunately the register placement is not stable/same across systems.
Intel tends to put it to various places. So like Apollo lake has it elsewhere etc. You
need to look to a documentation which matches 100% your system. You can try to check this
by comparing the PCI ids of various devices and checking
them against datasheets. You can try to look to coreboot sources or some other opensource
uefi implementation if they have support for your systems to see how the p2sb is done.
Unfortunately, I haven't been able to get access to that bit yet.
The P2SB Bridge is hidden. I've found a way to get the SBREG_BAR from the P2SB Bridge
in the QNX BSP.
Yes. But maybe it is for another chipset. See above.
However, using it to read the ITSSPRC still returns 0xFFFFFFFF. I was
hoping that I could clear that bit if it is getting set to test if that makes the PC
speaker work >again.
Hm 0xffffffff sounds way suspicious. I don't know what other bits do but it looks like
you are looking to wrong place. Possible errors:
1) you did not map correct memory region
2) you did not map it uncached
3) you did not enable decoding of the region (maybe the P2SB has also command register
where you might need to enable BAR decoding)
4) you did not use proper compiler things like "volatile" or compiler barriers
and/or your access has been optimized out by the compiler
5) you did not read the register using correct register length
Part of this is a learning exercise for me, but part of it is also to
get a proper fix for this system. If this is just an "APM thing" that
shouldn't be enabled to begin with on my system, then I guess I need to figure out how
to tell BIOS that this OS is "not APM aware".
The ACPICA does correct thing. See above.
Either that, or just block 0xa0 writes to 0xb2 (but that feels like
the wrong approach).
Yes this is wrong approach, because BIOS will often generate SMIs and SCIs for many
events. I'm afraid you need to do the write to 0xb2.
Giving it more thoughts the clock gating might not be the only or correct problem to
solve. If it is a laptop, I suspect that the legacy speaker
goes to sound codec somehow and then to laptop speakers, and maybe BIOS switches off the
sound codec (like puts it to D3 sleep).
I don't know how the sound codec routing is usually done. You need to check it
Do you have schematics of that system to check what the beeping output from the chipset