[PATCH v5 14/15] arm: sc5xx: Add fdt_addr_r, kernel_addr_r, and ramdisk_addr_r
Simon Glass
sjg at chromium.org
Fri May 1 00:16:36 CEST 2026
Hi Caleb,
On Thu, 30 Apr 2026 at 13:29, Caleb Ethridge <jcethrid at gmail.com> wrote:
>
> Hi Simon,
>
>
> > The other 32-bit boards in this patch leave ~16
> > MiB. Is that intentional?
>
> No, this looks to be a typo in the ramdisk_addr_r, all of the boards
> allocate the same space for the kernel image in the load. This will be fixed
> in the next revision.
>
> > How about picking a distinct value now so
> > the future booti patch doesn't have to touch every board file again?
>
> I'm not sure I follow your meaning here? Ultimately when booting a user would
> choose to either use the fitImage with bootm or the booti approach with
> everything loaded individually, and there is the potential that once booti
> support is added we will deprecate and completely replace the bootm commands with booti
> versions.
>
> Also, currently when we build the fitImage, we place the ramdisk and kernel
> offset in the fitImage so that when loaded to CONFIG_SYS_LOAD_ADDR, they would appear
> at the addresses from the environment for the ramdisk and kernel. So if you were to
> load the fdt, kernel and ramdisk to these addresses, then create a fitImage with our
> build system with those same images and load it at CONFIG_SYS_LOAD_ADDR, nothing in the
> RAM would change.
>
> Does this make sense? It would not ultimately matter if you loaded the fitImage or the
> pieces individually, as they would be loaded to the same locations in memory.
Ah yes that makes sense, thanks.
Regards,
Simon
More information about the U-Boot
mailing list