piter75

It needs some more love than simply using roc-rk3399-pc as base device tree ;-)
I will try to tweak a bit here and there in the coming days.

It needs some more love than simply using roc-rk3399-pc as base device tree ;-)
I will try to tweak a bit here and there in the coming days.

I fixed booting: https://github.com/armbian/build/commit/cd886792c0e4cb9761eddb6e9dca355892663769
I also switched blue led to heartbeat trigger for a clear indication that the board booted.
 
It boots but is rather not in the best shape - shutdown takes ages and it probably does not shutdown fully.
It was most probably my first boot with legacy using roc-rk3399-pc ;-)
I used roc-rk3399-pc to try it as Station P1 uses non standard headers for serial debig - probably 2.0mm pitch instead of 2.54mm. I need to get those.

Oops... It seems that I have broken it even before it was introduced  - after one of the mainline updates to roc-rk3399-pc.
 
It needs different device tree than mainline. Linking it to a proper filename should be enough.
 
I will post a quick fix tonight.

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.

That's the cultprit - u-boot does not recognise your SPI flash chip.
I only enabled XTX flash chips for ROCK Pi 4 as those come preinstalled but I should enable some more of them especially for owners of v1.3 that did the soldering themselves.
I will try to squeeze it into v20.11.2

Bugfix v1 was already pushed out:
 
[AR-551] - Update fan configuration, enable network LED and enable UPS timer Updated Helios64, Rockpi 4* images and rockchip64 kernels  
Bugfix v2
 
Let's try to patch other critical things before Christmas. I already addressed ZFS problem on Focal by adding most recent DKMS package, but to solve it also for Buster it requires all kernel recompilation - in case you want to push some late changes, now it's the time. The Beast can handle that in no time  We hopefully fixed Odroid HC4 (don't have HW to test), added KVIM2, DVFS on mvebu will be disabled from now on to secure stability (moving to 5.9.y ?) ... What will fail if we update Allwinner to 5.9.y? Mvebu? Rockchip.hf is ready. 
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000@ebin-dev @Heisath@chwe@ning@lanefu@gprovost@aprayoga@5kft @JMCC@karabek@Igor@martinayotte@tkaiser@selfbg@Siraj@jock@going 
 
What else can be squeezed into this mini quick release? Smaller, almost done, things only.
 
I would also like to point out that we are progressing nicely with:

- updated Desktop variant (sits in our main build repository under the branch "desktop"), where also some other general things has been changed. Merge into master is estimated 2/2021, early adopters are welcome. There are other changes, not just desktop.
- native ARM building. Need more testing, but basics are working.
 
Today +7 days?

At this point roc-rk3399-pc is the only one with blob-less boot sequence by default but it's certainly possible with some others too 
https://github.com/armbian/build/blob/master/config/sources/families/rk3399.conf#L19
And it's LPDDR4 too...

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.

Okay, another use case. This one will bring some surprises.
 
Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
 
In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
 
First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
$ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
 
Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
$ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
 
Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.

I remember building the ROCK Pi S image a few day ago and it was working fine. I will build again to verify it.
 
Refer to the output/debug/install.log to see if there are any errors during initramfs build.

I took a shortcut and enabled SPI by default for ROCK Pi 4.
I verified it with SPI CLK shorted on v1.4 but obviously it was not enough
The fix is in master.

Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
 
Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
 

To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
Check it out:
 

2 x NVME arrived, memory tomorrow, CPU, cooling and 2x DOM ETA next week.

Today I had the pleasure of benchmarking an ARM64 server.
This server has been made available for Armbian to test native ARM64 image building.
I knew nothing about the server. Nobody told me any details.
So everything was an adventure for me to find out. I got SSH access, so my research began.

A lscpu informed me it had 32-cores all clocked at 3.3Ghz. 
 
cat /proc/cpuinfo confirmed these 32-cores
 
Checking on what kernel we're on. Ubuntu Focal 5.4.0-52-generic. 
And how much memory. 128GB RAM.

So first thing I wanted to know, how does one core perform with 7-zip benchmark?
The record I had seen until now was from the A73 cores from the Odroid N2+ clocked at 2.4Ghz. 2504MIPS decompression.
So :
taskset -c 31 7z b
 
This beats the Odroid N2+ its A73 cores clocked at 2.4Ghz. 2763 vs 2504MIPS decompression. 
This also tells me these cores do not perform as good per clock as a high performance core. 
While doing the single core benchmark I checked the sensors to know the wattage and temperature.
 
CPU power is about 20W for a single core tasks. 
Without a load the CPU consumes between 10W-15W. So in total it consumes a bit more than 20W in idle.
Temperature never went under 49C even after +5 minutes in idle. 
 
Of course, the next thing to do is an all-core 7zip benchmark. 
This gives an amazing result. Way higher than anything I had ever seen on ARM.
 
85975MIPS decompression. This is amazing.
Best I had seen was 11000MIPS of the Odroid N2+. So this server does 8 x better than the N2+. 
Tho, I must say. 7zip does bad with unequal clusers. The N2+ has a great difference in cluster frequencies. So it performs worse then expected here. 

The wattage went a lot higher, up to 110W. And the temperature rose quickly up to 75C in seconds.
 
To test the internet connection I downloaded an Armbian image multiple times. Sometimes it was as low as 3MB/s. 
Highest average speed I've seen was 12.5MB/s
 
Next test. BMW Blender render benchmark. 
Here the fastest I had ever seen was by the Khadas VIM3. That did it in 42m51s.
I haven't done this yet with the N2+ in Armbian. In Odroid's Ubuntu it was a little slower. I expect it to be a little faster than the VIM3 in Armbian Bionic. 
This is a tile based test. So every core gets its own task, until all tiles are done. 

Well, this ARM64 server did this in 8m27s. 
5 x faster compared to the Khadas VIM3. 

For this the wattage didn't go over 85W. But the temperature did rise to 83C. So it started to throttle. 

@lanefu already had done SBC-Bench on it when it was free. So this I didn't have to do myself.
http://ix.io/2Dcc
Here we see a lot. For example the CPUMiner did : 81.0kH/s 
The Odroid N2+                                                         : 14 kH/s         5.7 x less 
RK3399 does a maximum of                                     : 10.23kH/s     8 x less
Odroid C2 clocked at 1.75Ghz                                   : 4.65kH/s       17 x less

So this server clearly can move a lot of bits around. 
Now, what is this server? Ask google if nobody else tells me. "32 core ARM server 3.3Ghz"
First answer : https://www.theregister.com/2018/09/18/ampere_shipping/
That looks like it is this CPU. But still I can't find the exact name. 
2nd answer : https://www.servethehome.com/ampere-32-core-64-bit-arm-chip-x-gene-3-ip/
So this is the Ampere 32-core 64-bit from X-Gene 3 IP.

Here the wikichip : https://en.wikichip.org/wiki/apm/x-gene/apm883832-x3?fbclid=IwAR0ljCQ61DY8Zwh_VyZd0fQH43dmPUTJA-CGLiQKYqU2fWwszFm1CPjH6Zo

This supports up to 1TB RAM. 8 channels @ 2666Mhz. With a maximum memory bandwidth of 158.95 GiB/s.
42 lanes of PCIe Gen 3, with 8 controllers
– x16 or two x8/x4
– x16 or two x8/x4
– x8 or two x4
– Two x1

4 x SATA Gen 3 ports, 2 x USB2. And a TDP of 125W TDP.

For me this is just an awesome thing to behold. I use ARM for almost everything.
The NanoPi M4V2 is my main desktop computer.
It isn't as powerful as my PC, but does the task for 10 x less power consumption, while being completely silent.

But when I need a big CPU, it isn't enough.
Even the more powerful Odroid N2+ isn't powerful enough to render long, +20minutes 1440p video's for example for my Youtube channel.
So then i need to use my x86/amd64 PC. 

Today I have seen and tasted the future. 
While this doesn't use the most modern Cortex/clusters. And it is only 16nm.
So there is still a lot of room for improvements in performance and lower power consumption. 

ARM for desktop is possible, and ARM servers for big datacenters is possible(AWS). I have seen the future, I loved every second of it. 

Here benchmarks compared to my SBCs

 

Greetings, NicoD

@aprayoga Fingers crossed!
I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful).
I started some tests with 40000 right now.
 
