Case value already specified dsdt как исправить ошибку

Do you expect that the audio passthrough issues on Intel (e.g. NUC11PAHi)

The audio passthrough issue has been reported to Intel driver people but no one’s in a hurry to fix it.

May I ask you which machine you own yourself or plan to purchase?

I own an Asrock J4105B-ITX (Gemini Lake) board. I plan to upgrade it at some point to a Tiger Lake based mini-ITX board (most likely Celeron 6305 or Pentium Gold 7505) when they are available.

Current work-in-progress HDR code from lrusak’s git repo (which I use for my LE builds) does not work on AMD. No idea when or if it will ever work.

But the biggest concern should be AMD’s linux GPU driver quality, which is kinda crap. I encountered some nasty issues when testing LE on Athlon 200GE APU with Vega graphics.

The audio passthrough issues on Intel are nothing compared to general crappiness of AMD drivers.

You are using the wrong branch I’ve used HDR on my AMD vega-m. It’s very much WIP though. AMD drivers also don’t expose the colorimetry property yet so there is no way to flag bt2020 to the monitor (this is apparently going to be implemented this year though).

Also, the AMD drivers (IMO) are some of the best.

Can a machine ever be too fast?

Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.

You are using the wrong branch

I used this one. Is it the right one? HDR worked on Gemini Lake and (reportedly) on Tiger Lake. Didn’t work on Athlon 200GE.

Also, the AMD drivers (IMO) are some of the best.

Ok, but I can make a list of weird issues that are exclusive to AMD and not present on Intel.

Like this issue for example which I reported to AMD almost a year ago and it is still not fixed.

Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.

the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.

Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.

Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC’s like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC’s. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up.

the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.

Agreed. Its old enough that its price is a great value these days compared to newer NUCs. I have a ODROID H2+ which is very similar. I just can’t use it d/t the audio issue for now.

Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC’s like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC’s. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up

I just see a bit more benefit these days upgrading back end hardware (network, NAS etc) rather than trying to load up everything on a front end device, as an example look at how well the Netflix app works on your average Smart TV, there’s not a lot of front end processing power required, because all the heavy lifting is done at the back end.

I still like Kodi, it’s great for what it is don’t get me wrong, but there’s a lot of other UI’s out there that get by just fine on potato SoC’s too, and running x86 as a HTPC has always felt like too much overkill to me.

Well I had some time to work on the PN50 today.
I got stuck trying to setup my ir remote.

ir-keytable returns No devices found

and in dmesg it shows

[ 3.338380] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[ 3.338382] ite_cir: Using model: ITE8708 CIR transceiver
[ 3.338385] ite-cir 00:02: IR PNP Port not valid!

Using LibreELEC (community): nightly-20210313-c5d7822

I know my answer is not what you have asked for: But have you ever considered using a Flirc?

In case you don‘t know what a Flirc is:

A Flirc is a small USB plug which translates signals from any IR remote into keyboard presses. Makes it pretty easy to create a working keyboard.xml and the best is you don‘t have to hassle with ir-keytables.

I have also tried following the same methodology described in
📡 Getting the Fintek IR receiver to work with Linux | @GregNau – Apps and Blog

&

modprobe -r ite-cir
echo "auto" > "/sys/bus/acpi/devices/ITE8708:00/physical_node/resources"
modprobe ite-cir

After this, dmesg output remains the same:

[  997.359200] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[  997.359203] ite_cir: Using model: ITE8708 CIR transceiver
[  997.359207] ite-cir 00:02: IR PNP Port not valid!

ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
Sadly, this mail thread never resolved to something, as far as I can tell. I am not sure, but I think it indicates the cir module in the PN50 is somewhat different than what the driver expects.

2. The /sys/bus/acpi/devices/ITE8708:00/physical_node/resources has the following contents:

state = active
io 0x280-0x28f
irq 10
dma disabled

However, /proc/interrupts doesn’t show IRQ 10 as being used:

