sunxi-fel: add TOC0 boot image support

[jameshilliard]

Secure boot sunxi images use TOC0 containers instead of a bare eGON SPL header. Teach the spl/uboot command path to recognize a TOC0 image, validate its header and checksum, extract the firmware item, and wrap it in a synthetic eGON SPL header at the SoC SPL load address.

After the wrapped SPL returns to FEL, pass the payload appended after the TOC0 container to the existing U-Boot image loader so FIT-based u-boot-sunxi-with-spl.bin images can be loaded by the normal uboot command path.

[apritzel]

Why is that code patching the in-SRAM copy to look like eGON? U-Boot is able to handle TOC0 images, when loaded from SD card, for instance. So I think for consistency it should keep as much of the original TOC0 as possible.

[jameshilliard]

The conversion is intentional for the FEL path. It is not trying to model the
SD-card boot path; it is adapting a TOC0-packaged SPL to the existing
sunxi-fel/U-Boot FEL handoff convention.

For media boot, the BROM parses TOC0 itself, loads the firmware item to the
TOC0 load address, and jumps there. That is why U-Boot can handle TOC0 images
when they are loaded from SD card or another boot medium.

For FEL spl/uboot, the BROM is not parsing the uploaded image. sunxi-fel
is staging SRAM directly and then executing the sunxi-tools FEL SPL trampoline.
That trampoline is deliberately eGON-oriented:

• aw_fel_write_and_execute_spl() validates an eGON.BT0 header;
• fel-to-spl-thunk.S validates the eGON length and checksum;
• the thunk calls the SPL entry at soc_info->spl_addr;
• on success, it changes the in-SRAM signature from eGON.BT0 to eGON.FEL.

U-Boot also has special handling for that eGON/FEL convention. In SPL,
arch/arm/mach-sunxi/board.c detects a normal media boot by finding a valid
eGON.BT0 or TOC0.GLH image at SPL_ADDR. If neither is valid, it treats
the boot source as BOOT_DEVICE_BOARD, which is the FEL path, and returns to
the BROM FEL loop to receive the next-stage payload. In U-Boot proper,
board/sunxi/board.c also parses the sunxi SPL header fields that sunxi-fel
uses for FEL scripts and uEnv data.

So preserving a valid TOC0 header in SRAM is not equivalent here. It would make
the staged image look like a media-boot image to U-Boot's boot-source detection,
whereas the FEL path needs the SPL to return to the BROM FEL loop after DRAM
init. The synthetic eGON wrapper gives the TOC0 firmware item the same in-SRAM
shape and return-marker behavior that the existing FEL path already expects.

The original TOC0 container is still validated by sunxi-fel; the firmware item
is extracted from it and placed at the load offset described by the TOC0 item.
The eGON wrapper is only the transient in-SRAM representation used for the FEL
SPL trampoline and U-Boot's existing FEL detection convention.