Device-tree improvements

[TheSaint]

I just planned to get the latest kernel running. Unfortunately these days I'm busy for a little help to my friend to program a MCU.
I'll get back to you ASAP. Perhaps in few hours.

EDIT
I updated the system and kernel. In few words, your make is the BEST. The system started latest kernel flawlessly.
Then, I tried the new dtb rk2388-tinker-s.dtb, from mainline. It boot smoothly, but the WiFi is not there and the NIC also fails to do the simplest things.
$this->bbcode_second_pass_code('', '$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 88:d7:f6:c2:f1:42 brd ff:ff:ff:ff:ff:ff
=======================================
$ lsmod
Module Size Used by
realtek 16384 1
snd_soc_hdmi_codec 16384 1
dw_hdmi_cec 16384 0
dw_hdmi_i2s_audio 16384 0
snd_soc_simple_card 16384 0
snd_soc_simple_card_utils 16384 1 snd_soc_simple_card
rockchip_rga 20480 0
v4l2_mem2mem 24576 1 rockchip_rga
snd_soc_rockchip_i2s 16384 2
videobuf2_dma_sg 16384 1 rockchip_rga
videobuf2_memops 16384 1 videobuf2_dma_sg
videobuf2_v4l2 24576 2 v4l2_mem2mem,rockchip_rga
snd_soc_rockchip_pcm 16384 1 snd_soc_rockchip_i2s
videobuf2_common 45056 3 v4l2_mem2mem,videobuf2_v4l2,rockchip_rga
snd_soc_core 159744 5 snd_soc_rockchip_i2s,snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_rockchip_pcm,snd_soc_simple_card
ac97_bus 16384 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
rk_crypto 24576 0
dw_wdt 16384 0
snd_usb_audio 188416 0
snd_usbmidi_lib 28672 1 snd_usb_audio
snd_hwdep 16384 1 snd_usb_audio
evdev 24576 2
joydev 20480 0
snd_rawmidi 32768 1 snd_usbmidi_lib
snd_seq_device 16384 1 snd_rawmidi
snd_pcm 94208 4 snd_usb_audio,snd_pcm_dmaengine,snd_soc_hdmi_codec,snd_soc_core
snd_timer 32768 1 snd_pcm
pwm_rockchip 16384 0
dwmac_rk 28672 0
rockchipdrm 94208 0
stmmac_platform 20480 1 dwmac_rk
analogix_dp 32768 1 rockchipdrm
stmmac 126976 2 stmmac_platform,dwmac_rk
dw_hdmi 32768 2 rockchipdrm,dw_hdmi_i2s_audio
rockchip_saradc 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
sch_fq_codel 20480 2
crypto_user 20480 0
ip_tables 28672 0
x_tables 32768 1 ip_tables
')
Here's what journalctl -b said during the boot.
Regarding the SD card detection, still best the parameters we put earlier.
$this->bbcode_second_pass_code('', '$ cat /boot/boot.txt
# After modifying, run ./mkscr

setenv rootcmd "LABEL=TB-MM-root"
setenv fdtfile rk3288-tinker-s.dtb
setenv bootargs "console=ttyS2,115200n8 root=${rootcmd} rw rootwait"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt resize
fdt set /dwmmc@ff0c0000 broken-cd
# fdt set /usb@ff500000 no-relinquish-port
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
bootz ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi')
Summarizing, I'll put back rk3288-tinkerS.dtb, which gives the WiFi working with the latest kernel. Perhaps still crash when starting SoftAP with the module 80211.
BTW, I just noted that the 80211 is not loaded, even the NIC wants it.

If you need, I'll post the data when I boot with your rk3288-tinkerS.dtb.

[summers]

Ta thanks for that. With the rk3288-tinker-s.dtb did you try booting from eMMC, and then ejecting the sd card to see if you get the sd errors?

Missing wifi and bluetooth is known, the asus device tree, mainline hated. I'm just going though it now, getting to speed with what it did. Much of the problem is it invented fictional nodes; and no way for this to be mainlined. So changing it to mainline set up, it should make some things better (e.g. the bluetooth set up is better in mainline). Anyway I'm still getting my head around what mainline will allow - means needing to think device tree in a mainline way ...

Ah wait read your above more clearly - so you still need the "broken-cd". OK I'll make sure that is added ...

[TheSaint]

There's a module parameter to set the bluetooth working, which is BT_COEX. But not yet feasible in all the used dtb.
I'm curious to know why the debian derived are mostly keen to use miniarm dtf.

[summers]

Bluetooth in the kernel should be enabled using two configurations:

$this->bbcode_second_pass_code('', 'config BT_HCIUART_3WIRE
bool "Three-wire UART (H5) protocol support"
depends on BT_HCIUART
depends on BT_HCIUART_SERDEV
help
The HCI Three-wire UART Transport Layer makes it possible to
user the Bluetooth HCI over a serial port interface. The HCI
Three-wire UART Transport Layer assumes that the UART
communication may have bit errors, overrun errors or burst
errors and thereby making CTS/RTS lines unnecessary.

Say Y here to compile support for Three-wire UART protocol.')
and
$this->bbcode_second_pass_code('', 'config BT_HCIBTUSB_RTL
bool "Realtek protocol support"
depends on BT_HCIBTUSB
select BT_RTL
default y
help
The Realtek protocol support enables firmware and configuration
download support for Realtek Bluetooth controllers.

Say Y here to compile support for Realtek protocol.')
Am not sure what the module will get called, something like hci_h5 ... or maybe $this->bbcode_second_pass_code('', 'hci_uart')

I think debium use the miniarm dtb probably becuase it works and has most things enabled. The problem with miniarm, is that the dts is very none standard - no way it will be accepted in mainline. Its clear to me that mainlining it is a real hassle - need at least basic understanding of all parts of the device tree. E.g. one needs to power the bluetooth chip, and that is done in one part of the device tree, needs to ensure discrete lines are pulled the right way to bring the chip up, finally need a driver that talks across the uart. Doing all these as they are meant to be done is a hassle in mainline, and so I suspect no one at debian can be bothered to mainline it.

Really the problem is with asus, they pushed out the patches to make miniarm dtb work, without any thought as to how to mainline it. As they had understanding of the hardware, they could have done it in a way acceptable to mainline, which would have been more effort - but means it would be supported. Whereas to take miniarm and mainline it, takes additional effort - need to understand the hardware from the miniarm dts, before translating into mainline ...

[TheSaint]

Keeping your dtb is the most suited. I just wonder what is the cause to mess up with 80211 module. This is primarily caused by hostapd.
In the linux word, it's well know that we must wait for some time before the things get well known. So as it's for my laptop, which still doesn't fully function after 6 years, then the Tinker Board might follow a similar sort.

[TheSaint]

Latest kernel update$this->bbcode_second_pass_code('', 'Linux alarm 4.20.2-2-ARCH #1 SMP PREEMPT Fri Jan 18 03:39:51 UTC 2019 armv7l GNU/Linux')
Alas no changes

[summers]

I've given up on trying to mainline the bluetooth and WiFi for the tinkerboard. Its taking too much time, and is clear I don't have the skills or time to learn, more details:

https://www.spinics.net/lists/linux-bluetooth/msg78831.html

I may keep doing it slowly in the background, but no point in holding your breath; project is essentially stalled.

[TheSaint]

Hey Summers, I don't (won't) blame anything, you gave me the best. I'm happy with it.

After all, no many have knocked on ALarm doors for their TB(s).

[lategoodbye]

Hi guys,
i followed the discussion about enabling wifi and BT on the Tinkerboard. As i enabled these parts on the RPi for mainline, maybe i can help you.

But i have some questions because i don't have this hardware:
Why are these dt-bindings describe Realtek chipset but the miniarm dts define an ap6212 module which uses a Broadcom chipset?
Did you know how wifi is connected to the SoC the miniarm dts suggests it's SDIO but the mainline dts doesn't enable this interface?
Did you try to enable SDIO interface in mainline devicetree?

Regards
Stefan

[summers]

As I remember it one of the earliest device tree blobs I did for TheSaint was based on the mainline TB dts, with the eMMC enable one one sdio port, and another sdio port enabled for the wifi. This brought up the eMMC, but not the wifi.

Now if you look at the asus patch for miniarm that added wifi: https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678 its has the comment about power control and pin control. IIRC reading elsewhere, the power for the realtek wifi/bt chi comes from the rk808 chip, and you needed to up the voltage or something to get the device to work. So wifi at least needs pins being brought up in the right way, and also setting up the rk808 chip in the right way.

Bluetooth is similarly complicated, that goes via a UART. The kernel driver (according to mainline maintainer) is hci-h5 - a 3wire interface. Now according to the data sheet http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf, the BT uart as well as RX and TX, also has CTS, as well as "wake" in both directions (e.g. interrupts). This means in the uart part of the device tree you want to bring up at least CTS, but the miniarm dts also brings up RTS (but the chip doesn't have a pin for this, just an uncertain BT_DIS#). The BT_DIS# pin, according to the rest of the data sheet sounds like it needs to be pulled to bring up BT.

Now all of this interaction needs defining in the device tree, and these kind of interdependence are beyond my comfort zone.

The device tree done by asus, is *very* not standard; so at best you can just take hints from it over how the TB(S) is wired. Then taking to mainline, it needs rewriting in the way acceptable to mainline.

So from my position, until I find the time, to learn about how to set up these dependencies - I won't be in a position to mainline the code. I like you don't have one of these boards - so I can only test code by dropping on TheSaint - and this can't be done continuously.

[Edit] Actually guess an example helps makes the difficulties clear. Take the ASUS bluetoooth:
$this->bbcode_second_pass_code('', 'wireless-bluetooth {
compatible = "bluetooth-platdata";
uart_rts_gpios = <&gpio4 19 GPIO_ACTIVE_LOW>;
pinctrl-names = "default","rts_gpio";
pinctrl-0 = <&uart0_rts>;
pinctrl-1 = <&uart0_gpios>;
BT,reset_gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
BT,wake_gpio = <&gpio4 26 GPIO_ACTIVE_HIGH>;
BT,wake_host_irq = <&gpio4 31 GPIO_ACTIVE_HIGH>;
status = "okay";
};

&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_xfer>, <&uart0_cts>;
status = "okay";
};')
Now in mainline code this becomes something like:
$this->bbcode_second_pass_code('', '&uart0 {
status = "okay";
rts-gpios = <&gpio4 19 GPIO_ACTIVE_LOW>;
bluetooth {
compatible = "realtek,rtl8723bs-bt";
reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
wake-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
wake-host-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;
};
};
')
Now to get this far you need to read: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/serial/serial.txt and https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/gpio/gpio.txt and http://events17.linuxfoundation.org/sites/events/files/slides/serdev-elce-2017-2.pdf. Need to have read the asus device tree and understand what it is saying.

This gets complaints that the driver doesn't use reset-gpios, wake-gpios and wake-host-gpios. wake-host-gpios should probably be an interrupt, even though its attached to a gpio pin.

You can quibble is the chip cts connected to the cpu uart0-rts or to <&gpio4 19>? When feeling devious you brows the rk3288 device tree: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288.dtsi and find $this->bbcode_second_pass_code('', ' uart0 {
uart0_rts: uart0-rts {
rockchip,pins = <4 19 RK_FUNC_1 &pcfg_pull_none>;
};
};') and so the ASUS device tree has named something twice ...

You have to wonder where cts has got to; why doesn't the chip have an rts?

None of this explains how to power the device, that is needed else where in the device tree, but with handles into this code. The device sounds like its needs a BT_DIS# pin pulling, now that may be done via the "reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;" but thats hard to say without the schematic.

And so you can see the can of worms ...

wifi is just as bad ...

[reedit] Ah http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf says that rts is on pin 41. Now asus device tree doesn't reference this. But I'd guess its on uart0_cts. This means we can use:
$this->bbcode_second_pass_code('', '&uart0 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
uart-has-rtscts;
bluetooth {
compatible = "realtek,rtl8723bs-bt";
reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
wake-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
wake-host-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;
};
};
')