TonyMac32

Thanks @Myy, I was actually looking at your repo last night, I'll give it a look later today after work. In other news, it looks like the basic stuff will be in Kernel 4.12, including the wifi driver, albeit the old one (not sure why). However they've changed everything to tinker board from miniarm, so we'll have to adjust for that.

On a better note, I've hijacked the miqi device tree ( @Igor, I'm not sure how but I missed your response way back about stealing the Miqi one). It (the kernel) did get mad about the storage situation, and the dts format likewise is more like the rockchip-linux model than it is like the 4.4 miqi setup, which most likely explains the rockchip-linux setup. [edit] So mangling the miqi one didn't work out, it was getting messier by the second. I did, however, decide to just stuff the Eddie Cai patch for the tinker board in there, renaming it miniarm, and it worked out. Has 1080p desktop and not a lot else. The LED's work... ;-) [final edit] This image video output is extremely smooth, much better than the 4.4 based image. I'm able to use Plex Web to play videos in a 2/3 screen sized window smoothly. In case anyone wants to check it out: http://sprunge.us/POjR

I'd have to dig into the reboot process, but I think all eMMC stuff is gone at this point. That said, with the RK3288 linux support being what it is...

Tinker OS is the only distribution to use UART 1 as the communications port. All others I've tried, including Armbian, use Uart 2, pins 32 and 33. I have an FTDI Friend and a little pigtail harness I made for that purpose, I've been using it to debug since I became involved, see:

Mine gets stuck at the red LED. I haven't had time to debug that, I just repower it for now.

Found a GIC-related patch on RK3288 (and actually a bunch of other) SoC's concerning interface size, https://github.com/torvalds/linux/commit/387720c93812f1e702c20c667cb003a356e24a6c . Building the rk3288 one, doubt I'll see anything new and different, but thought I'd give you guys a heads up, I see exynos and allwinner in the list as well. [edit] Looking through commits at rockchip, there are quite a few small error corrections in the rk3288.dtsi, I'm collecting them, and I'll clean up my patches accordingly.

Awesome. @Igor, I was just getting ready to submit that rename, I caught it when I built tonight... Sorry about that.

Sorry about that tkaiser, I ran out of time last night to try it out. Wifi should be available in default nightlies tomorrow, no bluetooth yet.

I'm going to test the 4.4.1 tonight, might as well get it up to date as possible if it's going to be that heavy of a change anyway, once verified I'll push it.

Thanks Igor! I went through and don't see a way to shrink it down, there have been multiple revisions. Versions I've been able to find include 4.3.16, 4.4.0, and 4.4.1. It looks like a major rewrite took place at 4.4.0, the version in Tinker OS. The v4.4.0 commit I found shows 335 changed files https://github.com/anthonywong/rtl8723bs/commit/25e88f984ad93891f39822debbe86b2bc9f8035b

OK, after patching the Rockchip-wlan Kconfig and Makefiles, and updating the driver, then adding a fix found in a patch on the rockchip-linux site, I have functional WiFi. So, a silly question, but where is the config saved to after I make kernel config changes? That's all I need to get a patch submitted. [edit] oof, just yanked the resulting patch out of the folder, it's 10 MB. Soooo, what should I do with that? I'll see if there's a smarter way to replace the driver... [edit2] The driver in the miqi distro is v4.3.9 (Sep. 2014) I'm not sure finding the patches will help given the advanced age and huge differences.

Right now only the default works, I haven't gotten the device tree into the dev kernel yet. Transplanting the compiled device tree from the default into the dev is a messy patch just to see it work.

Let me take a look, as I've said before, on my part this is a learning by doing experience. But I have some unanswered questions on their hardware handling, so the source is good news, even if it is 1.4 (epic buggy)

U-Boot SPL 2017.05-rc1-armbian (Apr 17 2017 - 00:30:20) U-Boot 2017.05-rc1-armbian (Apr 17 2017 - 00:30:20 -0400) Model: Tinker-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1 It works! Figured I'd give it a look. Will update.

