ChanServ 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:
<MTecknology> That question went a bit over my head, particularly the *util stuff. I don't care to leave mac on here either (if it's not required, I think I read that m1n1 is sorta mini s/unix/mac/).
<marcan> MTecknology: you probably want to leave macos on there for updates, we're going to recommend dual-boot for a long while until we figure out a way to do firmware updates from linux
<alyssa> marcan: aren't you supposed to be asleep
<marcan> I just woke up
<alyssa> 😴
<pipcet[m]> sorry about that. I think all you need to play with m1n1 is the .macho, boot into recovery mode, open a terminal, run *util in the right order and with the right parameters, and reboot. you definitely do want to keep macos around on the nvme, though
<marcan> MTecknology: but yeah, right now the recommended thing to do is follow the dev guide to get things installed
<marcan> the main purpose of the dev guide is to get people to install a second macos partition to replace with linux; our installer will eventually do that without the macos step, but for now this is how it goes
<MTecknology> Does the dev guide still apply to a dual boot?
<marcan> the dev guide gives you a dual boot environment
<MTecknology> ah
<marcan> and the reason for that is that dual-booting is a low level feature on these machines; you need multiple "native" macOS installs (from the POV of the machine) to do it sanely
<marcan> right *now* it doesn't matter much and you can do what pipcet[m] says and just stuff m1n1 on top of a single macOS install
<pipcet[m]> when in doubt, listen to marcan :-)
<MTecknology> whew... if I were still drinking (unfortunate project name for me... many fond memories where that beer was involved), I'd be grabbing a few cans of asahi to drink while reading the guide
<marcan> eventually there will be some curl|sh thing that does everything for you :)
<alyssa> teetotalist noises
<marcan> anyway, the dual boot thing will start mattering soon, among other things because I'm going to be requiring people to use specific macOS versions as a base (for firmware ABI reasons; it's unstable) and because the SEP will be very unhappy if two OSes try to use the security stuff in one context
<marcan> basically Apple designed the thing for dual-boot at *their* level and we have to use it if we want to keep things sane :)
<MTecknology> Why do I suspect that even underneath, they treat every minor revision number as an excuse for absolutely any changes they feel like?
<marcan> half the firmwares are part of the OS boot bundle, so yes, they don't care about stability
<MTecknology> just like golang! :P
<marcan> in fact, uh, I've been ranting about this recently but the way they did their display controller firmware is to just take their driver and move *half* of the classes to firmware, then build an RPC mechanism that lets them call back methods on the other side, in both directions, with multiple execution threads even
<marcan> so it's literally an IOKit driver split down the middle, one side in firmware
<marcan> you can imagine how stable that is :p
<marcan> (and yes this is going to be fun to support in linux)
<marcan> this is why I've decided there will be "blessed" macOS bootloader bundles (=firmware bundles) that Linux supports
<marcan> no way I'm handling every time they touch the ABI in a point release
<marcan> thankfully none of this matters if you do native dual-boot, as the OSes have separate bundles, so the real macOS install can be updated separately
<marcan> the eventual installer will prompt you for a bundle/version to use out of the list of blessed ones, and handle installing all that without involving a full macOS install
<marcan> and the idea is that it'll prompt you for a distro image to install out of a list of supported ones (whatever people feel like maintaining), or you can just install the base m1n1+u-boot and make space on the partition table, and then handle the actual distro install like on any other ARM64 UEFI system, since you could boot from USB after that point
<MTecknology> any thoughts toward disk encryption? Will it be possible to use native mac utilities for that?
* MTecknology is getting excited and starts going through the documentation
<marcan> I'm not sure how that's done at the NVMe level, but at the very lease you could hook the SEP into dm-crypt and get secureboot-tied disk encryption that way
<marcan> using the native acceleration would require more research
<marcan> I think macOS does some fun stuff with per-file keys and such, or can (for iOS use cases), which is one reason why they extended (=broke in incompatible ways) their NVMe implementation
<marcan> (this isn't new, the x86 macs with T2 already had this)
<marcan> eventually I want to get PAM integration with the SEP so you can use hardware password verification, Touch ID, and all that from linux
<marcan> particularly interested in whether we can us ed25519 keys in that framework; right now you can create ecdsa ssh keys on macOS backed by the SEP, because that's all their user API supports, but I think the low level API probably does ed25519 too
<alyssa> marcan: itmt
<alyssa> DCP stream? 👀
<marcan> breakfast first :p
<alyssa> 🍎
<MTecknology> revive, eh?
<MTecknology> that's an interesting feature only possible by limiting the hardware your OS can run on
<MTecknology> wow... I now wish I got the 500GB model.
<MTecknology> According to the disk utility, I'm only using 15.4 GB. Can I just make my first command 'diskutil apfs resizeContainer disk0s2 50GB' instead and leave the rest the same?
<marcan> MTecknology: 50GB is not enough to update macOS
<marcan> their updater is insanely inefficient
<marcan> you need at least 70GB to keep it updatable
<marcan> re: revive, all the DFU stuff is already supported on linux with idevicerestore
<marcan> if you totally brick the thing (= wipe nvme including 1TR), you need to restore that way
<marcan> which means plugging it into another linux box with a USB cable and running idevicerestore, for us :)
<marcan> thankfully the libimobiledevice guys already implemented M1 support into it some time ago
<MTecknology> there isn't going to be a whole lot of room for linux after 70 for the main os plus 70 for the stub... I had planned (and might still plan on) trying to run my work VM from within linux on this hardware.
<MTecknology> I'll just appreciate it that much more when it's no longer needed. :D
<MTecknology> crud, I didn't read far enough in advance of running commands and just ran the addPartition commands. I didn't realize I should have been looking at diskutil list to figure out what the right disk name was.
<alyssa> raise your paw if you're sleepy shepherd 🐶
<MTecknology> I /think/ it looks like the docs are perfect for a default setup so they worked anyway. At least, I see that the LR volume created is 104 GB, which is what I expected. 70+70+1+104 == 245 ~= 250 GB
* MTecknology reads more betterer from now on
<MTecknology> (+5 GB recovery)
<alyssa> MTecknology: my chromebook is 32gb and it's good
<alyssa> 100gb for linux sounds delux
<alyssa> deluxe
<MTecknology> RDR2 is already over 100 GB, and you can't expect me to not be playing that through linux on M1, can you?
<alyssa> rdr2?
<alyssa> marcan: Is it safe to downsize to the stub partition post install btw?
<MTecknology> red dead redemtion 2; a game that actually has better performance through valve's compatibility layer than on native windows
<milek7> and crashes every 2 hours
<MTecknology> lucky bastards... once it starts crashing for me, it doesn't stop crashing. At best, I might get 5 minutes without rebooting back into windows and back into linux to clear whatever with nvidia
<MTecknology> or something like that... irunno
<MTecknology> When it actually works, I can get weeks of play time (I leave it loaded once it's working) without a crash.
<milek7> wat
<MTecknology> What crash were you referring to?
<marcan> alyssa: yes, but you won't be able to update it further
<marcan> though at this point, by the time I start writing the DCP driver and fixing the firmware version required, I'll probably spend a few days writing an install/update script that can avoid having to do a full macos install
<marcan> been thinking a lot about that in the background, just haven't started writing the code :)
<marcan> mrkajetanp_: eventual stubs will be <5GB
<marcan> just needs to be enough for the paired recovery (new thingy required in 12.0...) and the bootloader/firmware blobs
<marcan> er , MTecknology
flying_sausages has quit []
flying_sausages has joined #asahi
<MTecknology> yep, that'll be quite the savings indeed
<chadmed> marcan: 70GB? i cant believe how inefficient macos has become. i remember back in the day when i got snow leopard running on my phenom ii pc off a single layer installer dvd and a 16gb root partition. bringing across all the ios apis really has been a mistake
<alyssa> marcan: Cool. Speaking of, did you eat breakfast? 😇
<MTecknology> The craziest part of 70 GB is how the final install isn't /that/ big.
hashcheck has joined #asahi
<chadmed> macos userspace is based on gentoo now, and so it requires space for all the sources to be downloaded and built :-P
<MTecknology> awe... "If everything went well, you can restart and boot into m1n1!" --> "Custome kernel failed to boot."
<MTecknology> oh, I missed a step, where was that..
<MTecknology> ah, the thing I thought I missed was the environment variable for the other option.
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
hashcheck has quit [Quit: Textual IRC Client:]
<MTecknology> m1n1!!!
<marcan> chadmed: it's their updater. it has to download the update once, then install it to a snapshot, on top of the existing OS
<marcan> so that's 3 copies if you're counting
<marcan> and I think there's probably another one needed for some silly reason
<marcan> alyssa: I did now :p
<alyssa> marcan: Nom
<klange> looking forward to finally joining the club... between august 9th and 11th, because I had to have an US-QWERTY keyboard instead of a JIS one that would have been in stock locally... also maybe that joke about 'm1 toaruos when' might be less of a joke
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
quarkyalice has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven> marcan: no, it isn't. that's where the hack part comes in ;)
<marcan> sven: lol, then what is it?
<marcan> like a binlog?
<sven> it's called Log just because it also needs a buffer
<sven> something like that, yes
<marcan> is the ring buffer structure the same?
<sven> no
<marcan> lol
<sven> just that get buffer request is the same
<marcan> heh
<sven> kdebug is more fun i think. it should contain tracepoints somehow
<sven> also, please double check the endpoint id -> class assignment. iirc they were wrong at some point and i'm not sure i fixed them
<sven> and i think it'll be fine for dcp probably, but syslog is a little bit more complex
<sven> the init message sends a max number of entries and the length of the syslog messages
<sven> it's not just constant 0xa0 or whatever
<marcan> I know that
<marcan> that's in the tracer
<marcan> which you didn't share code with :D
<sven> oh, is it? but then you fixed it at some point
<sven> it used to be constant 0xa0 in there
<sven> it's hardcoded for dcp
<sven> but it's different for other asc
<sven> doesn't matter for DCP unless they change it ;)
<sven> marcan :further down
<sven> and the 0x80 is the msg size
<sven> + the header which is always 0x20
<sven> 0x80 + 0x20 = 0xa0
<sven> marcan: 31, 24
<sven> (might be larger, but who knows)
<sven> marcan: i think at least 3 is wrong there fwiw
<sven> i think crash is 1
<sven> and 3 is this kdebug thing
<sven> i think if you don't start some it'll hang
<sven> (at least for the system endpoints)
hashcheck has joined #asahi
<MTecknology> hrm... where was I, before my cat decided to get hurt and crap all over a room (plus a vet visit)?
<MTecknology> I have my mac mini booted up to m1n1 with the last line saying 'Running proxy...' I built linux from the asahi/linux branch, grabbed the debian initrd, and.... I'm getting a python error. Definitely not the kind of error I expected getting so close to what should be actually running something.
<sven> marcan: send 0x22 or 0x40 to the crashlog ep
<sven> that's "force crash"
<sven> with 0x40 it even survives
<sven> it'll just send a crashlog and continue
<jix> MTecknology: the pypi package is called pyserial not serial AFAICT
<MTecknology> rm -rf ~/.pip_dir; then replacing that pip install serial w/ pyserial seems to have worked. Now it's complaining about 'could not open port /dev/ttyACM0:' which I imagine has to do with the thunderbolt cable or something.
<MTecknology> jix: nice, thanks! :)
<sven> marcan: just after the DART
<sven> dart offset + 0x4000 or so
<sven> it's not in the device tree though but i believe that's this DAPF thing
<sven> hrm.
<sven> depends on the device
<sven> iirc TLB cache thing was before?
<MTecknology> With this thing booted up to m1n1, if I connect my (linux) laptop to the thunderbolt port closest to the power plug using a cable that I'm super confident is a proper thunderbolt cable (but possibly not that spec thing...), should I expect to see something showing up in dmesg?
<MTecknology> (spec thing --> SBU1/2 pins)
<MTecknology> I had two 4k displays running using this same cable, so I'm pretty confident about everything except that bit.
<marcan> MTecknology: you don't need to use any fancy cables for USB mode, which I presume is what you want to use
<marcan> that's only if the other side is another M1 Mac and you want serial
<_jannau_> connect the cable before booting the mac mini
<marcan> any standard USB cable will do
<sven> marcan: my notes say the regs might be [config, sid, start (64bit), end (64bit)]
<sven> dunno how accurate that is
<MTecknology> Yeah, usb mode
<sven> i never got this to work correctly
<MTecknology> ooooh, there's the usb device!
<_jannau_> MTecknology: the cable needs to be connected before booting the mac mini
<sven> marcan: can you check if you can write these? i believe the DAPF lockdown bit is different from the DART lockdown bit
<MTecknology> aye, thanks for mentioning that. I just got to the installer! :D
bisko has joined #asahi
<sven> :(
<sven> not sure if that's correct :D
<MTecknology> no keyboard... I saw something about not being able to use the on-board usb-a ports, so I thought using my dock (thunderbolt/usb-c) would work.
<sven> so on ANS it asks for a physical address and then also sends the same one back but that's expected because it goes through SART
<marcan> docks definitely won't work
<marcan> there is no thunderbolt support
<marcan> nor is USB-PD really in shape
<sven> on SMC it never asks for an address, it just sends me an address in that mmio shared memory window
<MTecknology> ah
<marcan> you should use a dumb USB hub
<_jannau_> MTecknology: thunderbolt/pci-e will not work. USB-C should work but has the same contraint of being connected at boot
<sven> marcan: i think i messed up the endpoints :D
<sven> maybe 3 gets the two messages
<sven> remember how i called this a "hack"? :P
<sven> that crash_soft/hard should go into crashlog though
<MTecknology> _jannau_: I assume that means "usb-c should work, but not via any usb-c/tb dock"?
<MTecknology> I don't have any hub, and the one I used to have was flaky on the best of days. I was going to live with just the keyboard if it had to be connected at boot, but my only usb-a->c adapter is one of those tiny things, so... thanks to apples brilliant orientation of those ports, I can only stick exactly one device in the port closest to the power plug.
<MTecknology> which I need for booting up, so... it seems to proceed further I kinda have to get that dumb hub.
<MTecknology> Most docks are basically just a not-dumb usb hub, aren't they?
<MTecknology> <-- Is this what I want?
<_jannau_> MTecknology: a tb dock will not work unless it can be somehow forced into usb3 mode on the dock side
<MTecknology> heheh... that just made me wonder if I can "force" it to usb3 mode by using a cheap cable.
<MTecknology> (cheap + no tb claim)
<_jannau_> the hub looks like it is USB 3.0 only and should work fine
<sven> marcan: 32 bit at most
<sven> technically it can do more
<sven> but i haven't seen any device with more than 32 address lines connected
<sven> in an older iphone there's a DART with 4k pages which required more iirc
<sven> there's even a bypass DAPF bit in the TCR fwiw
<MTecknology> _jannau_: excellent, it'll be here on tuesday :)
* MTecknology should make some docs notes now before forgetting where I stumbled... may as well make a pull request from all of the extra help/info. :)
aleasto has joined #asahi
<amw> Are all these modules asc, dcp purely tracing functions at the moment?
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ella-0[m] has joined #asahi
bisko has joined #asahi
bisko has quit []
bisko has joined #asahi
bisko has quit []
<x56> '
bisko has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hashcheck has quit [Quit: Textual IRC Client:]
norwoodites has joined #asahi
pinskia has quit [Remote host closed the connection]
pinskia has joined #asahi
norwoodites has quit [Ping timeout: 480 seconds]
bisko has joined #asahi
<marcan> I'll jump back on stream shortly
<sven> you can also NMI the coprocessor if the crashlog msg is too slow fwiw. write32(asc_base + 0x10004, 0x11) followed by write32(asc_base + 0x10024, 0x1) i think
cth451_desktop has quit [Remote host closed the connection]
cth451_desktop has joined #asahi
<dougall> anyone know if it's possible to load modified AGX (or other) firmware? I'm not clear on whether or not that's a security boundary
<marcan> dougall: unlikely
<marcan> I think everything preloaded by iBoot is locked
<alyssa> so what's the agx firmware buddy about
<alyssa> kext
<marcan> old code
<marcan> from before they started doing this
<alyssa> groan
<alyssa> apple sure are special
<marcan> there's also a whole display driver that doesn't use DCP, you know
<alyssa> marcan: The good news is that with all this firmware tucked away in iBoot, Asahi GNU/Linux-libre will be FSF endorsed 😂
<marcan> as long as you don't want wifi
<alyssa> it's a mac mini
<alyssa> why would i want wifi
<_jannau_> or bluetooth
<klange> why is wifi so universally cursed... [don't answer that, I know it's radio transmission laws / paranoia about them]
<pipcet[m]> I'm a bit surprised Apple actually licensed a broadcom chip instead of doing their own thing entirely, though.
<marcan> it's not licensed, it's just a broadcom chip
<marcan> they've been using broadcom for wifi since time immemorial
<marcan> (and for other things)
<dougall> (thanks - bit of a shame from the perspective of exploring the hardware, but probably to be expected since that's effectively what intel and nvidia do)
<pipcet[m]> it's a broadcom chip that's decidedly weird compared to the others, though, and I don't think that's just different firmware
<marcan> apple have also been customizing firmware for ages (see: AirDrop etc)
<_jannau_> in addition developing their own 5G modem has probably much higher priority than wifi/bt
<Ariadne> probably not
<Ariadne> there’s no business case for it
<alyssa> Ariadne: apple fabs otoh...
<Ariadne> apple fabs i could see
<phire> it's really hard to start a fab, would take years
<phire> TSMC would know the whole time that apple was 'replacing' them
<alyssa> phire: Even if they did know... boiling frog, right?
<phire> as far as I know, TSMC aren't vindictive or anti-competive
<alyssa> because they have no viable competitors? :P
<phire> They are current fabbing intel chips
<phire> I do wonder if Apple gets paranoid in their interactions, assuming that other companies will treat Apple like they treat everyone else
<Ariadne> modems though, like there are many options that are good on the market now (almost all from qualcomm :p)
<Ariadne> doesn’t make sense to make a modem
<Ariadne> intel has some decent SKUs too
<Ariadne> quectel also, but apple won’t ever use quectel
cth451_desktop has quit [Remote host closed the connection]
cth451_desktop has joined #asahi
pinskia has quit [Remote host closed the connection]
pinskia has joined #asahi
yuyichao has quit [Quit: Konversation terminated!]
bps has quit [Ping timeout: 480 seconds]
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi
roxfan2 has quit [Ping timeout: 480 seconds]
<alyssa> /join #dri-devel
yuyichao has joined #asahi
bps has joined #asahi
<arnd> Ariadne: I don't think Intel has any modem development left, maybe they just retained the rights to keep selling the old SKUs to existing customers?
<Ariadne> no idea. most of the modems we deal with in alpine are either quectel or qualcomm
<Ariadne> tho i could be wrong on that claim, should verify with the pmOS crew to see what their picture looks like
<arnd> I thought quectel just uses qualcomm chips
<Ariadne> they might
<Ariadne> they do use qmi
<Ariadne> i assumed they were knockoff chips
<arnd> IIRC most others that build their own chips (spreadtrum->unisoc, samsung, via->intel, infinion->intel->apple, hisilicon, mediatek) license the DSP plus 4g/5g software stack from CEVA
<Ariadne> i mean i just interact with these things, i admittedly don’t fully understand the supply chain
<Ariadne> :p
bps has quit [Ping timeout: 480 seconds]
<alyssa> marcan: You'll need to swap/present
<alyssa> (to "flush" the changes)
<hablerentand[m]> What USB-C to USB-A adapter/hub do you use for keyboard support? I still have not been able to get the USB keyboard to work on my mac mini, and I'd like to rule out that it is not an adapter issue. Thanks in advance!
<alyssa> marcan: Otherwise if you change multiple properties in a row and you're unlucky with the timing w.r.t vsync you'll get a junk frame in the middle
Spectrejan[m] is now known as GatekeeperJanwithoutBeer[m]
<alyssa> not just the "first swap", I expect a swap is needed for changing any property at any time
<alyssa> because, again, junk otherwise.
<sven> hablerentand[m]: preferably some adapter that's as dumb as possible
<sven> essentially only usb 2 works until i get around to writing the full phy driver
<sven> unrelated to that, can i just download some $random-distro userland from somewhere? i wanna use nvme-cli and adding that to my initrd sounds painful
<alyssa> sven: arch linux arm has a generic arm64 rootfs
<sven> perfect!
<alyssa> didn't try on the M1 but should Just Work if you're supplying the kernel
<sven> sounds good. i should probably also switch to a sane .config though
<alyssa> sven: I posted mine yesterday, it's yours with working systemd and usb net
<sven> ok. let's see.
<sven> [ 0.448653] apple-mailbox 277400000.mbox: syslog message: nvme_admin_ans2.c:2729: Invalid namespace 0 <-- i wonder what that's about. afaik this, 0 should be valid namespace :/
<sven> *as far as i understand this
<pipcet[m]> really? I have no namespace 0 on the M1, and no namespace 0 on the intel machine...
bps has joined #asahi
<sven> oh.... it starts at 1 :D
<sven> yeah, okay, that epxplains it
<sven> *explains
<jannau> sven: is based on the arch linux arm distro config
<jannau> the generic arch linix arm rootfs works without problems
<alyssa> sven: duh, it's M1, not M0 /s
<sven> ah, ofc!
jbowen has quit [Quit: leaving]
robinp has quit [Remote host closed the connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
bisko has quit [Quit: Textual IRC Client:]
Raqbit has joined #asahi
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
<sven> pipcet[m]: you've had some issues with nvme, haven't you? any simple way to reproduce them?
<sven> 'cause i've been trying to break it but it's been surprisingly stable so far
<sven> the worst i managed to do were these syslog message when trying to read from one of the other two namespaces:
<sven> apple-mailbox 277400000.mbox: syslog message: util.c:4121: element=PANICLOG written size=2097152, host request trimmed to end of written content
<sven> apple-mailbox 277400000.mbox: syslog message: util.c:4145: Util read unmap element: 8, lba: 512, size : 24
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
kenzie has quit [Quit: The Lounge -]
kenzie has joined #asahi
grange_c has quit [Ping timeout: 480 seconds]
hl` has joined #asahi
grange_c has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
<alyssa> sven: +"coprocessor sent shmem buffer with 0x%zx bytes at 0x%llx outside of the configured region 0x%llx...0x%llx",
<alyssa> PRIx64 instead of %llx methinks
<alyssa> though i guess the kernel has prior art for either
<alyssa> +/* A2I = Application Processor (i.e. we) to I/O Processor (i.e. usually RTKit) */
<alyssa> Nit: change (i.e. we) to (us) and (i.e. usually RTKit) to (usually RTKit)
yuyichao has quit [Ping timeout: 480 seconds]