ARM64 linux early boot stage hard hang post mmu enable - Check update

Question

I am trying to boot arm64 linux( custom kernel config built from current git master as of 09/23/21 ) on a cortex A53, emulated on a FPGA platform. The available mem I have is 2GB( 0x0 - 0x80000000 ). I used u-boot as the bootloader to pass uImage to a load point( and same entry point): 0x10000000.

Through an external jtag debugger I can see that the execution is in head.S (https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S ) running the function,(__enable_mmu). The moment the TTBR registers are set and the SCTLR register to enable mmu are executed, the system goes into a hard hang. I immediately lose the ability to track the program counter. I am assuming that the mmu got enabled, but I am not sure what went wrong.( no early prints till this point ).

My doubt:

• I see in head.S that linux does the bare minimum in terms of setting up page table entries before enabling mmu. I would assume that it's standard. Is there anything that could go wrong at this step. If the page tables didn't get set up correctly, how do I verify & fix this. I am relatively new to mmu related stuff.

Update:

• After loads of trial&error, disabling dcache somehow made it go past the hard hang. I changed the parameters passed to sctlr( enabled mmu, disabled caching ), the boot proceeded without any issues* . My question is, why did this work. This is definitely indicative of a deeper issue. Does the dcache flush/invalidation not happen properly? Is the timing of cache operations out of sync?

The boot does go and crash down the line during attaching of drivers but that's a different issue.

Any insight would be helpful. Cheers!

Answer 1

Answering my own question to resolve this matter. This is a very specific corner case and it had to do with how the HW was configured for the FPGA platform. The HW design had clock-gating implemented which was messing up the read cycles between cache and memory, leading to the hard hang.