Radxa Rock 4 SE not booting from SD Card

[CaWeissWz]

My Radxa Rock 4SE does not boot since community-build 25.8.0-trunk.228. Current local builds based on the "main" branch are also affected.

 

The bootloader log gives the following error:

Checking hash(es) for config config-1 ... OK
Checking hash(es) for Image atf-1 ... sha256+ OK
Checking hash(es) for Image u-boot ... sha256+ OK
Checking hash(es) for Image fdt-1 ... sha256+ OK
Checking hash(es) for Image atf-2 ... sha256+ OK
Checking hash(es) for Image atf-3 ... sha256+ OK
ERROR: not expected type found -4001165690437497392

 

This source suggests, that it might be a problem with the ATF.

However, my knowledge about details of the boot process are unforunately not sufficient to find a solution to this problem.

 

How to reproduce?

• Download https://github.com/armbian/community/releases/download/25.8.0-trunk.228/Armbian_community_25.8.0-trunk.228_Rock-4se_bookworm_current_6.12.33_minimal.img.xz
• Install on SD card
• Try to boot Rock 4 SE from SD card image

[laibsch]

Thank you for reporting about this issue.

 

What is the latest image that still works?  Is it still available for you to download?

 

Maybe this is the change you want to revert and see if that brings things back in line?  But supposedly, that commit was boot-tested by Niklas.  Your board does not have an official maintainer in armbian, so I suggest you contact Niklas to find out what the situation is for him.

[CaWeissWz]

The last working image is 25.5.0-trunk.256, which is still available for download.

 

I will try to look into the situation as my time allows. Thanks for the hint where to start.

[laibsch]

Do you know how to compile your own images?  Do you know how to use "git bisect"?

[CaWeissWz]

Yes, I know how to compile images. I'm still learning how to use git efficiently, though. 

Git bisect, I had never heard of before; but from what I read, is seems to be the right tool to find the breaking commit. But before I start into this possibly lengthy process, I came up with one theory, that I intend to check first:

 

The initial assumption was, that the error is due to an API incompatibility in the Arm Trusted Firmware. My first intention was, to check if a newer version of the ATF was available, I just didn't know for wich part exactly I should look.

Now I found out, that the working Image starts the "BL31"-thing right at the point where the current images fail:

Zitat

Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE:  BL31: v1.3(release):8f40012ab
NOTICE:  BL31: Built : 14:20:53, Feb 16 2023
NOTICE:  BL31: Rockchip release version: v1.1

 

So, the first thing for me to check will be which version of "BL31" is used for the current images and if a newer version would be available and could be used instead.

Unfortunately, i might not be able to work on this until next week. But I will report back as soon as there is new information.,

[laibsch]

sounds good. 

 

good luck and keep us posted!