IBV

Indeed you are trying to patch a file that is created by an armbian patch. I suppose you can overwrite the armbian patch that creates the rk3399-orangepi-4-lts.dts with a patch that creates the dts with your modifications.

Hi, your patch fails because the file rk3399-orangepi-4-lts.dts does not exist in the mainline kernel(s) you tried to build. Maybe previously you appplied it against the vendor kernel?

To provide logs: https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-provide-boot-logs-for-inspection There's also "armbianmonitor -h" which shows the possible options.

Hi, take a look at this thread: The user is using picocom to check the traffic on ttyS2: picocom /dev/ttyS2 --baud 115200 --echo

Hi, to me it looks like there's no difference in the overlay you took from the sunnxi-DT-overlays repo and the one in the Armbian image you're running which comes from this patch: https://github.com/armbian/build/blob/fad71e196230690a2c8205ec977dcc5a653f9746/patch/kernel/archive/sunxi-6.12/patches.armbian/arm-dts-overlay-Add-Overlays-for-sunxi.patch#L4136 Normally according to the doc, i2c-0 is the bus connected to pins 3 an 5 (PA11, PA12), isn't it ? https://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO So the behaviour looks correct when you enable the built-in i2c0 overlay. I cannot say why the numbering changes when you use your own overlay. Eventually you could follow the below link and provide 1 log after you boot the build-in overlay and 1 log after you boot with the custom one.

Hi, check the status of serial-getty@ttyS2.service and disable it. systemctl status serial-getty@ttyS2.service systemctl disable serial-getty@ttyS2.service Also can you please post your kernel command line again to check the console= param: cat /proc/cmdline According to the doc (https://0pointer.de/blog/projects/serial-console.html) systemd will spawn a serial getty for the console specified in the kernel command line.

Hi, could it be that the mic is muted or volume is too low? You might check the situation with alsamixer (then F4 for capture controls).

It looks like if you set console="display" in armbianEnv.txt then the console kernel param will be set to tty1. This might resolve your problem.

This would disable it entirely, which is probably not what you want... It looks like the the the kernel is not picking up the console parameter: Kernel command line: root=UUID=d0636019-ca11-404a-9874-04e6cbfedf37 rootwait rootfstype=ext4 splash plymouth.ignore-serial-consoles console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=8dc56fe2-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory [ 0.000000] Unknown kernel command line parameters "splash ubootpart=8dc56fe2-01 cgroup_enable=memory cgroup_memory=1", will be passed to user space. Maybe post here the boot.cmd and armbianEnv.txt

Hi, in general you can set status = "disabled"; in a dts to disable a component.

I don't think there exists an overlay to disable the bluetooth for your board. Are you able to follow the steps in the forum post you sent and do it yourself? You might need to: - Install the device-tree-compiler if not present apt install device-tree-compiler - Go in your boot dtb directory cd /boot/dtb/allwinner/ - I will assume your booted dtb is sun50i-a64-pine64-plus.dtb. If not, you might try the same with sun50i-a64-pine64.dtb and sun50i-a64-pine64-lts.dtb. Backup the file: cp sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus.dtb.backup - Generate the dts (ignore warnings) dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts sun50i-a64-pine64-plus.dtb - Edit the obtained dts file and remove the bluetooth section : bluetooth { compatible = "realtek,rtl8723bs-bt"; reset-gpios = <0x36 0x00 0x04 0x01>; device-wake-gpios = <0x36 0x00 0x05 0x00>; host-wake-gpios = <0x36 0x00 0x06 0x00>; firmware-postfix = "pine64"; }; - Generate the dtb out of dts (ignore warnings): dtc -I dts -O dtb -o sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus.dts -Reboot and check if /dev/ttyS1 is present

Hi, can you point the link to the documentation you refer to? Yes, you might have to disable the bluetooth in order to have the serial port. Also, can you list the files in /boot/dtb/overlay/ ?

Hi, please ignore my previous post, the patch will only work if applied to the kernel device tree sources before building.

First, I believe the correct modification to apply is the one below, please try it meson64-reboot { compatible = "meson64,reboot"; sys_reset = <0x84000009>; sys_poweroff = <0x84000008>; sd-vqen = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>; sd-vqsw = <&gpio_ao GPIOAO_6 GPIO_ACTIVE_HIGH>; sd-vmmc = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; }; Secondly, Yes @c0rnelius idea sounds correct in order to correctly patch this for the future.

Hi, maybe the fragment you applied is not really compatible with your dtb. [ 1.779992] OF: /meson64-reboot: could not get #gpio-cells for /soc/gpu@ffe40000 [ 1.780030] OF: /meson64-reboot: could not get #gpio-cells for /soc/gpu@ffe40000 [ 1.780050] OF: /meson64-reboot: could not get #gpio-cells for /soc/gpu@ffe40000 Can you post here the complete .dts + your modification?

Hi, 2025-02-25T01:22:22.972716+01:00 domotique kernel: [ 1.484132] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 156, base_baud = 1500000) is a 16550A 2025-02-25T01:22:22.972742+01:00 domotique kernel: [ 1.486026] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 157, base_baud = 1500000) is a 16550A To me it looks like you have only 2 serial ports. I suppose uart2=ttyS1. I suggest to try with /dev/ttyS1.

