tashaboot: VMSAv8-64 identity map at EL1 and EL2

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 <brads@mainlining.org>

0 files changed, 0 insertions, 0 deletions