Device-tree improvements

This is for any ARMv7 device that we do not officially support.

Re: Device-tree improvements

Postby TheSaint » Mon Jan 14, 2019 6:17 am

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.
Code: Select all
$ 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.
Code: Select all
$ 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.
TheSaint
 
Posts: 310
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Mon Jan 14, 2019 1:00 pm

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 ...
summers
 
Posts: 679
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Mon Jan 14, 2019 11:40 pm

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.
TheSaint
 
Posts: 310
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Tue Jan 15, 2019 11:48 am

Bluetooth in the kernel should be enabled using two configurations:

Code: Select all
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
Code: Select all
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
Code: Select all
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 ...
summers
 
Posts: 679
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Jan 15, 2019 2:27 pm

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
 
Posts: 310
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Thu Jan 24, 2019 12:27 am

Latest kernel update
Code: Select all
Linux alarm 4.20.2-2-ARCH #1 SMP PREEMPT Fri Jan 18 03:39:51 UTC 2019 armv7l GNU/Linux

Alas no changes :cry:
TheSaint
 
Posts: 310
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sat Jan 26, 2019 7:44 pm

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.
summers
 
Posts: 679
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Sun Jan 27, 2019 12:01 am

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).
TheSaint
 
Posts: 310
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby lategoodbye » Sun Jan 27, 2019 3:43 pm

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
lategoodbye
 
Posts: 40
Joined: Sat Dec 29, 2018 1:24 am

Re: Device-tree improvements

Postby summers » Sun Jan 27, 2019 8:20 pm

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:
Code: Select all
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:
Code: Select all
&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
Code: Select all
      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:
Code: Select all
&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>;
               };
};
Last edited by summers on Sun Feb 03, 2019 7:22 pm, edited 1 time in total.
summers
 
Posts: 679
Joined: Sat Sep 06, 2014 12:56 pm

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 0 guests