@Pedro Lamas if you want to also try testing it...
Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2.
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };  

Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them.
 
cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters
 

We need to work a bit on our download page for ROCK Pi 4 boards as I see you used 4B images - and these are the only ones easily accessible on the download page  (CC: @Igor)
 
For current use the images from here: https://dl.armbian.com/rockpi-4c/archive/ - all USB ports should work there.
In legacy they will not work right now. I have it on my TODO list so it is possible that with the next point release all USB ports will work in legacy too.

rtl8189fs was patched "upstream": https://github.com/jwrdegoede/rtl8189ES_linux/commit/0ba46e2434eec6f67d0712ed119a4ef8e05ccf91
 
I removed rtl8189fs from our patches for rockchip64 yesterday and propagated the change to other families about an hour ago.

Log in with ssh, remove /etc/modprobe.d/blacklist-rockpro64.conf file and reboot. HDMI should work then.
There is an issue with current v20.08 builds for some boards (including RockPro64) that crucial graphics modules are blacklisted - it will be fixed with next patch release.

I've done an PinebookPro build with rockchip64-dev 5.8.y, it worked, I'm planning to do a rockchip64-dev garden tour, and if nothing special, commit those change for 5.8.y ...

My big test rig:
 
32 devices IN
https://dl.armbian.com/_test-reports/2020-08-04_21.44.52.html
 
31 devices OUT
Only Orange Pi Zero Plus 2 failed to respond after extreme testings ...

This is a known issue with rk3399 boards using mainline kernel and it was mitigated for all other boards using mainline u-boot some time ago.
RockPro64 is the last one that is uses u-boot v2017.09 but I am planning to switch it to mainline for the next Armbian release (v20.11).
For now you need to either be patient or stay with 4.4.y.

Run these two commands:
sudo cp /lib/firmware/brcm/brcmfmac4356-sdio{-nanopi-m4v2,}.bin sudo cp /lib/firmware/brcm/brcmfmac4356-sdio{-nanopi-m4v2,}.txt Reboot and verify if your wlan0 interface is working.