Add device tree for TF101

[mnidza]

Add initial working version of device tree for ASUS EeePad Transformer TF101.
Basically just copy Ventana device tree and add WiFi and touchscreen to it.

[clamor-s]

I wouldn't recommend to merge this @digetx, transformers team is working on tf101 and we still have problems with it. This tree is not even partially complete.

@mnidza are you sure this tree has at least emmc/sdcard working, or maybe networking?

P. S. My tf101 tree and it still has issues

[mnidza]

@clamor95 I tested it with my unit, and WiFi works for me (with external firmware). I've been using it with root file system on SD card, so I guess SD works too. As for the MMC, I had to use this patch to make partition table accessible, but did not include it here since I'm not sure if how hacky this solutions is, and I guess the tablet can be functional even with SD card only.

If it's not already obvious, I'm not an expert in this, and this is just a collection of solutions I picked up from various versions of TF101 kernel I could find (based on various versions of the mainline kernel, starting from 3.10) and made them work for my TF101. I created his PR after @digetx asked some people with working TF101s in another thread to share what they have. I'm aware that the device tree is not complete, but maybe it's still useful for others to build upon.

[digetx]

@mnidza @clamor95 Could you please enumerate what works and what not?

The device-trees look okay to me, there are couple things that need to be improved, but they are minor. It should be fine to correct and extend the DT with additional patches, until DT will become fully completed.

The MMC patch shouldn't be needed by grate-kernel if you have CONFIG_TEGRA_PARTITION=y. If it doesn't work, then please let me know.

[clamor-s]

@digetx I don't have tf101 on hand and I can tell only about things my testers told me. Since @mnidza physically has tf101 let he works on it. I will shut all development for tf101 from my side.

[digetx]

It depends on how much @mnidza is wanting to get involved. If this will be a one-time contribution, then we still will need somebody to continue the work.

[antonialoytorrens]

@clamor95 I tested it with my unit, and WiFi works for me (with external firmware). I've been using it with root file system on SD card, so I guess SD works too. As for the MMC, I had to use this patch to make partition table accessible, but did not include it here since I'm not sure if how hacky this solutions is, and I guess the tablet can be functional even with SD card only.

For some reason I cannot get to boot my TF101 from SD Card. @mnidza I'm using your tf101 branch, tegra_defconfig as config file and gcc10. If you don't mind, could you explain how to build it (as I'm not an expert as well) and get it running?

P.D.: My tablet is sbk1 version, I don't know if it matters at all.

[digetx]

That might be because device-tree doesn't have aliases for MMC, thus sdcard may come up under a different name, depending on a probe order of the drivers.

[digetx]

If there are no objections, then I'll merge this PR later today and fix up the missing aliases and etc.

[digetx]

@mnidza @clamor95 @antonialoytorrens @fuzzy7k I'll merge this now, please let me know if you'll spot any problems and please open a new PR if you'll have more stuff to add or fix, thanks!

[mnidza]

Thanks @digetx ! As you can see by the frequency of my responses, I can't commit (and probably don't have the skills at this point) to contribute regularly at your pace, but I guess I can help with testing since I have the device. I don't have the keyboard/dock though.

@antonialoytorrens I'm attaching a dockerfile describing the my build tools.
dockerfile_xenial.txt
Within this docker container I just do the standard

export CROSS_COMPILE="arm-none-eabi-" ARCH="arm" && make tegra_defconfig && make && make INSTALL_MOD_PATH=<path> modules_install

For booting from SD card I use u-boot built with ventana_defconfig and nvflashed onto the tablet.

[digetx]

Thank you! Please don't worry about the pace, any help will be good.

I looked through the downstream kernel and made quite a few changes to the device-tree, please pull the updated grate-kernel and let me know if it works or not.

[antonialoytorrens]

Thanks @digetx ! As you can see by the frequency of my responses, I can't commit (and probably don't have the skills at this point) to contribute regularly at your pace, but I guess I can help with testing since I have the device. I don't have the keyboard/dock though.

@antonialoytorrens I'm attaching a dockerfile describing the my build tools.
dockerfile_xenial.txt
Within this docker container I just do the standard

export CROSS_COMPILE="arm-none-eabi-" ARCH="arm" && make tegra_defconfig && make && make INSTALL_MOD_PATH=<path> modules_install

For booting from SD card I use u-boot built with ventana_defconfig and nvflashed onto the tablet.

Thank you very much! It's very useful.
In my case, I have the dock, so I can test with it too.

I'm trying to get PostmarketOS working on my TF101.
So, just a last question, @mnidza are you using latest u-boot? What command do you use to nvflash it?
It's this one (it doesn't work for me, by the way) ?
./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl u-boot.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync

[digetx]

Guys, I added support for memory frequency scaling to TF101. Please post a full kernel boot log once you'll manage to test the grate-kernel, thanks in advance.

[mnidza]

