+andestech.com On 07. 09. 20 3:43, Simon Glass wrote: > Hi Michal, > > On Thu, 3 Sep 2020 at 05:03, Michal Simek <michal.si...@xilinx.com> wrote: >> >> The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which >> introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe. >> Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a >> problem to record these addresses in 64bit format. >> The patch adds support for systems which need to load images above 4GB. > > But what about 32-bit systems who read this as a 32-bit number? > Perhaps we should write 32-bit if !CONFIG_PHYS_64BIT? > >> >> Signed-off-by: Michal Simek <michal.si...@xilinx.com> >> --- >> >> common/fdt_support.c | 9 ++------- >> 1 file changed, 2 insertions(+), 7 deletions(-) >> >> diff --git a/common/fdt_support.c b/common/fdt_support.c >> index b8a8768a2147..5ae75df3c658 100644 >> --- a/common/fdt_support.c >> +++ b/common/fdt_support.c >> @@ -611,14 +611,9 @@ int fdt_record_loadable(void *blob, u32 index, const >> char *name, >> if (node < 0) >> return node; >> >> - /* >> - * We record these as 32bit entities, possibly truncating addresses. >> - * However, spl_fit.c is not 64bit safe either: i.e. we should not >> - * have an issue here. >> - */ >> - fdt_setprop_u32(blob, node, "load", load_addr); >> + fdt_setprop_u64(blob, node, "load", load_addr); >> if (entry_point != -1) >> - fdt_setprop_u32(blob, node, "entry", entry_point); >> + fdt_setprop_u64(blob, node, "entry", entry_point); >> fdt_setprop_u32(blob, node, "size", size); >> if (type) >> fdt_setprop_string(blob, node, "type", type); >> -- >> 2.28.0 >>
riscv: Your code is also using entry-point/load-addr and should be also fixed based on this series. Can you please take a look at this series? I am interested how riscv users are keeping in sync SPL and full U-Boot. Thanks, Michal