[Devel] Re: Question about ACPICA, QNX and making beeps

[Devel] Re: Question about ACPICA, QNX and making beeps

[Rudolf Marek]

[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]

On 30. 09. 21 15:53, Devin Steffler wrote:
> Hello,
> 
> Will Miles suggested that I monitor AcpiOsRead* and AcpiOsWrite* calls. I observed the following:
> ./test_sound # it plays fine
> ./acpica
> AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> AcpiOsWritePort: write 0xa0 to 0xb2 with width 8

This is likely the SMI_CMD and ACPI_ENABLE see my other mail.

> AcpiOsReadPort: read 0x1 from 0x1804 with width 16
> ./test_sound # it stops working
> 
> To check if that write to 0xb2 is related, I modified AcpiOsWritePort to return AE_OK on all writes to Address 0xb2 without doing the actual write. I also modified AcpiOsReadPort to do a "fake read" of 1 when reading from port 0x1804 if there was a previous write to 0xb2. When I do this, then the beep continues to work and reading battery information via ACPI also continues to work (at least on this laptop, I haven't tested other devices yet).

Try vice versa, do not enable/use the ACPICA at all and write 0xa0 to 0xb2 to see if it breaks it.

> Looking at the PCH datasheet for the Intel i5 11357G CPU (what I'm using at the moment), it looks like writing to 0xb2 will trigger an SMI and set "APMC_EN =1" and is reported via APM_STS. Does this mean that it's supposed to activate power management and enable SMI interrupts for BIOS controlled power management (i.e. to be executed by ACPICA via SMI interrupt handlers)? 

It tells BIOS, hey I'm ACPI aware OS stop messing around. And basically BIOS runs some unknown code in SMM when you just write to 0xb2 the 0xA0 command.
This unknown code can possibly enable the 8254 clock gating.

>I'm not sure why that would break the PC speaker. Could it be that my OSL interrupt handling is broken and BIOS was relying on it to re-enable the devices needed to use the PC speaker?

The PC speaker does not do anything with IRQs. The PIT has no architecturally defined way to be disabled. I don't know what Intel smokes but lets not inhale, intel invented the clock gating to make programers life more miserable (problem for TSC/lapic clock calibration when you have no HPET)

> Or could APMC_EN=1 also "turn off some devices (that the PC speaker requires) to save power as they won't be used by this OS"? Should I instead be looking at the ACPI tables for this laptop to see if something is being turned off to save power and figure out how to turn them back on via ACPI calls?

This is likely not the problem. The ACPI tables do not instruct the hardware, because you commented out above write. Also most hardware for chipset is memory mapped, not IOport mapped. Try what I wrote above. If it breaks, it confirms that BIOS is doing something behind the scene which is not even ACPICA related.

> The same section (22.4.5 SMI#/SCI Generation) in the datasheet also states things like the following:
> "The SCI is a level-mode interrupt that is typically handled by an ACPI-aware operating
> system. In non-APIC systems (which is the default), the SCI IRQ is routed to one of
> the 8259 interrupts (IRQ 9, 10, or 11). The 8259 interrupt controller must be
> programmed to level mode for that interrupt."

I don't think it is problem with SCI. See above.

The 8254 clock gating will slow down the PIT frequency 16x and it will stop legacy IRQ 0  (on PIC/IOAPIC) generation as a symptom of clock gating. This is not documented but it behaves like that. Yes again intel did not stop the counter completely to detect it but slowed down. Sigh.

Maybe it also affects PC speaker that it generates waveforms too slowly. You can also try to search BIOS option in setup menu for clock gating or try to disable C11 power state in there.

Yes it is mess.

Thanks,
Rudolf

[Devel] Re: Question about ACPICA, QNX and making beeps

[Rudolf Marek]

[-- Attachment #1: Type: text/plain, Size: 6205 bytes --]

Hi Devin,

On 01. 10. 21 21:08, Devin Steffler wrote:
> Hi Rudolf,
> 
> 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 Intel:
> Datasheet: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-2.pdf <https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-2.pdf>
> -------------------------------------------------
> 30.2.20 ITSS Power Reduction Control (ITSSPRC)—Offset 3300h
> Power controls for the entire interrupt and timer subsystem.
> Bit 2:
> "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 yourself.

Do you have schematics of that system to check what the beeping output from the chipset really does?

Thanks,
Rudolf

[Devel] Re: Question about ACPICA, QNX and making beeps

[Devin Steffler]

[-- Attachment #1: Type: text/plain, Size: 6924 bytes --]

Hi Rudolf,

You're correct. Simply writing 0xa0 to 0xb2 will cause this.

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.

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.

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.

Unfortunately, I don't see any option in the BIOS relating to clock gating
or C11 power states.

Should I pursue allowing the write but then disable the clock gating
separately? I'm not sure how to do that yet.

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 Intel:
Datasheet:
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-2.pdf
-------------------------------------------------
30.2.20 ITSS Power Reduction Control (ITSSPRC)—Offset 3300h
Power controls for the entire interrupt and timer subsystem.
Bit 2:
"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."
-------------------------------------------------

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

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". Either that, or just
block 0xa0 writes to 0xb2 (but that feels like the wrong approach).

Thanks,
Devin



On Thu, Sep 30, 2021 at 1:12 PM Rudolf Marek <r.marek(a)assembler.cz> wrote:

> On 30. 09. 21 15:53, Devin Steffler wrote:
> > Hello,
> >
> > Will Miles suggested that I monitor AcpiOsRead* and AcpiOsWrite* calls.
> I observed the following:
> > ./test_sound # it plays fine
> > ./acpica
> > AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> > AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> > AcpiOsWritePort: write 0xa0 to 0xb2 with width 8
>
> This is likely the SMI_CMD and ACPI_ENABLE see my other mail.
>
> > AcpiOsReadPort: read 0x1 from 0x1804 with width 16
> > ./test_sound # it stops working
> >
> > To check if that write to 0xb2 is related, I modified AcpiOsWritePort to
> return AE_OK on all writes to Address 0xb2 without doing the actual write.
> I also modified AcpiOsReadPort to do a "fake read" of 1 when reading from
> port 0x1804 if there was a previous write to 0xb2. When I do this, then the
> beep continues to work and reading battery information via ACPI also
> continues to work (at least on this laptop, I haven't tested other devices
> yet).
>
> Try vice versa, do not enable/use the ACPICA at all and write 0xa0 to 0xb2
> to see if it breaks it.
>
> > Looking at the PCH datasheet for the Intel i5 11357G CPU (what I'm using
> at the moment), it looks like writing to 0xb2 will trigger an SMI and set
> "APMC_EN =1" and is reported via APM_STS. Does this mean that it's supposed
> to activate power management and enable SMI interrupts for BIOS controlled
> power management (i.e. to be executed by ACPICA via SMI interrupt
> handlers)?
>
> It tells BIOS, hey I'm ACPI aware OS stop messing around. And basically
> BIOS runs some unknown code in SMM when you just write to 0xb2 the 0xA0
> command.
> This unknown code can possibly enable the 8254 clock gating.
>
> >I'm not sure why that would break the PC speaker. Could it be that my OSL
> interrupt handling is broken and BIOS was relying on it to re-enable the
> devices needed to use the PC speaker?
>
> The PC speaker does not do anything with IRQs. The PIT has no
> architecturally defined way to be disabled. I don't know what Intel smokes
> but lets not inhale, intel invented the clock gating to make programers
> life more miserable (problem for TSC/lapic clock calibration when you have
> no HPET)
>
> > Or could APMC_EN=1 also "turn off some devices (that the PC speaker
> requires) to save power as they won't be used by this OS"? Should I instead
> be looking at the ACPI tables for this laptop to see if something is being
> turned off to save power and figure out how to turn them back on via ACPI
> calls?
>
> This is likely not the problem. The ACPI tables do not instruct the
> hardware, because you commented out above write. Also most hardware for
> chipset is memory mapped, not IOport mapped. Try what I wrote above. If it
> breaks, it confirms that BIOS is doing something behind the scene which is
> not even ACPICA related.
>
> > The same section (22.4.5 SMI#/SCI Generation) in the datasheet also
> states things like the following:
> > "The SCI is a level-mode interrupt that is typically handled by an
> ACPI-aware operating
> > system. In non-APIC systems (which is the default), the SCI IRQ is
> routed to one of
> > the 8259 interrupts (IRQ 9, 10, or 11). The 8259 interrupt controller
> must be
> > programmed to level mode for that interrupt."
>
> I don't think it is problem with SCI. See above.
>
> The 8254 clock gating will slow down the PIT frequency 16x and it will
> stop legacy IRQ 0  (on PIC/IOAPIC) generation as a symptom of clock gating.
> This is not documented but it behaves like that. Yes again intel did not
> stop the counter completely to detect it but slowed down. Sigh.
>
> Maybe it also affects PC speaker that it generates waveforms too slowly.
> You can also try to search BIOS option in setup menu for clock gating or
> try to disable C11 power state in there.
>
> Yes it is mess.
>
> Thanks,
> Rudolf
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 7949 bytes --]

[Devel] Re: Question about ACPICA, QNX and making beeps

[Rudolf Marek]

[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]

Hi Devin,

On 30. 09. 21 14:56, Devin Steffler wrote:
> Hi Rudolf,
> 
> I have the ACPI utilities working in QNX as well (i.e. acpidump, acpixtract, iasl, etc). The problem is I don't know what to look for in the FADT.

You need to look for SMI_CMD (likely ioport 0xb2) and ACPI_ENABLE fields.

> So far I have only seen this happen on Lenovo based x86 PCs. For example, the one that I have on hand is a Lenovo ThinkBook 14 Gen 2 laptop. If I boot the ThinkBook into QNX, then I can play a beep over the PC speaker just fine. However, after running ACPICA, then I can no longer play a beep over the PC speaker anymore on this device.

So Intels?

> How can I check for 8254 clock gating?

In the datasheet of Intel, search the southbridge for "8254" + look for some "gating" around. It is quite badly documented and sometimes under NDA only.

Thanks,
Rudolf


> delay is a QNX call to sleep for the specified time in ms.
> 
> Thanks,
> Devin
> 
> On Wed, Sep 29, 2021 at 3:58 PM Rudolf Marek <r.marek(a)assembler.cz <mailto:r.marek(a)assembler.cz>> wrote:
> 
>     Hi Devin,
> 
>     Dne 28. 09. 21 v 21:04 Devin Steffler napsal(a):
>>     Hello, I am using ACPICA to read battery information in QNX. That part is working great so far. However, now some code that is being used to make beeps via the PC speaker stopped working. Strangely, this code stops working on a few devices only after ACPICA runs.
> 
>     You mean same device with same mainboard / BIOS version?
> 
>     Maybe SMI and/or ACPI bytecode turns on 8254 clock gating? You can
> 
>     try to disassemble the ACPI DSDT/SSDT bytecode and look for it.
> 
>     What you can also do, is to try out to send ACPI enable SMI command without
> 
>     enabling ACPICA and see if it breaks. You can read the I/O port address
> 
>     and data enable command from FADT. To disassemble the ACPI tables
> 
>     use acpidump acpixtract and iasl utillites in linux.
> 
>>     What could my ACPICA be doing (or failing to do) that could cause the beeps to stop working with the code below? Is the PIT being disabled somehow? I guess I'll need to learn more about the PIT and how to check its status to see if it's being disabled after ACPICA runs. Here's example code for QNX to generate a beep using the PC speaker: // ----------------------------------------------- #include <sys/neutrino.h> #include <hw/inout.h> #include <unistd.h> int main(void) { ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions // start a beep int freq = 1000; int scale = 1193046 / freq; out8(0x43, 0xb6); out8(0x42, scale & 0xff); out8(0x42, scale >> 8); out8(0x61, in8(0x61) | 3);
> 
>     you can also try to see if your assembly for out8 is correct and maybe not re-ordered
> 
>     by the compiler or that your asm clobber list is correct (same for in8)
> 
>>     // let the beep play for a second delay(1000);
> 
>     delay is an OS service right?
> 
>     Thanks,
> 
>     Rudolf
> 

[Devel] Re: Question about ACPICA, QNX and making beeps

[Devin Steffler]

[-- Attachment #1: Type: text/plain, Size: 4207 bytes --]

Hello,

Will Miles suggested that I monitor AcpiOsRead* and AcpiOsWrite* calls. I
observed the following:
./test_sound # it plays fine
./acpica
AcpiOsReadPort: read 0x0 from 0x1804 with width 16
AcpiOsReadPort: read 0x0 from 0x1804 with width 16
AcpiOsWritePort: write 0xa0 to 0xb2 with width 8
AcpiOsReadPort: read 0x1 from 0x1804 with width 16
./test_sound # it stops working

To check if that write to 0xb2 is related, I modified AcpiOsWritePort to
return AE_OK on all writes to Address 0xb2 without doing the actual write.
I also modified AcpiOsReadPort to do a "fake read" of 1 when reading from
port 0x1804 if there was a previous write to 0xb2. When I do this, then the
beep continues to work and reading battery information via ACPI also
continues to work (at least on this laptop, I haven't tested other devices
yet).

I'm not really sure where to go from here. For this laptop, this might be a
suitable workaround for me as I'm only using ACPICA at the moment to read
battery information and for system shutdown. However, this might not be an
acceptable workaround for other devices (or if I end up needing other ACPI
functionality in the future that depends on this). I also suspect that my
OSL might be missing something that is causing this.

Looking at the PCH datasheet for the Intel i5 11357G CPU (what I'm using at
the moment), it looks like writing to 0xb2 will trigger an SMI and set
"APMC_EN =1" and is reported via APM_STS. Does this mean that it's supposed
to activate power management and enable SMI interrupts for BIOS controlled
power management (i.e. to be executed by ACPICA via SMI interrupt
handlers)? I'm not sure why that would break the PC speaker. Could it be
that my OSL interrupt handling is broken and BIOS was relying on it to
re-enable the devices needed to use the PC speaker?

Or could APMC_EN=1 also "turn off some devices (that the PC speaker
requires) to save power as they won't be used by this OS"? Should I instead
be looking at the ACPI tables for this laptop to see if something is being
turned off to save power and figure out how to turn them back on via ACPI
calls?

The same section (22.4.5 SMI#/SCI Generation) in the datasheet also states
things like the following:
"The SCI is a level-mode interrupt that is typically handled by an
ACPI-aware operating
system. In non-APIC systems (which is the default), the SCI IRQ is routed
to one of
the 8259 interrupts (IRQ 9, 10, or 11). The 8259 interrupt controller must
be
programmed to level mode for that interrupt."

Thanks,
Devin

On Tue, Sep 28, 2021 at 3:04 PM Devin Steffler <devinsteffler(a)gmail.com>
wrote:

> Hello,
>
> I am using ACPICA to read battery information in QNX. That part is working
> great so far. However, now some code that is being used to make beeps via
> the PC speaker stopped working.
>
> Strangely, this code stops working on a few devices only after ACPICA
> runs. It works fine if I don't start ACPICA. The code is using I/O ports
> 0x43, 0x42, and 0x61 to generate beeps. This seems to be an industry
> standard way to make beeps on x86 based PCs using a Programmable Interval
> Timer (PIT).
>
> What could my ACPICA be doing (or failing to do) that could cause the
> beeps to stop working with the code below? Is the PIT being disabled
> somehow? I guess I'll need to learn more about the PIT and how to check its
> status to see if it's being disabled after ACPICA runs.
>
> Here's example code for QNX to generate a beep using the PC speaker:
> // -----------------------------------------------
> #include <sys/neutrino.h>
> #include <hw/inout.h>
> #include <unistd.h>
>
> int main(void) {
>     ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions
>
>     // start a beep
>     int freq = 1000;
>     int scale = 1193046 / freq;
>     out8(0x43, 0xb6);
>     out8(0x42, scale & 0xff);
>     out8(0x42, scale >> 8);
>     out8(0x61, in8(0x61) | 3);
>
>     // let the beep play for a second
>     delay(1000);
>
>     // stop the beep
>     out8(0x61, in8(0x61) & ~3);
>
>     return 0;
> }
> // -----------------------------------------------
>
> Thanks,
> Devin
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 5089 bytes --]

[Devel] Re: Question about ACPICA, QNX and making beeps

[Devin Steffler]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

Hi Rudolf,

I have the ACPI utilities working in QNX as well (i.e. acpidump,
acpixtract, iasl, etc). The problem is I don't know what to look for in the
FADT.

So far I have only seen this happen on Lenovo based x86 PCs. For example,
the one that I have on hand is a Lenovo ThinkBook 14 Gen 2 laptop. If I
boot the ThinkBook into QNX, then I can play a beep over the PC speaker
just fine. However, after running ACPICA, then I can no longer play a beep
over the PC speaker anymore on this device.

How can I check for 8254 clock gating?

delay is a QNX call to sleep for the specified time in ms.

Thanks,
Devin

On Wed, Sep 29, 2021 at 3:58 PM Rudolf Marek <r.marek(a)assembler.cz> wrote:

> Hi Devin,
>
> Dne 28. 09. 21 v 21:04 Devin Steffler napsal(a):
>
> Hello,
>
> I am using ACPICA to read battery information in QNX. That part is working
> great so far. However, now some code that is being used to make beeps via
> the PC speaker stopped working.
>
> Strangely, this code stops working on a few devices only after ACPICA runs.
>
> You mean same device with same mainboard / BIOS version?
>
> Maybe SMI and/or ACPI bytecode turns on 8254 clock gating? You can
>
> try to disassemble the ACPI DSDT/SSDT bytecode and look for it.
>
> What you can also do, is to try out to send ACPI enable SMI command without
>
> enabling ACPICA and see if it breaks. You can read the I/O port address
>
> and data enable command from FADT. To disassemble the ACPI tables
>
> use acpidump acpixtract and iasl utillites in linux.
>
> What could my ACPICA be doing (or failing to do) that could cause the beeps
> to stop working with the code below? Is the PIT being disabled somehow? I
> guess I'll need to learn more about the PIT and how to check its status to
> see if it's being disabled after ACPICA runs.
>
> Here's example code for QNX to generate a beep using the PC speaker:
> // -----------------------------------------------
> #include <sys/neutrino.h>
> #include <hw/inout.h>
> #include <unistd.h>
>
> int main(void) {
>     ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions
>
>     // start a beep
>     int freq = 1000;
>     int scale = 1193046 / freq;
>     out8(0x43, 0xb6);
>     out8(0x42, scale & 0xff);
>     out8(0x42, scale >> 8);
>     out8(0x61, in8(0x61) | 3);
>
> you can also try to see if your assembly for out8 is correct and maybe not
> re-ordered
>
> by the compiler or that your asm clobber list is correct (same for in8)
>
>
>     // let the beep play for a second
>     delay(1000);
>
> delay is an OS service right?
>
> Thanks,
>
> Rudolf
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3791 bytes --]

[Devel] Re: Question about ACPICA, QNX and making beeps

[Rudolf Marek]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

Hi Devin,

Dne 28. 09. 21 v 21:04 Devin Steffler napsal(a):
> Hello, I am using ACPICA to read battery information in QNX. That part is 
> working great so far. However, now some code that is being used to make beeps 
> via the PC speaker stopped working. Strangely, this code stops working on a 
> few devices only after ACPICA runs.

You mean same device with same mainboard / BIOS version?

Maybe SMI and/or ACPI bytecode turns on 8254 clock gating? You can

try to disassemble the ACPI DSDT/SSDT bytecode and look for it.

What you can also do, is to try out to send ACPI enable SMI command without

enabling ACPICA and see if it breaks. You can read the I/O port address

and data enable command from FADT. To disassemble the ACPI tables

use acpidump acpixtract and iasl utillites in linux.

> What could my ACPICA be doing (or failing to do) that could cause the beeps to 
> stop working with the code below? Is the PIT being disabled somehow? I guess 
> I'll need to learn more about the PIT and how to check its status to see if 
> it's being disabled after ACPICA runs. Here's example code for QNX to generate 
> a beep using the PC speaker: // 
> ----------------------------------------------- #include <sys/neutrino.h> 
> #include <hw/inout.h> #include <unistd.h> int main(void) { ThreadCtl( 
> _NTO_TCTL_IO, 0 ); // get I/O permissions // start a beep int freq = 1000; int 
> scale = 1193046 / freq; out8(0x43, 0xb6); out8(0x42, scale & 0xff); out8(0x42, 
> scale >> 8); out8(0x61, in8(0x61) | 3);

you can also try to see if your assembly for out8 is correct and maybe not 
re-ordered

by the compiler or that your asm clobber list is correct (same for in8)

> // let the beep play for a second delay(1000);

delay is an OS service right?

Thanks,

Rudolf


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3117 bytes --]

[Devel] Re: Question about ACPICA, QNX and making beeps

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

Sorry, I have no idea why this would stop working.
Bob


From: Devin Steffler <devinsteffler(a)gmail.com>
Sent: Tuesday, September 28, 2021 12:04 PM
To: devel(a)acpica.org
Subject: [Devel] Question about ACPICA, QNX and making beeps

Hello,

I am using ACPICA to read battery information in QNX. That part is working great so far. However, now some code that is being used to make beeps via the PC speaker stopped working.

Strangely, this code stops working on a few devices only after ACPICA runs. It works fine if I don't start ACPICA. The code is using I/O ports 0x43, 0x42, and 0x61 to generate beeps. This seems to be an industry standard way to make beeps on x86 based PCs using a Programmable Interval Timer (PIT).

What could my ACPICA be doing (or failing to do) that could cause the beeps to stop working with the code below? Is the PIT being disabled somehow? I guess I'll need to learn more about the PIT and how to check its status to see if it's being disabled after ACPICA runs.

Here's example code for QNX to generate a beep using the PC speaker:
// -----------------------------------------------
#include <sys/neutrino.h>
#include <hw/inout.h>
#include <unistd.h>

int main(void) {
    ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions

    // start a beep
    int freq = 1000;
    int scale = 1193046 / freq;
    out8(0x43, 0xb6);
    out8(0x42, scale & 0xff);
    out8(0x42, scale >> 8);
    out8(0x61, in8(0x61) | 3);

    // let the beep play for a second
    delay(1000);

    // stop the beep
    out8(0x61, in8(0x61) & ~3);

    return 0;
}
// -----------------------------------------------

Thanks,
Devin

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4988 bytes --]