Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

gmelchett · 2016-12-07 11:31:26

Applying this patch series: https://patchwork.freedesktop.org/series/16242/ makes i915 work without any workarounds.

gmelchett · 2016-12-08 07:24:23

I was hoping with working i915 that suspend/resume (echo freeze | sudo tee /sys/power/state) would work, since in 4.8 it was not far from. But somewhere in between 4.8 and 4.9rc3 something broke - I think - mmc/sd suspend. With no_console_suspend=1, I get like three-four screens of error outputs, so it is hard to say what comes first.
So if anyone is bored, has a fast computer to build on and has a few hours to spare, feel free to do a git bisect to track down the faulty patch(es)..
(Just keep i915 blacklisted, and don't start anything with wifi, the broadcom driver doesn't really work well with suspend/resume.)

pavan · 2016-12-14 16:09:54

Hi,
I am back with some updates. I did some more reverse engineering of the codec windows driver RTII2SAC.sys.
I am convinced (not sure, which applies for all the information in this post) that I`ve found the function call which sends the data over I2C bus - WdfIoTargetSendWriteSynchronously. I created a wrapper around it to dump all the data. I also added some more wrappers - for WdfIoTargetSendReadSynchronously and a function which seems to be something like read_register (it indirectly calls the two previously mentioned functions). If you are interested in the modified driver, you can download it here https://github.com/p-an/T100HA-DSDT/blo … II2SAC.sys. Just put it into C:\Windows\System32\drivers and disable driver signature enforcing. The output is in C:\Windows\Logs\rtkdebug.txt. Despite the extension, it is not a text file, it is full of redundant garbage (the driver always writes 0x70 bytes regardless how the actual string is long - it was too difficult to do it better). To remove the garbage use this https://github.com/p-an/T100HA-DSDT/blo … /readlog.c (it simply repeatedly reads the 0x70 bytes from the file and prints it as string - i.e. till the first 0 byte). An example of the log is here https://github.com/p-an/T100HA-DSDT/blo … ay-spk.txt - it is generated while playing a short file through speakers. There are several types of lines:
- starting with WDFWRT1 - probably the most interesting one - these are the data written to I2C. The first number is the number of bytes being written (1 or 3) and the second the actual data - 3 bytes. The first byte is the register and the rest the data written into it
- starting with WDFWRT2 - from the same wrapper - I added this to verify that the WdfIoTargetSendWriteSynchronously is always used in the same way. So the first item is pointer to WDFIOTARGET (there is only one used), the second one is type of input buffer (always 3 - WdfMemoryDescriptorTypeHandle), the third is number of bytes actually written and the last one is the return code.
- starting with WDFREAD - the same as the two above, just for reading
- starting with RR - this wrapper around the probable function read_register - the first item is the register number and the rest are the data. The same information can obtained from WDFWRT1 and WDFREAD1, this is just for convenience.
- starting with TAG - some other wrappers around functions, which seemed interesting in some point, but I haven`t followed this way yet (maybe never will)
- the rest of lines are the original debugging output from the driver - register writes, probably function names and some other messages. But I didn`t enable all of them (the driver crashed, when I tried)

Some more notes and observations:
- Just a while ago I`ve found this - https://bugzilla.kernel.org/show_bug.cgi?id=115531 - see the last message. Pierre Bossart says that ALC3270 is compatible with RT5645. I wonder what is this statement based on. Following points suggest some similarity, but I am not sure about compatibility.
- The 0xff register is checked in the windows driver against the same value as in rt5645 in Linux. Based on this value several function pointers are set up
- I didn`t find any notice in the windows driver about ALC3270
- The registers above 0xff are in fact so called private registers and they are indirectly accessed using 0x6a (used for the register number) and 0x6c (used for the value) registers
- there is a loop in the windows drivers, which dumps all registers.
- I blocked the actual I2C writes in the Linux driver to be on the safe side and I am comparing the register writes with the on windows. There some similarities - e.g. register 0x66 seems to work the same way. Not much, but it suggests, that at least one part on the audio path is switched in the same way in Windows and Linux, when the headphones are plugged in (so there is chance that speakers are safe with headphones connected). I`ve also googled data sheet for ALC5640, so I have some more information, but it is still too little. A data-sheet for alc3270 or at least alc5645 would be really helpful.
- This time I installed new kernel (4.9-rc8) and full desktop environment in Linux and aplay works without any previous mixer settings. I don`t know how exactly this happened - maybe new kernel, maybe pulseaudio or something else... Still no sound, but that is obvious, because I intentionally crippled the driver (see prevoius point)
- There is a file called realtek_fw_sst.bin in windows, it may work better than fw_sst_22a8.bin. But it is just an idea, I haven`t tried that.
- there is a pdf file called ASUS T100HAN Repair guide on some websites. The preview looks promising, but my attempts to download it always ended at the point, when someone wanted money. Not much, I`d pay that, if I am sure th
at file is usefull, but I am not even sure if I can trust those websites. Any chance someone here has this file?

gmelchett · 2016-12-15 07:11:13

Interesting!

The debug print in th log:
"ChangePowerStatus_5645"
does indeed suggests that there are some similarities. Also, when I tested with some generic alsa settings (my installation doesn't have any), except that there is no sound, it looked alright.
Could you upload your alsa settings? (I guess "alsactl store" will save the state.) I'm willing to risk my speakers with another attempt.
Also when you're at it, could you upload the fw? Thanks.

gmelchett · 2016-12-15 08:05:10

Quick lock at the log:
--
# RT5645_DEPOP_M2
write gen-reg=0x8F, data=0x3140
# power analog 1
write mask gen-reg=0x63, data=0x2002, mask=0x0003
# power analog 2
write gen-reg=0x64, data=0x8C04
# GLB_CLK
write gen-reg=0x80, data=0x0000
# ???
write pri-reg=0x15, data=0x2A87
# gen ctrl 1
write mask gen-reg=0xFA, data=0x2061, mask=0x0001
# gen ctrl 2
write mask gen-reg=0xFC, data=0x1B80, mask=0x0600
# RT5645_ADDA_CLK1
write gen-reg=0x73, data=0x0000
# RT5645_DEPOP_M2
write gen-reg=0x8F, data=0x1100
# RT5645_ADDA_CLK1
write mask gen-reg=0x73, data=0x1000, mask=0x700C
# RT5645_STO1_ADC_DIG_VOL
write mask pri-reg=0x1C, data=0xFD21, mask=0x0020
# ????
write mask pri-reg=0x39, data=0x0600, mask=0x0E00
# RT5645_PWR_DIG2
write mask gen-reg=0x62, data=0x0800, mask=0x0800
# RT5645_PWR_ANLG1
write gen-reg=0x63, data=0xE8DA

# power mixer
write mask gen-reg=0x65, data=0x3002, mask=0x3000
# power volume
write mask gen-reg=0x66, data=0xC000, mask=0xC000
# power dig
write mask gen-reg=0x61, data=0x1B01, mask=0x1B01
write mask gen-reg=0x61, data=0x9B01, mask=0x8000
# analog src 1
write mask gen-reg=0x83, data=0x0C00, mask=0xFC00
# analog src 2
write mask gen-reg=0x84, data=0x1000, mask=0xF000
# RT5645_MUTI_DRC_CTRL1
write gen-reg=0xEA, data=0x0F20
# ???
write pri-reg=0x94, data=0x8700
# RT5645_ALC_CTRL_2
write gen-reg=0xB4, data=0x0000

# speaker volume
write mask gen-reg=0x01, data=0x0707, mask=0xC0C0
write mask gen-reg=0x01, data=0xC7C7, mask=0xC0C0
# RT5645_STO1_ADC_DIG_VOL
write mask pri-reg=0x1C, data=0xFD01, mask=0x0020
# power dig1
write mask gen-reg=0x61, data=0x9800, mask=0x0301
# power dig2
write mask gen-reg=0x62, data=0x0800, mask=0x0080
# power alg 1
write mask gen-reg=0x63, data=0xE8DA, mask=0x0400
# power mixer
write mask gen-reg=0x65, data=0x0002, mask=0x3000
# power volume 0 --->>> OFF???
write mask gen-reg=0x66, data=0x0000, mask=0xC000
..
--

The log has its simularities with:
http://lxr.free-electrons.com/source/so … 45.c#L1694

however there are lot of differences. The private registers differs completely, and the values written might, I have not checked. But the registermap looks the same . So a good starting point could be to just modify the private registers to match the windows log. After testing with proper alsa settings.

pavan · 2016-12-15 09:00:48

Hi,
I upload my alsaconfig, but I have better news now - I contacted Pierre-Louis Bossart and he answered that he has working playback on T100HA :-) He pointed me to his repository https://github.com/plbossart/sound/comm … tal/codecs

With all I know I am also willing to risk my speakers, so I`ll definitely try this.

