Werner

I received the NVMe hat last week. I tried it and it doesn't seem to be working.
The case also isn't made for it. You need to remove the case except for the bottom plate to be able to plug the hat in. 
The wifi antenna is also glued with hot glue to the board. I needed to remove that to have the space for the hat.


The spacers also were too high to be able to plug the hat.

So I replaced them with lower spacer.
 
Then I was able to plug in the hat. But using my 512GB Samsung EVO 970 I couldn't make it recognize it in either Buster Legacy and Focal Mainline. Neither in Android.
I also tried other NVMe's, and none did work. 

A bit a pity they didn't hold the NVMe hat into account when designing the case. 

A little more detailed explanation about CREATE_PATCHES: https://zuckerbude.org/armbian-using-create-patches/

Done

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

https://zuckerbude.org/the-pinebook-pro/

No support for anything other than Armbian 
 
Yes, I realized it recently. Only 32-bit userspace will have Widevine DRM. I thought to make Kodi run in a 32-bit docker container, but there is no ETA for that project.

I'll take a closer look into that : )

@Werner How about changing this topic title, or splitting all posts except the very first ones to a new one, calling it "Station P1/M1 Board bring up"?

Let's do it
 
P.S.: Not a big fan of ZSH so far. I installed it on my Ubuntu PC, and it all just looked like an unconfigured BASH, needing plenty of work to make it useful. I guess the Armbian version comes pre-configured, I'll give it a chance in some near future.

Hey fellows,
 
quite a while ago we started working on a better way to guide users through the way of properly reporting bugs at the correct places and help them avoid common issues the same time. We came up with a form that, depending on users input and conditional logic, leads to the correct place or a dead-end with explanation why specific bugs are not accepted.
 
A link to this has been added to the documentation, the download page for each board and will pop up when creating a new topic in the bug tracker forums.
 
We appreciate your feedback and bring issues with the form to our attention. We are also aware that using Google forms is everything but ideal but in my opinion it is a good point to start with. If you know a good way to implement this in WordPress or even have a proof-of-concept handy we'd love to hear from you. Put your thoughts below this topic:
 
For those who want to test it directly, here it is https://www.armbian.com/bugs

I found a hothotfix solution without knowing the (side) effects.
 
# 0,1,2,3=Quad-core Cortex-A53 up to 1.4GHz
# 4,5=Dual-core Cortex-A72 up to 1.8GHz
root@helios64:~# cat /proc/cpuinfo |grep -e processor -e part
processor    : 0
CPU part    : 0xd03
processor    : 1
CPU part    : 0xd03
processor    : 2
CPU part    : 0xd03
processor    : 3
CPU part    : 0xd03
processor    : 4
CPU part    : 0xd08
processor    : 5
CPU part    : 0xd08
 
# always assign the same cpu types to a VM. core 0,1 for the host system
virsh edit VM1
...
<vcpu placement='static' cpuset='2-3'>2</vcpu>
...
virsh edit VM2
...
<vcpu placement='static' cpuset='4-5'>2</vcpu>
...

It looks like sufficient support for defaulting ZSH is not going to happen  But it will remain as a second choice ... lets repeat this question year later.

Speaking on armbian-config ... @tparys started to help on enhancements, I do what I can ... still more helping hand is needed. It's a long term job. Any idea how to get more movement there? Yes, its a wonderful tool, but require constant love. Like other parts of the project.

https://github.com/armbian/config/pull/135
 
In case anyone wants to try and break it.
 

Finally found the problem - HW "issue". My SPI flash is not soldered (no place on motherboard) - it is connected with wires which are (presumably) too long. Workaround is to reduce SPI speed in u-boot and Linux.
 
U-boot:

diff --git a/arch/arm/dts/rk3399-rockpro64.dtsi b/arch/arm/dts/rk3399-rockpro64.dtsi index 9bca258012..797dd80d38 100644 --- a/arch/arm/dts/rk3399-rockpro64.dtsi +++ b/arch/arm/dts/rk3399-rockpro64.dtsi @@ -677,7 +677,7 @@         flash@0 {                 compatible = "jedec,spi-nor";                 reg = <0>; -               spi-max-frequency = <10000000>; +               spi-max-frequency = <1000000>;         };  };
 
Linux:
Recompile your device tree with reduced SPI speed:

        flash@0 {                 compatible = "jedec,spi-nor";                 reg = <0>; -               spi-max-frequency = <10000000>; +               spi-max-frequency = <1000000>;         };

Suspecting media failure / image making trouble. I'll try to reproduce.

I have begun to make some changes to the TV Box 'Club' area.
 
The overall goal is to provide more useful information to users and reduce the support workload of answering the same questions over and over again.
 