@antonialoytorrens Here is the u-boot source that I use; it's not the latest, but it's fairly recent. It is set up so that the kernel and the boot script are on SD card, so I can change the script without rebuilding u-boot. Here is my boot script: uEnv.txt. Nvflash command line is the same as yours. At the end I do get

waiting for bootloader to initialize
bootloader failed NvError 0x0
command failure: bootloader download failed

but it seems that the bootloader starts successfully nevertheless, and can be used to boot kernel during development. Of course, I think this does not actually flash the bootloader, just loads it into SDRAM temporarily for development purposes. I think you need to use --create to reflash all partitions (including bootloader partition) once you are happy with it.

[mnidza]

@digetx I think I caused confusion above by not making it clear that my device tree worked only when I rebased it on top of mainline kernel 5.12-rc4, and not grate-kernel. I tried testing your recent changes and it does not boot for me (the screen just goes dark). I tried both the version from PR and the version after some of your modifications, but I get the same result for both.

Any recommendation how to proceed? Any way to use the fact that it works in 5.12-rc4 to pin down where it breaks in grate-kernel?

[antonialoytorrens]

Thank you very much for your help @mnidza . Will test it that way.

Also, if you are in trouble, I suggest you to join #tegra channel on freenode.net for discussion.
And if you are comfortable using matrix.org channels, I suggest you to join #postmarketOS-on-transformers as well.

[digetx]

@mnidza That's likely because of the work-in-progress core power domain patches which require the device-tree to have the voltage regulator specified for the domain.

I added the power domain node in this commit: e350a1a I think you should be able to boot with yours original device-tree if you'll cherry-pick this commit. I also think that we could add a default stub regulator to the tegra20.dtsi and then it won't be a problem anymore, I'll do it later today.

[mnidza]

I tested the version at commit ca64561. It had the issue where the screen would go dark and WiFi would disconnect every few seconds; most of the time pushing the power button would restore it, but then it would go out again after a few seconds.

I found that removing the hall-sensor node (remove_hall_sensor.patch.txt) fixes this problem for me. From what I can see, the only difference in kernel logs for the version that does not work (commit ca64561) dmesg_not_working.txt and the one that does dmesg_working.txt is that the latter has a few ramoops: uncorrectable error in header lines.

[digetx]

@mnidza Thank you! Do you know whether TF101 supports lid detection at all or I just messed up the GPIO polarity? I borrowed the GPIO config from downstream kernel https://github.com/Kali-/tf101-kernel/blob/master/arch/arm/mach-tegra/board-ventana.c#L584

Could you please clarify what do you mean by a "not working" and "working" version? You're referring to the same ca64561 commit when saying working/not working, so it's not clear to me what works and what not.

The ramoops errors are okay, they are harmless and tell that there is no previous kernel log found in the memory buffer.

[mnidza]

Do you know whether TF101 supports lid detection

Nope. I suppose "lid" in this case has to do with keyboard/dock, and I don't have one.

Could you please clarify what do you mean by a "not working" and "working" version?

• By "not working" I mean commit ca64561, because it has the problem that I described with screen/WiFi.
• By "working" I mean commit ca64561 + the patch that removes hall-sensor (attached in my previous post). This one does not have the screen/WiFi problem. So far I have not found any problems with it, although I have not yet tested many things (like Bluetooth, GPS, volume buttons), because I don't yet have that many apps installed. I basically just verified the functionality that I used to have with mainline kernel + my original device tree.

[digetx]

Alright, thank you for the clarification! I'll remove the hall-sensor node on a next kernel update (probably later today), please give it a try. Please also note there are already couple more fixes in the recent versions of kernel and device-tree and I see in the logs that you're using the version from a day ago.

[mnidza]

I'm trying to test sound for the first time, and I'm using commit 5269af0 (master branch at the time of writing) for this. Currently I can't get any output from speakers using speaker-test from alsa-utils. Any ideas? I tried changing volume using hardware buttons. UI seems to react to this (terminal cursor blinks), but still no sound comes out.

dmesg output
speaker-test output

[clamor-s]

@mnidza you need ucm config or manually set correct state in alsamixer

[digetx]

@mnidza , the audio switches should be in off state by default. You may run alsamixer and turn on manually "Left/Right Speaker..." and etc.

You may take a look at UCM for Acer A500, but note that A500 uses a different audio routing for speakers, while headphones/headset should be the same.

[digetx]

@mnidza @antonialoytorrens Could you please tell me your full name and email address that I could add to the patches? I may try to send the battery patches that are related to TF101 for v5.14.

[mnidza]

@digetx I've updated my GitHub profile. You should be able to see both full name and email there. Hope that works.

[antonialoytorrens]

@mnidza @antonialoytorrens Could you please tell me your full name and email address that I could add to the patches? I may try to send the battery patches that are related to TF101 for v5.14.

In my case, my full name is Antoni Aloy Torrens and my email is [email protected].

[digetx]

Thank you!