NicoD

Hi all.
In my latest video I test the new Armbian 22.02 images on RK3399.
I use the NanoPi M4. But it should be about the same for other RK3399 devices.
 
 

Long story short.
Jammy xfce 5.16 performs better. And has the better performing browser.
Focal xfce 5.15 firefox is not HW-acc. Chromium is, but performs badly. Also bad blender result. Not all cores are used to the max. I've never seen this behaviour.

So I would use the Jammy xfce 5.16 image. But I'm still using an older image that work. So I'm not upgrading.
Greetings, NicoD

This is not so much a 'Tutorial' or a 'Review' as it is an overview (and/or starting point for further research) of some things to consider when setting up a file server, some in general and then some more particular to SBC.
 
In the simplest case, you could attach almost any drive to almost any board, by any number of ways, and you have yourself 'a file server.'  However with even a small amount of effort, there are so many better ways to do things nowadays.  We have a lot more interesting hardware choices, advanced filesystems, etc. and so those are mostly what I want to talk about.
 
But first, some context.
 
Dedicated distros vs simple directory sharing
 
Personally I am not a fan of dedicated distros like FreeNAS, OMV, etc. as I consider them to be too 'heavy weight' and single solution specific.  I mean, if you need some/all of those features, or you like them or whatever, then great, use them.
 
However, a 'file server' is one of the simplest use cases of a 'server' and I am sure one which almost everyone buying a SBC will do at some point.  IMO, all one needs to do is simply share some folder(s) via either NFS (if your network is mostly GNU/Linux machines) or Samba/SMB (if your network is mostly Windows machines).  And that's it, you're done!  Simple, lightweight, and using standard protocols (well, a little less 'standard' in case of Windows, but I digress ).
 
You could also add any of the software included in the 'all in one' solutions in first paragraph on a 'piece by piece' basis, if/when you need them.  Personally I am more of a fan of starting small (vanilla Armbian base) and then adding things you need one by one.  But you are of course free to do whatever you want.
 
Setting any of that up, or debating about it, is considered off-topic for this thread, as there are tons of resources already around the Internet about those things.  So I want to focus on other, (IMO) more interesting, aspects.  You are welcome to make your own thread with a different focus, of course.
 
Important note about hardware RAID
 
RAID, in case you were unaware, means "Redundant Array of Independent Disks."
 
For a looooooong time, I (and I think many others with SOHO NAS perspective) thought that 'hardware RAID was the only proper way to do it' but in the course of researching ZFS I eventually became convinced otherwise.  In fact, apparently, historically 'big-iron' filesystems (Solaris, others) were always run with software RAID in the enterprise as there are a lot of advantages to that.
 
Just think about it.  If your hardware RAID card dies, you need to replace it with exactly the same model, before you can even begin to recover your data.  With software RAID, you just re-connect drives and you are back in business (with ZFS, you can even connect them in any random order, amazing!).
 
In particular if you are using ZFS, hardware RAID controllers are not recommended.  I am not sure how much this applies to other similar software RAID systems, but it would stand to reason that it does (IMO).
 
Hardware controllers are also typically very expensive and proprietary.  Where software RAID uses readily available and inexpensive commodity hardware (while actually increasing reliability).  All of which is why I have become such a big fan of it, whether we are talking about ZFS (which I like) or some other software RAID solution you may prefer instead.
 
Now, with that out of the way, onward!
 
Filesystem
 
Assuming you came to similar conclusions as I did in previous section already, this is where our decision making process really begins in earnest IMO.  As the way I see it, choice of file system will dictate topology, which will in turn dictate choice of hardware (which SBC to buy).
 
Of course if you already bought some SBC, you are in a different boat (and working backwards, from my point of view ).  Anyway, you will have to adapt accordingly (and/or buy different hardware).  However, if you are already there, go to 'Historical Overview' section, and maybe you can find some solution there which will work with the hardware you already have.
 
Now, back on track, we are really lucky nowadays, thanks to F/LOSS, to have some industrial grade, software based filesystems available to us mere mortals! 
 
I like ZFS, but certainly, opinions will differ.  Some people like btrfs, in fact I got into a lengthy (but IMO informative) debate with @tkaiser about that.
 
Then there are other distributed things like Ceph (and others) which I will admit to knowing less about.  If you do, kindly add your thoughts to the thread when you have a moment.
 
Point being, hardware setup for someone like me (using ZFS) or even someone using btrfs will be perhaps quite different than someone using something distributed like Ceph.  Just keep that in mind.
 
Historical Overview (SBC Hardware)
 
I want to cover some of things which came before, as I think they are relevant to understanding where we are today.
 
In the beginning, there was darkness.  Wait, let me fast forward a bit. 
 
I will start with the creation of Armbian.  Which happened, in fact, because Igor was trying to set up a file server on a cubietruck.  True story (and like I said, you are not alone, this is a common use-case)!    Anyway, many of us bought (A20 based) cubietruck back then, because they sold a small power adapter board which made this easy and they also had a SATA connector right on the board.  I think they were one of first to do this in fact (I could be wrong).
 
