<chadmed>
nicolas17: there is no aarch64 build of steam, there's not even a real amd64 build lmao its still 32-bit which is why you need a bunch of i386 libraries installed to run it
<chadmed>
this is handled with thunks in fex and box86 i believe, and box64 just calls box86 for 32-bit code
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
doggkruse has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
doggkruse has joined #asahi
the_lanetly_052__ has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
pyropeter1 has joined #asahi
PyroPeter_ has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
terpstra has joined #asahi
terpstra has quit [Remote host closed the connection]
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ptudor_ has quit [Ping timeout: 480 seconds]
ptudor has joined #asahi
nicolas17 has quit [Ping timeout: 480 seconds]
guillaume_g has joined #asahi
ptudor has quit [Ping timeout: 480 seconds]
X-Scale` has joined #asahi
X-Scale has quit [Ping timeout: 480 seconds]
X-Scale` is now known as X-Scale
ptudor has joined #asahi
guillaume has joined #asahi
guillaume_g has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi
MajorBiscuit has joined #asahi
Catyre has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi
Catyre has quit [Ping timeout: 480 seconds]
nela has quit [Quit: leaving.]
nela has joined #asahi
neatsquirrel has joined #asahi
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi
the_lanetly_052__ has quit [Remote host closed the connection]
doggkruse has joined #asahi
kov has joined #asahi
doggkruse has quit [Ping timeout: 480 seconds]
doggkruse has joined #asahi
ptudor_ has joined #asahi
ptudor has quit [Ping timeout: 480 seconds]
doggkruse has quit [Ping timeout: 480 seconds]
<redflag[m]>
hi! i was thinking of getting an M2 macbook, am i right in assuming the 14" model should be relatively easy to bring up? presumably it should be at feature parity with the 13" with only a tweaked dtb
<_jannau_>
which 14" macbook?
vvv[m] has joined #asahi
<redflag[m]>
haven't fully decided, probably the 10-core one but if M2 is similar to qcom that should(?) just be 2 more nodes in the dtb
<redflag[m]>
* to qcom stuff that should(?)
<vvv[m]>
hi! after my M1 macbook air battery went to zero, I can’t boot to mac os, only to asahi
<redflag[m]>
redflag[m]: at least, im assuming that the m2 model will release soon with similar specs lol
<vvv[m]>
is this known to happen and is there known solution?
<_jannau_>
redflag[m]: are trying to decide whether to get a m2 macbook or a 14" macbook pro with m1 pro/max?
<j`ey>
I think theyre talking about a hypothetical m2 pro/max
<_jannau_>
vvv[m]: the first time I heard of it. how does not booting to mac os look exactly
<redflag[m]>
supposed to be coming out soon from what i gather, was just curious if porting was hard previously (e.g. going from m1 to m1 pro) so i should know if i hold off till fall or just buy the 13" m2
<redflag[m]>
sorry if i was confusing
<vvv[m]>
disregard what I said earlier, I forgot that I need to boot with pressing the power button on whole time until options. for some reason I was starting with power button, then releasing, and then holding it :D
<vvv[m]>
(probs because I have not got much sleep recently because of newborn baby.)
<_jannau_>
redflag[m]: we have no information about m2 pro/max. I say it's likely that the effort to support it is similar to the m2 bringup
<redflag[m]>
fair enough. guess i'll just get the 13" then since im impatient
<j`ey>
redflag[m]: but it has a touchbar!
<redflag[m]>
isn't it broken in linux tho lol
<_jannau_>
redflag[m]: but I would be surprised if macbook pro 14"/16" with m2 processors are launced before end of october
<redflag[m]>
oof
<redflag[m]>
13 it is
<redflag[m]>
is the internal ssd upgradeable..? 512 feels tiny
<_jannau_>
if you can't wait the current 14" would be an option too
<_jannau_>
no, the ssd is not upgradable
<redflag[m]>
yea but i gathered the m2 is a significant upgrade, don't wanna buy a more expensive and worse product
<redflag[m]>
_jannau_: fair, it is apple
<Lucy[m]>
Doesn't seem to be that significant to be fair
<redflag[m]>
oh?
<j`ey>
and 8cores m2 vs 10cores m1 pro might be a reason to get the current 14"
<_jannau_>
and I wouldn't call a 14" mbp with m1 pro a worse product than the m2 mbp 13"
<redflag[m]>
huh. for some reason i thought the m2 was just vastly superior
<Lucy[m]>
Slightly faster single core speed and better power consumption, but that was never a problem on these laptops
<redflag[m]>
single core is useless for me so
<redflag[m]>
yea looking at benchmarks m1 pro is vastly better
<redflag[m]>
thanks!
<Lucy[m]>
No problem! Seems like a nice chip.
<Manouchehri>
redflag[m]: The Touch Bar isn't even supported very well in macOS :P
<redflag[m]>
yea that sounds like typical apple stuff lmao
tomtastic has joined #asahi
janrinze has quit [Remote host closed the connection]
kloenk_ has joined #asahi
kloenk has quit [Ping timeout: 480 seconds]
kloenk_ is now known as kloenk
amarioguy has quit [Quit: Leaving]
<nsklaus>
the touch bar, the notch, the removal of external ports, the removal of magsafe, removal of 32bit support in macos, deprecating opengl when their own stack (metal) isn't finished, they buttefly keyboard system, the macos new UI theme, many of apple broken ideas that they are beta testing on the general public.
<nsklaus>
*the butterfly keyboard
<ktz_[m]>
nsklaus: beta testing or alpha deceiving
Catyre has quit [Remote host closed the connection]
Catyre has joined #asahi
Gaspare has joined #asahi
Catyre has quit [Ping timeout: 480 seconds]
jesuismey[m] has joined #asahi
doggkruse has joined #asahi
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #asahi
Catyre has joined #asahi
doggkruse has quit [Ping timeout: 480 seconds]
<clover[m]>
does asahi have a 'reboot into MacOS' feature? where if you are in a shell in asahi you do a command that boots you into the MacOS disk without messing with the boot selector?
<clover[m]>
systemd-boot can do this with windows iirc
<Sobek[m]>
I don't think there is such a thing right now. You'd probably have to reverse the protocol used by the bless utility to select the next disk to boot under macOS. So probably a lot of driver work, especially for something where it should be reasonably easy to do, unless you are ssh-ing in the device.
CME has joined #asahi
<sven>
it's probably just a nvram variable
<sven>
yup, there's "boot-volume" in nvram
<sven>
and I think the NOR flash already has a driver that just needs to be attached to the SPI bus
<sven>
so it's probably not that much work. just a bit scary maybe because you're writing to that flash which is kinda critical for booting
<redflag[m]>
switching boot related stuff is horrible on arm
<redflag[m]>
don't count on it being just a var in nvram
<sven>
this is not arm, this is apple
<j`ey>
sven: yup, the t600x-j314-j316.dtsi already has that node NOR node
<_jannau_>
on the mbp 14/16 the nor is just disabled, marcan iirc tested at least read and used it for SPI driver
<sven>
so then all you probably need is to figure out that nvram format and change that variable
<j`ey>
yup
<sven>
i bet that format is even documented somewhere
<Dcow[m]>
isn't it like override the default boot volume?
<Dcow[m]>
it's gonna be "stop booting asahi" tool
<sven>
hm, true
<sven>
but there should be something that allows to do that for a single boot as well
<sven>
iirc you can boot to a secondary installation once without making it the default
<_jannau_>
yes, that has the way the boot picker works as it does a reboot
Catyre has quit [Remote host closed the connection]
ciggi has quit [Read error: Connection reset by peer]
ciggi has joined #asahi
MajorBiscuit has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
Gaspare has quit [Quit: Gaspare]
Catyre has quit [Remote host closed the connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
Catyre has joined #asahi
Catyre has quit [Remote host closed the connection]
Catyre has joined #asahi
babble has joined #asahi
babble has quit []
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
Gaspare has joined #asahi
roxfan2 has joined #asahi
<marcan>
the nvram format is CHRP
<marcan>
yes, the powerpc stuff
<marcan>
straight off of that spec
<marcan>
there's a twist though, apple added binary value support with some kind of escaping (since the format assumes newline delimiters or something IIRC)
<Dcow[m]>
marcan: do you know if there a key to set one-time reboot target?
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
<Manouchehri>
real stupid question, how can I check what version of ARMv8 my CPU supports?
<marcan>
Dcow[m]: yes, there is
<j`ey>
Manouchehri: you check for each feature instead
<j`ey>
Manouchehri: by looking at the ID_* feature registers
<marcan>
Dcow[m]: I forget the name though, but it should be pretty obvious
<Manouchehri>
j`ey: is there a handy thing like lscpu to list features?
<Dcow[m]>
marcan: so the pipeline would be set this key and reboot?
<j`ey>
some things are optional, so an arm 8.5 cpu might not have all features
<Dcow[m]>
is there any way to obtain list of bootable partitions from linux?
<j`ey>
Manouchehri: ^
<Manouchehri>
thanks!
<marcan>
Dcow[m]: you need to know the APFS GUIDs to figure out what is bootable, and a "proper" path involves mounting filesystems to see if they are real OSes
<marcan>
so you're going to need some APFS tooling to make it work
<Dcow[m]>
ooph
<marcan>
I noticed blkid shows APFS container UUIDs now, so it knows *some* APFS at least, but you need more than that (you need volume group IDs)
Catyre has quit [Remote host closed the connection]
<marcan>
I'm interested in whether that can do safe read-only, yes.
<marcan>
and for SEP, we're going to need a *very* simple write subset (just in-place writes to a fixed size file) and I'm interested in whether that can be done as a sort of simplified path to avoid bugs
<marcan>
pretty sure Apple does something like that in their in-kernel SEP xART path
<marcan>
Manouchehri: no, that will likely never be supported
<marcan>
exposing proprietary CPU features to VM guests is not very well regarded
<Manouchehri>
marcan: really? I didn't realize it was that different than exposing perf counters for x86_64 (which works)
<j`ey>
Manouchehri: theyre not the arm architected perf counters
<nicolas17>
macOS 12.5 is out btw
<sven>
I think the xART stuff actually goes through the regular apfs driver
<marcan>
does the write path go through the regular write path though?
<sven>
it’s just mapped to some /dev file because lol apple
<marcan>
I've wondered if they really do all that CoW stuff even for xART
<marcan>
I think I saw some "direct mapped" type story in the logs
<marcan>
but I'm not sure
<sven>
I just assumed that the xart partition has cow disabled
<marcan>
oh, is that a partition property?
<sven>
but im also not sure
<sven>
I vaguely remember seeing some strings about that, but dunno
<marcan>
but yeah, in principle, if this is just stored on disk blocks, you could just read the APFS structures, enumerate the disk blocks for the xART file, and then just write to those, and know it will never break due to APFS nonsense
<nicolas17>
>putting xart in a fusion drive for the lulz
<marcan>
could even be handled entirely in userspace in sepd
<marcan>
which would give us a way to use SEP without having to do some serious validation of linux-apfs
<sven>
yeah, that’s what I wanted to do for sep.py before i got side tracked by nvme and usb3 :D
<marcan>
because we really, REALLY don't want to break xART for users
<sven>
or, well, for sep.py i wanted to just dump the partition and manually find those blocks
<sven>
the file is constant size anyway, there’s crcs and at least on both my machines continuous
<marcan>
heh
<nicolas17>
probably risky to assume it's not fragmented
<marcan>
probably not production ready but good enough for m1n1 demos
<sven>
yeah
<nicolas17>
looking at the security notes of today's releases
<nicolas17>
"APFS: An app with root privileges may be able to execute arbitrary code with kernel privileges"
<sven>
for production I’d rather parse the apfs structures and then maybe write to the blocks directly
<marcan>
yeah
<marcan>
how hard is apfs anyway? it's documented these days, right?
<nicolas17>
it is
<marcan>
I can see writing being a major pain (even Apple can't get that right, apparently)
<marcan>
but just finding a file and getting the blockmap might not be that bad?
<sven>
yeah, reading is probably just annoying
<nicolas17>
the pdf is incomplete for some stuff but it's *way* more complete than the first release
<marcan>
I really, *really* enjoyed that m1n1 Rust stream
<sven>
I actually think Python would be the wrong tool for sepd :D
<marcan>
because for once, I was *utterly* clueless and the audience was handholding me
<marcan>
and everyone was super nice :)
<nicolas17>
I did like 5 days of Advent Of Code in Rust and then couldn't keep up
<sven>
that would end up very ugly once you try starting to talk to pam and ssh and gpg and whatever
<marcan>
yeah
<marcan>
rust is probably a good idea, both for interop and the security aspect
<sven>
yeah, and a good excuse to learn it ;)
<marcan>
might also be a good target for a rust kernel driver, since it's probably very simple and self contained? just some bespoke chardev interface, talking to mailbox (maybe not even that, if I get annoyed enough to stop using it before we get there), and some memory mapping
<sven>
probably
<sven>
maybe tracking a bit of state so that sepd can be restarted but dunno if that’s even required
<j`ey>
Manouchehri: the m1 perf counters are not the architeched counters
<Manouchehri>
for context, I'm trying to get rr working in a VM. It works on Asahi perfectly.
<dottedmag>
Manouchehri: apple rolled their own performance counters. Now every emulator/hypervisor under the sun has to implement them, and most of them probably just won't.
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
bisko has quit []
quarkyalice_ has joined #asahi
bisko has joined #asahi
BlueIn2Red has joined #asahi
BlueIn2Red has quit []
<marcan>
Manouchehri: the PMU counters on M1 are proprietary, and KVM in general will not expose proprietary CPU features to guests by policy
<marcan>
that patchset though *might* work for emulating the standard PMCs on top of the Apple PMU? but I imagine there's probably some corner case that needs dealing with
<marcan>
would be interesting if someone tried that
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Cy8aer[m]>
What could I bug report for getting the chrome engine running?
<clover[m]>
<osteoblast22[m]> "No, mariab crashes on asahi..." <- I am friends with someone who works at mariadb and asked them to fix this
janrinze has joined #asahi
chuang[m] has joined #asahi
<janrinze>
in general it's been a struggle with ARM Linux to get changes for the architecture throuhout both kernel and userspace. In the past we had serious issues with bad programming practices on x86 with respect to structure alignement. it held ARM linux back for many years. The 4k pages have a similar background and insisting that we need 16k pages might be holding the progress back unnessicarily. Having an option to choose 4k pages and
<janrinze>
ahi kernel support might help to mediate the time for distibutions and applications to catch up on a new era of pages-size agnostic software..
<janrinze>
dottedmag: there is contiguous memory support in the kernel to do both alignment and ensure size fits for IOMMU.. right?
quarkyalice_ has quit [Ping timeout: 480 seconds]
<dottedmag>
janrinze: I'm not qualified to answer, unfortunately. I only know that marcan said something along the lines "not feasible to upstream such a hack"
<clover[m]>
from the message, it looks like its trying to do hardware rendering
<janrinze>
dottedmag: not upstream, but keep the patch available to asahi users.
<Cy8aer[m]>
Ok, for me - cy8aer - all my future messages will depend on debian with Glanzmann 's new 5.19 kernel with 16k pageing. Chromium worked with 4k 5.17-x kernel and the same binary now throws the GPU message.
<dottedmag>
janrinze: Asahi Linux exists solely to upstream all patches. This would be a separate project.
<jannau>
mariadb/jemalloc works when recompiled on a 16k page size system, the only issue is that we do not want to recompile and distribute random arch linux packages
<dottedmag>
A separate project with non-upstreamable hacks to get the most of the hardware is not a terrible idea, but nobody volunteered so far.
<jannau>
unfortunately there is not really any movement on the merge request to ensure the binaries work when compiled on a 4k system
<clover[m]>
someone could create a project on github, "asahi-packages", self-host a custom pacman repo and the all end-users would have to do is add their gpg key and an entry to pacman.conf
<dottedmag>
Someone could. Anyone signing up?
<clover[m]>
im busy with other stuff
<dottedmag>
q.e.d.
Catyre has joined #asahi
bisko has joined #asahi
<sven>
eventually we’ll upstream a patch that allows to boot with 4K pages
<sven>
but right now that’s neither a priority for anyone nor do we want to do that right now because we’d rather have people fix their code to not make assumptions about the page size
<Manouchehri>
1:53:25 PM <@marcan> Manouchehri: the PMU counters on M1 are proprietary, and KVM in general will not expose proprietary CPU features to guests by policy
<Manouchehri>
is exposing CPU features to guest non-trivial?
<janrinze>
sven: in my experience noone cares if ARM Linux can't run certain software.. the x86 community is far too big.. eventually the changes will come but it may take much longer than we all might want to believe.
<sven>
🤷🏻♂️
<sven>
this approach already lead to a fix in emacs and chromium
<janrinze>
This coming from someone who ran ARM Linux since 1997..
* Manouchehri
quietly pretends he isn't using qemu to run programs with 4k pages
<sven>
times are changing and people are excited about these machines after all
<janrinze>
Glanzmann: any particular reaon to use testing instead of Sid?
<Glanzmann>
Well, if we're lucky the error will go away when marcan implements it.
<Cy8aer[m]>
Glanzmann: right
<Glanzmann>
janrinze: To be honest I would use stable if I could.
<janrinze>
Sid is a tad more stable than testing..
<Glanzmann>
janrinze: Nope. Sid is where the new packages come in. Testing is when they come down and than comes stable.
<Cy8aer[m]>
janrinze: I am using testing because it gets most of the packages of unstable soon with the dev-process. But I install e.g. firefox from unstable.
<Cy8aer[m]>
(say packages which will not go into testing)
<Glanzmann>
So, I'm on testing and I'm happy with that. Of course that chromium doesn't work is a big bummer. But to be honest I no longer use chromium, due to chromium breaking ublock origin, so I switched to firefox a long time ago.
<Cy8aer[m]>
> due to chromium breaking ublock origin
<Cy8aer[m]>
Wow, did not know that.
<clover[m]>
microscroft edge, mate..
<Cy8aer[m]>
What I am now missing is qutebrowser (and there we have the pageing problem)
doggkruse has quit [Ping timeout: 480 seconds]
<janrinze>
When using 'testing' a lot of packages may be unavailable. That's my experience.
<Cy8aer[m]>
Glanzmann: Ok for the bt stuff: I can now see a loaded `hci_bcm4377` but that will not do the bluetooth stuff by now, right?
<janrinze>
I'm going to test 16 k pages now.. rebooting and brb
janrinze has quit [Remote host closed the connection]
Catyre has quit [Ping timeout: 480 seconds]
janrinze has joined #asahi
<Glanzmann>
Cy8aer[m]: To be honest, I did not try, just made sure that the driver is compiled in.
<Glanzmann>
Cy8aer[m]: I also re-extracted yesterday the firmware to include the bt stuff.
<Glanzmann>
But I have not yet tested it.
<Glanzmann>
Cy8aer[m]: Btw. I just rebased the 4k iommu patch ontop of current asahi branch. Was only some trivial merges. But I have not tested it. Will test it know and report back.
<Cy8aer[m]>
you know these early adopters. They are never happy 😉
<Glanzmann>
From what I read in IRC it seems to be 'ready to use'.
<Glanzmann>
Cy8aer[m]: I'm not a big bluetooth fan myself, so I don't really care.
<Glanzmann>
But I could try to get it running.
<janrinze>
Chromium Version 103.0.5060.114 seems to work with 16k pages..
<Glanzmann>
janrinze: Good luck. Did it work for you?
<Cy8aer[m]>
Glanzmann: Ah, I already wondered how new firmware stuff could go into the dist from dist side only.
<Glanzmann>
janrinze: Interesting, how did you try using ssh x forwarding?
<Glanzmann>
Cy8aer[m]: It depens on the stub version.
<janrinze>
yup. i'm now running Linux M1UltraDebianSid 5.19.0-rc5-asahijrp-16k #1 SMP Wed Jul 20 22:04:29 CEST 2022 aarch64 GNU/Linux
<clover[m]>
that's good janrinze. i wonder how far off VSCode is
<Glanzmann>
janrinze: Okay, are you using xorg or wayland?
<janrinze>
VSCode?
<Glanzmann>
I'm on X and I get the gpu error message that was pasted before.
<janrinze>
On X..
<Glanzmann>
janrinze: Microsoft electron app ...
<dottedmag>
janrinze: The difference is that M1 and derivatives are first mass-produced fast end-user laptop with ARM, right? Apple holds ~9% of laptop market, and in a few years most of these 9% will be ARM. Not a mishmash, but a single-vendor mostly-compatible ARM devices.
<Glanzmann>
janrinze: Wow, that's strange because for me and Cy8aer[m] it apparently does not work.
<clover[m]>
typing this on second mass-produced fast end-user laptop with ARM. a thinkpad X13s
<Cy8aer[m]>
clover[m]: Linux?
<dottedmag>
clover[m]: How many of these are sold, compared to M1 Air?
GuildedThorn has joined #asahi
<janrinze>
That thinkpad is very recent..
<clover[m]>
Cy8aer[m]: I have an archiso working, yes.
<janrinze>
got Cortex A78 .. right?
<Cy8aer[m]>
8cxIII where can these machines be bought?
<clover[m]>
soc (8cx gen3)
<clover[m]>
lenovo store
<janrinze>
I have Nvidia AGX and was considering the Orin version but chose a Mac Studio Ultra instead O:-)
<Glanzmann>
clover[m]: How does the single and multi core performance compare to the m1?
<clover[m]>
it's worse
<Glanzmann>
I see. :-(
<clover[m]>
it's like an i5
<Cy8aer[m]>
clover[m]: Yeah, but it depends on the country... Germany: no
<clover[m]>
Cy8aer[m]: dang, sorry :(
<clover[m]>
its still fast though. builds a linux kernel in ~10 minutes
<Cy8aer[m]>
(but I am happy that this hardware really exists somewhere) - I hope for 8cxIII "NUCs"
<Glanzmann>
So my 4k patch appears to be working. I also have wifi.
<Cy8aer[m]>
hm, it would be nice to have the possibility to use both 16k and 4k, like ksh16 or so. Because then I would be able to report problems to bugs.debian.org
<janrinze>
Glanzmann: Chromium runs.. i have only 20 mins uptime on this kernel.. so i haven't checked all features yet
<clover[m]>
4xX1 + 4xA78, Supports both 32-bit and 64-bit
<Glanzmann>
janrinze: Works for me with the '4k' kernel.
<janrinze>
clover[m]: I'm very interested in that laptop. I run RISC OS on Linux and that might be the last generation of fast ARM chips that will run 32 bit.
<janrinze>
Glanzmann: my Mac Studio is fast, I'm not ;-)
<janrinze>
Glanzmann: the patch applied cleanly. i'll start a new build
<Glanzmann>
janrinze: So are my ryzens, almost finished building all debian artefacts. :-)