<alyssa>
which illustrates the sort of trouble I'd like to avoid
<alyssa>
disp0 is the first dart intiialized 231304000
<alyssa>
notice it takes several frames to go from "init DART" to "console switched" 🤷
phiologe has joined #asahi-dev
quarkyalice_ has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
kenzie has quit [Remote host closed the connection]
kenzie has joined #asahi-dev
<marcan>
alyssa: there is a specific dead battery flow in the PD controllers; this is a chicken and egg problem in ~all devices
<marcan>
once the system is alive it takes over
<marcan>
(this is documented in the manuals for the similar TI parts)
<marcan>
alyssa: there should be no races involved; it is not a valid solution to try to race setting up a new FB
<marcan>
DART inits first, takes over the mappings race-free, then the DCP driver does whatever whenever
<marcan>
we absolutely need seamless DART mapping takeover; I do not believe DCP initialization can even be done reliably without that, it's not just about the screen flickering
<marcan>
this consequence follows from ASCs that are already running when we boot. those mappings *need* to stay because they could be written to at any time
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
not sure if that's just DCP or there are more, but DCP for sure
<marcan>
actually I need to see what ANS does for the panic buffer. I know for DCP it *gives* you a DVA that is already mapped, you just translate it (no idea why it needs that)
<marcan>
sven: you might know?
<marcan>
though ANS is special, what with the SART and all
<sven>
marcan: you just setup a new one every time you make ANS go through the hibernate/wake cycle
<marcan>
sven: does the init sequence change?
<marcan>
for DCP IIRC it *gives* you the dva when initializing the crashdump endpoint
<sven>
no
<marcan>
as it already knows it apparently
<sven>
at least i don't think so
<marcan>
then where does the dva come from?
<sven>
it *asks* for one from you
<marcan>
that's not what DCP does :)
<sven>
weird
<marcan>
see m1n1.fw.asc.crash
<marcan>
the request is "TranslateDva", DCP sends you the dva and then (for some reason?) you give it the physaddr
<marcan>
I have no idea why it wants that
<marcan>
but that is what happens with osx
<marcan>
that dva is in an area already allocated by iBoot
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
bisko has quit []
bisko has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
bisko has quit []
bisko has joined #asahi-dev
suricato_ has joined #asahi-dev
suricato has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
<alyssa>
pipcet[m]: would like to give your DCP branch a try
<alyssa>
cherrypicks cleanly, that's a start :)
<alyssa>
not sure where the corresponding DT / makefile / etc changes went
<pipcet[m]>
oh...
<pipcet[m]>
i, uh, think I decided to fix that "later" and put them all in the -dts branch :/
<pipcet[m]>
and, then, obviously, forgot and started playing with the DCP instead, getting nowhere near a working framebuffer after changing video modes :-(
<alyssa>
right...
<pipcet[m]>
alyssa: I don't think the DCP branch does anything on the mini, though?
<pipcet[m]>
you can set other properties, but the only one I can make do anything is property 0, which inverts all colors if set to 1.
<pipcet[m]>
oh. uhm. if set to 1 TWICE. The first set doesn't do anything. I think that's a bug somewhere though...
<alyssa>
uhmm
<alyssa>
I guess I also really need the uart stuff
<j_ey>
alyssa: m1n1 emulates enough of the samsung driver now
<pipcet[m]>
no console?
<alyssa>
j_ey: magic invoc?
<j_ey>
shouldn't need anything extra. just use picocom /dev/tty<something>
DarkShadow4444 has joined #asahi-dev
<j_ey>
where the something is the second m1n1 port
<alyssa>
yeah, just haven't managed to boot linx in the hv yet
<j_ey>
/dev/ttyACM1 for me
<j_ey>
oh..
DarkShadow44 has quit [Ping timeout: 480 seconds]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
<alyssa>
sven: I rebased Corellium's SMC driver on the new mailbox interface
<alyssa>
using the rtkit library, not the compat mailbox
<alyssa>
that was educational :')
<alyssa>
mu-one/linux:smc-2 tip has the rebased driver
<j_ey>
alyssa: is the locked dart stuff needed for that?
<j_ey>
(or just in the tree because)
DarkShadow44 has joined #asahi-dev
DarkShadow4444 has quit [Read error: Connection reset by peer]
DarkShadow44 has quit []
<alyssa>
j_ey: not for SMC, yes for DCP
<alyssa>
just in tree because this is me getting sidetracked from DCP
<alyssa>
seemed like a good warmup
<j_ey>
does that driver actually provide an interface? in sysfs or whatever, it doesnt look like it
<alyssa>
smc? idk, I just check that pressing the power button generates a syslog in dmesg