After that, a lot of us used (more powerful Samsung Exynos5 based octo-core) ODROID-XU4, along with a good quality USB to SATA adapter with UASP.  That one in particular was recommended by tkaiser a long time ago, however -- as of time of writing this post -- PINE64 still sell it in their store(!).  And it may be an 'okay' solution if you have some (especially, USB3 capable) board laying around that you just want to use.  Some people are still using this today.  But we have a lot better options now.
 
Then RK3399 came on the scene.  Which was very exciting, because these support not only PCIe, but they are also 64-bit (which is required for ZFS).  Unfortunately, it took literally years for these to become really stable.  Lucky for you, this is all in the past by now.  And so, currently, many people will probably recommend RK3399 as a file (or other) server.
 
There are a lot of other boards out there, which I do not have as much experience with.  But I also try to note only historically significant developments here (at least the way I see them).  If you have any to add, please comment below or contact me somehow (PM or IRC) and I will edit this post and add them.
 
Usage (other than file server)
 
As I already stated, almost any cheap board can be a (minimal) 'file server.'  From that point of view, more powerful boards (like RK3399, or others) are overkill.  However maybe you want better throughput.  Or more disks.  Or, like me, you want to run advanced filesystem like ZFS (also with more disks).
 
Another thing which happens is that, once you handle the simple case of serving files, before you know it you will probably want to start doing more than that.  You may already have some more demanding requirements in mind beforehand.
 
For all these reasons, a slightly more powerful (and more expensive) board may be a better choice, as you will not be limited in the future.  But if you are very sure about your needs and wants, and have perhaps other boards on your network to handle processing intensive tasks, this may not apply to you.  Just something to consider.
 
Hardware Recommendations (RK3399 based)
 
For reasons mentioned at end of 'Historical Overview' section, many of us are fans of RK3399 based devices nowadays.
 
Within this subset, you will get a lot of opinions.    I know because I spent literally years asking people (including developers), while I was waiting for RK3399 to mature.  Some developers think certain vendors make crappy hardware (and maybe they are right).  Or they prefer the boards they know and develop on (naturally, IMO).  Some vendors support the project a lot more than others (PINE64, notably, do not support Armbian at all to my knowledge).  So you will have to do some amount of your own research, and form your own opinion here.
 
I don't want to discount any of the above criteria too much.  However, in the end, at least for me, one criteria bubbled to the top.  And that was direct PCIe (or SATA) support.  Since we are talking about RK3399 here, this means PCIe support.  Which of course is in the SoC, but that is not what I am talking about.  I am talking about putting a standard PCIe physical interface directly on the board.
 
This way, you can buy any standard cheap/dumb PCIe to SATA adapter card.  You can keep spares.  You will be able to obtain them for the foreseeable future.
 
By contrast, you can certainly rig up your own adapters, cables, etc. from GPIO.  But personally, I find that fiddly and it doesn't strike me as the most reliable.  I know some people are doing this just fine though.
 
Another way, is that many vendors sell some sort of HAT, which provides SATA connectivity.  However I find this short-sighted and -- quite frankly -- self-serving.  What if they are out of stock, or stop making them?  You are out of luck.  Or you would need to revert to the above option (rigging up cables and adapters).  It's good for them selling add-on hardware though I guess -- hence my 'self-serving' comment -- but maybe not the best for you and me in terms of keeping our important data available and up and running, on a long term basis.
 
Therefore I say, skip all of that and go with a board that has a standard physical PCIe right on the board.
 
ROCKPro64
 
And AFAIK, there is only one (standalone SBC) RK3399 that meets that description, which is ROCKPro64.  Of course, I am not the first to come to same conclusion, in fact there is a whole thread where myself and some other like-minded folks discuss using ROCKPro64 as NAS.
 
I say 'standalone SBC', because I almost forgot...
 
Helios 64
 
These of course are no longer made, and Kobol, our once partners, have unfortunately closed up shop.  However they still come up for sale on the forums from time to time (usually in Kobol Club but could be anywhere).
 
Here you would be getting a more integrated solution, often including a nice case, for perhaps a bit more money.
 
Some people have had problems with stability though, which I am not sure were ever fully worked out.  Have a look through Kobol club (linked above) and form your own opinion.
 
Hardware Recommendations (not RK3399 based)
 
ODROID HC4
 
ODROID HC4 was also brought up today, when this subject came up in IRC, by @rpardini as that is what he uses.  This is an interesting alternative to the above, except Amlogic (S905X3) based (like a lot of TV boxes).  Which to me means two things:
 
1. It almost certainly requires blobs.
2. It's probably cheaper than RK3399.
 
Well in fairness ROCKPro64 probably requires some blobs, too.  But somehow I get the impression that Amlogic are really obnoxious with their blobs, and I am not a fan of them as a company because of this.  Surely a developer will need to correct me here. 
 
Anyway, I am not sure how it compares in processing power.  I suspect less than RK3399(?).  However for media transcoding, it may actually be better (perhaps hardware decoders(?), speculation on my part).
 
Also for simple 'file server' use-case, in particular with Ceph or something like that, it becomes more interesting IMO.  Again, quoting rpardini from IRC today: "scale out, not up."
 
