Werner

IIRC I already agreed to changing the patch naming scheme for rockchip64 legacy kernels in the github discussion few weeks ago.
I would interpret the lack of response from others as indifference ;p
... or are we talking about other missing response?
 
BTW. I also received my mezzanine board which I reordered from AliExpress seller after previous order being cancelled resulted in a refund.
The order went smooth this time. 

With Armbian v20.11 one can write mainline u-boot image to board's SPI and enjoy booting nvme drives without any mmc devices.
Prerequisities: ROCK Pi 4(A/B/C) v1.4 or 1.3 with SPI soldered in (v1.3 comes without SPI flash from the factory).
 
If you already have Radxa's u-boot written to SPI you need to short pins 23 and 25 for Armbian to boot Boot fresh image of Armbian v20.11.x for ROCK Pi 4(A/B/C) Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's  enable spi-nor by executing (as root):
echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running
ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run nand-sata-install choose option: "Boot from SPI - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit Reboot Enjoy Armbian booting with SPI / NVMe  
Why bother with mainline u-boot?
It is known to boot some NVMe drives that legacy u-boot from Radxa has issues with, eg. SAMSUNG 970 EVO Plus and SAMSUNG PM981.
This does not mean that all NVMe drives are supported, YMMV.
 
Which NVMe drives are known to be working?
Corsair MP510 240GB/480GB/960GB
Gigabyte SSD M.2 2280 PCIe x2 Model:GP-GSM2NE8128GNTD
HP SSD EX900 M.2 NVMe 120GB. Model: 2YY42AA#ABB
Intel SSD 660p Model:SSDPEKNW512GB
Kingston A1000 SSD 240GB (PHISON PS5008-E8-10)
Kingston A2000 M.2 2280 PCIe NVMe
PNY 250GB XLR8 CS3030 M.2 NVMe SSD PCIe Gen3 x4
Sabrent Rocket 256GB NVMe PCIe M.2 2280
Samsung 970 EVO Plus SSD 250GB M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s
Samsung PM981 256GB
XPG SX6000 Lite 128GB (ASX6000LNP-128GT-C)
 
Why not using Radxa's u-boot SPI image?
Ambian's u-boot configuration is incompatible with Radxa's SPI image
 
Why Armbian is using u-boot that is incompatible with Radxa's?
It uses mainline u-boot with Open Source TPL/SPL/proper and BL31 from Rockchip packaged into u-boot and we may switch to using open source ATF instead of the BL31 in the future.
 
Can I boot Radxa's images with Armbian's u-boot written to SPI?
Yes. Armbian's SPI u-boot is compatible with Radxa's images available here: https://github.com/radxa/rock-pi-images-released/releases
It may not be compatible with some older images (released before July 2020) because of the device tree filename change.

Hey Werner,
 
I went ahead and escalated this issue to Innoscale's NOC and they have been reviewing things this afternoon.  It looks like at this time the NOC has pushed out some new routes which looks to have helped to resolve the loss being seen there and causing latent loading of the forum / site.
 
Can you test a bit and let us know if things still continue to see issue via IPv6?
 
I will sub to this so that and updates come to my inbox and can be addressed.
 
Have a great day!
 
Regards,
TheBug

from scratch... I'm working out the exact process now to automate it.  When I have the scripting worked out, I'll format it into proper Armbian format and submit a PR. It was all pretty straight forward to accomplish manually.  Wipe the NVMe and setup several logical partitions to use as encryption stores, add them to fstab, etc. It's all working now.  My biggest gripe is which kernel is supported... so far this is only working on legacy 4.4 and I really want to use 5.7+

I have Wayland/sddm/Sway working as well and will be integrating that as my default managers.

My needs are a little different, I have a fairly tight device in the making.

Yes, I'm working on adding patches.

Are you mainly going to participate live, listen later to recordings or not at all? Any topics that are related, close to single board computer world to recommend?

I am still working on my "shopping list", but this is some initial draft from https://fosdem.org/2021/schedule/
 
QA
About the joy and tears of testing Embedded Devices
https://fosdem.org/2021/schedule/event/testing_embedded_devices/
Interactive debugging inside CI systems
https://fosdem.org/2021/schedule/event/debugging_inside_ci/
QAOps - The Latest Trend in QA & Software Delivery
https://fosdem.org/2021/schedule/event/qaops/

Software Composition devroom
Overview Software Bill of Materials (SBOM)
https://fosdem.org/2021/schedule/event/sca_overview/
 
Legal
Protecting against proprietary re-licensing with a community contract
https://fosdem.org/2021/schedule/event/qtproprietaryrelicensing/
 
CI
ARM your continuous integration system with fruits! by @gounthar
https://fosdem.org/2021/schedule/event/arm_your_continuous_integration_system_with_fruits/
 
Community
Mental health and free software
https://fosdem.org/2021/schedule/event/community_devroom_mental_health_free_software/
 
And one fine Belgian beer for each day of the conference also just arrived  
 
 

I have to say that, after I have done the setup, I am really impressed by the performance of this little beast .
 
Exited to see how it will do its job in the datacenter.
 

It's looking better now. I removed the wire for the antenna from the frame, plugged it back in. And attached the frame.
 
They should have designed the case a bit higher so the hat would fit. But I like it like this. I'll try hirsute now. Been a while since I tried it. 

It works  I upped it a bit more and used the Focal mainline image. 465.76GiB of Samsung EVO 970 goodness. 
That's nice.  Happy.

Now what image should I use for the video? I wanted to use the media script for buster on it to have a great desktop image. 
I could also make a gaming image on it, but I'm not sure many people are interested in that. Could you please share your link again with Armbian TV images? 
Also for N2+ if you've got one. I'd like to use it as headless armbian build server. Thanks.

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

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>;         };