c0rnelius

I would suggest using a better SD card. G12B:BL:6e7c85:2a3b91;FEAT:E0F83180:402000;POC:F;RCY:0;EMMC:0;READ:0;0. bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 bl2_stage_init 0x02 L0:00000000 L1:20000703 L2:00008067 L3:14000000 B2:00402000 B1:e0f83180 TE: 53694 BL2 Built : 19:23:21, Sep 18 2020. g12b g9fde858 - gongwei.chen@droid11-sz Board ID = 12 Set A53 clk to 24M Set A73 clk to 24M Set clk81 to 24M A53 clk: 1200 MHz A73 clk: 1200 MHz CLK81: 166.6M smccc: 00011aa2 eMMC boot @ 0 sw8 s board id: 12 Load FIP HDR DDR from eMMC, src: 0x00010200, des: 0xfffd0000, size: 0x00004000, part: 0 Get wrong ddr fw magic! Error!! fw parse done PIEI prepare done 00000000 emmc switch 1 ok 00000000 emmc switch 2 ok NO find ddr boot_info from eMMC fastboot data verify result: 255 Cfg max: 12, cur: 1. Board id: 255. Force loop cfg LPDDR4 probe LPDDR4_PHY_V_0_1_22-Built : 14:57:26, Sep 1 2020. g12b g3c95fed - gongwei.chen@droid11-sz ddr clk to 1608MHz 00000000 emmc switch 0 ok dmc_version 0001 Check phy result INFO : End of CA training INFO : End of initialization INFO : Training has run successfully! Check phy result INFO : End of initialization INFO : End of read enable training INFO : End of fine write leveling INFO : End of read dq deskew training INFO : End of MPR read delay center optimization INFO : End of Write leveling coarse delay INFO : End of read delay center optimization INFO : Training has run successfully! Check phy result INFO : End of initialization INFO : End of MPR read delay center optimization INFO : End of write delay center optimization INFO : End of read delay center optimization INFO : End of max read latency training INFO : Training has run successfully! 1D training succeed Check phy result INFO : End of initialization INFO : End of 2D read delay Voltage center optimization INFO : End of 2D read delay Voltage center optimization INFO : End of 2D write delay Voltage center optimization INFO : End of 2D write delay Voltage center optimization INFO : Training has run successfully! soc_vref_reg_value 0x 0000001d 0000001c 0000001b 0000001e 0000001c 0000001c 0000001d 0000001c 0000001c 0000001a 0000001a 0000001b 00000019 0000001f 0000001b 0000001c 0000001b 0000001e 0000001c 0000001e 0000001a 0000001c 0000001c 0000001b 0000001c 0000001c 0000001b 0000001d 0000001d 0000001c 0000001b 0000001c dwc_ddrphy_apb_wr((0<<20)|(2<<16)|(0<<12)|(0xb0):0004 dram_vref_reg_value 0x 0000004d 2D training succeed auto size-- 65535DDR cs0 size: 2048MB DDR cs1 size: 2048MB DMC_DDR_CTRL: 00e00024DDR size: 3928MB cs0 DataBus test pass cs1 DataBus test pass cs0 AddrBus test pass cs1 AddrBus test pass non-sec scramble use zero key ddr scramble enabled 100bdlr_step_size ps== 403 result report boot times 0Enable ddr reg access 00000000 emmc switch 3 ok Authentication key not yet programmed get rpmb counter error 0x00000007 00000000 emmc switch 0 ok Load FIP HDR from eMMC, src: 0x00010200, des: 0x01700000, size: 0x00004000, part: 0 Load BL3X from eMMC, src: 0x00078200, des: 0x01768000, size: 0x000bea00, part: 0 0.0;M3 CHK:0;cm4_sp_mode 0 MVN_1=0x00000000 MVN_2=0x00000000 [Image: g12b_v1.1.3390-6ac5299 2019-09-26 14:10:05 luan.yuan@droid15-sz] OPS=0x10 ring efuse init chipver efuse init 29 0b 10 00 01 25 0c 00 00 0c 37 32 34 54 31 50 [0.778675 Inits done] secure task start! high task start! low task start! run into bl31 NOTICE: BL31: v1.3(release):4fc40b1 NOTICE: BL31: Built : 15:58:17, May 22 2019 NOTICE: BL31: G12A normal boot! NOTICE: BL31: BL33 decompress pass ERROR: Error initializing runtime service opteed_fast <debug_uart> U-Boot 2026.01 (Jan 15 2026 - 07:25:48 -0500) bpi-m2s Model: BananaPi M2S SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2) DRAM: 2 GiB (total 3.8 GiB) Core: 401 devices, 31 uclasses, devicetree: separate MMC: mmc@ffe05000: 0, mmc@ffe07000: 1 Loading Environment from nowhere... OK PCIE-0: Link up (Gen1-x1, Bus0) In: usbkbd,serial Out: vidconsole,serial Err: vidconsole,serial Net: eth0: ethernet@ff3f0000 starting USB... Starting the controller USB XHCI 1.10 Bus usb@ff500000: 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 mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 8133 bytes read in 2 ms (3.9 MiB/s) ## Executing script at 08000000 U-boot default fdtfile: amlogic/meson-g12b-a311d-bananapi-m2s.dtb Current variant: 211 bytes read in 1 ms (206.1 KiB/s) Current fdtfile after armbianEnv: amlogic/meson-g12b-a311d-bananapi-m2s.dtb Mainline bootargs: root=UUID=45e1ab7d-9528-4d3b-8b8e-27c59e112250 rootwait rootfstype=ext4 splash=verbose console=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ubootpart=fe959640-01 libata.force=noncq usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory 25338901 bytes read in 1073 ms (22.5 MiB/s) 42338816 bytes read in 1792 ms (22.5 MiB/s) 80849 bytes read in 6 ms (12.8 MiB/s) Working FDT set to 4080000 232 bytes read in 5 ms (44.9 KiB/s) Applying kernel provided DT fixup script (meson-fixup.scr) ## Executing script at 32000000 ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 25338837 Bytes = 24.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 04080000 Booting using the fdt blob at 0x4080000 Working FDT set to 4080000 Loading Ramdisk to 7e7d5000, end 7ffff3d5 ... OK Loading Device Tree to 000000007e758000, end 000000007e7d4fff ... OK Working FDT set to 7e758000 Starting kernel ... Armbian 26.2.1 Trixie ttyAML0 bananapim2s login: root Password: _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v26.2.1 for Banana Pi M2S running Armbian Linux 6.18.15-current-meson64 Packages: Debian stable (trixie) Performance: Load: 12% Uptime: 1m Memory usage: 5% of 3.68G CPU temp: 44°C Usage of /: 5% of 29G Commands: Configuration: armbian-config Monitoring : htop root@bananapim2s:~#

