IBV

Hi, how, which software do you use? - did you try to use "alsamixer" to check the volumes ? Just to rule out the mic being muted - please provide logs with: https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-provide-boot-logs-for-inspection

Indeed, the patch was for 32bit chips, I did not look too careful. But it touches the clk-pll.c which is common. Not sure if it is worth to try to apply it to the rockchip64 series. I had a similar issue with tinker board (rk3288) where the mainline kernel did not work with some HDMI panels but the vendor kernel did. In both cases I had EDID warnings. The problems was caused by clock issues.

Hi, as per this forum thread: and this PR: https://github.com/armbian/build/pull/7479 The patch clk-rockchip-max-frac-divider.patch was deactivated from patch/kernel/archive/rockchip-X.X/series.conf. The reason is that it broke the HDMI display for some TFT panels. However the patch broke things on Asus Tinkerboard (RK3288), but might work well for RK3566. I suggest you re-activate the patch in series.conf, rebuild your current or edge image and test. Maybe it works for you. When building, check the build log and confirm the above patch is listed and applied. Cheers

Link has an . at the end, the correct one: https://paste.armbian.com/febewikocu

Separate /var partition was never an issue for me with upgrades (I am talking about Debian now, but Armbian is Debian based). The ram log setting also should stay as it is if the package handling it is properly done. You can however test if you want to be sure: install an older release, do the configs and then upgrade to the latest release.

It would be interesting to see the error.. Also, without being knowledgeable with Ansible, to me it looks like a command timeout (5 minutes?). https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html

First method: even if you manage to mount the partition, you will be able to edit the /etc/fstab file, but moving the data in /var partition will be more difficult. You would need also the NVME disk available to the Ubuntu machine, then you will have to mount the new NVME partition and move the data. Maybe is simpler to boot the SD card and follow the steps I described as the 2 method.

OK, so it did not auto mount. Can you try to mount it manually ? sudo mount /dev/sdb1 /mnt If it works, you should see the contents in /mnt

Are you sure you properly prepared the SD card? https://docs.armbian.com/User-Guide_Getting-Started/#preparing-sd-card I just did a test write of the Orange Pi 5 max image, using dd on a usb stick. Granted, I used the Debian Bookworm minimal image. https://dl.armbian.com/orangepi5-max/Bookworm_current_minimal When I inserted the usb stick in my Ubuntu PC, it was automatically mounted. Can you post the output of "dmesg" command after you insert the SD card?

Yes you could. I gave the UUID example out of habit, I do this on VM's where the disks are /dev/sdX and I want to make sure I get exactly the partition I want on boot in case the kernel/udev is messing the device ordering. In your case /dev/nmve0n1p1 should be fine for example. You are right, you will need to move anyway the old /var contents to the new partition. In case you are able to mount the SD card on a Linux PC/VM, you could do that too before first boot. But maybe better to follow the procedure I describe later. Probably the easiest would be to use a Linux VM (eg. VirtualBox). You can then use a usb SD card reader and pass it through to the VM. My distribution does it (Ubuntu). Yes. After flash the Armbian image, boot it. Allow it to reboot and expand the filesystem. Then: - disable ram log (by editing the /etc/default/armbian-ramlog and setting ENABLED=false) then reboot - make sure you have the root password (you can set one with "sudo passwd" if you don't have it) - reboot in rescue mode (use the root password when prompted) sudo init 1 - mount the NVME partition you want to use as /var in /mnt. FYI: This step is to move the existing /var data to the new location. You need rescue mode so no services run and write stuff in /var when you do the move. Examples below assume that the partition you want to use is /dev/nvme0n1p1. mount /dev/nvme0n1p1 /mnt - move the data mv /var/* /mnt/ - edit /etc/fstab and add a line with the /var mount. /dev/nvme0n1p1 /var ext4 defaults 0 2 If you want to use UUID's you can run "blkid" command and you will get the UUID's of all disks/partitions. You can then take the one of the nvme0n1p1 and use it with UUID=<your uuid> like I showed you in the first answer. - Reboot

Hi, theoretically if you knew the UUID of the partition on the NVME disk that you want to use as /var partition, you could do the following: - after flashing the SD card with the Armbian image, put it in a reader (or a usb card reader) connected to a Linux PC. - the / partition on the SD card should be auto mounted - you can go and then edit the etc/fstab file on the SD card and add a line like this: UUID=<your UUID goes here> /var ext4 defaults 0 2 put the UUID of the partition you want to use as /var in the above line. - boot your SD card I am not sure how this will work with the ram logging, you should try it yourself. If it does not work I can show you how to move the /var partition on the NVME disk after Armbian boots the first time (I have done this myself and it works). This involves - ram log disabling - reboot in rescue mode - identify the UUID of your NVME partition for new /var - move the contents of the /var/ to the new /var - modify the /etc/fstab to mount the new /var on boot.

For the dts, I would take the patch/kernel/archive/rockchip64-6.12/dt/rk3399-orangepi-4-lts.dts , modify it according to your needs and put it in the user patches directory (using the recommended way to replace a patch).

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.