ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi
jeffmiw has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Ping timeout: 480 seconds]
riker77_ has joined #asahi
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
yuyichao has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
cth451_desktop has joined #asahi
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
<marcan>
will probably stream in a bit, once macOS finishes reinstalling :-) (I think I broke my "Linux" install)
<marcan>
oh hey it's done
<marcan>
fwiw, the (basic) installer is 70% of the way there; I just need to solve the ownership transfer problem (basically generate a macOS user database in the installer) and add the missing partitioning assistant type functionality (just wrapping diskutil to automate things)
<marcan>
so we should be able to deprecate that hideous quickstart wiki page for something much simpler today :)
<chadmed>
so that OD user database is where 1TR/bputil get the user information when it asks us for it?
<marcan>
not entirely sure, but regardless, the problem is it wants a user *in* that volume, not just any machine owner
<marcan>
I think the SEP backend lets you authenticate with any machine owner, but sadly the frontend tools don't (and we can't go directly to the SEP due to entitlements)
<marcan>
however, the boot picker has an ownership transfer feature that lets you set up ownership on a user in the volume, if it has one
<marcan>
so by creating that OD user database, the boot picker will let you do that
<marcan>
and that will set things up the way bputil/kmutil wants
<marcan>
that said, if kmutil/bputil is really only looking for the user existence in the database, maybe we can cheat
<marcan>
worth a bit of an experiment from macOS
<marcan>
(if it's just authing against the SEP, we could just create a fake user matching the *macOS* i.e. another partition's user, with no password even)
<marcan>
but I think that won't quite work because I do have the same username everywhere and it did want the right password
<marcan>
though it could be checking the password against the database first, then SEP
<marcan>
regardless, this worked when I copied the database over manually, and I think I did the ownership transfer thing then
<sven>
amw: and that didn't happen before? the code in nvme and devel is also essentially the same
<sven>
amw: and just to confirm: this specific usb drive works fine if you use it with another machine? (i'm asking because i have one broken usb drive that caused me headaches for a week or so until i realized it *also* failed in the same ways on macOS and another linux machine)
<chadmed>
wasnt there also someone else having data corruption issues with devel or dart/dev yesterday?
<sven>
pretty sure i've only read about that from amw
<sven>
it's also weird because even with 4k pagesize code that i know to be broken i haven't seen that severe corruption
<amw>
sven: My dart+nvme was pretty bad, but devel has the boot issues from time to time.
<amw>
I use it through a hub, but that shouldn't make a difference but I can move things around and see if this misbehave on other machines.
<sven>
would be good to make sure it's really an issue somewhere in linux
<sven>
another think you could try is to boot with the IOMMU in passthrough mode
<sven>
there's a config options and also a boot argument for that
<amw>
It's probably something screwy on my hacky set of patches that I have made - if anyone else tries it shoukd just be-aware of it.
<sven>
it also could be a very subtle bug in the iommu code that's why i'd like to make sure
<amw>
As I can re-image that partition in a minute, it's main impact is that if it happens, I have to re-start the Mac, then m1n1, then load linux et cetera.
<sven>
so this is not just the devel branch but devel branch + some of your patches?
<amw>
At the moment - yep it's got other corellium spi+gpio+keyboard patches
<sven>
hm.. that *shouldn't* break anything
<sven>
but it would still be great if you could try with just the iommu patches
<alyssa>
although those patches don't apply cleanly on top of the mainline DART
<alyssa>
sven: AFAIU you have a branch of those patches rebased on top of the latest DART (used to test said DART)? i don't want to go duplicating effort and it looks like a nontrivial rebase
<j_ey>
do you mean linux-next? it hasnt made it to torvalds / master yet
yuyichao_ has joined #asahi
lockna[m] is now known as Lockna
Lockna is now known as lockna
yuyichao has quit [Ping timeout: 480 seconds]
<alyssa>
kettenis_: building your u-boot, I'm getting a link error for print_cpu_info unless I unset CONFIG_DISPLAY_CPUINFO -- it looks like arch/arm/mach-apple/ needs to define tha
<sven>
the dt from u-boot should give you pcie then
<sven>
you may have to adjust the iommu-maps, let me check
<sven>
yeah
<sven>
- iommu-map = <0x100 &pcie0_dart_0 1 1>,
<sven>
- <0x200 &pcie0_dart_1 1 1>,
<sven>
- <0x300 &pcie0_dart_2 1 1>;
<sven>
+ iommu-map = <0x100 &pcie0_dart_0 0 1>,
<sven>
+ <0x200 &pcie0_dart_1 0 1>,
<sven>
+ <0x300 &pcie0_dart_2 0 1>;
<sven>
and then i use python3 proxyclient/tools/linux.py -u ../u-boot/u-boot-nodtb.bin -t /dev/cu.debug-console --bootargs="earlycon rw root=/dev/sda1 rootwait rootfstype=ext4" Image.gz ../u-boot/u-boot.dtb
<sven>
it's... not great. but now that DART is on its way to mainline we should be able to make this nicer
<alyssa>
that dt patch is to u-boot or to inux?
<sven>
u-boot
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
<alyssa>
I smell hax
<sven>
you must be mistaken! all my code is immensely beautiful and never contains any hacks whatsoever :-P
bps has quit [Ping timeout: 480 seconds]
<sven>
so the issue with that iommu-map is that apple's pcie controller allows you to essentially configure a pcie rid to sid map in some register
<sven>
that pci code in linux probably need some support to take care of that. there's another pci driver that also needs that but only during init time
<sven>
and any device that is not configure to a specific sid gets tagged with zero by default
<sven>
so that dtb patch just changes "map these devices to SID 1" to "map these devcies to SID 0" which then works out
<alyssa>
AttributeError: 'NoneType' object has no attribute 'baudrate'
<alyssa>
uhhh
<pipcet[m]>
old serial lib?
<sven>
ah.. so, uh, that might just be my u-boot hack
<sven>
i've only ever tested that with a hardware UART. it patches u-boot in memory to setup the correct baudrate for that
<sven>
just remove bootenv.append("baudrate=%d" % tty_dev.baudrate) i guess
<alyssa>
nod
<alyssa>
It is refusing to boot, uhh...
<alyssa>
(Just showing the apple logo)
<sven>
hrm... now if you had a hardware uart you could check what u-boot complains about
<alyssa>
big if
<sven>
dunno how to go from here. i've never debugged u-boot. i just treated it as a black box that i needed to hack a little bit to get pcie up and running
<sven>
i don't even know if it has a framebuffer
<pipcet[m]>
it does, it works with the fb here (but without the pcie hacks :/)
<alyssa>
:|
<alyssa>
it would helpt o enable simplefb in u-boot :p
<j_ey>
alyssa: i made the exact same mistake with the kernel :D
<sven>
framebuffers are overrated.
<pipcet[m]>
an LED is all you need, right? :-)
<sven>
it's a start :D
<sven>
i'm happy with uart though ;)
<pipcet[m]>
or a GPIO pin at sufficient voltage to zap your finger ;-)
<pipcet[m]>
speaking of insufficient voltages, my MBP just gave me the red battery just as I was about to test&push the fast-ipi thing. works now, code at https://github.com/pipcet/linux/tree/apple-fast-ipi, but I'm taking it as a sign that it's time to do something else prior to cleanup+checking it masks things at the vipi layer+serializing+PRing :-)