Erase a NAND camera's UBI partition by name, so chips bigger than 128 MiB install too

[widgetii]

Follows #392, using OpenIPC/u-boot-xmedia#12.

The UBI-only NAND install erased a fixed 0x7f00000 from 0x100000, which is the end of a 128 MiB chip. The partition is -(ubi) and runs to the end of whatever chip there is, so on a bigger one stale blocks were left behind. UBI counts those as corrupted PEBs when it attaches.

Linux step. It now reads:

tftpboot <la> rootfs.ubi.<board> && nand erase.part ubi && nand write.trimffs <la> ubi ${filesize}

• The erase and the write both name the partition, so they resolve the same range from the bootloader's mtdparts.
• erase.part comes with the u-boot-xmedia NAND build that the U-Boot step installs first (Fixed some translation errors about zh_CN #12, published from master).

Full-flash image. It is written from whatever U-Boot the camera already has, so it erases with nand erase.chip and still writes with write.trimffs.

Verified on a hi3516ev300 (W25N01GV, 128 MiB) with the published-to-be u-boot-xmedia build:

• nand erase.part ubi resolved to offset 0x100000, size 0x7f00000.
• The write by name went to offset 0x100000.
• The camera booted /boot/fitImage.

service/run.sh test passes. The documents.json hashes changed only for the seven UBI-only SoCs. The commit also gofmt's catalogue.go, which #392 left unformatted.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Erase NAND UBI partitions to the end of the chip

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Erase the UBI partition by name so installs clear chips larger than 128 MiB.
• Erase the whole chip for full-flash images to support existing bootloaders.
• Update wizard tests and document hashes for the affected SoCs.

Diagram

graph TD
  A["Wizard commands"] --> B{"Image type"} --> C["Erase UBI partition"] --> E["Trimmed write"] --> F["NAND flash"]
  B --> D["Erase whole chip"] --> E
  G["New NAND U-Boot"] --> C

Loading

High-Level Assessment

Use the bootloader's named UBI partition for Linux installs and a whole-chip erase for full images. This avoids hard-coded chip geometry while respecting that the existing bootloader used for a full image may not support erase.part; calculating the device size in wizard commands would add complexity without a clear benefit.

Files changed (5) +53 / -28

Bug fix (2) +36 / -13

camera.goRemove fixed UBI erase geometry +4/-6

Remove fixed UBI erase geometry

• Removes the 128 MiB-specific UBI offset and region-size constants. Updates the layout comment to describe a partition extending to the end of the chip.

service/internal/wizard/camera.go

lines.goGenerate size-independent UBI flashing commands +32/-7

Generate size-independent UBI flashing commands

• Adds a shared helper that erases the named UBI partition for Linux installs or the whole chip for full images, then writes with write.trimffs. Applies it to SD and network transfer variants while leaving other layouts on their existing path.

service/internal/wizard/lines.go

Refactor (1) +5 / -5

catalogue.goFormat NAND catalogue fields +5/-5

Format NAND catalogue fields

• Aligns the SoC struct fields with gofmt. No catalogue behavior changes.

service/internal/catalogue/catalogue.go

Tests (2) +12 / -10

documents.jsonRefresh affected wizard document hashes +7/-7

Refresh affected wizard document hashes

• Updates the expected hashes for seven UBI-only SoCs whose generated flashing instructions changed.

service/internal/wizard/testdata/documents.json

wizard_test.goAssert partition and whole-chip erase commands +5/-3

Assert partition and whole-chip erase commands

• Checks that UBI-only Linux commands erase and write by partition name, without the fixed erase size. Checks that full-image commands erase the chip and retain write.trimffs.

service/internal/wizard/wizard_test.go

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