c0rnelius

@ScoreABSM
 
https://github.com/armbian/build/pull/8339
 

I use a 12v 3a PSU "Barrel"
 
patrick@bananapif3:~$ dmesg | grep pcie [ 0.322772] k1x-dwc-pcie ca400000.pcie: has no power on gpio. [ 0.325025] k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: [ 0.325065] k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 [ 0.325088] k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 [ 0.425212] k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 0.525297] k1x-dwc-pcie ca400000.pcie: PCIe Gen.2 x2 link up [ 0.525837] k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 [ 0.543059] pcieport 0001:00:00.0: PME: Signaling with IRQ 65 [ 0.543510] pcieport 0001:00:00.0: AER: enabled with IRQ 65 [ 0.544202] k1x-dwc-pcie ca800000.pcie: has no power on gpio. [ 0.546446] k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: [ 0.546484] k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 [ 0.546510] k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 [ 0.546525] k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 [ 0.646655] k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 1.647016] k1x-dwc-pcie ca800000.pcie: Phy link never came up [ 1.647233] k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 [ 1.654489] pcieport 0002:00:00.0: PME: Signaling with IRQ 69 [ 1.654939] pcieport 0002:00:00.0: AER: enabled with IRQ 69 patrick@bananapif3:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk2 179:0 0 14.6G 0 disk ├─mmcblk2p1 179:1 0 508M 0 part └─mmcblk2p2 179:2 0 14.1G 0 part mmcblk2boot0 179:8 0 4M 1 disk mmcblk2boot1 179:16 0 4M 1 disk zram0 250:0 0 1.9G 0 disk [SWAP] nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 508M 0 part /boot └─nvme0n1p2 259:2 0 238G 0 part /  

sudo modprobe i2c-dev ?

If the u-boot on the unit supports USB Boot, yes. 
 
GXL:BL1:9ac50e:bb16dc;FEAT:ADFD318C:0;POC:3;RCY:0;EMMC:800;NAND:81;SD:800;USB:8;LOOP:1;EMMC:800;NAND:81;SD:800;USB:8;LOOP:2;EMMC:800;NAND:81;SD:800;USB:8;LOOP:3;EMMC:0;READ:0;0.0;CHK:0; The above looks like USB Mode. This Mode is for flashing vendor or custom imgs to the unit via USB. This is for recovery.
 
 

There are big differences between the two revisions. The biggest one is, one is using Wifi/BT over USB and the other SDIO, which requires the sdio overlay. The reason for BT not working on Armbian, I have yet to figure out. Like I said before, it works on (my personal) a more minimal build;
 
Debian GNU/Linux trixie/sid 6.12.26 #1 Sun May 4 17:50:23 EDT 2025 aarch64 BananaPi BPI-M4-Zero v2 ── DISK Filesystem Size Used Avail Use% Mounted on /dev/mmcblk2p2 29G 2.8G 26G 10% / /dev/mmcblk2p1 466M 74M 363M 17% /boot ── NETWORK Hostname: bananapim4zero Wireless: wlan0 UP 10.0.0.XX Bluetooth: hci0 AC:6A:A3:3B:D9:D6 ── SYSTEM Processor: Cortex-A53 @ 1416MHz 52°C Frequency: 1416MHz Online: 0-3 Governor: performance Memory: 3.8G 199M Entropy: 256 Uptime: 15:13:05 up 4 min, 1 user, load average: 0.01, 0.06, 0.  
It is hard for me to determine the reasons BT doesn't work, as the patching is very extensive. If it is even the patching?
 
And yes I include the BT node in the overlay; https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.12/patches.armbian/Add-BananaPi-BPI-M4-Zero-overlays.patch#L267
 
As for HDMI audio and GPU, the PR I posted a link to corrects this. In future releases and rolling (give it a day) it should now work. Although I think I need to now add my changes to the 6.14.y branch? I'll check.
 

The GPU node needs to be enabled.
There has been adjustments made to the patching for 6.12.y and above, but I haven't messed with yet. Basically nodes need to be added for sound.
As for  Bluetooth. I haven't figured out yet why it doesn't work on Armbian. In my personal builds it works fine. I believe there is some patching or service preventing it from loading. But I can't be sure.
 
