qemu-arm: hang during MMU initialization

[Ard Biesheuvel]

On Fri, 5 Feb 2021 at 18:38, Igor Opaniuk <igor.opaniuk at foundries.io> wrote:
>
> Hi,
>
> With this commit 3fa914af82("arm: qemu: implement enable_caches()") introduced,
> which enables instruction/data caches for qemu-arm target,
> U-Boot sometimes hangs during MMU init procedure :
>
> DRAM:  1 GiB
> initcall: 60011df8
> initcall: 60011904
> New Stack Pointer is: 80fffe90
> initcall: 60011a20
> initcall: 60011bcc
> initcall: 60011bd4
> initcall: 600119b4
> Relocation Offset is: 22042000
> Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
> initcall: 60011b8c
> initcall: 82053ea0
> initcall: 82053ea8
> initcall: 60012040 (relocated to 82054040)
> dram_bank_mmu_setup: bank: 0
>
> This issue reproduces every time when the amount of memory provided to QEMU
> is not 2MB granular. Looks like it might be some unexpected alignment issue.
>
> Test results (QEMU v5.2.0 release):
> qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots OK
> qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
> qemu-system-arm -machine virt -m 1056 -nographic -bios u-boot.bin - boots OK
> qemu-system-arm -machine virt -m 1055 -nographic -bios u-boot.bin - hangs
>
> Unfortunately I didn't have a chance to investigate this further, so
> just sharing my current observations. Thanks for any input.
>

Hello Igor,

enable_caches() results in a 1:1 mapping to be created, and since LPAE
has been enabled as well, the 1:1 mapping is created using 2 MB
blocks. So I am not surprised that using a value that is not a
multiple of 2 MB causes problems.

I'd suggest implementing a simple fix, e.g., just round down the
amount of available memory, as this is not something that is likely to
ever be a problem on real systems.

-- 
Ard.