TonyMac32

Good, I just got done with work here, was going to link it for you.

My apologies, I meant the Vendor kernel when I said "Rockchip", so in this case Kernel 4.4. "Rockchip-default" Sent from my Pixel using Tapatalk

There is not yet 4k in mainline, to my knowledge. For 4k you need to use the Rockchip kernel. Sent from my Pixel using Tapatalk

Yes, I remember the conversation on Le Potato. I need to follow up on what the end result of that was. As far as RAM, I believe it is also impacted, In would not attempt to move around bl31's. Sent from my Pixel using Tapatalk

I would be careful with any claims of clock control on Amlogic devices. I'm on my handy, but there is a thread here talking about that, the system is controlled via the trusted firmware, which is a closed source blob, and not always entirely honest.

Is that from the TinkerOS image? I just got to the "workshop"

I'm guessing you need to use an overlay, the other camera is enabled by default.

It would, in theory. This is actually a situation where the Hardkernel code base is significantly divergent from the others, due to their hard work early on to support the hardware. It means things are done differently, not necessarily incompatibly. Now, quite some time after Hardkernel, we have other boards, and Amlogic/others are pushing to get proper mainline support, so I'm sticking with that. As for compatibility of VPU's: https://elixir.bootlin.com/linux/v4.16.2/source/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt

The Tinker OS kernel is using a now deprecated driver, As we're using the Rockchip kernel directly, we should work to the new driver, which requires *a lot* less "tweaking" to work. In short, I haven't had the time to get this working, what with actual bugs on the table to deal with. Like I said, I'll give it another go shortly. There were some adjustments to the drivers, so we'll see.

I agree it isn't optimal, but that comes down to board design. you don't need to push the button at the same time if you are shorting those pins.

Tested on MiQi, Igor merged to the development branch. A quick minerd --benchmark showed 7.1 khash/sec, I had just updated to the previous config 4.16.0 and had tested (same rootfs, only kernel differed) at 6.9 khash/second. All things were constant other than the kernel config. Thank you!

Our images are simply not formatted into 7 partitions or whatnot like an Android image, there is nothing wrong with it. That makes a lot of tools for flashing them dislike them. If you look more closely it also gives instructions on what to do if that doesn't work ("unbrick"), which is to very carefully short two pins (I use precision tweezers for this). Then it will work without issue.

Yes. Building from Development will get the audio working in next as well.

The C2 is the same SoC as the NanoPi K2 (and the same evaluation board design), and the same family as the Le Potato and VIM 1, I believe that all share the same video decoding hardware block. Any of them should provide that ability assuming the kernel supports it. For now Mainline does not, however I think it's on the to-do list for BayLibre.

The instructions don't require you to be a developer, simply cut and paste some lines into a terminal, changing the "<>" entries to the proper file names. However in this case it is not necessary. As for the patch, it is already there, the current version in the download page is Armbian 5.41 for ubuntu desktop. Stretch is not officially supoported as yet, so it is lagging behind as it is not built as often, but all builds should have the newest kernel available, however, it is common across all distros. Approximately 200 MHz, or 11% It would seem you have a device tree that doesn't have the op points, it has nothing to do with temperature in this case. @Igor, it looks like the repo is not up to date on the Rockchip kernels, showing the 5.38 kernel 4.14.14 as the latest, which is about a week or so too old to have the opp table repaired after we shuffled kernels.