TonyMac32

Interesting, do you know why? This does not seem to be a problem on kernel 4.4...

For some better news, Bluetooth is now in the development branch for default and Next kernels. To DIY this change, look at: https://github.com/armbian/build/commit/ac8d0d86687007c894caf18b0ba85d99c38eb8b1 and https://github.com/armbian/build/commit/daf80053e8a1eda8ee2f95d879ec525f1d92fbe0 device tree changes are the most complicated part, or build and apply. The device tree changes will break the functionality present in existing installs until the service/script are added. In reality the BT as it is today is somewhat broken, the new implementation is so far superior in every respect.

That I do not know, I do not believe they have been officially released yet. If you must have the eMMC, then wait, otherwise the standard one is fine. Now, make sure you read everything you possibly can about things like Amazon, netflix,etc. a lot of devices have strange behaviors in this arena, and I am no expert (I have only had 3 TV boxes, one that was a complete failure (s905x "Trongle"), and the other 2 have... quirks... (Z28 Pro and Ugoos UT3s)

Some feedback from @chwe and some improvements on the protection circuitry: And for the record, electrical cleaner can/will dissolve your electrical connectors... Also, lead-free solder is an angry and terrible thing. ;-) I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...

Well, as far as that goes, the Tinker is one of your better bets at present, thanks to the work of @JMCC. Using his "how-to's", you'll have multimedia capabilities on Linux in short order. Now, if you want Android, I believe that is also supported, but only by ASUS, not by us.

OK, mainline wifi appears to be having troubles, please ad comments/observations In this topic I just created

Please post complaints, as of my latest build I'm getting the link drops as well.

Anything in-tree, I don't see a problem. Yep. I have the service working on my end, I consolidated everything down a bit to reduce the number of working parts/etc, one thing that stuck out was the script @Jyu Ho pasted in had an else block which meant if the gpio was not initialized it would initialize it and then not attempt to reset/communicate, I was confused for a bit when I'd boot and have the GPIO ready but no bt.... @Igor, if this works as expected on every boot I'm going to try it on 4.4 and potentially avoid using the Rockchip rfkill altogether, it bypasses any unexpected software updates/"upgrades" that might happen, especially since the rtl8723bs isn't even technically supported so it is treated as "generic bt" [Done] I'm going to do some cleanup and get this committed to next/dev. I also apparently need to fix hdmi on dev, but Myy already took care of that. Updated first post to reflect status, stuck the historical info into a spoiler.

I need to go through this SPI procedure myself, until then I guess I'm not very helpful

ah ok, yeah it's not in Armbian yet, I was just waiting for it to be merged upstream since no one was complaining. I will see about patching it in the meantime if it isn't going to make it into 4.14 fixes.

I thought it already existed, but there was a bug when a name got changed on the dai cells. I can take a look since I've got all the rockchip stuff open at the moment. https://patchwork.kernel.org/patch/10298295/

Excellent! Thank you, and @Myy I will see about getting this at least into the build system for tonight, then it should be in the next rollout. Existing users will have to do some work, however, as daemons aren't part of our update path ("demons" sometimes are, but that is quite different... )

Yes, this was my goal tonight, should be straightforward.

That has been my experience with the Rockchip RFKill as well, so... ;-). TBH I would probably stop using the Rockchip RFKill driver on 4.4 and do it this way if it works well.

For the Adventurous: https://github.com/armbian/build/commit/3b4338069f751fbf7c51315c3f0b6008719dbc02

&uart0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>; }; Should at least pull the RTS out of the list of exports. Then the possibility of using rfkill-gpio improves. I'll look into a gpio binding that will get the other pins set up. [edit] Confirmed that adding <&uart0_rts> to the uart0 pin control makes it unnecessary on the gpio manipulation. Also successfully paired a device as an audio source, and played some songs through it. [edit2] It kind of looks like the most straightforward "solution" would be to define the reset/etc as LED's just to get them configured by the kernel without userspace intervention... someone with more kernel-fu than I can cut in and call me an idiot, I would appreciate it as a learning opportunity.

The last look I had at the rtl8723bs datasheet showed (if I remember) an independent reset for the bluetooth, so that should be fine. I will take a look shortly.

did you try nan-sata-install?

I saw some French going back and forth on on your github, . So, perhaps this can be put into a service or perhaps compiled into a "tinker_hciattach". I'll toss it on the list of things to look at. :-P [edit] if hcitool can scan, then bluetooth is working. [edit2] (posting while thinking) needs look at the device tree a bit more I think, could take care of some of this.

I tested K2 last night, it's broken again. I need to replicate the C2 method of building u-boot, all gxl/gxbb boards are u-boot mainlined at this point.

Since I'm playing more and more with hardware on my own time, I'm going to start the process of uploading my work to github for general consumption. At the moment I only have DXF board outlines for a few things, I'll follow those with proper KiCAD templates so no one has to wonder where things go if they decide to build. https://github.com/Tonymac32/Board-Geometries

I should have one early next week, I'm a sucker for new toys, and have been an on and off customer of FriendlyARM for a long time. :-)

It's a Realtek 8723BS, but operates the same way. (any guess what BS stands for? ;-) ). I actually think we should wipe out the DTS entry that's there for it and start over, since that one appears to be tied somehow to the Rockchip special rfkill system. I was able to get it to start the handshake by toggling the gpio pins associated, so this might be a template for getting to to work properly. Ok, enough off-topic. :-D

I just received mine today, having a hard time getting the image downloader (etcher based) to work, keeps failing out. Not that I wasn't going to try to build something anyway... @tkaiser https://github.com/FireflyTeam/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380 https://github.com/FireflyTeam/u-boot/commit/3f87b0c622e246f138d4d32c599fa087b880cade Mainline I haven't looked at/for yet. @JMCC I'm not 100% on the differences, but my understanding is the Rock64 is DDR3 and does not support UHS modes on the microSD. It has also been out a while and has decent support. The Rock64 is friendlier to the wallet and comes with a (small) barrel jack and SPI flash for housing uboot, something I can always support. ;-) Memory and SD throughput would be the major benefits on the Renegade, although I'd have to question why someone that concerned wouldn't just us a USB3 storage medium for the rootfs at that point, on either board, to be honest. I believe the Rock64 can boot a USB media from the SPI flash. (correct me if wrong, anyone, I haven't tried it)

@Igor if I have time tonight this might be the culprit: https://github.com/ayufan-rock64/linux-kernel/commit/75a7a42ab19f026427c8aa0dacc034f9956f1745 [edit] hmmm, ok, so that was already remedied. I guess I'll wait for @Hoerli to report back what the tty is calling itself... [edit2] downloaded today, login via tty1 was no problem.