Turns out CTRR does not like working with huge pages, and just throws up
its hands in the air with an L2 address size fault if a huge page
overlaps the CTRR region.
Signed-off-by: Asahi Lina <lina@asahilina.net>
If an explicitly specified display mode exceeds the allocated
framebuffer allocate a new one from the top of RAM.
Note: macOS panics immediately with a realloced framebuffer.
Signed-off-by: Janne Grunau <j@jannau.net>
This fixes display DART real-time cache hits causing AMCC exceptions.
The relevant carve-outs have flags 0x60004016; 0x60004002 is used for
DCP which is non-realtime, so I'm guessing the '16' means we should map
it uncached.
Signed-off-by: Hector Martin <marcan@marcan.st>
This turns on the system level cache. The carveout unmapping also moves
here, and now it handles T8103/T6000 properly.
Signed-off-by: Hector Martin <marcan@marcan.st>
Turns out AMCC on t600x throws errors when DISP0 real-time memory
requests hit the CPU cache, and then macOS panics.
Signed-off-by: Hector Martin <marcan@marcan.st>
For now we compute this as phys_base aligned down to a 4GiB boundary.
Hopefully that works for future SoCs too.
Signed-off-by: Hector Martin <marcan@marcan.st>
This unbreaks dcp.py and other things that need to access reserved
regions. This way we don't have to start doing manual MMU maps, but
we're still safe from SErrors caused by hitting TZ carveouts.
Signed-off-by: Hector Martin <marcan@marcan.st>
We saw some crazy speculation running in the HV breaking things by
reading from invalid RAM, so let's actually map only what's available.
For now we do map all lowmem as we haven't seen SErrors there yet, but
we stop at the high boundary.
Fixes: #97
Signed-off-by: Hector Martin <marcan@marcan.st>
This replaces the old pagetable code with an adapted version of what
hv_vm.c does, which can handle block and page mappings more
intelligently.
Then, map the m1n1 code section as RX. This allows us to work in modes
where W^X is enforced.
Signed-off-by: Hector Martin <marcan@marcan.st>
This is like fb_console_scroll(), but only scrolls if necessary to
ensure that enough free space is available at the end of the console.
This avoids spuriously scrolling during shutdown if we still have space.
Signed-off-by: Hector Martin <marcan@marcan.st>
Since we're in VHE mode, we can pretend to be in EL1 - but this will
allow us to really run in EL1 if we want to in the future.
Signed-off-by: Hector Martin <marcan@marcan.st>
Enable EL0 access to MMIO/etc, but not main RAM, because AArch64
architecturally enforces EL0w ^ EL2x.
Instead, create an alias of main RAM to grant EL0 full permissions,
at 0x80_0000_0000.
Grant EL0 full access to MMIO stuff, since EL2 will never execute
from there.
Signed-off-by: Hector Martin <marcan@marcan.st>
Previously all MMIO was mapped twice with different attributes
which may or may not lead to strange behaviour when the same
physical range is accessed from both mappings.
We now have a better idea which ranges require nGnRE and nGnRnE
and can just do it correctly instead.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
I can't remember why I used vmalls12e1is but this leads to
the following bug:
1. Load m1n1 with normal MMU setup
2. Disable all mappings, recompile and chainload to that m1n1
3. Everything will work fine for a while even though it should explode
when enabling the MMU.
This happens becuse there are still stale TLB entries in some cache.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
This fixes the random SErrors after returning from a page fault. Turns
out the M1 was randomly deciding to speculate an instruction fetch from
address 0, triggering a fabric error.
Quoting the ARM ARM:
"Hardware does not prevent speculative instruction fetches from a memory
location with any of the Device memory attributes unless the memory
location is also marked as Execute-never for all Exception levels.
This means that to prevent speculative instruction fetches from memory
locations with Device memory attributes, any location that is assigned
any Device memory type must also be marked as execute-never for all
Exception levels. Failure to mark a memory location with any Device
memory attribute as execute-never for all Exception levels is a
programming error."
Signed-off-by: Hector Martin <marcan@marcan.st>
