Okay yeah there were some incorrect branch statements due to which the bootstrap wasn't getting trapped infinitely at the start of the code, things work flawlessly now!
Yeah, as you suggested, I tried looking at what's exactly going on under the hood, and here's what I observed:The entries in the respective tables have been verified, and they are stored appropriately along with the descriptor flags.
The exception is raised when the branch to `kernel_main()` happens, specifically in the prologue of the function. There is a store instruction, which raises the exception, and as you rightly stated, an EL1H SYNC exception. Here are the details for that:I found some forum discussions online which claimed that this happens because the data cache isn't invalidated after enabling MMU, hence I attempted to do that as well:but, in vain...
The fact that the branch and link instruction to `kernel_main` succeeds, afaik, means that there are no translation faults(?), so I'm not quite sure what's going on here...
Thanks!
Yeah, as you suggested, I tried looking at what's exactly going on under the hood, and here's what I observed:
Code:
PGD Address -> 0x204000PUD Address -> 0x205000PMD Address -> 0x206000, 0x207000, 0x208000, 0x209000, 0x20a000 (5 tables)The exception is raised when the branch to `kernel_main()` happens, specifically in the prologue of the function. There is a store instruction, which raises the exception, and as you rightly stated, an EL1H SYNC exception. Here are the details for that:
Code:
stp x29, x30, [sp, #-32]!sp -> 0x400000x29 -> 0x80090x30 -> 0x800d0ESR_EL1 -> 0x2000000 (which decodes to unknown exception class, 32-bit mode)Code:
dc ivac, xzrdsb ishisbThe fact that the branch and link instruction to `kernel_main` succeeds, afaik, means that there are no translation faults(?), so I'm not quite sure what's going on here...
Thanks!
Statistics: Posted by kvp_933 — Fri Jun 21, 2024 4:54 am