hansdegoede: me (Default)
About 10 weeks ago I bought a GPDwin. I was working on improving Fedora on Cherry Trail based as a side project and I found out about this cute little machine via a blogpost from Adrien Plazas.

So now 10 weeks later I'm happy to report that after spending a lot of my spare time on kernel fixes I've it mostly working, specifically I've fixed the following things:

1) Brightness control
2) Wifi no longer working with recent kernels
3) Suspend/resume not working
4) Power and volume up/down buttons not working
5) System not waking up when opening the lid
6) Not charging when the power cable gets plugged in after boot
7) Only drawing max 0.5A from the charger, charging slowly if at all
8) Battery monitoring

And Takashi Iwai and Adrian Plazas have fixed:

9) Headphone jack detection

I've done my best to fix all of these properly and I've been submitting patches for all of this upstream. About half of the patches have already been accepted and will be merged into the kernel for the 4.12 release.

If you want to give it a try here are some step-by-step instructions:

1) First of all if you still have Windows on there and you've the 20161118 BIOS you may want to consider downgrading the BIOS to the 20161025 version before wiping Windows. The 20161118 BIOS is locked in a sort of novice mode and removes all options from the BIOS. Since Windows does not support USB gadget mode the dwc3 gadget controller is disabled and cannot be re-enabled in the 20161118 BIOS. So if you want to be able to use the USB-C connector in gadget/device mode and not just as a charging or host port in the future you are going to need the 20161025 BIOS and BIOS-flashing is only supported under Windows (flashrom may work but I was not brave enough to try it).

2) Install your favorite distro, either use an external hdmi monitor or add "i915.modeset=0 fbcon=rotate:1" to the kernel cmdline

3) To get wifi to work copy this file to /lib/firmware/brcm and then reboot.

If you kernel is new enough it will trip over a BIOS bug which causes the wifi chip to get disabled, you can "fix" the BIOS bug (if you do not have
the 20161118 BIOS) by changing the following BIOS setting: "Chipset" -> "South Bridge" -> "LPSS & SCC Configuration" -> "SCC SDIO Support"
to "Disabled". My patches include a workaround for the BIOS bug which works with the 20161118 BIOS, so if you've that you will need to install my kernel through other means (e.g. an USB network adapter).

4) clone my personal linux kernel repo:

git clone https://github.com/jwrdegoede/linux-sunxi.git

This comes with a kernel .config file based on the standard Fedora kernel config (so highly modular). Follow the usual instructions for your distro to build a kernel from source (minus getting the .config). Make sure an initrd gets generated, this kernel-config will not work without an initrd.

Before rebooting into the new kernel add the following to the kernel cmdline in your grub configuration: "fbcon=rotate:1 dmi_product_name=GPD-WINI55".

For brightness control to work your initrd must include the pwm-lpss and pwm-lpss-platform modules. Under Fedora you can do this by booting into the new kernel and then running:

dracut -f --add-drivers "pwm-lpss pwm-lpss-platform" /boot/initramfs-$(uname -r).img $(uname -r)

5) To get sound to work you need to do some userspace config tweaks:

Edit /etc/pulse/daemon.conf and set: "realtime-scheduling = no" to work around a pulse issue with the hdmi-audio support for Cherry Trail.

Create an /usr/share/alsa/ucm/chtrt5645 directory and copy the 2 .conf files from here into that dir.

6) Edit /lib/udev/hwdb.d/99-local.hwdb, add:

sensor:modalias:acpi:KIOX000A*:dmi*:
 ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1


Copy this file to /lib/udev/rules.d/

Then run "sudo udevadm hwdb --update" and reboot, together with a new enough iio-sensor-proxy, this will fix the screen orientation under gdm / gnome (note you need to tilt the device a bit toward you after booting to get it to recognize the screen orientation for now).

7) All done enjoy your (almost) fully functional GPDwin under Linux

Note these instructions are for somewhat advanced Linux users, if you hit problems please take a look at your distro's documentation or ask for help on your distro's forums.

Linux BIOS tweaks, if you have the 20161025 BIOS, there are 2 BIOS tweaks you can do:

