tashaboot: VMSAv8-64 identity map at EL1 and EL2

2026-10-03T22:12:35Z

The bootloader now builds its own stage 1 translation tables instead of only tearing firmware state down. one L0 table, one L1 under it, device nGnRE block for the low 1GB, normal writeback 2MB blocks for RAM. the descriptors, attribute encodings, MAIR and TCR settings come straight from the manual, level 0/1/2 and level 3 formats at D5-2444 and D5-2447, stage 1 attribute fields at D5-2451, MAIR region attributes at D5-2476, the PA size from ID_AA64MMFR0_EL1.PARange per D5-2399. The tables are EL aware, TTBR0/TCR/MAIR at whichever regime the entry left us in, EL2 or EL1, and the self test translates through AT S1E2R or AT S1E1R per the exception level and checks PAR_EL1 for the identity result: mmu: mmio 0x09000000 (uart) ok, pa 9000000 mmu: mmio 0x00000000 ok, pa 0 mmu: ram 0x40200000 (load) ok, pa 40200000 mmu: ram 0x41000000 ok, pa 41000000 mmu: self 0x40080000 ok, pa 40080000 mmu: identity map on The map is torn down again before the payload, the kernel wants the architecture state at entry, not ours. Two bugs the self test caught on the way. T0SZ was 25 for a 39-bit VA, but with the 4KB granule a 39-bit VA starts the walk at level 1, and the L0 indexed structure was misread one level over, every descriptor landed in the wrong slot and all fetches past the first 2MB faulted level 1. T0SZ is 16 now, the walk starts at level 0 and the three level structure matches. The second, the mmio table was orphaned, the l0 entry was written twice and the second write won, so the device block was never reachable and AT on the uart address faulted. the mmio block now lives at l1[0] in the same L1 table as RAM. The stack also moved to its own region above the bss in the linker script. the tables are bss objects, a stack growing down from the bss end shares their address space and a deep call chain writes into the top table. Signed-off-by: Bradley Morgan

tashaboot/arch/arm64/include/asm/mmu.h, branch main

tashaboot: VMSAv8-64 identity map at EL1 and EL2