| Message ID | 20210814064901.3840-1-s-anna@ti.com |
|---|---|
| State | Accepted |
| Commit | 7d67334dfe9ce6a9f5ef3e9b95dd87ef482002b0 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | tools: k3_fit_atf: Fix DM binary FIT load addresses | expand |
On 8/14/21 1:49 AM, Suman Anna wrote: > The DM binary runs on the MCU R5F Core0 after R5 SPL on J721E and J7200 > SoCs. The binary is built alongside the TFA, OPTEE and A72 SPL binaries > and included in the tispl.bin FIT image. The R5 SPL loads the DM binary > at 0xA000000 address, based on the value used in the FIT image build I had a typo here and below, missed a zero in the address. It should be 0xA0000000. Let me know if you want me to post a v2 for that. regards Suman > script. The DM binary though is an ELF image and not a regular binary > file, and so is processed further to load the actual program segments > using the U-Boot's standard ELF loader library. > > The DM binary does leverage a certain portion of DDR for its program > segments, and typically reserves 16 MB of DDR at 0xA000000 with the > 1st MB used for IPC between Linux and the remote processor, and > remaining memory for firmware segments. This can cause an incomplete > loading of the program segments if the DM binary is larger than 1 MB, > due to overlap of the initial loaded binary and the actual program > segments. > > Fix this by using the address 0x89000000, which matches the current > "addr_mcur5f0_0load" env variable used by R5 SPL before the DM firmware > inclusion into the tispl.bin. > > Fixes: df5363a67f35 ("tools: k3_fit_atf: add DM binary to the FIT image") > Signed-off-by: Suman Anna <s-anna@ti.com> > --- > Hi Lokesh, > > This issue is found recently when attempting to use an unstripper DM > firmware binary, it was masked with the existing DM binary since it's > size was very small. > > The script can do with some overhaul, as it is not generic and uses > hard-coded addresses. It should be possible to place ATF, OPTEE and > use a complete different memory layout for firmware images. The ATF > address selection is adjusted recently, but the others remain. > > regards > Suman > > tools/k3_fit_atf.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh > index 3a476ced98b1..7bc07ad07468 100755 > --- a/tools/k3_fit_atf.sh > +++ b/tools/k3_fit_atf.sh > @@ -67,8 +67,8 @@ cat << __HEADER_EOF > arch = "arm32"; > compression = "none"; > os = "DM"; > - load = <0xa0000000>; > - entry = <0xa0000000>; > + load = <0x89000000>; > + entry = <0x89000000>; > }; > spl { > description = "SPL (64-bit)"; >
On Sat, Aug 14, 2021 at 01:49:01AM -0500, Suman Anna wrote: > The DM binary runs on the MCU R5F Core0 after R5 SPL on J721E and J7200 > SoCs. The binary is built alongside the TFA, OPTEE and A72 SPL binaries > and included in the tispl.bin FIT image. The R5 SPL loads the DM binary > at 0xA0000000 address, based on the value used in the FIT image build > script. The DM binary though is an ELF image and not a regular binary > file, and so is processed further to load the actual program segments > using the U-Boot's standard ELF loader library. > > The DM binary does leverage a certain portion of DDR for its program > segments, and typically reserves 16 MB of DDR at 0xA0000000 with the > 1st MB used for IPC between Linux and the remote processor, and > remaining memory for firmware segments. This can cause an incomplete > loading of the program segments if the DM binary is larger than 1 MB, > due to overlap of the initial loaded binary and the actual program > segments. > > Fix this by using the address 0x89000000, which matches the current > "addr_mcur5f0_0load" env variable used by R5 SPL before the DM firmware > inclusion into the tispl.bin. > > Fixes: df5363a67f35 ("tools: k3_fit_atf: add DM binary to the FIT image") > Signed-off-by: Suman Anna <s-anna@ti.com> Applied to u-boot/master, thanks!
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh index 3a476ced98b1..7bc07ad07468 100755 --- a/tools/k3_fit_atf.sh +++ b/tools/k3_fit_atf.sh @@ -67,8 +67,8 @@ cat << __HEADER_EOF arch = "arm32"; compression = "none"; os = "DM"; - load = <0xa0000000>; - entry = <0xa0000000>; + load = <0x89000000>; + entry = <0x89000000>; }; spl { description = "SPL (64-bit)";
The DM binary runs on the MCU R5F Core0 after R5 SPL on J721E and J7200 SoCs. The binary is built alongside the TFA, OPTEE and A72 SPL binaries and included in the tispl.bin FIT image. The R5 SPL loads the DM binary at 0xA000000 address, based on the value used in the FIT image build script. The DM binary though is an ELF image and not a regular binary file, and so is processed further to load the actual program segments using the U-Boot's standard ELF loader library. The DM binary does leverage a certain portion of DDR for its program segments, and typically reserves 16 MB of DDR at 0xA000000 with the 1st MB used for IPC between Linux and the remote processor, and remaining memory for firmware segments. This can cause an incomplete loading of the program segments if the DM binary is larger than 1 MB, due to overlap of the initial loaded binary and the actual program segments. Fix this by using the address 0x89000000, which matches the current "addr_mcur5f0_0load" env variable used by R5 SPL before the DM firmware inclusion into the tispl.bin. Fixes: df5363a67f35 ("tools: k3_fit_atf: add DM binary to the FIT image") Signed-off-by: Suman Anna <s-anna@ti.com> --- Hi Lokesh, This issue is found recently when attempting to use an unstripper DM firmware binary, it was masked with the existing DM binary since it's size was very small. The script can do with some overhaul, as it is not generic and uses hard-coded addresses. It should be possible to place ATF, OPTEE and use a complete different memory layout for firmware images. The ATF address selection is adjusted recently, but the others remain. regards Suman tools/k3_fit_atf.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)