Posts by mccrae

  • Asus PN50 challenge

    Even though I just seem to be talking to myself, I thought I'd try to bring my contribution closer to completion. I eventually discovered that there seems to be an address conflict with the CIR on my PN62S. By changing the _ADR from Zero to 0x01 and recompiling my DSDT as above, ite-cir will happily see, and connect with the ITE8708. I have submitted a tech support request to Asus detailing my issue, hoping this, or an equivalent correction, will make its way into a future BIOS update. I also mentioned the PN50 length issue, so hopefully they will examine that as well. If I get any relevant response, I may provide an update. In the meantime, I'm using the script for grub from Updated `01_acpi` script. · GitHub to automatically load my custom DSDT.

  • Asus PN50 challenge

    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:

    Code
    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)

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

    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.

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

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

    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.

    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.

    Code
    sudo cp DSDT.aml /boot

    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:

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

    Code
    j@frontend:~$ 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.

  • Asus PN50 challenge

    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.

    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 ( :idea: After this I'm going to download the PN50 and see if there's anyway I can find the DSDT table in it!)

    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