> Date: Sun, 31 Oct 2021 11:43:38 +0100 > From: Michael Walle <mich...@walle.cc> > > Hi, > > I sometimes see a corrupted initrd during kernel boot on my board > (kontron_sl28). Debugging showed that in this case the spin table > for the secondary CPUs overlaps with the lmb initrd allocations > (initrd_high is set). > > I had a look at how the fdt and initrd are relocated (if enabled). In > summary, they use lmb_alloc() which will first add all available memory > and then carve out reserved regions. There are calls for arch > (arch_lmb_reserve()) and board (board_lmb_reserve()) callbacks. The > interesting thing is that, there is also code to carve out any > reserved regions which were added to the fdt earlier > (boot_fdt_add_mem_rsv_regions()). The problem here is, that the DT > fixups, > which might add the reserved regions are called just before jumping to > linux. Thus both the allocation for the fdt (if fdt_high is set) and > the ramdisk (if initrd_high is set) will ignore any reserved memory > regions. > > Unfortunately, I don't see any good way to fix this. You'd need all the > DT fixups before we can initialize the lmb. Also, I don't know if this > will affect any other areas; probably I'm the only one, who reserves an > area which is outside of the u-boot code and data segment. > > A hackish way would be to carve out the spin_table code in > board_lmb_reserve(). But meh..
The spin table is embedded in the u-boot binary itself isn't it? But the memory occupied by the u-boot should already be reserved... Unless CONFIG_EFI_LOADER is defined. Then it relocates the spin table to memory allocated using efi_allocate_pages(). But that function only looks at the EFI memory map to figure out what memory is available. So I suspect that it might hand out the same memory as lmb_alloc(). It all looks a bit broken to me... Does your target end up with CONFIG_EFI_LOADER defined?
