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]
<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
<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 :)
<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]
<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]