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>
These functions all perform a store direcly followed by a load.
This is useful to e.g. useful to find busy bits which might
already be cleared a few cycles after a write.
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 can be used when the input file size is unknown: the decompression
functions will keep track of it and return it to the caller instead.
Signed-off-by: Hector Martin <marcan@marcan.st>
3 second faster load and uncompress time for small kernel
(5.6M uncompressed, 2.1M gz and 1.6M xz). Compression method is
autodetect by the filename suffix or can be set by the '--compression'
command line option.
Also supports uncompressed payloads (no auto detection).
Signed-off-by: Janne Grunau <j@jannau.net>
Seems one of the registers is some kind of system-level CPU spinup flag,
without which the CPU runs but the rest of the system thinks it's still
dead.
Signed-off-by: Hector Martin <marcan@marcan.st>
Proxy.py has a few typos that appear if you try to use debug mode and dump a region of memory. This should fix those.
Signed-off-by: Iris Johnson <iris@modwiz.com>
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>
