Okay, currently, I’m having a boot issue with my encrypted nvme installed OS, with the rk3588 dsi cpu module. This is clearly a software issue, because I can boot off an SD card image and mount the nvme drive’s encrypted partitions manually.
I’ve got a fresh SD image, kernel 6.16.9-mnt-reform-arm64 on both the sd card and my nvme install.
reform check reports the most recent uboot is 25-05-06, and this is present on both the SD card AND the eMMC.
but it also reports that the “version of U-Boot: 2024.10-g424c714eb247-dirty”
So, where is that installed? The “s1” flash? How do I update that? Is it an actual problem?
Is the problem that you see both values “2025-05-06” as well as “2024.10-g424c714eb247-dirty” and you conclude they must be different u-boot versions? The first version is the git tag. The second version is the version of u-boot used by that git tag. Ideally, when building u-boot, the version string would include the MNT git tag as well to cause less confusion.
For example, would it be more helpful to let the u-boot version be something like this: 2024.10-MNT20250506-g424c714eb247-dirty
@minute I have a local patch which is able to inject the git tag into the u-boot version string – do you want it that way or any different?
That is the assumption I was making – assuming they were different versions, and was worried it was part of the problem I was seeing today, which was the screen not initializing at boot – not even when I did a blind entry of my LUKS password and let the system finish boot and I could log in via ssh.
The three things I dug around and found was that u-boot version string, which I thought might be related, for some reason /lib/firmware/arm/mali/arch10.8/mali_csffw.bin was a symlink to ../arch10.10/mali_csffw.bin which does not exist (this seems to be linked to firmware-misc-nonfree version 20250917-1), and that something had generated /boot/extlinux/extlinux.conf, despite u-boot-menu not being installed. Installing u-boot-menu and running u-boot-update did not help anything, reverting to firmware-misc-nonfree version 20250808-1 seemed to fix the mali_csffw.bin, and removing /boot/extlinux entirely allowed the screen to get initialized correctly. Booting from an sd image kept worked fine, though, and so I was looking at the differences between the emmc boot partition and the sd card boot partition.
I’m not really sure what’s going on there, but seem to have gotten myself back to a working state.
Thanks for reassuring me that it’s not a u-boot version issue, though! =)
The screen not initializing properly at boot happens to be fairly often; maybe one in four or so boots? I just hyper+enter 0 and then boot again immediately. I also use an encrypted system, so nothing is mounted read-write at that point, no harm done.
Yeah, it’s happened to me before too, but this was consistently every boot, probably a dozen attempts over the course of the day. It’s working now that I removed the spurious /boot/extlinux directory
Could you get me some logs of the uart output which you receive whenever this happens? Chances are, that what you are seeing is u-boot failing to initialize emmc.
@UnlikelyLass you have discovered what I have spent the past three hours trying to figure out already yesterday. The problem is firmware-misc-nonfree and the new bug I filed might as well be a duplicate of the already existing issue with the arm mail firmware that you quote above.
A version of firmware-misc-nonfree with this problem fixed is now in the MNT Debian repository and you should be able to grab it via apt update && apt upgrade.