Future
 
There are newer SoCs, like RK3566 and others.  At this time, they are a lot like RK3399 was early on.  Very exciting, but not able to realize their full potential due to lack of (software/Linux) development.
 
The consensus among developers seems to be that RK3566 development should go faster/easier than RK3399 development, because of all the ground work that was laid in the course of the latter.  Maybe that's true, but we are still talking about some time.  Maybe less years, but still significant time.
 
If/when this changes, I will try and remember to update the post.  Feel free to ping me by posting, I should get notified.
 
Others?
 
Possibly anything in NAS category.  Which I mostly covered already (above, in more detail) but can always change in future.
 
Certainly I forgot (or don't know about) some others.  I have shared what I learned from my research the last several years while looking for solution for myself.  However I do want to make this a more general resource that we can all point to, so please discuss, and I will be happy to edit this post later on and add relevant info.
 
To clarify, I am not talking about 'any SBC which can be made into a file server' which is almost any of them, but rather particular hardware which is interesting for some specific reason(s), especially currently (or perhaps historically, which I would add to that section).
 
Cheers!
 
 

And here the video I made about the new release.
 

I came across these recently and found several interesting things within, so thought I would share them.
 
I debated posting this in Development, but wanted anyone to be able to see and reply to the thread.
 
Anyway some parts I felt were important enough that I actually took down some notes and quotations, which I will include.
 
Open drivers for Arm GPUs
This looks like it was presentation LVC21-318 at  Linaro Connect '21 on 2021-03-25.
 
Video is available at above page, and also on ThemTube here.
 
I found this a fascinating presentation.  Alyssa contrasts the (proprietary) 'before times' with current situation which is apparently quite different.  In fact, I was quite surprised to learn that:
 
 
She then goes on to give 3 case studies, one of which was VideoCore, where I was more than a little surprised to learn that Broadcom at some point actually hired someone to work on their F/LOSS driver.  Now this was only after that guy was well into his own (night and weekend) reverse engineering effort, followed by a lot of public pressure, but still.  End result apparently is that this driver is now shipping in production RPi 4.
 
Next case study was about Freedreno.  I will quote my favorite part from here:
 
 
Of course being firmly in the camp with the 'looney Free Software types' myself, this comment warmed my heart quite a bit. 
 
Finally she gives the Panfrost case study, where she points out that things are apparently moving away from the 'reverse-engineering underdog' model, and:
 
 
And so reverse engineering is apparently no longer needed.
 
Apparently this is the driver that ships in PineBook Pro for example.
 
Of course I must admit to being more than a little bit (pleasantly!) surprised at all of this.  And also starting to soften my stance towards Broadcom (just a little though, lol). 
 
If you are the least bit interested in any of this, I can highly recommend watching the full presentation.  It's only 19 minutes long, anyway, but I personally was riveted the entire time.
 
The Open Graphics Stack
I think this presentation was given at Embedded Linux Conference '21 on 2021-09-29.  So, about 6 months after the above.
 
But honestly I came across it on ThemTube here.
 
In the beginning, she makes a good point about the tension between embedded devices with perhaps 20 year life cycles, and devices with proprietary drivers which may be EoL in 5 years, and how this tension can be alleviated by using F/LOSS drivers.
 
But what got my attention the most was:
 
 
She then goes on about details of particular platforms (including x86, ARM, etc.) and then finally:
 
 
Which is a quite bold (and again, pleasantly surprising) statement IMO, but then again I do consider her an authority on the subject.
 
After that she goes into quite some detail about the nuts and bolts of all the various parts of the stack, which you may or may not be interested in watching as much.
 
 

And here the video I made about the new release.
 

And here the video I made about the new release.
 

Hi @yang and @TRS-80,
 
If it's not too late, I'd like to pick up OrangePi Zero Plus2 H3 as a maintainer.
I have two Plus2 boards with expansion boards, and can to test for releases and troubleshooting.
Don't have much experience in SW development, but have some as Linux basic admin.
 
As an experiment built an image for "BRANCH=current KERNEL_ONLY=no BUILD_DESKTOP=yes RELEASE=bullseye", all seems to work: http://ix.io/3Qdm.
I like the board and would like to keep it in the game.

Maybe @NicoDwants to test those.

You are violating the startup order, this is a test version and it does not contain startup scripts from the desktop. It needs to be run as an independent software. After booting the system, DO NOT log in to the desktop. Switch to any console (Ctrl+Alt+F1). We log in as a user (but it's better to use root, then there will be more control options) and launch kodi. The problems of a long startup may be related to new KODI packages or the latest version of the image with the 5.10.88 kernel (you can try earlier versions from yandex disk, there is a version with the 5.10.62 kernel). I have a system with the first versions of these packages, everything works quickly with them and the splash works.
 
I recommend using the correct package installation order.
 
 su -
 apt update
 apt install <full_patch>/kodi-mainline-bin_18.9-final-18.9bullseye0armbian1_arm64.deb
 apt install <full_patch>/kodi-mainline_18.9-final-18.9bullseye0armbian1_all.deb
(installing additional packages if they are needed)
 reboot

@balbes150I'm unable to make it work.
I downloaded the Armbian_21.11.0-trunk_Station-p1_bullseye_current_5.10.88_xfce_desktop
Downloaded the deb files. https://users.armbian.com/jmcc/packages/kodi-mainline/arm64/
First tried with only the kodi-mainline-bin and kodi-mainline files
 
sudo apt install libcec6 libfmt7 libfstrcmp0 libgles2 liblirc-client0 libmariadb3 libtinyxml2.6.2v5 libmicrohttpd12 libpcrecpp0v5 libpython2.7 sudo dpkg -i kodi-mainline-bin_18.9-final-18.9bullseye0armbian1_arm64.deb sudo apt install libaacs0 libboost-python1.74.0 libshairplay0 libxxf86dga1 python3-bluez python3-gattlib python3-simplejson x11-utils sudo dpkg -i kodi-mainline_18.9-final-18.9bullseye0armbian1_all.deb When I try to start Kodi it kind of crashes the desktop. Mouse and keyboard stop working. Can't do anything. It does stay on the desktop, and the desktop is still running. I tried with a terminal window with htop running and htop was still running. But I was unable to do anything. Also couldn't switch with ctrl-alt-Fx
This is the same with either sudo kodi or without.

I then also tried with installing all the deb kodi files. But no change here.
I tried again with a fresh install and the same.
Did I download the wrong image? It is an older image, but the most recent 5.10 bullseye as you said.

Some other things. It takes a long time before it starts booting. About a minute after power on you see the first things on screen. And the led isn't on. It blinks one time when boot initiates. But then it stays off.
I think I remember this was working in the past.

I also notices the black spots in windows that other people talk about. Seems a graphical glitch, composer or GPU. I don't have that on my M4 with 5.14(old image).
And Firefox also crashed out of the blue. Just to let you know. Cheers.

You are behind the current state of rk3399 support. Now there is already support for HW GPU and VPU. I'm testing this on Firefly Station P1 (rk3399), everything works fine (kernel 5.1x), including 4k.
 
 
info glmark2 for Station P1
 
https://forum.altlinux.org/index.php?topic=36166.msg364846#msg364846
 
 

Hi all. In this video I show how to install Open Media Vault on your SBC with Armbian Buster.
I've used the Odroid HC4, this is the same for any board you'd like to use. 
Here my video.
Greetings.
NicoD

Hi,
Many thanks for your thorough and informative review. In a difficult year, and with two of my development machines failing, I rashly bought 3 4Gb Pi-400s and 2 of the pi keyboard/hub units.
I too, had problems with under-voltage on both machines. Fortunately, I have installed an uninterruptible DC 14v ring in my house, and use DC-DC converters to step the voltage down to around 5.3, for these machines, which as you have noted, gets around the problem. As for the keyboard? All 5 of the keyboards have at least one consistent problem - 'h' key, and lesser so, some of the number keys.
By far the worst problem, and one which you haven't mentioned, is during editing - particularly cut & paste using the mouse. I'm using 'Buster', and no editor is safe, whether it is geany, Thonny, Visual Studio or editing a WordPress post. 'cut sections get dropped into inappropriate places in a file or in BOTH files if I'm transferring from one to the other. The only 'safe' option is VIM, which points very strongly to the mouse and/or it's driver.
raspberry.pi.org have apparently lost the plot. There are other issues, especially with the Raspian OS'es. The last decent version of Raspbian was jessie. Everything after it is a mess.
My main development focus is on monitoring and control, and this includes website development, backend server, plus wifi-connected slaves such as the pi-zero, and latterly WEMOS D1.
Your review has prompted me to do two things: 1 - try Manjaro on thhe Pi400's, and 2: examine using Armbian on an Odroid XU4 which is currently unemployed.
Many thanks again NicoD.
 

Why don't you use flatpak?
I used it in my RK3399 board and it runs great. I got the latest release of PPSSPP on Armbian Focal.
But because the lack of OpenGL ES 3.2 and Vulkan Driver, a demanding game like God of War Chain of Olympus only get around 16-18 fps (2x res, autoframeskip).
For a middle game title it runs almost full speed. Like DragonBall Z Shin Budokai 60 fps, Daxter 30 fps with the same setting (2x res, autoframeskip)
sudo apt install flatpak flatpak search ppsspp flatpak install org.ppsspp.PPSSPP I also got Dolphin & Flycast Emulator with quite great performance from flatpak. But maybe dolphin need the driver for OpenGL ES 3.2 or Vulkan to get a higher framerate. Currently the only two-emulator that don't work from apt package or Flatpak are N64 Emulator and RetroArch (Installing core is disabled).

Yes, after running your script manually in Armbian Focal. I have a lot of dependencies conflict especially from armhf package vs. arm64 package. As a result almost all my 64bit program that has dependencies conflicts were removed from the system.
 
After a while, I looked at how TwisterOS do this beautifully without any dependencies conflict. When building Box86 in TwisterOS, I just realized that TwisterOS only need this "arm-linux-gnueabihf" library files. Then I copied this library and pasted them to my Armbian Focal in /usr/ folder.
 
After that I fixed all dependencies conflict by using "sudo aptitude install" and remove all armhf package that has conflict.
 
Magically, all the conflicts were gone and as what I suspected that Box86 could compile successfully even without armhf package dependencies.
 
Now I am very happy because I can run both Box86 and Box64 without interfering each other. even wine32, wine64 and winetricks are working.

I'll say that this Library Method is better than the Schroot Method. But I am not sure for some distributions that do not support Multiarch like Manjaro, whether this Library Method is working or not. If it isn't then they have to stick with the Schroot Method.
 
I am not good at github and scripting. I trust you, maybe you can try first. If it works, then you can update the armbian-config on Github with the command that I wrote.

Many Thanks @NicoD

Dear All,
I just want to share my workflow of successfully installing Box86-Box64, Wine32-Wine64 and Winetricks on Arm64
Big thanks to @NicoD for sharing his source code of Armbian-Gaming. I modified some of his code to be used in Armbian Focal (or any Arm64 distro) and fix the armhf dependencies issue by using the "arm-linux-gnueabihf" Library from TwisterOS. I also used some of Box86 Manual. So many thanks to all of them.
 
Ok Let's Start:
 
1. Add armhf multiarch
sudo dpkg --add-architecture armhf sudo apt-get update 2. Install dependencies for box86 & box64
sudo apt-get install git cmake cabextract gcc-arm-linux-gnueabihf libc6-dev-armhf-cross
Then download these "arm-linux-gnueabihf" files and extract them on folder /usr/
(Alternatively, you can manually copy paste the "/usr/arm-linux-gnueabihf" folder from TwisterOS and transfer it to your arm64 OS. This file contains dependencies for Box86)
*NOTE: I split the files because Armbian site doesn't allow me to upload more than 1,5MB.
arm-linux-gnueabihf.7z.001 arm-linux-gnueabihf.7z.002 arm-linux-gnueabihf.7z.003 arm-linux-gnueabihf.7z.004
 
3. Compile box86 for general ARM64 board (read box86 manual for more info about your board)
cd git clone https://github.com/ptitSeb/box86 cd box86 mkdir build cd build cmake .. -DARM_DYNAREC=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j3 sudo make install sudo systemctl restart systemd-binfmt cd 4. Compile box64 for general ARM64 board (read box64 manual for more info about your board)
cd git clone https://github.com/ptitSeb/box64 cd box64 mkdir build cd build cmake .. -DARM_DYNAREC=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j3 sudo make install sudo systemctl restart systemd-binfmt cd 5. Restart your Computer
6. Install Wine32 & Wine64 (Merged is the best option, and please follow the sequence accordingly. Currently at the time of writing, wine 5.21 & Wine 6.0.2 have the best support from Box86-Box64. You can also try a different version of wine if you want)
    #Wine 5.21
cd cd ~/Downloads wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-i386/wine-devel-i386_5.21~buster_i386.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-i386/wine-devel_5.21~buster_i386.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-amd64/wine-devel-amd64_5.21~buster_amd64.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-amd64/wine-devel_5.21~buster_amd64.deb dpkg-deb -xv wine-devel-i386_5.21~buster_i386.deb wine-installer dpkg-deb -xv wine-devel_5.21~buster_i386.deb wine-installer dpkg-deb -xv wine-devel-amd64_5.21~buster_amd64.deb wine-installer dpkg-deb -xv wine-devel_5.21~buster_amd64.deb wine-installer mv ~/Downloads/wine-installer/opt/wine* ~/wine rm -rf wine-installer cd     #Wine 6.0.2 Stable
cd cd ~/Downloads wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-i386/wine-stable-i386_6.0.2~buster-1_i386.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-i386/wine-stable_6.0.2~buster-1_i386.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-amd64/wine-stable-amd64_6.0.2~buster-1_amd64.deb wget https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-amd64/wine-stable_6.0.2~buster-1_amd64.deb dpkg-deb -xv wine-stable-i386_6.0.2~buster-1_i386.deb wine-installer dpkg-deb -xv wine-stable_6.0.2~buster-1_i386.deb wine-installer dpkg-deb -xv wine-stable-amd64_6.0.2~buster-1_amd64.deb wine-installer dpkg-deb -xv wine-stable_6.0.2~buster-1_amd64.deb wine-installer mv ~/Downloads/wine-installer/opt/wine* ~/wine rm -rf wine-installer cd  
7. Create Symlink to Wine
sudo ln -s ~/wine/bin/wine /usr/local/bin/wine sudo ln -s ~/wine/bin/wineboot /usr/local/bin/wineboot sudo ln -s ~/wine/bin/winecfg /usr/local/bin/winecfg sudo ln -s ~/wine/bin/wineserver /usr/local/bin/wineserver sudo chmod +x /usr/local/bin/wine /usr/local/bin/wineboot /usr/local/bin/winecfg /usr/local/bin/wineserver 8. Setting Wine32 Folder in ~/.wine (set win32 as wine default, because currently winetricks doesn't work in win64. I would gladly use win64 as my default setup only if winetricks works in win64 in the future).
 
WINEPREFIX=~/.wine WINEARCH=win32 wine winecfg 9. Setting Wine64 Folder in ~/.wine64
WINEPREFIX=~/.wine64 WINEARCH=win64 wine winecfg 10. In Home Folder Create alias in .bashrc (to make shorter command for wine64)
cd nano .bashrc        --> enter this command
alias wine64="WINEPREFIX=~/.wine64 wine"       --> then save (ctrl+x, choose yes)
      --> then logout & login
 
11. Installing & Running 32bit Windows app
wine uninstaller wine /File/can/be/drag/and/drop/32bit.exe 12. Installing & Running 64bit Windows app
wine64 uninstaller wine64 /File/can/be/drag/and/drop/64bit.exe  
13. Install Winetricks
sudo apt-get install cabextract -y cd ~/Downloads && wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks sudo chmod +x winetricks && sudo mv winetricks /usr/local/bin/ 14. Using Winetricks (ex: Corefonts & Dotnet 4)
BOX86_NOBANNER=1 winetricks BOX86_NOBANNER=1 winetricks corefonts dotnet40 15. Creating Wine Desktop Launcher
Now create a launcher in the desktop with this code in the command section:
wine explorer /desktop=shell,1280x720 explorer.exe  
As an alternative, I personally like explorer++ mainly because of its GUI and additional feature compared to the original wine explorer. You can download it from here: https://explorerplusplus.com/software/explorer++_1.3.5_x86.zip and then extract it, and then rename to "explorer++.exe" (with small e, not capital E), then copy-paste it to the ~/.wine/drive_c/windows. Then create a launcher in the desktop with this code in the command section:
wine explorer /desktop=shell,1280x720 explorer++.exe  
 
 
**NOTE:
- With this setting I am able to run Box86 and Box64 without having dependencies conflict between armhf package and arm64 package.
- I used the win32 as my default wine. Alternatively you can also use win64 as your default ~/.wine setup. It is up to you (In fact, by default it will create win64 setup in your ~/.wine folder).
- For RK3399 users, you can use these scripts to Install and Update Box86 & Box64:
install_box86.sh install_box64.sh update_box86.sh update_box64.sh
 
I hope this could help somebody out there. Have a Nice Day!
RNA
 
 

Hi thanks for the excellent job with armbian. I don't have much experience but I want to learn and colaborate as board maintainer.
 
My board is an orangepipc.
github: https://github.com/lbmendes

Hi all.
You might have already heard. Armbian is aiming to support the Raspberry Pi4. @rpardini already made well working images for it.
In this video I talk about why we would want Armbian for the RPi4, and I show you around in Armbian Jammy 5.13 for the RPi4.
 
 
We do need to find someone who wants to take the task on him/her to be maintainer for RaspberryPi4 at Armbian.
For this you need one spare board that can be used for testing when new release are made.
Here some info I gathered.

 
Raspberry Pi 4 cooled with big heatsink on SoC and fan on-top Board | SBC-Bench | Distro | Clockspeeds | 7z all cores | 7z small core | 7z big core | CPU-Miner | NicoD-Blender | Max temp | C copy backwards NanoPi M4 2GB http://ix.io/3xnJ Armbian Hirsute xfce4 5.13.12 1.4Ghz/1.8Ghz 7760 1267 1857 10.05 14m41s 78C *** 1782.9 MB/s NanoPi M4 2GB http://ix.io/3xv3 Armbian Hirsute xfce4 5.13.12 1.5Ghz/2Ghz 8288 1348 2070 10.95 13m21s *** 1806.7 MB/s NanoPi M4 2GB http://ix.io/3xs3 Armbian Hirsute cinnamon 5.13.12 1.4Ghz/1.8Ghz 7766 1267 1851 10 14m33s 78C 1742.6 MB/s NanoPi M4 2GB http://ix.io/3xt0 Armbian Hirsute budgie 5.13.12 1.4Ghz/1.8Ghz 7941 1272 1863 10.05 14m24s/14m18s 78C 1738.3 MB/s NanoPi M4 2GB http://ix.io/3xtR Armbian Buster xfce4 4.4.213 1.5Ghz/2Ghz 8383 1359 1982 10.8 14m17s 1377.3 MB/s NanoPi M4 2GB http://ix.io/3xuf Armbian Buster xfce4 4.4.213 1.4Ghz/1.8Ghz 7879 1278 1807 10 15m20s 1392.3 MB/s NanoPi M4 2GB http://ix.io/3xux Armbian Focal xfce4 5.10.60 1.4Ghz/1.8Ghz 8028 1286 1859 10.27 13m29s *** 1765.3 MB/s NanoPi M4 2GB http://ix.io/3xuL Armbian Focal xfce4 5.10.60 1.5Ghz/2Ghz 8427 1351 2076 11.2 12m53s *** 1759.9 MB/s NanoPi M4 2GB http://ix.io/3EDB Ubuntu Xenial armhf 4.4 xfce4 1.4Ghz/1.8Ghz 7069 1140 1695 1387.1 MB/s Board | SBC-Bench | Distro | Clockspeeds | 7z all cores | 7z small core | 7z big core | CPU-Miner | NicoD-Blender | Max temp Odroid C4/HC4 http://ix.io/2LaP Ubuntu Mate 4.9 1.91Ghz 7000 1769 7.2 kH/s 2087.5 MB/s Odroid C4/HC4 http://ix.io/3F6z Armbian Buster 5.9 2.10Ghz 7971 2030 7.9 23m02s 2020.0 MB/s Khadas VIM3 Armbian Hirsute cinnamon 5.13.12 12m55s Raspberry Pi4 http://ix.io/3F6o Armbian Jammy 5.13 2Ghz 8047 2070 Didn't work Blender doens't work 2054.3 MB/s Raspberry Pi4 http://ix.io/3F6K Armbian Jammy 5.13 1.5Ghz 6239 1572 2556.8 MB/s Raspberry Pi4 Armbian Hirsute edge xfce4 5.11 1.5Ghz 5832 1534 18m11s 60C Raspberry Pi4 http://ix.io/3Euw Armbian Hirsute edge xfce4 5.11 2Ghz 7747 2037 9.8 14m26s 68C 2382.2 MB/s Raspberry Pi4 http://ix.io/3FbW Armbian Hirsute 5.11 OC GPU+CPU 2.1Ghz 8168 2147 Blender crash 2445.0 MB/s Raspberry Pi4 http://ix.io/3EU7 Armbian Impish edge headless 5.13 1.5Ghz 6251 1584 15m39s 2618.0 MB/s Raspberry Pi4 http://ix.io/3Ewi Armbian Impish edge headless 5.13 2Ghz 8171 2093 12m41s 2713.7 MB/s Raspberry Pi4 http://ix.io/3EPQ Armbian Bullseye edge headless 5.13 1.5Ghz 6328 1594 7.3 Blender doesn't work 2680.5 MB/s Raspberry Pi4 http://ix.io/3EK9 Armbian Bullseye edge headless 5.13 2Ghz 8242 2096 9.7 Blender doesn't work 2505.4 MB/s Raspberry Pi4 http://ix.io/3ECd Raspberry Pi OS Bullseye 32-bit 1.5Ghz 7577 1933 21m09s 2511.7 MB/s Raspberry Pi4 http://ix.io/3ECt Raspberry Pi OS Bullseye 32-bit 2Ghz 9746 2533 17m05s 2263.0 MB/s Raspberry Pi4 http://ix.io/3EIe Raspberry Pi OS Bullseye 64-bit 1.5Ghz 6174 1567 7.2 17m01s 2463.5 MB/s Raspberry Pi4 http://ix.io/3EJs Raspberry Pi OS Bullseye 64-bit 2Ghz 8026 2053 9.65 Blender unstable at 2Ghz 2326.1 MB/s Raspberry Pi4 http://ix.io/3EGZ Ubuntu 21.10 (Impish) 5.13 arm64 1.5Ghz 6160 1563 16m50s 2421.2 MB/s Raspberry Pi4 http://ix.io/3EHA Ubuntu 21.10 (Impish) 5.13 arm64 2Ghz 7965 2038 Didn't work Blender unstable at 2Ghz 2501.9 MB/s Odroid N2+ http://ix.io/3EwQ Armbian Impish xfce4 5.14 2Ghz/2.4Ghz 11714 1765 2517 8m51s 2053.0 MB/s Raspberry Pi4 SD->USB3 with SandDisk Extreme 89.7 MB/s read SD with on-board sd-card reader Sandisk Extreme 45.4 MB/s read (rather slow compared to 70MB/s for M4) RPi4 fastest memory, then N2+, then M4(lpddr3) Armbian Impish 2.93.5 Raspberry Pi OS Bulsseye 32-bit/64-bit blender 2.83.5 Ubuntu 21.10 Blender 2.93.3 Armbian Jammy Blender goesn't work / bug *** Ubuntu 21.10 unstable when installing ubuntu-mate-desktop, Unity very slow Armbian on RPi4 pro's + Having the same platform for RPi and other Armbian supported boards + Reliability/ stable + ARM64 vs armhf of RaspberryPiOS/Ubuntu unstable at high clocks and a lot of bugs and hangs + Ubuntu and Debian images and all their versions + Great for server tasks + Customizable + You can build your own RPi4 images with whatever modules you need Armbian on RPi4 con's - Not great for desktop use (yet) - No VPU drivers, video playback firefox ok up to 720p - Audio glitchy, no audio on some images like Jammy *** For audio install pavucontrol *** On-board wifi and dongles don't work with the Armbian Impish and Bullseye images. Dongles work on Hirsute. I guess kernel issue 5.13 -> 5.11 *** Armbian Bullseye 5.13 USB not always working Install desktops sudo apt install xfce4 (ubuntu-mate-desktop, kubuntu-desktop, lubuntu-desktop, ubuntu-desktop, ...) sudo apt install lightdm sudo apt install lightdm-gtk-greeter sudo apt install pavucontrol sudo apt install xinit Power draw at 5.3V headless 1.5Ghz with fan maxed out 0.95A 2Ghz with fan maxed out 1.10A To do - M4 Impish - Gather the info I've got from other boards and my pc's
And for those who don't like watching a video, here a short text of what I talk about.

 
What is Armbian? What is the Armbian build framework which is one of the valued pro's compared to RPiOS? Why Armbian for RPi4? For software compatibillity with other Armbian supported SBCs, Reliabillity, ARM64, Ubuntu and Debian and their versions, great for server tasks... Accentuate this is only a preview, not full release or supported Show Armbian download page Show the NanoPi M4 and Odroid N2+, talk about their specs(short) Difference between other SBCs and RPi/ThreadX - Under Voltage problems/eMMC and NVMe possible on others(better I/O) What doesn't work yet on Armbian for RPi4. Wifi, BT and HDMI sound Show Armbian Impish, show htop, install desktops, Benchmarks between different OS's. Explain they aren't worth much since, different versions of software, different architecture armhf vs arm64, 7zip multicore doesn't play well on different sized clusters, and doesn't always give exact the same result... !!!Test the performance of the software you use to know if this is the correct tool for you!!! Show different desktop environments installed on Armbian - Not the Armbian default desktops - mate doesn't work great, xfce4 works ok, kde works but is slow(newer version should improve that soon)Change openGL2->OpenGL3, ... Performance of I/O. Better to use a good but cheap usb3 sd-card reader than on-board sd-card reader. ssd/NVMe->USB3 even better. ???Would you like to become RPi4 Armbian maintainer??? Or for another board??? Conclusion. Good for RPi community to have even more choice. Good for Armbian community to be able to use the same software on their RPi devices as on their others. Good for Armbian to reach more people and have more awareness about other boards. Having a good build environment to build your own images/kernels/patches for the RPi4.  

@NicoD
why only for the RPI4?
I commented out (like you said in the video) the 2GHz overclock out of the config.txt and booted the image on the RPI3b(+)
for a headless-server-only version (No Desktop)
 
Little problem was the /erc/rc.local where I mount my SAMBA from another pistyle-sbc, because the Network card is getting up very late.
So I had to add a "sleep 20" at the beginning of my /etc/rc.local
 
Armbian on my the RPi 3B v1.2 takes around 185MB for booting - so enough space to do something
 
Because onboard audio doesnt work I used a USB-Audio with a proper /etc/asound.conf
 
After a "dpkg-reconfigure console-setup" the RPi does copy many new/current modules again and seem to setup the system better.
 
To gain back some memory from the RPi3 I changed the GPU memory in the config.txt from 256MB to 32MB to get 950MB useable for the headless-server
 
armbianmonitor -u result at:
http://ix.io/3Fly
 
 

In current armbian-config,  we have a broken desktop install on top of CLI images, while I have made several checks and come to a conclusion its fairly simple to install desktop. Which could be a nice first working functionality in the new armbian-config. And a reason to start moving on.  

1. Available desktops per release for select box:
 
apt-cache search armbian-$(grep VERSION_CODENAME /etc/os-release | cut -d"=" -f2)-desktop- | cut -d" " -f1  
armbian-focal-desktop-gnome
armbian-focal-desktop-xfce
armbian-focal-desktop-budgie
armbian-focal-desktop-cinnamon
armbian-focal-desktop-deepin
armbian-focal-desktop-i3-wm
armbian-focal-desktop-mate
armbian-focal-desktop-xmonad
 
All those exists in repository and are up2date.
 
2. Installation
 
echo lightdm | sudo tee -a /etc/X11/default-display-manager DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true apt-get install --install-recommends -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -y armbian-focal-desktop-xfce  
3. After install - more or less copy / paste
https://github.com/armbian/config/blob/master/debian-config-functions#L780-L819
 
I would start, but my brain is stuck in stack overflow mode  

Hello, recent upgrades to armbian are regarding kernel 5.15.
I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.
mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.
 
This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:
Rockchip RK3228/9 (kernel 5.10, 5.14) Rockchip RK3288 (kernel 5.14) Rockchip RK3318/28 (kernel 5.15)  
It should work on allwinner platforms too, but I didn't test it there.
Binaries are built by me on developing boards.
 
The binary for armhf is available here
The binary for arm64 is available here
 
Copy the binary into /usr/local/bin directory of your system (mpv-armhf for 32 bit systems, mpv-arm64 for 64 bit systems):
sudo cp mpv-armhf /usr/local/bin/mpv  
Install dependencies for Debian Bullseye and Ubuntu Hirsute:
apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2  
I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.
I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.
There may be the need for some other dependency depending upon your actual installation.
 
Run mpv in a virtual terminal (videos up to 4K) with this CLI:
mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>  
Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:
mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>  
This is an experiment and your mileage may vary a lot:
H.264 codec should be well supported around the boards; H.265 has more limited support VP8 should be generally supported VP9 seems to still require some work.

Hi all.
I've done a collaboration with @Igor, the creator of Armbian.
He shows and talks about the hardware that is used to maintain the project. Servers, boards, other electronics, ...
Enjoy!

More videos to come.
 

I'd be happy to assist with Pinebook Pro maintenance. github.com/seclorum
 

Hows this