AIBOX-K3 (Bianbu 4.0.8): apt dist-upgrade overwrites the Firefly SPI-NOR boot firmware — no display, fan at full speed

Chip Platform SpacemiT
1

Board / image: Firefly AIBOX-K3, Firefly Bianbu 4.0.8 image (kernel 6.18.3, Firefly build k3/firefly-6.18: cb266e72a599/260924, linux-image-6.18.3-generic 6.18.3-1.0.0.4 on hold), boot from SPI NOR, rootfs on UFS.

What I did: sudo apt update && sudo apt dist-upgrade on 2026-10-30 against the stock archive.spacemit.com/bianbu4 sources shipped in the image.

What happened: after the reboot the display is dead (no DRM device at all, sddm has nothing to drive), the fan runs at full speed permanently, and cpufreq and all I2C buses are missing. SSH still works.

Why: the upgrade pulled in spacemit-hardware-support 1.1 as a new dependency of bianbu-minimal. That metapackage installs three packages the Firefly image never had: opensbi-spacemit 1.0.10, esos-spacemit 1.0.10 and u-boot-spl-spacemit 1.0.10. Each one’s postinst writes straight into the SPI NOR with dd (bootinfo, FSBL and env at 0 / 128K / 640K, esos.itb at 704K, fw_dynamic.itb at 1728K on /dev/mtdblock0), with no backup and no board check. I verified the NOR partitions are now byte-identical to the package files. Only U-Boot proper (the uboot partition) is still Firefly’s.

With SpacemiT’s generic firmware in NOR the kernel logs:

riscv-sbi-mpxy-mbox soc:mpxy_mbox@0: SBI MPXY extension not available
platform soc:power-management@0:power-controller: deferred probe pending: supplier soc:mpxy_mbox@0 not ready
platform cac00000.imggpu: deferred probe pending: supplier soc:power-management@0:power-controller not ready
platform soc:dpu1_crtc0: deferred probe pending: supplier soc:power-management@0:power-controller not ready
Spacemit K3: cpu0 OPP init failed (-517)

The boot before the upgrade, same kernel and same DTB, had mailbox registered with 5 channels and the GPU/DPU bound normally. The SRST and SUSP SBI extensions are gone as well, so the RPMI link between OpenSBI and ESOS is not coming up at all.

Digging into SpacemiT’s sources, the AIBOX-K3 ESOS config (k3_rt240_firefly_aibox_k3.dts, added July 2026) sets the RPMI shared-memory base to 0x100800000, while every other K3 board, SpacemiT’s U-Boot k3.dtsi since May 2026, and the Linux reserved-memory map all use 0x100e00000. OpenSBI reads the address from the U-Boot device tree, so on this board OpenSBI and ESOS disagree on where the mailbox is. I filed that upstream: k3: AIBOX-K3 os0 rpmi shmem-base is 0x100800000 while U-Boot/OpenSBI and all other boards use 0x100e00000 (SBI MPXY extension not available) · Issue #2 · spacemit-com/esos · GitHub

Requests for Firefly:

  1. Please publish the original AIBOX-K3 NOR firmware blobs (bootinfo_spinor.bin, FSBL.bin, env.bin, esos.itb, fw_dynamic.itb, u-boot.itb) or a NOR-only recovery package, with Titan Flasher / fastboot steps that don’t wipe the UFS. The postinst scripts keep no backup, so nothing on the box can restore the vendor firmware.
  2. Please hold or pin opensbi-spacemit, esos-spacemit, u-boot-spl-spacemit and spacemit-hardware-support in the Firefly image (the kernel and spacemit-flash-dtbs are already held), or ship Firefly-built versions of them.
  3. Until then, a warning to AIBOX-K3 users not to run apt dist-upgrade / apt full-upgrade on the Bianbu image would save some boards.

Workaround for anyone who hasn’t upgraded yet: before upgrading, create /etc/apt/preferences.d/no-spacemit-firmware containing

Package: opensbi-spacemit esos-spacemit u-boot-spl-spacemit spacemit-hardware-support
Pin: release *
Pin-Priority: -1

apt will then hold back bianbu-minimal instead of reflashing the NOR.

1 Like
3

Follow-up after a serial-console session on the box.