pn50:~ # cat /proc/interrupts
            CPU0       CPU1       CPU2       CPU3
   0:         38          0          0          0  IR-IO-APIC    2-edge      timer
   8:          0          0          1          0  IR-IO-APIC    8-edge      rtc0
   9:          0          1          0          0  IR-IO-APIC    9-fasteoi   acpi
  11:          0          0          0          0  IR-IO-APIC   11-edge      AMDI0010:01
  25:          0          0          0          0   PCI-MSI 4096-edge      AMD-Vi
  26:          0          0          0          0  IR-PCI-MSI 20480-edge      PCIe PME
  27:          0          0          0          0  IR-PCI-MSI 34816-edge      PCIe PME
  28:          0          0          0          0  IR-PCI-MSI 36864-edge      PCIe PME

Success

[    4.677490] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[    4.677492] ite_cir: Using model: ITE8708 CIR transceiver
[    4.677492] ite_cir: TX-capable: 1
[    4.677493] ite_cir: Sample period (ns): 8680
[    4.677493] ite_cir: TX carrier frequency (Hz): 38000
[    4.677494] ite_cir: TX duty cycle (%): 33
[    4.677494] ite_cir: RX low carrier frequency (Hz): 0
[    4.677494] ite_cir: RX high carrier frequency (Hz): 0
[    4.758949] rc rc0: lirc_dev: driver ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter
[    4.759098] ite_cir: driver has been successfully loaded

I am attaching the kernel patch I made
linux-9999-pn50.patch.txt

If you’d like to learn sending something upstream I’m always happy to coach on the process — it’s not that hard and we can review to spot the normal ettiquette mistakes before you send the patch. If not, I’d deferr to HiassofT who will understand what the change does — I don’t code

I was thinking of a double approach:

1. Do a pull request on the LibreELEC github, with the above patch, so that it hopefuly becomes a part of the future stable LE 10.0

That way I can soon go back to using nightlies to further test the PN50 (at least until the next beta), instead of having to compile my own builds.

And for 2 I’ll start by dropping an email on the linux-media list

Start with 2, and also send the email to Sean Young (he’s the IR remote maintainer). When he acceptet your patch create a PR for LibreELEC, ideally with a link to the linux media patchwork URL.

so long,

Hias

beredim Your change will fail on any motherboard reporting the correct 8 byte register length.

To implement the discussed fix change ‘!=’ to ‘<‘ in this line.

Yes, I see what you mean.

According to that email thread it’s the motherboard that is reporting the wrong register length of 16 in the ACPI tables

(while the device is still supposed to have an register length of 8 )
So by changing the register length to 16 in the driver, I am borking every other motherboard with correct ACPI tables, and possibly the PN50 in case a BIOS update fixes the value in the future.

I’ll try your approach.

* It’s a mystery to me how this ended up being an issue. It seems ASUS has been using the same ITE8708 since ages ago.

This thread has provided me many ideas on how to tackle my problem with my new PN62S, which appears to be the Intel version of the PN50. Looking for info on the ITE8708 led me here. While I still have not solved my issue yet, in appreciation of the work done so far, I thought I could share some of what I’ve tried/learned over the last week, which may trigger someone else’s solution to their problem.

When I received my PN62S, the first thing I did before I even installed an OS was updated to the latest BIOS. I’m ultimately using this as a MythTV frontend, but started with a 20.04 Xubuntu minimal install to see what worked, and what didn’t. I’ve updated the kernel to a 5.10. IR is one of the reasons I chose this unit. I use FLIRC on my main machine, but for something this tiny, I wanted to try and keep it more elegant. So when it wanted to play rough, I accepted the challenge.

I downloaded and installed Windows 10 on an old drive just to see if things truly worked, and they did. Without installing anything extra, a Microsoft remote «just worked». I confirmed my address space as 8 bytes (0x0680 — 0x0687) and IRQ (10) requirements from this side. Oh, and the Windows driver? From 2006 according to it’s properties! So all of this is pointing me to your length issue as being an ASUS issue. Sure, a patch to ite-cir may work around it, but ultimately I think a BIOS update would be the proper solution (I’ll get to that shortly).

