August 27Aug 27 Hi there!!! LTNS. Not pretending to ask for a solution. Just curious, what am I doing wrong, after a decade with Armbian. ;) A new Chinese board with RK3567, quite similar to kickPi. Boots up to "INFO: BL31: Initializing BL32" then hangs. Changing DTB in armbianEnv.txt does nothing, same is for verbosity. I guess there's some pre-DTB in uboot, as I recall, this is common with RK chips. And it seems to not match my hardware. Any reasonable way to fix, before i rebuild the whole image? Thanks in advance!
August 28Aug 28 Solution Hi cu6apum, You already guessed right about the pre-DTB — armbianEnv.txt can't touch this stage. And since BL31 printed at all, DDR init in TPL/SPL succeeded, so it's the trust chain that's dying.On RK3576 that line usually means one of two things: 1. The trust image on flash has no OP-TEE payload (some vendor SDK builds are TEE-disabled), or one built for a different DRAM map — BL31 jumps, nothing answers, silence. 2. BL31 and BL32 aren't from the same rkbin build — happens when a vendor flash and an Armbian image each rewrote part of the chain. Maskrom + rkdeveloptool to dump what's actually on flash, then rewrite idbloader + uboot + trust as a matched set from the closest supported RK3576 board. If it turns out TEE-less, a no-TEE trust combo is a legitimate workaround — you lose the secure boot path but gain a booting board. Happy to compare notes if you post the full UART log.
September 11Sep 11 Author Thank you! Yes, I abandoned the secure boot, don't need it. Built uboot from other distro (linux-rk from RK itself) and am able to boot.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.