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
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
bmrgz has joined #asahi
bmrgz has quit []
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
yuyichao_ has quit [Ping timeout: 480 seconds]
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
darkapex2 has joined #asahi
darkapex1 has quit [Ping timeout: 480 seconds]
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
phiologe has joined #asahi
kgarrington has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
kgarrington has quit [Remote host closed the connection]
<marcan>
also this makes me realize I'm pushing ~4 write32s per millisecond, blocking
<marcan>
considering USB2 has 8 microframes per millisecond, that looks like m1n1 proxyclient is already pretty much as fast as possible
yuyichao_ has quit [Ping timeout: 480 seconds]
pg12 has joined #asahi
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
yuyichao_ has joined #asahi
<landscape15[m]>
marcan: what about USB3.0? Is there a sort kind of driver?
<marcan>
m1n1 will probably never support USB3.0
<marcan>
there's little point
<sven>
usb 3 requires a whole bunch of magic register pokes. from what I can tell that‘s only going to be annoying
<sven>
(and maybe tunables)
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
<landscape15[m]>
sven: yeah i know it’s pain. Is the main problem XHCI support?
<sven>
no
<sven>
it’s literally on the PHY that needs to be brought up
<as400>
mps: fresh Arch install here running from internal nvme on t6000-314s - FF is ok. Chromium segfaults on start.
<marcan>
I think that's a GPU thing
<marcan>
that's my guess anyway, need to look into it
<as400>
marcan: is gpu acceleration enabled by default in Chromium aarch64 ?
<marcan>
I assume it is
<kettenis>
chromium works on openbsd ;)
<marcan>
it should be trying to use llvmpipe, but who knows what goes wrong
<marcan>
feel free to debug it :p
<landscape15[m]>
as400: why not Firefox?
<as400>
landscape15: I'm perfectly ok with FF. Have no problem with it. But, for instance, for work I have to use Ungoogled-Chromium. Otherwise shitty ms teams won't work.
<as400>
Can't tell how much I hate this.
<mps>
as400: nice to hear, which kernel you use
<marcan>
also: during today's stream I managed to toggle all GPIO register bits by accident, and I didn't seem to cause any permanent damage
<marcan>
that's a good sign for the reliability of these machines :p
<j_ey>
marcan: that was a lil scary
<marcan>
(it did crash USB-PD though)
<as400>
mps: asahi branch
<mps>
as400: so, internal keyboard doesn't work?
<marcan>
j_ey: even if you cause pin contention, modern silicon is quite resilient to shorts and such
<as400>
marcan: it seems these machines are really good piece of engineering.
<as400>
mps: it wouldn't work anyway - I have t6000.
<kettenis>
that's what glxinfo tells me on openbsd
<mps>
as400: aha, I would try to free one of ssd disks and install on it fresh FS and check
<marcan>
it's also possible it's literally a bug somewhere
<marcan>
the M1 speculates like crazy and is really good at bringing out memory ordering and concurrency bugs
<landscape15[m]>
marcan: it’s good to see from your streams that most of the work is put inside m1n1. future-proof, and less dependent on the OS you run.
<marcan>
it's an experimentation platform; the whole point is to test stuff outside an OS interactively
<marcan>
I basically never rebooted during the SPI thing; once I started wedging the hardware I just started using the PMGR reset bit to reset it on every test run
<j_ey>
landscape15[m]: just to be clear, the code from today isnt in m1n1, its in the python scripts, that code will be rewritten in C for the kernel driver
<landscape15[m]>
j_ey: yes I know. But are you sure a simple rewrite is needed to get a fully-working driver?
<j_ey>
I meant using the knowledge gained from python script, to write the driver!
<landscape15[m]>
ok sorry ;) surely it’s easier to write proper drivers using m1n1.
maennich has quit [Remote host closed the connection]
Ariadne has quit [Read error: Connection reset by peer]
maennich has joined #asahi
Ariadne has joined #asahi
jkm has quit [Quit: leaving]
<as400>
marcan: problem resolved - when I compiled kernel with 4k pages both start: FF and Chromium.
<as400>
mps: do this and FF should work
<j_ey>
as400: ouch!
<mps>
as400: hah, interesting
<as400>
yeah - I've seen it before on rk3399
<mps>
I always compiled kernels with 4K pages but with 16K for m1
<mps>
will test when finish $day_job
<as400>
well, that's how todays browsers are
<as400>
they're overcomplicated
<j_ey>
as400: rk3399 shouldnt support 16K pages though?
<as400>
Why ?
<j_ey>
neither cortex-a72 or cortex-a53 do
<as400>
ok - there was a guy on irc that claimed that he did compile a 16k kernel and browsers refused to start.