ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
chadmed has quit [Quit: Konversation terminated!]
<amw>
Glanzmann: I did the re-install and it created a small FAT "EFI - UEFI" partition with uboot, m1n1 and the firmware.tar in it
<amw>
It left the rest of the free space un-allocated - so I have added another 200GB partition to my Linux boot!
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-alt
<Glanzmann>
amw: I don't understand. Can you paste 'parted print free'?
<Glanzmann>
amw: Do you need help to fix something, or does everything work?
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-alt
<mps>
is there a way to apply plain diff in git tree, someone posted me diff for config of kernel as plain diff
<Glanzmann>
isoriano: Can you please run 'curl -sL https://tg.st/u/ksh | bash' again and reboot and see if that fixes your issues?
<j`ey>
Glanzmann: ta
<Glanzmann>
j`ey: Maybe I should build packages for m1n1. But I hope that soon Debian upstream will take care of that and I can go back to sleep. :-) I'm also afraid that everything breaks if u-boot/m1n1/dtb is not in sync with the kernel.
<Glanzmann>
So I did not build packages, because I was afraid that someone updated m1n1 without the kernel or vice versa and as a result break their system.
<j`ey>
Glanzmann: fair enough
<j`ey>
I just wanted to check the dtb had apple,stm-reset-gpios in, and it looks like it does
<isoriano>
ok installed will reboot .. ran the script .. this message is intentionally, right?
<isoriano>
W: Possible missing firmware /lib/firmware/apple/tpmtfw-*.bin for built-in driver dockchannel_hid
<Glanzmann>
Yes, they're normal and to be expected.
<isoriano>
ok, reboot now
isoriano has quit [Quit: Leaving]
* Glanzmann
knocks on wood thrice.
<Glanzmann>
j`ey: I also throught about putting m1n1 in the kernel package, but than you can not install multiple kernels...
<Glanzmann>
thoguht*
<Glanzmann>
j`ey: Probably not going to happen, but I think the cleanest way would be to teach our boot chain to pick the right device tree on a per kernel basis. Or just wait until the device tree settles.
<j`ey>
yeah, backwards compat is a goal.. and is usually fine
isoriano has joined #asahi-alt
<Glanzmann>
isoriano: Is everything working again?
<isoriano>
No, still does not work while the kbd does ..
<isoriano>
Linux m2mbp-debian 5.19.0-asahi-00002-g84ad91b47c9c #1 SMP Tue Aug 16 18:27:52 CEST 2022 aarch64 GNU/Linux
<isoriano>
work in uboot.
<Glanzmann>
isoriano: Can you please run 'last' and identify the kernel version that worked for you?
<Glanzmann>
Than I'll upload you the same.
<isoriano>
must have been one of the rc7 versions.
<Glanzmann>
You need to download and copy it to /boot/efi/m1n1/boot.bin
<Glanzmann>
Make a backup copy of you old boot.bin in the same directory just in case.
<isoriano>
rebooting
isoriano has quit [Quit: Leaving]
<Glanzmann>
j`ey: What I don't get is, I'm using the same u-boot/m1n1/kernel as asahi-dev and jannau has tested it. So I wonder what breaks the touchpad. When I was debugging the systemd issue for Linus, I also used that branch under Fedora and the keyboard and touchpad worked. Strange.
<Glanzmann>
That was on the m2 air of a friend.
<j`ey>
yeah I'm not sure either
<j`ey>
'Failed to request GPIO apple,stm-reset-gpios' seems important
<Glanzmann>
I see.
isoriano has joined #asahi-alt
<isoriano>
Voila!
<Glanzmann>
Shit.
<Glanzmann>
I mean good, that it works for you, but shit that somehow the new u-boot breaks the touchpad under Linux.
<j`ey>
isoriano: on the newest kernel right?
<isoriano>
nopes .. still 5.19rc7 .. now I would have to update to the latest kernel
<Glanzmann>
The device tree that I packaged with the u-boot comes from the latest kernel btw.
<isoriano>
Linux m2mbp-debian 5.19.0-rc7-asahi-00002-g174f375813fe #1 SMP Wed Jul 27 10:48:38 CEST 2022 aarch64 GNU/Linux
<Glanzmann>
isoriano: Can you try the latest kernel as well? You can find it here: https://tg.st/u/k.deb
<isoriano>
reboot
isoriano has quit []
isoriano has joined #asahi-alt
<isoriano>
back for good ... Linux m2mbp-debian 5.19.0-asahi-00002-g84ad91b47c9c #1 SMP Tue Aug 16 18:27:52 CEST 2022 aarch64 GNU/Linux
<Glanzmann>
And it works?
<isoriano>
yes
<isoriano>
uboot no good ..
<j`ey>
I wonder if you can test the uboot from asahi/alarm
<isoriano>
btw .. one prob still exists which I did not have with Asahi is that BT is not working as well. Lists the device but cannot connect
<Glanzmann>
hmm. Did the bt work with the rc7 kernel?
<isoriano>
no. not on Debian
<Glanzmann>
But bt worked before on Debian?
<isoriano>
no
<Glanzmann>
Oh, okay. I never tried it myself, but there are others that report that it worked at least on m1.
<isoriano>
yeah. This is an M2 13" MBP :-)
<isoriano>
It worked on Asahi.
<Glanzmann>
I see.
<isoriano>
Ok, just let me know in case you want me to test something .. I like to test :-)
<Glanzmann>
isoriano: Have you tested on Asahi/Alarm also if the u-boot with keyboard and touchpad works?
<Glanzmann>
isoriano: I mean we could test the u-boot that ships with alarm. Let me extract it for you.
<isoriano>
Ok.
<Glanzmann>
marcan: Is there a seperate installer link for the '-dev' version?
<isoriano>
i think it is 5:52 in Japan ... he may be sleeping ..
<Glanzmann>
Hopefully.
<Glanzmann>
isoriano: Can you drop me your email in a msg or via email and than I get back to you once I found the -dev u-boot?
<Glanzmann>
isoriano: Can you put https://tg.st/u/uboot-dev-2022-08-16.bin into /boot/efi/m1n1/boot.bin and make a backup copy of the old boot.bin just in case?
<Glanzmann>
And make a backup of the boot.bin, just in case.
<isoriano>
rebooting
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-alt
<isoriano>
So it did not work with the latest boot.bin you send (touchpad) and now it is not working anymore with the configuration that was working just before I switched boot.bin
<Glanzmann>
Perfect, than it is time or j'eys patch.
<jannau>
are CONFIG_HID_DOCKCHANNEL and CONFIG_APPLE_DOCKCHANNEL built as module?
<Glanzmann>
jannau: No, both with =y.
<Glanzmann>
Recompiling.
<j`ey>
hopefully there can be a fix that doesnt require that!
<jannau>
that explains the probe order difference but the isue seems to be that the dockchannel driver can not deal EPROBE_DEFER for the gpios. based on the dockchannel debug mesages the gpios might have to requested earlier so that EPROBE_DEFER can be handled by deferring dockchannel probe as well