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

On 05/01/2025 11:24, Ferass El Hafidi wrote:
> Hi Jonas and Simon,
> 
> On Sat Jan 4, 2025 at 10:23 PM UTC, Jonas Karlman wrote:
>> Hi Simon,
>>
>> On 2025-01-04 20:31, Simon Glass wrote:
>>> Hi Jonas,
>>>
>>> On Sat, 4 Jan 2025 at 10:59, Jonas Karlman <[email protected]> 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 <[email protected]>
>>>> ---
>>>>   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.
> 
> I'm happy to announce that U-Boot SPL can now boot on gxbb and gxl SoCs,
> and I'll be sending some patches to upstream that work later on.

\o/

> 
>>
>> 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)
> 
> gxlimg now also supports G12A/G12B, but it does not support GXBB at the
> time of writing.

Exact :-)

GXBB is radically different, it was heavily based on the TF-A FIP architecture,
then Amlogic switched to custom headers for GXL and followings.

I would instead support a full SPL boot with associated tooling in U-Boot
source an leave the legacy FIP stuff where it should be, out of tree.

Each board has basically a custom BL2 provided by Amlogic, with sometimes
some custom tools, so supporting this in U-Boot would be an endless pain.

Neil

> 
>>
>> 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.
> 
> Yes, my tree has documentation on how to make use of images generated by
> amlimage.  I believe such documentation should be documented when there
> actually is U-Boot SPL support as well.
> 
> Best regards.
> 
>>
>> Regards,
>> Jonas
>>
>>>
>>> [..]
>>>
>>> Regards,
>>> Simon
>>>
>>> [1] https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/