RK3328 Kernel

[TonyMac32]

Yes, I'm looking at that specific Bluetooth code as well, honestly I can't get it to behave with the uart.  That could be my fault, I'll need to keep messing with it.  Right now it simply won't sync up.

[Xalius]

Pine64 uses the same RTL8723BS module and we got BT working more or less reliably now. There are some versions of the BT firmware loader floating around (Iwfinger, hadess, ...) but NextThingCo seems to have the latest version for the RTL8723DS, which also works with CS and BS though...

 

Check out:

 

https://github.com/ayufan-pine64/linux-build/blob/master/Makefile#L49 - build the rtk_hciattach firmware loader, loads FW over UART and attaches it to the BT stack

 

https://github.com/ayufan-pine64/linux-build/tree/master/package/root/lib/firmware/rtlbt - needed firmware files

 

https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/rtk-hciattach.service - systemd service

 

 

[Myy]

Interesting. I'll see if Tinkerboarders are able to use that one. Still, I didn't know that you had to load the firmware using the UART protocol.

 

[Xalius]

Do not forget to actually lift the BT reset GPIO, on the Pine64 that is done via 'rfkill unblock all' or 'rfkill unblock xxx' otherwise the uart of the BT part will not answer and you just get a 'sync timeout'  from the firmware loader...

[Myy]

Ah ! I didn't know. I'll let tinkerboarders try this command and see if this unblock the situation

[TonyMac32]

Good info!  That was why I mentioned checking the 4.4 kernel, since they did so much hackery, I seem to remember some BT messages in the dmesg, but didn't know about the hci attach "artwork" at the time. 

 

[edit]

 

Well, on the 4.4 kernel, something different happens when you try to use hci attach....   I got a soft lockup and crashed the machine! 

As for dmesg:

[   17.144121] [BT_RFKILL]: ENABLE UART_RTS
[   17.254095] [BT_RFKILL]: DISABLE UART_RTS
[   17.254126] [BT_RFKILL]: bt turn on power

So it toggles the power using whatever magical software the Rockchip engineers created.  I'll work on debugging the crash.

 

[TonyMac32]

Off the current stream of consciousness, but I ran iperf3 just for kicks, kernel 4.12:

 

Ethernet:

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   110 MBytes   927 Mbits/sec    0    682 KBytes
[  4]   1.00-2.00   sec   113 MBytes   946 Mbits/sec    0    682 KBytes
[  4]   2.00-3.00   sec   112 MBytes   936 Mbits/sec    0    682 KBytes
[  4]   3.00-4.00   sec   113 MBytes   947 Mbits/sec    0    682 KBytes
[  4]   4.00-5.00   sec   112 MBytes   938 Mbits/sec    0    682 KBytes
[  4]   5.00-6.00   sec   112 MBytes   940 Mbits/sec   11    409 KBytes
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec    8    342 KBytes
[  4]   7.00-8.00   sec   112 MBytes   944 Mbits/sec    0    481 KBytes
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec    9    444 KBytes
[  4]   9.00-10.00  sec   112 MBytes   936 Mbits/sec   12    356 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec   40             sender
[  4]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec                  receiver

 

WiFi:

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.57 MBytes  46.7 Mbits/sec    0    277 KBytes
[  4]   1.00-2.00   sec  4.91 MBytes  41.2 Mbits/sec    0    379 KBytes
[  4]   2.00-3.00   sec  5.24 MBytes  43.9 Mbits/sec    0    451 KBytes
[  4]   3.00-4.00   sec  5.22 MBytes  43.8 Mbits/sec    0    482 KBytes
[  4]   4.00-5.00   sec  5.04 MBytes  42.3 Mbits/sec    0    508 KBytes
[  4]   5.00-6.00   sec  5.12 MBytes  43.0 Mbits/sec    0    508 KBytes
[  4]   6.00-7.00   sec  5.15 MBytes  43.2 Mbits/sec    0    533 KBytes
[  4]   7.00-8.00   sec  4.52 MBytes  37.9 Mbits/sec    0    533 KBytes
[  4]   8.00-9.00   sec  5.61 MBytes  47.0 Mbits/sec    0    533 KBytes
[  4]   9.00-10.00  sec  5.20 MBytes  43.6 Mbits/sec    0    533 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  51.6 MBytes  43.3 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  50.8 MBytes  42.6 Mbits/sec                  receiver

