eselarm

I see it like who is motivated to check and do the work w.r.t U-Boot. Especially while EDK2 UEFIv1.1 is available already a year and at least for my ROCK5B and NanoPi-R6C with both Armbian rockchip edge kernels as well as standard Debian arm64 kernels works OK. We call those things 'firmware' but the 'firm' selling this OP5 HW is not delivering this. Good thing is that it is all open source at least. For the ROCK5B I also used it in 'vendor' mode, so 6.1.115 works and so video encoders as well (for Jellyfin). For NanoPi-R6C (RK3588S, same as OP5) it is in the on-board eMMC, that is some disadvantage compared to SPI and more as SD-card. So not sure how OP5 will deal with it.

There will be no fix if it is not clear what exactly needs to be fixed I would say. I guess you need to dig deeper yourself. You can build U-Boot independent of Armbian if you want, maybe less reading initially, still the testing/debugging is what matters.

Yes that is what it seems. But strange that mainline kernel+DTB gets it right and 2026.04 U-Boot not. You need to look into the build-config of this U-Boot for the OP5 then I think. All PCIe NVME needed for boot might be there, but still other factors might determine fail or success. Maybe timing at power on, some power line or other signal not enabled. You could flash https://github.com/edk2-porting/edk2-rk3588 into SPI and see if you can boot mainline based kernel with that with just SPI and NVME. Maybe other things don't work then, but depends on what the board should do. You need to add or already have an extra EFI type FAT formatted partition with that, usually done manually and also installing grub-efi package and installing all that manually. Also you may want to add loglevel=7 to kernel command line, then you see what is happening after 'Starting kernel'

What happens after that? Do you see PCIe getting activated? Is the NVME SSD enumerated? What brand and type of NVME?

You need to look into github changes then, everything is traceable, but certainly not an easy and quick thing to do.

What you prefer or think is best. An extra boot partition is more flexible as it is an extra 'boot-stage' sort of, and normal computers that use UEFI anyway need also a FAT formatted bootpartition besides 1 or more rootfs for (multiple) OS. So not a bad approach to have separate boot partition an if on SD-card, is removable, so is flexible in case of trouble and/or testing things.

Both logs show initial timestamped text, then the same again non-timestamped. That is something fundamentally wrong. You can de-compile and compared DTB files but it might not reveal why it fails. Btrfs might by just un-related. I see in the NOK log a disabling of an LDO, might be on purpose but also because code is just corrupted somehow. I do not have this BPIM2U board, so no way to see if same would happen for me. Hope someone else can reproduce, else use older kernel that does not fail.

I assume OPi02w has no on-board storage, so it only is the bootcode in ROM, and that reads U-Boot binary blob from fixed sector offset location on the SD-card. It does not even need a MBR-table or GPT and it is not in a partition, so you won't see it. Only if you use dd to read (or write/wipe) that data you will know. See how U-Boot needs to be written for your OPi02w, then you will understand. If the U-Boot is build to initialize the USB and HDD, you do not need /boot partition on the SD-card. But I do not know that. Not all USB-SATA chipset drivers are in U-Boot, so if not, you indeed need a boot partition on de SD-card where kernel initrd DTB are, those should understand USB-SATA chips and so see the rootfs on HDD.

The bootlog-OK.txt shows: [ 10.796728] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read which is not good at all. I also think you think you still not have set verbosity=7 in armbianEnv.txt, else the both the OK and NOK logs would show more and that is needed as a start for further investigation.

That is at least the same base release (2024.01) from U-Boot as my Allwinner H3 boards, but old 32-bit ones. If it would be something like 2017.09 that would point to vendor legacy as older Rockchips might still use that. So I think you would need to look at live kernel logs at power-on and see where it stalls. It might be for example a swap in mmcblk numbers (SD-card v.s. eMMC), just an example. I have also seen many things related to powering as well, or some clock wrong (maybe too high for storage HW, whatever). USB serial console/debug cables cost about 1 euro nowadays, so I once just ordered 10-pack, standard connected one to most SBC's.

