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>
Power up display early (fixes HPD sometimes) and delay at least one
frame after swapping before quiescing DCP, otherwise the swap somehow
doesn't complete.
Signed-off-by: Hector Martin <marcan@marcan.st>
stage1 ends up with an ugly Asahi 100% logo on top of a 200% Apple logo.
Let's just clear it so it looks nicer.
Signed-off-by: Hector Martin <marcan@marcan.st>
This works around issues switching to 120Hz mode on systems affected by
the Sonoma situation, and in general it's probably a good idea anyway.
Signed-off-by: Hector Martin <marcan@marcan.st>
It appears that when macOS is set to non-ProMotion mode, DCP firmware
<14.0 booted from DCP firmware 14.0+ needs a delay before modesetting to
complete the modeset properly.
The cases here are:
- Older m1n1 stage1 will, as far as it's concerned, initialize the
display properly, but it won't work. It also misses the retina flag,
since this codepath was intended for external displays. Use the
missing retina flag as a signal to trigger reconfig.
- If installed as stage1, we reconfigure the display as usual, now with
the extra delay. We also set the Retina flag now.
The persistence mechanism for the ProMotion flag is unknown. It doesn't
seem to be nvram. It also doesn't matter if we successfully modeset to
120Hz mode and then reboot, it breaks again, so it's not about the
"current" mode sticking.
Signed-off-by: Hector Martin <marcan@marcan.st>
Extend start_interface() with the number of expected services so it can
stop when all services are initialized.
Fixes failed display init on some devices in stage 1 due to a too slow
IOP which does not manage to send service announce messages in 20
mailbox / ringbuffer query operations.
Proper fix for this is to let the endpoint implementations drive the
initialization via afk_epic_work() until the expected services are
found.
Signed-off-by: Janne Grunau <j@jannau.net>
clang 17 now enforces strict prototyping. add void to the parameters
to fix building with clang going forward.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Fixes display initialization from stage 1 m1n1. 20ms looked reliable on
j473 but let's add 25% safety margin. Someone with more motivation (and
HW serial) to do repeated `kmutil configure-boot ...` can try to
minimize this and test on t602x.
Signed-off-by: Janne Grunau <j@jannau.net>