Using a proper antenna should help I would guess, but I won't pretend to know what an rtl8723bs is actually capable of, especially with the older driver software being used by the mainline kernel.

 

[edit]  using kernel 4.4:

 

Ethernet:

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.01   sec  85.0 MBytes   705 Mbits/sec    0    206 KBytes
[  4]   1.01-2.00   sec   112 MBytes   949 Mbits/sec    0    612 KBytes
[  4]   2.00-3.00   sec   113 MBytes   945 Mbits/sec    0    612 KBytes
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    612 KBytes
[  4]   4.00-5.00   sec   112 MBytes   938 Mbits/sec    0    612 KBytes
[  4]   5.00-6.00   sec   112 MBytes   942 Mbits/sec    0    612 KBytes
[  4]   6.00-7.00   sec   112 MBytes   943 Mbits/sec    0    612 KBytes
[  4]   7.00-8.00   sec   112 MBytes   943 Mbits/sec    0    612 KBytes
[  4]   8.00-9.00   sec   112 MBytes   940 Mbits/sec    0    612 KBytes
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec    0    612 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   918 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.07 GBytes   917 Mbits/sec                  receiver

 

WiFi:

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  6.30 MBytes  52.9 Mbits/sec    0    269 KBytes
[  4]   1.00-2.00   sec  6.05 MBytes  50.7 Mbits/sec    0    332 KBytes
[  4]   2.00-3.00   sec  6.28 MBytes  52.7 Mbits/sec    0    349 KBytes
[  4]   3.00-4.00   sec  5.85 MBytes  49.0 Mbits/sec    0    386 KBytes
[  4]   4.00-5.00   sec  6.09 MBytes  51.1 Mbits/sec    0    450 KBytes
[  4]   5.00-6.00   sec  5.98 MBytes  50.2 Mbits/sec    0    496 KBytes
[  4]   6.00-7.00   sec  5.85 MBytes  49.1 Mbits/sec    0    496 KBytes
[  4]   7.00-8.00   sec  5.95 MBytes  49.9 Mbits/sec    0    523 KBytes
[  4]   8.00-9.00   sec  6.01 MBytes  50.4 Mbits/sec    0    549 KBytes
[  4]   9.00-10.00  sec  6.04 MBytes  50.7 Mbits/sec    0    587 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  60.4 MBytes  50.7 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  59.8 MBytes  50.2 Mbits/sec                  receiver

I tried the Ethernet one a few times to verify the slow start.  For Wifi, the board's physical location/orientation were not changed.

[TonyMac32]

This is the output of the hci_attach program and the resulting kernel panic:  https://pastebin.com/0cgqBkGC

 

the recommended one from NextThingCo got to "Device setup complete" and then crashed the same way.

 

Time to go hunting:

[    3.146549] [BT_RFKILL]: Enter rfkill_rk_init
[    3.146798] of_get_named_gpiod_flags: parsed 'uart_rts_gpios' property of node '/wireless-bluetooth[0]' - status (0)
[    3.146806] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: uart_rts_gpios = 139.
[    3.146815] of_get_named_gpiod_flags: can't parse 'BT,power_gpio' property of node '/wireless-bluetooth[0]'
[    3.146831] of_get_named_gpiod_flags: parsed 'BT,reset_gpio' property of node '/wireless-bluetooth[0]' - status (0)
[    3.146837] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,reset_gpio = 149.
[    3.146852] of_get_named_gpiod_flags: parsed 'BT,wake_gpio' property of node '/wireless-bluetooth[0]' - status (0)
[    3.146858] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_gpio = 146.
[    3.146872] of_get_named_gpiod_flags: parsed 'BT,wake_host_irq' property of node '/wireless-bluetooth[0]' - status (0)
[    3.146877] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_host_irq = 151.
[    3.146886] [BT_RFKILL]: bluetooth_platdata_parse_dt: clk_get failed!!!.
[    3.146937] [BT_RFKILL]: Request irq for bt wakeup host
[    3.146964] [BT_RFKILL]: BT_WAKE_HOST IRQ fired
[    3.146987] [BT_RFKILL]: ** disable irq
[    3.147108] [BT_RFKILL]: bt_default device registered.

 