So inspired by your conversation, I thought maybe updating the driver with your corrections might solve my issue. I’ve tried the length correction, the != correction, and both together with no change. Which didn’t entirely surprise me because my problem seems to start at a lower level. The kernel seems to be aware enough that the device exists, but nothing in dmesg even hints at an attempt to load the driver. If I could get as far as your dmesg output, I’m sure the patch would solve my issue.

[email protected]:~$ lsmod | grep cir
ite_cir                28672  0
rc_core                61440  3 ite_cir,cec

[email protected]:~$ sudo ls -l /sys/bus/acpi/devices/ITE8708:00/physical_node/
total 0
-r--r--r-- 1 root root 4096 Apr 28 19:47 ari_enabled
-rw-r--r-- 1 root root 4096 Apr 28 19:47 broken_parity_status
-r--r--r-- 1 root root 4096 Apr 28 19:47 class
-rw-r--r-- 1 root root  256 Apr 28 19:47 config
-r--r--r-- 1 root root 4096 Apr 28 19:47 consistent_dma_mask_bits
-rw-r--r-- 1 root root 4096 Apr 28 19:47 d3cold_allowed
-r--r--r-- 1 root root 4096 Apr 28 19:47 device
-r--r--r-- 1 root root 4096 Apr 28 19:47 dma_mask_bits
lrwxrwxrwx 1 root root    0 Apr 28 19:47 driver -> ../../../bus/pci/drivers/skl_uncore
-rw-r--r-- 1 root root 4096 Apr 28 19:47 driver_override
-rw-r--r-- 1 root root 4096 Apr 28 19:47 enable
lrwxrwxrwx 1 root root    0 Apr 28 19:47 firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ITE8708:00
-r--r--r-- 1 root root 4096 Apr 28 19:47 index
-r--r--r-- 1 root root 4096 Apr 28 19:47 irq
-r--r--r-- 1 root root 4096 Apr 28 19:47 label
drwxr-xr-x 2 root root    0 Apr 28 19:47 link
-r--r--r-- 1 root root 4096 Apr 28 19:47 local_cpulist
-r--r--r-- 1 root root 4096 Apr 28 19:47 local_cpus
-r--r--r-- 1 root root 4096 Apr 28 19:47 modalias
-rw-r--r-- 1 root root 4096 Apr 28 19:47 msi_bus
-rw-r--r-- 1 root root 4096 Apr 28 19:47 numa_node
drwxr-xr-x 2 root root    0 Apr 28 19:47 power
--w--w---- 1 root root 4096 Apr 28 19:47 remove
--w------- 1 root root 4096 Apr 28 19:47 rescan
-r--r--r-- 1 root root 4096 Apr 28 19:47 resource
-r--r--r-- 1 root root 4096 Apr 28 19:47 revision
lrwxrwxrwx 1 root root    0 Apr 28 19:47 subsystem -> ../../../bus/pci
-r--r--r-- 1 root root 4096 Apr 28 19:47 subsystem_device
-r--r--r-- 1 root root 4096 Apr 28 19:47 subsystem_vendor
-rw-r--r-- 1 root root 4096 Apr 28 19:47 uevent
-r--r--r-- 1 root root 4096 Apr 28 19:47 vendor

What became key to me here is that in the relevant /sys/bus/acpi folder for this device is that I have no resources file (resource is something completely different). I also think because the BIOS marks that memory area as motherboard resources, it gets picked up by another driver when ite-cir doesn’t grab it. So the lack of resources led me to investigate ACPI in the BIOS, thinking that it wasn’t providing me the right information.

