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
<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
<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]>
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
<_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
<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>
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