Here is an IMG with just u-boot flash to it; https://github.com/pyavitz/binary/releases/download/images/k1-spacemit-boot.img Using it will bypass the SPI and allow you to boot from USB NVME EMMC. Granted, an Armbian IMG would need to have already been flashed or transferred to one of them. It could be useful if say, you b0rked the SPI and wanna attempt to fix it or to use the SD card as a chainload mech to boot into the NVMe.

I don't own an OPI RV2, but I do have a few K1's. I suggest trying without that NVMe attached as it may be a contributing factor to boot fails. Technically correct. But I've seen some peps attempt some odd things and then wonder why it doesn't work. With serial attached, stop auto boot with the SPACEBAR. From there run `nvme` and you'll be provided with options. Are you suggesting you wanna bypass SPI by using an SD card to boot into say an NVMe or USB? Should be easy enough. Partition an SD card with an 4MiB offset and flash the u-boot bins to it. U-boot should then check for what ever is available to boot from; USB SD NVME MMC. If there is no extlinux.conf, boot.scr or *.efi to boot from on the SD, it will look else where.

Some NVMe's just don't play nice with some units. I have one such NVMe, which is why I rarely try to use it. Also u-boot is not set up to look for an infinite amount of $devnum. Currently it is hard coded to look for nvme 0:1. So I suggest moving the NVMe to the first available. According to the boot log you have more than one PCIE link up [ 1.438] PCIE-0: Link up (Gen2-x2, Bus0) <-- Thats where you want to attach the NVMe [ 1.600] PCIE-2: Link up (Gen2-x2, Bus2) Honestly though. It looks like the NVMe you are trying to use isn't compat.

The armbian boot loader is diff than the vendors. It checks for specific things in a particular order. nvme_devtype=nvme nvme_devnum=0 nvme_bootpart=1 autoboot=if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; nvme part; \ setenv devtype $nvme_devtype; \ setenv devnum $nvme_devnum; \ setenv distro_bootpart $nvme_bootpart; \ if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; bootcmd=echo "Loading K1-X Environment ..."; \ echo ""; \ echo "Running NVMe Scan ..."; \ nvme scan; \ run autoboot SD takes priority. After that it checks for an eMMC and if nothing on the eMMC is found it can use, it then moves on to check the NVMe. What this means? If the unit has an SPI, it needs to be updated with the Armbian boot loader. If the bootloader finds an extlinux.conf, boot.scr or *.EFI on the eMMC it will attempt to boot from it. I have a BPI-F3 which has no SPI. What I do in that case is boot from SD, format the eMMC and transfer the install to the NVMe. I then flash u-boot to the eMMC and wham oh. System boots from NVMe. In the case of an SPI, its the same. As long as it doesn't find anything of use on the eMMC your good.