gmelchett · 2016-12-15 11:17:57

Pavan, Great news! Btw, this commit https://github.com/plbossart/sound/comm … 372165642b looks pretty much like yours in comment #57, done about the same date as well :-)

I'll retest with your alsa config.

pavan · 2016-12-15 12:29:11

This change is obvious, but there some more complicated ones, so I am curious. If everything goes well, I`ll test it this evening and let you know (and upload the alsa config).

gmelchett · 2016-12-16 12:10:56

I tested yesterday with Pierre-Louis' tree, the experimental/codecs branch, and I got the same error as with our hack:
"Audio Port: ASoC: no backend DAIs enabled for Audio Port"
so something must be lacking on my system when it comes to audio path configuration.
Pavan, how did it go for you?

pavan · 2016-12-16 13:43:21

I have some sound from headphones, but just noise, definitely not the sound which I expected. You can take a look at my alsa config here https://github.com/p-an/T100HA-DSDT/blo … /alsa.conf But I don`t expect it will be useful for you. As I wrote, it is related to the full desktop system or pulse audio. I am not sure exactly, but if I start only to the text console, I have the same result as you.

I suppose that all of this can be fixed by the proper mixer settings. I`ll do some more tests, but I don`t have so much time for as I`d like to.

pavan · 2016-12-16 15:15:26

Just one small update - Pierre-Louis Bossart wrote me that he is working on the UCM (as I understand it, this is the library, which should handle the mixer settings) for this and he hopes that it will be ready before the winter break (whatever that means).

pavan · 2016-12-20 20:47:49

Hi,
thanks to Pierre-Louis Bossart I have sound, kind of ... Check the asound.state-hp and asound.state-spk files here https://github.com/p-an/T100HA-DSDT The first one enables sound into headphones, it is quiet (I didn`t even notice it for the first time) and noisy. The second one enables sound into speakers (even if headphones are plugged in), also a bit noisy, but volume is OK. I guess now it is all about the mixer settings. The problem is that there are too many switches. There is datasheet for rt5640 on the web, which brings some sense into this. You can also try this UCM https://github.com/plbossart/UCM/tree/master/chtrt5645 (according to Pierre-Louis Bossart this should the sound make work).

