MichaIng

In the meantime, the difference between the two initramfs images lsinitramfs revealed is conf/conf.d/zz-resume-auto. This is generated by mkinitramfs in case there is a RESUME variable set, which is expected to be a path or UUID to a swap partition, for suspend-to-disk functionality. Searching for it in DuckDuckGo gives kernel panic reports as 3 of 5 first results, though mostly due to a syntax error in this script, which I would expect to be fixed, or non-existing swap partition UUID. On the host (outside the initramfs), there is no other initramfs-tools config than the default, which does not define RESUME, and there is (has never been) a swap partition in our or Armbian images, but at best a swap file on the root filesystem. So I wonder why this script is generated. Since I could not find any reason in initramfs or kernel maintainer/postinst scripts or configs, I guess the kernel itself somehow must ask/trigger initramfs-tools to generate it. It however can not contain anything correct, but either nothing or false content, as there is no swap partition. Sadly the user who helped investigating initially set up the system freshly now, hence cannot further help, checking the content of this script and whether it can be prevented via RESUME=none in initramfs-tools config. I can further investigate myself from January 17th on. However, while this script, and the kernel panic in search results seem very suspicious, it might be the wrong track. But so far it is the only trace I was able to find 😉.

Failing log: https://0x0.st/8i-h.txt Compared to successful boot with 6.6.43-current-odroidxu4: https://0x0.st/8ioK.txt Notable differences: [ 1.861869] Trying to unpack rootfs image as initramfs... [ 1.862068] rootfs image is not initramfs (invalid magic at start of compressed archive); looks like an initrd The 2nd line is not present in successful boot. Initramfs compression is done with zstd, default since Bookworm, and of course the Armbian kernel builds support it: https://github.com/armbian/build/blob/main/config/kernel/linux-odroidxu4-current.config#L198-L204 [ 4.879383] Disabling rootwait; root= is invalid. [ 4.883718] RAMDISK: Couldn't find valid RAM disk image starting at 0. [ 4.891991] /dev/root: Can't open blockdev [ 4.894661] VFS: Cannot open root device "UUID=a3af1683-ebad-4def-b14b-3bdb314411d2" or unknown-block(0,0): error -6 It seems to not support the root=UUID entry, which is something the initramfs is supposed to provide (support for UUIDs I mean). So it indeed looks like something with the initrd/uInitrd is wrong. It has grown in size from 8888221 to 9439519 but otherwise seems ok (checksums). initramfs-tools did not get an update and configs are the same, same with zstd. This was faced on Bookworm btw, so seems to be independent of the Debian version. I have physical access to an XU4 only in two weeks. Will see whether I can get some content check/comparison of the initrd from our user(s), and some logs of the kernel upgrade/initramfs generation. EDIT: Addresses for kernel, initramfs and dtb 0x40008000 0x42000000 0x44000000 are still fine with large margin. I wonder whether initrd_high "0xffffffff" might be a problem, as this requires support by the kernel as well.

Since a board with 16G RAM practically has a little less than 16 GiB RAM, probably mem=16G limits it a little too less to prevent the crash 100% reliably, while mem=15G would do. I don't know how exactly those limits are applied, and at which point exactly the power usage of the RAM raises above the critical point (in case really this is the reason for the crashes), so this is just a guess which can be tested.

Either, you need to add it to the "extraargs=" (optionally "extraboardargs=") line in /boot/armbianEnv.txt, in case create those lines, if missing: extraargs=mem=16G Or, when adding it to /boot/boot.cmd directly, you need to generate /boot/boot.scr from it: mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr The initramfs does not need to be regenerated in any case.

We found the same issue. It does boot with the dedicated rock-4se target, hence pretty surely an issue with the updated DDR blob. The Armbian repo ships functional U-Boot packages already: https://apt.armbian.com/pool/main/l/linux-u-boot-rock-4se-current/ But WiFi does not work. We tried with rk3399-rock-4se.dtb as well as rk3399-rock-pi-4b.dtb (as used in armbianEnv.txt with rock-4se target). Still trying to figure out what is missing: The correct brcmfmac driver loads. With ROCK 4 SE device tree, it tries to load the brcm/brcmfmac43455-sdio.radxa,rock-4se.bin, else brcm/brcmfmac43455-sdio.radxa,rockpi4b.bin, but actually it uses brcm/brcmfmac43455-sdio without the device-specific appendix anyway. Also creating symlinks for the device-specific suffix mutes the warning, but does not fix WiFi: The adapter is just not showing up in e.g. `ip link`. Does someone know why the ROCK 4B device tree is explicitly used for the ROCK 4 SE target? For the U-Boot config, there is a note that upstream U-Boot ROCK 4 SE target is/was broken, but no hint why the 4B device tree is used. I thought that some patches might patch the 4B device tree only, but as far as we tested, both device trees generally work, but with none of them onboard WiFi is working on the ROCK 4 SE.

