[PATCH v5 7/7] doc: Add a warning about using RELOC_ADDR_TOP

[Ilias Apalodimas]

On Sun, 7 Jun 2026 at 21:20, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On 2026-06-04T07:37:05, Ilias Apalodimas <ilias.apalodimas at linaro.org> wrote:
> > doc: Add a warning about using RELOC_ADDR_TOP
> >
> > Since devices that can't DMA above 4GiB will misbehave with this option
> > enabled add a warning on the documentation.
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> >
> > doc/develop/memory.rst | 6 ++++++
> >  1 file changed, 6 insertions(+)
>
> Reviewed-by: Simon Glass <sjg at chromium.org>
>
> nits/suggestions below
>
> > diff --git a/doc/develop/memory.rst b/doc/develop/memory.rst
> > @@ -110,6 +110,12 @@ U-Boot Proper Flow
> >
> >        This follows the same as in SPL flow. In board_init_f(), a part of memory
> >        is reserved at the end of RAM (see reserve_* functions in init_sequence_f)
> > +   #. Relocation address
> > +      By default U-Boot will try to relocate below the 4GiB boundary. If
> > +      RELOC_ADDR_TOP is enabled U-Boot will look into the dram bank config of
> > +      gd->dram[] and try to relocate to the highest available bank. Use this
> > +      with caution as devices that can only DMA below 4GiB will misbehave
> > +      since their buffers may be allocated above the 32-bit boundary.
>
> Can you check the rendering here? It seems that the title will run on
> to the text?
>
> Also text only covers the default and RELOC_ADDR_TOP, but does not
> mention that boards can still override via board_get_usable_ram_top().
> Worth a sentence, since that is the other half of the new behaviour
> from patch 5.

Sure I'll update it on v6

Thanks
/Ilias
>
> Regards,
> Simon