TonyMac32

no SD card in the slot, right? Otherwise I'll try to install a fresh 4.14 and repeat the process again and see what happens tomorrow my time (is 1:30 here, I have to sleep. ). If I can't reproduce it, then we will have to wait on your USB-UART adapter

No, the armbianEnv.txt file overrides it. Maybe check to be sure the file has the right file listed.

That looks the same, now, did you reboot it with the USB attached to the PC still (crazy question, but if I don't ask...) (This would get it stuck in UMS mode)

I'll have to catch up on that. This worked on mine, but has not worked on @AdamD's I want to verify the boot comands/etc

OK, show me what your boot.cmd file looks like.

OK, don't edit anything, just copy this file into the "dtb" folder with the other device trees. @Igor I'll push this patch, basically creating this device tree for the older u-boot systems. rk3288-miniarm.dtb

OK, mine is wanting to see "rk3288-miniarm.dtb" and can't find it. We had a symlink there, it must have gotten lost, but why that isn't angering the SD cards I'm not sure... if you edit /boot/armbianEnv.txt to read "fdt_file=rk3288-tinker.dtb" instead of "fdt_file=rk3288-miniarm.dtb" you are a step closer, but mine is hanging after a few seconds, can you verify that behavior? I am trying something else quickly. @Igor does u-boot not get updated on eMMC? My board is still listing the 2018.05 revision after the update

OK, I'll have a look. I haven't tried an in-place update on the eMMC, but the board in front of me is set up with 4.14 on eMMC. Give me a couple minutes.

Sounds like it's not getting past u-boot. You say the non- eMMC Tinkerboards were fine after upgrade?

https://github.com/radxa/kernel https://github.com/brian541/build Appears to be it, at least brian541 was working on a PR...

The solution is to make an overlay. The correct dts/dtb is the overlay mentioned in my response. The method is to make a device tree overlay and compile it, then, in the armbianEnv.txt file, specify it for inclusion at boot. I'm afraid I don't have time to give you a tutorial on this at the moment, if you look at our build system you might be able to pick it up. You also need to recognize the differences between kernel versions, I'm uncertain if mboehmer was using a 4.x kernel. This page http://www.linux-meson.com/doku.php?id=start Says pwm works with modern kernels, so, simply enabling it should be sufficient in the device tree overlay, and making sure the driver is compiled with the kernel. If you are unable to do it, I may be able to by the end of the week, since it will benefit 3 boards. No promise though, I have quite a few projects I'm working on simultaneously.

Yeah, VPU doesn't exist in mainline. There are some patches for educational purposes out there, but nothing constituting a truly functional driver. Mali needs patched in, similar to what @Myy does with RK3288.

Awesome! I was reminded on my site that not only is my writeup for the 3.x kernel, but I also have older revision boards than current.

Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19. Notable changes include the use of device tree overlays.

I'm afraid not. :-/ I have an 800x400 hdmi, it's behavior is a bit different from a typical HDMI display, but as to why, I'm afraid I'm in the dark.

Well then, that's the new "most extreme SBC environment", the next is of course the undersea Odroid C2.

If you look at their code, they are more or less bridging python and their pile of I/O libraries/routines. The result should be ready to go support for the adafruit-supported hardwares.

Hmm, I pulled this from their device tree, unless somehow their image predates that change...

@Neil Armstrong everything looks good now, changing modes, changing monitors, no problems. Tested on Le Potato. [edit] Just tossed it into the dev branch, anyone else wanting to test, go forth.

No idea, correcting it.

I came across this, the project allows the control of a lot of home-brew hardware as well as commercial products: https://www.home-assistant.io/docs/installation/armbian/

Right, this is a reference driver, not a complete one. Certainly useful in the right hands I think, for example the person adding the jpeg hardware driver is interested.

This early on that is a tough one, most of the work is basic board support, so device tree/etc. Sent from my Pixel using Tapatalk

Excellent! Basic electrical concepts win the day!

Wait, what? Not much faster? If you say at burning energy during operation, I agree; otherwise, I think every benchmark on the planet is against you. I have 2 Pi3's, I can't use them because they are slower than very nearly every other board I possess, they collect dust. My Pi2 serves to play music for me. Sent from my Pixel using Tapatalk