ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
Wubbzy04 has quit [Ping timeout: 480 seconds]
darkapex1 has quit [Remote host closed the connection]
darkapex1 has joined #asahi-dev
jacksonchen666 has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
<leio>
janneg: I guess it's expected to have the picture not update after stage1 if stage2 is still without that change?
jnn is now known as jn
<leio>
weird, chainloading an old stage2 from other computer otoh worked in terms of booting to linux without display; no clue then, but allows me to ssh to my linux partitions to actually make a matching stage2 as I hadn't grabbed a copy of those things before stage1 upgrade
<janneg>
leio: not sure, I'd expect it to work but I'm not sure what your 2nd stage does
<leio>
yeah, no idea what happened that one boot where display was stuck with last stage1 output
<leio>
when trying to boot my old working stage2; I SSHed in and now scratching head about dcpext5 branch or not
<leio>
janneg: so I should ditch the dcpext5 branch stuff now from m1n1 and kernel?
<leio>
the m1n1 bits conflict on .pmgr_dev changes
<janneg>
leio: yes, this is instead of the dcpext5 changes in kernel and m1n1
<janneg>
you don't need to build an entire new kernel, `make dtbs` is enough
<leio>
so it won't be able to drive a higher frequency in theory based on your commit about dcpext5 then? Of course my 6K resolution is a battle for another year probably :)
<leio>
full kernel builds in a minute, I'm sure it'll be redoing dtbs only anyhow :)
<leio>
so asahi-wip then?
<janneg>
or asahi-sources 6.6-p12 from the overlay
<leio>
again frozen picture from stage1
<leio>
hmm, it says No valid payload found
<janneg>
can you build a 2nd stage m1n1 without payload?
<leio>
after `make RELEASE=1 CHAINLOADING=1` on amd64 from m1n1 origin/main
<janneg>
you have to append options from where to chainload the 2nd stage
<janneg>
let me chack how the installer's upgrade routine works
<leio>
no worries
<leio>
I know what to do now, just completely forgot about that bit
<leio>
I'll chainload the full image from other computer instead to get the thing initial tested before going through the stage1 fix dance
<janneg>
ok, you could use the installer's upgrade m1n1 routine if you replace m1n1.bin in the installer's temp directory after it has started
<leio>
janneg: I have the echo commands and what to echo from an earlier stage1; I need to get u-boot going at some point now that that's fixed to use more of the standard upgrade tooling
<janneg>
so the same "AppleDCPDPTXController::handleInterrupt(): FIFO error interrupt COMMON_INT_STA_3=0x00000010" issue as with dcpext5. I suspect this might a display specific with the current dcp implementation
<janneg>
please remove apple_dcp.enable_verbose_logging=1 there's nothing helpful in it and obscures just the other messages
<janneg>
I assume still no luck with unpluging and replugging the display
<leio>
correct, though had forgotten to try that earlier, but still the case now after having booted it directly after stage1 fix
<leio>
I'll remove verbose logging and retry with that monitor, followed by the 6K monitor that advertises 4K@60Hz proper
<janneg>
Oh, just seeing something
<leio>
here's dmesg on the 59.9997 monitor for seeing better with less verbosity: http://dpaste.com/CZLNZ7695
<leio>
something about "IOMFB updateFrequencies EDT ERROR: getClockFrequency(0) (0) < videoClock 148500000! Giving up on frequencies." maybe? :)
<leio>
interestingly until I unplugged, the monitor wasn't responsive to trying to open the menu
<leio>
the monitor is in a failed firmware upgrade state, complains over OSD occasionally, hope it wouldn't affect anything; Dell going to replace it a second time soon..
<leio>
quality control of 2300 EUR monitors isn't really there, apparently (backlight flicker when dimmed, usb coil whine on previous, etc)
<janneg>
I wouldn't think so as you see the same or a very similar error on the 4k monitor
<janneg>
so something the dcp driver does "wrong" as 1920x1080 works with iboot. I've seen the "FIFO error interrupt" before. Unfortunately I can't remember the circumstances
john-cabaj has joined #asahi-dev
<leio>
4K works with m1n1 too, but that's that
<leio>
I guess that's effectively iboot in a way?
Compassion has quit [Quit: Ping timeout (120 seconds)]
<janneg>
dcp has two interfaces to control the display. one simplified used by iboot/m1n1 and the full one used by macos and linux