I've put a lot of time already into the DTS to get this working on both REVS. To much time in my opinion. Anyone is welcome to do a PR and add and enable the bits if they like. Otherwise peps are just gonna have to wait till I get around to it again.
 

I tested Armbian 25.2.2 Bookworm Minimal / IOT on both the REV1 and REV2. Wifi worked fine in both cases.

https://github.com/armbian/build/pull/7951

They were custom built.
 
I suspect the issue is: https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch
 

@dnwhoop02
 
sudo dd if=u-boot.bin of=/dev/mmcblk1 bs=512 seek=1  

The kernel checks a few places for firmware blobs. https://docs.kernel.org/driver-api/firmware/fw_search_path.html
 
You can also set a firmware path in cmdline. This usually isn't needed though.
firmware_class.path=/lib/firmware/updates/brcm  
The kernel checks /lib/firmware/updates before /lib/firmware, allowing us to be able to test new firmware without removing the old.
 

Should be available in future kernel builds.
https://github.com/armbian/build/commit/db3fdc74117392d3d0c0ec02811c8939769fe6da

Makes sense, thanks @c0rnelius

I'm told the bluetooth doesn't work, which is why I haven't submitted it. The patch was also done quick and dirty and I'm sure needs some clean up.
0001-arch-arm64-dts-allwinner-sun50i-h618-bananapi-m4-zero-v2.patch

I think the problem is Pine and not Armbian here. But I understand your point of view.

I've only worked with the BPI-M4-ZERO.
 
My personally opinion on the h616/8 line up is that the focus should be on stable and not LTS. Little to none of the official mainline patches are being back ported and the patches being used currently in LTS are kind of hack-a-noodle patches.
 
For example:
https://lore.kernel.org/linux-arm-kernel/CA+E=qVeMnQNrT8tNnHBnCL2Efy3VjbRAYQGMXstziCThRsiBDw@mail.gmail.com/T/
https://lore.kernel.org/linux-arm-kernel/20240419071450.7aiheeoyq35yjoo7@vireshk-i7/T/
 
The ones being currently used in Armbian I believe are either RFC's or taken from OPI. The thermal patch above is already in 6.9.y.
 
But with that said, if you have any questions feel free to hit me up and if I can, I'll help.

Kali is in a lot of ways a polished SID with all of their own custom bits added. It can be debootstrap'd just like Debian, Devuan and Ubuntu. I did find some services didn't work on boot; 'ssh avahi bluetooth ntp'. But there could be some option they have I'm not aware of to allow those services to start out of the box. Creating a custom service to start those does the trick though.
 
I would think adding this as an option could be doable, but the question then becomes who wants to handle the support required to maintain it?
 

Not ideal, but: sudo halt

I'm using overlay meson-g12a-radxa-zero-i2c-ee-m1-gpiox-10-gpiox-11.dtbo
sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Overlay meson-g12a-radxa-zero-i2c-ee-m3-gpioa-14-gpioa-15.dtbo works for me as well.
 

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.
 

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.

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.

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.

The boot partition is flagged ESP, which the PI3 does not support.
 
Model: Generic MassStorageClass (scsi) Disk /dev/sdd: 32.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4194kB 273MB 268MB primary fat32 esp 2 273MB 4106MB 3834MB primary ext4  
Removing the ESP flag from the boot partition should allow the image to boot on both the RPi3 and RPi4. This can be easily done using gparted.
 
if you are comfortable using the command line:
sudo parted /dev/XXX set 1 esp off   

My efforts into this are done. I was asked to make it boot and get it functioning, not to produce images for the masses. I think as that goes, I did as much. Sorry the kernel doesn't have everything "that everyone ever wanted" ticked on, but that wasn't a concern of mine at the time. With that said, I added support for it in the defconfig, if you or someone else wants to compile their own kernel for those images, you are more than welcome too.
 
Honestly, I would suggest people check the commit: https://github.com/armbian/build/pull/4247 and help provide proper Armbian support. 
 
Thanx