On 31/08/2023 05:37, Simon Glass wrote:
Hi Ferass,
On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi
<vitali64pmem...@protonmail.com> wrote:
Hi Simon,
So I wonder how best to move this forward so that we can build things
using binman and everything works?
It's still not ready yet, but I'm working on porting U-Boot SPL to some
Amlogic SoCs [1]. I'm currently working on Amlogic S905 boards, but
eventually I'll work on Amlogic S905X devices too. And speaking of
signing, Jonas Karlman wrote amlimage, and integrated it into mkimage,
and I applied his patch to my tree. There's a few things to be aware of
about Amlogic signing and binaries in general, however.
amlimage was intended for use with U-Boot SPL, which obviously has
no support for Amlogic's FIP format and as such amlimage will only do as
little as possible to get the bootROM to load U-Boot SPL. Most of the
packaging format is handled by BL2. The fact that the signing process is
completly different across SoC generations makes it difficult to
implement them all into one single tool (and by which I mean all of it,
not just signing BL2 for the bootROM to run it, that's mostly the same
across SoCs). amlimage has been confirmed to work on GXBB (ODROID-C2 and
the KII Pro set-top box), GXL (librecomputer lepotato), and SM1 (ODROID-C4).
My U-Boot SPL port is still rather incomplete. As of today, it still
can't boot anything from any storage device. The goal eventually is to
be able to load upstream TF-A BL31 and U-Boot+linux.
While Amlogic distributes proprietary BL31 binaries upstream Trusted
Firmware-A has a port for some Amlogic SoCs [2], but as far as I know
SM1 (which is the SoC generation your ODROID-C4 is using) is still
unsupported. GXBB, GXL, AXG, and G12A are all supported however, but the
overall port still lacks some features the proprietary implementation
has.
As for the SCP firmware (aka. BL30) I'm not aware of any
reverse-engineering efforts for that.
Thanks for your efforts on this. I look forward to seeing where it ends up.
Honestly, in my opinion, including proprietary and poorly-written
Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea.
With Binman, we don't really include them in U-Boot; we allow them to
be fetched easily so that a complete build can be produced.
I don't like it either, but for users it is better than doing the
build manually.
I'll rather spend time and effort to have a fully-upstream TF-A boot chain
for Amlogic SoC (when possible) that maintaining support for bulky closed-source
x86-64 binary only tools. The tools aren't even officially distributed.
Neil
[1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl
[2]:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic
Cheers.
Regards,
Simon
