JMCC

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.

Using 5.75 image
 
Glamor: The tweaked X server that you included is just as snappy IF you turn compositing back ON in the windowing settings.
This is the opposite setting for armsoc. If you leave it disabled, the screens are horribly delayed when dragging.
I have just tested both and Glamor is as fast as Armsoc on my 4GB renegade when the compositing is enabled.
 
Chromium is still having issues playing anything 1080p from youtube (Just running chromium-streaming from GUI)
Trying to change settings in Chromium-streaming makes it crash (probably known, as you stated some web pages will be broken)
 
Audio out from the audio jack is still not working. HDMI audio works fine.
 
- Bottom USB2 sometimes doesn't work. Unplug / replug keyboard fixes this once the OS has finished loading.
 
Thank you for your efforts here. :-)
This device is almost usable because of this. Once browsing is fixed, I'tgoing to be my daily Linux box!

JMCC: You'd asked for a follow-up, I have been using a 4GB Rock64 as a primary desktop machine for about six weeks now using Armbian + your script.

Thank you very much for the script, being able to use sites like YouTube etc with streaming video and have it work (in full screen) is very nice.

Chromium is horribly unstable for me, I find that it works well for the first while, but eventually locks up the box almost completely. I ran vmstat on a console to try and figure out what the issue is, I think it is because I have a microSD card for storage and that is basically not a long-term solution, I need an eMMC.

I was never able to get to get the Rock64 to talk properly to my 27" screen, I always experienced severe tearing and flickering -- I believe I will have fewer problems with a newer screen, so that is another solution I want to try, in the meantime I use a small screen with low resolution -- I will provide more feedback when I have a better storage device and screen, in the meantime I get by and the script helps a lot with getting this SBC to where I need it to be.

Running Deluge also causes similar to behaviour to Chromium with half a dozen tabs open -- the machine locks up for a few minutes at a time, with maybe ten seconds of normal responsiveness between slow periods.  At the console with vmstat, I see large swaps right before the GUI becomes responsive again, so I believe it may be thrashing. It seems that any use of swap at all with a microSD card is very bad for performance. 

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.
 
@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.
 
[edit]  Fixed the lower USB port on Renegade.

Okay, I just had a look at the commit history, and the history of "/patch/kernel/rockchip64-default/Add_dts_rk3328-roc-cc.patch" was lost when it was merged into a commit for creating the rockchip64 family: now only the tiny LED patch that I applied recently is appearing. So it will be harder to figure out which patches I applied in the first place to make the board work. I'll try to figure it out.
 
[EDIT]: Nevermind, I just figured out the directory containing the patches changed the name. Now I found the original DTS. @Igor please ignore the question I just deleted, in case you got to read it.

Debian people are very good at backporting security fixes. Why not just make a bug report there?

@lanefu will help around admin duties.

What did you try yet?
Did you connect the camera? Did it show up?
You can check this with : ls -ltrh /dev/video*
If it shows up, download mjpg_streamer. Set it up, and ready.
Here how to set up mjpg_streamer: https://www.acmesystems.it/video_streaming
If it doesn't show up, then....... another story.

In addition to @NicoD's response, there is also a snap package for mjpg-streamer. So, once you get an Ubuntu Bionic running on your board, all you have to do is:
$ sudo apt update $ sudo apt install snapd $ sudo service snapd start $ sudo snap install mjpg-streamer $ sudo snap connect mjpg-streamer:camera $ snap run mjpg-streamer You can get some more instructions with "snap info mjpg-streamer"

In case someone is looking to add an Emby media server to their Nextcloudpi with hardware accelerated transcoding, I made a step-by-step guide here: 
 

Ok. I'll try that tomorrow.
I now have this. A snowy surface.  I think it's an improvement. Tomorrow I'll try different renders with different settings, and rounded edges too. It's enough for today. Greetings.
 

Change the floor again and made the eyes whiter. Now I'm really gonna put an end to it for today.

Here one with straight lines, and one smoothened. Let me know what you like more.
I made it look cute with the round big eyes, but the original looks a bit more though than this. Do I need to change that?
All tips are welcome.

