c0rnelius

This should correct the audio issue. Run as root `sudo su` and only choose one. # ANALOG amixer -c 0 set 'TOACODEC OUT EN' 'on' amixer -c 0 set 'TOACODEC SRC' 'I2S B' amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' amixer -c 0 set 'ACODEC' '85%' alsactl store # HDMI amixer -c 0 set 'TOHDMITX' 'on' amixer -c 0 set 'TOHDMITX I2S SRC' 'I2S B' amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' amixer -c 0 set 'ACODEC' '85%' alsactl store

Try these: https://github.com/pyavitz/debian-image-builder/tree/feature/patches/overlays/arm64 As for them showing up under /dev correctly, I believe we would need to do a PR to add the aliases to the DTS. aliases { serial0 = &uart_AO; + serial1 = &uart_AO_B; + serial2 = &uart_A; + serial3 = &uart_B; + serial4 = &uart_C; + i2c0 = &i2c0; + i2c1 = &i2c1; + i2c2 = &i2c2; + i2c3 = &i2c3; + i2c4 = &i2c_AO; + spi0 = &spicc0; + spi1 = &spicc1; + spi2 = &spifc; }; radxazero: ~ $ ls /dev autofs initctl ram0 snd tty23 tty42 tty61 vcs6 block input ram1 stderr tty24 tty43 tty62 vcsa btrfs-control kmsg ram10 stdin tty25 tty44 tty63 vcsa1 bus kvm ram11 stdout tty26 tty45 tty7 vcsa2 cachefiles log ram12 tty tty27 tty46 tty8 vcsa3 cec0 loop-control ram13 tty0 tty28 tty47 tty9 vcsa4 char mapper ram14 tty1 tty29 tty48 ttyAML0 vcsa5 console mem ram15 tty10 tty3 tty49 ttyAML1 vcsa6 cpu_dma_latency mmcblk1 ram2 tty11 tty30 tty5 ttyAML4 vcsu disk mmcblk1boot0 ram3 tty12 tty31 tty50 udmabuf vcsu1 dma_heap mmcblk1boot1 ram4 tty13 tty32 tty51 uhid vcsu2 dri mmcblk1p1 ram5 tty14 tty33 tty52 uinput vcsu3 fb0 mmcblk1p2 ram6 tty15 tty34 tty53 urandom vcsu4 fd mmcblk1rpmb ram7 tty16 tty35 tty54 userio vcsu5 full mqueue ram8 tty17 tty36 tty55 v4l vcsu6 fuse net ram9 tty18 tty37 tty56 vcs vga_arbiter gpiochip0 null random tty19 tty38 tty57 vcs1 video0 gpiochip1 port rfkill tty2 tty39 tty58 vcs2 watchdog hwrng ppp rtc tty20 tty4 tty59 vcs3 watchdog0 i2c-3 ptmx rtc0 tty21 tty40 tty6 vcs4 zero i2c-5 pts shm tty22 tty41 tty60 vcs5 zram0 radxazero: ~ $ cat /boot/ext*/ext* label default kernel ../Image initrd ../uInitrd fdtdir ../amlogic/ fdt ../amlogic/meson-g12a-radxa-zero.dtb fdtoverlays ../amlogic/overlays/meson-g12a-radxa-zero-gpio-8-led.dtbo ../amlogic/overlays/meson-g12-gxl-cma-pool-896MB.dtbo ../amlogic/overlays/meson-g12a-radxa-zero-uart-ee-c.dtbo ../amlogic/overlays/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtbo append earlyprintk console=tty1 console=ttyAML0,115200n8 console=both rw root=PARTUUID=2c552180-02 rootwait rootfstype=xfs fsck.repair=yes loglevel=1 net.ifnames=0 no_console_suspend init=/sbin/init

I'm not 100% on this, but I don't believe there is an easy way to change the order as its hard coded now. Maybe someone else knows better?

It is more than likely a u-boot issue caused by a specific patch; https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch https://github.com/armbian/build/blob/main/config/boards/radxa-zero.conf#L17 You would need to build u-boot with this patch disabled, flash it to the unit and see if it solves the problem.

These are my available options / resolutions with the current display I have plugged into it. cat /sys/class/drm/card1-HDMI-A-1/modes 1280x720 1280x720 1280x720 1280x720 1280x720 800x600 800x600 800x600 800x600 720x576 720x576 720x576 720x480 720x480 720x480 640x480 640x480 See what you have available.

The answer is, no. This might be the case on the bsp kernel, but not on mainline. Sure they have a lot in common, but by no means is it the same unit.

