eselarm

My ROCK5B was ordered as a 'blue one' on Aliexpress a year ago; I got a 'green one' and as with included case the price was > 150 euro, it got stuck at customs for quite some time. It was with blank/empty SPI flash and endless boot-loop. That was already known by me, so I had fixed 12V soldered to a male USB-C connector. Same story for ROCK3A, although that one booted most of the time but then while running al sorts of strange errors and or crashes. So I think you have to assume USB-C PD negotiation is not working with the Armbian images you tested. Only the U-Boot starting at sector 64 does matter, rest (Linux) is don't care. If a stable U-Boot or UEFIv1.1 form SPI-flash or SD-card, you have already a very extensive commandline interface or text menu's in the EDK2. But lock up might simply happen because the PSU does not do 65W, instead max 15 W (only up to 3A) and the 5V might drop way too low, just very short dip that is not measurable without good oscilloscope or so. The Radxa image might have a bootloader variant that does do USB-C PD, although I haven't seen proof anywhere that it correctly handles and does operate the FUSB302, but that might simply be because my ROCK3A and ROCK5B came out of the box with empty SPI and for ROCK5B I have ignored Radxa images anyway after the big troubles with ROCK3A, so do not really know what happens with those. So I have no other advice then use fixed higher voltage, formally it is >= 9V according to Radxa wiki/docs AFAIR, but I remember the powertree design actually better than those quick facts and my conclusion was : forget about 5V, use 12V and it was easy decision for me as I use 12V UPS and 3.5inch HDD that also needs 12V anyway.

Here your debugging activity will need to start. There is an awful lot of things unknown, to others on this forum but more important, also to yourself. It could already be that your server (Armbian) has nothing to do with it, but that it is the info in your router (even caching stuff) that has refreshed, simply because you probably restarted, so something was not 'reset proof'. I have seen many of such things myself in my house/home networking and in conjunction with various ISP's (also mobile4G). Which made me use my own (open-source) router instance for example, so I can at least check all what is needed in such case as you have. But it might be simple, you can use wget (do 'man wget' first to see all options) to mimic browser behavior and that should already say something. If docker etc is involved, make sure you understand all (virtual) networking, it can get very complex. I haven't seen potentially disturbing things from Armbian 26.2.1, but I removed/blocked also several things, like no netplan.io, that at least works on Debian Trixie based installs. There have been lots of security related updates in Debian recently, so make sure you log and see changes to packages (edit listchanges.conf)

This topic is 2 years old and HA formally does not support supervised anymore. And doing 2 such modifications and then hoping all will be fine is false hope IMO. If you don't have a serial console cable to watch kernel en journal log etc to see what your system is doing, maybe it is time now to get one. I have an old supervised inatsllation (not use for many months, but it is plain Debian and a VM so I have free/easy CLI console.

What U-Boot/bootloader is in the MTD?

I just checked at my ROCK5B running Armbian userspace: # sudo apt update # sudo apt list -a linux-headers-*current-bcm2711 linux-headers-current-bcm2711/trixie 26.2.1 arm64 linux-headers-current-bcm2711/trixie 25.11.2 arm64 linux-headers-current-bcm2711/trixie 25.8.2 arm64 linux-headers-current-bcm2711/trixie 25.8.1 arm64 linux-headers-current-bcm2711/trixie 25.5.1 arm64 linux-headers-current-bcm2711/trixie 25.2.3 arm64 linux-headers-current-bcm2711/trixie 25.2.2 arm64 linux-headers-current-bcm2711/trixie 24.11.1 arm64 linux-headers-current-bcm2711/trixie 24.8.2 arm64 linux-headers-current-bcm2711/trixie 24.5.1 arm64 linux-headers-current-bcm2711/trixie 24.2.1 arm64 So you can install them with: # sudo apt install linux-headers-*current-bcm2711 You will get the latest if you do not select explicit version 6.18.9, I got 6.18.10 as that seems to be the latest now. Armbian also has edge and legacy, but for normal release all 64-bit Raspberry Pis is named 'current-bcm2711', which should be the equivalent of 'rpi-v8', which is the normal 4k pages downstream kernel in Raspberry Pi OS 64-bit. It might be you originally had the dedicated rpi5b installation, so you simply had not gotten the headers maybe. Armbian has no 16k pages kernel, if you want that, you need to build yourself, but note that this comes with quite some of issues, many people are not aware and cannot fix issues due to that. See 2+ years of trouble w.r.t. that on RPL forums. I do not use Ubuntu based Armbian, but Debian based, but should not matter for that kernel packages as those are Armbian on top of either distro.