Push request in to update rk3288.dtsi and rk3288-miniarm.dts. There are no kernel driver updates in that patch, just the device tree updates. All info was pulled from Rockchip-linux, which I sincerely hope is the leading source of info for the chip (maintained by Rockchip). The rockchip-linux kernel has a huge patch involving the wlan module, I'm wondering what on earth they did, or maybe it was just a driver update? Obviously testing of the Miqi might need done, but I doubt there will be any issues. A question I do have, does the miqi not have hardware decoding/vpu functionality enabled?

OK, so I have the LED's, 4k, and an assortment of other things working properly, I have, in theory, everything in the DTS to make it work. Of course at this point I truly am lost, the wlan type in the DTS's that other working distros use says AP6212, but the board has 8723bs. I also am not enough of a Linux guru to patch driver things. Some notes: I am trying to track down the most recent rk3288.dtsi, I had to add A LOT to it to cover the additions for hevc and gpu handling. (have not tested any of that yet). I plan on starting from the latest "official" one to make sure there's as little hackery as possible. Unless patching in the one from rockchip-linux is acceptable, then I'll save myself the time. Also, preliminarily working on getting the DTS to compile with the dev kernel. will keep you posted.

Well, I decided to quit being lazy and starting hacking away, I have a better understanding of the structure now and have begun updating the device tree, testing it out now. I found the issue I was having before, my brain was stuck in C territory and I was assuming declarations flowed from the top down, and didn't stop to think that the various subsections (like, oh , pinctrl) would be referenced elsewhere within the same file. I transplanted the LED information from a Feb patch on Kernel.org, it had aliases for the pin numbers that were breaking everything. I'm testing and tweaking, forgot to add the appropriate modules to the board config after I got the dtb :-/ [Edit] is there any reason the board is equipped with the 8723bs but every DTS has ap6212 listed?

Small update: I simply can't get any device tree to compile other than the one already patched in. The dts fails to compile, then the kernel compile fails. I'm going to start looking at the bindings and see if everything is in there that's used on the newer device trees, although to be honest I don't see anything that should be causing the pain (spoken like a true amateur, I'm sure someone will find in it 10 seconds once they start looking.)

As you'll see in the thread, this board doesn't have official support yet, the core devs don't even have a board available to them. As far as the device tree is concerned, you are correct it leaves out quite a few things, I'm looking into that but have little experience I'm afraid. I will look into/test out what I can of your recommendations, I was of course looking for feedback along these lines. First and formost is to get the device tree sorted, of course I haven't yet seen two that look similar or seemingly point at all of the hardware...

Hold your praise until I provide something besides a functional U-boot flash. Like I've said before, I'm an electrical engineer by profession, I work with embedded bare-metal software, this tangled web of device trees, makefiles, build instructions, and such is a little outside my core competencies...

Getting back to the Tinker Board itself.. I swapped in the device tree from the miniarm branch at rockchip-linux, it compiles and boots properly, however I have had no luck getting the Bluetooth or wifi devices enumerated, I need to spend some more time with it. More troubling, and the reason I have so little progress, is the adjustments made to the HDMI portions of the DT have rendered video output almost impossible to maintain (anytime the system puts the monitor output to sleep it refuses to wake up, sometimes a hotplug of the monitor will rectify it). The mainline builds fail if I try to patch anything at the device driver level, I'll dig into that later.

The power supply that works for the Pi may not be good enough for the Tinker Board, I haven't made any measurement of the power requirements, however I know of a USB cable in my possession that will boot a Pi 3 and not the Tinker Board. I'm downloading the nightly to double-check, I see some patches , but I don't think those are "live" yet. [edit] Ah, I forgot one other small thing: It resizes the filesystem on first boot. That can take it a bit, and you won't see HDMI output in the meantime, at least I don't. I just booted the image gotten from the "nightlies" link on the Tinker Board download page.

On the global site ASUS has released a beta of "Tinker OS" 1.6 https://www.asus.com/Single-Board-Computer/Tinker-Board/HelpDesk_Download/

Yes, I've been messing with the device tree. It hasn't been going well... (Learning by doing has disadvantages)

Could Be. For my part, however, I want to use the massive library of available hardware for the Raspberry Pi with a proper SoC.