Wifi and bluetooth should work out of the box. You also appear to be using the wrong img; 591 Thu Aug 31 03:17:42 PM UTC 2023 | Banana Pi M2S | 23.8.1 | arm64 | aarch64 | 6.1.50-current-meson64 14736 fdtfile=amlogic/meson-g12b-a311d-bananapi-m2s.dtb Aren't you using a CM4?

You should not have these overlays enabled; g12a-radxa-zero-gpio-10-led sm1-bananapi-rtl8822cs

If that doesn't work, you are more than welcome to donate to Armbian so the baseboard can be purchased and a proper OVERLAY or DTS can be created for it. As I will not be buying another baseboard out of pocket to do so.

I did my testing on the CM4-IO-BASE-B. The USB, RTC and PCIe with NVME attached work as expected.

It is my understanding that the USB-C is actually on USB2. All the PCIe bits are on USB3. At least this what I've gathered by quickly scanning over the schematic. I could be wrong of course and it would be nice if I was. My IP is also banned from the forum for some unknown reason? As for possibly getting a drive to show up, try changing the `dr_mode = "peripheral";` to `dr_mode = "host";` or even maybe otg? This can be done with an overlay. /dts-v1/; /plugin/; / { fragment@0 { target = <&usb>; __overlay__ { dr_mode = "host"; }; }; }; BPI_M2S_V10_SCH_Reduce_202212.pdf

Give it a whirl and let me know. lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive Bus 001 Device 003: ID 0bda:a811 Realtek Semiconductor Corp. RTL8811AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub meson-g12b-bananapi-cm4-waveshare-usb.dts

Getting this working doesn't appear to be complicated, but I personally don't like playing guessing games. I'll see if I can get the baseboard.

I don't have that baseboard to run tests on, but my guess would be it needs its own DTS file or at the very least, the current one would need to be edited. This would more than likely be true for a lot of obscure baseboard out there, as stated in the initial commit to mainline. The keywords there are "should work fine". To me, it sounds like something just needs to be tweaked on the USB front.

I have an X96-AIR-GBIT and from what I can see reviewing the DTS files, it is not much different than the MAX. What I do to get the ETH working is make the following changes to &ethmac https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/6.1/004-arch-arm64-dts-amlogic-meson-sm1-x96-air.patch#L39 https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/6.1/004-arch-arm64-dts-amlogic-meson-sm1-x96-air.patch#L219 Using that as a reference, you should be able to edit the DTS in Armbian and if all goes well have functional ETH.

Although this is doable. It would be a fairly large undertaking. Any services and custom services currently used, would need a sysvinit equivalent. Then there is the question, would this also need to be integrated into armbian-config? Probably, yes. Would all features in armbian-config even be supported in Devuan? I seriously doubt it. Also depending on how debs specific to Armbian are currently put together and the depends they may or may not have, those would also need to be modified. Plus it would need to be extensively tested. I have found some scripts I run that are linked to services sometimes need modification when using them on Devuan. For a lot of boards though, on a basic level. It could be done.

I've been around. This method generally works well in my testing on both Amlogic and Allwinner boards. The only catch is, some USB ports don't work as well as others "or at all?", so it requires a little trial and error. I've been told by some users that adding a sleep and USB reset to the script also helps when having issues. But I've personally never needed to do so. As long as the drive is properly powered, it should just work.

I use a similar approach but also include a boot script. boot.cmd: setenv bootlabel "USB Boot" usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi Flash img to SDCARD, flash Armbian to USB drive, insert into unit and power on. https://github.com/pyavitz/binary/releases/download/images/meson64_odroidc4-usb-boot.img

This requires patching, I'm not sure if it has been submitted yet. You are more than welcome to test it. 001-arch-arm64-dts-sun50i-h5-thermal-support.patch A similar patch is also needed for the A64.

Is Crust even all that useful on ARM? It is a requirement now `last I checked?` with v2023.04 / ARM64. But on ARM, according to the Github it is still BETA. I can say on the PineA64+, that when using Crust the board actually powers down and resets properly. It still has issues of course, but that has more to do with the revision of the board.

does this correct the issue?

Check to see if the following is available: ls /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp As long as the kernel has all the correct bits in place, you should then be able to choose a trip point for when you want the fan to start running. Example echo "55000" | sudo tee /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp

Can you provide a dmesg of the randomly freezing unit, when running on that kernel? Thanx. EDIT: Not 6.0, as its not a good frame of reference with what may be happening on 6.1 and up.

The R2 uses a diff wifi module lsmod | grep "8723ds" 8723ds 1355776 0 cfg80211 331776 1 8723ds https://github.com/lwfinger/rtl8723ds.git