TonyMac32

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.
 
 

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.

Hi,
 
I would like to thank to Tony for doing Armbian for Tinker Board. It is very appreciate.
 
I think that Tinker Board will have big success and Armbian for its, too.
 
Many thanks again.
 
 
 

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?

@zador.blood.stainedimmediately reminded my to ask for this. Done last week, waiting for an answer (in the meantime explaining to FriendlyELEC kernel dev how to use Armbian's build system since they want to start now to support all their boards with mainline kernel too. My personal goal is to get them to send PRs against Armbian's repo for new hardware and to also send those patches upstream and become board maintainers of their own hardware). Let's wait and see...
 

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?
 
 

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?
 
 

Tutorial for ili9325 and spfd5408

 
soon tutorial for fastes ili9341

Hi, 
Just a quick vote of thanks for the people involved in creating the OS for this board. Since buying the board a week or so I have tried several different OSś, but this is definitely the best available. Iḿ using it as a desktop with most of my favourite apps working.
I appreciate there is still a long way to go, but the work is appreciated.
 
Thanks again
 
Nick

Really impressive work for a "one man army". Much appreciate your effort.

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.

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

Hi, I also created a Image with the current armbian git builder and it's working, eth0 is working, wlan is not important at the moment.
 
Great work, thank you.
 

I really love your valuable comments. All the time. They're so great. Awesome. You should really try to get a job as CEO at one of those stupid Chinese companies. They need you.
 
For all those people not thinking they're the only smart person on this planet: Check NEO heatsink here: http://www.friendlyarm.com/index.php?route=product/category&path=82

Great!

I moved Tinkerboard from WIP section and enable nightly building. I hope it will work now 

Thanks guys, this worked perfectly on my NanoPi NEO H3 board.  I hope you don't mind if I cite this thread in my list for building a network MPD player out of the little board?
 
I can verify that for both the PCM5102A and the onboard H3 audio hardware, I had to set " format          "*:32:2" " for MPD to have equal volume across my 16 and 24 bit source material.

Hello from Armbian!  4K output is configured by default, however my monitor was not behaving properly.  Otherwise USB, ethernet, etc are working, And it is smoother than the ASUS tinkerOS 1.4
 
It could be that the MiQi is more robust bootloader wise, it might be able to overlook some formatting differences on the SD card where the Tinker Board cannot, my net crawling did uncover some comments to that effect concerning the Tinker Board being "inflexible".

No need.

Pulled out the hex editor to get a closer look at the bootloader to see if it was putting everything where it belongs, and I figured out why I can't see serial terminal, it's on UART2 in this build instead of UART1 like on the ASUS build.  So that explains that mystery.  I'm sure the sources could have told me that, but somehow the hex editor was easier to follow...  I also see references to the now-gone eMMC, so it's probably trying to boot that and hanging.
 
Can't get the build script to give me serial 1 instead of serial 2, but I did change the U-Boot source to the Rockchip Linux one, and I made an even more interesting adapter to ttyS2 and got this:
U-Boot SPL 2017.03-rc3-armbian (Mar 14 2017 - 23:21:19)  
It hung right away just like the mainline, I'm learning my way around to see if it's a device number issue, I'm still seeing the dwmmc@ff0f0000 (that's the eMMC address) popping up in the binary (less than with mainline), I haven't figured out where to turn that off if it's being passed as a parameter somewhere.