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
ourdumbfuture has joined #asahi-dev
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
veloek has quit [Remote host closed the connection]
veloek has joined #asahi-dev
jeisom_ has quit [Ping timeout: 480 seconds]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
gabuscus has quit []
sawyer_ has joined #asahi-dev
sawyer has quit [Ping timeout: 480 seconds]
sawyer_ is now known as sawyer
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gabuscus has joined #asahi-dev
tobhe_ has joined #asahi-dev
crabbedhaloablut has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
tristan2_ has joined #asahi-dev
tristan2 has quit [Ping timeout: 480 seconds]
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
completenoob has joined #asahi-dev
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
completenoob has joined #asahi-dev
CoolStar has joined #asahi-dev
CoolStar_ has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
completenoob has joined #asahi-dev
eiln has joined #asahi-dev
Cyrinux9474 has quit []
Cyrinux9474 has joined #asahi-dev
<eiln>
ah-: sorry for the late reply, $dayjob
<eiln>
I just remembered the firmware is per-device. god.
<eiln>
ah-: can you try setting ctrr_size=0xf00000 under dt_set_isp_fwdata() in m1n1 src/kboot.c
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
eiln: left some comments on the m1n1 PR, but I'm tempted to hack on this a bit myself if you don't mind
<eiln>
marcan: yeah, that part's really shaky and it's pretty relevant rn.
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
completenoob has joined #asahi-dev
<marcan>
going to poke around on an M1 air and see if I can clean up a bit
<marcan>
eiln: what's up with apple_isp_resv_region? that stuff is already handled in common code, no? it actually fails for me because of_iommu already took care of it and the mappings end up duplicated...
ourdumbfuture has joined #asahi-dev
<marcan>
or was this broken in the asahi branch still? (I rebased on asahi-wip, please always use that as a base; asahi is more so random packagers don't package random dev kernels, but I keep forgetting to update asahi...)
ourdumbfuture has quit []
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
with that removed it works \o/
<marcan>
now let me see if I can clean up the DART stuff a bit
ourdumbfuture has joined #asahi-dev
<marcan>
args.unk_size = 0x1800000; that sure looks like the heap size thing
completenoob has joined #asahi-dev
cylm has joined #asahi-dev
jeisom_ has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
completenoob has joined #asahi-dev
<marcan>
eiln: I have this idea that we just carve out the heap in m1n1 and drop it in as a reserved region and let the linux side be oblivious to it
completenoob has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<eiln>
marcan: woohoo! device?
<marcan>
t8103 m1 air, should be the same as you
<marcan>
I'm trying out this idea and cleaning up the m1n1 side a bit
<eiln>
also left some comments in the draft pr
<eiln>
marcan: I tried and failed to do both the mapping and the heap in m1n1 some time ago. it really should be a locked dart, except it's not, so the mapping didn't persist I think
<marcan>
oh on power off?
<marcan>
linux does the mapping, m1n1 just tells it via reserved-regions
<marcan>
I'm saying we just alloc the heap in m1n1 and treat it like another region, so it just works
<marcan>
working on it
<marcan>
then we can also put the silly hardcoded table in m1n1
<marcan>
(I like putting stupid stuff in m1n1)
<_jannau__>
have you checked if i-boot creates a carveout? check carveout-memory-map in the adt
<marcan>
_jannau__: this is allocated by macOS
<eiln>
left another comment which might be useful
tobhe_ is now known as tobhe
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<marcan>
eiln: so I think the heap top thing is per ISP hardware rev, not per firmware
<marcan>
I'm starting to doubt whether it actually makes sense to alloc in m1n1, since you have a pile of per-hw hardcoded values in the kernel anyway
cylm has quit [Ping timeout: 480 seconds]
<marcan>
still might though
<eiln>
marcan: following ANE I think "revision" means board type. it makes sense at that point in probe too. it's not in adt but there might be a register.
<eiln>
the hard-coded values are per-sensor, which are unrelated to the board type (e.g. m1 pro & m2 air)
<marcan>
there is a register
<marcan>
but it's not board type
<marcan>
by hardcoded values I mean apple_isp_hw_t8103 etc
ourdumbfuture has joined #asahi-dev
<eiln>
oh that. sigh, they have a firmware for each fucking device I dont know why they couldn't have took care of that shit in there. t8103 is probably all the same, but it might not be
<marcan>
it should be if it's mostly hardware stuff
<marcan>
look at drivers/gpu/drm/asahi/hw/* if you want pain :p
<eiln>
but the sizes are different per OS version too. that's not in the kext
<marcan>
ah, ew
<marcan>
then that's a good reason to do it in m1n1
<eiln>
yeah, that 13.5 issue I had some time ago was this
seb91nihel has joined #asahi-dev
seb4nihel has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
<marcan>
eiln: I need to get some sleep, but I pushed a bunch of stuff to m1n1 & linux under the isp/heap-alloc branch on both
<marcan>
didn't break it on t8103 at least :p
<marcan>
that moves the heap alloc to m1n1 which removes the slightly dodgy thing of allocating it as a surface. the driver still needs to parse the heap base+size to compute the region top, but that's not that bad.
<marcan>
also started adding t8112 but that's half-assed
<marcan>
I *think* the logic in isp.c for the heap sizes is correct for all the combinations we care about. I think. Might've guesstimated based on nearby versions :p
<marcan>
btw, why the drm_mm/manual iova management? I'm not sure if the DRM folks will want non-drm drivers using that infra, but I'd normally expect the regular kernel iommu/iova allocators to do all that for you?
<marcan>
(the drm stuff is more... peculiar since it's intended for GPUs)
<marcan>
anyway, let me know what you think of those changes
<marcan>
I'll try to look at the DART mess next
<_jannau__>
is there a need to map specific things at specific iova? or is it needed due to dart mess? i.e. mapping subsets but only consistantly over multiple darts?
<marcan>
at least the heap has to go at a specific iova, but I just took care of that one
<marcan>
not sure about the rest
<marcan>
man why is apple so damn inconsistent about everything
<marcan>
this is like the only coproc that has a statically allocated heap not carved out in iBoot
<marcan>
the random hardcoded addresses/values in kexts make me cry
<_jannau__>
different teams not allowed to know of each other without adult oversight
<marcan>
yeah...
<marcan>
and also rushing to ship
<_jannau__>
and not allowed to fix past mistakes
<marcan>
more like no time
<_jannau__>
same same
<marcan>
btw, does anyone have a t6020 *laptop*? I think that's the only ISP SoC variant I can't personally test (because I have the mini...)
<marcan>
(though I kind of hope/assume it's identical to t6021)
<_jannau__>
are t6000 and t6001 identical?
<marcan>
actually it's the same firmware so yeah
<marcan>
and yeah I think so
<marcan>
t8103 -> pallas, t600x -> astraeus, t8112 -> triton, t602x -> helios (yes another set of codenames)
<_jannau__>
have there been any surprise differences between Pro and MAx variants so far? I can't think of anything
<marcan>
GPU has some stuff
<marcan>
other than that no, I think
cylm has quit [Ping timeout: 480 seconds]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
cylm has joined #asahi-dev
<marcan>
there's so much junk in this firmware, like Face ID stuff...
<eiln>
shower thought. piodma could mean peripheral IO DMA device
<eiln>
ISP is not the only one with a static non-iboot carveout. see ANE and AVE ;)
<eiln>
also I can finally boot the ANE firmware with my cursed ISP knowledge. not sure what to do with this
<eiln>
ANE/AVE also use greek mythology code names, particularly the Hyperion/Crius family tree
<eiln>
the drm mm allocator is because iova.c can't allocate bottom up. there was a patch some time ago but it wasn't reviewed. some stuff about zero iovas
<eiln>
as for the ANE, DMA to/from the upper iovas (I think it was piodma_size <= iova <= vm_size) is noticeably slower, at least 10x, and their kext actually does tricks to avoid using this range. it seems loading/unloading an entire transformers model is cheaper
<eiln>
with the heap gone (thank you), the only iova arithmetic is in firmware boot stage 2, but that's all contained within the ipc surface so it shouldn't matter.
<eiln>
quickly inverting the iovas in m1n1 does not break it. frankly, it was pasted from the ane code, and also the familiar iovas make debugging a lot easier. I will check on the bottom-up allocator though
lena6 has quit [Remote host closed the connection]
ellyq has joined #asahi-dev
jeisom_ has quit [Ping timeout: 480 seconds]
Guest2042 has quit [Quit: Bridge terminating on SIGTERM]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
Jamie has joined #asahi-dev
Jamie is now known as Guest2157
rhysmdnz has joined #asahi-dev
<eiln>
the power domains, the one required read the revision version register, not being in the dt, is such a nice touch
Cyrinux9474 has quit []
Cyrinux9474 has joined #asahi-dev
<ChaosPrincess>
Required read = something is read-sensitive and won't boot w/o it?
<sven>
dma to higher iovas is *slower*? how the hell did they mess that up
<sven>
like, does that dma go through some additional path or whatever because the device can’t handle that many bits in the dma address??
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<ah->
eiln: was kinda fun playing with m1n1 and debugging this all a bit
<ah->
still getting the same "ISPASC: ASSERT: ./h10isp/common/misc/H13/CSystemConfiguratorConnectivityH13Jade.cpp, 472: 0" and then timeouts with ctrr_size=0xf00000
<ah->
i was staring at the macos trace a bit (https://textbin.net/raw/dwnb1wyhud) and latest theory is that the boot_args data is somehow different. I can see the place where it writes the bootargs addr to the gpio, but the contents look different. e.g. I can't find args.unk_size = 0x1800000 or args.unk5 = 0x40; in the macos trace