Devicetrees with dart-disp0 will have it disabled to avoid breaking
scanout off the boot framebuffer when booting via m1n1 version which
does not lock dart-disp0.
Signed-off-by: Janne Grunau <j@jannau.net>
DCP and disp0 need their bootloader iommu mappings maintained until
an OS driver can take over. DCP's mappings have to be kept
indefinitively since it's unknown if or how it can be restarted.
Bindings based on
https://lore.kernel.org/asahi/20220923123557.866972-1-thierry.reding@gmail.com
Signed-off-by: Janne Grunau <j@jannau.net>
This prevents older systems from resetting dart-disp0 on init when they
encounter device trees with DCP/disp nodes.
Signed-off-by: Janne Grunau <j@jannau.net>
0 is a valid and used device virtual address. Daart functions returning
device address can not use 0 to indicate errors.
Signed-off-by: Janne Grunau <j@jannau.net>
It seems unclean startup sometimes takes longer. On top of that, if we
don't do a clean shutdown in the error path, the next startup will
continue failing (we know hard-disable triggers races and crashes the
ASC).
Signed-off-by: Hector Martin <marcan@marcan.st>
"simple-bus" restricts the node names to predefined list. "soc" looks
like the most appropiate name considering the dies are M1 Max SoCs.
Signed-off-by: Janne Grunau <j@jannau.net>
This is for things that xnu hard-codes. This first one for AGX is
required to make coprocessor TLB coherency work properly...
Signed-off-by: Asahi Lina <lina@asahilina.net>
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>
This is usually a race that happens when the Python side has just
removed a hook, but there was already a CPU core faulting on an access.
Signed-off-by: Asahi Lina <lina@asahilina.net>
This should fix the issue where console writes from another CPU in the
middle of events/etc corrupt data
Signed-off-by: Hector Martin <marcan@marcan.st>
Some of these errors are apparently sticky / write-1-to-clear, and if we
don't do this, then the SError behaves as level-triggered and just continues
to fire.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Seems -v stopped being filtered (or never was?). Explicitly check boot
policy, so we don't depend on boot-args filtering directly (which can
change). -v still makes things verbose unconditionally, but the proxy
backdoor now requires that plus full SIP disable (sip0=127).
Signed-off-by: Hector Martin <marcan@marcan.st>
These are from a public Apple source that shall remain unidentified
(because it's utterly silly that they keep trying to hide these).
Signed-off-by: Hector Martin <marcan@marcan.st>
Unlike the MAC addresses Bluetooth addresses have to be stored
in little-endian byte order (see devicetree/bindings/net/bluetooth.txt)
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Depending on the chip stepping (stored in the OTP) either the blob for
beamforming or the normal calibration blob has to be used.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Writing to the IPI register causes a trap, which sets the event...
causing every CPU to go into a tight loop of traps contended on the BHL.
We don't need to clear IPIs in WFE mode, so don't do that.
Signed-off-by: Hector Martin <marcan@marcan.st>
This stops DCP from killing our modeset if the connection cycles.
Also force a (potential) configure cycle if the display is external;
this makes sure updated stage2s will have a chance at fixing issues of
old stage1s. Modesetting is fast when it's the same mode as before.
Signed-off-by: Hector Martin <marcan@marcan.st>
Get rid of asc_cpu_stop() which was never a thing. The CPU start bit
should always be off in the steady state, it is only used momentarily to
start the CPU.
Signed-off-by: Hector Martin <marcan@marcan.st>
Commit 9c795fbdbf introduced the pair of
WFE and SEV for spinlock, but it caused delays of tens of seconds. A
possible explanation for the delay is lack of data synchronization
barrier between the store instruction and SEV instruction.
Arm Architecture Reference Manual for A-profile architecture (issue H.a)
says:
> Arm recommends that software includes a Data Synchronization Barrier
> (DSB) instruction before any SEV instruction. The DSB instruction
> ensures that no instructions, including any SEV instructions, that
> appear in program order after the DSB instruction, can execute until
> the DSB instruction has completed.
However, inserting a DSB instruction still didn't resolve the delay.
The exclusive load is an alternative to the SEV instruction. The manual
says:
> ...However, in Armv8, when the global monitor for a PE changes from
> Exclusive Access state to Open Access state, an event is generated.
> This is equivalent to issuing an SEVL instruction on the PE for which
> the monitor state has changed. It removes the need for spinlock code
> to include an SEV instruction after clearing a spinlock.
As an additional benefit, the exclusive load is local to the PE and
eliminates spurious events for other PEs.
Trusted Firmware-A v2.6 also employs the same algorithm.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
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>
DART nodes for dcp and disp0 have pre-allocated L1 and L2 tables which
are annotated in the ADT. The pre-allocated memory is specified in
"pt-region-${DEVICE}". The first page is used as L1 table and the
following pages are used as L2 tables. The number of valid L2 tables is
specified in "l2-tt-${DEVICE}". The first entry identifies the region
and the second entry is the number of valid L2 tables.
iboot (macOS 12.3) inits just 2 L2 tables. Larger framebuffers require
more. By using the pre-allocated page tables we do not have worry about
keeping the memory mapped after m1n1 executes the next target.
Signed-off-by: Janne Grunau <j@jannau.net>
The reserved framebuffer on the Mac Studio is 0x854000 bytes. This is
too small for 1920x1200 with 4 byte per pixel. Setting 1920x1200 as
mode crashes dcp but not the actual display controller. The display
remains working and even comes back after display hotplug/power cycle.
Signed-off-by: Janne Grunau <j@jannau.net>
The device tree for multi die SoCs as the M1 Ultra has its devices
under "/soc/dieX" instead of directly under "/soc".
Signed-off-by: Janne Grunau <j@jannau.net>
Get rid of the hv_rearm() thing (which was always a bit dodgy) and
instead properly make sure that all CPUs rendezvous when needed and
switch the active proxy thread without ever exiting exception context.
The Python side can now switch proxy context (by waiting directly for
a proxy boot) without having to exit out of the hypervisor callback,
so cpu() now works as a normal Python method.
Add a cpus() iterator so you can do things like:
>>> for i in cpus(): bt()
Signed-off-by: Hector Martin <marcan@marcan.st>
This should reduce memory traffic spam and power usage from lock
contention when threads are blocked on a spinlock.
Signed-off-by: Hector Martin <marcan@marcan.st>
Previously RAM was mapped ad-hoc, but this can end up interacting
poorly with the tracer infrastructure which we are now using for RAM
too. Move to mapping guest RAM via the tracer infra, and also unmap the
TZ carveouts in the Python side so it knows about them.
This is a HV ABI break.
Signed-off-by: Asahi Lina <lina@asahilina.net>
The HV tick polling now only runs on CPU#0. All CPUs have the 1000Hz
HV tick, but secondaries only use it to poll the FIQ state and that path
does not take the BHL if no other FIQ was pending.
Signed-off-by: Hector Martin <marcan@marcan.st>
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>