So lately I’ve been learning about ACPI and more specifically the DSDT table provided in the BIOS. And this is where it might lead to a fix for your length issue. Deep in this table (over 64k lines!), from my BIOS, is the definition for this device. I’d be interested to compare this against the definition in a PN50 ( After this I’m going to download the PN50 and see if there’s anyway I can find the DSDT table in it!)

      Device (CR00)
      {
          Name (_ADR, Zero)  // _ADR: Address
          Name (VBAN, 0x0680)
          Name (VIRQ, 0x0A)
          Name (UIDN, Zero)
          Name (_HID, EisaId ("ITE8708"))  // _HID: Hardware ID
          Method (_UID, 0, NotSerialized)  // _UID: Unique ID
          {
              Return (UIDN) /* _SB_.PCI0.CR00.UIDN */
          }

          Method (_STA, 0, Serialized)  // _STA: Status
          {
              If ((CIRE == Zero))
              {
                  Return (Zero)
              }
              Return (0x0F)
          }

          Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
          {
              Name (BUF0, ResourceTemplate ()
              {
                  IO (Decode16,
                      0x0000,             // Range Minimum
                      0x0000,             // Range Maximum
                      0x01,               // Alignment
                      0x08,               // Length
                      _Y10)
                  IRQNoFlags (_Y11)
                      {}
                  DMA (Compatibility, NotBusMaster, Transfer8, )
                      {}
              })
              CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y10._MIN, IOPL)  // _MIN: Minimum Base Address
              CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y10._MAX, IOPH)  // _MAX: Maximum Base Address
              CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y11._INT, IRQ)  // _INT: Interrupts
              IOPL = VBAN /* _SB_.PCI0.CR00.VBAN */
              IOPH = VBAN /* _SB_.PCI0.CR00.VBAN */
              IRQ = (One << VIRQ) /* _SB_.PCI0.CR00.VIRQ */
              Return (BUF0) /* _SB_.PCI0.CR00._CRS.BUF0 */
          }
      }

My length is defined as 0x08. If you were to check your DSDT table (see below for useful links), would it say that, or would it say 0x10? If this was the case, then I think this should be pointed out somehow to ASUS. An updated BIOS with a fix to this table could make the problem go away if this is the root cause.

Now in addition to finding this info, I’ve also learned that in addition to disassembling this and other ACPI tables, they can be modified and recompiled. Once recompiled, depending on your kernel build (and many may be built for this … mine was, out of the box), the recompiled table can be loaded at boot time to be used instead of the one provided by the BIOS. It can be built into the kernel too apparently, but that’s a lot more work.

I’ve tested this process with a couple things, like preventing the address from being reserved by the motherboard, in case that was preventing the right driver from grabbing it, and making sure the _STA method returned 0x0F, regardless of the BIOS setting for enabling CIR (CIRE). None of these fixed my problem, but showed me that a fix might be possible to implement.

If there is more interest in my pursuit, I can go into more detail, but I feel like I have probably already dragged on long enough for now. I’ve got a lot more to learn, but I’ll leave you with some of the links (I’ve got a lot of open tabs right now!) I’ve found useful around working with ACPI:

Overriding a DSDT | 01.org

Learned something potentially important about version number in this one:

ACPI AML debug and override ACPI tables using initrd — Programmer Sought

DSDT — ArchWiki

Getting my customized DSDT loaded in Xubuntu:

boot — Including a custom ACPI DSDT with (K)Ubuntu 18.04 (RC1) — Ask Ubuntu

So shortly after my last post, I found one of my open tabs contained this: ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media

which seems to confirm what I was saying about the length in the PN50 DSDT table being 0x10, instead of 0x08. So, as an alternative to using the ite-cir patch (not trying to discredit the work done on that … just giving another option), I’ll walk through how I would approach this ACPI table.

Before you start this process though, check the following:

cat /boot/config-$(uname -r) | grep ACPI_TABLE_UPGRADE
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y

If your kernel has this configuration, it will allow the loading of an updated ACPI table from a file (DSDT in this case). If not already present, you can build a kernel that can, but that goes against this being a «quick» fix. If it doesn’t have this config, then the rest of this post won’t be relevant.

Now, retrieve the DSDT table. I’ve made a new folder to try and keep the clutter down. (Can I ask a favour here … could someone attach their DSDT file for a PN50 here? I’d like to compare it against my PN62S to see if I can figure out why the kernel really doesn’t like my CIR. Thanks)

mkdir acpi
cd acpi
sudo cp /sys/firmware/acpi/tables/DSDT ./
sudo chown j:j DSDT       // or be prepared to use sudo more often

