AM263P4: RS note segment - build reproducibility

Hi Neil,


What the random data is for

The __add_rs_note_segment function serves two purposes:

1. AES-CBC alignment
It zero-pads the program segment payload to a 16-byte boundary. AES-CBC, which is used in the AM263Px secure boot encryption flow, is a block cipher that requires the input data to be an exact multiple of 16 bytes. This padding is a functional requirement.

2. Random nonce
32 random bytes are appended after the padding. These act as entropy/nonce material for the encryption step. The intent is that even two builds from identical source code will produce different encrypted images. This is a deliberate cryptographic design choice. it prevents an attacker who captures multiple firmware images from performing pattern analysis to extract sensitive information.

Consequences of each option

Removing the RS note segment entirely
Not recommended for production use. Removing the segment also removes the alignment padding. If the downstream signing or encryption tool expects a 16-byte aligned payload which it does in the secure boot flow this will either cause a hard failure or, worse, silently produce an encrypted image that fails to boot on the device.

Using a fixed value instead of random
This resolves the reproducibility issue while keeping the alignment padding intact. The tradeoff is a reduction in encryption security, a fixed nonce means identical source always produces identical ciphertext, which weakens the cryptographic protection. However, this is an acceptable tradeoff for CI and development builds, provided those images are never deployed to production hardware.

You can follow below approach

CI / development builds
Use a fixed deterministic 32-byte value (e.g. derived from a build hash or simply all zeros). This restores MD5 reproducibility and makes your pipeline checks reliable.

Production / release builds 
Retain the current random generation to preserve the full security property of the secure boot flow.