Hi all. 
Since I wanted a 3D intro for my Youtube Channel I started working with Blender again. Now the intro is finished I've got time to try to make a 3D Armbian Logo.
 

I'll show some of the progress here for those who are interested. And if anybody else wants to do the same, go  ahead. We can then compare the results.
I've only just begun. But I needed a break so I started writing this.
Here's how it begins... create a side view ... 


Then put those pictures in Blender, add a cube, position it right on both pictures, and start modeling....

All done with the NanoPi M4 on Armbian Bionic.

I'll slowly keep working on it. I can't promise it will look great, but nothing is lost if it doesn't... Someone once asked me to do this, I can't remember who it was. I think Chwe or jmcc or tido. Could also have been a ghost in my sleep.
Cheers, NicoD

ps: @Igor It would be nice if we could easily resize images in our posts. Maybe with a dropdown box and % would be easiest to do. I know this isn't a priority, just a suggestion. 
 

Yes, and believe me, total time difference is not that big compared to a core i7 cross-compiling on a VM (we're talking about the high-end ARM SoC's, the ones with A15's, A17's and A72's). Plus, it saves you the time and boredom of setting a cross-compiling environment. And it's funny to do anything on a small $50 device made with random TV box pieces soldered to a cramped PCB

You probably should link to the original post cause the Register tends to be a bit....
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183486
 
His statements in the whole context sound a way more reasonable:
besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
 
and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
well, I quoted this one just cause it's funny.
I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
 
and followup:
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183500
 
make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
 
Don't get me wrong, willy's buildfarm (https://www.cnx-software.com/2019/01/07/nanopi-neo4-build-farm-rk3399-overclocking/) is great, but not everyone wants to build such a farm just to avoid cross-compiling.
 
besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.
 
https://www.zdnet.com/article/linus-torvalds-would-like-to-see-an-arm-laptop-but-he-doesnt-expect-it/
https://www.zdnet.com/article/linus-torvalds-still-wants-the-linux-desktop/
 
It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.
 
https://lkml.org/lkml/2018/1/21/192
 
IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..

Just a notice that I edited my last post above, to include a link to a very interesting discussion at CNXSoft, that clarifies the PCIe matter. A kind of a summary, with some additional insights by @tkaiser in this article:
https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md

Debian people are very good at backporting security fixes. Why not just make a bug report there?

Just a notice that I edited my last post above, to include a link to a very interesting discussion at CNXSoft, that clarifies the PCIe matter. A kind of a summary, with some additional insights by @tkaiser in this article:
https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md

Totally agreed. It is very likely that a user's project depends on features that are only available in a certain kernel and not in others. That is particularly true when it means jumping from a kernel that is actively maintained by the vendor (like Hardkernel's 4.14 for the XU4) to a vanilla mainline.
 
Practical examples: A user that has OMV installed on his Odroid HC1 with disk encryption on 4.14 kernel, would lose HW crypto support if upgrading to 4.19 (I think @tkaiser already pointed this out). Or if they have an Emby server with HW transcoding in that machine, it will stop working with the move to 4.19. Or if he has a media player/gaming station for the kids on a XU4. Etcetera.
 
Well, I think everyone is clear on this point already, I just wanted to show my support for the idea of being very careful when making big kernel moves.

cnx-software-Link: https://www.cnx-software.com/2019/01/19/orange-pi-3-allwinner-h6-sbc/
 
Quote from cnx-software:
 
...but who want to use a OrangePi with a OrangePi-image?
The H6-support of armbian is very limited - so I wouldnt buy a H6-board now
 
Last year I did buy a NanoPi K1 Plus because the H5 is much better supported.
The H6 is also "only" a QuadCore A53 like the H5 - so only the newer Mali T720 GFX is the difference.
 
The OPi 3 H6 would be nice for the price if the complete hardware is supported by armbian
 
https://aliexpress.com/store/product/Orange-Pi-3-H6-1GB-LPDDR3-8GB-EMMC-Flash-Gigabyte-AP6256-Bluetooth5-0-4-USB3-0/