install --uboot-file crashes: NameError 'cached' is not defined (RAM-burn session)

[widgetii]

Summary

defib install --uboot-file <file> crashes with NameError: name 'cached' is not defined before it can burn U-Boot. The --uboot-file code path never assigns cached, but the RecoverySession for the RAM-burn is constructed with firmware_path=str(cached).

Environment

• defib a39e0e2 (master), pyproject.toml version 0.1.0
• Target: hi3516ev300 (128 MiB SPI-NAND, board Rostelecom IPC8232SWC-WE)
• Host: Linux

Repro

defib install -c hi3516ev300 \
  --firmware openipc.hi3516ev300-nand-ultimate.tgz \
  --nand -p /dev/ttyUSB4 \
  --uboot-file u-boot-hi3516ev300-nand.bin \
  --nic eth0 --host-ip ... --device-ip ...

Root cause

In src/defib/cli/app.py, Step 2 "Get U-Boot":

# --- Step 2: Get U-Boot ---
if uboot_file:                       # L2349
    ub_path = _Path(uboot_file)
    ...
    uboot_raw = ub_path.read_bytes() # cached is NEVER set here
    uboot_label = ub_path.name
else:
    ...
    cached = get_cached_path(chip)   # L2368 — only set in the else branch
    ...

Then later:

session = RecoverySession(
    chip=chip, firmware_path=str(cached),   # L2439 — NameError when --uboot-file was used
    ...
)

cached is only bound in the else (no --uboot-file) branch, so any --uboot-file invocation raises NameError at L2439 (and the rack-fastboot path at L2480 has the same cached.read_bytes() reference).

Expected

--uboot-file should work. The apparent intent is: RAM-burn uses the cached universal U-Boot (defib knows its SPL boundary), while --uboot-file overrides only the image flashed to the boot partition (uboot_raw). So cached should be resolved unconditionally.

Suggested fix

Resolve cached (the universal U-Boot for the RAM-burn) before the if uboot_file: block, and let --uboot-file override only uboot_raw/uboot_label:

cached = get_cached_path(chip) or (download_firmware(chip) if has_firmware(chip) else None)
if uboot_file:
    ub_path = _Path(uboot_file); uboot_raw = ub_path.read_bytes(); uboot_label = ub_path.name
else:
    ...
    uboot_raw = cached.read_bytes(); uboot_label = cached.name

(For V500 chips with no universal U-Boot, cached may legitimately be None; the session should then RAM-burn uboot_file itself.)

Workaround

Omit --uboot-file; defib then uses the cached universal U-Boot for both RAM-burn and the flashed boot partition, which boots fine on hi3516ev300 NAND.

[widgetii]

This bug is more than a crash — the --uboot-file workaround (omitting it) causes silent NAND corruption on --nand installs, because the RAM-burned u-boot is what actually executes the nand write of kernel/rootfs.

The deeper issue

_install_async RAM-burns cached (the universal u-boot) and uses it to write the partitions; --uboot-file was only ever meant to override the flashed boot image, not the writer. But on HiSilicon SPI-NAND the u-boot doing the nand write must be in the same NAND ECC scheme as the reader. u-boot-<chip>-universal.bin and u-boot-<chip>-nand.bin use different ECC schemes, and the kernel's scheme matches the nand one.

What it looks like in practice (hi3516ev300 + Winbond W25N01GV)

Install with the universal u-boot as writer → the camera boots, UBIFS mounts, then throws:

UBIFS error (ubi0:0): ubifs_check_node: bad node at LEB 120, node_type 9 (indexing node)
UBIFS error (ubi0:0): ubifs_iget: failed to read inode N, error -117
UBIFS ... switched to read-only mode

Proof it's an ECC-domain mismatch, not a bad write or bad flash:

• u-boot read-back of the freshly written rootfs = source CRC, byte-perfect.
• /sys/class/mtd/mtd3/ecc_failures = 0, corrected_bits = 0 (kernel flags no ECC error).
• dd if=/dev/mtd3 | md5sum (kernel raw read) ≠ md5 of the source image → the kernel reads different bytes than u-boot wrote.
• Same flash read by two u-boots: crc32 = 0529bf41 (universal) vs 8d080558 (nand) → different ECC schemes.

Rewriting the rootfs with u-boot-hi3516ev300-**nand**.bin as the writer fixed it permanently (survives reboots + a full find / -exec cat with 0 UBIFS errors).

Suggested fix (beyond the NameError)

For install --nand, the RAM-burn writer should default to u-boot-<chip>-nand.bin, not -universal.bin — i.e., resolve the NAND u-boot for the session that performs the flash writes, not just for the boot-partition image. Otherwise --nand installs on chips with a distinct nand u-boot (and on-die-ECC SPI-NAND like the W25N01GV) come up subtly corrupted even when every write "verifies" against the same (wrong-domain) u-boot.