piter75

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

@i5Js you can download these packages and install them with apt/dpkg: https://users.armbian.com/piter75/nanopim4v2-stability-fix/
You need both of them for the fix.
 
When they are correctly installed and the board is rebooted you should see this message in your dmesg:
piter@nanopim4v2-4:~$ dmesg | grep rk808-regulator.*buck [ 2.840331] rk808-regulator rk808-regulator: max buck steps per change: 4 The last "4" means you have the fix. No message or "8" means you don't have a fix.

Could you test this image with your procedure?
It should fix the issues with voltage scaling on little cores cluster that made my units unstable and fail in the first loop of "memtester 3280M".
With the fix it run 150 loops without failures.
 
 

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.

The tag was always there but at a different configuration level so no need to change it manually ;-)
 
Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.

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.

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

Mine is 000048.

Thanks for testing!
 
The boot hanging issue has a workaround now in the rockchip64-u-boot-v2020.10 branch indeed and the board boots consistently for me again.
I don't know if it also fixed those "Timeout poll on interrupt endpoint" errors - I did not observe them with v2020.10.
 
This is also fixed in the branch with the patch from Sigmaris.
 
I will also definitely add some polish to the nand-sata-install writing process.

I had the same.
They explained after a few days that it had some outgoing customs issues and asked me to place the order again.
Yesterday I opened a dispute which was resolved by Aliexpress within an hour in my favour and today I got the money back.
Seeing how well it went with the dispute I ordered it again - it was 0.25EUR more expensive now. Let's see how it fares this time ;-)

The tag was always there but at a different configuration level so no need to change it manually ;-)
 
Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.

You can use "dwc3-0-host" overlay in /boot/armbianEnv.txt to enable it now - it switches to port from otg to host mode.
 
overlays=dwc3-0-host  
I will prepare some corrections to the device tree soon and will enable the host by default to make it consistent with vendor's configuration.

@JMCC This should do the trick to fix it for boards in rk3399 family:
https://github.com/armbian/config/pull/134/files

Ultimately we should have a single kernel source for all rockchip64 devices ;p
At this point neither rockchip64 nor rk3399 is really fit for that. They do not support rk3308 as a simple example. It should probably be some more or less stable cut from Rockchip's master.
Until recently I was actually more inclined to move devices from rockchip64 to rk3399 and make it a base for switching to Rockchip's master whether it would be 4.4 or 4.19 (FriendlyElec is already using 4.19 for R4S).
 
On the other hand boards are now divided ~50/50 between those kernels so we can move Station P1 to rockchip64 if it fits there better.
We will worry about switching to some form of Rockchip's master later - most probably not earlier than with first rk3568 boards...
 
As stated above I see no harm in that.

Glad to hear that
 
The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.

Ok, it needs one more change to fix the boot issue (besides working bluetooth).
Right now the service type is set to forking but the brcm_patchram_plus_rk3399 binary is not forking so systemd treats it as not successfully activated / activating.
 
Change Type to exec and it should be properly treated by systemd.
I adjusted it in the PR too: https://github.com/armbian/build/pull/2480/commits/92729573cea1aa786432e1dce42d641019e8bcd4

Glad to hear that
 
The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.

Almost all shipments from Aliexpress come to me through Liege and get here usually within 3-4 weeks - it should be sooner for you 
One additional factor though is Christmas time...
 
BTW, I have ordered one too.

In case neither of you wins this time ...
https://www.aliexpress.com/item/20000004598102.html delivery to my country is free

In case neither of you wins this time ...
https://www.aliexpress.com/item/20000004598102.html delivery to my country is free

Hi all.
I've just finished a new video where I polish the heatsink of my Rock Pi X with sandpaper. This because there's a rather thick powdercoating on the heatsink in the spot where it makes contact with the SoC.
This caused a lot of thermal resistance. The SoC would get hot and overheat, while the heatsink didn't warm up. And the top of the board was the hottest spot.
Here my video.

On the NanoPi M4 and M4V2 there was a thermal pad included. This also was pretty bad.
I raplaced those with a copper shim and some thermal paste and improved the thermals by about 10C.

If you like to use your board passively cooled it can be important to look for the details to improve things. This method might also be possible on the Rock Pi 4. I don't have it anymore to test.
Greetings.

Glad to hear that
 
The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.

Ok, it needs one more change to fix the boot issue (besides working bluetooth).
Right now the service type is set to forking but the brcm_patchram_plus_rk3399 binary is not forking so systemd treats it as not successfully activated / activating.
 
Change Type to exec and it should be properly treated by systemd.
I adjusted it in the PR too: https://github.com/armbian/build/pull/2480/commits/92729573cea1aa786432e1dce42d641019e8bcd4

I might have been a little bit too braggy (and tired)  last night.
SPI boot for ROCK Pi 4 still uses a single blob file
 
The other part of the message is correct however - it takes a simple change to the configuration file to enable both blobless boot for both SD/eMMC and SPI and I run my ROCK Pi 4B this way.