Hi Jonas, Thanks for your review!
On Thu, Dec 11, 2025 at 3:27 PM Jonas Karlman <[email protected]> wrote: > > Hi Alexey, > > On 12/10/2025 9:10 PM, Alexey Charkov wrote: > > Load images unconditionally to a known-safe location (which is > > CONFIG_SYS_LOAD_ADDR) to be later relocated to its desired load address. > > > > Some storage devices may be unable to directly load each of the images > > listed in a FIT to their desired load addresses, as is the case with > > e.g. booting from UFS storage on Rockchip RK3576, where part of the > > ATF should end up in SRAM but the UFS controller cannot directly write > > there. > > > > Furthermore, the code down the line does a memmove or image decompression > > from the original src_ptr, anyway, so there shouldn't be any performance > > implications from this change. > > If I am not mistaken the memmove will try to move the src_ptr into > load_addr and as long as they are same this is a no-op, so I am > expecting this will have performance implications. If there is no difference in alignment between src_ptr vs. load_addr and no image overhead, the memmove down the line should indeed return early. You're right that there are after all cases where this change will affect performance. > I suggest we instead try to configure the rk3576 firewall to allow the > UFS controller to access SRAM (SYSMEM) similar to how this is allowed on > e.g. rk3588. Please see U-Boot rk3576.c and rk3588.c, and also TF-A > plat/rockchip/rk3576/drivers/secure/firewall.c. Won't this introduce some sort of a security hole? I have to admit I don't know how the "trusted" part of "trusted firmware" is enforced, but I have a suspicion that there is a security reason why this particular segment gets written to a more locked-down SRAM rather than system RAM before TF-A code takes over the management of the firewall. Would be great to know otherwise, because this sounds like a much cleaner (=fewer code changes) solution than the alternatives. Any advice from the list would be appreciated! > For other Rockchip SoCs we have also used non-DMA mode or a bounce > buffer to work around similar issue in the drivers. I'll look into a potential non-DMA mode in the driver for use in SPL, thanks for the pointer! > On a final note I would not fully trust the SYS_LOAD_ADDR addr on > Rockchip platform, to my knowledge this is not really used for anything > and because of this have not fully been considered when other static > load addresses have been picked, so this could introduce some unintended > overlaps. That should be relatively easy to fix with a quick Kconfig change, but I agree it might lead to an unknown number of regressions on platforms that didn't use SYS_LOAD_ADDR before. Good point, thank you. Best regards, Alexey