It would save you (and others) a lot of time if you would have a USB serial console/debug cable and with verbosity=7 in armbianEnv.txt I actually only got triggered because of 'Btrfs' in the topic title, but it might be a totally unrelated issue. Also note that besides the kernel provided .dtb file (is in /boot/dtb but and same file is also somewhere in /usr/lib/linux-image-<KVER> ), U-Boot has its own DeviceTree version/variant. Might be older, newer, broken, incomplete, vendor, mainline, patched, custom. So what U-Boot is loaded/used, also is important to know. Extract that info from SD-card where the U-Boot blob is written (sits at fixed sector offset, between partition table and 1st partition). You can look into U-Boot writing scripts to get to know the offset for Allwinner, but something like this is quicker:

@technik007_cz I see I also posted here, I initially thought the problem was in kernel or initrd or armbian scripts, but it turned out HW related (power). Is all sorted now and all understood and also situation for my ROCK3A is very different now. And also ROCK3A is Rockchip, BPiM2ultra is Allwinner. What is common it seems is that the storage device where the rootfs is on is unavailable to the kernel+initrd. If you have a running Armbian system and you do apt update && apt full-upgrade, you get new kernel and new u-boot if those packages are updated. BUT, the U-Boot blob is not written to storage device automatically, so this seems like a problem as I have had and seen various times before: older U-Boot and newer kernel. As you also it have a non-working with a pre-installed/pre-generated image, the problem is also there its seems. However, it needs more details. You need U-Boot log and kernel log posting here. Attach a serial console cable and set kernel loglevel to 7 Just for (my) reference, the board is this: https://wiki.banana-pi.org/Getting_Started_with_M2_Ultra_%26_Berry

I had similar experience, can't remember exact numbers and versions etc as I already considered it not going to work, so did not take notes. Was on NanoPi-R6C, so same RK3588S at least. I think I already had put 'serial' as console in the EDK2 setup (is in eMMC for NanoPi-R6C), but not the older display option (GOP or so, forgot it). For my trial it was just the kernel, so instead of the a latest edge-rockchip64 that works all fine with EDK2 v1.1 in my setup, it was the generic UEFI-ARM64 kernel. You use a full image, so I think something is missing or not implemented yet. Also, my main assumption was (and is), is that only serial console is working for a CLI image. I have always a serial console cable available/prepared, although you need an extra other computer, but your OPi5 should simply run, just display is not initialized. You can look in dmesg, there might be a lot of HDMI debug/info, might also be the kernel and your HDMI monitor experience miscommunication, timing issue. I rebooted again with 7.0-rc3 rockchip64 and that worked again. Now I did some apt pinning so I can install/use Debian sid kernel (6.19.11 at the moment). That works the same as the armbian build 7.0-rc3 rockchip64. Also Opensuse Tumbleweed with its default 6.19 kernel works fine.

You need the U-Boot source-code version; I at least cannot conclude on it; You can watch the start-up via serial console, then you will see. Or like this: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) I see you have 2 options: which U-Boot is used: mtdblock0 (the SPI-flash) or mmcblk0 (SD-card) ??

Log shows nothing about PCIE when 6.19.0-edge-rockchip64, it does when 6.18.8-current-rockchip64 If you just upgraded the kernel via apt, then this might be the point where an older U-Boot is incompatible with newer kernel. This is the case for all Rockchip devices I have and not strange. It is like it is, so if you want edge or newest or even standard Debian sid/unstable/testing kernel, you will need to look at that in more detail. I have been spending a lot of time on it, it is simply what you want or need. If you want all RK3588 silicon HW support, so like video encoders, stick to vendor based U-Boot and kernel. I you want a generic computer that is good enough for server tasks and web-browsing etc, use mainline based U-Boot and kernel. Of course something else might be wrong, but reporting U-Boot version would be needed and helpful first I think.