Finally got my Rock5B!
Let the party start!
Would soon try to install ArchlinuxARM/Manjaro on it, and since it’s booting using UEFI, I guess this time I can finally push my systemd->kernel boot sequence more.
1 Like
If you are really lucky, our generic-efi images might boot on it already, since it requires the board firmware to provide the information about the board in question.
Unfortunately, I don’t believe the kernel has needed drivers, especially considering upstream kernel only supports emmc and UART, not PCIE/network etc…
And further disappointed by the fact that, it’s not UEFI runtime by default.
The board boots from its SPI NOR flash, which by default is U-boot (without any serial output).
Although U-boot also provides UEFI runtime, at least we may need a UEFI bootloader as payload first (e.g. systemd-boot).
So overall it is not that different than RK3399 boot sequence, the only difference is, we can skip the ATF/bootloader building, and rely on the vendor U-boot for now.
Will try to craft a new PKGBUILD using radax tree as the next step.
1 Like
Well yeah, that’s the general rk3588 support status in mainline. 
And anyone with the board with v1.42 version, and have checked if the default SPI flash contains a bootloader at all?
The official wiki provides a step to flash SPI image to have a Uboot (along with its firmwares).
If we can rely on the vendor Uboot in the SPI flash, we can skip the complex (and mostly crappy) Uboot compile procedure. (especially their Uboot tree can not even pass compile due to some bugs).
The board put boot priority on SDcard/eMMC, not the SPI flash unfortunately.
To no one’s surprise, the vendor U-boot doesn’t have UEFI runtime enabled.
What a shame…
1 Like
Compiled the vendor kernel, and although it boots, it’s very unstable.
There are at least two locations can cause a hard reset, mostly related to PCIE.
But if it went after PCIE initialization, it is mostly fine.
And the boot output (loglevel7 using vendor SPI flash image):
1 Like
By incident, it looks like I also found the reason why Rockchip PCIE host controller sometimes failed to properly initialize and crash.
It has a very high chance to be related to PCIE ASPM, at least related to powersave mode.
After I set CONFIG_PCIEASPM_PERFORMANCE, I have never seen another boot crash.
And considering the host controller is mostly the same as the one used on RK3399, maybe we can skip that extra PCIE wait patch, and just go ASPM performance mode instead?
I’m not sure it solves the same issue. Will have to ask the patch author about that.
CONFIG_PCIEASPM_PERFORMANCE seems to disable some power management features in PCIE if I understand it correctly.
Yes, that’s exactly why I found it by incident.
Initially I thought it should not be related to the PCIE initialization problem, but at least my local tests never hit the crash at PCIE initialization time anymore.
Even after removing the patches?
Haven’t yet tested on RK3399, but I’m using the vendor source tree, and it doesn’t has extra delay thing in the call chain of rockchip_pcie_really_probe() at all.
Or I shouldn’t have so many crashes during PCIE initialization I guess.
Tested with my RockPro64 (rk3399), using ArchlinuxARM linux-aarch64 kernel, which doesn’t contain any Manjaro patches.
No more PCIE related initialization problem using pcie_aspm=off cmdline option.
This is way better than the older days where PCIE initialization tends to have a 1/3~1/5 chance to fail.
But I haven’t dig deeper into the PCIE initialization code, thus more confirmation would be better.
But it would mean that users need to add this option manually if they have PCIe.
Default ASPM policy can be set using kernel config:
CONFIG_PCIEASPM
Or
CONFIG_PCIEASPM_PERFORMANCE
The former (set to N) would completely disable ASPM, meaning cmdline options can no longer change it.
The latter would default to NO ASPM, but user can still override the behavior using cmdline.