TonyMac32 Posted June 11, 2017 Share Posted June 11, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Xalius Posted June 11, 2017 Share Posted June 11, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 11, 2017 Share Posted June 11, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Xalius Posted June 11, 2017 Share Posted June 11, 2017 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... 1 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 11, 2017 Share Posted June 11, 2017 Ah ! I didn't know. I'll let tinkerboarders try this command and see if this unblock the situation 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 12, 2017 Share Posted June 12, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 12, 2017 Share Posted June 12, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 12, 2017 Share Posted June 12, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
plasta-blaster Posted June 13, 2017 Share Posted June 13, 2017 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:-( 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 13, 2017 Share Posted June 13, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
plasta-blaster Posted June 13, 2017 Share Posted June 13, 2017 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 0 Quote Link to comment Share on other sites More sharing options...
plasta-blaster Posted June 13, 2017 Share Posted June 13, 2017 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! 0 Quote Link to comment Share on other sites More sharing options...
Tido Posted June 14, 2017 Share Posted June 14, 2017 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 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 15, 2017 Share Posted June 15, 2017 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... 1 Quote Link to comment Share on other sites More sharing options...
patrick-81 Posted June 15, 2017 Share Posted June 15, 2017 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 ? 1 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 15, 2017 Share Posted June 15, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 15, 2017 Share Posted June 15, 2017 Thanks @Myy, There are obviously some major differences between 4.4 and 4.12, but I want to make sure. 0 Quote Link to comment Share on other sites More sharing options...
patrick-81 Posted June 16, 2017 Share Posted June 16, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Frostbyte Posted June 19, 2017 Share Posted June 19, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
cyberk Posted June 20, 2017 Share Posted June 20, 2017 Hi, can someone make a separate thread for recommended accessories for the tinkerboard, specifically heatsinks and cooling? Much appreciated! 0 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Frostbyte Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
chrisf Posted June 20, 2017 Share Posted June 20, 2017 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 0 Quote Link to comment Share on other sites More sharing options...
Kwiboo Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Frostbyte Posted June 20, 2017 Share Posted June 20, 2017 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.. 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Myy Posted June 20, 2017 Share Posted June 20, 2017 @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 ? 0 Quote Link to comment Share on other sites More sharing options...
TonyMac32 Posted June 20, 2017 Share Posted June 20, 2017 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. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.