marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | 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
rohin has joined #asahi
jmr has joined #asahi
jmr has left #asahi [#asahi]
jmr2 has joined #asahi
zopieux has quit [Quit: zopieux]
zopieux has joined #asahi
<jmr2>
alyssa: I might be able to assist with testing on a MB Air as well - although I only have installed m1n1 so far.
<jmr2>
By the way, is it possible to use a USB 2.0 stick connected through a USB-C hub for rootfs? Or adapters only for now ?
zopieux has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
jmr2 has quit [Remote host closed the connection]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi
<alyssa>
USB 2.0 over USB-C works fine for rootfs, indeed that was my setup for july tweet
jmr2 has joined #asahi
<jmr2>
Excellent. Thanks for the confirmation.
thunfisch has quit [Remote host closed the connection]
thunfisch has joined #asahi
jmr2 has quit [Quit: Page closed]
<alyssa>
sure
<chadmed>
damn i wish i could upload images so you could see my reaction to the insinuation that C is better than Python for GUI programming :P
<psykose>
links to images work
phiologe has joined #asahi
<marcan>
_alice: the installer will do the distro install for you, the rootfs image way (which is popular these days anyway, see e.g. ALARM itself)
<marcan>
I just need to work out some firstboot script to copy the wifi firmware and resize the ext2fs, though we might be able to just bundle resize2fs built for mac with the installer to take care of that
<alicela1n>
what will the default distro be like
<marcan>
whatever people want to maintain; I'm going to maintain ALARM
<marcan>
there's no "default" other than, er, whatever order we show them in
PhilippvK has quit [Ping timeout: 480 seconds]
BlitzWorks has quit [Ping timeout: 480 seconds]
jmr2 has joined #asahi
<kode54>
spamming offtopic with my wonderful troubles with not-Asahi and gaming while also in video calls
<chadmed>
im still trying to think of the most easily maintainable way to have a luser-proof gentoo install for these macs. im leaning towards a shell script that just grabs the latest stage3 and sets up a m1n1->uboot->grub boot chain but idk... seems a little convoluted
nobodynada has quit [Quit: Lost terminal]
<chadmed>
i just like that way because it just abstracts away the mac-specific boot stuff and lets people follow the handbook pretty much word-for-word. assuming youd never want/need to update m1n1 or u-boot, you could treat the system in almost exactly the same way as any amd64 machine now
<chadmed>
plus we could just have a shell script that updates m1n1/u-boot from 1TR should it become necessary
nobodynada has joined #asahi
<marcan>
chadmed: why not just do what we do for all the other distros and use an image?
<marcan>
stage3 is an image after all, the script just automates the partitioning, then you can follow the handbook from first boot
<marcan>
the installer will have an "update my m1n1 please" option
<chadmed>
well yeah i just meant use the stage3 as the image, rather than something like the genpi image where you get a ready-to-go system
<marcan>
well yeah, it's gentoo, I'm assuming users will know what they're doing and know how to install the rest
<chadmed>
the latter just doesnt seem to be in the spirit of gentoo imo
<chadmed>
yeah that
<marcan>
for arch I'm going to do both a barebones ALARM image (same spirit) and a proper desktop
<marcan>
so people can choose
<marcan>
it would also be neat to have a "firstboot" style wizard like the macos one, so people can set up their own login/password instead of having to change a default
<chadmed>
you could implement that as an init service that destroys itself after the first boot, theres a few SBC images that do similar things
<marcan>
for a desktop thing I might end up writing something (in Qt or PyQt maybe?) if I find some time
<marcan>
all this is going to need buildboxes, I'm looking forward to making a little cluster of M1X Mac Minis ;)
marvin24 has joined #asahi
<chadmed>
yeesh that piwiz code hurts to look at
marvin24_ has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
<jmr2>
Ouch... I'm rusty... Downloading a kernel tree through github's "Download zip archive" is NOT faster than git clone... because that destroys symliinks. The 2nd error is fixed (I manually recreated some links). Still waiting for git clone to see if it fixed the 1st one too.
yuyichao has joined #asahi
<chadmed>
add --depth=1 to the clone command if youre only interested in building the kernel and wont need to walk down the repo at any point. speeds up the download significantly and doesnt break any symlinks
<chadmed>
do not do this if for any reason you will need to revise commits older than the most recent for each file
<jmr2>
Thanks. Too late for this time, but I'll remember it.
<jmr2>
marcan: not sure if this one exists in your tree or not (I'm still on Alyssa's): drivers/soc/apple/apple-pmgr-pwrstate.c:101:6: warning: unused variable ‘ret’
<jmr2>
alyssa: Confirmed - I still have the 1st set of errors. Fixing the symlinks only fixed the second.
jmr2 has quit [Quit: Page closed]
rohin has quit [Quit: Konversation terminated!]
<chadmed>
are there any distros that dont ship with python by default anymore?
Glanzmann has joined #asahi
<Glanzmann>
I'm taking care of Debian, if noone else who is better suited wants to do it. ;-)
<Glanzmann>
Installer Distribution wise.
<psykose>
alpine doesn't
<chadmed>
what init does alpine use
<psykose>
openrc
<psykose>
eventually s6 in like 2 years
<chadmed>
noooooooo aahahah i was trying to write a generalised openrc firstboot to do roughly the same thing that systemd-firstboot does
<psykose>
planned to use python? :p
<chadmed>
oh well whoever maintains the alpine rootfs image can just add python to it
<chadmed>
not only did i plan to use python, im basically 80% of the way done writing the thing using python :P
<psykose>
by rootfs image you mean the installer/etc images?
<psykose>
an init.d service can use whatever you want it to
<psykose>
but python will probably not be in any base image
<psykose>
so... probably won't work on alpine then for firstboot ( i just now read what it is )
<chadmed>
yeah so marcan's idea was to have a barebones/desktop rootfs image for each distro people want to maintain such that the asahi installer script can just extract that to the root partition which is a popular way of "installing" distros on other ARM SBCs
<chadmed>
so i guess if someone wants to maintain an alpine image for that, they can just have python included with it which isnt any trouble
<psykose>
if it's not a normal rootfs image, and needs user customisation, then if there is a maintainer that wants to maintain one with python in it for alpine-rootfs-m1 it should be fine
<psykose>
ype
<psykose>
yep*
nobodynada has quit [Quit: Lost terminal]
<psykose>
it's third party after all :) upstream won't care
<chadmed>
what im doing isnt really even entirely necessary, its just a nice-to-have for new users who might not be comfortable being dumped to a shell with the expectation that they just know a priori that they have to change the default root pw and/or delete the default local user that is usually set up on these ARM images
<chadmed>
i likely wont even use it myself :P
<psykose>
makes sense :)
<psykose>
doesn't sound like a bad idea at all
<chadmed>
eventually i think marcan wants to write one in Qt to mimic the macos firstboot for desktop images which is a nice idea. uni is a few weeks from finishing here so i will have a few months free to brush up on my C++ and maybe help out with that too
confusom1 has quit [Remote host closed the connection]
<chadmed>
when i get some free time im gonna port it to C so that it works on all openrc distros without depending on python. its not like it does anything that depends on python anyway
<sorear>
the installer is in python so it needs python available in the macOS/1TR environment where it runs, if I've understood correctly. I don't think it matters whether there is also a copy of python in the installed distro, since the installer doesn't run there?
<chadmed>
this will be run on the first boot of the linux environment though, not from 1TR with the installer
<chadmed>
its broken anyway, useradd doesnt like being called
<chadmed>
nvm fixed it by using os.system instead of subprocess.call
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
chadmed has quit []
chadmed has joined #asahi
chadmed has quit []
chadmed has joined #asahi
<chadmed>
ok it now works fully
bps has joined #asahi
<Glanzmann>
chadmed: Nice.
<chadmed>
working on a C port now just to reduce external dependencies
<psykose>
alpine doesn't have useradd either by default :)
<psykose>
just adduser/addgroup from busybox
<chadmed>
aaaaa youre killing me
<chadmed>
well its MIT licensed so whoever wants to make it work with alpine can do so
<psykose>
:p don't mean to spoil the fun
<psykose>
it's an `apk add shadow` away anyway
* povik
is looking into setting up a m1n1+petitboot boot chain
<povik>
for subjective aesthetic reasons
<maz>
povik: good luck with petitboot. we can't support kexec on M1 for now.
<povik>
really? i thought that works
<maz>
no
<povik>
:(
<maz>
it requires PSCI support, which requires a more privileged exception level. No EL3, no PSCI, no kexec.
<maz>
you *could* have it under m1n1's hv though.
<povik>
that goes over my head
<maz>
but as far as bare metal is concerned, no way.
<povik>
well i guess it's back to working on audio then
<j_ey>
huh, wasnt pipcet[m] using kexec..
<povik>
yeah but he's using some frankenstein of corellium and asahi kernel AFAICT
<j_ey>
yes but that has no EL3 either :P
<povik>
good point
<maz>
do make that work, you'd need the kind of SMP ops that we had on 32bit so that platform can bring their own SMP bring-up crap.
<maz>
sdo/to/
<maz>
Ard had an idea to implement this un EFI, but that's a long way away.
<maz>
in*
<sven>
j_ey: i think he only brought up the other cores in the final kernel he loads
<maz>
sven: so *that* would have a chance of working.
<j_ey>
sven: they also added "cpu_operations cpu_apple_start_ops"
<j_ey>
which might be the SMP ops maz mentioned?
<sven>
all i remember is that it wasn't very pretty
<maz>
j_ey: that. it has NAK written all over it.
<j_ey>
but maybe the CPU nodes in the dt can be 'disabled' for petitoboot
<kettenis>
petitboot also sucks if you try to boot something that isn't linux
<ar>
but why would you want to boot something that isn't linux? ;)
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
<psykose>
freebsd supports it no? :p
<kettenis>
I believe so; they support powernv and that means petitboot must be in the loop somehow
<kettenis>
I implemented support for OpenBSD/powerpc64; basically ended up booting a special "bootloader" kernel that loads the final kernel through its own "kexec" implementation
<kettenis>
the ELF parser in the kexec tools shipped with the stabdard firmware images is seriously broken though
<kettenis>
working around that was fun (not)
<povik>
seems it may just work if the spin table set by m1n1 makes it all the way to the final kernel undepleted
<povik>
if this doesnt require any hacks in the final kernel then i am happy
Retr0id3 has joined #asahi
Retr0id has quit [Remote host closed the connection]
gabuscus_ has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
gabuscus has joined #asahi
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
X-Scale has quit [Ping timeout: 480 seconds]
X-Scale has joined #asahi
<kov>
I installed m1n1 using the installer on my macbook air; I built m1n1 and linux on my Fedora VM, copied things over to my mac mini and tried to chainload m1n1, it went wrong, any ideas? http://paste.debian.net/1215497/
<povik>
i dont know whether running the proxyclient scripts under macos is tested
<povik>
could be there are some differences in configuring the serial port
<sven>
i used from exclusively from macos
<sven>
*use
<povik>
okay
<povik>
so that should work
<sven>
that's an serror, so something went terribly wrong
<j_ey>
kov: what compiler did you use?
<j_ey>
to build m1n1
<povik>
oh right, there are m1n1 log lines there
<povik>
just skipped over those
<sven>
TTY> L2C_ERR_ADR: 0x301000a038c7ec0 <-- that looks strange
<kov>
j_ey, clang, I think m1n1's makefile wasn't happy I was running under aarch64 and tried to use a cross-gcc
<j_ey>
kov: use gcc, I had issues with m1n1 with clang too
<kov>
I guess I can try building m1n1 on my x86 laptop with gcc, that is probably the most tested setup
<sven>
ugh.. i think we added clang support early on but never tested it again
<j_ey>
sven: yep
<j_ey>
i got exceptions too, so switched back to gcc
<sven>
so i guess we should either fail to even build on clang or fix those :D
* kov
will try that later today
<j_ey>
fix them would be better, i guess its probably an issue in the code, rather than a clang issue
<sven>
last time one issue was that clang silently converted '\r' to 'r'
<sven>
but another issue was that the code didn't save some register before calling a function it should have saved iirc
<sven>
so fixing them is probably a good idea and might uncover other subtle bugs
<krbtgt>
oh god, another channel i'm on proposed doing an RYF M1 system. it almost sounds possible except for the fact iBoot loads only signed firmware for the coprocessors (tho you can choose wrt the Broadcom and SEP)
<krbtgt>
if someone figured out how to exploit the ROM stage iBoot, you could probably give a lot of free software enthuiasts aneurysms from libre macs
<alyssa>
krbtgt: no no no you can't touch the firmwares, you can just pretend they don't exist, that's ryf right?
<alyssa>
it worked for that laptop...
<krbtgt>
god i just "love" how purism made a mockery of the criteria and how dumb it is
nuh^ has joined #asahi
<krbtgt>
seal the proprietary software in a mask rom so you can't replace it with libre alternatives
yuyichao has quit [Ping timeout: 480 seconds]
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
<marcan>
krbtgt: it's not even a mask rom, in the end it was the same (updatable!) SPI flash that has the Type-C controller firmware (which is *another* blob)
<marcan>
it's just they use a secondary CPU to *load* it, so as long as you don't give cooties to the main CPU by touching it from there, it's fine!
<marcan>
I guess then the second CPU is tainted and can never be used by Libre software though
<marcan>
but the loader code is Libre
<krbtgt>
god what a joke
<marcan>
so maybe we do indeed have a case of infinite libre poisoning recursion
<marcan>
fun fact: that thing has the same line of PD controllers as the M1 Macs
<krbtgt>
maybe you could rules lawyer the existing M1 setup as RYFable, considering the mockery of the rules, and the fact apple's system is arguablly pretty close to being there
<krbtgt>
of any mainstream system at least
<marcan>
you'd have to rules lawyer all the boot stuff into somehow counting as a ROM
<marcan>
maybe we can hack the ANS2 into only exposing the Linux partition to the OS
<marcan>
then you wouldn't see all the iBoot stuff from there
<sven>
lol
<krbtgt>
Respects Your Fear
<alyssa>
💯
<marcan>
kov: please run addr2line -pf -e build/m1n1.elf 0x1d6b4
<marcan>
I should add that to the exception dump screen
<marcan>
though that exception isn't precise so that may or may not end up being useful
<marcan>
ah wait, that's the m1n1 from the installer
<marcan>
and you used the mrcn.st/alxsh installer?
<marcan>
or your own build?
<marcan>
if it's your own build it'd make sense
<kov>
my own build, yeah, I'll do a reinstall with mrcn.st/alxsh then!
<marcan>
what compiler are you using
<marcan>
try replacing compressed_writemem with writemem in chainload.py and see if that fixes things
<marcan>
I get the feeling your build broke gzip decoding somehow, maybe there's something dodgy there or a compiler issue?
<marcan>
if you send me the binary I can try to reproduce here :)
<kov>
marcan, let me try that, I am coming to the conclusion that my issue is basically me trying to use my Fedora VM on the M1 for my builds heh, I'll do everything from my x86 laptop
<marcan>
well... it *should* work with a native compiler
<marcan>
it's entirely possible there's some undefined behavior in tinf or something like that
<marcan>
so I'd quite like to figure out what's up with that :)
<kov>
let me try the change to chainload.py and I'll get the binaries all packaged up and put them somewhere after that
<j_ey>
marcan: try build with clang, if you have clang
<marcan>
also can you addr2line 0x27fc0 ?
<marcan>
incidentally, with the uncommitted m1n1 changes I have here that SError would at least turn into a precise data abort :)
<kov>
marcan, with iface.writemem I get an error because m1n1 wants to call aarch64-linux-gnu-gcc which I don't have on my macos, weird
<kov>
marcan, you want add2line 0x27fc0 on the m1n1 I'm trying to chainload or the one from the installer? I think the one from the installer is downloaded pre-built?
<marcan>
though I probably just broke dcp.py and other things :-)
<kov>
I would have to install that new m1n1 I am guessing or could I chainload it?
<marcan>
you could chainload it without the tinf stuff, but you still need to figure out the compiler issue there
<kov>
yeah, ok
<marcan>
(that won't change regardless)
<kov>
got a call in 5, I guess I'll just do a rebuild and reinstall after that and lunch, then
<marcan>
I wonder if I can somehow figure out the proper top of mem boundary where things are unmapped, not just what the boot args says is the top of normal RAM...
<marcan>
avoids having to manually map everything up there from now on
<kov>
(and maybe I just switch to using my x86 laptop for my testing for a bit as I really want to see the DCP and keyboard on this Air this weekend ;D)
_alice has quit [Quit: irc_error]
_alice has joined #asahi
_alice has quit []
_alice has joined #asahi
nuh^ has quit [Remote host closed the connection]
nuh^ has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
<marcan>
sven: umm... I can not only *read* the DCP firmware, I can *write* it too
<marcan>
and it works.
<marcan>
the only ASC range that is protected, that I can find, is the ANS2 thing in highmem
<sven>
hrm, so if the TZ0 registers are at the same location as on A13 it's at 0x9dcb1f000...0x9dad90000 on my machine i think
<povik>
ah, it serror's, then?
<marcan>
yeah
<marcan>
basically I'm trying to figure out what ranges SError, and avoid mapping *just* those
aleasto has joined #asahi
<marcan>
so far the best idea I have is "region-id-2, region-id-4, region-id-5" in the carveout map (that's ANS and the two SEP ones)... but I'm not sure if that's stable...
<sven>
you should be able to get ANS from the SART entries as well i think
<sven>
region-id-4 = [0x00000009DAD90000, 0x0000000001D90000] so that matches up with what i found above
<marcan>
do you see ANS around that reg range?
<sven>
marcan: so get the first SEP region 0x800000000+read32(0x2000006a0)<<12 is the start
<sven>
and 0x800000000+read32(0x2000006a4)<<12 the end i think
<sven>
6a0 is start, 6a4 is end and 6a8 is enable
<marcan>
>>> read32(0x2000006d0) << 12
<marcan>
0x1e6e64000
<marcan>
hmm
<marcan>
so that's ANS
<marcan>
tz3 I guess?
<sven>
i guess
<sven>
the registers are always START, END and then LOCK
<sven>
so if the third one isn't 1 you can actually reconfigure it. but they're all locked afaict
<marcan>
I guess this is arm-io/mcc.reg[1]
<sven>
so then i really don't understand why that DCP DART is locked anymore :/
<alyssa>
sven: locking DCP DART might be for robustness, not security?
<marcan>
sven: pushed a thing to unmap only the TZ regions
<sven>
how would that increase robustness?
<marcan>
now dcp.py works again
<alyssa>
sven: you said locking the DART locks almost all the registers (not just the ttbr one)?
<sven>
yes
<marcan>
sven: I bet it's locked because on some *other* platform, iPhone or whatever, this matters and the DCP firmware is locked
<marcan>
but not here
<marcan>
and it's just leftover
<sven>
marcan: hah, i can totally believe that
<alyssa>
sven: maybe the point was one of the other registers that gets locked, less opportunities for things to change under DCP's feet? shrug
<j_ey>
can apple give us a bug tracker so we can file issues
<sven>
alyssa: that doesn't make much sense tbh if we can overwrite the firmware as marcan figured out
<marcan>
kov: so if you want to update the m1n1 submodule in your installer and rebuild that (you can just copy it over and kmutil it, see what step2.sh does; no need to rerun the whole installer), that might fix the gzip decompression thing without breaking anything else
<marcan>
(hopefully)
<alyssa>
sven: I didn't say it was a /useful/ decision :-p
<sven>
i just don't think robustness makes any sense at all
<alyssa>
also don't discount the possibility of a hw/fw/sw bug somewhere
<alyssa>
or a "i set it to locked while debugging iBoot and forgot to unset it and nobody noticed because it makes 0 difference to XNU"
<alyssa>
or...
<sven>
xnu has special code to deal with this behavior
<sven>
and the DT has special entries to tell XNU where the pagetables are
<alyssa>
16:02 <@marcan> sven: I bet it's locked because on some *other* platform, iPhone or whatever, this matters and the DCP firmware is locked
<sven>
yeah, that i can agree with. all i'm saying is that "robustness" doesn't make any sense to me
<alyssa>
we know apple shares code between watchOS and macOS and everything in between, that special code could have made sense in the past and not now
<alyssa>
fair enough
<alyssa>
"robustness", in the way declaring things `const` in C is "robustness" ;-)
<alyssa>
(...Truly the DART lock is the moral equivalent of "const void *")
yuyichao has joined #asahi
<kov>
marcan, I can copy it to /Volumes/Linux and rerun step2.sh from there as well I guess?
<marcan>
yeah, that works, though you might need to diskutil umount / mount it since it'll probably be mounted readonly by the system
yuyichao_ has quit [Ping timeout: 480 seconds]
<kov>
marcan, got it
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
Nspace has joined #asahi
handlerug has quit [Remote host closed the connection]
handlerug has joined #asahi
handlerug has quit [Remote host closed the connection]
handlerug has joined #asahi
handlerug has quit [Remote host closed the connection]
handlerug has joined #asahi
handlerug has quit [Remote host closed the connection]
handlerug has joined #asahi
handlerug has quit [Remote host closed the connection]
handlerug has joined #asahi
bps has quit [Ping timeout: 480 seconds]
Raqbit4 has joined #asahi
Raqbit has quit [Ping timeout: 480 seconds]
Raqbit4 is now known as Raqbit
<kov>
marcan, j_ey, sven so I installed the newly built (with clang on aarch64 linux) m1n1, and managed to chainload the macos cross-built with gcc m1n1
<kov>
had to symlink all files to "remove" the -unknown part
<kov>
interestingly the clang built m1n1 does not chainload, the air goes to the apple logo and the proxy client times out waiting
<marcan>
kov: interesting, mind sending me the binary? wonder if we're running into some other silliness
Nspace has quit [Quit: Nspace]
<marcan>
I'm going to sleep now though, will look tomorrow :)
<kov>
marcan, sure, is email ok for that?
<marcan>
sure
<marcan>
marcan@marcan.st
<kov>
marcan, k, good night o/
thunfisch is now known as Guest3025
Nspace has joined #asahi
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi
rohin has joined #asahi
Nspace has quit [Quit: Nspace]
Nspace has joined #asahi
yuyichao has joined #asahi
gladiac is now known as Guest3035
gladiac has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
Guest3035 has quit [Ping timeout: 480 seconds]
DavideCavalca[m] has joined #asahi
DavideCavalca[m] is now known as dcavalca
dcavalca has quit []
dcavalca has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
rross101 has joined #asahi
<rross101>
Glanzmann: Your most recent instructions worked for me after a few days of slow progress. The mu-one kernel with patches got me usb keyboard or network access which I haven't had till now. I'm in the debian installer vs you copying a rootfs across - any cons to that? And not sure if I now can install onto a partition without overwriting m1n1? But mainly thanks for the help.
kenjigashu has joined #asahi
kenjigashu has quit []
kenjigashu has joined #asahi
kenjigashu has quit []
kenjigashu has joined #asahi
kenjigashu has quit []
marvin24 has joined #asahi
kenjigashu has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
kenjigashu has quit [Remote host closed the connection]
kenjigashu has joined #asahi
<alyssa>
hmmmm do I work on DCP or something else
marvin24_ has joined #asahi
<steev>
DCP
<jn>
this channel may provide slightly biased answers to this question :)
<alyssa>
jn: I mean there are M1 things I could be doing
<alyssa>
^other
<alyssa>
(other kernel drivers, AGX userspace..)
<jn>
hmm
marvin24 has quit [Ping timeout: 480 seconds]
jmr2 has joined #asahi
<alyssa>
Glanzmann: I have a patch "fixing" Xorg hotplug
<jmr2>
Glanzmann: success for me as well, on an MB Air. Thanks! I'm logged on the bookworm rootfs. My next step will be to get the wifi working.
<alyssa>
jmr2: eh?
<alyssa>
jmr2: Is this with the DCP branch?
<jmr2>
With your Oct 13 one.
<alyssa>
Ooh
<alyssa>
Good to know everything works on the macbooks as-is, the
<alyssa>
*then
<jmr2>
Anything specific you want me to check? At this time, I'm still on the text console (which is tiny at that resolution...)
<alyssa>
paste `dmesg` output? :)
<alyssa>
also, # apt install weston, $ weston, open a terminal and move it around, there should be 0 tearing
<jmr2>
Sure. Will take a few minutes. I'll be back.
<alyssa>
thanks!
<jmr2>
No apt install, no networking yet.
<alyssa>
as for wi-fi, I mean, the minimal kernel side is in that branch
<alyssa>
though idk how much I recommend its use
<alyssa>
and you need to deal with firmware "fun"
<jmr2>
Yup. Just need to figure out the cpio part.
<alyssa>
(Read: Expect it to keep working since I'm testing it, but also don't expect me to help when it breaks 😉)
Nspace has quit [Quit: Nspace]
Nspace has joined #asahi
<jmr2>
Yeah. This channel could easily turn into a tech support one... Let me get your dmesg output.