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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
jn has quit [Remote host closed the connection]
m42uko has quit [Read error: Connection reset by peer]
m42uko has joined #asahi
jn has joined #asahi
richbridger has joined #asahi
aquijoule_ has quit [Ping timeout: 480 seconds]
guan has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
<marcan>
bloom: m1n1's primary purpose is to do low level CPU init and take care of ADT->FDT adaptation
<marcan>
how much other hardware init is in m1n1 vs u-boot is subject to discussion; right now we're doing things like taking care of some fuse-based pokes and such in m1n1 so downstream users don't have to
<marcan>
currently I like being able to not require u-boot to boot linux from m1n1 but sven has a hack to chainload via u-boot anyway and I will accept that as a requirement if it makes sense :p
<marcan>
but I don't see much point in moving all of m1n1 into u-boot; there isn't really anything to be gained there, it'd just be moving code from point A to point B, including all of the ADT handling and whatnot
<marcan>
kettenis: fwiw m1n1 currently provides enough entropy (forwarded from iBoot) to linux to init its entropy pool, iff it's built with the config option to trust bootloader-provided entropy
phiologe has joined #asahi
<brentr123[m]>
I’m curious is the hyper visor going to be optimized any time soon so that it can run the best it possibly can or is it “good enough”?
PhilippvK has quit [Ping timeout: 480 seconds]
<marcan>
I don't think there is much to optimize; ARM virtualization doesn't really trigger many traps
<marcan>
if it's slow it's because it runs on one e-core only and, when you have mmiotrace, because that slows things down obviously.
<marcan>
though I do wonder how much slowness is caused by my bad timer handling (can't be fixed due to ARM limitations); might be worth trying a few hacks for that
<bloom>
marcan: Mostly I like as-simple-as-possible boot chains
<bloom>
We have no choice on iBoot or Linux, and we can't teach Linux to be an iBoot payload, but we do have a choice of having in between 1 or 2 or 3
<bloom>
and if we can do iBoot -> m1n1 -> Linux or iBoot -> U-Boot -> Linux, I would much prefer that to iBoot -> m1n1 -> U-Boot -> Linux or, er, iBoot -> m1n1 -> U-Boot -> GRUB -> Linux
<brentr123[m]>
Kind of related to asahi, but how did you guys get into coding? Self taught or you learned it in school? It’s always interesting to see how people get into it. Even though I don’t know all of these complex terms like “traps” and such, it is so interesting just to be here and witness people talking in that sort of way
<bloom>
but I suppose m1n1 could be cut down dramatically if _all_ it needs to do is to do ADT->FDT, some mmio pokes, and jump to u-boot
<marcan>
bloom: I mean, what's your concern with having m1n1/u-boot as two things?
<bloom>
so, er, iBoot -> tiny-m1n1 -> U-Boot -> Linux is probably my preference, since distros know how to do U-Boot so you get some semblance of standard
<bloom>
ok. consider my convinced :-p
<marcan>
I mean it's not like u-boot doesn't run multiple stages on lots of hardware
<bloom>
yeah, for sure
<marcan>
the code has to exist somewhere, it's really just about two repos vs one
<bloom>
nod
<marcan>
they get concatenated together and deployed as one blob anyway
<bloom>
m1n1 with all the r/e code stripped out is very little code anyway
<marcan>
exactly
<marcan>
and yes eventually there will be some compile time option for that
<bloom>
so err.. +1 for me, I'm convinced as long as I don't have to stick GRUB in there ;)
<marcan>
in fact I bet just taking out the proxy stuff from main() will optimize out most of that code, because -ffunction-sections and such
<marcan>
(need to check about the hypervisor exception vectors, might need some directives)
<marcan>
GRUB is optional, I expect distros to use it, but you can use u-boot directly
<bloom>
i haven't used GRUB since 2017
<marcan>
heh
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb has quit [Remote host closed the connection]
bgb has joined #asahi
norwoodites has joined #asahi
pinskia has quit [Remote host closed the connection]
bgb has quit [Ping timeout: 480 seconds]
shenki has quit [Quit: leaving]
shenki has joined #asahi
shenki has quit []
shenki has joined #asahi
norwoodites is now known as pinskia
shenki has quit []
shenki has joined #asahi
<emilazy>
I thought the planned boot chain involved UEFI at some point which sounded cursed... so I'm glad to hear it's slightly less cursed than that
<jannau>
marcan: nothing wrong with booting Linux directly from m1n1. It is just inconvenient in production
VinDuv has joined #asahi
<jannau>
kernel updates only through 1TR or booting over uart/usb. The second has currently no security whatsoever
<jannau>
emilazy: u-boot provides UEFI and it is desireable so that distro's installers just work
<emilazy>
yeah, I get the practicality benefits with aarch64 server/desktop ecosystem standardizing on UEFI/ACPI for everything... just a little sad since part of the appeal of the Apple Silicon machines is the less fucky firmware/bootchain situation for me
<marcan>
jannau: I'm talking about for development/testing only; the question is whether we eventually want to have linux drivers rely in initialization that only u-boot performs or not
<marcan>
if we go that route, then USB loading will have the u-boot wrapper requirement (which we already have a hack for)
<marcan>
I do not expect anyone to do direct linux loads as a m1n1 payload in production for normal boot; the end-user setup we ship will definitely be m1n1+u-boot
<marcan>
the question is whether we can keep `linux.py <kernel>` working without a u-boot intermediate stage, or whether there are good enough arguments to do some of the init in u-boot and just say we expect linux.py to always load it first
<marcan>
emilazy: u-boot provides enough UEFI services to load GRUB or a UEFI-wrapped linux, but it can also load kernels directly
<marcan>
we have no plans to port "full" UEFI a la tiano or any of that
<emilazy>
nods
<marcan>
whether people want to use UEFI or just u-boot straight to arm64-boot-protocol linux is up to them
<emilazy>
that'll presumably happen when someone masochistic enough gets Windows running on them :p
<marcan>
running windows bare metal on M1 is impossible without MS help
<emilazy>
ah, because of unimplemented stuff?
<marcan>
windows needs core kernel changes; like linux, there's enough different about the M1 that you can't just do it all in drivers
<marcan>
in particular all the IRQ mess
<emilazy>
right
<marcan>
MS only ever did that for one platform (rpi)
<emilazy>
well I mean you could always just something something hypervisor something something magically shim things out
<marcan>
yes, that's what the pongoos guys wanted to do
<emilazy>
but I guess then it doesn't count as bare metal
<marcan>
and I mean I already wrote a shim hypervisor so if someone is masochistic enough to want to go that way and emulate a GIC inside that and PSCI or something then sure, it'll probably work
<marcan>
but then you still get to port all the drivers to windows
<marcan>
which is the hard part :p
<emilazy>
of course
<emilazy>
raspi4 doesn't even have good windows drivers
<emilazy>
and that's with official microsoft involvement...
<marcan>
yeah...
<sorear>
what arm platform has the best support to emulate? :p
<emilazy>
qualcomm
<marcan>
good luck emulating that
<marcan>
:p
<emilazy>
I kind of want that Microsoft/Snapdragon ARM64 development PC purely because it's the only Windows 10 you get GPU acceleration on
<emilazy>
but it's going to cost like >$300 for 4 gigs of RAM
<emilazy>
because, I guess, Microsoft
VinDuv has quit [Quit: Leaving.]
bgb has joined #asahi
norwoodites has joined #asahi
pinskia has quit [Ping timeout: 480 seconds]
norwoodites is now known as pinskia
vafanlignarde has joined #asahi
bgb has quit [Remote host closed the connection]
bgb has joined #asahi
<maz>
sven: sure, no worries. just let me know when you have something I can resync on.
bgb has quit [Ping timeout: 480 seconds]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi
bgb has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
ganpa[m] has joined #asahi
egavinc has quit [Remote host closed the connection]
egavinc has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
choozy has joined #asahi
<alessandrorzz[m]>
>how much other hardware init is in m1n1 vs u-boot is subject to discussion; right now we're doing things like taking care of some fuse-based pokes and such in m1n1 so downstream users don't have to
<sven>
i don't get any MSI interrupts though. still have to figure out what's going on there
klltkr has joined #asahi
kyjus25 has left #asahi [#asahi]
kyjus25 has joined #asahi
Emantor[m] has joined #asahi
berryRed has joined #asahi
klltkr has quit [Ping timeout: 480 seconds]
<pugguu>
Hello
<jn>
hi again
<pugguu>
How u doing jn
<pugguu>
Who is xerpi
<jn>
i'm fine
<jn>
xerpi is a cool person :)
<pugguu>
How cool are we talking
<pugguu>
Cus he literally dm'ed me 2 days ago but since i never have notifcations on my phone i didnt notice
<pugguu>
Or she
<pugguu>
They are doing linux on psvita
<pugguu>
:o
<jn>
yep!
<pugguu>
I alredy like this guy
<pugguu>
Dont tell me he is as yong as he looks on his github
<sorear>
for half a second i thought this was a new apple silicon-based playstation, they've migrated architectures enough already
berryRed has quit [Quit: Leaving]
<pugguu>
sorear: 🤦♀️good one that will never happen
<pugguu>
XD
<pugguu>
I wish tho
<sven>
can we please try to keep it on-topic in here?
<jn>
sven: good call
<jn>
we have #asahi-offtopic after all
<pugguu>
What am i like xD
<pugguu>
sven: Sorry
<kettenis>
sven: I don't immediately see what's going wrong with the MSIs
<sven>
yeah, me neither. i've checked and the interrupts in the AIC are unmasked
VinDuv has quit [Quit: Leaving.]
<sven>
but they never seem to fire
<kettenis>
oh, wait
<kettenis>
msg->address_hi = 0xfffff000;
<kettenis>
that should be
<kettenis>
msg->address_lo = 0xfffff000;
<kettenis>
and hi should be set to 0
<sven>
[ 9.099932] IRQ83 (2) eoi
<sven>
:D :D
<sven>
yup, that's it. thanks!
<sven>
aaaaand we have working pcie
<sven>
:-)
<jn>
congratulations :)
<j_ey>
that certainly looks like a weird address kettenis
<sven>
again, 99% of this is thanks to maz and kettenis. i just did some plumbing to make sure it plays nicely with my dart driver
<hell__>
\o/
<kettenis>
so using stream ID #1 works fine with your code?
<sven>
i changed the device tree to id #0 iirc
kyjus25 has quit [Quit: Leaving.]
<kettenis>
ah, right
<sven>
64 bytes from 192.168.42.1: seq=0 ttl=64 time=0.812 ms <-- and with working interrupts we're down to <1ms from what used to be ~130ms :-)
<j_ey>
how did it work without interrrupts?
<sven>
i have no idea
<sven>
i guess something kicked it every 100 or so ms
<kettenis>
AFAIK linux network drivers poll
kyjus25 has joined #asahi
<kettenis>
it seems robh is mostly happy with my pcie dt binding
<kettenis>
last version removes the "phy" set of registers, so that will require an adjustment in the driver code
<sven>
i'll probably send a v3 of the dart code to get some feedback on the 4k bypass hack but i hope that at least the dt binding should be fine sooner than later
<kettenis>
but bypass doesn't work for the pcie darts is it?
<sven>
only by programming a static pagetable
<sven>
i couldn't get bypass to work no matter which bits i set in the TCR
<kettenis>
right, that's what I do for u-boot
<sven>
and that matches with the some function called fullBypassSupported in the kext which checks if bit 1 in the register 0x04 is set
<sven>
so for the 4k pages what i can do for now is just setup a static pagetable to map 0x0..0x100000000 to 0x800000000 and then setup dma-ranges to let the dma layer know about that offset
<sven>
not great, but maybe better than just stopping at a BUG_ON during early boot