NicoD

The M4 is also a RockChip. But the company behind it, FriendlyElec is a lot better with support. And almost everything seems to work well. I use it daily, I use it for Blender rendering, for video editing, for gaming, programming, watching youtube... The Rock64 isn't good for those things. It's best to use as a NAS.
It was the first cheap one with USB3 + GigE. But Pine64 is just the worst company when it comes to software support.
So the Pine64 boards or best for Linux freaks who like to test and tinker a lot. I would not advice it for a normal user. I've just made a video about the Media Script on the Rock64, and how to overclock it to 1.5Ghz. Now rendering and in an hour it'll be online. I say it many times there are better boards for these things...

Good luck

@pzwI also got one of those. I haven't tried any armbian on it. I did use images for the M1+ from FriendlyElec because they were better.
Maybe the one from Armbian works.
https://www.armbian.com/nanopi-m1-plus/
It is end of support. But could be a good base to build upon.

I should pick it up again and try. I made a wifi cam with a small powerbank. But I'm not happy of the camera. Picture isn't stable.

Hi @NicoD ; Looks like a good start for sure.  I also consider a learning project for me, since I would like to learn more about how the kernel etc works, so I can make the needed overlays where needed...  But for now I need to make sure they are loading! (Pretty critical step in the process!)

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

@JMCC Progress.
I downloaded the image again. I downloaded the script again, I used another 4A PSU, an SD-card instead of eMMC, another wifi dongle. But still the same. After I installed the script, I reboot, open Chromium and play a video. After 2 minutes hard crash and the system reboots.

Then I noticed the only thing I didn't change was my usb hub. I can't use my wifi dongles when they're plugged into the Rock64(can't find my network, but it finds all the others(also weird)), but they work external plugged in a usb hub. So I switched the hub for an extension usb-chord.
I haven't had any crash since then. +3 hours now. I can't hardly believe this usb hub is the cause, and why that one kernel doesn't have the reboot with that hub. The hub does have a problem, when the Rock64 reboots, it doesn't turn on the usb devices at boot. So I had to replug them every time.
Now I don't have this with the extension cable.

I do still sometimes have the "aw snap". But not much. Mostly when it's on 1080p. 720p 30 is perfect(Youtube), 720p 60fps also doesn't work well. Some 1080p works perfect, most doesn't.
I'll keep testing to see what happens. It's looking good now. The few "aw snap"'s are acceptable. I've watched multiple videos now.

If anyone could try this script on his rock64 and see how Youtube plays in 1080p with Chromium/Firefox, that would be awesome.

Sorry for the hassle. I hope it's ok now. The video is comming in a couple of days now. Thank you. Cheers.

merged https://github.com/armbian/build/pull/1324
 
thanks @NicoD for doing the homework.

It is there on the commit I did on Friday ... I'm currently running 5.0.y from the eMMC ... Oh ! you're right ! I've the eMMC still on 4.20.y ... I must have forgotten some thing ... Now checking !

Everything seems to be working very well. I've tested the USB3, works fine. +300MB/s.
5G wifi works great (5MB/s)
It is fast for a quad-core. Only my Odroid C2 can keep up when it's overclocked to 1.75Ghz + ram OC 1104Mhz. It can't keep up at stock settings.
I've used a mid-large heatsink with a 5V fan connected at 3.3V and while maxed out for 2hours it didn't go over 52°C.

Last time the temperature shot up to +70°C after a second maxed out. It's not doing this anymore.(I don't know why, it's the same heatsink, just another image)

Now it does throttle at 60°C. It goes down to 1.3Ghz. So this is a big difference. Maybe this could be done a bit better. Example : at 70°C to 1.5Ghz and +80°C to 1.3Ghz?

It stays at 65°C and 1.3Ghz with heatsink and without a fan.

So without a fan you don't have a good performance right now.

I couldn't get acces to the eMMC. Maybe this still needs to be added.

Otherwise it's a joy to work with.

 

So I'm trying to be enthusiastic about this for you, but it's kind of a disappointment to post an announcement like this on the Armbian forum and literally not have any code.   

I would like to announce that I am getting started on an armbian-derived project, Armbian-NG. This is not a fork of Armbian, nor a rewrite, it's a derived project that piggyback's on the excellent work by Igor and the entire armbian development team. I think of Armbian-NG as armbian's little clumsy brother, who is just learning to walk but has great potential. 
In as few words as possible, Armbian-NG will be a Python (set of) script(s) that runs natively on Aarch64 (64-bit ARM) hardware (running Ubuntu 18.04 or later) to build Armbian images. More details  can be found here: https://github.com/AndrewBCN/Armbian-NG
 
