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
klaus has joined #asahi
macc24 has quit [Ping timeout: 260 seconds]
troseman_ has left #asahi ["Leaving"]
artemist has quit [Ping timeout: 260 seconds]
artemist has joined #asahi
troseman has joined #asahi
troseman has quit [Client Quit]
troseman has joined #asahi
troseman has quit [Client Quit]
troseman has joined #asahi
troseman has quit [Quit: Leaving]
troseman has joined #asahi
troseman has quit [Client Quit]
klaus has quit [Ping timeout: 260 seconds]
troseman has joined #asahi
odmir has quit [Remote host closed the connection]
klaus has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 246 seconds]
klaus has quit [Ping timeout: 252 seconds]
odmir has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 260 seconds]
odmir has quit [Ping timeout: 240 seconds]
troseman has quit [Ping timeout: 252 seconds]
klaus has joined #asahi
inglor has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
klaus has quit [Ping timeout: 240 seconds]
inglor has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
phiologe has quit [Ping timeout: 250 seconds]
phiologe has joined #asahi
klaus has joined #asahi
marvin24 has quit [Ping timeout: 245 seconds]
marvin24 has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
mxw39 has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
j`ey_ has joined #asahi
lewurm_ has joined #asahi
klaus has joined #asahi
Jaehyuk[m] has quit [*.net *.split]
ewlsh[m] has quit [*.net *.split]
mofux[m] has quit [*.net *.split]
m1kr0[m] has quit [*.net *.split]
fstokesman[m] has quit [*.net *.split]
meiji163[m] has quit [*.net *.split]
izzyisles[m] has quit [*.net *.split]
pipcet[m] has quit [*.net *.split]
noc0lour1 has quit [*.net *.split]
winocm has quit [*.net *.split]
nickray has quit [*.net *.split]
foxlet has quit [*.net *.split]
fridtjof[m] has quit [*.net *.split]
Chainsaw has quit [*.net *.split]
j`ey has quit [*.net *.split]
lewurm has quit [*.net *.split]
klaus has quit [Ping timeout: 246 seconds]
Chainsaw has joined #asahi
klaus has joined #asahi
fridtjof[m] has joined #asahi
winocm has joined #asahi
ewlsh[m] has joined #asahi
fstokesman[m] has joined #asahi
Jaehyuk[m] has joined #asahi
meiji163[m] has joined #asahi
pipcet[m] has joined #asahi
mofux[m] has joined #asahi
izzyisles[m] has joined #asahi
m1kr0[m] has joined #asahi
foxlet has joined #asahi
nickray has joined #asahi
noc0lour1 has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
klaus has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
VinDuv has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
ephe_meral1 has joined #asahi
the-mentor3 has quit [Quit: The Lounge - https://thelounge.chat]
klaus has joined #asahi
the-mentor3 has joined #asahi
klaus has quit [Ping timeout: 246 seconds]
M1f4a9[m] has joined #asahi
VinDuv has quit [Quit: Leaving.]
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
klaus has joined #asahi
vimal has quit [Ping timeout: 260 seconds]
j`ey_ is now known as j`ey
j`ey has quit [Changing host]
j`ey has joined #asahi
vimal has joined #asahi
Namidairo has quit [Ping timeout: 265 seconds]
Namidairo has joined #asahi
<marcan> I think the driver needs a few patches, but that's about it
wagood[m] has quit [Quit: Idle for 30+ days]
<arnd> agreed, the corellium patch doesn't look too bad as a start. Someone could probably just split it up into logical changes and add a changelog text after figuring out what the changes are in fact needed for. The maintainers might want some things to be handled differently, but most of it is rather straightforward
<kettenis_> passing the mac address in the device tree should probably be done a bit differently
<kettenis_> the standard way to do it would be to have a mac-address ptoperty on the device tree node for the pci device
<kettenis_> the (wired) ethernet device needs that too
<arnd> kettenis_: my reading of the driver is that the mac address is stored in the nvram of the PCI device
<arnd> in that case I think it is best to leave it in the driver and not try to access the PCI device from the boot loader just to pass the address through DT
<arnd> unless the ethernet driver also wants to read the mac address from the wireless device, in which case using the boot loader would help avoid an inter-dependency between two otherwise unrelated pci network drivers
<kettenis_> apple doesn't store the mac address in nvram/eeprom/otp
jaalsa has joined #asahi
<kettenis_> all mini's will end up with 00:10:18:00:00:00 as their mac address for the wired interface
<kettenis_> the "real" mac address is stored in the ADT
<arnd> kettenis_: for both ethernet and wireless, or just the former?
<kettenis_> both
<kettenis_> well 00:10:18:00:00:00 for ethernet
<kettenis_> not sure what the "default" address is for the wifi
<kettenis_> 00:10:18 is the OUI for Broadcom
raster has joined #asahi
<kettenis_> related to the wifi; it seems power to the wifi device is controlled by the SMC
<kettenis_> if it isn't powered on, it simply doesn't show up as a PCIe device
<marcan> do we have a standard binding for passing macs, or is that a device-specific thing still?
<kettenis_> standard binding
<marcan> I guess it still needs to be handled in the driver though, right?
<marcan> should be an easy patch though
<kettenis_> it is a bit awkward for pci devices though sine you need to (partly) describe the pci hierarchy
<marcan> yeah, I've seen that on some dts IIRC
<kettenis_> something that's normally not needed for pcie
<kettenis_> not sure how this works for drivers in linux
<kettenis_> but OpenBSD does indeed need driver modifications
macc24 has joined #asahi
<kettenis_> bge(4) already has that though since Sun did something similar with theur onboard broadcom ethernet
luca020400 has quit [Quit: WeeChat 3.1]
luca020400 has joined #asahi
<tmlind> hmm i can't find the link to view the adt files.. wasn't there some pseudo-translated url for those to look at?
<tmlind> heh with pseudo-translated i mean adt to dts translation, not url translation naturally
Chainsaw has quit [Remote host closed the connection]
<kettenis_> ah, the linux tg3 driver calls eth_platform_get_mac_address()
<kettenis_> so that should take care of fetching the mac address from the device tree
_rjeffman is now known as rjeffman
<tmlind> ah i found the adt link i was looking for: http://csgraf.de/tmp2/m1.json
<tmlind> i think that was from #armlinux channel few months ago, helps to keep notes.. but could not find the notes earlier
<tmlind> should that be linked somewhere on the wiki if not already there?
<arnd> kettenis_: it looks like arch/sparc still emulates the idprom from the m68k sun3 days, while everybody else uses the ibm-style local-mac-address property. ADT (in the link that tmlind cited) apparently contains a local-map-address property but it contains the "macaddr/wifiaddr,syscfg/WMac/6,zeroes/6" string instead of of actual address
<arnd> Does Apple's bootloader replace that with the actual value before passing it to the OS?
<kettenis_> yes
<kettenis_> and indeed, local-mac-address is the right property
<tmlind> fyi, i recall local-mac-address also depends on having ethernet aliases to work properly, might be worht checking if that still is the case
<tmlind> hmm maybe that was actually u-boot limitation, not sure
<kettenis_> that's for u-boot
<kettenis_> but an alias will make life easier for m1n1 as well
<tmlind> ok
<arnd> kettenis_: interestingly, the ethernet device in adt encodes the local-mac-address property in the same place that Linux would look for it, in /arm-io/apcie/pci-bridge2/lan-1gb/local-mac-address, but the wireless device has a device in /arm-io/apcie/pci-bridge0/wlan/ withouto such a property, and another device in /arm-io/wlan that has a few properties including local-mac-address but no registers
<kettenis_> yeah, the way the wifi/buetooth is integrated is strange
<kettenis_> I wonder if Apple has it somehow hooked up to the SMC via a side-channel to do some sort of active standby
<arnd> I also see that /arm-io/uart2 has a "wlan-debug" child node with a "wlan.uart.baudrate = <0x2f8e7a>" property. I wonder if that is used for debugging the wlan firmware, or if there is a hidden debug mode that exposes a console over wlan
<arnd> has anyone tried talking to uart2 at that baud rate?
<sven> iirc I couldn't attach it while running Mac OS (resource busy) and there was nothing when using linux but that might just be because I didn't bring up pcie or the wifi module
Chainsaw has joined #asahi
<marcan> tmlind: adt to dts translation is not possible in the general sense, because there is not enough information in the format
<marcan> property values are just bytes, and the endinanness is different, so you can't know what needs to be flipped
<tmlind> marcan: yeah the "raw data" view in the m1.json link above is handy though :)
<marcan> I've been using shiz's dt.py, which spits out this format: https://mrcn.st/p/t1926QWh
<Shiz> :)
<Shiz> note that dt.py also does implement a to-dts
<Shiz> but marcan's caveats also apply there
<Shiz> specifically for int values
<marcan> would be nice to start building up a high-level schema to do this properly. not for actual conversion, but to get nice pretty-printed versions, and for diffing / dealing with newer devices
Chainsaw has quit [Remote host closed the connection]
<tmlind> thanks for the link
<sorear> [macos capabilities question] does rosetta 2 support any kind of system/hypervisor emulation, or do you have to use non-M1-specific emulators like qemu for that
<sorear> more generally curious if anyone here has long-term emulation plans. I am acutely aware of qemu's architectural limitations from my time with riscv but I'm not sure what could be done about them beyond tech demos
<delroth> emulation of what?
<arnd> sorear: HdkR is working on https://github.com/FEX-Emu/FEX for emulating x86 user space, you can find him on #armlinux. It requires x86 or arm64 hosts today, but I'm fairly sure porting to rv64 would be possible, given how similar it is to aarch64
<sorear> my experience is rv64-on-x86, which might be a better match for x86-on-M1 since you're not emulating flags (one of the least pleasant parts of TCG)
<marcan> sorear: no system stuff AIUI, only userspace
<marcan> qemu does work
<marcan> I do wonder how many of the M1 Rosetta-isms we can expose on Linux sanely
<marcan> TSO should be easy; that just requires flipping a bit in ACTLR_EL1 (which does mean we need to save it on context switches or whatever, but that shouldn't be a big deal since it *is* at least a standard register)
<marcan> AF/PF and the SSE stuff is ickier; those rely on Apple-proprietary registers which again would become part of architectural state, and I'm not sure how much hate we would get for trying to introduce those into process context
<marcan> same with AMX
<marcan> (maz: thoughts?)
<maz> marcan: I'm pretty sure you will get a huge push-back on exposing TSO to userspace in any shape or form. it's like SVE, only far worse because there is no architecture to write against.
choozy has joined #asahi
<maz> marcan: you'd have to abstract it behind some "strongly ordered" API. overall , this doesn't fit the architecture, nor its direction of travel.
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
<marcan> maz: wouldn't it just be a prctl? that's where all the other related crap is
<sorear> non-standard architectural state is a huge developing problem on the riscv side, opportunity for a common solution
<marcan> something like PR_SET_MEMORY_MODEL
<sorear> surely this has come up at least once for mips or sparc, maybe powerpc
<marcan> I mean, is there significant reason not to expose it? it would seem like a fairly minimal patch, and decent x86 emulation is a significant benefit
<marcan> if ARM isn't working on anything along those lines, well, they should be :)
<marcan> and AIUI there are ARM cores that unconditionally guarantee TSO and under those the API could just always return that
<sorear> riscv also needs a solution for "32-bit hwcap is not a scalable way to handle vendor extensions and requiring procfs isn't great"
<maz> marcan: what ARM comes up with or not is only one side of the problem. adding non-architectural stuff in a userspace visible way is not something anyone will consider lightly. If you want to run TSO, flip the bit from the bootloader and be done with it.
<maz> disclaimer: I don't give a rat's arse about x86 emulation.
bendoin_ is now known as bendoin
artemist has quit [Quit: artemist]
Chainsaw has joined #asahi
ephe_meral1 has quit [Ping timeout: 240 seconds]
hir0 has joined #asahi
ephe_meral1 has joined #asahi
VinDuv has joined #asahi
taziden has quit [Ping timeout: 250 seconds]
taziden has joined #asahi
radex has joined #asahi
hir0 has quit [Ping timeout: 252 seconds]
jeffmiw has joined #asahi
jeffmiw_ has joined #asahi
jeffmiw has quit [Read error: Connection reset by peer]
jeffmiw_ has quit [Remote host closed the connection]
jeffmiw has joined #asahi
kendfinger has joined #asahi
jeffmiw has quit [Remote host closed the connection]
ephe_meral1 has quit [Ping timeout: 268 seconds]
jeffmiw has joined #asahi
jeffmiw has quit [Client Quit]
jeffmiw has joined #asahi
<sorear> neat
h_ro[m] has joined #asahi
kettenis_ has quit [Ping timeout: 265 seconds]
kettenis_ has joined #asahi
VinDuv has quit [Quit: Leaving.]
raster has quit [Quit: Gettin' stinky!]
inglor has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<jeffmiw> trying to boot the linux kernel in EL1 while running m1n1 as EM2 hypervisor, I'm hitting an instruction abort because of a translation fault level 0 on the first instruction after the ERET from el1_call in exception_asm.s
<jeffmiw> I'm not clear about this level 0, is it the exception level or the translation level ? I'm a bit confused here ...
<j`ey> translation level
<jeffmiw> humm and how is controled the translation level 0 ? TTBR are for stage 1
inglor has joined #asahi
<jeffmiw> ok, I found its definition in armv8 figure D5-9, thanks j`ey
vlixa has quit [Remote host closed the connection]
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
vlixa has joined #asahi
kettenis_ has quit [Ping timeout: 240 seconds]
kettenis_ has joined #asahi
jixbo has joined #asahi
HeN has quit [Quit: Connection closed for inactivity]
rjeffman has quit [Ping timeout: 260 seconds]
jixbo has quit [Quit: jixbo]