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
<lina>
eiln: Yeah, the surface filter is a hack... Though 0xc000 does work in practice ^^
<lina>
I wanted to get rid of the iotranslate stuff because I'd seen it crash there and also some really ugly memory corruption stuff (filesystem page cache oopses) and I felt really uncomfortable about doing it that way... ^^;;
<lina>
That's sus... in the DART only for t8112 ISP...
stipa has quit [Remote host closed the connection]
espo has quit [Quit: WeeChat 4.0.5]
<lina>
Woah... what's up with the DAPF property here...
<lina>
I'm so confused...
<lina>
Looks like that workaround thing is a red herring...
<lina>
I think it's the DAPF config getting lost when we power down the DART. We might need save/restore in the DART driver for that...
flom84 has joined #asahi-dev
<lina>
That and in general more stuff being wrong with the IOVA offset...
<lina>
I think it basically worked by accident when it worked ^^;;
AnuthaDev has quit []
<lina>
Maybe it doesn't need save/restore, hmm...
<lina>
Hmm... back to square one...
jeisom has joined #asahi-dev
<lina>
Fixed the tracer for t8112, trying to compare things now...
dcow has quit [Remote host closed the connection]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
mps has quit [Ping timeout: 480 seconds]
mps has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
<janneg>
the nvram size depends on on the stub version
dcow has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
<lina>
Pushed some stuff but I haven't really gotten anywhere... Next things to check are DART registers and whether there's any other weird init stuff (tunables...)
dottedmag has left #asahi-dev [#asahi-dev]
dottedmag has joined #asahi-dev
dottedmag has left #asahi-dev [#asahi-dev]
roxfan has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
<lina>
Only DART difference is streams 14 and 15... but I tried enabling them (just as clones) and it doesn't fault or anything, so I don't think that's it...
maria has quit [Remote host closed the connection]
maria has joined #asahi-dev
maria has quit [Ping timeout: 480 seconds]
maria has joined #asahi-dev
espo has joined #asahi-dev
maria has quit [Remote host closed the connection]
maria has joined #asahi-dev
fugi has quit [Quit: Ping timeout (120 seconds)]
fugi has joined #asahi-dev
Wormn has joined #asahi-dev
eiln has quit [Ping timeout: 480 seconds]
Wormn has quit [Remote host closed the connection]
kaazoo has joined #asahi-dev
<janneg>
which #address/#size-cells does FDT to parse ranges? for ADT (looking at spinor
<janneg>
it's apparently the nodes an not the parents
<kaazoo>
Using the same values as for other models made the GPU driver initialize correctly on my t6020-j414s. Before I had that uat_handoff remap error.
<marcan>
you have that backwards. those values are set by m1n1 and should never be hardcoded, in fact we should remove the existing ones.
<marcan>
the problem with t602x is just the missing no-map;, which we know.
<marcan>
until machines are considered production-ready there will be dumb stuff like this (this only breaks if you use u-boot, which we rarely do for testing)
<marcan>
in particular wifi isn't done for t602x machines and I'm in no particular rush to consider them usable until that's done, so if you really want to use them before they're ready you get to deal with the bugs :p
<marcan>
I'll fix this one for the next kernel tag anyway
SalimTer- has quit [Ping timeout: 480 seconds]
<janneg>
I think you did already both in the isp branch
<marcan>
quite possible :p (since I added the heap thing)
<kaazoo>
marcan: OK, thanks for the details. I already saw that "no-map" option added when comparing 6.4.10 and 6.5.x tags and wondered ;)
eiln has joined #asahi-dev
SalimTerryLi has joined #asahi-dev
Wormn has quit [Remote host closed the connection]
eiln has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
Leo3418 has quit [Quit: Applying updates]
Leo3418 has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
tenkuu has quit [Quit: WeeChat 4.0.4]
dcow has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Remote host closed the connection]
dcow has joined #asahi-dev
<jonmasters>
after chainloading a new m1n1, if I just want it to do a normal boot, how do I tell the proxyclient to continue?
<jonmasters>
i.e. I've got the new Linux kernel already on the system, don't want to do linux.py loading
<j`ey>
you have to use u-boot for that
<jonmasters>
I built an m1n1 with an appended u-boot
<jonmasters>
I think did a chainload -r with the new image
<jonmasters>
* then did
<jonmasters>
the system reset, chainload said it was waiting to reconnect
<jonmasters>
it reconnected, then I got Proxy is alive again and it exited
<jonmasters>
I'm assuming at this point it loaded the new m1n1 with the u-boot payload but is waiting to be told to run it?
<j`ey>
jonmasters: did you gzip uboot before you appened it?
<jonmasters>
yes
<j`ey>
can you check the logs, it should talk about payloads at some point
<jonmasters>
followed the instructions to build a stage 2 then chainloaded it
<jonmasters>
I'll try a direct kernel load
<j`ey>
if you can post the m1n1 log that would help diagnose it
<jonmasters>
I built the u-boot binary by pulling the latest git, then cross compiled setting CROSS_COMPILE with the Fedora aarch64 gcc
<jonmasters>
(ACM1 because I appear to have some other device on this laptop, so I get ACM0 and ACM1 for the M1)
<jonmasters>
(ACM1 because I appear to have some other device on this laptop, so I get ACM1 and ACM2 for the M1)
<jonmasters>
* corrected
<j`ey>
looks like the 2nd m1n1 didnt show up, I think that output is from stage1
<jonmasters>
indeed
<jonmasters>
what I'm waiting to do is build a stage2 u-boot and chainload that
<jonmasters>
am I missing something?
<sven>
that output looks normal, the error at the end happens because chainload.py is usually used to load into another m1n1 without u-boot
<sven>
and I think m1n1 with u-boot, etc. will try to boot into of exposing another proxy on usb
<sven>
*instead of
<j`ey>
right, a normally chainloaded stage2 wont do USB serial, makes sense (when I was doing this, mostly I did it under the hv, so I did have serial output..)
<sven>
is the dtb also part of that m1n1-uboot.bin?
<jonmasters>
yea
<sven>
and yeah, i usually just run this into the hv as well and always skip uboot as well
<sven>
*inside
<jonmasters>
ok so here's the thing, if I load a kernel and dtb into hv what patches the dtbs?
<j`ey>
m1n1 still
<sven>
oh, I run the full m1n1+kernel inside the hv
<jonmasters>
right, that's what I did, but you do it without the raw m1n1?
<sven>
cat build/m1n1.macho Image.gz t8103-j274.dtb > payload.macho; python3 proxyclient/tools/run_guest.py -S payload.macho is my (at this point very old) runhv.sh
<j`ey>
you could try the same m1n1-uboot.bin with run_guest.py, that should work
<j`ey>
(instead of chainloading)
<jonmasters>
right
<j`ey>
that would get you output, and hopefully help diagnose the issue
<jonmasters>
thing is since I'm testing those USB4 patches I need to switch the dtb that gets patched
kidplayer_666_ has quit [Remote host closed the connection]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
jeffmiw has joined #asahi-dev
<jeffmiw>
It seems that the asahi/calamares installer is not able to configure correctly the keyboard selected: when setting the fr applealu_iso in the installer, it is not configured when login after. I saw that while trying the fedora remix.
<jeffmiw>
is there an easy way to run this calamares first boot installer to investigate ?
eiln has joined #asahi-dev
<janneg>
jeffmiw: with an recent image? Since the images don't contain xorg-server related packages anymore there was an issue with /etc/X11/xorg.conf.d/ missing but I believe that should be fixed
<jeffmiw>
I used the rawhide version
<janneg>
yes, systemd-localectl uses that path to store global keyboard layout config
<janneg>
it just depends on the image creation date. does /etc/X11/xorg.conf.d/ exists?
<jeffmiw>
it does not.
nela has quit [Ping timeout: 480 seconds]
<jeffmiw>
I think I used the 20230929 image, still quite recent