As with armbian, anybody is welcome to contribute with code and ideas to Armbian-NG. And since no project is worth its storage space without a logo, Armbian-NG already has one. 

i made a patch from his tree and u-boot compiled.. I'll share an image and a WIP PR in a bit

Right ! Only 3 small commits :
https://github.com/janwillies/u-boot/commits/v2019.01-sopine-spi
 

Looks like just a few patches to u-boot 2019.01.  I can at least try to build an image from it

This is the same problem as this thread.
@AZClusterboard Did you try the fix of siffland yourself?
 
https://www.pine64.org/?product=clusterboard-with-7-sopine-compute-module-slots
 
Maybe it's not the right tool for the job for you? Pine makes a lot of hardware, but doesn't support it. So people buying it are supposed to know how to make these things work. Or at least find pleasure in searching for fixes.
If you want a device that works out of the box, with software support. Then you've bought the wrong device from the wrong company.


Maybe try this.
 

It is a work around. But once you've got them running, you can go further.
It does seem nice hardware, but since not many people are using it, you're not going to have a lot of help. But best is to join those who are working with it.
@lanefu
Can this u-boot be easily merged into the sopine build? (I don't know, just trying to help...)
 
Take care of yourself. Most could not handle the stress of such a huge project. Try not to worry too much about Armbian, there's others who do. Best of luck.
 

It's been a while since I don't test this setup. I'll have it a look.

Hi again. I've been testing things. I've had a few problems. Now I think I've got most fixed. But I don't get the performance others have.
First a recap.
With : Armbian_5.75_Rock64_Ubuntu_bionic_default_4.4.174_desktop (from downloadpage) : Chromium is very unstable after installing the script. I constantly get "aw snap". It plays up to 720p, but crashes during playing. Firefox the same. Plays 720p but sometimes crashes(less than Chromium) Also had hard crashes with resets. Very unstable.
I then build : Armbian_5.77_Rock64_Ubuntu_bionic_default_4.4.176_desktop : The same issues, but no hard crashes of the system. Then I changed to nightly and reinstalled your script. Chromium was a bit more stable, Firefox and Vivaldi couldn't boot anymore, they couldn't show anything in their window.

So today I started reading everything again in this thread. Until I came upon
 

So I thought, lets try with kernel 4.4.167. Everything is stable. Chromium plays Youtube well, only in 720p. 1080p seems to play ok, but it continuesly rebuffers. Firefox works again, but without vpu now.
I've now played almost an hour of different content on youtube and it hasn't crashed yet. Even different browsers together.

So it seems to me there is a problem with your script and the kernel that's used now in default build. I'm sorry I'm not more knowledgeable to know what the problem is. I just want to let you know.

Another small thing, when I choose to install streaming in the script, I can't choose arm soc or glamour anymore. You get that warning it takes xxxMB space, and after that it starts installing.

Any idea how I could improve 1080p? I'm using eMMC, and wifi connection is ok. (wifi works only with a USB hub, and I've got to replug every time it boots, I tought this was fixed. But that's another topic )

Chromium 32-bit works on none of the kernels. It always crashes, and there's no VPU support either.

I'm happy with what I've got now. It's a lot better than default where even 480p is unwatchable. If it could be improved then it's a bonus.
Here is my walktrough until now.
sudo apt update && sudo apt upgrade sudo armbian-config -> system -> other -> linux-image-rockchip=5.70 4.4.167-rockchip64 reboot sudo armbian-config -> system -> freeze enable sudo nano /etc/default/cpufrequtils MAX_SPEED -> 1520000 (it clocks to 1.39Ghz at 1510000) Download script : https://forum.armbian.com/topic/9310-rk3328-media-script-rock64-renegade/ Install script : sudo ./media-rk3328.sh <- ARM SoC Disable compositing : Windows Manager Tweaks -> compositor -> disable display compositing sudo reboot I'll do more tests, in a few days I'll make my video. Cheers.

I have no 4K monitor either. In theory, the SoC supports 4K@60. Can anyone confirm if this actually works with Armbian?

@JMCC First of all, great job done.
I'll make a video about the desktop useability of the Rock64 these days. This with Armbian Bionic + your media script. I've red many complaints of novice Rock64 owners that they can't make things to work well(Pine64 forum, my YT channel...).
So I think this video is needed for many.

I've red all the posts here and I'll add the info I've learned. Can you confirm the display refresh rate must be 30Hz in 4K to make it work well? I don't have a 4K monitor.
I'll say it's not officially supported by Armbian. If there's anything else you find important to mention, please let me know.

I'll also show how to set it to 1.51Ghz because this has changed since my first Rock64 video.
Thanks for all the work. Next month I'll do the same with the NanoPi M4 and RockPi4B. Hopefully Radxa can improve things a bit by then for their software.
Cheers.

Great job. I've built Armbian_5.77_Orangepi3_Ubuntu_bionic_dev_5.0.1_desktop, and I finally can see the potential of this SoC.
It now outperforms all my other quad-core SBC's. Thermals are ok, even without a fan it's very workable.
It does seem that the heat can't dissipate well into the heatsink, I think this SoC is a bit too small. With a short 7z benchmark is quickly goes up to 75°C. But the heatsink doesn't warm up. When done it immediatly goes back to 45°C. So it can't deliver the heat into the heatsink.

Maximum display resolution is 1024x768. On-board wifi doesn't work, but my dongles worked immediatly. Also no hdmi sound.
Just for fun I tried Youtube. And it plays great in 1080p with Firefox. Don't know if this would be the same with a true 1080p display resolution.

I'm very happy seeing a better performing image for it. What a difference with the images from Orange Pi.
The SoC could use a metal casing to better dissipate the heat, otherwise it looks good. Thank you.

It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
 
Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).