Now you need iasl, the ACPI Source Language compiler/decompiler. I was initially able to install a package (acpica-tools) on my system which contains this, but the version available in that package found errors during the ACPI compilation process. So I built the latest version from GitHub — acpica/acpica: The ACPI Component Architecture (ACPICA) project provides an open-source operating system-independent implementation of the Advanced Configuration and Power Interface specification (ACPI). For detailed project information and downloads, go to https://www.acpica.org. For ACPICA contributor and source code licensing information, go to and it didn’t have a problem compiling a new ACPI table Once you have it installed, use it to disassemble the current DSDT table.

[email protected]:~/acpi$ iasl DSDT 

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation

File appears to be binary: found 95539 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file DSDT, Length 0x449FF (281087) bytes
ACPI: DSDT 0x0000000000000000 0449FF (v02 ALASKA A M I    01072009 INTL 20160527)
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
 Warning - Emitting ASL code "External (CIRE)"
           This is a conflicting declaration with some other declaration within the ASL code.
           This external declaration may need to be deleted in order to recompile the dsl file.

 Warning - Emitting ASL code "External (COME)"
           This is a conflicting declaration with some other declaration within the ASL code.
           This external declaration may need to be deleted in order to recompile the dsl file.

 Warning - Emitting ASL code "External (ESPC)"
           This is a conflicting declaration with some other declaration within the ASL code.
           This external declaration may need to be deleted in order to recompile the dsl file.

 Warning - Emitting ASL code "External (PSON)"
           This is a conflicting declaration with some other declaration within the ASL code.
           This external declaration may need to be deleted in order to recompile the dsl file.

Disassembly completed
ASL Output:    DSDT.dsl - 2051852 bytes

There’s now a text file, DSDT.dsl, in the current folder, which is the source code for the DSDT table. This is the file that will be edited later to change the length reported to the kernel. I slightly overstated the file size last time, but my file is 62,293 lines.

I think there’s a lot of clutter in this file. I suspect there’s a lot of code in here meant for other machines, new code without looking for old code, etc., which possibly accounts for a lot of these errors. «Case» in point … if I try to recompile what I just decompiled, without making any changes, it finds errors (using the -ve option only displays errors, otherwise they’re hard to find among the 209 warnings and 536 remarks!). Several times there are Case statements for the same value.

[email protected]:~/acpi$ iasl -ve DSDT.dsl

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation


DSDT.dsl  61533:                     Case (0x03)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61489:                     Case (0x03)


DSDT.dsl  61537:                     Case (0x03)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61489:                     Case (0x03)


DSDT.dsl  61541:                     Case (0x30)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61497:                     Case (0x30)


DSDT.dsl  61569:                     Case (0x78)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61561:                     Case (0x78)


DSDT.dsl  61577:                     Case (0xA0)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61573:                     Case (0xA0)


DSDT.dsl  61639:                     Case (0x03)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61606:                     Case (0x03)


DSDT.dsl  61642:                     Case (0x03)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61606:                     Case (0x03)


DSDT.dsl  61645:                     Case (0x30)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61612:                     Case (0x30)


DSDT.dsl  61666:                     Case (0x78)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61660:                     Case (0x78)


DSDT.dsl  61672:                     Case (0xA0)
Error    6022 - Case value already specified ^


Original Case value below:
DSDT.dsl  61669:                     Case (0xA0)


ASL Input:     DSDT.dsl - 2051852 bytes  29862 keywords  62295 source lines


Compilation failed. 10 Errors, 209 Warnings, 536 Remarks
No AML files were generated due to compiler error(s)

Editing the file and removing the redundant Case statements solves this problem. That gave me a file that would compile:

[email protected]:~/acpi$ iasl -ve DSDT.dsl

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation


ASL Input:     DSDT.dsl - 2050902 bytes  29847 keywords  62260 source lines
AML Output:    DSDT.aml -  280440 bytes  24941 opcodes    4906 named objects


Compilation successful. 0 Errors, 209 Warnings, 536 Remarks, 618 Optimizations

The DSDT.aml file is technically the new DSDT table that can be loaded by the kernel, although this one doesn’t have any changes in it yet.

