On 13:20-20210831, Nishanth Menon wrote:
DM binary is expected to be an elf file. The expected address of this elf is in the range of 0xa000_0000 in DDR. In the current configuration, elf file is loaded to the exact same address and we invoke load_elf_image_phdr to decode and memcpy sections of the elf to the same address range, we are eventually going to overwrite sections of the original elf image itself corrupting the DM firmware as a result.
To prevent this, we must load the DM section to an address that does'nt overlap with the actual section address where it will eventually be copied to.
Lets add an offset of 256MB to a lesser used DDR address, yet within the typical 1GB address space.
We may need to consider going for a configuration option if this is turning to be a limitation (boards with lesser DDR space).
Signed-off-by: Nishanth Menon nm@ti.com
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..6469f188e8ff 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 = <0xb0000000>;entry = <0xb0000000>;-- 2.32.0
Sigh.. I see Suman also discovered the exact same error in [1] - I think I prefer Suman's choice of address to mine.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210814064901.3840-1-s-ann...