To that end there is now a FAQ forum on the menu.  While it is currently empty and just a place holder it should provide a centralized location for TV Box information over time.
 
The second new addition is the forum titled 'TV Boxes running Armbian'.  The idea here is to provide a maintained list of current information with links to the details for boxes reported by the community to be successfully running armbian.
 
Both of the two above forums will likely be strictly moderated to keep the information concise and on topic.  I don't want these to become mega threads (like some of the TV box threads tend to be).  Content that gets posted here that belongs elsewhere will be moved.
 
I'm still trying to figure out how the rest of the area should be organized.  There needs to be a place for newbies to ask questions and it would be nice if there was a place for developers to share information.  The problem is that the current mega threads for the Rockchip CSC builds do that in a single thread, vs using one or more forums for that.  Also I wonder if there should be different forums by CPU family (AML,RK,AW?) by developer build (Balbes vs Jock's CSC builds?).  Any suggestions on how others think things should be organized?
 
  

Mostly because I was bored and for self-educational purpose I desigend a custom fan hat for the Nanopi R4S.
Planned to mill it from 2mm aluminum.
 
As reference I created a heavily simplified version of the board (4GB version) using the provided 2D drawing from Friendlyarm.
 
Fan: https://www.amazon.de/dp/B071JN6HKM?ref=ppx_pop_mob_ap_share
Heat sink: https://www.aliexpress.com/i/4000107291369.html
Bolts and nuts: Whatever fits... M2
 
 


Baugr1.mkv

Mostly because I was bored and for self-educational purpose I desigend a custom fan hat for the Nanopi R4S.
Planned to mill it from 2mm aluminum.
 
As reference I created a heavily simplified version of the board (4GB version) using the provided 2D drawing from Friendlyarm.
 
Fan: https://www.amazon.de/dp/B071JN6HKM?ref=ppx_pop_mob_ap_share
Heat sink: https://www.aliexpress.com/i/4000107291369.html
Bolts and nuts: Whatever fits... M2
 
 


Baugr1.mkv

Might also be worth discovering the idea about an external addon case for further 3,5" harddrives...
@gprovost you heard what we want: Go big or go home

@Werner Hahaha yes we are working at improving the design ;-) More news soon.

I know this topic's already marked solved, however wanted to add something interesting that I found in my travels.
 
If for some reason a software software controlled read-only switch isn't sufficient, it is actually possible to make a MicroSD card read-only.
 
https://github.com/BertoldVdb/sdtool
 
I'll still echo that overlayroot is generally the way to go. But in some applications that may not be sufficient.
 
And the permlock function does work as advertised.

Some day I have to test this ZFS. I'm too attached to the good ol' EXT4 

After checking, /var/log/armbian-hardware-monitor.log 
I detected btrfs did not exist in my build. I went back to lib/configuration.sh and saw btrfs-progs package was not installed if BUILD_MINIMAL = YES. 
 
if [[ "$BUILD_MINIMAL" != "yes"  ]]; then     # Essential packages     PACKAGE_LIST="$PACKAGE_LIST bridge-utils build-essential fbset \         iw wpasupplicant sudo linux-base crda \         wireless-regdb unattended-upgrades \         console-setup unicode-data initramfs-tools \         ca-certificates expect iptables automake html2text \         bison flex libwrap0-dev libssl-dev libnl-3-dev libnl-genl-3-dev keyboard-configuration"     # Non-essential packages     PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL alsa-utils btrfs-progs dosfstools iotop stress screen \         ntfs-3g vim pciutils evtest pv libfuse2 libdigest-sha-perl \         libproc-processtable-perl aptitude dnsutils f3 haveged hdparm rfkill vlan bash-completion \         hostapd git ethtool unzip ifenslave libpam-systemd iperf3 \         software-properties-common libnss-myhostname f2fs-tools avahi-autoipd iputils-arping qrencode sunxi-tools" fi  
I changed then this from
 
PACKAGE_LIST="bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
to
 
PACKAGE_LIST="bc btrfs-progs cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
And now it works. I suppose btrfs-progs needs to be added to PACKAGE_LIST (or DEBOOTSTRAP_LIST?) only in the case ROOTFS_TYPE=btrfs and irrespectively of BUILD_MINIMAL.

Shared lines are not uncommon even on x86 mainboards. For example: https://www.asrock.com/mb/intel/fatal1ty z97 killer/#Specification
Take note at Storage and Slots sections:
That is to mention as addition to @tommitytom.
You can try to sell it in forums. I already noticed a few people who did this successfully here. However if I were a potential buyer I'd consider a person with such an attitude not necessarily trustworthy