NicoD

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...

Thanks for pointing it out. I will have out engineer look at it and clean the device tree. We would like to contribute to Armbian and get some decent support on ROCk Pi 4. Apparently, we should do it in the right way.

Sweet.. I installed Blender on my frankendell and doing a 4k on terracota...  Sadly CPU rendering is faster i was hoping my Quadra K620 would make things interested.... but i think its not in an optimal PCI slot anyway.. oh well.

Yes. I've got a big heatsink on the way for my Rock Pi4B. That one has 4GB ram vs 2GB of my M4. So with that I can do 4K or higher renders during a week/month of all of them.
I've added all the original .png renders + all the blender files as attachment file. Everyone can do a higher resolution render (8K, 16K, 32K???) if they want. Or play with it a bit.

Here are all of them. These are 1440p but converted to jpg.
Armbian transport

Snowy Armbian

Old school Armbian

Armbian in space

Empire of Armbian

Armbian @ the beach

Armbian__Backgrounds.7z

Armbian as transportation company (of 1's and 0's)...

This will be my last submission. I've got too many other things to do. Otherwise I would never stop. Cheers.

I have just received my SATA HAT, it is recognized and working on Armbian out of the Box  (4.4.176-rk3399).  

That seems a very paradoxical question. To ask that question you have to first start writing a question, but the question you ask can't be written before you start asking a question.  It's like a new big bang is happening in my head.
Welcome to the forum.

That is because it is your first build.
Redoing almost the same build later, it can take less than 30 mins, thanks to "ccache" ...

When I did start I also did think I need every bullet-point - you are not alone
In the future if you want to be a bit more risky, then you could use
./compile.sh EXPERT="yes"

I didn't have one. I always used prebuild images.
Now this seems a lot easier than what I thought. I had tried multiple times in the past to follow these instructions
https://docs.armbian.com/Developer-Guide_Build-Preparation/
What do I need? x86/x64 machine running any OS; 4G ram, SSD, quad core (recommended), VirtualBox or similar virtualization software (highly recommended with a minimum of 25GB hard disk space for the virtual disk image), Setting up VirtualBox and compile environment is easy following our Vagrant tutorial, Docker environment is also supported for building kernels and full OS images, The only supported compilation environment is Ubuntu Bionic 18.04 x64 (no other releases are supported! It has to be exactly 18.04 otherwise default compiler versions might not match so if you’re on an older Ubuntu release upgrade to 18.04 now, if you use a newer Ubuntu version start with 18.04 from scratch), installed basic system, OpenSSH and Samba (optional), no spaces in full path to the build script location allowed, superuser rights (configured sudo or root shell). I thought you needed every bullet point, and I never could run vagrant right. I didn't know what it did, and didn't know why I needed it.

Even this I had done, I was in the build directory  If only I had typed ./compile.sh
apt-get -y install git git clone https://github.com/armbian/build cd build Only the last step not. So stupid. Thank you so much, it's clearly a lot more simple than I made it look in my brain. I've now got mini.iso, and started the build process.
It's one of the most simple things, while my autistic brain made it take months just by not wanting to understand it's simple.
Well. Nothing is hard, when you know how to do it.

Didnt you already got a armbian-build-system?
 
If not - why use vagrant and not only the minimal-18.04 Ubuntu in a VirtualBox?
 
I do only use Virtualbox and there there the is installed the mini-iso of 18.04 64Bit.
 
I used this page as information: https://github.com/armbian/build
 
If you got 18.04 minmal 64Bit installed  (including configuring the network) - all you/I had to do is
 
apt-get -y install git git clone https://github.com/armbian/build cd build ./compile.sh @NicoD BTW: The "vagrant"-page seems to be old because of VirtualBox 5.1.12 (now we are up to 6.04) and 
Ubuntu Xenial (we are now using 18.04 Bionic)