TonyMac32

Ugh.

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.

I guess I should clarify my point then. As I see it there are really 3/4 major devs here, who shoulder the majority of the work. There are a handful of others who support specific devices from varying angles and levels of capability, like myself. The use of a non-public subforum is not a "cloak and dagger" inner circle in this case, it's a simple measure to ensure some focused discussion about devices along the lines of vendor maturity, architecture, use case, dev workload, etc. If there is to be official support on Armbian's part, at the very least the core team should agree to take on that work, and then a public statement of that discussion and reasons to back it (Not just a "nope, that board sucks and we hate it"). Given this project's advance notice of many devices, it would still fullfill the goal of educating those who might want to go out and jump on a brand new device (Tinker Board? Some buyer's remorse over here). As for what to do with other things: how about a ".community" list or something analogous? This could handle those devices that are "same as except", or unproven vendors, TV boxes, etc. Still available to build, however tagged as "unofficial/community support" until either defined standards are met or there is a consensus that the remaining items are worth ignoring (micro-USB supply perhaps, or inadequate thermal solution, headless only, that kind of thing). It has its own traps and issues, but perhaps an idea. For releases, I agree some sort of release candidate system might need to be used, at present only people running nightlies or building themselves really test new kernels/etc, and that is a small group all things considered. A more general audience may try out a release candidate if published and provide useful feedback.

I agree. If a board is really an obvious emergent problem, a statement can be agreed upon and stickied in a read-only board support forum and linked to whenever anyone asks why we don't support such-and-such board. If something really changes, the situation could be re-evaluated. That was actually my intention before finding this thread, while I recognized the example tag, I mistakenly thought it could serve both purposes.

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.

I was just about to post something, then decided to search first (Amazing, right?) I'd love to get my hands on one of these, if I can/do I'll be happy to help out/test/etc. There is a small mountain of mainline patches going through for the rk3328 and the rk805, so kernel support shouldn't be a problem for long.

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

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...

If my reading over the boot method of these devices is correct, you should be able to trigger it to boot from an SD card via shorting a couple wires together, I think the UT3S uses that recovery button to do it. Similar buttons probably exist on the cheapies.

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

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.

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.

3.10... Man, knowing the work of art the 4.4 kernel is, I can only imagine what the source for that looks like ;-)

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.

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.

Well, I sifted through commits on Tinker Boards debian kernel git for Bluetooth. I found a lot of ugly. https://github.com/TinkerBoard/debian_kernel/commit/5106d9486cf1c2bad4f701611f51a526191c56ad which seems to be a rollback of https://github.com/TinkerBoard/debian_kernel/commit/c500f743567e5f00efea6a6797e3c689f41ea4c7 So that's how it happened on Tinker Board. It appears the individual porting LibreELEC has abandoned bluetooth on the Tinker Board as well, citing "unwanted changes to kernel" I will safely say that is not something I want to maintain moving forward, surely there's another way, but I feel like it would involve just plain writing a driver.

No dice on my side, but I'll try those compiled tools I linked to on your git: https://github.com/lwfinger/rtl8723bs_bt

Fair enough, I'm doing some headscratching, see the edit I made to my post, I'm trying something real quick before getting back to what I get paid for... I checked out the config for Tinker_OS 1.8, none of that stuff is enabled either, of course they also recoded half the rfkill subsystem...

Hmmm, btcoexist pops up when the sdio RTL8723bs module is loaded, are you sure it needs to be separately configured? [ 6.689885] r8723bs: module is from the staging directory, the quality is unknown, you have been warned. [ 6.696989] RTL8723BS: module init start [ 6.697023] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 [ 6.697027] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40 [ 6.698894] pnetdev = ed9e1000 [ 6.900133] RTL8723BS: rtw_ndev_init(wlan0) [ 6.903840] RTL8723BS: module init ret =0 tony@tinkerboard:~$ dmesg | grep Bluetooth [ 0.323257] Bluetooth: Core ver 2.22 [ 0.323331] Bluetooth: HCI device and connection manager initialized [ 0.323350] Bluetooth: HCI socket layer initialized [ 0.323364] Bluetooth: L2CAP socket layer initialized [ 0.323415] Bluetooth: SCO socket layer initialized [ 1.496904] Bluetooth: HCI UART driver ver 2.3 [ 1.496917] Bluetooth: HCI UART protocol H4 registered [ 1.496925] Bluetooth: HCI UART protocol LL registered [ 1.496933] Bluetooth: HCI UART protocol ATH3K registered [ 1.496941] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 1.497272] Bluetooth: Generic Bluetooth SDIO driver ver 0.1 [ 1.568237] Bluetooth: RFCOMM socket layer initialized [ 1.568264] Bluetooth: RFCOMM ver 1.11 [ 1.568282] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 1.568300] Bluetooth: HIDP socket layer initialized I did find some pinctrl entries in the Rockchip/ASUS dts for uart0, which according to the wireless-bluetooth entry is the BT port: &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_xfer>, <&uart0_cts>; status = "okay"; }; I enabled the H5 3-wire and added the bluetooth-wireless entry last night to no success, missed the uart0 pinctrl stuff.

Not as far as I know, the emmc and sd formats are a bit different. What I was intending to point out is that device trees for the Radxa devices are available in the kernel sources, so for the industrious experimenter building an image using the Armbian build system should not be difficult. My comparison of the shared decompiled dts and the 4.12 dts show the hardware to be very similar, I'll see if I get smoke by just substituting dtb's.

What kernel is this from? This looks interesting, lots of rk3188 references. Most of these "compatible"s I'm unfamiliar with, I think this will take someone writing a dts using this one as an information source. Interestingly, Pastebin is telling me to "learn something new in 2017". I think I've accomplished that... [edit] http://freaktab.com/forum/tv-player-support/rk3288-devices/ugoos-3288-devices/513884-rabian-debian-8-distribution-on-ut3s Claims the rock2 distros seemed to be compatible, gives somewhere to start on dts's since those are in the mainline if anyone is motivated. using that and the old dts you should be able to get something running reasonably quickly.

I'll be off work shortly and can do a quick and dirty test after I look over the file. I was able to build Tinker board images using their main repo (not the "miniarm" one) following some instructions on tinkerboarding.co.uk , perhaps following those instructions but replacing the DTS with your own for a test?

Anyone willing to pastebin the file so I don't have to repeat steps?

I'm afraid I can't speak to this issue, although I have tried installing autofs on 4.4 and I got the error you did. I then tried it on 4.12, and had no errors. If you don't have a specific requirement for the 4.4 kernel, I'd recommend trying the 4.12.

I did too. I have an idea where to look, but I'll need to do a little more serious digging.