Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)

[daniel_k]

34 minutes ago, Mov AX, 0xDEAD said:

@daniel_k

no BSOD description/log - no workaround

Will take note of it.
 

Quote

port 60 emulation is bios SMM hack, i think problem in bios code

Yes, probably a bug, because the DSDT table looks about the same on my Gigabyte Z370 and doesn't crash XP with that emulation enabled.
Luckily it can be disabled.

[daniel_k]

33 minutes ago, Mov AX, 0xDEAD said:

C3 is ACPI hardware, as i remember anything after 110 chipset has disabled acpi's power-saving part

Hmm, probably is not disabled, C3 works properly on Vista.

[Damnation]

@Dietmar

maybe try this?

        if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) {
	            //
            // It's a PCI PDO, which means a root PCI bus,
            // which means that we should just handle this
            // as an ISA device.
            //
	            return STATUS_NOT_FOUND;
        }
        elseif (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_ISA) {
	            //
	            return STATUS_NOT_FOUND;
        }
	

Edited April 11, 2022 by Damnation

[Dietmar]

On the AMD board AB350 gaming k4 I have soldered by myself a socket for its Bios chip.

So there I can easy change DSDT with EEpromer entry for GPIO to

                        

 If ((OSYS >= 0x07D6))
                {
                   
                }

Dietmar

PS: Also possible to do add something like "GPIO is not under usual _SB.PCI0. path - i think this is problem".

But then GPIO becomes forced a PCI device and "ISA" mode is gone?

Edited April 11, 2022 by Dietmar

[Dietmar]

@Damnation

I think this is the right idea to keep the "ISA" device mode.

It is also possible, that it is just an mistake in DSDT for GPIO.

But because it is very close to hardware the idea with "ISA" should be kept

Dietmar

[daniel_k]

@Dietmar

See if any of your AMD or Intel boards/notebooks have a GPIO controller and don't crash XP.
Check the DSDT table and see where the GPIO is located (inside or outside the PCI0 scope).

Edited April 11, 2022 by daniel_k

[Dietmar]

        Device (GPIO)
        {
            Name (_HID, "AMDI0030")  // _HID: Hardware ID
            Name (_CID, "AMDI0030")  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
              Here is Level ActiveLow ===>>  Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }
                    Memory32Fixed (ReadWrite,
                        0xFED81500,         // Address Base
                        0x00000400,         // Address Length
                        )
                })
                Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((TSOS >= 0x70))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }

@daniel_k

This is from DSDT of the AMD AB350 k4, crashes

Dietmar

Edited April 11, 2022 by Dietmar

[Dietmar]

@daniel_k

No crash from Intel board z370 gaming k6.

No Device (GPIO) in DSDT at all

Dietmar

[daniel_k]

@Dietmar

That GPIO code from AMD AB350 k4, is it inside _SB.PCI0?

AMD boards usually expose the GPIO controller, Intel either hides or disables it.
Notebooks are a different story, though.

[Dietmar]

   @daniel_k

