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.

Right, however I have that patched in the build system to add those speeds. Like I said I'll have to download and verify what's going on there.

Well like I said the op points are in the device tree, not in the CPU governor's or utilities.

Yes, this seizure-like behavior seems to be normal... Why? Well, I haven't looked into it...

Well, this is an opportunity cost situation. Even tens of thousands of Linux guys don't compare to the profits in Android devices. So, if you're Amlogic, you have a lot more money to gain by putting your effort into new Android devices; money spent on Linux is money that will not net the profits of money spent on Android, and is thus a loss. I worry that "Time's up", so to speak, on RPi. This last revision is the lamest one yet in terms of features. It's a bugfix and an "Almost make relevant gains in performance" situation, the most interesting part is the 5 GHz WiFi. Better thermal is nice, but it's kind of a "Should have been done right the first time" situation (Not that most other guys do it that much better). Those Broadcom processors are not available to the public, they run Linux as a guest OS under a super-secret firmware on the GPU, etc. I think Pi had a good vision when it was founded: today I think it's a gimmick and a prayer.

Nanopi neo or duo for the absolute lightest weight and possibly lowest power consumption. I don't have a lot of good data compiled on the Amlogic chips and power consumption, but the Le Potato, NanoPi K2 or Odroid C2 may fit the bill as well, and are 64 bit with a couple additional goodies for improved performance.

@constantius have you done the apt update and apt upgrade I recommended? I've had family in to visit and haven't gotten much of anything done this week.

I am saying this only because I don't want too much time wasted here by talented people who can read:. All of the information we have that you need has been provided. Mainline has no hardware enc/dec support. All kernels have software support depending on the application. As for "knowing", I know I read that thread while working on an Amlogic TV box. It answers the questions, or points to where they could be answered. Read it again. This topic has been satisfactorally addressed in my opinion, if your concern does not seem to be answered in the thread, I propose you research the architecture of ARM systems, there appear to be some foundational issues with your understanding. I can make a csc entry in the build script for that if you like, it should be well supported by the BayLibre patchset. I was figuring on one for the VIM 1 as well. The issue you'll have with the VIM 2 is that the GXM is a different GPU than the GX(L,W,etc)

Ah ok. I had misread the OP and missed the comment on the LED working, I'm not pushing my patch unless someone has a truly dead board

Did you apply the patch in your own build then? Just want to compare notes before committing it to the build system. Sent from my Pixel using Tapatalk

Not yet. There was just an update to the kernel, looks like some driver work went on, might give it another go shortly.