imx8mm memory env in U-Boot

[Tim Harvey]

On Thu, Aug 26, 2021 at 12:41 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Aug 26, 2021 at 09:39:20AM -0700, Tim Harvey wrote:
>
> > Greetings,
> >
> > I'm trying to understand what the best memory usage is in U-Boot for
> > IMX8M boards for generic distro configs such as: loadaddr,
> > kernel_addr_r, fdt_addr_r, ramdisk_addr, scriptaddr.
> >
> > My understanding is that the following is a good rule of thumb:
> > loadaddr = DDR start + 32MB (as FIT images may load kernel at DDR
> > start; but this only allows for a 32MB kernel)
> > kernel_addr_r = $loadaddr
> > fdt_addr_r = $kernel_addr_r + 128MB (allows you up to 128MB for your
> > kernel; handy if you want a kernel with internal ramdisk)
> > ramdisk_addr = fdt_addr_r + 512KB (512KB should be plenty for a dt)
> > scriptaddr = $loadaddr
>

Hi Tom,

Thanks for the reply.

> Missing from the list here is bootm_size, so that we make sure
> everything that does need relocation is relocated within a specific size
> range.

I still don't quite understand bootm_size, you say it sets the limit
to where things are relocated to. Shouldn't this just be the size of
dram then? A few IMX8MM boards set this but most do not.

> Where much of this comes from is (or should be) the huge comment
> in ti_armv7_common.h that's based off of the Linux kernel arm "booting"
> document (now converted to rST):
> /*
>  * We setup defaults based on constraints from the Linux kernel, which should
>  * also be safe elsewhere.  We have the default load at 32MB into DDR (for
>  * the kernel), FDT above 128MB (the maximum location for the end of the
>  * kernel), and the ramdisk 512KB above that (allowing for hopefully never
>  * seen large trees).  We say all of this must be within the first 256MB
>  * as that will normally be within the kernel lowmem and thus visible via
>  * bootm_size and we only run on platforms with 256MB or more of memory.
>  *
>  * As a temporary storage for DTBO blobs (which should be applied into DTB
>  * blob), we use the location 15.5 MB above the ramdisk. If someone wants to
>  * use ramdisk bigger than 15.5 MB, then DTBO can be loaded and applied to DTB
>  * blob before loading the ramdisk, as DTBO location is only used as a temporary
>  * storage, and can be re-used after 'fdt apply' command is done.
>  */

Right, that's where I got my recommendations and I don't understand
the reasoning behind the default loadaddr be 32MB into DDR.

>
> At this point, re-reading and referencing both:
> https://www.kernel.org/doc/Documentation/arm64/booting.rst
> https://www.kernel.org/doc/Documentation/arm/Booting
> would be good, and note that there's not currently a similar document
> for RISC-V, they often follow the same guidelines.  And I know you're
> talking about imx8 specifically right now but due to the copy/paste
> nature of these kinds of values, I like to err on the side of maximal
> safety.  Which means that we should bump the DTB size to 2MB, per arm64.

ok, good to know 2MB should be allotted for dtb.

>
> It also doesn't cover kernel_comp_addr_r / kernel_comp_size for
> automatic decompression of Image files, but should.
>

interesting... I didn't even realize booti supported compressed images!

I see now commit 414c34ed55: ("image: Add compressed Image parsing
support in booti."). I'm not clear why the uncompressed kernel needs
to be moved to kernel_addr_r after decompression... why can't it
simply be decompressed directly to kernel_addr_r?

I would think kernel_comp_size would typically be set to filesize as
currently that is set by tftp as well as fs load commands.

> Note that I believe (but would have to think on and re-read a bunch of
> stuff to be sure), it's not that saying the kernel address is at 32MB
> from the start of memory limits us to 32MB, but that it makes life
> easier all around.
>
> > Looking at the various imx8mm boards upstream they are kind of all
> > over the place but do follow some patterns likely due to some of us
> > just going with what prior boards used.
> >
> > While I'm at it I've encountered a couple other questions:
> > - why on IMX8MM is CONFIG_LOADADDR is 0x40480000 when DDR starts at
> > 0x40000000. Why the 4608KB offset?

any idea why IMX8MM boards are using DDR+4608KB for loadaddr vs just
DDR? I am hoping some of the IMX8MM board maintainers I've cc'd here
can answer that.

> > - what is CONFIG_SYS_INIT_RAM_SIZE? Most boards are setting this to
> > 2MB but a couple (cl-iot-gate/phycore) set it to 512KB
>
> I feel like it's pretty likely CONFIG_SYS_INIT_RAM_SIZE has been
> copy-pasted around as part of setting CONFIG_SYS_INIT_SP_OFFSET which is
> unused.  A lot of unused (outside of m68k / PowerPC generally) options
> in that area.
>
> > - what are people using for the load address for the kernel within FIT
> > images? I expect start of DDR is appropriate (0x40000000) however for
> > whatever reason I've been using 0x40200000. This plays into the env as
> > you can't overlap where you loaded the FIT image with where you told
> > the FIT image to relocate the kernel to.
>
> Getting some documentation under doc/ about both the environment
> variables and optimal FIT layout would be good.  Since we're talking
> about arm64 here (but this is true for RISC-V too, same header).
> Reading over booti_setup(), the entry point we set is (so long as 2MB
> aligned) where we relocate to.  So the 0x40200000 would be base + 2MB,
> and there were points in history on arm64 where it had to be at that
> offset, I believe.

I did verify that using 0x40000000 for loadaddr in a FIT image booted
a modern kernel just fine so yes I guess the reasoning must have been
historical.

Best regards,

Tim