On 4/25/23 2:31 AM, Neha Malcom Francis wrote:
Hi Simon
On 25/04/23 01:12, Simon Glass wrote:
Hi Neha,
On Fri, 21 Apr 2023 at 06:32, Neha Malcom Francis <n-fran...@ti.com> wrote:
Support added for HS and GP boot binaries for AM64x.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
Note that the bootflow followed by AM64x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis <n-fran...@ti.com>
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 +
arch/arm/dts/k3-am642-r5-evm.dts | 1 +
arch/arm/dts/k3-am64x-binman.dtsi | 569 ++++++++++++++++++++++++++
board/ti/am64x/Kconfig | 2 +
4 files changed, 574 insertions(+)
create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi
Reviewed-by: Simon Glass <s...@chromium.org>
I notice that some of the entries are optional. Do you actual make use
of this (i.e. that when they are missing binman removes the entries)?
So right now the build generates binaries for all three types: HS-FS, HS-SE and
GP devices. It's not necessary for the user to provide component binaries for
all three of them, say they only have GP SYSFW binaries available with them.
Would this ever need to happen? We provide all three firmware types for all our
SoCs out in public[0], why would anyone only have one type of firmware
available?
Andrew
[0]
https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-sysfw?h=ti-linux-firmware
So that was the reasoning behind putting those binaries as optional, we should
not have a failed build in those cases. However binaries like DM and
board-config binaries that are common between all three needs to be there so
it's not optional.
Regards,
Simon
