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.