user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
asocialblade has quit []
asocialblade has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
asocialblade has quit []
asocialblade has joined #asahi-dev
kov has joined #asahi-dev
doggkruse has joined #asahi-dev
user982492 has joined #asahi-dev
slimjimsoftware[m] has joined #asahi-dev
doggkruse has quit [Read error: Connection reset by peer]
robinp has quit [Ping timeout: 480 seconds]
<marcan>
maz: t8103, t6000, t6001/2 cores are all slightly different revisions, that's why they have different MIDRs
<marcan>
I think apple forks their cores per SoC, then backports fixes and follows a different revision number lineage for each tape-out
<marcan>
if you look at the chicken bits, you can see they can mostly be sorted chronologically by looking at what got fixed/added, and you end up with interleaved soc/revision pairs
<marcan>
so for example, HID4_ENABLE_LFSR_STALL_LOAD_PIPE_2_ISSUE got added in t6000 rev >= 0x10, but base t6001 has it already
<marcan>
while the unknown HID18_SPAREBIT17 got added in rev >0x10 on both
<marcan>
that tells me they taped out t6000 before finding the first one, then found it before taping out t6001, then found the second one, or something like that
slimjimsoftware[m] is now known as unsui[m]
gladiac has quit [Remote host closed the connection]
gladiac has joined #asahi-dev
<chadmed>
oh awesome the chassis of these machines still floats referenced to mains voltage
<chadmed>
just got a lovely tingle :P
gladiac is now known as Guest376
Guest376 has quit [Read error: No route to host]
gladiac has joined #asahi-dev
<jannau>
marcan: do you still have your m1n1 memory benchmarks? it looks like you never pushed them
<marcan>
if you really start digging into the lower address bits you could probably map out the interleaving, but that wouldn't be useful for software anyway
<mps>
Glanzmann: in meantime I bought cable from apple, 40 euros
<Glanzmann>
mps: Just waste of money, I like your solution better.
<mps>
Glanzmann: yes, it is how 'real hackers' fix issues ;)
<Dcow[m]1>
ok, I am stupid
<Dcow[m]1>
nevermind ;)
<mps>
Glanzmann: but my son ordered it for me
<chadmed>
mps: lmao awesome, australian plugs arent really conducive to that though. our plugs always occlude the entire socket
the_lanetly_052 has quit [Ping timeout: 480 seconds]
lockejan[m] has quit [Server closed connection]
lockejan[m] has joined #asahi-dev
<jannau>
u-boot on the M1 ultra works after fixing my errors in memmap
<jannau>
nice, I can now boot into the unmodified asahi desktop install. tethered m1n1+u-boot boot, i.e. I chainload m1n1 + mac studio dtb + u-boot, grub, kernel, initrd and rootfs on the nvme are provided by the installer
kameks has quit [Ping timeout: 480 seconds]
<Dcow[m]1>
marcan is probably jealous on you right now xD
<marcan>
soon...
<Dcow[m]1>
what the delivery ETA?
<j`ey>
Dcow[m]1: we all are :P
<chadmed>
yeah i finally decided to bite the bullet and spec one out, then i noticed that delivery times here have blown out to 2 months...
<chadmed>
oh the joys of living through bronze age collapse 2: the revengenance
V has quit [Server closed connection]
V has joined #asahi-dev
minkuu[m] has quit [Server closed connection]
minkuu[m] has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
int80 has quit [Server closed connection]
int80 has joined #asahi-dev
gabuscus_ has quit [Server closed connection]
gabuscus has joined #asahi-dev
m6wiq has joined #asahi-dev
alcazar has joined #asahi-dev
Mary has quit [Server closed connection]
Mary has joined #asahi-dev
<jannau>
hdmi on the mac studio can handle disconnect/reconnect, even with with a different display without dcp
leonardeyer[m] has quit [Server closed connection]
leonardeyer[m] has joined #asahi-dev
lkvrsfld[m] has quit [Server closed connection]
lkvrsfld[m] has joined #asahi-dev
FarukAydn[m] has quit [Server closed connection]
FarukAydn[m] has joined #asahi-dev
MikaB[m] has quit [Server closed connection]
MikaB[m] has joined #asahi-dev
chengsun has quit [Server closed connection]
chengsun has joined #asahi-dev
di1[m] has quit [Server closed connection]
di1[m] has joined #asahi-dev
nico_32 has quit [Server closed connection]
nico_32 has joined #asahi-dev
zyroklarryfish[m] has quit [Server closed connection]
zyroklarryfish[m] has joined #asahi-dev
alexandruchi[m] has quit [Server closed connection]
alexandruchi[m] has joined #asahi-dev
Thib[m]12 has quit [Server closed connection]
Thib[m]12 has joined #asahi-dev
timokrgr has quit [Server closed connection]
timokrgr has joined #asahi-dev
<Retr0id>
chadmed, as of the switch to usb-c, grounding the grounding lug on the charger still does not ground the macbook chassis, because the usb-c receptacle is made of plastic
<Retr0id>
s/ground/earth/
<chadmed>
surely the shell of the magsafe connector is connected to the usb-c ground on the brick
<milek7>
I don't think you need grounded chassis, just need to ground EMI filter in the power supply
subject38[m] has quit [Server closed connection]
subject38[m] has joined #asahi-dev
ChaosPrincess has quit [Quit: WeeChat 3.4]
ChaosPrincess has joined #asahi-dev
the_real_briel[m] has quit [Server closed connection]
the_real_briel[m] has joined #asahi-dev
<chadmed>
yeah the mains voltage just needs to be stopped from being capacitively coupled into the low voltage side of the brick so grounding the mains side should be adequate
nametable[m] has quit [Server closed connection]
nametable[m] has joined #asahi-dev
robinp has joined #asahi-dev
<robinp>
does everyone else get the netfilter filename conflicts when cloning linux onto a mac ? how do you fix it ?
<j`ey>
you have to make the FS case sensitive
<j`ey>
from a quick google looks like you have to do it on a volume basis, not per folder: use std::borrow::Cow;
<j`ey>
Eighth_Doctor: I suggest you use the asahi branch for now, 5.17 doesnt have enough to be usuable
<Eighth_Doctor>
what is the asahi branch based on right now?
<Eighth_Doctor>
it seems like 5.17-rc7?
<jannau>
no, it's linux-next-20220310, 5.17-rc7 is just the last present tag
<Eighth_Doctor>
ah
<jannau>
almost 12000 commits of from 5.17-rc7
<j`ey>
only ~160 of them from asahi :P
<jannau>
those are on top, the linux-next commit is v5.17-rc7-11953-g71941773e143
<j`ey>
Eighth_Doctor: hopefully all you need is the kernel pkg
<Eighth_Doctor>
we've been packaging up the other parts
<Eighth_Doctor>
m1n1, asahi-scripts, etc.
<Eighth_Doctor>
I just need to pull in the asahi work into the fedora kernel tree :/
<Eighth_Doctor>
unfortunately the main kernel maintainers merged the packaging files into the source tree so it's difficult to use another source tree directly for packaging a kernel
<j`ey>
oh that's annoying
<Eighth_Doctor>
yeah, I'm extremely unhappy about it
<Eighth_Doctor>
I was unhappy when we made that change, and now I'm even more unhappy
<Eighth_Doctor>
moving to the RHEL workflow for the Fedora kernel has made experimentation much harder for folks like me :(
<Eighth_Doctor>
the upside, as it were, is that it makes it much easier for us to continuously test the kernel sources nightly with the RHEL and Fedora test harness
<Eighth_Doctor>
and we do that, but... sigh
<Eighth_Doctor>
I'm not sure it was worth it after all, but...
<Eighth_Doctor>
it is nice seeing nightly snapshots of the kernel being tested
<j`ey>
pros and cons
<Eighth_Doctor>
indeed
hir0pro has joined #asahi-dev
amarioguy has joined #asahi-dev
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matde[m] has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
<sven>
we just need to get better at upstreaming all that stuff ;)
<sven>
speaking of which, time to write some replies to the nvme comments
<jannau>
what's the status of t6000-dart?
amarioguy has quit [Ping timeout: 480 seconds]
kita99 has quit [Ping timeout: 480 seconds]
m6wiq has joined #asahi-dev
<marcan>
Eighth_Doctor: the udev trigger thing is to make udev trigger the nvme driver, *then* the firmware pull script runs, *then* normal udev trigger runs and loads the broadcom wifi driver
jeffmiw has joined #asahi-dev
<Eighth_Doctor>
?
<marcan>
without that you either end up with firmware not working on first boot / being out of step, or the firmware pull script blocking on nvme that won't come until it's done
<marcan>
for us asahi is just an auto-merge of our bits/ branches, which are frequently rebased on top of whatever linux-next I'm going by
<jeffmiw>
ok, I'm willing to help upstreaming pending bits, so if someone sees something I can do to help in this area let me know ..
<marcan>
I have some scripts to do that and the merge is supposed to be clean
<Eighth_Doctor>
marcan: that makes sense, after all you're actively working next-next-next code :D
<marcan>
(which is why a couple bits/ branches base on each other, it's always MAINTAINERS changes, hint hint sven)
<Eighth_Doctor>
it's just a little fugly for me to work through, sorry :(
<marcan>
but basically it's not actually too bad for us to pick a different base point, or merge linux-next after or split up bits/ in a way to make that easier
<Eighth_Doctor>
that would be hugely appreciated
<sven>
ah, right, i keep forgetting
<Eighth_Doctor>
fwiw, the folks working on fedora-asahi are available via matrix on #asahi:fedora.im (https://matrix.to/#/#asahi:fedora.im)
<marcan>
how about when something gets upstreamed, I pull that upstream tip into a bits-cur/ or something, or rebase it if it has too much unrelated history
<Eighth_Doctor>
that would be very useful
<marcan>
and then I can have all the bits/ branches base off of an RC or whatever in general, and our main -next merge would happen between next and only the bits/ branches
<marcan>
while you'd pull in cur too
<Eighth_Doctor>
how difficult would it be for you to maintain a set also on the latest stable tree?
<marcan>
and hopefully not too much explodes
<marcan>
stable as in normal kernel releases, or as in longterm?
<Eighth_Doctor>
normal
<Eighth_Doctor>
fuck longterm
<Eighth_Doctor>
Fedora kernels are aggressively rebased to the latest stable versions as they become available
* Eighth_Doctor
has terrible experiences with the longterm kernels
<marcan>
I can probably just say the base is stable tbh, though I'll only rebase on top of X.Y versions, I won't be maintaining minor merges
<Eighth_Doctor>
rebases are fine
<j`ey>
well stable is 5.16, so that might require backporting some things that are not in the current asahi, but are in 5.17
<Eighth_Doctor>
stable is 5.17 now
<marcan>
I mean I won't do X.Y.Z releases but if you want those hopefully those merges won't be painful
<Eighth_Doctor>
no, I think that's fine
<Eighth_Doctor>
usually cherry-picks after the fact are easy
<Eighth_Doctor>
and I need to do cherry-picks anyway because of the discordant history
<marcan>
I'll give it a shot next time I rebase and see how it goes, it's getting more reasonable now that most patches to existing things are in
<Eighth_Doctor>
so if you have one based on v5.17 tag then I can work with it
<marcan>
I should send another wifi series out, that's probably the only one likely to cause conflicts longer term and it's mostly reviewed already anyway
<Eighth_Doctor>
my hope is to have this fully integrated into Fedora sometime between now and Fedora 39
<marcan>
when's that?
<Eighth_Doctor>
that's October of next year
<Eighth_Doctor>
Fedora 37 is October of this year
<marcan>
ah, plenty of time then
<Eighth_Doctor>
yup
<Eighth_Doctor>
a Fedora Asahi Remix is probably going to become a thing sometime in the next few months
<marcan>
I hope to be fully back in kernel bikeshedding mode in a couple weeks at most, do a good round of that
<Eighth_Doctor>
just need to get a working kernel
<marcan>
that's cool :)
<Eighth_Doctor>
and a maintenance workflow in place for it
<Eighth_Doctor>
yup
<marcan>
yeah, putting together the distro is always an interesting break from the dev isn't it
<marcan>
(for asahi I think that was 90% me :p)
<Eighth_Doctor>
hehe yeah
<Eighth_Doctor>
I'm trying to hold to my promise to you when you started that I want to have Fedora be the first distribution after yours to have ARM Mac support
<marcan>
:D
<marcan>
I'm *very* happy to have you onboard FWIW :)
<Eighth_Doctor>
(also, I lead Fedora KDE :) )
<marcan>
:)
<Eighth_Doctor>
thanks, I appreciate it
<marcan>
you probably saw we have a couple forks of random things, like the xkeyboard stuff; all that is really just intended as sandboxes for improving mac support in $random_packages
<Eighth_Doctor>
yeah
<marcan>
so you don't have to care about that other than feeling free to backport patches if you want them early
<Eighth_Doctor>
as a Mac user for more than a decade, I've always appreciated the Mac hardware
<jannau>
october would probably end up with 5.19, i.e. we have 9 weeks to upstream everything
<Eighth_Doctor>
yup
<Eighth_Doctor>
and 5.19 will be backported to all currently supported Fedora releases at the time of its release
<marcan>
I'll be very happy if we get t6k IOMMU and NVMe in by then
<marcan>
that means installers will boot
<Eighth_Doctor>
yeah
<Eighth_Doctor>
then I just have to have a go at getting Anaconda to play nice on a Mac :)
<marcan>
:)
<marcan>
(how'd you like my Calamares hack? :p)
<Eighth_Doctor>
pretty clever
<marcan>
(that was very last minute too, but damn did it make things look nice)
<Eighth_Doctor>
I'm actually the calamares maintainer in Fedora, so I might steal a bit of it
<kettenis>
we have to tie sven to his chair and keep usb devices out of his reach
<Eighth_Doctor>
for the remix
<marcan>
hah
<sven>
lol
<marcan>
yeah, I should redo some things properly and clean them up
<marcan>
the keyboard support needs some improvements beyond my silly hacks
<marcan>
I did that like the week before release, so at some point I gave up on sanity and just needed to hack things up to make it work
<sven>
i'm writing replies to the nvme review comments from my couch right now and yet you people are already distracting me again :-P
<Eighth_Doctor>
a friend of mine is loaning me an M1 macbook pro since I can't afford a new computer at the moment, so that'll let me get my feet wet on this
<kettenis>
speaking of which, having the kblang property on /chosen doesn't make sense
<jannau>
I hope we get spi hid also in for 5.19
<Eighth_Doctor>
I currently have a very tetchy 2014 MacBook Pro
<marcan>
kettenis: I know, that was a hack too tbh
<marcan>
I want to have a discussion about that
<marcan>
the good news is it won't really break anything if it moves, since it only really matters at install time
<marcan>
so as long as we sync things up reasonably for installers we're good
doggkruse has joined #asahi-dev
<marcan>
and keeping a legacy copy in there won't hurt anything anyway
<marcan>
I think I did that, what, the day before release?
<marcan>
:)
<mps>
hehe, first distro on m1 was alpine ;)
<mps>
jk
<kettenis>
marcan: yeah, which is why I didn't bring it up at that point ;)
<mps>
I think marcan run Arch first
<Eighth_Doctor>
yeah, well I wasn't going to try to beat marcan
<marcan>
I think alyssa ran debian before I ran arch, lol
<kettenis>
meh, OpenBSD was the first self-hosting OS in m1 ;)
<marcan>
all my early testing was with a busybox initramfs
<kettenis>
(apart from macOS of course ;))
<Eighth_Doctor>
yes, but you're the first to make a distributable thing
<Eighth_Doctor>
I want to be next after that :D
<marcan>
:)
<Eighth_Doctor>
are the uboot things upstreamed yet?
<marcan>
then again corellium ran ubuntu before anyone here but that was also throwaway code so shrug
<mps>
Eighth_Doctor: glanzman already made very good debian
<marcan>
Eighth_Doctor: most of it is
<marcan>
we always seem to have a few patches on top, but it's fairly trivial stuff
<marcan>
all the drivers are
<marcan>
see our repo, it's rebased on top of a recent release
<mps>
aha, I tested corellium with ubuntu year ago
<mps>
but was not satisfied with it
<marcan>
I mean "hi ma I can run $distro" doesn't really mean much, you can pick whatever rootfs you want once you have a kernel with framebuffer and IRQs and maybe USB
<marcan>
the question is does it integrate properly :)
<Eighth_Doctor>
yup
<Eighth_Doctor>
and can someone else do it with distro support
<mps>
marcan: right, and is not much important
<marcan>
yeah
<Eighth_Doctor>
my goal is to have it actually integrated into Fedora itself reasonably quickly
<mps>
though I have alpine image filesystem to be dd-ed to usb
<marcan>
I'm very much looking forward to writing that blog post
<Eighth_Doctor>
then I get to have "fun" times trying to see if we can get this into CentOS/RHEL 10
<marcan>
as we've quipped before, Asahi's goal is to not exist as a distro (even if we never quite get there) :)
<Eighth_Doctor>
yup
<marcan>
heh, are they still on 64K kernels?
<Eighth_Doctor>
and I hope that Fedora's work will provide a blueprint for other distros that often look to us for how to do this to enable it for their own distros
<marcan>
because *that* will be a problem :p
<Eighth_Doctor>
marcan: finally broke them of that. 4k on RHEL 9
<marcan>
ha
<marcan>
cool
<marcan>
still going to need that 4K patchset though, which we don't even have in asahi yet
<Eighth_Doctor>
I was personally very pleased to see that change
<marcan>
that's another one to poke the stick at soon, if only because it will trigger more discussion
<mps>
tmlind run alpine for more that 6 months as daily driver, though with kexec
<marcan>
also please continue to build packages with 64K linker settings :)
<mps>
and I run it for more than 4 months
<sven>
if we make swiotlb work with > PAGE_SIZE alignments we can just re-submit that 4k thing. I have a branch somewhere that addresses the other review comments fwiw
<marcan>
cool
hir0pro has joined #asahi-dev
<sven>
but that swiotlb thing is a bit tricky and i've had a chance to grab some pencil+paper to work out how to make that happen together with this min_dma_align_mask or however it was called
<marcan>
(I'm not pulling it into asahi because I want people to feel the pain for a while, so packages get fixed first)
<sven>
*i haven't had
<marcan>
(we'll eventually ship it as an alternative)
<sven>
yeah, and I think that's good
<sven>
pain is always a good motivation to fix bugs ;)
<marcan>
:)
<Eighth_Doctor>
the btrfs stuff is all sorted out now, thankfully
<j`ey>
jannau: spi hid will only be useful if we have spi too :P
<Eighth_Doctor>
which is what really matters in the Fedora context
<Eighth_Doctor>
we originally got that work done for POWER (which uses 64k pages), but it's even more helpful with ARM now
<Eighth_Doctor>
because now btrfs should behave properly on 16k and 4k pages
<j`ey>
can you read a btrfs disk from kernels with different page sizes?
<Eighth_Doctor>
yes
<Eighth_Doctor>
there are now two different ways to do it: either with btrfs-fuse or with kernel 5.16+ btrfs
<Eighth_Doctor>
if it doesn't work with kernel-btrfs, please send an email to linux-btrfs@ about it to let them know
<Eighth_Doctor>
(btrfs-fuse is a read-only btrfs implementation designed to assist in recovery and similar scenarios)
<j`ey>
I dont use it, but I was thinking some people might like to reboot into different page_size kernels
Denver has joined #asahi-dev
<Eighth_Doctor>
yeah
<Eighth_Doctor>
btrfs should work fine in that case
the_lanetly_052__ has quit [Remote host closed the connection]
the_lanetly_052 has quit [Remote host closed the connection]
<Eighth_Doctor>
if the filesystem is created with 4k size (which it should by default now), then it'll work everywhere
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
nicolas17 has joined #asahi-dev
andre4[m] has joined #asahi-dev
asocialblade has quit []
asocialblade has joined #asahi-dev
andre4[m] is now known as quas4r[m]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
m6wiq has quit []
<aleasto>
nice to see you involved neal. is the fedora matrix room replicated to irc somewhere?
hir0pro has joined #asahi-dev
amarioguy has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
clee has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi-dev
amarioguy has joined #asahi-dev
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]