Great job. I've built Armbian_5.77_Orangepi3_Ubuntu_bionic_dev_5.0.1_desktop, and I finally can see the potential of this SoC.
It now outperforms all my other quad-core SBC's. Thermals are ok, even without a fan it's very workable.
It does seem that the heat can't dissipate well into the heatsink, I think this SoC is a bit too small. With a short 7z benchmark is quickly goes up to 75°C. But the heatsink doesn't warm up. When done it immediatly goes back to 45°C. So it can't deliver the heat into the heatsink.

Maximum display resolution is 1024x768. On-board wifi doesn't work, but my dongles worked immediatly. Also no hdmi sound.
Just for fun I tried Youtube. And it plays great in 1080p with Firefox. Don't know if this would be the same with a true 1080p display resolution.

I'm very happy seeing a better performing image for it. What a difference with the images from Orange Pi.
The SoC could use a metal casing to better dissipate the heat, otherwise it looks good. Thank you.

I just build a Armbian image for the Orange Pi 3. The performance is a lot better. It doesn't throttle quickly.
But there is something strange with the temperatures. I'm reading temperatures of 75°C while 7z b, while my heatsink doesn't feel hot to the touch. When the test is done it immediatly goes back to 40°C.
I tried different heatsinks, small ones and bigger ones. The same result.

But when I don't use a heatsink and put my finger on the SoC, then it gets very hot very fast.
So the problem probably is that this SoC is too small to be able to dissipate the heat well into a heatsink.

At least it now performs almost 2x as fast as the Orange Pi image with kernel 3.10. But hdmi resolution is 1024x768.

Great job. I've built Armbian_5.77_Orangepi3_Ubuntu_bionic_dev_5.0.1_desktop, and I finally can see the potential of this SoC.
It now outperforms all my other quad-core SBC's. Thermals are ok, even without a fan it's very workable.
It does seem that the heat can't dissipate well into the heatsink, I think this SoC is a bit too small. With a short 7z benchmark is quickly goes up to 75°C. But the heatsink doesn't warm up. When done it immediatly goes back to 45°C. So it can't deliver the heat into the heatsink.

Maximum display resolution is 1024x768. On-board wifi doesn't work, but my dongles worked immediatly. Also no hdmi sound.
Just for fun I tried Youtube. And it plays great in 1080p with Firefox. Don't know if this would be the same with a true 1080p display resolution.

I'm very happy seeing a better performing image for it. What a difference with the images from Orange Pi.
The SoC could use a metal casing to better dissipate the heat, otherwise it looks good. Thank you.

Something else I tried. The Armbian Terracotta Army. I need to add textures to the ground.

You can release it. We will polish the schematic formats and release it anyway...