IBV

Hi, you could try to apply the patch yourself (radxa patch that changes the boot order), then re-build u-boot: ./compile.sh BOARD=<your board> BRANCH=current BUILD_ONLY="u-boot" Then flash again the new binary on /dev/mtdblock0

Hi, I think swapon is not visible because you are not root. It should already be there via required package "mount". Try tu "su -" then you will "see" the command.

Hi, take a look at the build doc: https://docs.armbian.com/Developer-Guide_Build-Preparation/ You could try to build the kernel only, typically you get the latest version of the stable branch ./compile.sh kernel EXPERT="yes" BOARD=helios64 ARTIFACT_IGNORE_CACHE='yes' BRANCH=current

Hi, you need to provide a boot log, maybe something will be noticed. If you boot without wifi and can access a previous boot log when the machine is freezing, put it here.

Nothing to read on input. Maybe this is the real error, the keyboard input or console has issues. The console param on boot remained unchanged after update ?

The error talks about dm-mod kernel module and not dm-crypt. Can you confirm that dm-mod exists in your initramfs? Just to eliminate this being the issue.

did you check if this module is in the initramfs with lsinitramfs ? Just asking, I saw you looked for the libraries but not for the module.

Hi, how do you mount the share? It might be that systemd manages the mount in newer systems, then, to umount you have to simply systemctl stop your-share.mount You can check with: systemctl list-units --type=mount --all To see if the mount is systemd managed

Hi, I suggest you try with a different powered hub see if there's a difference. However, please provide logs with armbianmonitor -u

Hi, can you confirm that the OLED is working connecting it to another device (raspberry, Arduino)? It should be properly powered, cables should be checked if ok. Also, check in the spec if pull-up resistors are needed. You can force a scan of all i2c addresses again like this: # Force scan all addresses for i in {0..127}; do sudo i2cget -y 1 $i 2>/dev/null && echo "Device found at: 0x$(printf '%02x' $i)" done

Was the auditd disabled ? Without it is difficult to see where the sysrq comes from. Re. monitoring ttyS1: you could try use screen: sudo screen /dev/ttyS1 9600 Replace 9500 if needed with the baud rate configured in the UPS

Hi, I guess this happens because of the "-x" option in rsync which tells rsync to not cross the filesystem hierarchy. /var/log is typically a mount (/dev/zram1) so it will not be synced.

I suggest to confirm first that it works with the vendor image, just in case. If you boot the vendor image you could also gather some info, like aplay -L, etc.

Do you get sound (HDMI) through your monitor speakers with the official vendor image?

aplay -D plughw:0,0 -f S16_LE -r 48000 -c 2 your_audio_file.wav ? this will force a more common audio format (in case the monitor supports specific audio formats. If not working, no idea, hw detection looks ok.

Sorry I mean Which kind of output device: TV, Monitor with build in speakers? If you try "aplay -D plughw:0,0 your_audio_file.wav", still no sound?

What does "aplay -L" show ? How do you test the HDMI sound ?

Hi, always check with "amixer" (alsa mixer) if your outputs are not muted.

Hi, you can try to set up a readonly root filesystem: https://wiki.debian.org/ReadonlyRoot Cheers

Good news!

Hi, if it is similar to the tinkerboard, you should enable the overlay using "overlays=uart1", and the /dev/ttyS1 should be the serial port. What does "dmesg | grep ttyS" say?

After this test, you might try a boot just with forcing the mode, without edid: extraargs=video=HDMI-A-1:1920x1080@60 drm.debug=0x4

Hi, sorry I was away for a while. https://docs.armbian.com/User-Guide_FAQ/#why-things-stop-working Armbian basically takes the current kernel and applies patches and configs. You can start yourself with the framework and build the image for your board. https://docs.armbian.com/Developer-Guide_Build-Preparation/ You can inspect the patches applied for your board. Can you do some more tests? Can you confirm that the edid_asus_vs228.bin is in the /lib/firmware/edid directory? Also, can you boot without forcing a resolution, but forcing the edid: extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/edid_asus_vs228.bin drm.debug=0x4 Reason for this is that I hope the re-packaged edid (edid_asus_vs228.bin) does not have the checksum error, and maybe it works.

Ok, so probably the timings (frequency) for the 1920x1080 is rejected by the kernel. I took the EDID in your boot log: 00 ff ff ff ff ff ff 00 04 69 fd 22 01 37 02 00 2b 15 01 03 80 30 1b 78 2a 2a c5 a4 56 4f 9e 28 00 50 54 b7 ef 00 d1 c0 81 40 81 80 95 00 b3 00 71 4f 81 c0 81 00 02 3a 80 18 71 38 2d 40 58 2c 45 00 dc 0c 11 00 00 1e 00 00 00 ff 00 42 41 4c 4d 54 46 31 34 35 31 35 33 0a 00 00 00 fd 00 32 4b 18 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 41 53 55 53 20 56 53 32 32 38 0a 20 20 01 b7 and asked ChatGPT to decode it and create a .bin file. Here's the xrandr modeline (just for info): Modeline "1920x1080_60.00" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync And the .bin file is attached. I suggest you put the .bin file it in the Armbian location for edids (I don't remember, maybe /lib/firmware/edid/) and try to boot with it (armbianEnv.txt): drm.edid_firmware=HDMI-A-1:edid/asus_vs228.bin See what happens. edid_asus_vs228.bin

Ok, maybe @jock has some suggestions to this issue.