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
klltkr has joined #asahi
klltkr has quit []
kettenis has quit [Ping timeout: 480 seconds]
Nspace has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]
<bgb_>
Emantor: following your SW:Hypervisor, got errors at step 5 : Error Domain=KMErrorDomain Code=71 "Could not find: kernel mach-o at kernel.development.t8101"
<Emantor>
bgb_: Are you inside the Kernels directory with the file present?
<bgb_>
ah, not! just tried again and works well. thanks
apinski has joined #asahi
pinskia has quit [Read error: Connection reset by peer]
apinski is now known as pinskia
apinski has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
pinskia has quit [Ping timeout: 480 seconds]
apinski is now known as pinskia
pinskia has quit [Remote host closed the connection]
pinskia has joined #asahi
VinDuv has joined #asahi
robinp_ is now known as robinp
aquijoule_ has joined #asahi
VinDuv has quit [Quit: Leaving.]
e9 has joined #asahi
emptynine has quit [Ping timeout: 480 seconds]
e9 is now known as emptynine
EER has joined #asahi
MagMell[m] has joined #asahi
<MagMell[m]>
Hi everyone, I tried to start the Linux kernel on my Mac mini M1 with m1n1, and I found that my init did not move after booting (the cursor was still moving)
riatre has quit [Read error: Connection reset by peer]
<Emantor>
MagMell[m]: AFAIK the framebuffer won't provide a login console, which wouldn't be useful anyway since the current kernel does not support USB yet, so no USB Keyboard.
<Emantor>
a console is only available on the debug UART on the left most USB port next to the power connector on the mac mini, which requires additional hardware.
<MingcongBai[m]>
<Emantor "As said above, please read https"> I understand that, but I just don't quite get the idea about how the login prompt "won't display," is the framebuffer unloaded at some point?
<Emantor>
It looks like there is no getty started on the FB VT.
<pipcet[m]>
no, or the cursor wouldn't blink.
<MingcongBai[m]>
<pipcet[m] "no, or the cursor wouldn't blink"> That's right, and I should probably clarify as well - we are only running an initrd, so no getty involved here
<MingcongBai[m]>
We were only trying to get to a shell via initrd, which has an init script as mentioned above
<marcan>
a getty wouldn't help you anyway without keyboard support
<svenpeter[m]>
Yeah, i just need to get pcie up and running with the Frankenstein device tree I have now and then I can hopefully also submit that upstream soonish
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<MingcongBai[m]>
<marcan "a getty wouldn't help you anyway"> True that
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
<MagMell[m]>
Hi everyone, I'd like to ask about the "USB gadget mode using a standard USB cable" message. It seems that I'm using a normal USB-C cable here to connect my ThinkPad X230 to the USB-C port on the Mac mini M1 closest to the power source. But I don't see any output from the X230's dmesg, is this not supported by m1n1 yet?
<kettenis>
svenpeter: I sent an update of the pcie binding series last night
<sven>
ah, nice. let me check that
<sven>
i'm currently playing with maz' hack/m1-pcie-WIP to see if i can get that to work with my current DART code
<kettenis>
my u-boot currently has a bit of a frankendevicetree
<kettenis>
but that tree should be usable as well
<sven>
and i'm just making it worse. right now i have two pcie nodes in there: one for uboot and one for linux
<Emantor>
Can't wait to port barebox to the Mac Mini, I have no interest in struggling with U-Boot :-) But I am biased anyway.
<kettenis>
if you're using the latest apple-m1-m1n1-nvme branch you can probably just use the pcie node from that
<marcan>
MagMell[m]: if you mean m1n1, it should bring up usb gadget on both ports (the framebuffer should have logs to that effect)
<marcan>
note that reconnection does not work, you have to boot with it connected, because we don't currently handle the type C controller chip to make that work
<kettenis>
ignore the "apple,pcie-m1" compatible and the extra interrupts
<kettenis>
and maybe touch up the iommu references
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<kettenis>
u-boot needs the "apple,dart-m1" compatible on the DART nodes for now
<sven>
yeah, i think i'm at the point where pcie works in uboot now and i have to actually understand maz' pcie code now and see what's still missing
<kettenis>
I believe maz' pcie code uses the msi-ranges property that I added
<kettenis>
for reference, the openbsd driver is here:
pugguu has quit [Read error: Connection reset by peer]
<kettenis>
I haven't committed the switchover to "msi-ranges" there yet, but it shows you how to program the MSI-related registers
<eta>
marcan: oh dear, you tried to call out the crypto people on twitter
<eta>
sounds like a way to attract lots of replies :p
<kettenis>
sven: another thing is that you need to set up the requestor ID to stream ID mapping in the host bridge
<kettenis>
or as a hack you can change the DT to use stream ID 0
<kettenis>
it seems that if there is no RID to SID mapping set up for a device, stream ID 0 gets used
<MagMell[m]>
<marcan "Mag Mell: if you mean m1n1, it s"> It seems that the USB-C cable is not recognized even after reboot, is there a special condition for the USB-C cable?
<Emantor>
MagMell[m]: any USB 2.0 compliant C-to-C or C-to-A cable should work. any dmesg output on your development host?
<MagMell[m]>
My dmesg: http://fars.ee/EM56 (I don't seem to see any relevant information), As well as I use Anker's C-C charging cable, and oppo's C-A phone charging cable, dmesg does not output the relevant information
bgb has quit [Ping timeout: 480 seconds]
<Emantor>
Maybe the charging ables don't have the data lines connected?
<kettenis>
sven: implementing legacy (INTx) interrupts will require a bit more work
<sven>
yeah, i think that's what's missing
<kettenis>
I didn't bother since all the built-in devices support MSIs
<kettenis>
(for OpenBSD)
<sven>
but i'm still not 100% sure
<sven>
still trying to wrap my head around pci
<j_ey>
sven stream soon? it's all the rage now :P
<sven>
at least something requests a MSI, unmasks a AIC interrupt but that interrupt then never fires
<sven>
it also fails to setup this INTx thing because there's no code for it. so maybe that's just missing :D
<amw>
J
<amw>
J
<sven>
j_ey: that sounds like effort. you'd also only get to watch me reading linux code which is not very interesting
<j_ey>
:-)
<Emantor>
Common misconception seems to be that because marcans streams are good, every other developer also does good streams. IMO marcan is the exception with his prior streaming experience :-)
<kettenis>
maybe the network interface works without interrupts on Linux
<kettenis>
you should defenitely see MSIs firing for xhci
<sven>
i think it does. at least very slowly
<amw>
Sorrry, was just trying to say Thanks to marcan for m1n1 youtube, I'm learning so much from trying to follow along, on Python classes, ARM hardware and so on.
<sven>
so that's what i've assumed as well. maybe something is broken with MSIs then
<marcan>
prior... streaming... experience?
<Emantor>
marcan: didn't you do the touhou events beforehand?
<marcan>
what touhou events?
<Emantor>
I thought you did event streaming beforehand, guess I am confusing something here.
<marcan>
I did some re-broadcast DJ streams for a formerly physical event that shifted to streams because covid, but juggling RTMP feeds while trying to coordinate transition times and MCing in a radio voice doesn't really have much of a skillset overlap with, er, coding on a stream
<marcan>
other than "both use OBS" and "I know how to build audio pipelines in JACK"
bgb has joined #asahi
<kettenis>
sven: at least it seems you have the iommu stuff sorted
<marcan>
I have no personal streaming experience
<j_ey>
marcan: well, regardless of no previous experience, the streams are good lol
<sven>
kettenis: yeah, i think the iommu seems to work fine
<sven>
now i wanna see if i can somehow get this to at least boot with a 4k pagesize as well
<Emantor>
marcan: okay, than I misunderstood sorry. But having at least some OBS/Jack experience lowers the barrier to entry.
<sven>
yeah, i'd have to setup all that stuff before i could even start streaming
<sven>
and i'd rather spend that time reading/writing code :)
<marcan>
eh, normal people just install OBS and add two sources (desktop and mic)
<marcan>
I'm weird and use two computers with networked audio and HDMI to capture card video and a bunch of audio filters and stuff like that because me
<marcan>
but none of that really makes the stream "better" other than maybe audio quality
<marcan>
I don't know if my streams are good, but I'm pretty sure the content matters the most and none of that has anything to do with my audio shenanigans :-)
<Emantor>
You're streams are good and the content is very insightful. :-)
<marcan>
(if anyone wants my carla patch though, happy to share. I'm kinda proud of discovering the multiband compressor trick to reduce high-frequency noise)
<marcan>
(like fan/AC noise and such)
<marcan>
sorry, multiband gate
<Emantor>
Sure, I wouldn't say no. I played with carla and pipewire since it eliminates the whole "setting up Jack"-problem. Worked mostly fine.
<bgb>
marcan: how to catch the xnu boot log when running run_guest.py? upper right of your screen
<_jannau_>
bgb: serial output from m1n1's second ACM interface
<bgb>
so, export M1N1DEVICE=/dev/ttyACM1, then what cmd should I invoke?
<_jannau_>
no, not as M1N1DEVICE. open it directly with terminal emulator like picocom, screen, minicom, ...
<bgb>
ok, thx
Mi has joined #asahi
Mi has quit [Quit: Leaving]
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
<sven>
kettenis: i just briefly looked at the DART kext to confirm that we can't switch page sizes and stumbled across a method called "dartSupportsFullBypass". looks like bypass mode is only supported if bit 0 in register 0x04 is set
<sven>
that bit isn't set for the pcie darts
<sven>
which probably explains why we couldn't get bypass to work there
<marcan>
well, that makes me happy
<marcan>
no "oh we can just use bypass mode" excuses for 4K support
<marcan>
either we do it properly or we don't do pcie :p
<sven>
lol
<sven>
well... i mean.. we could build some hacked bypass support for 4k pages but uh
<marcan>
yes I know we could hardcode 1:1 tables but no, just no
<sven>
fine with me ;)
<marcan>
if we can get the kernel to play nicely with the diverging page sizes *somehow* that's fine by me, but no static bypass hacks for external interfaces
<sven>
i'm fine with only supporting 16k/64k pages *shrug*
<marcan>
sure
<marcan>
well, 64k won't happen anyway
<marcan>
so that just leaves 16k
<sven>
sounds good to me
<bloom>
I still don't understand why the CPU needs to use 16k just because peripherals need them
klaus has joined #asahi
<bloom>
Aren't the MMUs separate?
<sven>
yes, but the kernel currently assumes that cpu page size >= iommu page size
<j_ey>
could it do something weird and have page size 4kb, but alignment 16k?
<sven>
it's not impossible to support that, but it'd be annoying to implement
<sven>
there's already some support for small allocation by using swiotlb
<sven>
and we could also hack this by creating a fake-bypass mode with static pagetables + swiotlb
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<thunfisch>
marcan: re stream, if nothing else, the stream is awesome for watching you work and all the little shortcuts used. picked up a few tricks and reminders (e.g. to use git commit --patch more). didn't understand too much of what was going on, but seeing you get the iommu hv up and runnig was actually quite exciting entertainment ;)
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
<kettenis>
bloom: the problem with 16k iommu pages with 4k cpu pages is that you end up exposing more bits of memory to the devices than you really want
<kettenis>
it is still better than exposing everything though
<kettenis>
sven: just realized that I didn't push all my pcie-related u-boot changes last night
<kettenis>
so I just pushed a changes that renames the "ecam" reg-names name to "config" as requested by robh
Andalu30 has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
<sven>
dart has some sub-page protection support fwiw
pugguu has quit [Read error: Connection reset by peer]
<sven>
as as long as the iovas are 16k aligned you can probably also only map 4k
<kettenis>
ah, something to look at before I consider enabling pcie passthrough on the thunderbolt ports in OpenBSD
<sven>
iirc in the PTE bit 1 needs to be cleared and then the top bits become [12 bit start offset][12 bit end offset] or something like that
<sven>
haven't figured out the exact details because using usb to look into the iova space is a little bit annoying
<sven>
have you already made thunderbolt work? :D
<kettenis>
it is diffucult to use that in Linux's iommu code?
pugguu has joined #asahi
<kettenis>
no, not bothered with thunderbolt
<sven>
i'd have to write my own pagetable code
<sven>
but i think the issue is that the top level api in linux so far guarantees that you can map any page-aligned things to any page aligned iova
<sven>
with this we could map 4k pages to 16k aligned iovas
<sven>
(or even things smaller than 4k)
<sven>
or, well. not really. we could map 4k aligned pages to one of [iova],[iova+4k],[iova+8k],[iova_12k] or something like that
<sven>
but the linux iommu api manages the entire iova space. the dart driver just gets told "please map iova range [x,x+sz] to paddr range [y,y+sz]
<kettenis>
OpenBSD's bus_dma API has an API that just says "map this range of physmem and return the device address you mapped it at"
<sven>
that's one layer up from the dart driver in linux. iirc it's called dma_ops there
<sven>
and that iommu layer is the one that manages the entire iova space
<sven>
i'm not sure the maintainers would be very happy with me if i replace that with some special-case DART code though ;)
<sven>
hm. now that i'm reading that code again it shouldn't be too hard to just make it work with a different granule
<j_ey>
does that mean you also cant install m1n1 on external storage?
<agraf>
j_ey: it means that even if you install m1n1 on external storage, the internal firmware will first copy m1n1 to the local ssd before it can boot it
<j_ey>
does that affect the normal macOS install at all?
<agraf>
j_ey: you can always go back to the local macOS install. The location external boot files get copied to is on special partitions
<agraf>
j_ey: take a look at /System/Volumes/Preboot
<choozy>
Hmm
<arnd>
I couldn't actually get m1n1 to start from an external drive at all
<j_ey>
arnd: didnt you have som troubles with not being administrator?
<choozy>
Would it make sense to sort of flash Linux onto future machines using DFU mode?
<arnd>
j_ey: I tried with my coworker's help and they couldn't do it with their credentials either
<j_ey>
:/
<j_ey>
agraf: thanks
<agraf>
arnd: I'm not sure how far the boot loading logic advanced recently
<arnd>
we could install a regular macos to a thunderbolt drive, but installing two separate macos installations to different partitions always failed, and the same happened when trying to replace the macos kernel on the external drive with m1n1
<agraf>
arnd: but there's a good chance the "boot selector" thing doesn't set the hash that allows you to run 3rd party binaries
<agraf>
arnd: those were 2 separate installations on the same external drive, but different partitions?
<arnd>
agraf: yes. installing a second (or third) macos using the credentials from the internal drive works, but makes all other external partitions unbootable
<agraf>
j_ey: sorry, it should be /System/Volumes/iSCPreboot IIRC
<agraf>
j_ey: they do, the normal one is for macOS, the iSC one is for the firmware
<j_ey>
ah "When an OS from external media is booted via 1TR, its boot files (everything under /(uuid)/boot) are copied from the Preboot volume to this partition under the same path. This is how Apple Silicon macs can "boot" from external media, even though iBoot itself cannot."
<agraf>
arnd: that sounds .... very surprising :)
<arnd>
I think there is also a difference between booting through recovery mode and booting through the normal "pick default OS" (whichever that is called) setting
<agraf>
arnd: Did you manage to dig down into why it's breaking?
<agraf>
arnd: like look at the LocalPolicy files before/after, validate signatures, see if maybe the OIK ownership was changed/revoked
<arnd>
USB drives can only be booted using recovery mode by long-pressing the power button, but I did not try that at all. The method I used was with a thunderbolt drive, because some part of the boot loader apparently treats that as an internal drive. My best guess is that it breaks down after that, since this is not really a supported configuration
<arnd>
i.e. more than one "internal" drive
<arnd>
agraf: there was some cryptic error message I got when I tried to install m1n1 onto the thunderbolt drive, which I think was related.
<agraf>
arnd: So m1n1 on the external drive I can absolutely see how that would fail
<agraf>
arnd: because it wouldn't pass any signature verification :)
<agraf>
arnd: but normal macOS kernelcaches should just work