IBV

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