c0rnelius

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

I've seen that in there too, but I've never been able to get a subvolume to boot without using a boot partition. There is also CONFIG_CMD_BTRFS and I could be completely off here, but my thought was maybe a command needs to be executed with a boot script in order for the subvolume to be read/found? I normally use extlinux and with CONFIG_FS_BTRFS & CONFIG_CMD_BTRFS enabled it has always been a no go for me. Maybe someone else here has a thought on the subject? EDIT I tried 3 times getting this working using a Radxa Zero and it was a no-go for a single partition. Once I added a boot partition, it booted right up. radxazero: ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 253M 0 part /boot └─mmcblk0p2 179:2 0 29.5G 0 part / mmcblk1 179:32 0 14.6G 0 disk ├─mmcblk1p1 179:33 0 253M 0 part └─mmcblk1p2 179:34 0 14.3G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk zram0 253:0 0 1G 0 disk [SWAP] radxazero: ~ $ findmnt /boot; findmnt / TARGET SOURCE FSTYPE OPTIONS /boot /dev/mmcblk0p1 ext4 rw,relatime TARGET SOURCE FSTYPE OPTIONS / /dev/mmcblk0p2[/@] btrfs rw,noatime,compress=lzo,ssd,space_cache=v2,subvol

This is a pretty easy add. Basically after creating the btrfs filesystem, mount the LOOP and create the subvolume, now unmount the LOOP and remount it with the correct flags. Lets pretend these are the variables. P_ROOTFS="/mnt/p1" IMAGE_LOOP_DEV_ROOTFS="/dev/loop1p1" mkfs.btrfs -f -L ROOTFS ${IMAGE_LOOP_DEV_ROOTFS} mount "${IMAGE_LOOP_DEV_ROOTFS}" ${P_ROOTFS} btrfs subvolume create ${P_ROOTFS}/@ umount ${P_ROOTFS} mount -o compress=lzo,noatime,subvol=@ ${IMAGE_LOOP_DEV_ROOTFS} ${P_ROOTFS} Where all this would reside in the Armbian framework, I'm not really sure? But in general it wouldn't take that much effort to introduce. One issue I can see popping up, is that U-Boot "last I checked?" doesn't support BTRFS subvolumes. So if subvolumes were an option, the image would require a VFAT or EXT4 BOOT partition.

If you have never built an image, I don't recommend getting your feet wet trying on a tv box. I bricked one of my boxes a couple times before getting this u-boot right, so unless you know how to unbrick it, it is not something you should be playing with. I posted the patches for those who may be interested in adding the support.

I use mainline u-boot on my X96-AIR GBIT. It being a TVBOX, I'm not gonna help people brick their unit, but for those in the know and or willing to try, these are the bits I use. Firmware Image Package can be found here: https://github.com/pyavitz/debian-image-builder/releases/download/amlogic-boot-fip/amlogic-boot-fip-master.tar.gz I also have a kernel patch set. Although its modded for use with the jl2xx1 ETH module. NOTE: The u-boot patches should work with v2023.01 / 04. The vendor 'ANDROID' u-boot needs to be purged from the eMMC: dd if=/dev/zero of="/dev/${node}" bs=32768 count=32768 https://paste.debian.net/1277482/ 001-u-boot-v2023.04-x96-air-gbit-support.patch 002-meson64-boot-target-usb.patch

Absolutely. This has nothing to do with bluetooth. It's related to wifi and the error can be seen on all modern linux kernels. Creating a symlink will make it go away. With that said, the error doesn't break anything and it's just telling you the file is missing.

Although it was initially for use on Raspbian it works on Debian, Devuan and Ubuntu all the same. So it should work fine on Armbian. There is also Bluez hack that the Foundation and Ubuntu use to make sure the firmware is found and loaded during boot, but this can be avoided by simply creating a symlink `ln -s /lib/firmware /etc/firmware`.

Is the pi-bluetooth package installed? The package its self is just a set of scripts, rules and services: https://github.com/RPi-Distro/pi-bluetooth https://packages.ubuntu.com/jammy/pi-bluetooth Interestingly enough, this isn't required when using a mainline kernel. But that's a topic for another day.

HDMI sudo amixer -c 0 set 'TOHDMITX' 'on' sudo amixer -c 0 set 'TOHDMITX I2S SRC' 'I2S B' sudo amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' sudo amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' sudo amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' sudo amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' sudo amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' sudo amixer -c 0 set 'ACODEC' '85%' # not needed for the C4 sudo alsactl store ANALOG sudo amixer -c 0 set 'TOACODEC OUT EN' 'on' sudo amixer -c 0 set 'TOACODEC SRC' 'I2S B' sudo amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' sudo amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' sudo amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' sudo amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' sudo amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' sudo amixer -c 0 set 'ACODEC' '85%' sudo alsactl store