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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi
yuyichao has joined #asahi
bgb has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
<marcan>
alright, might take a bit to set up, but let's see if I can do the teardown/USB debug stream today
<maz>
j_ey: that name doesn't have to be unique.
<maz>
j_ey: this name is just a vague indication of where the interrupt is coming from, but is not meant to be a debug infrastructure. we have /sys/debug/irq for that.
chadmed has quit [Quit: Konversation terminated!]
<j_ey>
maz: thanks, I assumed it had to be unique
<maz>
j_ey: nah, it's just some userspace candy for /proc/interrupts
<j_ey>
maz: and the in-memory state thing, I started to try to remove, but decided it was better to get a first version on the mailing list first
<maz>
j_ey: fair enough. TBH, I don't think there is any major issue with this driver (we have far worse in the tree already).
<maz>
j_ey: I'm only trying to make sure that M1 is as clean as possible from an irqchip perspective so that I can point people at it and consider retiring.
<j_ey>
maz: :-)
<sven>
:D
<sven>
there's still this interesting question of how to handle these 7 or so AIC interrupts that can be distributed freely to the GPIO pins.
<sven>
probably doesn't matter for the first version (and maybe not at all because we'll only have to use like two or three gpio interrupts anyway)
<sven>
alyssa: so either this dwc3 has a quirk where you can't stop commands (ugh) or i have to actually start looking into this usb phy (ugh)
<sven>
erm.. *can't issue stop commands for device mode transfers
<maz>
sven: huh... doesn't the GPIO block expose a mux where any 32 pin can generate an interrupt that is then relayed by a single AIC interrupt?
<maz>
because that's what the driver implements...
linearcannon has quit [Read error: Connection reset by peer]
<sven>
this thing has 200+ pins and I thought you could assign any pin to any of its 7 AIC interrupts
<maz>
if the GPIO block actually implements a 1:1 mapping between a single pin and an AIC interrupt, then the driver is completely wrong.
<sven>
if you need less than 7 interrupts you can do a 1:1 mapping
<j_ey>
you can map the pins to one of 7 interrupts
<maz>
sure, but the question is whether you can have a a 32:1 mapping or not.
linearcannon has joined #asahi
<sven>
i though you could even have a 200:1 mapping
<sven>
*thought
<j_ey>
yes me too
<maz>
is there any writeup about this thing?
<j_ey>
the code :p
<sven>
i wish...
<_jannau_>
each pin config has 3 bits for interrupt control. so each pin can mapped to one of the 7 aic irqs or no irq
<maz>
_jannau_: OK. and you have a status per output interrupt to find out which interrupt has fired, I guess.
<maz>
in which case, I don't the the harm in having the driver evenly spreading the input pins over the 7 output lines, unless we want to play the priority game...
<_jannau_>
yes, there is for irq a bitfield for all pins to determine which pin fired
<_jannau_>
for each irq
<j_ey>
that's what the REG_IRQ() macro reads ^
<j_ey>
(and the "unused" variable unsigned irqgrp = 0;, is where we would change the value of the group)
<maz>
group 0 meaning no interrupt I guess?
<j_ey>
_jannau_: which group is no irq?
<_jannau_>
I think group 7 but I'm not sure
<j_ey>
I think it might be 7 actually, if so I can remove some other "hacks"
<j_ey>
(maybe, would have to test it ofc)
<_jannau_>
iirc group maps without offset of 1 into irq array and the irq status registers
<j_ey>
_jannau_: sorry what do you mean 'without offset of 1'?
<_jannau_>
if group 0 maps to aic_irqs[0]
<_jannau_>
-if
<j_ey>
_jannau_: I wonder if you can ack by setting the group to 7 (assuming thats the no-irq), rather than setting the irq type in the register
<_jannau_>
I suppose you can mask via setting the group to no-irq, ack seeems to need a write in the irq status bit
bgb_ has left #asahi [WeeChat 3.0.1]
<j_ey>
sorry yeah I meant mask/unmask not ack
<maz>
j_ey: I guess that by doing that, you'd lose the pending state for edge interrupts. bad idea.
<j_ey>
maz: then my question is, can I get the "type" of an interrupt from irq_data?
<maz>
j_ey: you can get it indirectly, from irqdesc.
<maz>
j_ey: but can't you read the state from the actual register?
<j_ey>
maz: the code currently sets the type-of-interrupt field in the register to OFF to mask the interrupt, so when unmasking it needs to know what the type previously was
<maz>
j_ey: I'm worried that this leads to lost interrupts. the expectations are that if an edge lands while the interrupt is masked, it fires on unmask.
<maz>
it is likely that setting it to OFF disables the latch, and you lose the edge that landed while masked.
<j_ey>
macOS seems to be handling it like this btw. and I'm not sure how I can test the edge behaviour :/
<maz>
j_ey: how do you test it the first place?
<j_ey>
maz: im testing with spi/keyboar
<maz>
does the SPI controller signal a level or dege interrupt?
<maz>
edge*
<j_ey>
level
<maz>
meh. if there is no other way, we'll have to live with it I guess.
<maz>
btw, the function you're looking for is irqd_get_trigger_type(), but you'll have to have use the corresponding setter in your set_type callback.
<j_ey>
maz: thanks!
<maz>
(\o/ UART and USB2 over a single USB-C connection -- I reached the 21st century!)
<j_ey>
looking at corelliums dts, there are some EDGE interrupts in here
<maz>
do they have the power button on the mini?
<maz>
that'd be an ideal test case.
<sven>
the power button interrupt comes from the SMC iirc
<sven>
but you can use that TI USB PD chip. it has an edge interrupt
<sven>
and if you just unplug/plug something to the secondary usb port it will fire
<j_ey>
sven: youre using IRQ_TYPE_LEVEL_LOW in your dt for the ti
<sven>
oh... duh.. edge
<sven>
sorry, nevermind
<sven>
(the plug/unplug interrupt is edge trigger, but that's for the interrupt controller inside the TI chip)
nskl has joined #asahi
nsklaus_ has quit [Ping timeout: 480 seconds]
roxfan has quit [Ping timeout: 480 seconds]
<tophevich[m]>
marcan: looking at the clock, I'd guess your "teardown/USB debug" stream wont happen today right?
linearcannon_ has joined #asahi
linearcannon has quit [Read error: Connection reset by peer]
linearcannon_ has quit [Read error: Connection reset by peer]
linearcannon has joined #asahi
linearcannon_ has joined #asahi
linearcannon has quit [Read error: Connection reset by peer]
linearcannon_ has quit [Read error: Connection reset by peer]
linearcannon has joined #asahi
linearcannon_ has joined #asahi
linearcannon has quit [Read error: Connection reset by peer]
<marcan>
ahaha, foiled by apple
<marcan>
apparently this thing uses TR6 screws
<marcan>
I have down to TR7, then just T6 for smaller
* marcan
places an order for a proper screwdriver set...
<marcan>
tophevich[m]: it would've started ~now were it not for... this problem
<tophevich[m]>
ifixit, or where do you order?
<j_ey>
nothign a hammer cant fix
<marcan>
yeah, I just got the ifixit one on amazon
<sven>
can't find until you finally figure out wtf that usb pd thing does
<ar>
marcan: what are you disassembling?
<marcan>
a second mac mini
<ar>
oh?
<marcan>
I'm going to scope out the USB lines to try to figure out the mystery of why the dwc3 thing locks up on internal hotplugs but not external ones
<marcan>
it makes no sense
<sven>
i think it just doesn't see the "new usb device connected" event :/
<marcan>
that's not a thing though
<sven>
(which equally makes no sense)
<marcan>
yeah
<sven>
iirc in gadget mode it doesn't even get the "usb device disconnected" event
<ar>
heh. i've seen the insides of the "devkit", and the pcb was the size of the intel mini, but almost all traces were on the inside layers of the pcb
<ar>
(also, the pcb was mostly empty)
<ar>
i wonder if the production one is any different
<j_ey>
wasnt the devkit an ipad in a mini case? (ish)
<marcan>
there is a choke on the way of the USB lines
<marcan>
between the PD chip and the M1
<marcan>
so I know those are probeable
<ar>
j_ey: the cpu iirc was from the then-current ipad, but i think it had more ram
<marcan>
the production pcb is quite smaller than the intel one
<marcan>
anyway, the screwdrivers should arrive tomorrow... though tomorrow I have some stuff to do, so I'm not so sure if I'll have time, we'll see
<marcan>
worst case, monday (busy weekend)
<nskl>
i was wondering, are you folks expecting the wifi driver on macbookpro m1 to be especialy tricky to create ? or on the opposite, are you expecting it to be a relatively straightforward to do ? (like, for example, if it's well documented, or somehow similar chip being already well supported on linux ?)
<j_ey>
pipcet[m] has it working I believe
<j_ey>
i think with only minor tweaks + the firmware that you need to grab from macOS
<nskl>
it already started working ? great news ..
<nskl>
will there be many steps needed to grab relevant blobs to import from macos to linux side ?
<nskl>
i mean beside the wifi stuff you've just pointed out, will there be more firmware to get and import ? is it a one shot -kind of overall general all encompassing firware to grab- or will it be many little separated ones ?
<j_ey>
nskl: iboot loads all(?) the other firmware for us
<marcan>
nskl: it's not a new driver
<marcan>
it's a standard broadcom fmac chip
<marcan>
it just needs some patches due to some custom apple silliness and slight silicon differences
<marcan>
corellium already did that ages ago, someone just needs to go through and clean up the mess and submit it
<marcan>
as for the firmware, I'll probably make the installer grab it from the running OS and put it somewhere for the installed OS to use
<marcan>
the same chip is used in some Intel macs fwiw, so this isn't even M1 specific
<j_ey>
"10 files changed, 371 insertions(+), 75 deletions(-)" for the corellium wifi patch
<sven>
yeah, the corellium patch probably just needs to be split from a single commit to three or four of them and it needs additional code i think to grab the mac address from the device tree
<nskl>
i thought corelium port had no wifi, and no internal ssd support too, requiring us to use an external drive, among a few other shrtcoming, but maybe it was their first release and since then things improved that i didn't know about.
<marcan>
and general cleanup/rewrites :p
<sven>
probably
<marcan>
they added wifi later
<sven>
but shouldn't be a big deal
<nskl>
i see, thanks for the answers.. lots of fast progress lately .. that's awesome
<marcan>
the main problem with the corellium port is that it was a PoC port made with no intention of upstreaming, they just wanted a validation guest for their proprietary hypervisor
<marcan>
so they got lots of things to work, but lots of it in crazy ways that needed to be redone
<nskl>
that's the impression i had too, that's also why i stayed away from it, prefering to wait for asahi and proper port
<marcan>
there's a whole pile of drivers on the review pipeline already, I should send pmgr soon too
<marcan>
might see about writing the cpufreq thing tonight if I have nothing else to do, seeing as the hardware hacking stream was foiled by Apple's screws
* sven
should send tipd v2 and i2c as well
<j_ey>
sven: the new approach with the split looks also fine I think
<sven>
yeah, and since heikki prefers that separate interrupt for the apple chip it also became a bit simpler imho
<sven>
*interrupt handler
<sven>
also less chances of messing up some tps chip with weird quirks somewhere ;)\
<marcan>
:)
<marcan>
sven: can you describe the phy/xhci fail in a bit more detail? just want to have the info before I bring out the scope
<sven>
in gadget mode: if you disconnect the cable dwc3 never submits an USBDisconnected event and if you plug it in again you also get no USBReset or USBConnectionDone event
<marcan>
but it works on the other side, right?
<sven>
in xhci mode: if you disconnect the cable xhci sees a disconnected event but never gets another cable connected event. the port status indicates that the correct cable status though
<sven>
if I use a dumb usb-c -> usb-a adapter and i disconnect the usb-a everything works (in host mode)
<marcan>
and in gadget mode leaving VBUS on works for me
<marcan>
and this gets fixed with a phy/dwc3 reset?
<sven>
with a dwc3 reset, yes
<sven>
it also usually gets fixed with a partial phy reset (i.e. not what mac os, but just setting two reset bits)
<sven>
but that can sometimes mess up dwc3 completely
<marcan>
I'm going to do a quick check on the usb pins with a scope externally on my normal M1, see what happens there
<marcan>
is there some tipd poking necessary anyway?
<sven>
nope
<marcan>
(e.g. under m1n1)
<sven>
you just need to send that SPSS command (like m1n1 does) and then everything is autonomous
<sven>
macos always pulls the entire PHY into reset when a cable is disconnected and tears down xhci completely
<sven>
then when you connect a cable it just brings everything up again
<sven>
(it's pretty easy to see with that tracer you merged)
<marcan>
it stinks of hardware bug so much, but I just don't understand how it's even possible
<marcan>
like does the tipd glitch the phy or something?
<alyssa>
🍿
<marcan>
sven: stupid idea... what about the SMC I2C?
<marcan>
is it possible the *SMC* reacts to the hotplug and actively screws something up?
<tophevich[m]>
marcan: you could say you were apple "screwed"
<marcan>
:p
<alyssa>
marcan: in that one case, one would hope Apple could fix that in the SMC firmware and not the OS..
<marcan>
wait hold on
<marcan>
hotplugging just worked for me once, I swear
Guest512 is now known as svenpeter[m]
<svenpeter[m]>
I disabled the interrupts for the smc and it still didn’t work fwiw
<svenpeter[m]>
Did it work again afterwards?
<svenpeter[m]>
Because at least in m1n1 hot plugging works exactly once
<marcan>
it worked once, once
<marcan>
I can't repro
<svenpeter[m]>
:D
<marcan>
oh, it just worked again
<marcan>
svenpeter[m]: I just got it to work like 4 times in a row
<marcan>
and then it died
<marcan>
it's inconsistent
<svenpeter[m]>
Lol
<marcan>
(but once it dies it dies)
<svenpeter[m]>
Never worked more than once for me
<sven>
marcan: fixed it yet? :>
<marcan>
sven: no but I found something interesting
<marcan>
if I disconnect D+/D-, it works fine
<marcan>
if I disconnect CC, it works fine
<marcan>
if I disconnect CC, then D+/D-, then reconnect D+/D-, then reconnect CC, it works fine as expected (since once CC drops it'll detach the data pins from the PHY, so how could it do anything?)
<marcan>
but if I disconnect D+/D-, then CC, then reconnect CC, then D+/D-, it's dead
<marcan>
so there's a race, which explains the repeatability problem
<sven>
huh
<_jannau_>
also explains why it works with the usb-c/a adapter
<marcan>
no, that's host mode, not gadget mode
<marcan>
but yes
<marcan>
it works differently because vbus matters in gadget mode but not in host mode
<marcan>
sven: I have a theory that this isn't dwc3/the phy's fault, it's tipd's fault
<marcan>
we'll know for sure with the teardown
<marcan>
here's the thing: when I disconnect the data side, one of the lines goes up as expected (gadget pullup)
<marcan>
however, if I then disconnect CC and reconnect it, the pullup never comes back
<marcan>
that's total wack
<marcan>
the thing is, the ti chip has some kind of "protection" crap; I've seen it cancel modes for me when I drew too much current and such
<marcan>
it's possible that it sees the pullup voltage and hates it for some reason (maybe because it considers vbus not ready yet?)
<marcan>
and the whole phy/dwc3 reset dance? all just to turn the pullups off and on again enough for tipd to not hate it.
<sven>
lol
<marcan>
if I'm right, I'm going to say apple themselves haven't debugged this properly, and are convinced it's a dwc/phy problem, and are doing all that shit for nothing
<marcan>
(consider: software people figured out how to make this work and never talked to hardware people)
<j_ey>
marcan: well if you're right, lets see what happens in the macOS release after this is posted to LKML :P
<marcan>
:D
<marcan>
so where's the pullup enable bit...
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi
<alyssa>
j_ey: lmao
<alyssa>
i've seen some pretty perverse Mali errata in my time
<marcan>
>>> clear32(0x38228c704, 1<<31)
<marcan>
>>> set32(0x38228c704, 1<<31)
<marcan>
sven: that fixes gadget mode for me.
<marcan>
and that does, indeed, kill the pullups.
<marcan>
(stops the controller)
<sven>
lol :D
<marcan>
you probably want some delay there too
yuyichao has quit [Quit: Konversation terminated!]
<marcan>
since the tipd would have to notice
<marcan>
so the next plan of attack is dumping not dwc/phy regs, but *tipd* regs during this mess
<marcan>
dinner first though
<marcan>
only problem is if I fix this now, what will happen with the teardown? T_T
<marcan>
the other half of the story is what about host mode; that uses pull-*downs* so what's up with that?
yuyichao has joined #asahi
<marcan>
(it's possible we're dealing with two different problems here, of course)
<sven>
i originally thought that host mode was broken because i didn't setup the phy correctly for that fwiw (or, to put it different: i was very surprised when dwc just worked in host mode without any additional phy pokes)
<sven>
but IIRC i tried reproducing macos' phy pokes for host mode and that didn't fix anything
<marcan>
ah, but this is interesting. if I set it to SuperSpeed mode it turns off the pull-ups, but still wedges
<marcan>
i.e. if I replug, then switch to high-speed mode without a reset (which normally does turn on the pullups immediately), it doesn't
<marcan>
reset the controller and it does
<marcan>
so there's something else here
yuyichao_ has joined #asahi
<marcan>
anyway, dinner first
yuyichao has quit [Remote host closed the connection]
aleasto has joined #asahi
<marcan>
sven: also there is some other chip in the way, some kind of level shifter
<marcan>
and it has i2c too, and a reset line
<sven>
huh, interesting
<marcan>
and *that* is driven by the retimer chip
<marcan>
which is a whole separate big thing with JTAG etc
<marcan>
and firmware
<marcan>
wait no, it's on the CD3217
<alyssa>
🍿
<marcan>
the CD3217 is the i2c *master* for those other chips
<marcan>
well, that's one i2c bus I need to poke then
<marcan>
but this is getting real smelly in this direction
<sven>
so we'll just patch the CD3217 ourselves to fix this? :>
<marcan>
does... does the M1 support one fewer hub at HS than every other computer?
<marcan>
and only *two* at FS?
<marcan>
... I think I have a FS hub lying around, I should test this
<marcan>
who came up with this pile of fail?
<dottedmag>
marcan: The answer is on pages 2-4
<marcan>
well apple is first...
<marcan>
sven: so the public TI part has the i2c pins of the apple part as "reserved"
<marcan>
who wants to bet they're the same die :p
<sven>
wouldn't surprise me
<marcan>
ok, so the thing is, if the repeater gets reset, which I bet it does when the TI part detects a hotplug... the phy needs to know about that
<marcan>
because it's the phy's job to put the repeater into host or device mode
<marcan>
I don't think there's any kind of way for the phy to detect that the repeater got reset
<marcan>
if so, then we don't have much choice, though we might be able to get away without a big hammer reset and do something more surgical (e.g. that poke I mentioned for gadget mode)
<alyssa>
is the big hammer reset such a problem?
<alyssa>
it's ugly as hell, but... if macOS does it that way at minimum we know it interacts fine with all the other type-C port drama (particularly displayport and thunderbolt crossbar)
<alyssa>
on that note, does macOS do even more big reset hammer shenanigans when hotplugging dp/tb before/after usb?
<sven>
the moment you unplug the cable it already puts everything it can into reset
<alyssa>
lovely
yuyichao_ has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
yuyichao_ has joined #asahi
yuyichao_ has quit []
yuyichao has joined #asahi
<nskl>
you probably already thought about it, but, will it be possible to have this install scenario: format everything clean. do initial macos install on _an external_ drive, then proceed installing asahi on the internal drive, it would grab all the needed stuffs from macos on the external drive, then once everything is installed, remove external drive and enjoy single os linux install on
<nskl>
mac m1
nsklaus has joined #asahi
<marcan>
nskl: you do not need to do any initial macos install; you can use system recovery
<marcan>
you *do* need to have had a certain minimum macos version installed; if you haven't, you can just upgrade the stock macos first before wiping it, or do it on an external drive.
<nsklaus>
marcan: but, would it be possible at all to get rid of the recovery partition and have linux only stuff on the internal drive ?
<marcan>
no, that's like saying would it be possible to remove the UEFI firmware from a PC and have linux only on the drive
<marcan>
recovery mode is part of system firmware, and starting with macOS 12.x you also need an additional copy of recoveryOS for each installed OS, Linux or otherwise
<marcan>
technically you *could* wipe some of this stuff after installing linux, but you would end up with a half broken system that e.g. cannot use the boot picker
nskl has quit [Ping timeout: 480 seconds]
<nsklaus>
i see .. i enjoy mac M1, low power consumption, good cpu, gfx and all, but that few gigabytes bios like uefi partition always seemed to me like waste of space
<marcan>
it's how Apple designed these machines
<j_ey>
nsklaus: just pretened the SSD is 250G instead of 256G or something :P
<marcan>
yeah, pretty much
<nsklaus>
maybe someday someone will find a cure for the apple fat "bios"
<marcan>
there's no cure, this is all signed secureboot
<marcan>
it's part of how the machine is designed
<marcan>
there's no way around it, wipe recoveryOS and you lose the boot picker. it's literally deleting part of the boot UI.
<nsklaus>
and there would be absolutely no way to replace that "boot picker" completely ?
<marcan>
no, it's signed
<nsklaus>
darn ;)
<marcan>
on the plus side, these machines are probably *the* most secure user-controllable secureboot systems available to end-users today
<marcan>
if you want a machine running your own OS that can withstand an evil maid attack, these are your best bet
<marcan>
they are practically the only system designed with a "physical access is not enough" philosophy
<marcan>
and you can build a secureboot linux on top of them
<marcan>
(at least you will be able to do it properly once we support the SEP for storage encryption and such)
<nsklaus>
wait until someday apple get the brillant idea to pull the plug and remove third party OS option .. you never know with them what strange decision they could come up with all of sudden
<nsklaus>
sony did just that too on ps3
<marcan>
they spent countless developer hours making this work, they aren't going to remove it
<nsklaus>
glad to hear
<marcan>
sony did that on the ps3 because they're incompetent and can't actually build a secure system, so they chickened out when geohot found a silly glitch thing
<marcan>
apple are way beyond that
<marcan>
and the M1s do not rely on hypervisor nonsense for security
<marcan>
in fact, as far as I know they are the only secureboot system that offers *per-OS* security modes
<marcan>
which allows you to do things like run full-DRM macOS with Netflix and iOS apps and all that walled garden stuff, *and* Linux, dual-boot
<marcan>
best of both worlds
<marcan>
can't do that on Android ;)
<nsklaus>
i see there might be advantage too to their big blob 6gb bios. thanks for pointing it out, that's also reassuring to hear they probably won't suddenly change their mind about allowing third party os to run on their hardware
<marcan>
it's not just a third party OS, the "official" reason for all this is to run self-built versions of the macOS kernel
<marcan>
and either way, as long as they allow third-party drivers, it's basically the same security-wise
<marcan>
so there is no good way they could lock all this down without hurting macOS developers
<marcan>
that's *why* they spent all the time on this; Apple management didn't make it like this for us (but I'm sure Apple engineers were thinking of it).
<marcan>
j_ey: does it actually say that somewhere?
<nsklaus>
'xnu' is the name apple gave to their kernel, is that right ? so it is necessary to build a custom macos kernel to allow to boot linux on m1 ?
<marcan>
that's why it builds as a mach-o executable like xnu
<marcan>
it's the same way m1n1 boots "linux" kernels but it can boot u-boot which happens to be built in the same format as a linux kernel; it doesn't have to care that what it's booting is not linux
<marcan>
as long as whatever we boot "looks" like xnu to the machine it will work
<marcan>
it doesn't have to be xnu
<nsklaus>
i understand better now
<nsklaus>
i was wondering where m1n1 was fiting in and in what form. i understand better now
<marcan>
that blog is very helpful for understanding how things are supposed to work, but the only part that is the same for us is the bit that mentions `kmutil configure-boot` near the end
<marcan>
instead of OpenSource.kc you use m1n1.macho. that's it.
<marcan>
(but our installer automates/guides you through that)
<ar>
170426 <@marcan> so there is no good way they could lock all this down without hurting macOS developers
<ar>
marcan: they do have a history of hurting developers
<marcan>
to a *point*
<nsklaus>
ar: and users alike
<marcan>
but they're not going to design all this stuff just to throw it away
<marcan>
and they're not going to throw it away for M1X/M2, and we're fast enough that by M3 things will be awesome and they'll have to think very hard about the PR hit if they actually try to make the next generation truly locked down like iOS ;)
<nsklaus>
in worst case scenario we could do like the jailbreak tools do, and warn users to not update to certain macos version (to get incompatible, updated firmware)
<marcan>
they aren't going to retroactively lock it out on existing machines
<marcan>
that would be PR suicide
<marcan>
at most they might decide to drop the feature in a future generation, but that's years away if it ever happens
<marcan>
remember, Sony lost a class-action due to this
<marcan>
and should've also been sued under other laws (e.g. european warranty laws)
<marcan>
it is literally illegal to do this
<nsklaus>
that's reassuring to hear
<marcan>
and Linux on M1 is going to be much higher impact than Linux on PS3 ever was
<nsklaus>
if someday linux on M1 allow users to run 32/64bits x86_64 apps, and eventualy virtualize macos too, you might have a better macos macos experience running it through linux instead. that should raise some eyebrows ;)
<nsklaus>
i was thinking of fex_emu and your hypervisor too
<nsklaus>
i tested quickly fex_emu in a vm, and that worked quite nicely already (my test is from a few months ago)
<marcan>
yes, fex is what I intend to provide in our images
<marcan>
virtualizing macos is a bit of an issue, you'd have to run the vmkernel version of macos at least and GPU support requires writing a Metal implementation
<marcan>
so I don't really count on graphical macOS ever being practical in a VM on Linux
<marcan>
(on arm64 systems)
<marcan>
OTOH running *Linux* in a VM on Linux should already be faster than running it on macOS, since we use the M1's vGIC and they don't ;)
<marcan>
faster IPIs/IRQs
<maz>
marcan: it certainly is one of the fastest VM host I have in my zoo.
<marcan>
:D
<marcan>
are you running with upclocked CPUs?
<maz>
marcan: very close to N1, and that's only running on the small cores (until you give me that cpufreq driver).
<marcan>
if you're booting via usb/proxyclient, run experiments/cpu_pstates.py before
<marcan>
that'll put all the big cores at max
<marcan>
actually if you're not on 12.x it might not quite be max
<marcan>
just pushed a fix for that
<maz>
no idea, I never booted macos since March.
<maz>
(since I got the machine, actually)
<marcan>
then definitely not, it wasn't out yet :)
<marcan>
(well, it's in beta now)
<marcan>
I'm actually not sure what machines/versions need that, but whatever
<marcan>
(mine doesn't, other people's do apparently)
<marcan>
either way, I'll see about poking at the cpufreq driver tomorrow, should be pretty easy
<marcan>
already gathered all the info (measured latencies too)
<marcan>
maz: make sure you chainload *first* after a reboot
<marcan>
before running that script
<maz>
that's what I do.
<maz>
but maybe I need to give it a power-off instead of a reset...
<marcan>
reset should work, hm
<maz>
reconnection times out, and nothing after that.
<marcan>
ah, are you on the second USB port? I noticed something weird about chainloading over that today, on my existing installed m1n1 (but after a chainload it's fine, so whatever it is I fixed it I guess?)
<maz>
leftmost port.
<marcan>
looking which way?
<maz>
when facing the back of the mini
<marcan>
should be the first port then
<marcan>
hm, not sure then, hard to debug without serial :/
<marcan>
anyway, it's no big deal
<marcan>
I should get some sleep :)
<maz>
please do!
<marcan>
thanks for testing!
<maz>
thanks for everything! :D
<j_ey>
/win 84
<j_ey>
err, lala ignore that
<psykose>
that's a lot of windows
<j_ey>
im too lazy to clean them up
nsklaus_ has joined #asahi
nsklaus has quit [Read error: Connection reset by peer]
artemist0 has joined #asahi
artemist has quit [Remote host closed the connection]
<steev>
relatable
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi
jlkjlk has joined #asahi
jlkjlk has quit []
Retr0id has quit [Read error: Connection reset by peer]
Retr0id has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
___nick___ has quit [Ping timeout: 480 seconds]
phiologe has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
* alyssa
is getting close to a DCP driver that she's not completely embarassed by
<alyssa>
only like... 95% embarassed
yuyichao has quit [Ping timeout: 480 seconds]
<alyssa>
* for the Mini only. No promises it won't set your MacBook on fire.