Ayaneo Kun

Circuit board

Some pictures of the Kun's circuit board.

• Picture 1
• Picture 2
• Picture 3
• Picture 4
• Picture 5
• Picture 6

Firmware EEPROM

The vendor/manufacturer of the EEPROM is Winbond, the product name is W25Q256JWPQ. Size is 32MiB and interface is SPI.

The EEPROM is located directly above the APU, see Picture 1.

Recovery

The following hardware is required for recovery.

• CH341A MinProgrammer USB programmer (easily available on Amazon)
• 1.8V level shifter for programmer
• alternatively: CH341A v1.7 USB programmer (this one can operate directly with 1.8V output level)
• DFN8/QFN8/WSON8 probe with 5x6 mm size (larger sizes don't fit the chip)

If you choose the v1.7 USB programmer you don't need the level shifter. Make sure you switch the programmer into 1.8V mode though. The EEPROM is only rated for 1.8V, hence higher voltages may permanently damage it.

Programming of the EEPROM can be done e.g. using flashrom.

Information dumps

• Content of /proc/cpuinfo: Link
• Output of the cpuid utility by Todd Allen: Link
• Output of lspci -v: Link

The following dumps were created using an Arch Linux install medium with a 6.6.8-arch1-1 kernel.

• Output of dmesg: Link
• Output of ls /sys/devices/platform/: Link
• Output of ls /sys/module/: Link

For each class in /sys/class we did a udevadm info -a -p ${node_name} for all nodes of this class type. The output was named ${class_type}_${node_name}.txt.

• Tarball of all outputs: Link

USB devices

• Output of lsusb -t -v: Link
• Output of lsusb -v -d 045e:028e: Link
• Output of udevadm info -a -p /sys/bus/usb/devices/1-4.1:1.0: Link#

Integrated Xbox360 controller

Firmware upgrade

Fetch the controller firmware (Ayaneo calls it handle firmware) from their website. The firmware blob should be named something like AB08_V1.5_10.bin. Make sure the device is charged.

• Powerdown the device
• Disconnect any external power supply
• Disconnect any external USB devices
• Wait for at least 10 seconds (probably to give the controller hardware time to drain capacitors)
• Press down L3 (left controller thumbstick) and keep it pressed
• Press power button
• Wait until the bootloader comes up (e.g. GRUB) and unpress L3

Once the kernel has booted, you should now see a USB mass storage device that replaces the controller device usually found on the bus. The device has no partition layout, just one 8MiB (16391 512-byte blocks) sized FAT filesystem. Mount the filesystem, copy the firmware blob onto it and issue a sync. After a short while the device should drop of the USB. Powerdown the device again, and leave it for 10 seconds. Now power it up again normally.

Firmware reset behaviour

For some reason the controller firmware seems to implement some very strict watchdog mechanism. If the firmware doesn't see a USB transfer from the host within a second (exact value is unknown), it resets the USB device. The device drops of the bus, the kernel unloads the driver. Once the device pops up again on the bus, it is then again probed by the kernel, which then loads the driver. This cycle of USB disconnect followed by almost immediate reconnect is repeated ad infinitum.

In fact this behaviour is not unique to this firmware: Link

A workaround consists of immediately opening the event device of controller and to keep it open. On the kernel driver level this results in periodic USB transfers to query button and other states. Due to these transfer happening several times each second the firmware watchdog is happy and keeps the device alive.

It is unclear why the firmware implements this behaviour, in particular because it is detrimental to powersaving. Also it is not known if the problem also appears on Windows. The kernel driver on Windows might be implemented differently, e.g. it could request periodic USB transfer regardless if the input device is used or not.

A issue report is open on the xpad issue tracker.

Workaround implementation

A draft implementation of the workaround can be found here: Link

Relevant files are:

• src/evdev_keepalive.c
• systemd/xbox360-config@.service
• udev/70-gamepad-controller.rules

It consists of a UDev rule, a systemd unit template and a C application. The rule automatically starts the systemd unit once the event device of the controller is available. The unit is just a thin wrapper around the application that keeps the event device open until the application is terminated by the unit again.

AT keyboard

Some of the buttons are exposed through a regular AT keyboard.

Power:

0xe05e 0xe0de 0xe05e 0xe0de (press+release)

Volume Down:

0xe02e (press)
0xe0ae (release)

Volume Up:

0xe030 (press)
0xe0b0 (release)

LC:

0xe01d 0xe05b 0xe03f (press)
0xe0bf 0xe0db 0xe09d (release)

RC:

0xe01d 0xe05b 0xe025 (press)
0xe0a5 0xe0db 0xe09d (release)

Start (upper-right corner of screen):

0xe01d 0xe05b 0xe040 (press)
0xe0c0 0xe0db 0xe09d (release)

Ayaneo (lower-right corner of screen):

0xe01d 0xe05b 0xe065 (press)
0xe0e5 0xe0db 0xe09d (release)

Hamburger (right of Ayaneo button):

0xe05b 0x20 (press)
0xe0db 0xa0 (release)

Standard keyboard scancodes

Note that most of the buttons generate a multi-scancode sequence.

Some common scancodes are:

0xe05b = Left_Meta/Windows (press)
0xe0bb = Left_Meta/Windows (release)
0xe01d = Right_Ctrl (press)
0xe09d = Right_Ctrl (release)

Touchpad

The touchpad is exposed as USB device. The device is not directly connected to a root hub, but through a USB hub IC by Terminus Technology Inc. (vendor ID of the hub is 1a40, and product ID is 0101). The hub usually is device 4 on bus 1 (bus of the first root hub).

The vendor ID of the touchpad is 0483 which indicates a hardware based on a microcontroller by STMicroelectronics. The product ID is 52a4, which was probably chosen by Ayaneo. The device exposes three USB HID interfaces.

Firmware upgrade

Analysis of the content of the firmware upgrade package shows several interesting files.

• SoundModeFirmware.dfu
• dfu-util.exe
• libusb-1.0.dll
• lsusb.exe

Hence it is very likely that the firmware is upgraded via DFU. However there is no USB interface exposing DFU. Since STM is involved, the device might use the propriertary DfuSe protocol. This seems plausible as this protocol allows switching between HID and DFU mode using a vendor specific HID detach feature. See these links for reference.

• UM0412
• DfuSe USB device firmware upgrade
• DfuSE sourcecode dump

You can find a dump (using hid-decode from the hid-tools package) of the HID report descriptors here: Link

Sadly the detach feature 0x0055 is not there. Further analysis is needed. Some ideas:

• check if upgrade functions under Wine and trace USB traffic using usbmon
• if that doesn't work, passthrough the Terminus hub to a Windows VM and trace the traffic there

Problematic hardware

CS9711 fingerprint sensor by Chipsailing Technology Co., Ltd.

• USB vendor ID 2541, and product ID 0236
• no upstream userspace driver available at the moment
• reverse engineering project on the libfprint issue tracker: Link

Ryzen AI

• AI accelerator integrated in the AMD 7840U APU
• Driver stack in development: Link
• kernel driver was merged in drm-misc-next: Link
• most likely part of the v6.14 kernel release

Bosch IMU

• confirmed by Derek J. Clark that the devices houses a BMI260
• ACPI table information indicates a BMI160 (done by the vendor to provide backward compatibility to old Windows driver)
• support for the BMI260 was merged in the v6.13-rc1 kernel: Link
• is going to be part of the v6.13 kernel release

Audio support

• ACPI tables indicate that device includes a amplifier by Shanghai Awinic Technology Co., Ltd. (the string AWDZ8830 is present in the tables)
• two amplifiers (model AW87559) are attached to the second DesignWare I2C adapter (ACPI node AMDI0010:01), addresses are 0x58 and 0x5b
• AW87559 uses standard SMBus protocol, identifies itself as 0x5a as IDCODE on register 0x0
• datasheet available here: Link
• no upstream kernel driver is available
• driver can be found in downstream Rockchip kernel: Rockchip (only implements DeviceTree probing)
• modified driver (with ACPI probing) can be found here: Link
• driver requires proprietary firmware (which poses a distribution problem)

Miscellaneous

• LED control
• touchpad firmware update

Also see this report on the ChimeraOS issue tracker for additional information.

Pending upstream patches

No patches are currently pending.

The following kernel patches are not submitted yet: Link

ACPI tables

A dissassembled dump of the non-data ACPI tables can be found here: Link

Dump was done using the firmware blob AB08_Kun_7840U_P6C3L6M0C15_V2.18_S20_AC_EC_V0.0.59_6400_OnlyS4_MS_Pro_20240326.bin.

UEFI firmware analysis

Analysis was done using this blob: AB08_Kun_7840U_P6C3L6M0C15_V1.9_EC_V0.0.58_7500_OnlyS4_S011.8_D01_54W_20230809.bin

Interesting DXE drivers are:

• Setup
• AmdPbsSetupDxe

Interesting VarStores are:

• Setup (EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 with VarStoreId 0xf101)
• AMD_PBS_SETUP (A339D746-F678-49B3-9FC7-54CE0F9DF226 with VarStoreId 0x1)
• UsbSupport (EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 with VarStoreId 0xb)

Setup

Interesting variables:

• Enable Hibernation (offset 0x32)

UsbSupport

Interesting variables:

• Legacy USB Support (offset 0x1)
• XHCI Legacy Support (offset 0x2a)
• XHCI Hand-off (offset 0x2b)

AMD_PBS_SETUP

Interesting variables:

• UCSI Support (offset 0x14)
• USB4 ACPI _DEP Support (offset 0x465)
• Sensor Fusion User Mode Driver (offset 0x3f)
• AMD PMF Device Support (offset 0x9d)
• S3/Modern Standby Support (offset 0x38)
  • S3 Enable (value 0, default)
  • Modern Standby (value 1)
• Modern Standby Type (offset 0x41)
  • Modern Standby + S0i2 (value 0)
  • Modern Standby + S0i3 (value 1, default)
  • Modern Standby + S0i2 + S0i3 (value 2)
  • S0i3 with workaround (value 3)

Other firmware versions

The latest firmware blob AB08_Kun_7840U_P6C3L6M0C15_V2.18_S20_AC_EC_V0.0.59_6400_OnlyS4_MS_Pro_20240326.bin seems to use the same offsets.