ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
msmith12[m] has quit [Server closed connection]
msmith12[m] has joined #asahi-dev
Guest466 has quit [Server closed connection]
enick_53 has joined #asahi-dev
sikkileo[m] has quit [Server closed connection]
sikkileo[m] has joined #asahi-dev
yuyichao_ has joined #asahi-dev
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-dev
riker77_ has joined #asahi-dev
suricato_ has joined #asahi-dev
suricato has quit [Ping timeout: 480 seconds]
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
c10l has quit [Remote host closed the connection]
c10l has joined #asahi-dev
c10l has quit [Remote host closed the connection]
c10l has joined #asahi-dev
c10l has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
Hinata[m] has quit [Server closed connection]
Hinata[m] has joined #asahi-dev
abilash1994[m] has quit [Server closed connection]
abilash1994[m] has joined #asahi-dev
alexanderwillner[m] has quit [Server closed connection]
alexanderwillner[m] has joined #asahi-dev
davay[m] has quit [Server closed connection]
davay[m] has joined #asahi-dev
Bastian[m] has quit [Server closed connection]
Bastian[m] has joined #asahi-dev
BastienSaidi[m] has quit [Server closed connection]
BastienSaidi[m] has joined #asahi-dev
bpalmer4[m] has quit [Server closed connection]
bpalmer4[m] has joined #asahi-dev
brentr123[m] has quit [Server closed connection]
brentr123[m] has joined #asahi-dev
daftfrog[m] has quit [Server closed connection]
daftfrog[m] has joined #asahi-dev
David[m]1234 has quit [Server closed connection]
David[m]1234 has joined #asahi-dev
Dcow[m]1 has quit [Server closed connection]
Dcow[m]1 has joined #asahi-dev
denden[m] has quit [Server closed connection]
denden[m] has joined #asahi-dev
dnjmis[m] has quit [Server closed connection]
dnjmis[m] has joined #asahi-dev
Liam[m] has quit [Server closed connection]
Liam[m] has joined #asahi-dev
etsukata[m] has quit [Server closed connection]
etsukata[m] has joined #asahi-dev
fetsorn[m] has quit [Server closed connection]
fetsorn[m] has joined #asahi-dev
ghantaz[m] has quit [Server closed connection]
ghantaz[m] has joined #asahi-dev
ianlienfa[m] has quit [Server closed connection]
ianlienfa[m] has joined #asahi-dev
joerosenberg[m] has quit [Server closed connection]
joerosenberg[m] has joined #asahi-dev
katatafjsh[m] has quit [Server closed connection]
katatafjsh[m] has joined #asahi-dev
kdrag0n[m] has quit [Server closed connection]
kdrag0n[m] has joined #asahi-dev
kjm99[m] has quit [Server closed connection]
kjm99[m] has joined #asahi-dev
lockna has quit [Server closed connection]
lockna has joined #asahi-dev
l3k[m] has quit [Server closed connection]
l3k[m] has joined #asahi-dev
mmlb[m] has quit [Server closed connection]
mmlb[m] has joined #asahi-dev
fezhead[m] has quit [Server closed connection]
fezhead[m] has joined #asahi-dev
notyou[m] has quit [Server closed connection]
notyou[m] has joined #asahi-dev
obflv[m] has quit [Server closed connection]
obflv[m] has joined #asahi-dev
ograff has quit [Server closed connection]
ograff has joined #asahi-dev
HaoYanQi[m] has quit [Server closed connection]
bisko has quit [Read error: Connection reset by peer]
HaoYanQi[m] has joined #asahi-dev
latko[m] has quit [Server closed connection]
latko[m] has joined #asahi-dev
bisko has joined #asahi-dev
RasmusEneman[m] has quit [Server closed connection]
RasmusEneman[m] has joined #asahi-dev
plantaintion3[m] has quit [Server closed connection]
plantaintion3[m] has joined #asahi-dev
ponkey364[m] has quit [Server closed connection]
ponkey364[m] has joined #asahi-dev
rohin[m] has quit [Server closed connection]
rohin[m] has joined #asahi-dev
quentin[m] has quit [Server closed connection]
quentin[m] has joined #asahi-dev
Redecorating[m] has quit [Server closed connection]
Redecorating[m] has joined #asahi-dev
rethematrix[m] has quit [Server closed connection]
rethematrix[m] has joined #asahi-dev
retonlage[m] has quit [Server closed connection]
retonlage[m] has joined #asahi-dev
rgort10[m] has quit [Server closed connection]
rgort10[m] has joined #asahi-dev
samfromspace[m] has quit [Server closed connection]
samfromspace[m] has joined #asahi-dev
shaman_br[m] has quit [Server closed connection]
shaman_br[m] has joined #asahi-dev
SocioProphet[m] has quit [Server closed connection]
SocioProphet[m] has joined #asahi-dev
sppdqd[m] has quit [Server closed connection]
sppdqd[m] has joined #asahi-dev
Guest477 has quit [Server closed connection]
enick_375 has joined #asahi-dev
Synth[m] has quit [Server closed connection]
Synth[m] has joined #asahi-dev
user974[m] has quit [Server closed connection]
user974[m] has joined #asahi-dev
Name[m] has quit [Server closed connection]
Name[m] has joined #asahi-dev
xiaomingcc[m] has quit [Server closed connection]
xiaomingcc[m] has joined #asahi-dev
YichaoYu[m] has quit [Server closed connection]
YichaoYu[m] has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
the_lanetly_052___ has joined #asahi-dev
GraysonGuarino[m] has quit [Server closed connection]
GraysonGuarino[m] has joined #asahi-dev
IsfarSifat[m] has quit [Server closed connection]
IsfarSifat[m] has joined #asahi-dev
MatthewLeach[m] has quit [Server closed connection]
MatthewLeach[m] has joined #asahi-dev
null-nop[m] has quit [Server closed connection]
null-nop[m] has joined #asahi-dev
ybk[m] has quit [Server closed connection]
ybk[m] has joined #asahi-dev
zbotpath[m] has quit [Server closed connection]
zbotpath[m] has joined #asahi-dev
gryfbane[m] has joined #asahi-dev
captain has joined #asahi-dev
captain has quit []
<marcan> fun, looks like the APCIE/ANS2 relationship is indeed as specified in ADT... which means we need to make ANS2 support multiple PDs, dammit
mixi has quit [Ping timeout: 480 seconds]
mixi has joined #asahi-dev
<marcan> sven: btw, have you tested the m1n1 nvme stuff on t6k?
<marcan> I get Message 1: assert failed: [11184]:HIX 256 timed out for segIdx 0x603 in 8 seconds, comp FIFO count 0, bus=0, nandOp=0 on attempting to shut down
<sven> i don't have a t6k
<marcan> ah
<marcan> also read commands complete but the buffer is not written to
<sven> that sounds weird
<sven> never saw that on my t8103
<marcan> ah wait, I fail it
<marcan> TTY> nvme: command failed with status 11
<marcan> so it does fail
<sven> :D
<marcan> but I don't know why
<sven> do you use namespace id 1?
<sven> but i think it'll complain in syslog anyway if you don't
<marcan> sven: that was one problem, but now it still fails with no error :D
<sven> uh. so it never completes the command?
<marcan> oh wait, that's proxy fail
<marcan> wasn't passing through retvals :D
<marcan> ok, so the read works now
<marcan> but nvme_shutdown() explodes with that assert
<sven> hrm, it did that after i updated to 12.x when I didn't deleted the SQ/CQ
<sven> but i think you already merged the PR for that
<marcan> it dies in rtkit_sleep
<sven> and i guess the panic message isn't all that helpful?
<marcan> it's just that assert I pasted
<marcan> it spends 8 seconds waiting for something then asserts
<marcan> not sure if any of that is useful to you :D
<marcan> I/O SQ : 0x10006bd0000, size: 64, tail/head: 0/0
<marcan> I/O CQ : 0x10006bd4000, size: 64, tail/head: 0/0
<marcan> not sure if that's supposed to disappear when you delete that queue?
<marcan> those delete commands don't fail though
<sven> hrm, iirc those things should disappear (or at least have size: 0)
<marcan> sven: is tag always supposed to be 0 in command submission?
<sven> yeah, I only queue one command at a time there anyway
<sven> I only realized later that I could've also decreases the queue size then but forgot to fix that
<sven> tags can be reused once they appear on the completion queue and have been written to NVMMU_TCB_INVAL
<marcan> also I don't really see any syslogs?
<marcan> am I supposed to?
<marcan> ah wait, that was a #define right
<sven> yeah
<marcan> yeah, just the usual boot syslogs
<marcan> ending with rtkit(nvme): syslog: [cmd.c:5848]Emergency GC: must = 4, special=5
<marcan> which I assume is normal
<sven> yeah
<sven> i just tested it on my t8103 and it still works there
<marcan> wonder if the sq/cq deletes don't work for some reason...
<sven> can you try send a few commands? It should show something different from 0/0 then
<sven> +to
<sven> at least on the cq. the sq doesn’t have a head/tail because it’s not really a queue when the nvmmu is used
<marcan> sven: still 0/0 on both
<sven> sounds like the queues are deleted then though and the print is just misleading
<marcan> sven: I also get 0/0 if I remove the delete commands
<sven> huh. can you also remove the disable_ctrl call?
<sven> iirc it’s supposed to delete the queues once NVME_CC.EN has been cleared
<marcan> ah yeah
<marcan> Admin SQ: 0x100061b0000, size: 64, tail/head: 0/0
<marcan> Admin CQ: 0x100061b4000, size: 64, tail/head: 2/2
<marcan> I/O SQ : 0x100061bc000, size: 64, tail/head: 0/0
<marcan> I/O CQ : 0x100061c0000, size: 64, tail/head: 2/2
<marcan> that does it
<marcan> and yeah, the I/O one becomes 0 and the Admin one 4/4 if I issue the deletes and not the disable
<marcan> so that seems to work
<sven> no idea why it panics then though :/
<marcan> ok, it's a stupid race
<marcan> if I wait before shutdown it works
<marcan> I think it explodes if I try to shut it down before the "GC Search bitmap" rebuild is done
<marcan> call it another ANS bug? :/
<sven> :/
<sven> can you check if nvme_ctrl_disable was actually successful?
<marcan> and it works without delay if the last shutdown was clean
<marcan> yeah, I already added that
<sven> so i think there's another way to shut down nvme a bit more cleanly
<marcan> the interesting thing is iBoot doesn't trigger this rebuild at all, which means it's probably booting in some kind of read-only mode?
<sven> i kinda take the big hammer approach by clearing NVME_CC.EN
<sven> but let me check again
<sven> yeah, you can set NVME_CC.SHN to trigger the shutdown
<sven> and then wait for NVME_CSTS.SHST
<marcan> aand now I just can't repro
<sven> lol
<sven> <3 ANS
<sven> it's the same for this weird thing where the linux driver sometimes misses irqs or commands for other people. i could reproduce it once (but I even doubt that at this point) but since then it's been working fine for me even without that additional mystery spinlock around command submission
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-dev
<marcan> TTY> rtkit(nvme): syslog: [cmd.c:7704]NVMe shutdown start seg->lba: 0, seg->size: 0
<marcan> TTY> rtkit(nvme): syslog: [cmd.c:7717]seg->lba 0 saveCtx 1 took 126 ms
<marcan> ok, that works
<marcan> took a while to realize we weren't *clearing* the shutdown field
<marcan> on init
<marcan> and apparently it's transition-sensitive, so it was doing nothing
<marcan> ok, confirmed that the shutdown process at least blocks on the GC rebuild properly
<marcan> u-boot should probably also do this then
<marcan> actually this timed out, heh
<marcan> need to give it more time
<marcan> sven: so, good chance this fixed it
<sven> ouch
<kettenis> the u-boot nvme code doesn't try very hard to shut things don properly
<kettenis> shut things down I mean
<marcan> kettenis: I'll make it do the same thing m1n1 does now at least
<marcan> do you mind if I push straight to asahi in u-boot? or would you rather I run things through you?
<kettenis> not sure; my git skills are somewhat limited
<marcan> sven: also the shutdown field being set implies iBoot is doing this too
<marcan> kettenis: it's easier not to clash if we use separate branches, so I can leave you in charge of asahi if you want
<marcan> (and just open PRs)
<kettenis> then let's do that
<marcan> kettenis: apparently PRs default to upstream uboot since ours is a fork. we could re-create the repo, or apparently GH support can just fix it for us; either way I think it's preferable if the fork relationship is removed, since otherwise we might open PRs against upstream. does that make sense?
<marcan> if you're okay with that, I'll try the second route (apparently there's a chatbot? wonder if it's automated...)
<marcan> I guess GH-tied forks only make sense for projects that actually take GH PRs...
<marcan> (I'm talking about the 'forked from u-boot/u-boot' at the top of the repo, which apparently makes PRs default to going to that repo)
<marcan> (would be nice if GH had a setting to control this independently, but it seems they don't...)
<kettenis> the u-boot/u-boot git repo is only a mirror; the real upstream is a gitlab at denx.de
<kettenis> guess breaking the fork means you can't push the button to synch master with upstream
<kettenis> but that's ok
<marcan> yeah, you'd want to rebase asahi when you do that anyway, which you'd be doing via the cli
<marcan> I don't even use the master branch in our linux repo
<marcan> I'll ask the chatbot, see what happens
<kettenis> go for it
<kettenis> I don't use the master branch of that repo either
<kettenis> I pull directly from denx.de
<marcan> done, apparently it opens a ticket after asking you for the info
<marcan> so I guess now I wait for a human :)
blasty has quit [Remote host closed the connection]
<marcan> going to grab some dinner and then fix this power domain stuff
<marcan> kettenis: does u-boot support multiple PDs for a single device? because it looks like we're going to need that for ans... :(
<marcan> though I still need to double check that ANS2 doesn't just manage these itself
<marcan> yeah, it doesn't :(
<kettenis> indeed it doesn't
<kettenis> had to hand-roll that for pmgr
<kettenis> what is wrong with the current way that's represented in the device tree?
<kettenis> other than that it doesn't correctly describe the actual hardware?
jannau has quit [Server closed connection]
jannau has joined #asahi-dev
amarioguy has joined #asahi-dev
<marcan> kettenis: the apcie_st nodes do truly depend on ANS2 in hardware; they refuse to come up without it
<marcan> which means loading nvme as a module fails since by then pmgr has shut things down
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kettenis> doesn't that mean you should make ps_acpie_st depend on ps_ans2 and make the mbox/sart/ans2 nodes depend on ps_acpie_st?
wCPO6 has quit [Server closed connection]
wCPO6 has joined #asahi-dev
<amarioguy> general question: how do i get started reversing hardware? i've heard MMIO tracing mentioned a few times as a completely clean way of doing it, but can someone give me a tl;dr version or something
<marcan> kettenis: it's *two* depending domains on t6000
<marcan> so that doesn't work
<marcan> there's more than one leaf
<marcan> of course we could cheat by chaining them all, but that's... not great :/
<amarioguy> btw @marcan, if we want to use information from the Asahi Linux project for something independent (with credit of course!) is that allowed under the license?
<amarioguy> any particular restrictions on that
<marcan> what do you mean by use information?
<marcan> you mean like hardware docs and such, not copying anything verbatim?
<amarioguy> like using information about Apple hardware documented on the Asahi Linux wiki, or looking at the Asahi Linux driver code as a reference for Apple hardware or stuff like that
<amarioguy> yea definitely *not* verbatim copying
<marcan> facts aren't copyrightable, so you don't even have to ask that question :-)
<j`ey> and the code is GPL (+MIT for some bits)
<marcan> looking at driver code of course comes with the usual cleanroom caveat, i.e. if you think you might accidentally copy something copyrightable, then you should follow the license
<marcan> but we try to license everything worth copying as MIT anyway
<amarioguy> that's good to hear, i just wanted to ask, since i know licensing can be quite a murky subject so I wanted to err on the side of caution and all
<j`ey> amarioguy: whats your plan? ;D
<marcan> honestly, re: code, I'd rather you just outright copy stuff if you want and follow the license (which isn't hard) :)
<amarioguy> don't want to reveal my cards just yet, but it's gonna be a fun one if it goes to plan ;)
yuyichao_ has quit [Ping timeout: 480 seconds]
<j`ey> alyssa: just watched the 2019 vid, cant remember anything about it since my mind was wiped
the_lanetly_052__ has joined #asahi-dev
<alyssa> j`ey: I too can't remember much of it ;0
<j`ey> alyssa: you ran away!
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<alyssa> I did yes
yuyichao_ has joined #asahi-dev
<marcan> so many subtle module issues...
<marcan> geninitcpio missing modules, module aliases gone wrong, missing ops owner for dart...
<sven> :D
<sven> i don’t think I ever tried anything as a module fwiw
IanPlatt[m] has joined #asahi-dev
<marcan> yeah, I'm trying *everything* as a module now
<marcan> :p
<sven> my bet for breakage would’ve been SART or rtkit though
amarioguy has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
<marcan> those are fine!
<marcan> because they're hard module deps
psykose has quit [Ping timeout: 480 seconds]
psykose has joined #asahi-dev
<sven> lol, so atcphy definitely has a few “reset the whole system if you do something wrong” modes
<kettenis> really?
<sven> I’ve only been poking some registers there and it just rebooted my system a few seconds later
<sven> same thing happen a while ago when I tried to bring up cio to test my mailbox patches there
<sven> but there it was a minute or so before it decided to reboot
<marcan> sven: sounds like smc, where if the asc/m3 watchdog expires the whole system reboots?
<marcan> also: [ 848.984220] dwc3 702280000.usb: this is not a DesignWare USB3 DRD Core
<marcan> wonder how *that* happens...
<alyssa> thonk
<sven> lol
<sven> maybe it’s still in reset
<sven> all regs read back as 0 then and the dwc driver can’t find some magic value
<sven> but m1n1 should’ve already taken it out of reset
<marcan> but it works built-in and fails as a module? :p
<marcan> oh I bet I know
<sven> yeah, that’s weird
<marcan> sven: define reset
<marcan> some internal dwc thing?
<sven> some bit in registers apple calls “pipehandler”
<marcan> yeah, well, you see, linux will powergate everything that doesn't have a driver
<marcan> :D
<marcan> so I bet that killed that
<sven> hah. yeah
<marcan> can we make linux deal with that too?
<sven> yeah, with the phy driver I’m working on…
<marcan> hah, ok
<sven> or, well, it exposes a reset line we need to hook up to dwc3
<marcan> cool
<sven> and then it should do the right thing
<marcan> I'll just mark the PDs as always-on for now
<marcan> and wait for that
<sven> sounds good
<marcan> (something something DT compat break but oh well)
<sven> there’s a chance we also need to redo the usb2 phy init sequence m1n1 does fwiw
<marcan> sure
<sven> though I guess some part stuck because the dwc3 regs serror before that one iirc
<sven> or maybe I’m misremembering things
<sven> https://github.com/AsahiLinux/m1n1/blob/main/src/usb.c#L125 that's the one that makes all regs read back as 0. i have BIT(0) as DWC3_RESET_N
<sven> and BIT(4) is FORCE_CLAMP_EN
<sven> (whatever that is, but xnu always flips it together with the reset)
<sven> er... wrong line
<sven> "drd_regs_unk3" is what apple calls "pipehandler"
amarioguy has quit [Ping timeout: 480 seconds]
<marcan> sven: looks like only the _aon domains need to stay on to avoid disaster
<marcan> (or maybe having those on prevents powergating and only allows clockgating, which is also a thing that happens)
<marcan> at least on t6k
<sven> apple calls the register with that reset bit something like “AON_GEN” but that could just be a coincidence
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has joined #asahi-dev
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
yrlf has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan> bleh, still finding more module dep fail
<marcan> going to sleep, it's 4AM
<Glanzmann> marcan: Have a good night sleep.
DarkShadow44 has quit [Server closed connection]
DarkShadow44 has joined #asahi-dev
<Glanzmann> m a r c a n: Could you please also apply poviks audio jack input patch, he already asked you 2 days after rebase to apply the same. With this patch audio recording over the jack works for 2020 models: https://tg.st/u/XKVZ.patch mps and I have tested it extensively on the 2020 air and pro.
<Glanzmann> That is the last patch I have in the Debian build which is not in your tree.
amarioguy has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
<Glanzmann> So u-boot installation worked. Logo looks strange.
<Glanzmann> But it does not boot grub, investigating.
<j`ey> Glanzmann: if you mean u-boot logo, that's just because there's a patch that needs cherry-picking
<Glanzmann> I see.
<mps> I think this logo is upstream
<mps> and not sure why it would be changed for asahi u-boot
<Glanzmann> jannau: I see.
___nick___ has quit [Ping timeout: 480 seconds]
<mps> jannau: I have same logo on arm32 peach_pi (exynos-5800 chromebook) as it is in current asahi u-boot (and it looks quite fine for me personally)
<mps> jannau: maybe I've built peach_pi u-boot from your branch, I forgot
amarioguy has quit [Ping timeout: 480 seconds]
<j`ey> yes asahi branch has it, but not the u-boot branch used by the installer
<mps> hmm, I have logo on rk3399 chromebook, u-boot built from Alper Nebi Yasak github fork
<mps> (in last month I've built so much u-boots so I lost what is where)
<alyssa> iBoot U-Boot we all boot for boot boot
<mps> I hope one day someone experienced with firmware will create u-boot to be flashed to 'flash rom' (leave all hopes you who enters here :) )
<sven> flash rom?
<mps> sven: flash u-boot into boot eeprom
<sven> uh, on the m1?
<mps> is that possible
<sven> no
<mps> hmm, why? how macos on upgrade does this
<sven> because apple has the iboot encryption key and the private signature key
<mps> uh, ...bad word here...
<sven> with those they can sign new iboot stage 1 versions and flash those to the nor
<mps> didn't knew this
<sven> we’re literally putting m1n1 and uboot to the earliest point we can
<j`ey> sven: there's an iboot stage before that right?
<j`ey> iboot ROM(?) -> iboot (NOR) -> m1n1?
<sven> there’s SecureROM which is inside the SoC followed by the first stage iboot in NOR
<sven> erm… now I just confused myself. The first stage iboot is the secureROM
<sven> and the second stage is in the NOR
<sven> ah.. yes. So im confused, possibly behause it’s late here ;)
<sven> but either way, we can’t replace any of the stages before what we currently replace
<j`ey> yeah
<mps> unsolder rom and replace with eeprom :)
<sven> the rom is inside the SoC
<mps> oh yes, I know
<mps> it is in SoC
<mps> late is here too
<sven> :-)
<j`ey> sven: decap it
<sven> and then use some fancy ion beams or micro needles or something to replace it!
<sven> and then do even more low level hardware init we can’t easily observe that the two iboot stages otherwise do for us!
<j`ey> :D
<mps> heh