I think most important is that people make sure they can fix their own issues if a HW/computer fails. I found high-availability interesting, but for just my house (or even 2 places/countries at the same time) I found it too much to make it all work. The thing I could maybe use is DRDB, however I see v9 is under development since 2011 and it still is not in mainline kernel. Compared to that I have some script to transfer latest differential Btrfs snapshot from 1 computer to the other on-the-fly, I doubt I can really benefit from DRDB, but maybe I set up a test and see what it does. I use only ARM64 for 24/7 servers, so no x86_64 <=> ARM64 incompatibility. So same as for ZFS for example, it is external to Linux distro and my experience is that complicated issues/failures always happen at the wrong moment, e.g. also no internet and/or mains power failure etc. So I try to minimize the amount of 'external' HW/SW modules, certainly if the backing company is commercial and in whatever country far away from where I am. Proxmox is nice, but also 'external'. Same for even Docker, so I have actually no such containers. But it all depends on how much you are involved in various HW and SW. As you can see in my earlier message, I already forgot HA was available as generic aarch64 image, so that says enough. I use several custom (own) HW (like 'changed' solar inverter) and HomeAssistent does not support it, so I actually do not really use it. It is mostly C-code and Node-RED in conjunction with various micro-controllers. A good test is to disconnect internet (power-off fiber-RJ45 box in my case) and/or also do an ad-hoc power cut (no cheating with UPS). And then see if you can get it all running again within a certain time frame (what you think is acceptable, like before temperature in freezer gets > -10 or so).

I see it is this board, quite new: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-4A.html You can see at https://github.com/armbian/build/commits/main/config/boards/orangepi-4a.csc that no manintainer is defined, so up to yourself to figure out what is wrong. You need to start with attaching a serial debug cable (see 3 pins next to power key) Also I see this board has SPI-flash, there might be an old U-Boot variant in there that does not work together with mainline based 7.0.x kernel.

I have just cleaned-up / changed (again) things w.r.t. network names for my Nanopi-R6C. Same as Nanopi-R4S, it has 'wan' and 'lan', where wan is on-chip ethernet and lan is external PCIe connected. Double check for the R4S, but I am almost sure. So a mainline kernel in principle just numbers them eth<x> depending on timing and other things. New kernel behavior is that the on-chip gets named end0 and for my Nanopi-R6C the external gets named enP3p49s0, as that represents how it is HW connected via PCI-e. That is 7.0.<x-flavor> generic distro kernel. Then Armbian has 2 udev rules to rename to wan? and lan?. That is where the problem was and is for me as I use various different bootloader/firmware. I removed those udev rules as I run standard main distros as well and I need the names for bridges and vlans etc future proof and I don't care about names wan and lan (not using it as router). But if you want to keep that naming, check bootloader version (U-Boot I guess for you) and also udev rules and maybe other patches for RK3399 and/or R4S.

You know there is a fruit company in Cambridge UK that is proud to tell they have sold 75 million pieces and 75% is to non-noobs. They provide passwordless sudo by default and a self-modifying rpi-update script by default in their OS. So why so complicated with this copy-fail exploit, every script kiddy had and has an easy task of keeping the noobs on a leash for more than a decade.

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.

I have seen some kernel errors w.r.t. trim on Silicon Power 16GB SD-card, was in ROCK3A. But no other errors. Kernel is unspecified, although I might be able to figure out which/what, you can even search this forum, then you know yourself. This errors do not occur on a RPi4 v1.1 (with RPL OS and kernel). So if you want to know, dig more into logs, doe specialistic blocklevel error checking. In general: welcome to SD-card magic!. See also this: