Torte

u-boot has to be compiled specifically for the board that it runs on. That means the Armbian project for the board has to be changed and it may require some additional source code changes - these additional requirements show up, when trying to boot with that new bootloader and something does not work. I have managed to switch to a recent u-boot on a RK3328 board that I own (required changes can be seen in these commits) and I could try adopting that for the RockPi4b. But as that change would affect all RockPi4b boards and I don't have a direct way to test it before publishing (it took me dozens of image builds and boot attempts), I am reluctant to give it a go without more indications that the bootloop is really caused by that specific bootloader problem: It may have a completely different cause and the u-boot switch may also introduce new problems. So I'd rather wait until that loop can be reproduced and the log proves u-boot being the cause before opening that can of worms.

Thanks for publishing these logs. Now we have to wait for the bootloop to happen, when the serial-adapter is still in reach . If the loop happens directly at the "illegal free" messages, then switching to a more recent bootloader (u-boot 2025) could fix this.

Great! See https://wiki.radxa.com/Rockpi4/dev/serial-console for a guide on how to connect the serial lines to the board and setting up a terminal program. The wire colours are different, but take a look at the picture on that link: Do not connect the +5V or 3V3 pins GND cable needs to be connected to the 3rd GPIO-pin (GND) on the top/outer side of the connector (the black wire in the picture) RX cable needs to be connected to TX, that's the 4th GPIO-pin, just below the GND wire (it's white in the picture) TX cable needs to be connected to RX, that's the 5th GPIO-pin, just below the RX wire (it's green in the picture) (If you can't connect, then RX and TX needs to be swapped. Don't worry, having these lines swapped won't break anything, it just doesn't allow a connection when wrong.) Then start the terminal program (e.g. putty on Windows or minicom on Linux, both described in that link). When booting the RockPi, you should see the boot messages in the terminal window (otherwise try swapping RX/TX). Keeping the spacebar pressed (in the terminal program, make sure it is selected) should then interrupt the bootloop and you should be able to copy&paste the output. If interrupting still does not work: Putty has the opption to copy the whole content to clipboard: Right-click the title bar and select "Copy All to Clipboard". Then paste it into an editor. Once you have pasted that log into an editor, you can try to clean it up a little bit, it may contain several boot attempts. It would be sufficient to include just one complete boot attempt and the start of the next. But if in doubt, use the complete log. Finally post that log here.

There is no hidden magic in the .xz files. You assumed correctly, that this is "just some form of zip". Some image-writing software like rufus or etcher allow on-the-fly decompression of these files, but extracting them with "xz -d" and then writing the uncompressed .img file e.g. with dd should work. If the resulting image didn't work, then it must have a different cause (e.g. interrupted decompression, decompressed the wrong file, issues with the image file contents itself, etc.).

You can take a look at the postinstall script from the u-boot package. It should be called sth like "/var/lib/dpkg/info/linux-u-boot-current-rockpi-s.postinst" and should be quite small, so easier to understand. You can extract the required commands from there. Assuming it is similar to my u-boot installer, this could result in a script like this: #!/bin/bash source /usr/lib/u-boot/platform_install.sh write_uboot_platform "$DIR" /dev/mmcblk0 sync That way you don't have to handle the hardcoded sector offsets yourself (not sure, if these offsets would ever change - but if they do, then that will probably be reflected in the platform_install script).

With a usb-serial-adapter it would be easier, but well, it is how it is Can you try pressing the spacebar when the device is bootlooping (keeping it pressed for a while)? This should interrupt the bootloader - and with a bit of luck, the interesting lines are still visible on the screen, then you could simply take a photo and post it here (if the lines are readable).

@Gwolf2u (or anyone else): Are you able to provide a log from the bootloader when it goes into bootloop?

This could be a similar problem that I have had with the mks-klipad50 board (also a rockchip64). In case of the bootloop, do the u-boot messages show "efi_free_pool" messages, directly followed by a "Synchronous Abort", like this? (The hex numbers can vary and there are a lot more registers dumped, this is just the start): Starting kernel ... efi_free_pool: illegal free 0x000000003cf21040 "Synchronous Abort" handler, esr 0x96000004 In that case, it is rather caused by the bootloader (u-boot) and the kernel version change had just a very indirect effect which triggered that problem.

(Please ignore, this doesn't apply to the NanoPC T4) You can try if the LEDs show up after "sudo modprobe pinctrl-rk805". The switch from rockchip64 kernel 6.6.x to 6.12.x included a change that made the "pinctrl-rk805" being built as a module instead of compiled-in. That module does not get autoloaded, so it has to be added to /etc/modules. On the Klipad50, the gpio-leds are attached to the rk805 gpio bank, which is not known to the system without that kernel module. Only after loading that module, the LEDs appeared under /sys/class/leds and started working. Edit: - Board is NanoPC T4 - sorry, I haven't seen the label - The NanoPC T4 does not have the rk805 controller, so this posting does not apply. Edit#2: Do "sudo gpioset 0 13=1" or "sudo gpioset 0 13=0" change the LED state?

I wrote a small guide for customizing the status LED's behaviour on the MKS-Klipad50 board. The available LEDs and their names in "/sys/class/leds/" will be different on other boards, but the general behaviour should be the same. Just make sure to change the filenames like "firefly:blue:user" in the examples to those available on your system.

You can use "evtest /dev/input/event0" to analyze its output. Docs for gpio-leds: https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.yaml https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt

Using "HAS_VIDEO_OUTPUT = no" will enable "full-cli-stable-ubuntu" (Ubuntu Server) and "minimal-cli-stable-debian" (Debian Minimal), but I was hoping for "full-cli-stable-debian" (Debian Server) instead. But maybe I should drop my expectation and just go with Ubuntu-Server, I guess it won't behave much differently.

I would like to change the image types at https://www.armbian.com/mks-klipad50/ so that Debian Server images ("full-cli-stable-debian") for current and edge kernels are built for this board. Optimal would be, if the "Desktop" and "Minimal/IOT" were omitted, so that only the Server images appear. Something similar is done for "aml-s9xx-box" here: https://github.com/armbian/os/blob/main/userpatches/targets-release-community-maintained.template#L57 So my approach for enabling Server images would be https://github.com/armbian/os/compare/main...torte71:armbian-os:main as PR. But I am not sure a) if adding boards directly to the "items:" property is intended at all (or if it is e.g. just an unwanted workaround) b) if my changes work at all: I don't see a way to test it first c) how to disable generation of Desktop and Minimal/IOT images (but that point is optional, esp. if the changes would become too big) Could someone please give me some tipps for that?

The "Edit Device" wordpress template ("https://www.armbian.com/wp-admin/...") has some input fields that I would like to understand. I am trying to complete it for the MKS-Klipad50 (https://www.armbian.com/mks-klipad50). (It's a CSC board, not standard support - if that matters.) Following fields are unclear to me: "Compatible" What is the meaning and expected syntax? Is that something like devices using the same kernel, but different setup/devicetree files? "Expose kernels" / "How many kernels to expose?" Is this related to the "Kernels" table (see below), like how many rows to use? "Kernels" Is it required adding rows to have images automatically generated and appear as download links on the device page? Or are these options just required for additional non-standard images? Is it better to leave it empty? Could someone please shed some light on the meaning of these fields?