Here is an example of an overlay for adding an RTC to the radxa zero /dts-v1/; /plugin/; / { compatible = "radxa,zero", "amlogic,g12a"; fragment@0 { target-path = "/"; __overlay__ { aliases { rtc0 = &rtc; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { #address-cells = <1>; #size-cells = <0>; rtc: rtc@68 { compatible = "dallas,ds1307"; reg = <0x68>; wakeup-source; }; }; }; __overrides__ { rtc = <0>,"+0"; addr = <&rtc>, "reg:0"; }; }; Key bits here: * aliases (some of these AML units have vrtc on rtc0, so it may need to be set to rtc1) * i2c# (this should be obvious) * compatible string * wakeup-source The i2c-dev module must be force loaded in some cases. If it isn't hard coded into the kernel, you can add it to /etc/modules

https://forums.kali.org/ There is an arm64 section.

Add to /etc/rc.local and reboot. echo "1" > /sys/devices/system/cpu/cpufreq/boost && echo "performance" | tee /sys/devices/system/cpu/cpu[0-9]/cpufreq/scaling_governor &&

Not sure its related, but on the MusePi Pro I was getting odd happenings with the PCIe. Adding this to the command line resolved it my case: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off

@sven-ola https://lore.kernel.org/spacemit/20260310161853.3900605-1-gaohan@iscas.ac.cn/T/#t Sometime soon-ish I'll be doing another PR with early SD card and CPU freq scaling support. The above link should at least get you boot from eMMC or NVMe.

Welcome to Armbian! Documentation: https://docs.armbian.com | Community support: https://forum.armbian.com IP address: xx.x.x.xx Create root password: ***** Repeat root password: ***** Developer Preview Build This Armbian image was generated automatically for development and testing purpose. It may include unfinished features or unstable components. If you are not here to report issues or just test it, please do not use this image in production. Expect things to change — or even break — as improvements are made. Creating a new user account. Press <Ctrl-C> to abort Please provide a username (eg. your first name): Disabling user account creation procedure root@orangepi3-lts:~# rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth bluetooth unblocked unblocked 1 wlan phy0 unblocked unblocked 2 bluetooth hci0 unblocked unblocked root@orangepi3-lts:~# bluetoothctl [NEW] Media /org/bluez/hci0 SupportedUUIDs: 0000110a-0000-1000-8000-00805f9b34fb SupportedUUIDs: 0000110b-0000-1000-8000-00805f9b34fb Agent registered [CHG] Controller 30:96:18:9E:A7:02 Pairable: yes hci0 new_settings: powered bondable ssp br/edr le secure-conn [bluetoothctl]> show Controller 30:96:18:9E:A7:02 (public) Manufacturer: 0x01ec (492) Version: 0x09 (9) Name: orangepi3-lts Alias: orangepi3-lts Class: 0x00400000 (4194304) Powered: yes PowerState: on Discoverable: no DiscoverableTimeout: 0x000000b4 (180) Pairable: yes UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: SIM Access (0000112d-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0554 Discovering: no Roles: central Roles: peripheral Advertising Features: ActiveInstances: 0x00 (0) SupportedInstances: 0x10 (16) SupportedIncludes: tx-power SupportedIncludes: appearance SupportedIncludes: local-name SupportedSecondaryChannels: 1M SupportedSecondaryChannels: 2M SupportedSecondaryChannels: Coded SupportedCapabilities.MinTxPower: 0xffffffec (-20) SupportedCapabilities.MaxTxPower: 0x0008 (8) SupportedCapabilities.MaxAdvLen: 0xfb (251) SupportedCapabilities.MaxScnRspLen: 0xfb (251) SupportedFeatures: CanSetTxPower SupportedFeatures: HardwareOffload [bluetoothctl]> exit root@orangepi3-lts:~# uname -a Linux orangepi3-lts 6.12.74-current-sunxi64 #6 SMP Thu Feb 19 15:29:56 UTC 2026 aarch64 GNU/Linux

I'm not seeing any bluetooth error, are you? rfkill unblock all

Which kernel? Should work on 6.12.y, although I see issues with it on 6.18.y, as there were changes made to that wireless patch set that don't agree with my DTS changes. In fairness, I haven't checked to see if it works at all regardless of my changes on that kernel though. Its on my list of things to investigate. The new DTS changes require an updated hciattach_opi binary. "known to work on 6.12.y" https://github.com/armbian/build/blob/main/packages/blobs/bt/hciattach/hciattach_opi_arm64_upstream

Looks like the same adjustment that was made for EDGE needs to be done so for CURRENT.

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