Packed image has incorrect parameter partition

[cgilmour]

When trying to build and install armian using scripts from this project, https://github.com/luisdosreis/linknlink-isg-box-se-armbian the image produced after running afptool-rs to repack the image could not be installed using the Rockchip upgrade_tool.

After further debugging, it seems the changes since commit ff93e32 produce an incorrect parameter partition. Discussion here. Main point: ERROR:DownloadImage-->CheckParamPartSize failed is reported when attempting to install the firmware.

Happy to collect extra information or test a fix provided by a developer.

The project above does apply a patch to afptool-rs, but it's specific to the chip family being used, and not the issue with the parameter partition.

(I'm just a user of that project, not a maintainer or embedded engineer)

[suyulin]

Thanks for the detailed report and for narrowing this down to ff93e32.

I believe this is a compatibility regression introduced by e4f4caa (fix: strip and re-wrap PARM header for parameter partitions).

The repack script you linked already wraps Image/parameter.txt as:

PARM + little-endian content length + content + CRC

Current afptool-rs then unconditionally applies the same wrapper again when packing a partition named parameter. That produces a nested PARM blob and adds another 12 bytes, which matches the 0x174 / 0x180 size difference shown in the forum discussion. The older ff93e32 build works because it writes the already-wrapped file without adding another wrapper.

As a temporary workaround, either:

• continue using ff93e32; or
• when using current main, remove/skip wrap_parameter_for_afptool in the external repack script and pass the plain-text parameter.txt.

The intended upstream fix is to make packing accept both forms: preserve an already-valid PARM blob, otherwise wrap plain parameter content. We should also validate the PARM magic/length while unpacking and add regression coverage for pre-wrapped input.

The current test suite passes, but it only covers plain-text parameter input and therefore misses this compatibility case.

[cgilmour]

Thanks @suyulin, amazingly fast feedback. I'll try the second suggestion using current main.

[suyulin]

The upstream fix is now available on main in 0235e30.

It now:

• preserves an already-valid PARM-wrapped parameter.txt instead of wrapping it a second time;
• still wraps a plain-text parameter.txt when needed; and
• uses the vendor-compatible 0x04C11DB7 polynomial for the parameter CRC.

So you should be able to test your existing repack script as-is, including wrap_parameter_for_afptool; removing that function is no longer necessary with the latest main.

Could you rebuild afptool-rs from the latest main (or remove the script's cached binary first), repack the image, and confirm whether upgrade_tool uf now accepts it? Thanks again for testing this on real hardware.

[cgilmour]

I've tried it. It now works perfectly when the script does not call wrap_parameter_for_afptool. Accepted by uf, installs, boots as expected.

It fails when that function is called, not accepted by uf. I think you expected this to work as well. Would you like me to check into this further?

I've got two working solutions now: original script and older afptool-rs, modified script and current afptool-rs. Happy to debug a bit more if it's helpful/important to get this other combination (original script + current afptool-rs) working too.