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 <jo...@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 <jo...@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.
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.
>
> 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.
>
> 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/20211124040954.699821-8-...@chromium.org/
