t8103 and t600x use "asc-dram-mask" in iop-dcp-nub to mask bits out of
DMA addresses. This needs to be used in the firmware mappings
check/remap since the segments have maskable bits sets.
Fixes: 8332e24 ("dcp: Undo carnage from bad stage1 DART code")
Signed-off-by: Janne Grunau <j@jannau.net>
A bug in our DART code was wiping and aliasing page tables. Go through
the segment ranges for DCP and redo any missing mappings. If we redid
any mappings, then PMGR reset DCP so it can recover from having faulted
on the previous boot.
Signed-off-by: Hector Martin <marcan@marcan.st>
We were assuming L2 tables were always allocated consecutively at low
IOVAs. 14.5 broke this, causing all kinds of explosions.
The new code looks for the first unused L2 PT, and also checks whether
the first 2 entries are aliased to latter entries (which is what the old
code caused). If so, it clears them and reallocates them. This doesn't
undo the PT wipe from stage1 though, so downstream code has to redo any
missing mappings...
Signed-off-by: Hector Martin <marcan@marcan.st>
Use a struct instead of global variable to hold the necessary setup
information. This allows executing the setup for both sio instances.
In addition change the status to "okay" so that sio can remain disabled
if the setup fails.
Signed-off-by: Janne Grunau <j@jannau.net>
Not much to see here, most of the juice is over at:
https://github.com/eiln/avd.git
The kernel driver (m1n1.fw.avd) only really pipes the instruction stream
into the respective hardware FIFOs and then hushes the interrupt lines.
Most of the work (bitstream syntax parsing and instruction generation)
is done in the avid repo above.
I'm hoping to keep this userland-kernel separation in the very imminent
actual driver.
experiments/avd.py: Decode on the command line. Read file for usage.
experiments/avd_e.py: Decode via emulated instruction stream.
experiments/avd_f.py: Decode via Cortex-M3 firmware (for debugging).
hv/trace_avd.py: Tracer. Read file for usage.
m1n1/fw/avd/__init__.py: Driver base class (power, tunables, etc).
m1n1/fw/avd/decoder.py: Codec-specific decode logic + mini media player.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
For some reason the ans node for t602x devices has an empty
"clock-gates" property. Use the MMIO address instead to determine on
which die the device is.
Fixes: 34f49a5 ("nvme: assume die 0 if clock-gates not set")
Signed-off-by: Janne Grunau <j@jannau.net>
M3+ have a new USB power controller and it works over SPMI.
However, the USB ports work (at least within m1n1) if we ignore
this and just init the phys directly.
This detects the case where we are not on an I2C based USB machine,
and initializes the phys directly.
Eventually we should support SPMI properly.
Signed-off-By: Daniel Berlin <dberlin@dberlin.org>
On m3, these previouly expected-to-be-constant fields have exciting
non-constant values. This updates adt.py to allow them to be
non-constant. The second field is also really a flags field,
though i could not tell you all the flags involved.
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
The UART base has moved from the M2 chips.
Everest settings introduce some changes to unknown registers
The MCC data has changed as well.
There is a drive-by change where I discovered what some of the unknown
HID18 bits are and documented them.
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Right now, we assume the boot cpu is cpu0. That is not true on m3 max,
where it is CPU 4.
To figure out which CPU is the boot CPU, we check to see which CPU
is running before we start any other CPUs, and record the MPIDR/idx.
Without this patch, four issues happen on m3 max:
1. We try to start the boot CPU again, crashing it
2. We skip the real CPU 0
3. We start m1n1 again on CPU0 when we boot it
4. We enable interrupts on CPU0 because we think it's the primary CPU.
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Only observed with dcp/dptx in linux after initialisation and reset in
m1n1. On the initial startup dcp sends two D576 (hotPlug_notify_gated)
presumendly due to state confusion due to the multiple dptx
connections.
Signed-off-by: Janne Grunau <j@jannau.net>
dcpext0 behaves like dcp on M1* devices and can sleep after display
init. This has the advantage of not breaking macOS when starting with an
initialized display.
dcpext* are according to Apple's tech specs slightly more powerful than
dcp. They are advertised as 6K at 60Hz while dcp seems to be limited to
5K at 60Hz.
Signed-off-by: Janne Grunau <j@jannau.net>
Apperently just informative as display init on M2 Ultra in m1n1 worked
as expected despite passing '0' as die number.
Signed-off-by: Janne Grunau <j@jannau.net>
Required for stage 1 loader to allow chainloaded display/dcp experiments
to start with the state left by iboot.
Signed-off-by: Janne Grunau <j@jannau.net>
Same value as the arm64 kernel build uses.
Avoids following warning:
| src/tinf/tinflate.c: In function ‘tinf_uncompress’:
| src/tinf/tinflate.c:559:5: warning: stack usage is 1712 bytes [-Wstack-usage=]
| 559 | int tinf_uncompress(void *dest, unsigned int *destLen,
Signed-off-by: Janne Grunau <j@jannau.net>
Same functionality as the readline shell, but based on
ipython so that it has nicer help/autocomplete/etc
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
I only can easily find the T6031/T6034/T8122 values.
If there is a T6030, the value is not in the same place I found these.
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
When I tried to use the proxyclient shell, I got:
"Exception parsing /device-tree/arm-io/dart-dcp.dapf-instance-0 value […]"
I laid out the hex dump in a text editor, and added line breaks every
56 bytes (the former size of DAPFT8110B):
0000703b020000000080713b0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000
40723b020000000080723b020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000
003b020000007f73073b02000000200000000000000000000000000000000000000000000000000000000000000000030100000000000028
3d020000000040283d020000002000000000000000000000000000000000000000000000000000000000000000000301000000000080003d
020000000380003d020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000e03f02
000000ffffef3f0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000c0403e0200
0000ffff403e020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000433e020000
00ff3f433e020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000783d02000000
03417a3d0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000003c3b0200000000
003e3b020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000403c02000000ffff
473c020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000103c020000004f0c10
3c020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000703d020000000341723d
02000000200000000000000000000000000000000000000000000000000000000000000000030100000000
Looking at the patterns shared by all struct instances
(r0h = 3, r0l = 1, for example), each row appeared to be shifted one
byte to the left compared to its predecessor. This suggests that
DAPFT8110B has only three extra bytes of padding compared to
DAPFT8110.
So, here I introduce DAPFT8110C, a new variant, one byte shorter than
DAPFT8110B. Unlike DAPFT8110, there's no flag to differentiate
between these two variants, so we just have to guess based on what
divisor makes whole structs.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
If DEBUG is not defined, the compiler doesn't look at the arguments to
dprintf(). This has led to dprintf() bitrotting over time, referring
to variables that no longer exist, or by the wrong type, etc.
Here, I've tried to fix all the dprintf() calls to the best of my
ability, by comparing them to nearby calls that do compile, and
looking through the git history to understand the original intent.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
The dptxport endpoint changed API between 13.3 and 13.5. Nobody is
supposed to run 13.3 OS firmware at this point so do not claim to be
compatible. The DCP linux driver is fixed since a couple of weeks to
accept 13.5 as compat version.
Signed-off-by: Janne Grunau <j@jannau.net>
Only the HDMI port on 14 and 16 inch Macbook Pros needs dcpext and the
dptxport endpoint implemention in the DCP driver supports only the 13.5
firmware. Postpone this for after the fedora release.
Signed-off-by: Janne Grunau <j@jannau.net>
Avoids manually matching pre-mapped memory against "carveout-memory-map"
and maintaining a list of hopefully static carveoout regions.
Leave t8103 and t600x alone for now. Porting dcp over to this a littles
harder since that needs additional handling for regions mapped to
"dart-disp0?".
Signed-off-by: Janne Grunau <j@jannau.net>
