[PATCH 2/2] tools: amlimage: Add support for GXBB eMMC header

[Jonas Karlman]

Hi Simon,

On 2025-01-04 20:31, Simon Glass wrote:
> Hi Jonas,
> 
> On Sat, 4 Jan 2025 at 10:59, Jonas Karlman <jonas at kwiboo.se> wrote:
>>
>> GXBB BL1 only tries to read boot image from sector 0 on eMMC and sector
>> 1 on SD-card. GXL and newer read boot image from sector 1 on both eMMC
>> and SD-card.
>>
>> Vendor BL2 have solved the issue with different offsets by considering
>> where BL2 was loaded from to adjust the offset where BL3 is read from.
>>
>> This provide a different solution to create a boot image that can be
>> booted from both eMMC and SD-card and where the offset for reading next
>> stage loader can be shared for both boot options.
>>
>> Inject code, that relocate the payload located at 0x1200 offset in TZRAM
>> to the expected offset of 0x1000, into the padding area at offset 0x200
>> when a normal GXBB boot image is created. A special GXBB eMMC header can
>> then be created that have the payload offset point to this relocate
>> code, BL1 will jump to this relocate code when booted from eMMC instead
>> of the normal payload start. One effect of this is that the payload size
>> limit must be reduced by 512 bytes on GXBB.
>>
>> Example of how to use it:
>>   # Create a normal boot image
>>   tools/mkimage -T amlimage -n gxbb -d u-boot-spl.bin bl2.bin
>>
>>   # Create a boot image with a special eMMC header
>>   tools/mkimage -T amlimage -n emmc -d bl2.bin bl2-emmc.bin
>>
>>   # Write normal boot image to sector 1 of eMMC/SD-card
>>   dd if=bl2.bin of=/path/to/dev bs=512 seek=1
>>
>>   # Write eMMC header, 112 bytes, to start of eMMC
>>   dd if=bl2-emmc.bin of=/path/to/dev bs=1 count=112
>>
>> Or with binman using something like:
>>   binman {
>>         multiple-images;
>>
>>         u-boot-gxbb-sd {
>>                 filename = "u-boot-gxbb-sd.bin";
>>                 pad-byte = <0xff>;
>>
>>                 mkimage {
>>                         filename = "bl2.bin";
>>                         args = "-n", "gxbb", "-T", "amlimage";
>>
>>                         u-boot-spl {
>>                         };
>>                 };
>>         };
>>
>>         u-boot-gxbb-emmc {
>>                 filename = "u-boot-gxbb-emmc.bin";
>>                 pad-byte = <0xff>;
>>
>>                 mkimage {
>>                         filename = "bl2-emmc.bin";
>>                         args = "-n", "emmc", "-T", "amlimage";
>>
>>                         blob-ext {
>>                                 filename = "bl2.bin";
>>                         }
>>                 };
>>         };
>>   };
>>
>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>> ---
>>  tools/amlimage-gxbb-relocate.c | 79 ++++++++++++++++++++++++++++++++++
>>  tools/amlimage.c               | 37 ++++++++++++++++
>>  2 files changed, 116 insertions(+)
>>  create mode 100644 tools/amlimage-gxbb-relocate.c
>>
> 
> I sent [1] some years ago and would quite like to enable the odroid-c2
> in my lab. Is that an older version of what you are supporting here?

The amlimage type in this series is only for creating an image format
that the SoCs BootROM (BL1) can understand. This image type will most
likely only be useful together with Ferass El Hafidi's U-Boot SPL work
or for someone wanting to run bare metal code from SRAM on these SoCs.

Vendor bl2.bin blobs is based on TF-A, is already in correct image
format and expect next stage payload to be signed using a Amlogic FIP
format. For this you will still need to use vendor tools or open source
tools like meson-tools, gxlimg or meson64-tools.

The amlogic-boot-fip repo [2] has blobs, vendor tools and Makefiles to
combine the blobs with a U-Boot proper u-boot.bin to create a firmware
image that should boot for a wide range of boards.

[2] https://github.com/LibreELEC/amlogic-boot-fip

> 
> I heard that there are people working on open source tools, but it has
> been a few years and I'd be quite OK to just use vendor tools.

Open-source tools exist to replace the binary-only Amlogic tools:
- https://github.com/afaerber/meson-tools (GXBB, GXL & GXM only)
- https://github.com/repk/gxlimg (GXBB, GXL, GXM & AXG only)
- https://github.com/angerman/meson64-tools (developed for G12B, should work on G12A & SM1)

Would be nice if someone would combine those into a mkimage amlfip type
or similar (a different format than this amlimage format).

> 
> For your docs, could you put them in doc/ instead?

Not fully sure what you want me to put in doc/, please be specific. The
code comments and commit message should already document as much as
possible until there is upstream use of the GXBB eMMC header workaround.

At such time something like following could be documented:

  Write image to SD-card or eMMC module:
    dd if=u-boot-amlogic.bin of=/path/to/dev bs=512 seek=1 conv=fsync,notrunc

  Write the eMMC header to eMMC module:
    dd if=u-boot-gxbb-emmc.bin of=/path/to/dev bs=1 count=112 conv=fsync,notrunc

Until Ferass El Hafidi's U-Boot SPL work has made its way upstream such
commands and information would purely be speculative and will be easier
to document in a future series.

Regards,
Jonas

> 
> [..]
> 
> Regards,
> Simon
> 
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20211124040954.699821-8-sjg@chromium.org/