[plasta-blaster]

On 31/05/2017 at 8:42 AM, chrisf said:

NF_CONNTRACK_NETBIOS_NS is not configured in the kernel build

https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip-default.config#L780

 

Hey 

 

I just noticed that ufw is no longer running/enabled as above error.

 

Is this likely to be fixed anytime soon?

In the mean time Is there a firewall you guys are using that works? I tried arno but could not get it run properly.

 

I guess Ill have to edit iptables manually:-(

[TonyMac32]

1 hour ago, plasta-blaster said:

Hey 

 

I just noticed that ufw is no longer running/enabled as above error.

 

Is this likely to be fixed anytime soon?

In the mean time Is there a firewall you guys are using that works? I tried arno but could not get it run properly.

 

I guess Ill have to edit iptables manually:-(

Which kernel are you using?  Did you switch kernels?  I haven't messed with that configuration at all, so I'm a little confused.

[plasta-blaster]

Just now, TonyMac32 said:

Which kernel are you using?  Did you switch kernels?  I haven't messed with that configuration at all, so I'm a little confused.

4.4.66-rockchip

 

[plasta-blaster]

I had a load of crap in the iptables which I have cleared out. and installed iptables-persistent which worked.

 

I installed arno and ran it again but it failed on the reconfigure, it turns out arno adds a load of stuff and I cant be bothered to work it out so I guess its back to iptables persistent!

[Tido]

9 hours ago, plasta-blaster said:

4.4.66-rockchip

look here https://forum.armbian.com/index.php?/topic/3327-asus-tinkerboard/&do=findComment&comment=32887

 

[TonyMac32]

Can anyone with a MiQi verify they can correctly reboot using kernel 4.4 ?  @Myy reported that the attempt to implement the Tinker Board reboot change on the 4.12 kernel made the MiQi have reboot issues.  @IgorThis change has not been rolled out on the 4.12 kernel at Armbian, it has been so far unsuccessful, the device is hanging in BootROM mode because the SoC bootloader does not support high speed SD (1.8V) and the kernel does not reset everything before going for reboot.  Another fun Tinker Board issue, one that I'm looking at other devices to see if there are solutions.  Oh, to have my $60 back...    That said, if anyone has an extra MiQi laying about...

 

[patrick-81]

Hello,

I have a problem with wifi access point. I can define the access point but can't connect to it from any device. The status switch between Registered and try to connect.

Otherwise the wifi can connect to my wifi router.

I have the same result either with the 4.4.71 kernel or the 4.12 kernel.

Might it be a symptom of wifi hardware disease ?

 

[Myy]

18 hours ago, TonyMac32 said:

Can anyone with a MiQi verify they can correctly reboot using kernel 4.4 ?

I'll try to give it a shot this week-end, if nobody tested that before.

[TonyMac32]

Thanks @Myy, There are obviously some major differences between 4.4 and 4.12, but I want to make sure.

[patrick-81]

On 15/06/2017 at 1:34 PM, patrick-81 said:

Hello,

I have a problem with wifi access point. I can define the access point but can't connect to it from any device. The status switch between Registered and try to connect.

Otherwise the wifi can connect to my wifi router.

I have the same result either with the 4.4.71 kernel or the 4.12 kernel.

Might it be a symptom of wifi hardware disease ?

 

I found the reason of the problem,

It looks like there is a regression on the wifi support in the 5.30 version with 4.4.71 kernel. The 5.27 4.4.70 wifi works fine. Hope that the 5.31 will fix this.

I think the problem is deeper than it seems. The wifi handshake between my Dell 6440 PC and the TinkerBox fail. If I use a TP-Link USB wifi dongle the handshake succeed and I can connect to the Tinkerboard.

The handshake between my Chineese tablet under Android 4.4.4 fail. My smartphone which is under Android 5.1 connect to the Tinker, my other smartphone under Android 5.1.1 connect too.

Might it be a wifi firmware problem ? A network-manager problem ? Might it could be useful to manually define a static hotspot in /etc/network/interfaces with a dhcp server ?

Would be nice to have an answer from you.

 

 

[Frostbyte]

Any chance someone could include support for the tinker board on this?
I've already asked on the adafruit forums and they shot me down.

I tried meddling around to see if I can do it myself, but my coding skills are not up to par.. my brain got fried once I reached the actual GPIO parts.

[cyberk]

Hi, can someone make a separate thread for recommended accessories for the tinkerboard, specifically heatsinks and cooling? Much appreciated!

[Myy]

On 2017/6/16 at 7:14 AM, patrick-81 said:

The handshake between my Chineese tablet under Android 4.4.4 fail. My smartphone which is under Android 5.1 connect to the Tinker, my other smartphone under Android 5.1.1 connect too.

Might it be a wifi firmware problem ? A network-manager problem ? Might it could be useful to manually define a static hotspot in /etc/network/interfaces with a dhcp server ?

Would be nice to have an answer from you.

 

 

 

Could it be a protocol issue ? Like the Android smartphone supports WiFi protocols that the tablet doesn't ? Are all devices communicating through the same channel ? With the same frequency (2.4 Ghz) ?

 

Also, is the Tinker powered correctly ? Underpowered boards might have issues when it comes to WiFi stability (or stability overall).

 

That said, to analyse such issues Wireshark and the Aircrack-ng suite might be welcome, in order to capture raw 802.11 packets and have a clear idea about what's going on in the bad case, and what's going on in the good case.

 

[Myy]

11 hours ago, Frostbyte said:

Any chance someone could include support for the tinker board on this?
I've already asked on the adafruit forums and they shot me down.

I tried meddling around to see if I can do it myself, but my coding skills are not up to par.. my brain got fried once I reached the actual GPIO parts.

Well, I guess that the most difficult part will be to know which GPIO you should read to get informations about the temperature... of the CPU I guess ? Or is that the main room temperature ?

Anyway, same thing for the humidity sensor GPIO.

 

Once you have these informations, the rest should be easier.

[Frostbyte]

1 hour ago, Myy said:

Well, I guess that the most difficult part will be to know which GPIO you should read to get informations about the temperature... of the CPU I guess ? Or is that the main room temperature ?

Anyway, same thing for the humidity sensor GPIO.

 

Once you have these informations, the rest should be easier.

Nah they don't read off of the CPU. DHT11/DHT22 are environmental sensors that you connect to the GPIO.
They provide temperature and humidity readings wherever you place them.

[TonyMac32]

For the Ethernet MAC problem, https://github.com/TinkerBoard/debian_kernel/commit/2d84377b2c0541d9491ab33f936832634f5db123

 

It messes with stuff I think it shouldn't, and I think it has a chance to break the MiQi.  My love of puzzles is beginning to wear thin.

 

 

@Myy, did you have a chance to see if the reboot hacks broke the MiQi reboot or not?  No one else has spoken up so far, but I want to be certain.

[chrisf]

4 hours ago, Frostbyte said:

Nah they don't read off of the CPU. DHT11/DHT22 are environmental sensors that you connect to the GPIO.
They provide temperature and humidity readings wherever you place them.

How reliable did you find the adafruit library? Looking at the source code it seems a bit flakey. Reads would fail or return garbage if another process took over the CPU while it was reading.

The timing is reliant on busy-waiting and magic numbers in loops as well.

 

You'd be better off switch to an i2c sensor like BMP085 or something

 

Apparently there is a DHT11 kernel driver you could try

https://github.com/torvalds/linux/blob/master/drivers/iio/humidity/dht11.c

 

Googling around came up with this thread:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=113988

 

Which also led to

http://abyz.co.uk/rpi/pigpio/examples.html#pdif2_DHTXXD

 

[Kwiboo]

6 hours ago, TonyMac32 said:

For the Ethernet MAC problem, https://github.com/TinkerBoard/debian_kernel/commit/2d84377b2c0541d9491ab33f936832634f5db123

 

Is this still a problem? I have never had any issue with getting persistent ethernet mac address since I started using a u-boot build that included https://github.com/u-boot/u-boot/commit/ecc3bd73b35398d8337096b19493028a29ed038e

 

@Myy @TonyMac32 I was able to get bluetooth working on LibreELEC with Rockchip LSK 4.4.70 kernel using a pre-compiled rtk_hciattach taken from https://github.com/rockchip-linux/rk-rootfs-build/tree/master/overlay-firmware

See https://github.com/Kwiboo/LibreELEC.tv/commit/e4af07d34b0a919adb3d1d3ff2f32c08cf7511b7 for the changes I made, still not sure if the chip_enable_h related changes was necessary or not.

Another change that is not part of the commit diff is that I now have CONFIG_RFKILL_GPIO enabled in my kernel config.

[Frostbyte]

3 hours ago, chrisf said:

How reliable did you find the adafruit library? Looking at the source code it seems a bit flakey. Reads would fail or return garbage if another process took over the CPU while it was reading.

The timing is reliant on busy-waiting and magic numbers in loops as well.

 

You'd be better off switch to an i2c sensor like BMP085 or something

 

Apparently there is a DHT11 kernel driver you could try

https://github.com/torvalds/linux/blob/master/drivers/iio/humidity/dht11.c

 

Googling around came up with this thread:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=113988

 

Which also led to

http://abyz.co.uk/rpi/pigpio/examples.html#pdif2_DHTXXD

 

I just happened to use it on the RPi3 simply because it was more accessible and easy to install. My sensor is a DHT22.
I could try the code in the last link you provided, but I'm afraid that it won't work as it's not designed for the tinkerboard.

I had a read on the available ASUS.GPIO code here and here, to see if I can get any hints on how I can modify the pdif2_DHTXXD to work with the tinkerboard, but I just can't understand anything..

[TonyMac32]

3 hours ago, Kwiboo said:

 

Is this still a problem? I have never had any issue with getting persistent ethernet mac address since I started using a u-boot build that included https://github.com/u-boot/u-boot/commit/ecc3bd73b35398d8337096b19493028a29ed038e

 

@Myy @TonyMac32 I was able to get bluetooth working on LibreELEC with Rockchip LSK 4.4.70 kernel using a pre-compiled rtk_hciattach taken from https://github.com/rockchip-linux/rk-rootfs-build/tree/master/overlay-firmware

See https://github.com/Kwiboo/LibreELEC.tv/commit/e4af07d34b0a919adb3d1d3ff2f32c08cf7511b7 for the changes I made, still not sure if the chip_enable_h related changes was necessary or not.

Another change that is not part of the commit diff is that I now have CONFIG_RFKILL_GPIO enabled in my kernel config.

Thanks Kwiboo,  I think the chip_enable_h related stuff involves some hardware that was not being reset on reboot and causing problems, I'll take a look at the pre-compiled rtk_hciattach for the 4.4 kernel here, as for 4.11/12, I think it will take more work. 

[Myy]

@TonyMac32 I gave it a shot with the latest linux-image-rockchip and DTB, however rebooting just froze the machine (´・ω・`　)

The green light is not blinking too.

I guess that adding a special kernel option might be required. Something like rockchip.TBrebootfix=1 and add check this option in the reboot fix function, so that it doesn't impact the others boards.

 

@Kwiboo Interesting ! Could you paste your dmesg so that I know what kind of messages I should expect from the driver ?

 

 

[TonyMac32]

1 minute ago, Myy said:

@TonyMac32 I gave it a shot with the latest linux-image-rockchip and DTB, however rebooting just froze the machine (´・ω・`　)

The green light is not blinking too.

I guess that adding a special kernel option might be required. Something like rockchip.TBrebootfix=1 and add check this option in the reboot fix function, so that it doesn't impact the others boards.

 

Ugh.