piter75

I believe "apt install linux-dtb-legacy-rk3399 linux-image-legacy-rk3399" is what you really wanted to do ;-)

Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
 
XFCE desktop with "browsers" app group
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz
 
CLI
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz
 
PR: https://github.com/armbian/build/pull/3984 (against master)
All work by @amazingfate I just gathered stuff and built images.
Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
 
 

The truth is I did not test the SPI booting lately. Will give it a shot as soon as I find some spare time.
 
It's not merged into master yet: https://github.com/armbian/build/pull/3489

Radxa rock-3a github.com/catalinii

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
 
It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
 
You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
 

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

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.
 

This is actually good news that they are present and are different
Do you see the production week markings on top of the package? What is it? - both of mine are 1810.
 
I must admit that this scenario crossed my mind when I read that you have two boards. The explanation is a bit long but pretty simple...
 
Many boards that Armbian support does not have a stable MAC address and have it randomly generated on each startup.
On the first run Armbian checks the current MAC and creates the NM connection configuration with this random MAC as cloned address.
Thanks to this the next time you boot the board it uses this MAC instead of another generated one achieving some degree of stability - until next reimage.
 
With Rockchip (rk3328 and rk3399 at least) it is a bit different as the MACs for first two ethernet interfaces are generated based on CPUID stored in CPU's NVRAM.
Armbian does not recognise it (not all versions of u-boot can do this generation) and also saves this MAC as a cloned MAC in NM connection settings.
 
When you switched the SD card between boards you started assigning a stable MAC address from the first board to the second one (as a cloned MAC) and the first one was still using the same stable MAC that's assigned to it ;-)
The best you could do IMHO in this situation would be to simply delete the cloned-mac-address stance from connection files on both of your boards and enjoy two stable and different MACs for your boards

Is the result of the following command anything different than mine?
root@rock64:~# xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Both of my rock64 CPUs have their efuse empty and thus both also have the same mac address which is generated by u-boot and based on CPUID. CPUID should be present in bytes 0x07 - 0x16.
I always wondered if it is a common issue...
I also have ROCK Pi E and NanoPi R2S - both based on RK3328 - but they have their efuses set.
 
Did you deactivate and activate the connection after editing cloned mac address?
 
My "/etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection" looks like this and it overrides the default mac address
 
 

Hi al.
I've finished my review of the PineBook Pro. I just love this thing. Runs great with Armbian.
Here my video.
Here all my gathered information:
 

It will be fixed with https://github.com/armbian/build/pull/2877

@TCB13 I am a bit late to the party but I figured it may still be needed ;-)
 
spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.
 
For configuration options have a look here:
https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126
You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays

@Chalix You have done quite a research already
Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
 
U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
 
The recipe to write the images to device (more or less) is to be found here.
 

@Chalix You have done quite a research already
Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
 
U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
 
The recipe to write the images to device (more or less) is to be found here.
 

@Chalix You have done quite a research already
Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
 
U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
 
The recipe to write the images to device (more or less) is to be found here.
 

Something similar to this hat most probably ;-)
https://www.aliexpress.com/item/33029451117.html

With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in.
My experience is that you could also set it to min/max 2GHz and it would be just as good.
 
Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor.
 
It seems that the instability of little core's voltage during the voltage change was the issue.
Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still unstable).
It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.

I am not sure of that.
 
My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
-rockpi-4b legacy focal cli stable yes means that focal legacy image for rockpi-4b will not be built.
Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)

Glad to hear that.
 
BTW The fix is now included in Armbian v21.02.3 images

Glad to hear that.
 
BTW The fix is now included in Armbian v21.02.3 images

So far its planned to rebuild them all. Building one or all its pretty much the same trouble