marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
axboe has quit [Ping timeout: 480 seconds]
<hramrach>
shared tags are pretty new, they weren't in 5.14
<hramrach>
or was that some other version where they were missing?
<hramrach>
using too many old kernels
<j`ey>
oh I didnt realise it was some generic feature
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jbowen has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi
kov has quit [Quit: Coyote finally caught me]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
kov has joined #asahi
<Glanzmann>
marcan: axboe only sees 5 cpu cores, but he should see 8 (2e; 6f). Any idea what this is about. Here is his kernel config: tg.st//u/m1-config-smc-2022-02-06 and here is video of m1n1: https://tg.st/u/video-1644259413-yuv420p.mp4 (rehosted an reencoded to be able to watch it better in a browser) CONFIG_NR_CPUS=256, so its not that.
<Glanzmann>
s/6f/6p/g
<tpw_rules>
what does the device tree say? is he using u-boot?
<Glanzmann>
He is using tethered boot and the device tree that comes with the kernel (smc branch).
<tpw_rules>
it's possible to leave cores by the wayside if the entries in the device tree to init them are not right
<tpw_rules>
m1n1 has to init them and set the cpu-release-addr
<marcan>
m1n1 is stopping after #4
<marcan>
I'm guessing this is a machine with disabled cores?
<Glanzmann>
I was not aware that this is possible. Is this a config thing in MacOS?
<marcan>
fixed in m1n1 6f525fc0f186, probably
<marcan>
(which I just pushed)
<Glanzmann>
I see. I ping him.
<marcan>
08:18:52 < axboe> looked up the hw, mine has 2 energy, 6 perf
<marcan>
yeah, downbinned machine
<marcan>
that commit probably fixed it then
<Glanzmann>
I see.
<Glanzmann>
marcan: So this is a CPU that has some broken cores, so it is sold in the low end machines with disabled cores?
<marcan>
in theory
<Glanzmann>
I see.
<marcan>
good chance they aren't actually broken, since the first "failed" core is the last p-core in the cluster which is suspicious :p
<marcan>
that's what they'd do when they have too many good CPUs and need to just disable cores and sell them as lower-core ones
<Glanzmann>
Ah, I see.
<marcan>
(it could be they remap within a cluster to always make the failed cores last, but that seems like too much effort)
jbowen has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jbowen has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
jx0 has joined #asahi
atka has joined #asahi
<Glanzmann>
mps: I now switches to the smc branch with u-boot. Thank you for the instructions. I also updated my bootstrap.sh script and the Debian artefacts.
duc4405[m] has joined #asahi
duc4405[m] is now known as ducc[m]
N3ros[m] has quit [Server closed connection]
N3ros[m] has joined #asahi
lendi[m] has quit [Server closed connection]
lendi[m] has joined #asahi
jx0 has quit [Quit: poof!]
eroux has joined #asahi
karlyeurl has quit [Server closed connection]
karlyeurl has joined #asahi
jbowen has joined #asahi
AdwyzzOLEDEdition[m] has quit [Server closed connection]
AdwyzzOLEDEdition[m] has joined #asahi
JamesTaylor[m] has quit [Server closed connection]
JamesTaylor[m] has joined #asahi
atka has quit [Quit: WeeChat 3.4]
leah2 has quit [Server closed connection]
leah2 has joined #asahi
fetsorn[m] has quit [Server closed connection]
fetsorn[m] has joined #asahi
jbowen has quit [Ping timeout: 480 seconds]
ar has quit [Server closed connection]
ar has joined #asahi
daniel0611[m] has quit [Server closed connection]
daniel0611[m] has joined #asahi
<sven>
axboe: yeah, single io and a single admin queue only. I'll take a look into using shared tags, the current approach is just copied from the pci driver
denden[m] has quit [Server closed connection]
denden[m] has joined #asahi
z11h_beast[m] has quit [Server closed connection]
z11h_beast[m] has joined #asahi
ifthenelse has quit [Quit: Ping timeout (120 seconds)]
<joske>
could be a gkrellm problem, but other tools might have same issue
<marcan>
there is no AC adapter device yet
<joske>
ah
<joske>
the panel applet does see that it's charging though
<marcan>
because that's a property of the battery, not the AC adapter
<marcan>
they are different things
maz_ is now known as maz
bdju has quit [Ping timeout: 480 seconds]
bdju has joined #asahi
<maz>
marcan: is there a minimal SMC branch I can pick in order to start looking at this PCIe hotplug issue? the current smc/work has all sort of stuff piled in...
<marcan>
you do need RTKit and all that... or do you mean something else?
<maz>
I'm happy to drag the rtkit dependency in my tree, but not *everything* that's on that branch! that's pretty much everything that's currently in flight ;-)
<marcan>
I'll put together a bits branch soonish :)
<maz>
thanks! :)
KrushnaDeore[m] has quit [Server closed connection]
KrushnaDeore[m] has joined #asahi
MajorBiscuit has joined #asahi
jix has quit [Server closed connection]
jix has joined #asahi
<mps>
Glanzmann: so, battery driver works also on air when machine booted with u-boot iiuc?
jbowen has joined #asahi
<joske>
mps: yes, if you put the dtsi of the kernel in u-boot an rebuild u-boot
<joske>
I'm booting with u-boot, and battery driver working
jbowen has quit [Ping timeout: 480 seconds]
<mps>
joske: nice to know, and it works also on MPB
<Glanzmann>
mps: Wifi works also. And now I have on kernel for tethered and untethered boots.
<Glanzmann>
one*
<Glanzmann>
So I can continue working on the debian installer.
<mps>
good, wifi, rtc, mca, battery, keyboard/touchpad are now usable
<mps>
so backlight is only missing to have really good workstaion
<mps>
backlight i.e. brightness control
<mps>
Glanzmann: did you tried to change gamma with simpledrm (to set color temperature) or redshift
<Glanzmann>
mps: No, I did not.
<chadmed>
redshift doesnt work under wayland yet, i guess simpledrm doesnt have gbm support?
<chadmed>
would make sense since you need gamma LUTs from the hardware afaik
<chadmed>
and since theres no hardware...
<mps>
chadmed: yes, also I think so
<mps>
chadmed: though it doesn't work also on my rk3399 (gru-kevin) chromebook and it have hardware driver
<chadmed>
the rockchip driver doesnt support the GAMMA_LUT DRM property
<chadmed>
which is what is required by wayland compositors to correct colour output
<mps>
interesting is that mt8173 (mediatek) supports it fine
<chadmed>
yeah its something that has to be implemented in the drm driver. the property is attached to the crtc object (basically the scanout buffer) in the driver, and wayland compositors access it to apply colour corrections
<chadmed>
its currently only supported in amdgpu, i915, mediatek, sun4i, omap, vc4, rcar and nouveau
<_jannau_>
dcp can and will eventually support it
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vup has quit [Server closed connection]
pwg has quit [Server closed connection]
pwg has joined #asahi
qm3ster[m] has quit [Server closed connection]
qm3ster[m] has joined #asahi
arthegor[m] has left #asahi [#asahi]
<landscape15[m]>
Glanzmann: I think you have to specify to run ```make modules_install``` on the Mac running Linux in this guide https://github.com/AsahiLinux/docs/wiki/Untethered-m1n1 Otherwise, modules are installed in the build system. Correct me if I’m wrong
<chadmed>
if you have the rootfs somehow mounted on the build machine you can also give make the INSTALL_MOD_PATH parameter
<landscape15[m]>
chadmed: yeah maybe with an external USB
<mps>
landscape15[m]: did you looked at make script I posted few times, there is 'recipe' how to build and install modules
<chadmed>
it also works with an NFS/samba mount (through the kernel) afaik so you can mount the remote root somewhere in the local filesystem and install the modules there
<landscape15[m]>
mps: yeah I used it. But on Ubuntu I can’t resolve openssl1.1-compat-dev dependency
<mps>
landscape15[m]: you need to tweak it to use package names and versions on your distro
<landscape15[m]>
I don’t know which is the equivalent. dtc is device-tree-compiler on Ubuntu
<mps>
landscape15[m]: Glanzmann probably knows names and versions
<nsklaus_>
re: mps| so backlight is only missing to have really good workstaion .. --> yes and make it available in one unified installable form, a beta release of asahi distro
<mps>
nsklaus_: I doubt that unified installer will be ready till all kernel stuff become upstreamed to mainline
<chadmed>
marcan wants to do a beta release soon-ish, thats why hes working on all the power management stuff this week.
<nsklaus_>
asahi team could make it itself while waiting for stuffs to be properly mainline'd
<chadmed>
not even beta tbh, if a letter came before alpha it would probably be that
<j`ey>
chadmed: `, in ascii :P
<nsklaus_>
i mean, create a prerelease with everything that's already been done so far. even though not everything has been included in mainline, what's stopping the team to make it ?
<j`ey>
nsklaus_: nothing, it's going to happen
<nsklaus_>
j`ey: that's good to hear
<chadmed>
apart from what we discussed not two days ago (the fact that nothing that isnt upstreamed is really production-ready yet) nothing, which is why its happening soon :)
<nsklaus_>
chadmed: good to hear too
yuukirafflesia[m] has quit [Server closed connection]
yuukirafflesia[m] has joined #asahi
<nsklaus_>
pre-alpha-wip :)
<mps>
chadmed: aha, fine
DarkShadow4444 has quit [Server closed connection]
DarkShadow44 has joined #asahi
krirogn[m] has quit [Server closed connection]
krirogn[m] has joined #asahi
pimeys[m] has quit [Server closed connection]
pimeys[m] has joined #asahi
Stary has quit [Server closed connection]
Stary has joined #asahi
ChristianOndaatje[m] has quit [Server closed connection]
ChristianOndaatje[m] has joined #asahi
pent1ckel has quit [Server closed connection]
pent1ckel has joined #asahi
NightsOnly[m] has quit [Server closed connection]
NightsOnly[m] has joined #asahi
<Glanzmann>
landscape15[m]: You can add the make modules_install, however of course the modules need to end up on the rootfs or initrd. I have that for the debian build scripts, but not in the instructions. This is what had me, you and axboe without a framebuffer, because I forgot that SIMPLEDRM was a module due to dcp testing.
<Glanzmann>
landscape15[m]: On Ubuntu just do a apt-cache search <package> | grep package to find the version you need.
<nsklaus_>
Glanzmann: does it require building or importing pre-built kernel when installing ? does it fetch automatically needed firmrwares during the install ?
<Glanzmann>
nsklaus_: Of course it does.
<nsklaus_>
of course, which part ? of course it require building or importing kernel, or , of course it automatically fetch all the needed firmwares during install ?
<Glanzmann>
nsklaus_: Kernel is prebuild, but optionally you can build everything yourself.
<Glanzmann>
And of course it fetches all the firmware during install.
<nsklaus_>
on linux building your own kernel is always an option, what i'm trying to figure is how functionnal the installation process has become so far, and how much manual steps are still required, and how much unified and consistent the whole distro has become so far
<nsklaus_>
i can forgive missing hardware support that is still wip, but a consistent install is a must, and assurance all the bits and pieces of the distro work well together
g8rfx9wozue0e9pa3n[m] has quit [Server closed connection]
g8rfx9wozue0e9pa3n[m] has joined #asahi
<j`ey>
lol
<Glanzmann>
nsklaus_: I'm only doing Debian. With Debian it is almost there, but not quiet. Ubuntu will be simliar, for other Distros, I have no idea.
<Glanzmann>
At the moment it is ready for kernel developers, soon it will be ready for end users.
<mps>
Glanzmann: I see you use perl
<Glanzmann>
mps: Of course I do, I hate python, don't know python. Perl I know well and apple gave me a perl interpreter for a reason.
<mps>
Glanzmann: I'm in your bandwagon :)
<nsklaus_>
yes, i'm waiting on that part, becoming ready for users, and even then it will be like a rocky road
<nsklaus_>
bumpy road
<Glanzmann>
But this is anyway just proof of concept and get some early adopters running, someone else will rewrite it in python and ship it when its time.
<mps>
Glanzmann: I use perl to make utils every day, and never tried to learn python
<Glanzmann>
nsklaus_: I'll soon record a video which will make it possible to install Debian in approx. less than 20 minutes with only a few manual steps.
<nsklaus_>
Glanzmann: i'll watch it
<nsklaus_>
thanks for doing it
<Glanzmann>
mps: Everytime I tried to use python in blew in my face (www::mechanize alternative, utf8), at some point I said, no thanks.
<Glanzmann>
nsklaus_: You can also already watch the three videos which are already there. They're bumpy, but get you where you need to be eventually. I'm rebuiling the debian artefacts daily. So everything is up2date.
<nsklaus_>
Glanzmann: i watched some of these previous POC install videos
<nsklaus_>
i did find it too much early for me
<Glanzmann>
nsklaus_: I see, there is one new about the live system. But soon it will be like executing 3-4 commands and getting into 1tr.
<nsklaus_>
the state of the distro i mean, i prefered to wait a bit more for things to settle a bit mor
<nsklaus_>
e
<Glanzmann>
I mean most distros will take a year or two to adopt at least. Because we first need to get everything upstream. Once its upstream it has a chance to be being picked up by a distro. And than we have to wait for the next distro release. Which is 1,5 years for Debian at least.
<Glanzmann>
Debian Testing might be quicker but not much quicker.
<immychan[m]>
Frankly, I think that presumes we‘lol get mainstream support all
<immychan[m]>
Linux on M1 seems more like something we’d see in a fork
<sven>
uh, no
<sven>
there's already stuff inside mainline and we'll upstream the rest as well
<mps>
Glanzmann: if some of alpine devs experienced with alpine installer I think we could have alpine install ready in a month or two (if I continue to test basic ideas)
<j`ey>
immychan[m]: it's all going upstream eventually!
<immychan[m]>
mps: Now that sounds awesome
<immychan[m]>
I think the main thing that I’m waiting on before I jump in is a simple installer
<nsklaus_>
i'm wondering, what is the position of asahi regarding macos updates, i mean, some macos updates will also change bits of the recovery boot partition, and many thing might get updated, would that harm asahi boot ? will it be necessary to do extra steps at each macos updates ? like on intel reinstalling / regenerate grub's boot blocks on hdd ? i understand on asahi things are more complicated about the boot process, how macos
<nsklaus_>
updates could endanger asahi ability to boot ?
<Glanzmann>
mps: In Debian the kernel is missing, and you need to be able to tell the d-i to say that grub installs in removable media path and does not try to update nvram modules and than it would work out of the box.
<Glanzmann>
s/modules/variables/
<mps>
myon98: I have installer for alpine ready on usb disk but I'm thinking about put it ESP from asahi-installer
<Glanzmann>
mps: I could do that as well (put the installer in esp or run it from usb stick).
<mps>
myon98: sorry, I mean immychan[m]
<immychan[m]>
The install process is way to complex for me lol
<mps>
Glanzmann: yes, we can do now to make it nearly ready, but imo for 'true' distro install we need kernel in distro repos
<Glanzmann>
nsklaus_: Nope, because we can freeze the stub, if we need to.
<nsklaus_>
i guess i could also wait and see the beta getting out and read through the install notes
<mps>
for example I made script to install alpine on usb disk with unofficial kernel and u-boot (I made and put them on dev.alpinelinux.org/~mps/m1)
<mps>
but didn't started to write guide
<immychan[m]>
That sounds genuinely very useful, thank you
<chadmed>
nsklaus_: macos updates are self contained and the firmware ABI goes with it. the asahi macos stub with all the boot time firmware + u-boot + m1n1 will never be updated unless we want it to
<immychan[m]>
Is there any script like that for Debian that just sets everything up automatically?
<Glanzmann>
immychan[m]: tg.st/u/m1di.pl but it is not ready for end users (tm).
<mps>
in a day or two I will upload new u-boot and kernel and fix script
<Glanzmann>
I'll improve the script in the following days so that it is more robust and user friendly.
<nsklaus_>
chadmed: good to hear, things a coming together nicely, i just finished marcan's last stream and now poweroff/reboot seems implemented too, all good news :)
<Glanzmann>
Wow, I'm looking forward for poweroff.
<immychan[m]>
Glanzmann: How would I use this? Simply run it on my M1 system?
<nsklaus_>
when audio out (through speakers) will be there it will be a very good base to use while waiting for the rest to come, gradualy
<immychan[m]>
nsklaus_: I think there is already, I’m content to use headphones or a Bluetooth adapter
<chadmed>
BT doesnt work yet. the adapter has an odd interface that needs to be reverse engineered first
<nsklaus_>
immychan[m]: on macmini maybe ? i'm on macbookpro (2020)
<immychan[m]>
chadmed: I’d be using a USB adapter
<Glanzmann>
immychan[m]: Start the asahi installer.
<Glanzmann>
immychan[m]: Once in 1tr run this script
<immychan[m]>
Where’s the Asahi Installer?
<Glanzmann>
immychan[m]: Than you have to decide between u-boot (for m1) or tethered m1n1 (for m1 pro/max).
<_jannau_>
usb is easy to fix, we're still investigating why the keyboard is not probed
<mps>
axboe: thanks, I will as Glanzmann later to send me kernel config
Erus_Iluvatar has joined #asahi
<mps>
_jannau_: so it is too early for Pro/Max to make it 'easy' to install
<mps>
s/as Glanzmann/ask Glanzmann/
<_jannau_>
there are no currently no kernel config differences between m1 and m1 pro/max
<mps>
_jannau_: thanks for info
<_jannau_>
the same kernel will work on all apple silicon targets
<mps>
_jannau_: that is what I expected but wasn't sure
<j`ey>
_jannau_: for now, but I think there are differences in the audio codecs, right?
the_lanetly_052 has joined #asahi
<_jannau_>
even now the sdcard reader is also is only on m1 pro/max devices so that's something to check for
<_jannau_>
bu all core drivers are the same and just depend on dtb compatible and not CONFIG options
<axboe>
j`ey: don't see audio here, was just looking at that
<j`ey>
axboe: I dont think its working on the pro/max yet
<axboe>
j`ey: gotcha
Erus_Iluvatar has quit [Ping timeout: 480 seconds]
Erus_Iluvatar has joined #asahi
Erus_Iluvatar has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has joined #asahi
the_lanetly_052 has quit [Read error: Connection reset by peer]
<Glanzmann>
mps: This is the config which works for m1 and m1 max/pro. I also did set SIMPLEDRM and dependencies to yes so that you see something on the screen before the rootfs is loaded. https://tg.st/u/m1-config-smc-2022-02-06
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<Glanzmann>
jannau: What is the kernel option for the sdcard? Than I enable it my config for the m1 max/pro users.
<axboe>
j`ey: since you asked, comparing just nop io_uring requests/sec between an x1 gen9 with a core i7-1185G7, x86 scores ~210M/sec and ~230M/sec on the m1 pro
<axboe>
~255M/sec if I include the two effiency cores
<axboe>
with no batching, m1 is substantially slower. syscalls look more expensive
<tpw_rules>
what page size are you using?
<axboe>
16k
<j`ey>
null: any thoughts on that ^
<_jannau_>
Glanzmann: CONFIG_MMC_SDHCI_PCI
<null>
j`ey: the "syscalls look more expensive" bit?
<j`ey>
yes
<j`ey>
you like the syscall code :P
<null>
j`ey: sure; just trying to figure out what the question/context was
<mps>
Glanzmann: thanks. we have too much differences
<null>
I don't have an recent x86 box to compare with, and there could be a bunch of reasons why syscalls are slower, so difficult to say much without more info
<null>
(e.g. could just be config, could be more stuff that we save/restore like the PAC keys)
<null>
axboe: if there's a concrete benchmark where you think things are slow, I'm happy to take a look if you could send a mail to LKML or LAKML
<null>
(for syscall / entry, that is)
<axboe>
null: may indeed just be an artifact of differences in the arch, just reporting what I'm seeing from my very first tests
<axboe>
which is the PAC option? I can try without
<j`ey>
ARM64_PTR_AUTH ARM64_PTR_AUTH_KERNEL
<axboe>
let's see if it does anything
<axboe>
fwiw, I'm running t/io_uring -N1 -c1 -s1 from the fio repo
<axboe>
single thread, 10M for my x86 laptop, 4M for the m1
<axboe>
and that's purely syscall bound
<j`ey>
axboe: and its running on the perf core?
<j`ey>
not sure what those cli options are
<axboe>
j`ey: yep
<axboe>
compiling...
<null>
axboe: does that just run forever, or does it eventually summarize? Is the 'IOPS' bit roughly the nr of syscalls/sec (when those options are used) ?
<axboe>
null: it keeps running until you ctrl-c it, unless you set a runtime
<axboe>
null: with the options above, it's exactly equal to syscalls per second
<axboe>
disabling PAC is good for about a 7.5% improvement
<sven>
axboe: w.r.t nvme: the controller is indeed limited to 1 admin and 1 io queue, both with 64 entries at most and the tags have to be shared across them because the controller FW uses the tag as an index for a shared data structure
<axboe>
_jannau_: will give it a go
<_jannau_>
no cpu frequency driver yet
<axboe>
sven: yeah I surmised as much, my question was on why aren't you just using a shared tags set for the admin and IO queue?
nsklaus_ has quit [Ping timeout: 480 seconds]
<kov>
well, it fluctuates, now 0.84 user 1.15 sys
<sven>
axboe: because i couldn't figure out how to do that
<axboe>
sven: ah ok, maybe I found a spot to help then :)
<sven>
sure! :)
<tpw_rules>
kov: have you happened to try UTM?
<sven>
i only saw how to share tags across queues inside a single tagset but not how to share tags between ctrl.admin_tagset and ctrl.tagset
<kov>
using parallels mostly for convenience, though I have a VM in UTM that I use from time to time too
<kov>
tpw_rules, I found no significant different tbh, cpu-wise it's the same as far as I have tested it, and all of them use the same virglrenderer, so...
the_lanetly_052__ has joined #asahi
<j`ey>
axboe: what's the benefit of the shared tags? is that that you dont need to reserve 8 for the admin queue, and therefore can use more for the normal io?
<sven>
yup
<axboe>
exactly
<axboe>
merged with current -git, some weirdo conflicts
<axboe>
building...
<_jannau_>
rebasing onto 5.17-rc1 had iirc just 1 or 2 trivial conflicts (without smc though)
<axboe>
_jannau_: this was just a merge, but had ~20 files with conflicts I had to resolve
<axboe>
unrelated stuff, all of it
<maz>
running fio in a VM is pretty interesting: IOPS=6925K with 16k pages, IOPS=4235K with 4k pages.
<axboe>
woo
<axboe>
booted -rc3 merge and with the m1n1 clock change, ~7.3M
<axboe>
from ~4.3M
<axboe>
1.84s E core getpid, 1.39s P core
<maz>
I guess that Pro/Max is a wee bit faster than my standard M1.
<j`ey>
axboe: cool!
<maz>
anyway, I need to repost the PMU support so that you can all have fun counting cycles!
<sven>
hrm, i should also repost that ugly usb hack. and maybe work on that 4k iommu thing again.
<axboe>
maz: that'd be awesome :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<maz>
sven: yeah, 4k support would be great. I'm tired of having a special M1 build! ;-)
<tpw_rules>
sven: the 4k iommu thing as i last found it seems to work fine
<j`ey>
axboe: Im guessing most of that was the m1n1 change
<axboe>
also takes the "all cores" peak to 380M :)
<sven>
tpw_rules: it works but I need to work on the review comments I got last time
<tpw_rules>
sven: ah okay
<axboe>
j`ey: I'd expect so, can't imagine -git adds much :)
<sven>
well, "works". it won't for untrusted devices but it'll be a while before we have thunderbolt anyway
<axboe>
this thing is flying now with that clock change
<null>
Funny, that
<axboe>
null: yeah who would've thought...
<mps>
sven: I use 4K iommu patch to mount f2fs, didn't had issue (at least for now)
hckr has joined #asahi
<sven>
yeah, i've been using it for a while now. i'm confident it does what it's supposed to do. it just needs a more work to (hopefully) be accepted upstream
jbowen has quit [Ping timeout: 480 seconds]
<sven>
but good to hear you guys didn't manage to break it either ;)
hckr has quit [Quit: hckr]
<mps>
what is ethernet driver name in kernel confog for mini
<maz>
TG3
<mps>
AQUANTIA?
<_jannau_>
tg3, not sure abot the config name
<_jannau_>
aquantia is the 10gbit driver
<maz>
TIGON3, actually
<mps>
thanks, will add it kernels I build
<landscape15[m]>
How can I check if SMC works under Linux?
<j`ey>
landscape15[m]: look in /sys/class/power_supply
<tpw_rules>
does smc mean poweroff works?
<j`ey>
nearly
<landscape15[m]>
j`ey: there is an applesmc-battery folder
<j`ey>
markan managed to have a poweroff today, but the drivers arent there yet
<landscape15[m]>
s/applesmc/macsmc/
<j`ey>
landscape15[m]: that should have `capacity` and other stuff in there
<j`ey>
so it's working
<maz>
axboe: 20220208185604.1097957-11-maz@kernel.org <- PMU patches. plumbing this on pro/max is left as an exercise for the reader.
<landscape15[m]>
j`ey: yeah there are. But shutdown doesn’t work
<axboe>
maz: b4 not finding it yet, did you just send it?
<maz>
axboe: couple of minutes ago.
<axboe>
I'll give it a few more
<landscape15[m]>
j`ey: ok then. I also see the battery icon in kde
<j`ey>
tpw_rules: poweroff also relies on SPMI/PMU
<maz>
axboe: ah, that's because I copy-pasted the last patch instead of the first (had a 1 in it, could have been good).
<maz>
20220208185604.1097957-1-maz@kernel.org is what you are looking for, until the last patch trickles in...
<axboe>
maz: there we go
jbowen has joined #asahi
<landscape15[m]>
SMC works but again USB no :) I still don’t know the reason
<j`ey>
kernel configs is the obvious place to start
bdju has quit [Ping timeout: 480 seconds]
<landscape15[m]>
j`ey: yeah but I don’t find more related options to check. The same happens with Glanzmann .config here https://tg.st/u/m1-config-smc-2022-02-06
<j`ey>
landscape15[m]: what device are you pluggin in?
<landscape15[m]>
j`ey: only a usb-c dongle
<j`ey>
got anything else to try?
<landscape15[m]>
No, because I don’t have other dongles. When I connect it I see the led lighting, but no device is recognized.
<j`ey>
then probably needs a modprobe or something
<landscape15[m]>
The weird thing is that using an old kernel image (I made some weeks ago using mps’s config) USB actually worked
<landscape15[m]>
And I didn’t install any module to make it work
timokrgr has quit [Quit: User left the chat]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
timokrgr has joined #asahi
<mps>
landscape15[m]: do you have kernel branch smc/work with battery, spi and other patches ready to build? I can post you my config with everything working fine
<landscape15[m]>
mps: thanks a lot. I’ll give it a try
c41e3a has quit [Quit: c41e3a]
___nick___ has joined #asahi
dhewg has quit [Server closed connection]
dhewg has joined #asahi
jbowen has quit [Ping timeout: 480 seconds]
<Glanzmann>
landscape15[m]: Are you installing the kernel modules?
<Glanzmann>
landscape15[m]: Which Distribution are you running?
<Glanzmann>
landscape15[m]: Which m1 device do you have?
<Glanzmann>
jannau: Thank you for the kernel optin for SDCARD, I already had it in.
mrkajetanp has quit [Server closed connection]
mrkajetanp has joined #asahi
<Glanzmann>
But it was missing from the 'DesktopKernel' wiki page, I added it.
<Glanzmann>
jannau: You cracked the u-boot keyboard issue on m1 max/pro?
<jannau>
yes
<Glanzmann>
jannau: Congrats.
<Glanzmann>
jannau: Does that mean we can use the same u-boot on m1 and m1 max pro?
<Glanzmann>
If that is the case, I would change my scripts to pull u-boot from you and change the wiki pages.
<landscape15[m]>
Glanzmann: I’m running Debian on M1 MBP, without installing modules for now. I don’t want to mess up my rootFS if basic things doesn’t work
<j`ey>
landscape15[m]: that's probably it then, if you have whatever USB as a module..
<Glanzmann>
Reboot and everything is working.
<j`ey>
landscape15[m]: basic things still need modules!
<sven>
unless you just disable modules and make everything built-in :P
<Glanzmann>
landscape15[m]: If you want to build the kernel by yourself, just have a look at my script. And please build the kernel using the debian infrastructure using 'make -j 16 bindeb-pkg'
<Glanzmann>
And than install the corresponding deb.
<Glanzmann>
landscape15[m]: Are you running on m1 or m1 max/pro?
<landscape15[m]>
Glanzmann: Ok I’ll try. It’s an m1 Mac. Do I run bindeb-pkg instead of “make Image dtbs”
<landscape15[m]>
s/”/”?/
<Glanzmann>
landscape15[m]: Yes.
<Glanzmann>
landscape15[m]: It's the Debian build infrastructure which was upstreamed in the linux kernel. So you can just build a deb out of the upstream kernel.
<Glanzmann>
You install this deb and the Debian infrastructure takes care of everything: Put the file where they belong, run depmod -a, build an initird, update grub config and god knows what.
<Glanzmann>
landscape15[m]: Are you on the u-boot?
c41e3a has joined #asahi
<Glanzmann>
If not, do that as well, boot to 1tr download curl -sLO tg.st/u/ush; bash ush
<j`ey>
sven: thats what I do!
<Glanzmann>
Because than, if something does not work, you can just boot the debian lvie system.
<j`ey>
sven: even build in the wifi firmware, so i dont need an initramfs :P
<Glanzmann>
jannau: How is that possible
<sven>
the way it’s meant to be!
<Glanzmann>
j`ey: How can you compile in the wifi firmware?
<j`ey>
landscape15[m]: this is probably the reason
<mps>
j`ey: yes, I noticed this in Glanzmann config
___nick___ has joined #asahi
<j`ey>
which is why it didnt work without modules
<mps>
I set usb driver with =y in case I boot from usb
milek7 has quit [Server closed connection]
milek7 has joined #asahi
<mps>
I thought to upload my u-boot and kernels this evening but interrupted with upgrading kernels for alpine
int16h has joined #asahi
jeffmiw has joined #asahi
___nick___ has quit [Ping timeout: 480 seconds]
<int16h>
Hello! I've just acquired a T6000/J314s so thought I'd see if I would poke around XD. I am, however, struggling to get a kernel to boot - the furthest it gets is: 'Preparing to run next stage at 0x1000dc00000...' before the proxyclient bailing and the log on the MBP screen clearing - I've applied the patches as described in the wiki::quickstart (and asahi.txt quickstart). Am I missing something? :D
<int16h>
Sure, I've tried https://tg.st/u/m1-config-2022-01-27 and another that was named config-2022-01-28 but I didn't check the options individually
<int16h>
OK, I shall recompile and see if that works. Thanks :)
<axboe>
the 2022-02-08 should be good
jbowen has quit [Ping timeout: 480 seconds]
<ah-[m]>
hey, do you have any advice what to do about a flaky usb connection to m1n1? i've installed it on a t6001, and connecting via a usb-c -> usb-a phone charging cable, and i've managed to boot linux once
<sven>
get a better usb cable :-(
<ah-[m]>
but most of the time i'm getting any of m1n1.proxy.UartTimeout: Expected 1 bytes, got 0 bytes, TTY> usb-dwc3@702280000: Host cleared EP 0x82 stall or similar
<ah-[m]>
ok, might try and getting another one, I tried two cheap phone charging cables
<mps>
also I have two problematic usc-c<-->usb-c cables
<sven>
as usual, usb is cursed and all that. but this specific dwc3 controllers deserves a special place in hell
<sven>
if the M1 is in gadget mode (which it always is inside m1n1) and the usb connection is flakey and drops at the wrong moment the entire controller needs a hard reset to work again
<j`ey>
it's weird because I can go days.. with it being fine, and then some days it just refuses to work
<j`ey>
(Im never sure if it's the m1 side or the rpi side..)
<sven>
knowing usb it’s probably both sides :P
<jannau>
or the cable
<mps>
cable from apple power supply works fine
<sven>
for me a usb c/usb c cable with all lines present (i.e. it claims 10 gbps support) works just fine
<j`ey>
I have a script to unbind/rebind the USB driver on the rpi, in case
<jannau>
it's also rock solid for me with a fully connected usb-c <> usb-c cable
<tpw_rules>
i've never had a problem with a usb a -> c cable
<tpw_rules>
but i only ever tried one
<j`ey>
this is usb a -> c
<mps>
I have one old noname usb-a > usb-c and it always worked fine
<mps>
i got it with one sandisk ssd
<sven>
It would’ve be usb if there was a pattern ;)
<mps>
sven: :-)
psydroid has quit [Server closed connection]
psydroid has joined #asahi
<ah-[m]>
cable #3 with usb-c to usb-c, still no luck :)
<ah-[m]>
doesn't even consistently accept its address now
<sven>
just to make sure, did you reboot the m1 between trying each cable?
<immychan[m]>
I had to uninstall Asashi, I deleted all of the partitions it generated, just to verify this means that my system is back to stock right? There’s no security features that I need to re-enable?
<ah-[m]>
yep, push the power button for a few seconds and the chime comes on when it boots, should I reboot it harder?