Scope (_SB)
    {

...

Device (GPIO)

[Dietmar]

GPIO Interfaces
===============

The documents in this directory give detailed instructions on how to access
GPIOs in drivers, and how to write a driver for a device that provides GPIOs
itself.

Due to the history of GPIO interfaces in the kernel, there are two different
ways to obtain and use GPIOs:

  - The descriptor-based interface is the preferred way to manipulate GPIOs,
and is described by all the files in this directory excepted gpio-legacy.txt.
  - The legacy integer-based interface which is considered deprecated (but still
usable for compatibility reasons) is documented in gpio-legacy.txt.

The remainder of this document applies to the new descriptor-based interface.
gpio-legacy.txt contains the same information applied to the legacy
integer-based interface.


What is a GPIO?
===============

A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
digital signal. They are provided from many kinds of chip, and are familiar
to Linux developers working with embedded and custom hardware. Each GPIO
represents a bit connected to a particular pin, or "ball" on Ball Grid Array
(BGA) packages. Board schematics show which external hardware connects to
which GPIOs. Drivers can be written generically, so that board setup code
passes such pin configuration data to drivers.

System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
non-dedicated pin can be configured as a GPIO; and most chips have at least
several dozen of them. Programmable logic devices (like FPGAs) can easily
provide GPIOs; multifunction chips like power managers, and audio codecs
often have a few such pins to help with pin scarcity on SOCs; and there are
also "GPIO Expander" chips that connect using the I2C or SPI serial buses.
Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
firmware knowing how they're used).

The exact capabilities of GPIOs vary between systems. Common options:

  - Output values are writable (high=1, low=0). Some chips also have
    options about how that value is driven, so that for example only one
    value might be driven, supporting "wire-OR" and similar schemes for the
    other value (notably, "open drain" signaling).

  - Input values are likewise readable (1, 0). Some chips support readback
    of pins configured as "output", which is very useful in such "wire-OR"
    cases (to support bidirectional signaling). GPIO controllers may have
    input de-glitch/debounce logic, sometimes with software controls.

  - Inputs can often be used as IRQ signals, often edge triggered but
    sometimes level triggered. Such IRQs may be configurable as system
    wakeup events, to wake the system from a low power state.

  - Usually a GPIO will be configurable as either input or output, as needed
    by different product boards; single direction ones exist too.

  - Most GPIOs can be accessed while holding spinlocks, but those accessed
    through a serial bus normally can't. Some systems support both types.

On a given board each GPIO is used for one specific purpose like monitoring
MMC/SD card insertion/removal, detecting card write-protect status, driving
a LED, configuring a transceiver, bit-banging a serial bus, poking a hardware
watchdog, sensing a switch, and so on.


Common GPIO Properties
======================

These properties are met through all the other documents of the GPIO interface
and it is useful to understand them, especially if you need to define GPIO
mappings.

Active-High and Active-Low
--------------------------
It is natural to assume that a GPIO is "active" when its output signal is 1
("high"), and inactive when it is 0 ("low"). However in practice the signal of a
GPIO may be inverted before is reaches its destination, or a device could decide
to have different conventions about what "active" means. Such decisions should
be transparent to device drivers, therefore it is possible to define a GPIO as
being either active-high ("1" means "active", the default) or active-low ("0"
means "active") so that drivers only need to worry about the logical signal and
not about what happens at the line level.

Open Drain and Open Source
--------------------------
Sometimes shared signals need to use "open drain" (where only the low signal
level is actually driven), or "open source" (where only the high signal level is
driven) signaling. That term applies to CMOS transistors; "open collector" is
used for TTL. A pullup or pulldown resistor causes the high or low signal level.
This is sometimes called a "wire-AND"; or more practically, from the negative
logic (low=true) perspective this is a "wire-OR".

One common example of an open drain signal is a shared active-low IRQ line.
Also, bidirectional data bus signals sometimes use open drain signals.

Some GPIO controllers directly support open drain and open source outputs; many
don't. When you need open drain signaling but your hardware doesn't directly
support it, there's a common idiom you can use to emulate it with any GPIO pin
that can be used as either an input or an output:

 LOW:	gpiod_direction_output(gpio, 0) ... this drives the signal and overrides
	the pullup.

 HIGH:	gpiod_direction_input(gpio) ... this turns off the output, so the pullup
	(or some other device) controls the signal.

The same logic can be applied to emulate open source signaling, by driving the
high signal and configuring the GPIO as input for low. This open drain/open
source emulation can be handled transparently by the GPIO framework.

If you are "driving" the signal high but gpiod_get_value(gpio) reports a low
value (after the appropriate rise time passes), you know some other component is
driving the shared signal low. That's not necessarily an error. As one common
example, that's how I2C clocks are stretched:  a slave that needs a slower clock
delays the rising edge of SCK, and the I2C master adjusts its signaling rate
accordingly.

 

[Dietmar]

@daniel_k

And now I remember, that I come to the idea of GPIO and this Bsod also,

because of the changed use in Ryzen cpu of signals for GPIO "Active-High and Active-Low".

And from exact this hardware changes for GPIO came the very big problems for Linux and Ryzen

Dietmar

EDIT: In DSDT table the IRQ is defined as

Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, }

but in dmesg it prints

[ 0.098531] ACPI: IRQ 7 override to edge, high

Edited April 11, 2022 by Dietmar

[Dietmar]

@daniel_k

Fresh from Bios of PRIME X570 PRO ASUS board

crash

Dietmar

Earlier AMD boards do not have this problem. And I think, it is Ryzen related, because this AM4 have GPIO, but only Ryzen crashes, other CPU on the same board not. Maybe, that only Ryzen offers these GPIO connectors

IRQ 7 override to edge, high

 Scope (_SB)
    {

...

Device (GPIO) 

 

 

Edited April 11, 2022 by Dietmar

[Damnation]

@Dietmar

I downloaded the BIOS for the ASRock B550 Steel Legend (board I chose for a build, still waiting for it on backorder)

checked it's DSDT, it also has

	        Device (GPIO)
        {
            Name (_HID, "AMDI0030")  // _HID: Hardware ID
            Name (_CID, "AMDI0030")  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }
                    Memory32Fixed (ReadWrite,
                        0xFED81500,         // Address Base
                        0x00000400,         // Address Length
                        )
                })
                Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
            }
	

I think perhaps all AMD Ryzen boards use this DSDT code.

[daniel_k]

@Dietmar

Please do the following test, without the last ACPI patches (only QwordField fix):
- put Device (GPIO) inside Device (PCI0)
- search for _SB.GPIO and replace it with _SB.PCI0.GPIO

So we will know for sure if the issue is the improper location of the GPIO device or the device itself.

Edited April 11, 2022 by daniel_k