Asus PN50 challenge

    Quote from Deezle

    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.

    Quote from Deezle

    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.

    • Official Post
    Quote from smp

    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.

    Quote from lrusak

    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.

    Quote from lrusak

    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.

    Quote from powerarmour

    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.

    Quote from lrusak

    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.

    Edited 2 times, last by pletopia: Merged a post created by pletopia into this post. (March 9, 2021 at 12:30 AM).

    Quote from pletopia

    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

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

    Any ideas?


    PS Just saw 10.0 Beta 1 has been released. dmesg output is the same

    Edited 2 times, last by beredim (March 15, 2021 at 11:58 PM).

    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

    &

    Getting the IR receiver to work with Haswell NUCs - The NUC Blog

    So for the PN50 I figure the commands should be:

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

    Code
    [  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!

    and ir-keytable still returns No devices found.

    1. There is one more direction to look at, that is this mail thread I found, regarding the PN50 specifically:

    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:

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

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

    Code
    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

    Edited once, last by beredim (March 16, 2021 at 2:37 PM).

    Success

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

    It was that email thread I posted earlier
    ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
    where the answer was hiding, but it took a lot of effort from my part.
    First time building LibreELEC, first time writing a patch and so on.

    ir-keytable now works correctly :D

    I'll need some help pushing this, at least as a patch to libreelec project, and possibly to the linux drivers. Can anyone help with this? pinging chewitt

    As far as I can tell after digging through dozens of forums/posts/reddits this is the first publicly documented instance of the IR module in the PN50 actually working

    • Official Post

    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.

    2. In addition, try to push this upstream to the appropriate linux mailing list, so that it becomes a part of the kernel drivers at some point, and possibly also backported (if that's an option). I'm not really sure how long that's going to take.

    So for 1 I guess I'll do a PR on github. Does that sound good?

    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

    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.

    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

    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.

    Edited 2 times, last by mccrae (April 29, 2021 at 9:44 PM).