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