sudo sed -i '/^extraargs=/$/ ipv6.disable=1/' /boot/armbianEnv.txt Respectively add ipv6.disable=1 to the end of the "extraargs" line, separated with a space from other possible values. However, this disables IPv6 support completely kernel-wise, which some software has problems with. E.g. the default Apache2 config on Debian comes with a vhost which dynamically binds to IPv4 and/or IPv6 addresses based on whether it is active on the interface or not. This syntax requires the kernel to at least understand IPv6, otherwise the webserver fails to start. So it is generally safer to only disable IPv6 on all interfaces, but keeping the kernel module active: echo -e 'net.ipv6.conf.all.disable_ipv6=1\nnet.ipv6.conf.default.disable_ipv6=1' | tee /etc/sysctl.d/disable_ipv6.conf sudo sysctl -p /etc/sysctl.d/disable_ipv6.conf EDIT: Ah, now I see you basically tried this already. As this is universally functional on all Linux distros, it must actually work. Not sure how exactly to tried it, which exact command or config file? E.g. using the sysctl command itself is not boot-persistent, hence the config file.

@SoSie And did you try to reset mixer settings as I suggested above? And it doesn't work on other host hardware either? I still do not believe it is possible to physically damage a USB device by changing ALSA mixer settings of an internal sound card. Probably just a coincidence, but I lack knowledge to rule it out for certain. At least we offer this setup (switching between HDMI and analogue jack) to a few hundred users and didn't receive such a feedback yet. @ricardovasc Did you try the linked/pasted steps (at best while not having any USB DAC attached)?

Try this: We offer this and a similar amixer config to enforce HDMI audio since a while among a few hundred Odroid N2 users and so far didn't receive any negative feedback. But someone just posted here that this "burned" his/her USB DAC (plugged in concurrently), whatever was meant by that, but double check that card 0 is really the onboard sound card, as I mentioned below here: I basically found this via trial&error and at best only half understood, e.g. why this cyclic looking src/bus/dst linking is required, especially including explicitly device/card 0 while those are for card 0 in the first place (-c 0). Probably a conflicting device tree patch caused the issue in the first place, or a fundamental change with Linux 5.10 which broke a functional Armbian patch.

@SoSie What do you mean by "burn"? You can always reset all mixer settings via rm /var/lib/alsa/asound.state alsactl init The commands explicitly change settings for audio device/card 0 (-c 0), so check first whether onboard audio is card 0 via aplay -l Usually it should be, but I read on recent kmod changelog (Debian Bookworm and above, probably Ubuntu Jammy already) Not sure how kmod shall have an effect on the order in which the kernel detects sound devices, but always good to double check. On USB DACs, the amixer commands should mostly just fail since either the controls are invalid, or the values. USB audio is not internally attached via I2S etc.

Since Linux v5.10 it is a bit complicated to get it working. Try this: # Reset and re-initiate ALSA mixer states rm /var/lib/alsa/asound.state alsactl init # Enable 3.5mm output amixer -c 0 set 'TOACODEC OUT EN' 'on' # Use I2S B as source for 3.5mm output, I2C A is somehow not usable amixer -c 0 set 'TOACODEC SRC' 'I2S B' # Use ALSA device 0 as input for I2S B amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' # Enable I2S B (SRC 2) on device 0 (_A) amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' # Set output channels for device 0 (_A) amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' # Set master volume to 85% amixer -c 0 set 'ACODEC' '85%'

USB gadget mode does currently not work OOTB on Armbian, but it can be enabled easily with a device tree change or overlay: /dts-v1/; /plugin/; / { compatible = "radxa,zero", "amlogic,g12a"; fragment@0 { target = <&usb>; __overlay__ { dr_mode = "otg"; }; }; }; I can open a PR for adding this as device tree overlay, or enabling OTG OOTB on Radxa Zero, like vendor did: https://github.com/radxa/kernel/commit/775a467 The latter would be simple. In case of an overlay, I'd need some hint about how to do it best: Adding it to the general meson64 overlays patch seems to be right: https://github.com/armbian/build/blob/master/patch/kernel/archive/meson64-6.0/general-meson64-overlays.patch But how to prefix or set `compatible` attribute best to assure it can be applied, resp. make clear that it works on Radxa Zero only (as state of testing)?

v21.08.2 (Linux 5.10) is the latest which works. U-boot seems irrelevant since only updating the kernel breaks it and updating/flashing U-boot doesn't solve it. It works on NanoPi NEO3 (same SoC), which probably indicates an issue with the device tree, if the USB3 host is the same?

Since Linux 5.15, the USB3 port on ROCK64 does not work anymore with Armbian. The following kernel errors are shown: usb 5-1: USB disconnect, device number 2 [...] usb usb5-port1: Cannot enable. Maybe the USB cable is bad? This has been reported by multiple users with multiple drives and cables, also disabling UAS does not help. lsusb shows the drive/device, but lsblk does not. I know the ROCK64 is not currently supported by Armbian/has no maintainer, so I'm not expecting anything, just posting this as information and probably someone with more insights into the rockchip64 kernel build has an idea or workaround.

I leave it to you whether a quicker RC-based release or little later stable-based release is feasible. I tested it with eMMC and SD card and it works pretty well. It does support being loaded from SPI flash as well? That is nice indeed, at least as backup bootloader, haven't tested this yet.

The rk3399-opp-2ghz overlay is currently broken on all RK3399 SBCs since Linux 5.15 kernel btw (including both, "current" 5.15 and "edge" 5.18). Another report on this forum: And we replicated on NanoPi R4S and got reports on ROCK Pi 4 and NanoPi M4.