c0rnelius

U-Boot SPL 2025.07-armbian-2025.07-Se37d-P526e-H8869-V8e92-Bb703-R448a (Aug 19 2025 - 04:10:01 +0000) DRAM: 4096 MiB Trying to boot from MMC2 NOTICE: BL31: v2.12.5(debug):armbian NOTICE: BL31: Built : 04:09:39, Aug 19 2025 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b5100, model: BananaPi BPI-M4-Zero INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: Probing for PMIC on I2C: INFO: PMIC: found AXP313 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2025.07-armbian-2025.07-Se37d-P526e-H8869-V8e92-Bb703-R448a (Aug 19 2025 - 04:10:01 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: BananaPi BPI-M4-Zero DRAM: 4 GiB Core: 65 devices, 22 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0, mmc@4022000: 1 Loading Environment from FAT... Unable to use mmc 1:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready eth0: usb_ether starting USB... USB EHCI 1.00 USB OHCI 1.0 Bus usb@5311000: 1 USB Device(s) found Bus usb@5311400: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 4641 bytes read in 1 ms (4.4 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 280 bytes read in 0 ms Load fdt: /boot/dtb/allwinner/sun50i-h618-bananapi-m4-zero.dtb MMC: no card present ** Bad device specification mmc 0 ** 43728 bytes read in 4 ms (10.4 MiB/s) Working FDT set to 4fa00000 1358 bytes read in 3 ms (441.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-bananapi-m4-sdio-wifi-bt.dtbo 4203 bytes read in 2 ms (2 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 17177939 bytes read in 543 ms (30.2 MiB/s) 38219784 bytes read in 1207 ms (30.2 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=0x42760000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17177875 Bytes = 16.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 48f9e000, end 49fffd13 ... OK Loading Device Tree to 0000000048f2a000, end 0000000048f9dfff ... OK Working FDT set to 48f2a000 Starting kernel ... Armbian 25.8.1 Trixie ttyS0 bananapim4zero login: root Password: _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.8.1 for BananaPi BPI-M4-Zero running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (trixie) Updates: Kernel upgrade enabled and 6 packages available for upgrade IPv4: (LAN) xx.xx.xx.xx (WAN) xx.xx.xx.xx Performance: Load: 16% Uptime: 0 min Memory usage: 4% of 3.83G CPU temp: 46°C Usage of /: 5% of 29G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@bananapim4zero:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk2 179:0 0 29.1G 0 disk └─mmcblk2p1 179:1 0 28.8G 0 part /var/log.hdd / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk zram0 252:0 0 1.9G 0 disk [SWAP] zram1 252:1 0 50M 0 disk zram2 252:2 0 0B 0 disk root@bananapim4zero:~# https://www.armbian.com/bananapi-m4-zero/ Seems fine to me?

Boot with serial attached and see if the DRAM is being properly detected. If not this patch would appear to solve the issue. https://lore.kernel.org/linux-sunxi/2813637.mvXUDI8C0e@jernej-laptop/T/#t

When I got the MusePi Pro it came pre flashed so I tested the install. I don't recall it having an amazing DE experience. Not sure about the GPU but like most SBC's I wouldn't expect great things in that department. Which makes me wonder about the MuseBook.

There is probs away to pull in those apt sources from Bianbu, but I haven't messed with it yet. Types: deb URIs: http://archive.spacemit.com/bianbu/ Suites: noble/snapshots/v2.2 noble-security/snapshots/v2.2 noble-porting/snapshots/v2.2 noble-customization/snapshots/v2.2 noble-updates/snapshots/v2.2 bianbu-v2.2-updates Components: main universe restricted multiverse Signed-By: /usr/share/keyrings/bianbu-archive-keyring.gpg Would need to go on gitee or mount one of their imgs and get that *-keyring.gpg

That's not bad honestly. The K1 series runs hot in general. If you add heavy lifting to thee equation it would require a fan. I have the MusePi Pro and BPI-F3 and both run hot.

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

Tried this?

Then stick with what you got going on.

sm1 and g12 share the same common dtsi file. Use that aml flash tool along with --soc=g12a and flash the android img. That should bring you back to where you were. That would be a full recovery.

@user03 For sm1 devices use --soc=g12a Another option which is something I recently had to do with my BPI-CM4 "if I recall correctly, I've also done so on a tvbox i b0rked" is use pyamlboot. sudo pip3 install pyamlboot Short the board and run; sudo boot-g12.py u-boot.bin # if you have a functional u-boot binary This won't actually flash anything, "atleast it didn't in my case?" it will just force the unit to load that boot binary. From there you should be able to hit the SPACEBAR and check ur options using `print` and `help`. Should see options like usbboot, usb_update, etc. Not saying you should use one of these, but... You may be able to find one online or inside the Android img for ur unit. https://github.com/pyavitz/debian-image-builder/tree/feature/files/boot/uboot/ac2xx Anyway. At least you got it booting from USB. Next step would be running a recovery on it.

If you can get the unit in the proper state by shorting, you can flash an android img or custom one using this tool; https://github.com/natinusala/linux-amlogic-toolkit Other repos that you may find useful: https://github.com/mluis/aml-flash-tool https://github.com/Stane1983/aml-linux-usb-burn

This unit on Armbian has bigger problems than the Ethernet not coming up. such as: I believe that stems from the current U-Boot being used. If I flash mine and use my DTS that comes up correctly and the ethernet. Sorry but bringing this unit up to snuff would take more time than I'm currently willing to put in right now. If a window opens up in the future, I'll look into it.

If I have the time I'll do a PR. I also ended up modifying and compiling a new hciattach_opi binary, to get bluetooth to come up.

6.12.y

Here is the opi3lts DTS I use. Eth, WIFI and BT work as they should. If someone feels like running a diff and making the adjustment. sun50i-h6-orangepi-3-lts.dts

@iav nice. Yeap. One fixes topology and the other pcie performance. Tested on the BananaPi BPI-CM4

https://lore.kernel.org/linux-amlogic/20251127170908.14850-1-18255117159@163.com/T/#t https://lore.kernel.org/linux-amlogic/176397825606.3590190.10935817124468233062.b4-ty@linaro.org/T/#t

Short of KIckPi opening a contract with Armbian and providing the units they want worked on. I don't see how?

I haven't personally had issue with 6.17.y, but 6.18.y is a mess on meson-g12. It is basically unusable in my opinion. PCIe is hosed, even the patch that kind of fixes the issue just makes the error go away and doesn't fix the underlining problem "performance". I also get topology errors, but as I haven't really seen anyone yet complain about that, I'm assuming its me. For my personal use, I will be sticking with 6.12.y until things get sorted.

The v2 uses a diff wifi chip: SKW wifi module VS6621S I have a patch for it, which came from KICKPI in the deb builder, but... I don't have a V2 to work any magic on it. chuanzz at one point contacted KICKPI and they sent him an archive that had a bunch of Armbian adds in it, including the patches and board.confs. But the HDD I had the archive on got erased by mistake, so yeah... I don't have the info anymore. I don't see the K2B REV2 getting official support here or by me, as its using a wifi chip that is just to obscure. Here is a u-boot-v2025.07 binary for the K2B REV2 u-boot-sunxi-with-spl.bin

If you are using the radxa-pkg github "which is the most up-to-date" know that its hardcoded to point to specific firmware. To get around this you need to create a file: This example is for an SDIO variant using the radxa dkms package cat > /etc/modprobe.d/aic8800-wireless.conf <<- EOT options aic8800_fdrv_sdio aicwf_dbg_level=0 custregd=0 ps_on=0 options aic8800_bsp_sdio aic_fw_path=/lib/firmware/aic8800_fw/SDIO/aic8800 EOT Also note that the AIC8800 firmware located in armbian-firmware is kind of old and probs not compat with the radxa builds.

Ur welcome.

Ok. Also I think these are wrong for the PI5: dtoverlay=disable-wifi dtoverlay=disable-bt I believe it's: dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 My notes on this: # Pi3 / ZERO2W dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt # PI5 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 # Everything else dtoverlay=disable-wifi dtoverlay=disable-bt Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.

Does it work when you remove that HAT?

Same deal using Noble; https://paste.armbian.com/orexafoxen.less