Confirmed from the UART and the U-Boot prompt. The boot chain is now SpacemiT’s generic SPL (Oct 16 build, from u-boot-spl-spacemit 1.0.10) → Firefly’s own U-Boot (Sep 24, still in the uboot partition) → Firefly kernel. U-Boot identifies the board correctly (product_name=k3-firefly-aibox-k3). The device tree U-Boot hands to OpenSBI puts the RPMI mailbox queues at 0x100e00000 (rpmi-shmem-mbox@cac90c00), while SpacemiT’s ESOS 1.0.10 AIBOX-K3 config serves at 0x100800000. From Linux, 0x100e00000 is PMP-protected (OpenSBI has claimed it) and MPXY/SRST/SUSP are all absent. The full U-Boot dump and the serial boot log are in the latest comment on the GitHub issue linked in the first post.

Three things Firefly should know, found along the way:

  1. With the display stack stuck in deferred probe, reboot/shutdown panic in the DP driver (inno_dp_shutdown → cancel_delayed_work_sync on never-initialised work → “Attempted to kill init”). Affected boxes need a power-cycle; echo b > /proc/sysrq-trigger works as a remote hard reset. That’s in the Firefly kernel build (k3/firefly-6.18: cb266e72a599/260924).
  2. The image runs agetty -a root on ttyS0 (systemd override in serial-getty@.service.d), so the front Console port is an auto-logged-in root shell for anyone with a cable. Please drop that from production images.
  3. Console port note for the docs: it doesn’t enumerate over a USB-C-to-USB-C cable from a USB-C host (two cables tried from a MacBook, no attach at all). With a USB-A host/adapter it shows up as a CDC-ACM “USB TO UART BRIDGE”, 115200 8N1. U-Boot’s autoboot stop key is s.

Quick check for other AIBOX-K3 owners: dmesg | grep -i mpxy — if you see SBI MPXY extension not available and dpkg -l esos-spacemit shows it installed, your NOR has already been overwritten. Holding packages won’t undo it; only a NOR reflash will.

1 Like
5

As described at https://community.t-firefly.com/en/docs/products/computers/AIBOX-K3/usage-k3: AIBOX-K3 does not currently support full system software upgrades using apt upgrade. Regular software packages can be installed and updated using apt update and apt install. Executing the apt update and apt install commands works without issue. To upgrade critical packages such as esos, uboot, and kernel, you need to 内部工具 the official Firefly SDK package and update it by compiling and flashing it.

6

Thanks. Two things worth adding, because “rebuild the SDK and reflash” is a big hammer for what turned out to be three device-tree values, and the board is fixed now without it.

  1. Your public SDK tree already contains the fix; SpacemiT’s package doesn’t. In the Firefly-spacemit-linux esos repository, branch k3/firefly-6.18, commit f039ec69c8 (“k3: aibox-k3: update dts”, 30 July) moves the AIBOX-K3 core-0 RPMI shmem-base from 0x1 0x800000 to 0x1 0xe00000 and raises the edcdc1/edcdc2 regulator-max-microvolt from 1005000 to 1100000. SpacemiT’s k3-br-v1.0.y branch, which esos-spacemit 1.0.10 in the Bianbu 4 archive is built from, still has the old values. Could Firefly push that commit to SpacemiT so the archive package stops breaking AIBOX-K3 boards? I’ve referenced it on the GitHub issue linked in the first post.

  2. Recovery without a full reflash, confirmed working. The board DTB is a separate LZO-compressed image inside esos.itb, so I patched just those three properties in the 1.0.10 esos.itb (the other 36 FIT images stay byte-identical), wrote it to the NOR esos partition at 704K with dd the same way the package postinst does, and rebooted. The kernel now logs mailbox registered with 5 channels, SRST and SUSP are back, DRM/GPU/I2C/cpufreq all probe, HDMI output is back, the fan is back under thermal control, and a plain reboot works again (so the inno_dp_shutdown panic from my earlier post only bites while the display is stuck in deferred probe). No Titan Flasher, no UFS wipe, no Baidu download. Anyone in the same state can do the same with fdtput, lzop -9 and mkimage on the package’s esos.itb.

Separately, please still consider (a) holding or pinning opensbi-spacemit, esos-spacemit, u-boot-spl-spacemit and spacemit-hardware-support in the Firefly image, as the kernel already is, since the next upload of esos-spacemit will re-flash the broken DTB on every AIBOX-K3 that upgrades, and (b) publishing the AIBOX-K3 NOR blobs (the partition_4M.json set) on the download page so owners don’t have to build the whole SDK to recover a 4 MB flash.

1 Like
7

Thanks for the feedback. Your suggestions are very valuable. I will check with our technical team to confirm the details. We really appreciate your support!

8

good