marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: | Wiki: | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs:
yuyichao_ has joined #asahi
adamcstephens has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
adamcstephens has quit [Quit: The Lounge -]
bgb has joined #asahi
mini has quit [Ping timeout: 480 seconds]
mini has joined #asahi
mini_ has joined #asahi
aquijoule_ has joined #asahi
mini has quit [Ping timeout: 480 seconds]
mini_ is now known as mini
adamcstephens has joined #asahi
richbridger has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi
mini has quit [Remote host closed the connection]
mini has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
adamcstephens has quit [Ping timeout: 480 seconds]
adamcstephens has joined #asahi
adamcstephens is now known as Guest1248
adamcstephens has joined #asahi
Guest1248 has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
<bloom> It's creation!
VinDuv has joined #asahi
VinDuv has quit [Quit: Leaving.]
al3xtjames has joined #asahi
al3xtjames has quit [Quit: Ping timeout (120 seconds)]
EER has joined #asahi
bisko has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Emantor> My USB PD PCB arrived.
<Emantor> Now waiting for Digikey to send the FUSB302 and USB connectors.
<sven> [ 0.242694] nvme0n1: p1 p2 p3 p4 p5 p6
<sven> :-)
<sven> still a big fat hack though
<Emantor> Nice :-)
<j_ey> are those partitions or?
<sven> probably
<Emantor> yes, they are.
<sven> (and, as usual, i'm just doing the plumbing. this is mostly based on arnd's nvme platform split)
<j_ey> I forgot about that, did that land?
<sven> "This is completely untested and probably does not work."
<sven> it almost worked though ;)
<arnd> ah, nice
<j_ey> hehe
tomtastic has quit [Ping timeout: 480 seconds]
tomtastic has joined #asahi
<arnd> marcan had mentioned he would look into getting it to work in the near future when I initially created the patches, so I did not bother setting up an environment for testing the PCIe side of it, and I never got far enough with the mac in the office to actually try things out on that either
<sven> i just had half an hour while waiting for something to install on my actual work machine and figured i'd give it a try
<sven> the pcie side is completely untested and the platform side needed two or three on line changes
<sven> (plus all the apple specific stuff ofc)
Firefox317 has joined #asahi
<Firefox317> Hey guys! Do you know what's up with the m1n1 wiki? When I access I get redirected to
<j_ey> I guess there isnt one?
<Firefox317> j_ey: Aha, that is where all the information is. Thanks!
<bgb> Emantor: DIY Arduino-based USB-PD interface ?
<Emantor> bgb: I did a small redesign of the Reclaimerlabs FUSB302 breakout board ( which includes the SBU pins:
<bgb> cool! I'd like to try it
<bgb> Emantor: btw, which pcb tool do you use?
<Emantor> kicad
Firefox317 has quit [Quit: Page closed]
<kettenis_> sven: so we'll need to work on the NVMe and IOP mailbox DT bindings as well...
kettenis_ is now known as kettenis
<sven> kettenis: so i've been ignoring the mailbox for now and just let uboot handle that
<sven> but other than that... hea.
<sven> *yeah
<kettenis> the mailboxes are "interesting"
<kettenis> they need some memory for logging
<kettenis> so u-boot allocates some memory and reserves that memory in the memory map
<sven> ah, so they'll trash random memory that uboot left setup then? fun
<j_ey> how much memory>?
<pipcet[m]> 64 KB or so
<kettenis> not much, just a few pages
<kettenis> the current u-boot code reserves the memory in the EFI memory map
<pipcet[m]> I think it's more interesting that you can't reboot the remote processors that you communicate with using the mailbox, so you can't leave the hardware in the state you found it.
<kettenis> but I'm not sure it does the right thing if you load linux kernels the non-EFI way
<sven> wouldn't be surprised if this just trashes some random memory for me then ;)
<kettenis> I haven't seen it write to the memory yet
<kettenis> pipcet[m]: it must be possible to reset the thing, since iBoot uses the NVMe storage but in U-Boot I had to start it up again
<pipcet[m]> good point. we just don't know how.
<pipcet[m]> by the way, I stole your code for barebox experiments and found I needed to reorder the device tree so the SMC mbox is initialized before the ANS mbox... any idea on how to represent that in the DT properly, if it's actually correct?
<pipcet[m]> is there a generic "this device only works once that device does" mechanism, maybe?
<kettenis> there is a bug in the memory reservation code for the mailbox driver
<kettenis> it shouldn't matter in which order the mailboxes are initialized, but currently it does
<kettenis> not gotten around to fixing that
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi
Graypup_ has quit []
Graypup_ has joined #asahi
<Emantor> pipcet[m]: can you gist your config somewhere? Really wondering why gadget/chainloading barebox from m1n1 is not working for me.
<pipcet[m]> Emantor:, I'll put the device trees there in a second
<pipcet[m]> you probably need to ignore the NVME/mbox/DART/i2c stuff unless you're using my repo, but framebuffer and USB gadget should work without those (as long as you chainload from a new m1n1)
<pipcet[m]> and sven was saying usb host mode might work as well, I think :-)
<arnd> sven: if you boot into Linux with the nvme driver, are you able to run 'nvme id-ctrl /dev/nvme0n1'? I'm curious to see if it uses the host memory buffer (hmpre/hmmin/hmmaxd)
<sven> i only have a very minimal ramdisk that comes without nvme. any other way to get that info?
<sven> i patched the kernel to printk those values after nvme_identify_ctrl and i think they're all zero
<arnd> sven: ok, adding those printks would have been my first suggestion, all zeroes just means it has no HBM and presumably uses an internal DRAM cache like every high-end device does
<kettenis> pipcet[m]: I pushed a change that should fix the mailbox dependency issue
<pipcet[m]> thanks!
os has quit [Quit: The Lounge -]
<_jannau_> arnd: but where is the dram cache? stolen from unified memory? the storage controller is integrated according to apple
<kettenis> dumping the SART registers in m1n1 might provide a clue
<arnd> _jannau_: my first guess would be in the same package as the NAND flash, at least if that comes in a custom package
<kettenis> the SART is a very simple IOMMU which gives the side-processor that handles NVMe access to the SOCs address space
<kettenis> it has a few mappings that allow access to main memory regions
<kettenis> SART 0x009e6e84/0xff018c6c
<kettenis> that is probably a mapping for some sort of DRAM cache
<arnd> ah, so maybe they did their own version of HMB before it became a standard NVMe feature?
<kettenis> maps a block of 0x18c6c 4K pages at physical address 0x9e6e84000
<kettenis> which is part of the upper block of reserved memory
<kettenis> arndb: likely; they can just have the firmware set it up
<kettenis> damn now im mixing up arnd with ardb
<arnd> kettenis: that happens a lot. if you use irccloud, you'll now see my picture next to what I write, it used to also assign the same colour icon to both of us
<arnd> kettenis: 400MB seems quite a lot for the cache, but that must be what it's used for. The Linux NVMe driver allocates at most 128MB unless you override it with a boot time or module option.
os has joined #asahi
<kettenis> hard to imagine needing that much memory for anything else
choozy has joined #asahi
GreatGodvin has joined #asahi
<Emantor> pipcet[m]: It was the serial driver, disabling that lets simple FB work.
<Emantor> Even when chainloading.
<pipcet[m]> Emantor: ah, that's good to know. do you want to write a keyboard driver for barebox on the MBP? ;-)
<Emantor> pipcet[m]: I don't have a MBP, can't really without the hardware ;) But if ehci works you should be able to use a USB keyboard.
<pipcet[m]> does that work for you? I tried briefly and it didn't immediately work, but I'm still using old phy sequences...
<Emantor> Eh, MMU also needs to be disabled.
<Emantor> No, I don't have any USB-C adapters here :D
<Emantor> With PCI XHCI on the Minis USB-A ports may also work.
<Emantor> *PCIe
GreatGodvin has quit [Quit: GreatGodvin]
GreatGodvin has joined #asahi
bisko has joined #asahi
<sven> only if you do the pcie init dance that u-boot usually does
adamcstephens has quit [Quit: The Lounge -]
adamcstephens has joined #asahi
bisko has quit [Remote host closed the connection]
bisko has joined #asahi
<marcan> arnd: I was waiting for sven to get the dart stuff going for nvme :)
<marcan> (and then got caught up in a hypervisor)
<marcan> and yeah, a big next one is going to be IOP mailbox, especially since that's a dep for graphics too
<marcan> and display, both
<marcan> it's on my list, but if someone wants to tackle it while I work on the mmiotrace side by all means
<marcan> I'll probably hack up some basic m1n1-based gpu driver scripts first before jumping into linux
<sven> nvme isn't behind a dart fwiw
<marcan> oh, it isn't? I thought it was
<marcan> ah, then i was waiting for power/clocks at least
<marcan> I remember now :p
<sven> this still heavily lies on u-boot to bring this all up ;)
<sven> *relies
<marcan> yeah, spin up the core etc
<marcan> we need that code in linux anyway, since it needs to do all the other ones
<marcan> (unless we make m1n1 do it all, but... that kind of smells like relying on the bootloader a bit too much)
<marcan> (especially since I fully expect resets to be necessary to get us out of trouble during development)
<sven> yeah, probably
bgb has quit [Ping timeout: 480 seconds]
GreatGodvin has quit [Quit: GreatGodvin]
GreatGodvin has joined #asahi
GreatGodvin has quit []
choozy has quit [Quit: - Chat comfortably. Anywhere.]
bgb has joined #asahi
balrog has quit [Quit: Bye]
bgb has quit [Ping timeout: 480 seconds]
tomtastic has quit [Quit: ZNC -]
tomtastic has joined #asahi
bgb has joined #asahi
<sven> arnd: that's all i had to fix i your patches to make nvme as a platform device work
<arnd> sven: wow, I was really lucky there, I fully expected some major screwup
bgb has quit [Ping timeout: 480 seconds]
<arnd> sven: actually in my build tree, I added a hack to only allow building CONFIG_BLK_DEV_NVME_PLATFORM when CONFIG_PCI is also set
<arnd> which doesn't matter for the M1, but in theory those two should be completely separate
<sven> true, probably also makes sense to split this out of pci.c as well
<arnd> I did not want to take that last step in order to make rebasing easier until the nvme maintainers are ready to merge it
<sven> makes sense, that probably made the rebase i had to do relatively painless
<j_ey> what exactly is a platform device/driver?
<sven> my limited understanding is that a platform device is defined in a device tree (or possibly even in some code directly) as opposed to a device that can be enumerated on a bus
<Emantor> NVMe didn'
<Emantor> t have support before because usual nvme devices are connected to the PCIe bus.
<Emantor> And enumeration of devices on the bus is done by the PCIe bus driver.
<arnd> originally platform devices were always defined in board files or architecture code, such as
<arnd> arch/x86/kernel/rtc.c: platform_device_register(&rtc_device);
jryans is now known as Guest1328
<arnd> when we converted embedded powerpc platform code to DT, we started out with having a separate device type for devices defined in there, but ended up merging the two as a ton of drivers ended up needing to support both board files and DT booting
<arnd> it's a bit of an anachronism now since only a few hundred non-DT boards remain, compared to over 2000 dts files in tree, and more that work with mainline kernels but were never submitted for inclusion
EER_ has joined #asahi
Guest1328 is now known as jryans
jryans has quit [Quit: authenticating]
jryans has joined #asahi
EER has quit [Ping timeout: 480 seconds]
choozy has joined #asahi
<pitust[m]> how do i shrink the linux partition and give more to macos
<pitust[m]> ah erasing twice worked
aleasto has joined #asahi
VinDuv has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
<arnd> sven: ah, now the build bot started reporting the !CONFIG_PCI failures on your tree that I had seen earlier. Curiously it doesn't happen on a defconfig build with PCI disabled, it needs some other config options that I have not analyzed yet.
<j_ey> arnd: some build bot is running on the asahi github branches?
<arnd> j_ey: yes, the kernel zero-day bot builds all branches of git repos that feed into linux-next
<arnd> with some heuristics, I think it only tests recent commits
<arnd> and there is a manual opt-in and opt-out
<j_ey> arnd: oh cool, I didn't know asahi was feed into linux-next
<j_ey> *fed
<arnd> oh, actually it doesn't. In this case there must be some other heuristic, maybe they started building all trees with recent commits that forked from torvalds/linux.git
Andalu30 has joined #asahi
aleasto has quit [Remote host closed the connection]
choozy has quit [Remote host closed the connection]
<bloom> /scroll/scroll goto -10
<bloom> OA
<bloom> marcan: I might take IOP
<bloom> seems like a low hanging fruit and it'll get me to actually build a kernel for this thing
<kettenis> that's the u-boot driver
<sven> arnd: ah, yes. still some cleanup work left to be done. i think that build bot might take any git url it finds in MAINTAINERS
<sven> either way, very useful bot :-)
<kettenis> I wrote that after studying the corellium driver
<pipcet[m]> it's essentially the state machine turned back into linear code, right?
<pipcet[m]> or are there major differences in behavior?
<kettenis> not really
<kettenis> I only implemented the states that are needed
<kettenis> for SMC and NVMe
<kettenis> but a linux driver should probably be interrupt-driven
VinDuv has quit [Quit: Leaving.]
Andalu30 has quit [Quit: Konversation terminated!]
choozy has joined #asahi
EER_ has quit [Remote host closed the connection]
choozy has quit [Quit: - Chat comfortably. Anywhere.]
<bloom> kettenis: thanks
<bloom> > writeq((msg[1] & ~0xffULL) | chan->id, priv->base + REG_A2I_MSG1);
<bloom> I don't think the & here is really correct (though I know Corellium does that)
<bloom> Philosophically it doesn't make any sense to have a nonzero value in the first byte of msg[1], since the channel ID is supposed to be there.
<bloom> Be assert()ive
zopieux has quit [Quit: zopieux]
zopieux has joined #asahi