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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
cdesai is now known as ircdesai
ircdesai has quit [Quit: ircdesai]
cdesai has joined #asahi
cdesai is now known as ircdesai
tertu has quit [Ping timeout: 480 seconds]
ircdesai is now known as cdesai
cdesai has quit []
ircdesai has joined #asahi
ircdesai is now known as cdesai
cdesai is now known as ircdesai
ircdesai has quit []
ircdesai has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
<emilazy>
dunno, but i could believe it
marvin24 has joined #asahi
<marcan>
in principle "everything" is in scopre, but it's unlikely we'll ever get to do all the userspace work that isn't done yet, so we do kind of depend on the overall state of these things in Linux moving forward on its own too
<marcan>
I'm happy to fix bugs or implement missing tidbits in random userspace packages though, once everything else is done... but that'll take a while :)
<marcan>
(re HDR and such)
<marcan>
ah-[m], sven: the next step for the hypervisor is starting to build modular hw-specific tracing bits that hook into the mmiotrace subsystem
<marcan>
so a SEP one would dump all the SEP commands and parse them to the extent we understand them, etc
marvin24_ has quit [Ping timeout: 480 seconds]
randomdud has joined #asahi
bgb_ has quit [Quit: WeeChat 3.0.1]
bgb has joined #asahi
randomdud has quit [Remote host closed the connection]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
VinDuv has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
<Emantor>
FYI, my USB serial connection was dropping out with a 3.2 Gen 2 (10GBit/s) C-to-C cable, switching to a USB A to C with an older USB 2.0 hub fixed that.
tsida has quit [Remote host closed the connection]
<dottedmag>
Required formats are argb8888 and xrgb8888, but compositors expose more formats. It's up to clients to make use of them.
VinDuv has quit [Quit: Leaving.]
<kettenis_>
Emantor: wonder if that is because m1n1 isn't doing some of the PHY tuning at the moment
<sven>
Emantor: interesting. i use a 3.2 gen 2 c-to-c cable as well and i never had issues like that. is that on a mac mini?
<sven>
i was hoping to only need the tunable and all that for usb > 2 but who knows
<Emantor>
Second port is the USB-C port on an Asus X370 Pro Ryzen motherboard.
<Emantor>
and target mac is a mini
<sven>
did you see anything in dmesg or some debug prints from m1n1?
<Emantor>
nothing on the dmesg side, no debug prints on the fb, don't know about the debug uart, since I don't have the necessary hardware to use it yet.
<_jannau_>
USB C-C cable works fine for me to the USB-C port of a thinkpad thunderbolt docking station
<sven>
they should've shown up on the fb console fwiw
<marcan>
arnd, maz: chances of arm64 linux ever getting universal page size builds? :-)
<marcan>
Emantor: does it show up as a SuperSpeed or a High Speed device?
<marcan>
I assume the latter, in which case the SS lanes should not matter...
<marcan>
UART receive timing out etc usually means m1n1 crashed
<marcan>
when that happens the device controller stays up, but it won't reply to any USB transactions
<marcan>
especially if e.g. echo 1 > /dev/ttyACM0 hangs
<Emantor>
yep, high speed.
<marcan>
you can try changing the iodev code at the top of iodev_console_write to use IODEV_FB instead of IODEV_UART as the fallback reentrancy path
<marcan>
that should let you see exceptions that happen *during* USB code on the framebuffer
<maz>
marcan: no, that's way to hard. you'd have to assume 64kB for all page alignments, turn the VA range into something dynamic... you'd be better off having 3 kernels, compiled for each page size, and get the bootloader to pick the one you want.
<marcan>
maz: figures...
<maz>
which obviously would be 16kB for M1 thanks to the DART limitation...
<marcan>
this is unfortunate for people who want to use distro kernels
<maz>
yeah, this is a total bummer.
<maz>
we *may* be able to do something in the DMA layer to just map all memory in the PCI DARTs and treat it as a bus offset.
<maz>
(alpha style).
<marcan>
I... really don't want to enable thunderbolt like that
<marcan>
that's almost worse than it just not working
<maz>
then 16kB it has to be. we can't have different granularities between MMU and IOMMU.
tsida has joined #asahi
<maz>
which means no distro kernels for M1.
<maz>
(or a M1-specific distro).
<marcan>
well, we could convince distros to at least ship these kernels
<marcan>
it's not like it's a custom fork, just a config change
<marcan>
they already like to ship a bunch of kernel variants anyway
* Emantor
needs to really disable the chime
<maz>
sure. it just doubles the number of kernels to ship, and the size of the validation space.
<maz>
Emantor: dremel?
<Emantor>
With USB-C I get "usb-dwc3@382280000: unsupported SETUP packet".
<marcan>
ha.
* Emantor
has watched enough streams that the ha sounds exaclty like marcan in his head.
<marcan>
Emantor: modprobe usbmon && usbmon -i usb1 (or whatever your bus number is)
<marcan>
(much easier than making m1n1 dump it all out)
<marcan>
that just means we're missing some standard request (we're missing a bunch)
<pinskia>
I missed that M1 requires 16k page sizes. The last time I tested 16k pages sizes in arm Linux (long time ago) on the Cavium ThunderX1, it failed if there was more than 32G installed. I don't know if this was solved yet.
<pinskia>
I should say arm64 Linux
<marcan>
pinskia: the CPU does not, but the IOMMU does (apparently)
<pinskia>
I always wondered why ARM added 16k page size to the spec as a (late) optional feature and I guess Apple is the answer
<marcan>
but it got an EPIPE on a bulk in, that's weird
<marcan>
Emantor: it looks like you're looping back on the port?
<marcan>
like you have the tty in cooked mode or something, though that shouldn't *break* things
<marcan>
I think the set feature thing is a red herring, it's trying to clear the endpoint stall after it happens
<arnd>
Ubuntu started shipping 64KB page kernels in addition to 4KB, so maybe they would add a third one as well
<arnd>
I can also imagine running a 4KB page kernel on M1, as long as that rules out connecting arbitrary devices on thunderbolt. For the internal devices it's no worse than any of the other chips that have no usable IOMMU at all
<Emantor>
marcan: I assume its something on the Linux USB side, I also got dmesg errors this time. Switching from C-to-C to C-to-A also moves to a different port with basically no other device on the port.
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi
kettenis_ has quit [Ping timeout: 480 seconds]
robinp_ has joined #asahi
<marcan>
Emantor: pushed some changes, let me know if they improve things
<marcan>
but also paste any dmesg errors please
<j_ey>
marcan: CI failed :<
<marcan>
ugh
<marcan>
fixed
robinp has quit [Ping timeout: 480 seconds]
<Emantor>
still borked, dmesg has xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 4. I found some older LKML threads with issues on isochrounous transfers on intel XHCI ports, the port with USB-C has isochrounous transfers from my USB sound card, the USB-A port does not.
<marcan>
that sounds like a host bug, yeah
eta has quit [Quit: Gateway shutdown]
bih420 has joined #asahi
<maz>
pinskia: yeah, this was added at the last minute (right *after* the arch was frozen) at the request of particular vendor, which explains the very bizarre encoding in ID_AA64_MMFR0_EL1.
<Emantor>
/* HC is busted, give up! */ is above the xhci_err line in the kernel (:
eta has joined #asahi
<bih420>
Hello I am new here, I want to try m1n1 (bootloader) on my mac mini m1 (256gb storage, 16gb ram), I only have 1 m1 hardware with other are amd64(x86_64) machines. I don't have any Arduino (but rpi3), is there any way to try m1n1 on my current situtation or should I wait (lockdown in my country). is there any alternative for meantime I have USB C to USB A cabel(it is usb3) (from pixel 1
<bih420>
box). Thanks, If I break any rules Please pardon me.
bih420 has quit [Read error: Connection reset by peer]
<jn>
ah, bih420 left already :(
<pinskia>
@maz I do know that Cavium was the one of the drivers for LSE and v8.1
<pinskia>
and the reason why CRC is an optional feature of ARMv8.0 was because xgene's core was completed before crc was added to the spec too
bih420 has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bisko has joined #asahi
<pinskia>
Also I don't know how many cores implement 16k pagesize;is it still an optional feature, I have not looked into the spec in this area in the last 3 or so years
<maz>
pinskia: they completely fucked the v8.1 stuff in all TX1 implementations.
<pinskia>
yes I know
<pinskia>
I debugged a lot of it
<maz>
so did I, and then thrown the box again! :D
<pinskia>
casp was the biggest thing they fucked up
<pinskia>
well and VHE
<maz>
well, they alsi ignored the requirement for ASIDs at EL2 with VHE...
<maz>
and the GICv3 virtualisation that allowed the guest to remove all interrupts from the host...
<pinskia>
let me go look up the errata from the bug database
<arnd>
pinskia: out of the Cortex cores, it seems that all cores starting with A73/A35 support all three granules (4K, 16KB, 64KB), just not the very earliest ones (A57, A53, A72) that are limited to 4KB and 64KB
pcm720_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<pinskia>
DC ZVA was broken too in ThunderX1 but was not found out until much latter when debugging OcteonTX2 (96xx) where a GCC bootstrap was failing; tar would produce a corrupt file. That was one of the easier bugs to debug really
pcm720 has joined #asahi
<pinskia>
The harder bugs have been global TLBI related and/or interrupt related
ake_ has joined #asahi
PeterHilgenfeld[m] has joined #asahi
<ake_>
It seems that /dev/cu.usbmodemP_01 on macOS is equivalent to /dev/ttyACM0 on Linux.
<ake_>
It might be useful for those who use Mac Mini M1 as a host.
ake_ has left #asahi [Leaving]
ake_ has joined #asahi
ake_ has quit [Quit: Leaving]
bgb has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gladiac has joined #asahi
bih420 has quit [Quit: WeeChat 3.1]
peace has joined #asahi
ircdesai is now known as desairc
desairc is now known as cdesai
cdesai is now known as desairc
desairc is now known as cdesai
cdesai is now known as desairc
desairc has quit [Quit: desairc]
desairc has joined #asahi
tsida has quit [Remote host closed the connection]
<eta>
marcan, you transcribe directly into Ardour?
<marcan>
this one I did
<marcan>
depends on what I'm doing
<eta>
huh
<j_ey>
hm?
<eta>
my limited experience with the Ardour MIDI editor is that it's not very nice to use >_>
<eta>
so I generally use musescore for transcription and then pipe the MIDI into Ardour later
<marcan>
I find ardour a lot more efficient to input notes than musescore, lol
<eta>
well if you know what the notes are in advance, sure
<marcan>
but that may just be because I don't find music notation particularly intuitive compared to piano roll, when I'm just going to from sound to midi
<eta>
I'm bad at transcribing so I have to press up/down a lot until the pitches match :p
<marcan>
but also, ardour midi has gotten a lot better, if you're used to old versions
<marcan>
I also transcribed the chords to the song, but I just did that in a text editor :p
<eta>
my music-fu is way too bad to know how to chords
<eta>
I should try the ardour midi again though
<marcan>
the only annoying thing is still the rounding errors (e.g. snapping a region to a bar has a 50/50 chance of eating notes that start on that bar) but that's been a long-coming fix in the nutempo branch
<marcan>
hope they finally merge it this year
<marcan>
(I just pad my regions)
<eta>
yeah I've had that
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
peace has quit []
robinp has joined #asahi
robinp_ has quit [Ping timeout: 480 seconds]
hir0pro has joined #asahi
VinDuv has joined #asahi
Dt3 has joined #asahi
Glanzmann has joined #asahi
<Glanzmann>
marcan: Can be put a hint on https://asahilinux.org/community/ that it requires that you connect to irc.oftc.net using tls in order to join the channels? And congrats on getting macos run inside the m1n1 hypervisor. :-)
<marcan>
I think we can drop that now
<marcan>
that was an antispam measure
<Glanzmann>
OIC>
<Emantor>
I ams tarting to wonder how to build a kernel collection using the development kernel. Apple docs are not exactly helpful…
<marcan>
look at the unofficial blog by apple employees about building custom m1 kernels
<marcan>
that's what I used to make the one I'm using in the HV
<marcan>
(except just using the dev kernel, not a custom build)
Dot has quit [Ping timeout: 480 seconds]
<Emantor>
Ha, I wasn't too far off, but this is still weird. oh well. Thanks.
<ar>
marcan: what we now need is to get onto some weird timeline where apple devs start using m1n1 for macos development ;)
<sven>
i sure hope they have jtag/swd :D
<sven>
but i could totally see some third party kexts devs using the hv as a nicer debugger
<marcan>
ar: apple devs are already using our documentation because it's better than theirs in at least some use cases, I hear
<marcan>
:-)
<ar>
marcan: from what i've heard about how apple operates, i wouldn't be surprised if the better/more accurate docs weren't available to all teams
<marcan>
exactly
<marcan>
in particular I think our Codenames page is particularly convenient :-)
<marcan>
going by xnu build scripts, there's some, uh, mysql database or something they use that contains that kind of info? and it's no doubt only accessible by some people
<marcan>
and probably only a subset
<marcan>
sven: I was just talking with a security reporter and I mentioned asahi and he was like "I guess I need a security angle" and I mentioned how I'm sure kernel vuln researchers will *love* the HV
<sven>
lol, yeah
desairc is now known as cdesai
cdesai is now known as desairc
desairc is now known as cdesai
cdesai is now known as desairc
choozy has joined #asahi
pcm720 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
pcm720 has joined #asahi
pugguu has joined #asahi
choozy has quit [Ping timeout: 480 seconds]
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pcm720 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
thunfisch has quit [Remote host closed the connection]
pcm720 has joined #asahi
thunfisch has joined #asahi
VinDuv has quit [Quit: Leaving.]
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
VinDuv has joined #asahi
<kettenis>
David Gwynne and Jonathan Matthew wrote a driver for the NVMe controller for OpenBSD
<kettenis>
and I just fixed the last critical bug
<kettenis>
so I can now access the NVMe disk
<kettenis>
guess I need to repartition the disk now
zopieux has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
<sven>
nice!
jkkm has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
chipuba has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
chipuba has left #asahi [#asahi]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
hir0pro has quit [Ping timeout: 480 seconds]
SunWuKung has joined #asahi
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
yuyichao has joined #asahi
VinDuv has quit [Quit: Leaving.]
<yuyichao>
got a m1 (pro 8G 256G) ahead of plan (graduation gift) so I'm trying to follow the wiki on it and I've got a few feedbacks/questions.
<yuyichao>
2) on my archlinux x64 host, I got both ttyACM0 and ttyACM1 when m1n1 boots ACM0 seems to work, is that expected?
<yuyichao>
3) both ttyACM0 and ttyACM1 disappears when the usb cable was disconnected (as expected) and either shows up again when the cable is plugged back in without rebooting m1n1
<yuyichao>
4) is there a way to talk to linux booted through linux.py using only a usb cable? https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart suggests `/dev/ttyUSB0` bit I couldn't figure out what exactly it should be/if it needs other hardware connection to work
<yuyichao>
(hope this is the correct channel to ask.....)
<jannau>
1) I guess it's safer to use the dtb from the kernel (arch/arm64/boot/dts/apple/t8103-j274.dtb) and not the one from m1n1
<jannau>
2) yes, we added a second cdc acm interface
<jannau>
3) I assume you mean neither. yes, there is no usb connection management in m1n1
<yuyichao>
do both cdc acm interface do the same thing?
<jannau>
no, the second one is intended for use as virtual uart for the hypervisor
<yuyichao>
yeah i meant "neither". k. that's fine, I just unplugged it to figure out which one it is (and both disappeared so I was quite confused....)
<sven>
it's not about connection management
<sven>
replugging also doesn't work with the linux dwc3 driver
<sven>
there's something going on with the PHY that we don't know yet
<yuyichao>
do you mean it's a host side problem? (not sure what each name refers to ....)
<jannau>
interaction with linux requires currently the serial. does the usb cdc gadget already work with the dart/dwc3 usb changes
<yuyichao>
ah, ok. I somehow read "USB gadget support is not yet in our main Linux tree" as "not yet in mainline linux tree" = = .... and thought that it was in the fork ....
<jannau>
it is a problem how m1n1 and linux interact with the m1 usb-c hardware