1) Enable USB gadget support, goto: "Chipset" -> "South Bridge" -> "USB Configuration" And change the following 2 options:
"USB OTG Support" : "PCI"
"DRD Access Method" : "Mmio"
This will allow you to load gadget drivers (e.g. "modprobe g_serial") and then connect the GPD-win to a PC and have it show up as an usb device

2) Enable the "S5-Charging Driver" some howtos actually advice disabling this, but it is useful to make sure the GPDwin fast charges when plugged into a charger without being turned on (and even allows for faster charging once the OS is booted). The reason some people advice to turn it off is because it causes problems turning the device on when plugged in and fully charged, when plugged in and fully charged it will simply show a "Battery 100%" screen when you turn it on and then turn off again. You can workaround this by pressing ctrl-alt-del while at the "Battery 100%" screen, or not enable the "S5-Charging Driver" and live with the slower charging.

To enable this goto: "Advanced" -> "System Component" and set "S5-Charging Driver" to "Enabled"

TODO:

1) Recently I found out that the GPDwin has a FUSB300C USB Type-C controller and a PI3USB30532 USB switch which together should allow full USB-C functionality at USB 3.0 speeds (currently the gadget mode runs at 2.0 speed and host mode does not work at all). I plan to write and upstream drivers for this to make this all work.

2) Get all of the required kernel changes upstream.

3) Make things more simple overall ideally new distros released in 2018 will just work without requiring any changes at all.
hansdegoede: me (Default)
At the end of 2013 I've spend 2 full months working on getting XHCI streams support and the UAS driver in the Linux kernel, which uses streams into shape. With the release of the 3.15 kernel this work now is available for end users to use.

This is good news for anyone who cares about performance of USB connected harddisks / ssds. The old usb mass-storage protocol is well known for its poor performance. UAS however allows NCQ and thus allows effectively using the full USB-3 bandwidth. If you've an UAS capable harddisk enclosure then all you need is a 3.15 kernel build with the UAS driver enabled and you should instantly get better performance. Note that most harddisk enclosures, including USB-3 enclosures do not support UAS, so if you want to use UAS double check before buying a harddisk enclosure.

One use-case of UAS I love is to have a 2.5" ssd with a full Fedora rawhide install with me so that when people ask me about hardware compatilibty issues they are having, I can simply plug in the ssd to there laptop boot rawhide and see if having the latest kernel + xorg fixes things. For a decently priced UAS capable 2.5" hdd enclosure search ebay for: "sedna usb 3.0 2.5 inch hdd enclosure". when shopping for UAS enabled devices, always check that the device description mentions UAS or UASP.

Besides UAS support, the 3.15 kernel also features support for using USB-3 bulk streams from userspace through usbfs. To use this you need the just released libusb-1.0.19 release. One use case of USB-3 bulk streams from userspace is using these for usb-redirection in qemu. With the upcoming 2.1 qemu release this will be supported allowing the use if usb-3 redirection with uas devices from within a qemu vm. This will be supported with both qemu's host usb redirection, as well as spice's network usb redirection. This means that starting with qemu-2.1 qemu's USB redirection features full USB-3.0 compatibility.
hansdegoede: me (Default)

Sunday May 4th Revspace is organizing a workshop on reverse engineering USB protocols of devices with proprietary protocols.

Reverse engineering protocols is fun! It's like a puzzle, and if there's software out there that can solve the puzzle, your brain can do it too.

We'll be taking a look at reverse engineering the protocols on USB-connected devices. Too many of these devices still come with windows drivers only, and use an undocumented protocol. Figuring out those protocols is often a lot easier than you might think, and so is writing a simple driver.

If you want to participate in this workshop, bring a Linux laptop, preferably with a virtual machine with a Windows guest OS. If you have an exotic USB device that only has a Windows driver, please bring that too.

For more details see: https://revspace.nl/UsbProtoReverseEngineeringWS2

Profile

hansdegoede: me (Default)
Hans de Goede

July 2025

S M T W T F S
  123 45
6789101112
13141516171819
20212223242526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 9th, 2025 08:15 pm
Powered by Dreamwidth Studios