IBV

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.

Can you check if you can pass drm.debug=0x4 to the kernel command line and see if you get more info ? If yes, paste here the boot log.

More like a kernel issue than Armbian. The Armbian supplied edid bin file probably does not match your monitor's. Take a look here on how to get the actual edid and force it: https://wiki.archlinux.org/title/Kernel_mode_setting#Forcing_modes_and_EDID

Do you actually have this edid file : edid/1920x1080.bin ? How did you generate it?

Hi, can you provide logs with: PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u Also, take a look at this thread how to force a mode using boot parameters and Xorg config. https://forum.armbian.com/topic/46932-5-inch-hdmi-display-not-working/#comment-206059 I suggest you connect your monitor to a linux system which supports it and gather the modelines there with: xrandr --verbose Then you can try to force that missing mode. Cheers

You need to check the disk space, apparently you are out of space and the daemon is not logging.

You could try to install auditd and check what it says when the event appears. Maybe it will tell you which process is sending the event: $ sudo apt install auditd $ sudo auditctl -w /proc/sysrq-trigger -p w -k sysrq_watch The second command is creating a watch on sysrq-trigger for write events, called sysrq_watch. You can query check this watch with: $ sudo ausearch -k sysrq_watch See what you can find when you detect another trigger of the sysrq key.

The actions in the dts for setting the GPIO pin are is based on the boot log line. marlin chip en dummy pull up -- need manually set GPIO You can check the whole discussion here and the reasoning https://chatgpt.com/share/68466d15-e5bc-8013-b200-17ae7f7c89fc However, After your last answer, Chatgpt suggests this is not really the issue, but a delayed initialisation would help. When the bt fails to initialise, try the following: sudo hciattach /dev/ttyS0 any 115200 flow sudo hciconfig hci0 up If this works, you can put this in a service to run at every boot. You can try yourself to continue the above conversation with chatgpt and see if you find the final solution. Then you can post it here.

Ok, try with this dts file /boot/overlay-user/bt_enable_clean.dts /dts-v1/; /plugin/; &pio { bt_en_pin: bt_en_pin { pins = "PH1"; // GPIO225 function = "gpio_out"; bias-pull-up; drive-strength = <20>; output-high; }; }; Compile it: sudo armbian-add-overlay /boot/overlay-user/bt_enable_clean.dts and enable it in /boot/armbianEnv.txt user_overlays=bt_enable_clean Then see if better on reboot.

Interesting, pls post the failed boot.

Ok, create a new dts /boot/overlay-user/bt_enable_full.dts /dts-v1/; /plugin/; &pio { bt_en_pin: bt_en_pin { pins = "PH1"; function = "gpio_out"; bias-pull-up; output-high; }; bt_wake_pin: bt_wake_pin { pins = "PH0"; function = "gpio_in"; bias-pull-up; }; }; &{/soc} { wcn_bt: wcn_bt@0 { compatible = "wcn,bt"; status = "okay"; enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; // PH1 = GPIO225 wake-gpios = <&pio 7 0 GPIO_ACTIVE_HIGH>; // PH0 = GPIO224 (if connected) }; }; And compile it: sudo armbian-add-overlay /boot/overlay-user/bt_enable_full.dts Then enable it in /boot/armbianEnv.txt user_overlays=bt_enable_full See if there's an improvement on boot.

Ok, replace the contents of the dts file with this: /dts-v1/; /plugin/; / { fragment@0 { target = <&pio>; __overlay__ { bt_enable_pin: bt_enable_pin { pins = "PH1"; function = "gpio_out"; bias-pull-up; output-high; }; }; }; }; And try again the steps

Ok, if you want we can try one more thing. According to AI, the correct way to always enable the bluetooth is to do it via a custom overlay, which is not done. First, remove the bt-gpio.service, it does not help: sudo sytemctl disable bt-gpio.service sudo rm /etc/systemd/system/bt-gpio.service sudo systemctl daemon-reload Then, create the custom overlay file /boot/overlay-user/bt_enable_ph1.dts with the following content: /dts-v1/; /plugin/; &pio { bt_en_pin: bt_en_pin { pins = "PH1"; function = "gpio_out"; bias-pull-up; output-high; }; }; &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; status = "okay"; }; &wcn_bt { compatible = "wcn,bt"; uart = <&uart0>; enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; // PH1 = GPIO 225 status = "okay"; }; Then we can try to compile and install it: sudo armbian-add-overlay /boot/overlay-user/bt_enable_ph1.dts Then activate it in /boot/armbianEnv.txt, add the following line: user_overlays=bt_enable_ph1 If all works well try to reboot and see what happens.

Difficult to see like this, better list the overlay directory: ls /boot/dtb/overlays

sudo armbian-config Are you able to see the below overlays ? If yes, activate them. System → Hardware/Kernel → Activate UART0, UART1, BT overlays

Can you post your /boot/armbianEnv.txt ?

I did not see the bt-gpio service starting on boot. Can you post the status ?

Hi, without owning this board, chatgpt is pointing out to an initialisation issue of the bluetooth system caused by the GPIO pin not being correctly handled at boot. [ 6.024062] WCN: marlin chip en dummy pull up -- need manually set GPIO The correct solution would be to handle the init in the dtb file, but you can try the following systemd initialisation as a workaround to see if it works. Create (as root) the following service file /etc/systemd/system/bt-gpio.service with the contents: [Unit] Description=Enable GPIO for Bluetooth chip Before=bluetooth.service [Service] Type=oneshot ExecStart=/bin/sh -c 'echo 225 > /sys/class/gpio/export || true; echo out > /sys/class/gpio/gpio225/direction; echo 1 > /sys/class/gpio/gpio225/value' [Install] WantedBy=multi-user.target Then enable it (as root): systemctl daemon-reexec systemctl daemon-reload systemctl enable bt-gpio.service Reboot and check if the bluetooth starts correctly. Post the boot log if it does not.

Hi, it looks like you or a process is triggering the SysRq key. For example, If I press Alt + PrtSc (SysRq) + h, I see the same message in dmesg. https://en.wikipedia.org/wiki/Magic_SysRq_key

Hi, could you point to a like where this status is shown? Normally yes, once Armbian will start integrating that kernel version you should have what you need.

Take a look here: https://docs.armbian.com/User-Guide_Getting-Started/#deploy-the-image

It only works when you are already logged in Gnome, just for your session (no sudo). If you want global settings, you could try setting this via /etc/profile.d/. Create a script like: /etc/profile.d/disable-screen-blank.sh With the contents #!/bin/bash if [ "$XDG_SESSION_TYPE" = "wayland" ]; then gsettings set org.gnome.desktop.session idle-delay 0 fi and make it executable sudo chmod +x /etc/profile.d/disable-screen-blank.sh I tried it and it works for my Gnome 48 test system.