We use mmu_ranges to track the list of memory ranges and their types for
MMU initialization. We also keep track of used memory ranges in
usedmem_ranges, to avoid them from being re-allocated in
mmu_alloc_range().
The problem is, the CBMEM range (CB_MEM_TABLE) is added to mmu_ranges,
but is never marked as "used" in usedmem_ranges. This potentially causes
any allocation (for example the framebuffer) to overlap with CBMEM. This
issue is observed when DMA_DEFAULT_SIZE is reduced from 32MB to 1MB [1].
Prior to that change, because there isn't enough space above the
coreboot table (with the 4GB upper limit) to fit the 32MB requested
region, the DMA heap is always allocated *below* the coreboot table. And
because the coreboot table is usually the lowest within CBMEM, the DMA
heap region is allocated *below* the whole CBMEM, which happens the
avoid the issue.
Fix the bug by adding CB_MEM_TABLE ranges to usedmem_ranges. The ranges
in usedmem_ranges don't need to be combined because they are not for MMU
initialization (and there's only one CB_MEM_TABLE range).
[1] commit aedc177f00 ("libpayload: arm64: Reduce DMA allocator space to 1MB")
BUG=b:424107889
TEST=emerge-skywalker libpayload
BRANCH=none
Change-Id: Ie9ecafc17546e524253c60ab684ec10ff3495998
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
b4f2a51533