So go back to the editor and make the necessary changes. I haven’t tried leaving the version as-is, but from what I’ve read it needs to be larger than the hardware version for this to work. So changing mine from 0x01072009 to 0x0107200A has worked in the past. Obviously, you will need to choose your value accordingly. This is located at the very start of the file (line 21).

/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20210331 (64-bit version)
* Copyright (c) 2000 - 2021 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of DSDT, Thu Apr 29 15:14:50 2021
*
* Original Table Header:
*     Signature        "DSDT"
*     Length           0x000449FF (281087)
*     Revision         0x02
*     Checksum         0xDD
*     OEM ID           "ALASKA"
*     OEM Table ID     "A M I "
*     OEM Revision     0x01072009 (17244169)
*     Compiler ID      "INTL"
*     Compiler Version 0x20160527 (538314023)
*/
DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)

If you search for ITE8708, the device we’re after, you should be led to it’s definition in the file. Change the value on line 31 to 0x08.

Device (CR00)
{
    Name (_ADR, Zero)  // _ADR: Address
    Name (VBAN, 0x0680)
    Name (VIRQ, 0x0A)
    Name (UIDN, Zero)
    Name (_HID, EisaId ("ITE8708"))  // _HID: Hardware ID
    Method (_UID, 0, NotSerialized)  // _UID: Unique ID
    {
        Return (UIDN) /* _SB_.PCI0.CR00.UIDN */
    }

    Method (_STA, 0, Serialized)  // _STA: Status
    {
        If ((CIRE == Zero))
        {
            Return (Zero)
        }

        Return (0x0F)
    }

    Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
    {
        Name (BUF0, ResourceTemplate ()
        {
            IO (Decode16,
                0x0000,             // Range Minimum
                0x0000,             // Range Maximum
                0x01,               // Alignment
                0x08,               // Length
                _Y10)
            IRQNoFlags (_Y11)
                {}
            DMA (Compatibility, NotBusMaster, Transfer8, )
                {}
        })
        CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y10._MIN, IOPL)  // _MIN: Minimum Base Address
        CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y10._MAX, IOPH)  // _MAX: Maximum Base Address
        CreateWordField (BUF0, _SB.PCI0.CR00._CRS._Y11._INT, IRQ)  // _INT: Interrupts
        IOPL = VBAN /* _SB_.PCI0.CR00.VBAN */
        IOPH = VBAN /* _SB_.PCI0.CR00.VBAN */
        IRQ = (One << VIRQ) /* _SB_.PCI0.CR00.VIRQ */
        Return (BUF0) /* _SB_.PCI0.CR00._CRS.BUF0 */
    }
}

Save the file and recompile it (iasl -ve DSDT.dsl). There shouldn’t be any errors. Now the DSDT.aml file should contain the correct information to report to the kernel when loaded. Move this file to the /boot folder.

Now the boot loader should be able to access the revised DSDT as the machine starts. Without getting into the various ways that boot loaders work (because I need to brush up on that myself), I have only interrupted my GRUB loader and manually added the acpi statement to the end:

initrd /boot/initrd.img-5.10.0-1023-oem
acpi   /boot/DSDT.aml

The advantage of being able to load an .aml file is that if the config of the boot loader is such that the necessary statement is added automatically, upgrading a kernel shouldn’t require any changes related to this. And if a BIOS update resolves the issue, then removing this from the boot process is all that it takes to clean up.

After booting, I can find evidence of the new table in dmesg. My new version number is present.

[email protected]:~$ dmesg | grep DSDT
[    0.010373] ACPI: DSDT 0x0000000028A7C000 044778 (v02 ALASKA A M I    0107200A INTL 20210331)
[    0.259601] ACPI: _SB_.PCI0.LPCB.EC0_: Boot DSDT EC used to handle transactions
[    0.318901] ACPI: _SB_.PCI0.LPCB.EC0_: Boot DSDT EC initialization complete

Hope someone can find this useful. I’ve tried to be detailed enough, so it may look long, but once it’s been done a couple times, I can make a change in a few minutes without rebuilding a driver or kernel, and reverting even quicker.