U-Boot kernel/ramdisk memory allocation

Autonomous Machines Jetson & Embedded Systems Jetson Nano
#1

Hi,

I’m working on a Jetson Nano based system which I was basing on L4T R32.3.1. Some multimedia related bugs were fixed in R32.4.2 and so I was going to use this new version as my base instead, but I am having some trouble with the new kernel/ramdisk/fdt memory allocator in U-Boot.

There are some bugs in arch/arm/mach-tegra/cboot_board.c, specifically in mark_ram_allocated. There is a memmove call which is passing a count for the size argument, which is corrupting the tegra_mem_map structure when it gets hit. I changed that locally to multiply the count by the size of the structure but I still have some other issues with this approach.

I have some local changes to U-Boot to always use a ramdisk as my rootfs. I read the ramdisk from a partition on the SD card/eMMC and leave it in memory where ever it is supposed to go. These changes work on R28.3, R28.3.2 and R32.3.1. With the changes in U-Boot on R32.4.2 to always use dynamic memory locations and sizes, my local changes no longer work. This is fine as I can change my code to use the dynamic locations and sizes, but the allocation code seems to assume that tegra_mem_map will never be resized larger than the number of entries already in it. This array has a zero’d entry at the end for a sentry, and this entry is overwritten by the first call to mark_ram_allocated that causes a new section to be allocated, causing other basic problems since there is no longer a sentry at the end of the array.

I can increase the size of the tegra_mem_map array in arm64-mmu.c to allow for some extra allocations of non contiguous sections, but this seems like a hack and I’m not even sure what other sorts of problems might be present with this dynamic address/sizing code to be honest.

Is it possible to get these things addressed for the R32.4.2 release? I’m happy to provide debug output or whatever else is needed to help get this fixed. I’d like to use this version as a base for my product if possible.

Thanks for taking time to look at this.

Chris Richardson

#3

Chris,

I added the new calculated_env_vars change to T210 U-Boot, expecting it to work the same as it did on TX2 (T186), which was already using it. I’ll take a look at what you found and see if I can repro and get a fix out, but R32.4.2 has already shipped, it’ll have to wait until the next release. Note that you can remove the entire calculated_vars table (18 lines) from tegra210-common.h, and if needed, adjust the ramdisk_addr and fdt_addr_r to not conflict w/your initrd/kernel. I’m using fdt_addr_r=0x83000000 and ramdisk_addr_r=0x83200000 in the upstream (Denx) T210 U-Boot right now, so those addresses should work for now.

Let me know if this works for you.

Tom

#4

Hi Tom,

Thanks a lot for the response and information. I was thinking that since the current R32.4.2 is a developer preview that there might be room for changes between now and the final release. Based on your response, I suppose U-Boot is expected to stay as-is until after the final release?

I forgot to mention it in my post but removing ramdisk_addr_r from the calculated_vars table is the hacked solution I am using for now. I did attempt to fix some things and debug the allocations before I posted, but the kernel was never able to successfully mount my ramdisk rootfs when using the dynamically assigned address. I will take your advice and just use all fixed addresses for now.

If you end up making changes here and want someone to test them please let me know.

Thanks,

Chris

#6