rv1109 and rv1126 ship a NAND tarball with no kernel in it

[openipc-ai]

rv1109_lite and rv1126_lite publish a firmware tarball that contains no kernel — not beside the rootfs, and not inside it either. The only artifact those two boards ship cannot install a working system.

Evidence

The published assets hold the rootfs and nothing else:

$ curl -sL .../releases/download/latest/openipc.rv1126-nand-lite.tgz | tar tz
rootfs.ubi.rv1126
rootfs.ubi.rv1126.md5sum

$ curl -sL .../releases/download/latest/openipc.rv1109-nand-lite.tgz | tar tz
rootfs.ubi.rv1109
rootfs.ubi.rv1109.md5sum

And there is no NOR tarball to fall back on — both boards are UBI-only (BR2_TARGET_ROOTFS_SQUASHFS is not set):

openipc.rv1126-nor-lite.tgz: 404
openipc.rv1109-nor-lite.tgz: 404

Why

Makefile:140-145 chooses the repack branch by vendor:

ifeq ($(BR2_TARGET_ROOTFS_UBI),y)
ifneq ($(filter $(BR2_OPENIPC_SOC_VENDOR),"rockchip" "sigmastar"),)
	@$(call PREPARE_REPACK,,,rootfs.ubi,16384,nand)      # no kernel in the tarball
else
	@$(call PREPARE_REPACK,uImage,4096,rootfs.ubi,16384,nand)
endif
endif

Omitting the kernel is correct for rockchip and sigmastar because their ubinize config puts it inside the UBI image:

general/scripts/ubifs/ubinize_rockchip.cfg    vol_name=kernel  image=BINARIES_DIR/zboot.img
general/scripts/ubifs/ubinize_sigmastar.cfg   vol_name=kernel  image=BINARIES_DIR/uImage
general/scripts/ubifs/ubinize.cfg             (no kernel volume at all)

rv1109 and rv1126 fall between the two. They are vendor rockchip, so they take the kernel-less repack branch — but unlike rv1103/rv1106 they point at the generic ubinize.cfg, which has no kernel volume:

br-ext-chip-rockchip/configs/rv1109_lite_defconfig:41
  BR2_TARGET_ROOTFS_UBI_CUSTOM_CONFIG_FILE=".../scripts/ubifs/ubinize.cfg"
br-ext-chip-rockchip/configs/rv1126_lite_defconfig:41
  BR2_TARGET_ROOTFS_UBI_CUSTOM_CONFIG_FILE=".../scripts/ubifs/ubinize.cfg"

br-ext-chip-rockchip/configs/rv1106_lite_defconfig:43
  BR2_TARGET_ROOTFS_UBI_CUSTOM_CONFIG_FILE=".../scripts/ubifs/ubinize_rockchip.cfg"

Both sides assume the other is carrying the kernel, so nobody does. All four boards build zboot.img (BR2_LINUX_KERNEL_IMAGE_NAME="zboot.img"); only rv1103/rv1106 get it packaged.

This is invisible to CI. rv1126_lite is in SMOKE_BOARDS, so it builds on every PR — the build succeeds, because the defect is in what gets packaged, not in what gets compiled. The kernel-less branch also passes empty kernel arguments to PREPARE_REPACK, so no CHECK_SIZE runs on a kernel for these boards and a zero-size kernel could not be caught there either.

Two coherent fixes

1. Point rv1109/rv1126 at ubinize_rockchip.cfg, so the kernel goes inside the UBI as it does for rv1103/rv1106. Consistent with the rest of the vendor, and the repack branch then becomes correct as written.
2. Key the repack branch on whether the ubinize config actually carries a kernel volume, rather than on the vendor name — which removes the class of bug rather than this instance of it.

I do not know which of the two matches the intent for these boards, hence an issue rather than a PR.

Secondary, same root cause

.github/workflows/build.yml:358 gates the Telegram "Send binary" step on env.NORFW:

if: github.event_name != 'pull_request' && env.NORFW
...
-F document=@${NORFW}

NANDFW is collected at line 304 and uploaded to the release at build-one.yml:136-137, but never posted. A NAND-only board therefore never announces a binary at all. Cosmetic next to the above, but it is why nobody noticed these two boards were shipping half an image.

Found while researching NAND artifact layouts for OpenIPC/website#58.