It didn`t burn my speakers, but use on your own risk.

Last edited by pavan (2016-12-20 20:54:39)

gmelchett · 2016-12-22 07:29:19

Great that there is some progress on the audio part! I've not yet tested myself.

Some progress else where:
https://bugzilla.kernel.org/show_bug.cgi?id=177101
Contains a fix for sd card detect when pinctrl-cherryview is compiled as a module.

But my ticket on the dsdt issue got rejected as a bios bug:
https://bugzilla.kernel.org/show_bug.cgi?id=189801
However, a workaround in the kernel might be possible since according to spec:
"A device object must contain either an _HID object or an _ADR object, but should not contain both."

The T100HA includes both _HID and _ADR, so that could be used as a check. But where to put those few lines....

gmelchett · 2016-12-26 09:02:24

Did some testing with audio on Pierre-Louis Bossart's kernel branch.
asound.state-spk brings mostly static, with what you're playing at a weak volume, and choppy. Also, I get these:
--
[ 53.839339] Base clock rate 0 is too low
[ 53.842163] rt5645 i2c-10EC3270:00: Failed to set DMIC clock
[ 53.844517] rt5645 i2c-10EC3270:00: ASoC: PRE_PMU: DMIC CLK event failed: -22
--
however, asound.state-hp works better. If you enable "Speaker channel" in alsamixer, you get good audio in the speakers :-)
But it's useless for headphones, mostly statics.

EDIT: With the UCM file, I got the usual:
--
Audio Port: ASoC: no backend DAIs enabled for Audio Port
--

Last edited by gmelchett (2016-12-26 12:33:20)

gmelchett · 2016-12-26 12:30:42

With 4.10rc1, i915 works without any quirks and if you apply these patches:
http://lithops.se/patches-on-4.10rc1.tar.bz2
you'll get audio in speakers (see previous comment) as well as touchpad and the ASUS specific keys support.

Suspend is still broken, but it is the touchpad hack that causes it. Without the touchpad hack "freeze-suspend" works fine.
Creating a proper driver is probably the best way forward. I might do that.

Left to fix (IMHO):
- suspend/resume - create proper driver
- headset audio output
- volume up/down + power button. evtest shows two "Power buttons", but nothing happens.
- Headset jack detect - Untested EDIT: Doesn't work.
- LID close suspends - Untested EDIT: Works.
- Bluetooth, I don't use it often but sometimes.
- Get the touchscreen to behave as a touchscreen. - Hopefully next xserver version will fix that.

Last edited by gmelchett (2016-12-26 18:18:49)

gmelchett · 2016-12-28 07:13:02

Dug a little deeper into the power and volume button issue, and found this:
http://www.gossamer-threads.com/lists/l … 89#2528889
explaining that without a "Dollar Cove" driver deepest sleep state and the power button won't work.
There is an out of mainline driver for Dollar Cove in the android-x86 kernel tree:
https://android.googlesource.com/kernel … ntel_pmic/
The style is however quite different from the mainline kernels. It is a small driver so making a dirty port might not be too hard..

gmelchett · 2016-12-28 12:02:50

Added two more patches to my patch stack, one to get bluetooth working, one to fix some i915 error:
http://lithops.se/patches-on-4.10rc1-2.tar.bz2

After boot, run (as root)
--
btattach -B /dev/ttyS1 -P bcm
--
To get bluetooth working.

Edit: BT fw can be found here: https://github.com/Asus-T100/firmware/b … 3341B0.hcd

Last edited by gmelchett (2016-12-28 12:04:19)

jmiahman · 2016-12-28 16:36:45

gmelchett wrote:

Added two more patches to my patch stack, one to get bluetooth working, one to fix some i915 error:
http://lithops.se/patches-on-4.10rc1-2.tar.bz2

Can you include your kernel config as well not sure about your options with pinctrl etc.. I don't want to spend the time finding out

gmelchett · 2016-12-28 18:17:09

Sure, here it is http://www.lithops.se/config-4.10rc1.bz2

Beware, it's based upon Arch Linux' kernel config which means it builds like 3300 modules, while you actually only need like 100-150.

jmiahman · 2016-12-29 15:54:16

I actually just diffed it to the Fedora config file they have in git for 4.10-rc1 and there's no major differences, in fact it works quite well. If fixes get mainlined covering those 12 patches in 4.10 Fedora will have support for the T100HA. If not I will build some packages for Fedora and post them some where until it happens.

jmiahman · 2016-12-29 18:21:05

Alright for the first time ever sound is going through the external speakers. Yay!!.. and the i915 Card is working.. It's starting to become usable now. I haven't tested Bluetooth yet as I don't have btattach compiled and fedora doesn't offer it in its bluez package. I most likely will though. I also haven't tested the mic.. if the mic works it will be usable for me. I can do headphones through my USB-C adapter and use the on board mic for Skype, Hangouts etc.. at that point this device will be usable for my needs. It's coming along. thanks for all your hard work and testing.. and they risks you're taking with your devices.

gmelchett · 2016-12-29 18:55:54

Regarding getting the touchscreen working as a touchscreen. I had to blacklist the kernelmodule "mousedev" in order to get the touchscreen properly configured. Me or X or both, got confused when a few /dev/input/mouse was the same device as /dev/input/event.

You need this in your xorg.conf:
--
Section "InputClass"
Identifier "touchscreen"
Driver "libinput"
MatchIsTouchscreen "on"
Option "TransformationMatrix" "0 -1 1 1 0 0 0 0 1"
EndSection
--
The transformation means "rotate left".

Also, I noticed that once I whitelisted i915, the backlight got set to maximum and I couldn't adjust it. Got 8 acpi_video files in /sys/class/backlight instead of intel_backlight.

With my limited knowledge it looks like according to the DSDT, that the hardware keys, volume up/down and power (head set detect?) needs two more PMIC's Dollar Cove, and Dollar Cove TI. And those are missing in the mainline tree. None-acpi versions exists in various android-x86 kernel trees.

And looking in:
/sys/kernel/debug/pmc_atom/sleep_state

No deeper powerstates are reached.

gmelchett · 2016-12-29 19:00:02

jmiahman wrote:

I actually just diffed it to the Fedora config file they have in git for 4.10-rc1 and there's no major differences, in fact it works quite well. If fixes get mainlined covering those 12 patches in 4.10 Fedora will have support for the T100HA. If not I will build some packages for Fedora and post them some where until it happens.

The touchpad hack will never reach mainline as it looks today.I might get around to write a proper driver. The sound patches and the i915 patch will reach mainline, while I might try to get the other two mainlined. (the extra keys and bluetooth acpi id)

How will you handle the patched DSDT if you make a Fedora package?

gmelchett · 2016-12-29 19:04:43

jmiahman wrote:

Alright for the first time ever sound is going through the external speakers. Yay!!.. and the i915 Card is working.. It's starting to become usable now. I haven't tested Bluetooth yet as I don't have btattach compiled and fedora doesn't offer it in its bluez package. I most likely will though. I also haven't tested the mic.. if the mic works it will be usable for me. I can do headphones through my USB-C adapter and use the on board mic for Skype, Hangouts etc.. at that point this device will be usable for my needs. It's coming along. thanks for all your hard work and testing.. and they risks you're taking with your devices.

You're welcome. I've not used windows for months on my T100HAN. I find it very stable (hours of use every day) and battery performance is alright.

I doubt the mic work with those alsa state files that pavan has provided. Maybe you will be more lucky with the UCM files than I've been, and get things working that way.

jmiahman · 2016-12-29 20:11:08

gmelchett wrote:

The touchpad hack will never reach mainline as it looks today.I might get around to write a proper driver. The sound patches and the i915 patch will reach mainline, while I might try to get the other two mainlined. (the extra keys and bluetooth acpi id)
How will you handle the patched DSDT if you make a Fedora package?

Create a Basic initrd with the dsdt.aml file in it and append the new initramfs overtop it. It's a good question though and a bit tricky.. but it should work (it's what I do manualy now). Of course it's a special case for just this model so the RPMS will have to be for just this model, unless I put some checks in there. I don't know of any similar devices though that may benefit.. if those do arise and they don't need the DSDT fix then I can write in checks in the postinst scripts and not append the generated initramfs to it.

Last edited by jmiahman (2016-12-29 20:13:27)

Arch Linux

#76 2016-12-07 11:31:26

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#77 2016-12-08 07:24:23

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#78 2016-12-14 16:09:54

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#79 2016-12-15 07:11:13

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#80 2016-12-15 08:05:10

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#81 2016-12-15 09:00:48

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#82 2016-12-15 11:17:57

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#83 2016-12-15 12:29:11

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#84 2016-12-16 12:10:56

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#85 2016-12-16 13:43:21

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#86 2016-12-16 15:15:26

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#87 2016-12-20 20:47:49

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#88 2016-12-22 07:29:19

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#89 2016-12-26 09:02:24

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#90 2016-12-26 12:30:42

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#91 2016-12-28 07:13:02

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#92 2016-12-28 12:02:50

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#93 2016-12-28 16:36:45

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#94 2016-12-28 18:17:09

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#95 2016-12-29 15:54:16

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#96 2016-12-29 18:21:05

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#97 2016-12-29 18:55:54

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#98 2016-12-29 19:00:02

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#99 2016-12-29 19:04:43

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#100 2016-12-29 20:11:08

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

Board footer