c0rnelius

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

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.