Hi, I can confirm that the mentioned patch is breaking another display i am using: $ xrandr Screen 0: minimum 320 x 200, current 640 x 480, maximum 4096 x 4096 HDMI-1 connected primary 640x480+0+0 (normal left inverted right x axis y axis) 400mm x 300mm 640x480 60.05* 75.00 72.81 66.67 60.00 59.94 720x400 70.08 This is a LVDS panel using a LVDS to HDMI convertor. I am seeing also the same kind of error: [ 28.408594] rockchip_rk3066_pll_set_rate: Invalid rate : 33290000 for pll clk pll_npll Using the kernel built without clk-rockchip-max-frac-divider.patch makes the display work.

Hello, I believe I found the problematic patch which is messing my display: patch/kernel/archive/rockchip-6.6/patches.armbian/clk-rockchip-max-frac-divider.patch This patch adds the code that generates this pll_set_rate error. I have removed it from patches directory and rebuilt the kernel. The system booted fine (no video kernel param) and Xorg started fine (without extra modelines). I will test this kernel with other displays I have around to make sure it works. Do you know something about the patch above ? Thanks

Hi, thanks, I booted the kernel you build but no change. However, using your advice with the video kernel param, i got the following results: 1) First, without any intervention here's what Xorg says about the screen: [ 16.605] (II) modeset(0): Printing probed modes for output HDMI-1 [ 16.605] (II) modeset(0): Modeline "800x480"x65.7 32.00 800 840 888 928 480 493 496 525 -hsync -vsync (34.5 kHz eP) [ 16.605] (II) modeset(0): Output HDMI-1 connected [ 16.605] (II) modeset(0): Using exact sizes for initial modes [ 16.605] (II) modeset(0): Output HDMI-1 using initial mode 800x480 +0+0 The EDID looks OK, the Modeline is read and applied (according to Xorg), but screen is black. xrandr --verbose shows the following: 800x480 (0x42) 32.000MHz -HSync -VSync *current +preferred h: width 800 start 840 end 888 total 928 skew 0 clock 34.48KHz v: height 480 start 493 end 496 total 525 clock 65.68Hz 2) Using video=HDMI-A-1:800x480@65D as kernel param, I indeed get a framebuffer, I see the kernel + systemd booting, all good. However, when Xorg starts, screen goes black. Note that I used 65 for refresh rate instead of 60 just to use what the EDID is delivering. xrandr --verbose now shows: 800x480 (0x42) 32.000MHz -HSync -VSync *current +preferred h: width 800 start 840 end 888 total 928 skew 0 clock 34.48KHz v: height 480 start 493 end 496 total 525 clock 65.68Hz 800x480 (0x43) 32.691MHz -HSync +VSync h: width 800 start 824 end 904 total 1008 skew 0 clock 32.43KHz v: height 480 start 481 end 484 total 499 clock 64.99Hz There is a second mode shown now. 3) If I force this new mode now, using the following xorg.conf Section "Monitor" Identifier "HDMI-1" Modeline "800x480_65.0" 32.69 800 824 904 1008 480 481 484 499 -hsync +vsync Option "PreferredMode" "800x480_65.0" EndSection then Xorg is also working. Now I see the following dmesg errors: [ 17.456578] rockchip_rk3066_pll_set_rate: Invalid rate : 32690000 for pll clk pll_npll Waiting on your thoughts on this. Thanks

Thank you. If I can help in any way let me know.

I am also suspecting one of the applied patches, but don't know which. I have today booted libreelec distro (kernel 6.6) and the display worked, so not sure what is causing the issue in armbian. https://releases.libreelec.tv/LibreELEC-RK3288.arm-12.0.1-tinker.img.gz

Hi, thanks for answering. What I tried: - Official armbian image for tinker: Bookworm desktop xfce, kernel 6.6 https://dl.armbian.com/tinkerboard/Bookworm_current_xfce This does not work. Bootloader shows, then kernel boots and screen goes blank. Backlight is on. Ssh works. - Official asus image from here (based on Debian 10, kernel 4.4): https://tinker-board.asus.com/download-list.html?product=tinker-board-r2 This works, but it is not an option for me as debian buster is too old. Any ideas what I could try? Thanks

Hello, the latest armbian image (Bookworm_current_xfce) with kernel 6.6 has issues with the winstar tftp 5 inch hdmi display that I am using. Bootloader (u-boot) is showing but after loading the kernel message, screen goes blank. The screen resolution is 800x480, in attach the pdf specs. Info: the official asus image with kernel 4.4 works, but it is not an option for me as I don't want to use debian buster. Please help. Thank you very much. Bogdan WF50FSYFGDHNV.pdf