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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<j_ey>
cool maz reviewed my code and then provided me a patch with all their suggestions
<alyssa>
j_ey: don't get any ideas for me doing code review like that ;-p
<chadmed>
nsklaus: firmware/pre-linux stuff does an asston of hardware initialisation on x86 too, its just that its all proprietary and you dont get to see it happening
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
<nico_32>
and on server class hardware
<nico_32>
you've very strange thing happening
<nico_32>
dell uefi calling into the idrac to do firmware upgrade
<nico_32>
'(iDrac that boot with uboot)
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
nehsou^ has joined #asahi
xorly[m] has joined #asahi
xorly[m] has quit []
xorly[m] has joined #asahi
chadmed has quit [Quit: Konversation terminated!]
Glanzmann has quit [Quit: leaving]
chadmed has joined #asahi
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #asahi
xorly[m] has quit [Quit: Reconnecting]
xorly[m] has joined #asahi
tertu2 has joined #asahi
tertu has quit [Ping timeout: 480 seconds]
<marcan>
< nsklaus> marcan may need to that too <- yeah...
<marcan>
nsklaus: firmware's job is to get the system into a sane state
<marcan>
m1n1's job is to get the system into a sane state for Linux
<marcan>
(partially by fixing insanity that iBoot leaves behind)
<marcan>
m1n1 is best compared to part of UEFI/FSP on PCs
<marcan>
it is not really a bootloader, it's even less of a bootloader than UEFI
<j_ey>
linux's job is to get the system into a usuable state for the user
<marcan>
speaking of, I have a few TODOS I should get into m1n1
<marcan>
pmgr cleanup and cpufreq init for one
<nsklaus>
marcan: (and chadmed too): my comments were not criticism about m1n1 specificaly, and may have been motivated by a lack of comprehension of how things actualy work, on x86 too. on x86 the bios probably did the same kind of hardware initialisation jobs and i didn't get to see it either, even in the lilo days. but at that time it didn't seems strange to me.
<chadmed>
yeah thats totally understandable. i dont think anyone was trying to have a go at you :)
<nsklaus>
even though it's probably the same things that m1n1 does
<nsklaus>
yes, no problem
<nsklaus>
i was just trying to justify myself, and why i said what i said. there may have been a part of ignorance from me,
<chadmed>
its hard to accustom yourself to the quirks and procedures of other platforms if all youve known for the past 20 years is x86, as is probably the case for most people
<nsklaus>
about this whole part of the boot process
<nsklaus>
my question and comments might look sometimes like criticism, but they're not really that. it's just the way i ask questions to get a better understanding
<nsklaus>
chadmed: yes, indeed
<nsklaus>
about getting used to a different platform, its differences and quirks, as you were saying, on mac i find it too bad there's no interface to customize settings (like bios on pc)
<nsklaus>
but well.. if linux can just boot, and i can finally get a sane env and ditch maacos i'll just be happy
<chadmed>
yeah, most non-x86 platforms lack that. if we ever see x86 supplanted in a large way in the enthusiast space i suspect we will see firmware implementations that take care of that. if AMD/Intel ever decide to abandon it they will probably make sure that nothing about the PC platform changes except the ISA in the chips, as its vital to their revenue
<chadmed>
i.e. you will have an $ISA platform with ACPI, UEFI, "BIOS" settings, etc
<j_ey>
most of the times I need to go into BIOS, something wasnt working, and I was annoyed :P
<nsklaus>
that would be nice
<nsklaus>
j_ey: in a bios with simple interface, one could set boot order, or boot security levels for example or toggle some hardware features on/off
<chadmed>
additionally, theres nothing stopping current ARM/RISC-V vendors from offering a platform like that. in fact, in the server space ARM machines commonly have ACPI or UEFI. theres just not been a need for any of that in the traditional non-x86 markets (i.e. mobile devices, SBCs, embedded, etc)
<nsklaus>
on mac we need to boot the whole bloated macos to be able to have some form of control over those example i gave
aleasto has joined #asahi
<chadmed>
yeah, and its likely that this will continue since thats how apple likes their platform. try not to think of the new macs as PC-equivalent, but rather idevices with a higher tdp, because thats essentially what the platform is
<nsklaus>
what is "tdp" ?
<chadmed>
thermal design power, basically how much thermal energy the chip is designed to disspiate (measured in W) under "normal" operating conditions
<nsklaus>
i see, thanks for telling
<chadmed>
it has traditionally been a pretty decent proxy for chip power consumption, but is becoming increasingly meaningless because of boosting algorithms and how TDP is calculated by chip designers
<nsklaus>
yes, i actually like m1 arch so far, lots of crunch power, without hardware heat, and very low power consumption.
<nsklaus>
i have a 2015 intel macbookpro with arch linux on it, just having the darn thing on makes it warm
<chadmed>
yeah its insane, the entire M1 mac mini pulls something like 30W at the wall under full load which is ridiculous considering it is performance competitive with PCs double its price
<chadmed>
which under similar conditions would guzzle down hundreds of Watts
<nsklaus>
indeed
<marcan>
and on monday we're getting new Macs with 2x the performance...
<marcan>
and I totally see a 4x version dropping at some point...
<marcan>
it's almost scary, but Apple is really doing something crazy here
<nsklaus>
and hopefully no more touchbar :) return of magsafe, and more ports too
<j_ey>
got the scoop right here ^
<j_ey>
marcan: soo tuesday stream m1x bringup? :P
<marcan>
new magsafe that's just USB Type C with most of the pins removed :D
<chadmed>
the touchbar being gone has been confirmed for a while now. good riddance imo
<marcan>
j_ey: the *announcement* is tuesday morning for me :p
<nsklaus>
chadmed: truely
<marcan>
also I don't think they ship *that* quickly
<marcan>
:p
<chadmed>
gonna go to the gym and grab an energy drink in a little while so i can stay up for the event. 3am? childs play.
<marcan>
only sad thing about the touchbar is M1 MBP owners are likely going to be stuck with a dead ecosystem
<marcan>
I somehow doubt anyone's going to add any kind of integration with desktop environments to support one machine model...
<marcan>
so we'll have soft keys and that's about it, is my guess
<marcan>
(well, no different from boot camp on the x86 Macs)
<nsklaus>
i'm thinking of exchanging my m1 for a m1x just for the touchbar being gone, but i wouldn't mind the 2x perfs bump too :)
<chadmed>
i have a cruddy A1708 macbook pro you can have, no touchbar :P
<nsklaus>
i think i'll pass on that offer :)
<nsklaus>
monday announcemnt should be wild, with tons of hype words
<sorear>
increasingly of the opinion ISA is a bad proxy for anything platform related
<sven>
hm... let's see if i can justify buying another m1x then :D
<sven>
i think a mac mini with 32gb ram would be tempting
<nsklaus>
the only problem i have with m1 so far, is about the gpu side, on macos i mean, it seems it's tailored for metal api, and it seems it's lacking some functionality compared to opengl and vulkan. the result is that games running through wine don't display well or refuse to run completely for missign feature.
<j_ey>
sven: you need one for dartv2 compatible :P
<marcan>
nsklaus: that's just because apple doesn't support opengl properly
<nsklaus>
i'm wondering how that will turn out on asahi once the gpu driver will progress enough
<chadmed>
nsklaus: yeah the gpu lacks some hardware implementations of opengl/vulkan functions that some games will assume. hopefully we get some software emulation of this missing functionality at some point but that wont be coming from official sources
<nsklaus>
i mean, if full vulkan and opengl will be able to run at all, or not. i'm fearing limitations in the gpu itself
<chadmed>
if you think that's bad, just remember that x86 chips didnt have integrated FPUs until the the 486
<j_ey>
nsklaus: well alyssa is passing most of the opengl tests isnt she?
<nsklaus>
on moltenvk git, cdavis (i think he's one of the lead dev of that project) hinted he would resort to tricks and emulations of said missing feature too, but so far that hasn't happened yet, i compile moltenvk and run it bleeding edge each time i see a commit on their github, but so far result in-game is always the same
<chadmed>
oh theyll definitely be able to run, theyll just require some software emulation of functionality that vulkan/opengl have that metal does not. fortunately though, at the end of the day stuff like that is just abstractions of math concepts, and because all GPUs do virtually the same maths even though the hardware has no explicit support for vulkan/opengl its hardware should be able to handle most of both APIs fairly well
<marcan>
the GPU has hardware support for some OpenGL-specific features already
<marcan>
and lots of things are done in shaders, so it seems unlikely we'd run into any horrible showstoppers
<nsklaus>
from my (limited) understanding, one of the most problematic missing feature so far is the lack of " transform feedback"
<maz>
j_ey: quite often, it is more painful to review the code and explain what it should be like rather than just hack the damn thing and provide the patch, retrospectively writing the review.
<nsklaus>
fallout4 running on wine on macos looks very bland and many objects and lights are not showing correctly
<marcan>
I'll defer to alyssa on that specific feature
<nsklaus>
curiously enough, running the same fallout4 under paralells (macos virtualization app) produce exactly the same errors, so i guess paralells uses moltenvk too for the graphic stack
<j_ey>
maz: :) it compiles at least! will test this afternoon. gotta go for a bike ride while its still dry out!
<chadmed>
nsklaus: fallout 4 (or any creation engine game) probably isnt the best tool to use to test an API's stability just saying ;)
<chadmed>
youd be lucky to get fo4 to look anything but bland/incorrect even on a windows machine with directx
<nsklaus>
chadmed: i tested many games, like witcher3 too and many other, and i see similar errors
<nsklaus>
on x86 linux, with fully supported vulkan and dxvk all those games, including fallout4 and witcher3 they run fine
<nsklaus>
i think the problem is with macos only partially supporting vulkan through moltenvk
<chadmed>
i mean yeah its probably moltenvk i just wanted to make a joke about how awfully optimised bethesda games are
<nsklaus>
many missing extensions
<nsklaus>
but i agree bethesda games are full of bugs, problems and bloat, unoptimised and all
<chadmed>
but these are definitely questions best directed to alyssa, whether or not moltenvk's level of support can be used as a yardstick to predict how complete our opengl/vulkan implementation will be is something i cant answer for you
<nsklaus>
resident evil 2 remake won't run too on macos + wine , while on x86 linux it runs fine
<nsklaus>
yes
<chadmed>
consider also that there may be bugs with rosetta 2 that prevent the game engine from doing what it needs to do on the cpu
<maz>
j_ey: well, compilation is the only thing I tested!
<nsklaus>
there might be that too, but on those issue i suspect moltenvk missing some extension primarily
<chadmed>
again, not really something im gonna pretend to know how to answer. i am a dumb hardware jock and embarrassingly incompetent at anything software
<nsklaus>
(about rosetta2)
<VinDuv>
honestly I’m impressed that the combination wine + moltenvk + rosetta2 even works at all :)
<chadmed>
even more impressive is that some games are playable. gtav 60+ fps on a macbook air, csgo 100+fps on the same
<nsklaus>
VinDuv: performance-wise, it works surprisingly well, considering all the multiple levels of encapsulations and layer the software run through
<nsklaus>
fallout4 and witcher3 for example, are AAA titles, and they run fast
<chadmed>
counter strike is especially impressive because it contains an in-engine implementation of toGL, so its dx9-->toGL-->moltenvk-->metal all on rosetta 2
<nsklaus>
my hope though is that we will be having direct vulkan and opengl support without the need for that moltenvk layer
<nsklaus>
those missing gpu features point, it will mean either linux port of moltenvk, or reimplementation of what it does.. either way that will be a tricky part
<marcan>
moltenvk makes no sense on linux
<marcan>
again, this is not a "metal" GPU
<marcan>
if it's missing GL features they can be emulated, but that has nothing to do with VK on Metal
<nsklaus>
i mean, there's no metal on linux obviously, but i'm talking about glue code for working around missing gpu features and ending with a working vulkan
<marcan>
yes, but that code is going to look completely different on top of metal and on top of bare hardware
<nsklaus>
that should be an interesting milestone to watch, once we reach it.
<nsklaus>
i mean, once the gpu driver reach the point where it need to consider how it will tackle this problem, watch the road it will choose
pugguu has quit [Remote host closed the connection]
<kettenis>
sven: the mailbox driver still has the code to enable clocks
<sven>
good point. let me drop that
<kettenis>
want me to reply on the mailing list?
<sven>
can't hurt i guess
<kettenis>
such that patchwork records it?
<sven>
yeah
<sven>
otherwise i'd just be a note in the cover letter for v3
<kettenis>
oh wait, you didn't send out v3 yet
<sven>
every now and then my laziness is actually useful ;)
<kettenis>
heh, well, I could have told you about this earlier ;)
nsklaus_ has joined #asahi
nsklaus has quit [Ping timeout: 480 seconds]
<sven>
alright. submitted v3 now
<j_ey>
sven: "This is the second version of my series", v3 is the 2nd series? :P
<sven>
*sigh*
<j_ey>
second version after the first version
<chadmed>
uh ok so i just realised that the event isnt until the 19th in UTC+10... aaaand its 10pm and i just had an energy drink thinking that the event was this evening...
<j_ey>
chadmed: lol
<sven>
haha :D
<chadmed>
someone please remind me never to do things XD
<maz>
sven: talking about reposting stuff... have you reposted your 4K series?
<sven>
uhh... not yet. but good point
<sven>
i think the other series i was waiting for that fixed some swiotlb/iommu interaction has been merged at this point
<chadmed>
nsklaus: the gpu doesnt "speak" metal, it "speaks" AGX. when we say that it implements "metal" features all that means is that the hardware has optimised blocks to do the maths associated with those functions.
<j_ey>
asahi/dart/4kpgsize is so old it has the DART driver cherry-picked!
<sven>
it also won't apply anymore at this point :D
<maz>
you want to keep Robin entertained.
<chadmed>
consider an "rt core" on an Ampere or Turing gpu. the core doesnt "trace rays" or anything, its just highly optimised for calculating the intersections of matrices, in the case of ray tracing (specifically BVH/culling) that would be the vector representing the ray emitted by the light source, and the matrix representing the coordinates of the bounding volume of whatever the ray is intersecting
<j_ey>
I have yet to meet Robin, he wasn't at the office when I went in
<maz>
j_ey: you're missing out. he's awesome.
<j_ey>
maz: when I went to the office, I couldnt find my desktop machine, I could ping and ssh it, but I wasnt sure where it was :P
<chadmed>
you could, feasibly, use "rt core" hardware to speed up any similar matrix operations, just as the "metal" hardware in the apple gpu can be used just fine for opengl/vulkan features that do the same maths. for others, you can just build a software model of the maths that the particular opengl/vulkan feature does and run it. we will not need to translate metal to vulkan on linux at all.
<maz>
j_ey: ah! that's because you didn't have a TX2 as a desktop. reboot the box, and you immediately know where it is, thanks to the fan basting out a tornado until EFI takes over.
<j_ey>
:D
<maz>
of course, with a mini as a desktop, you immediately lose it under the crap that lands on the desk...
<j_ey>
since I just moved office, I have a clean desk, I will try keep it that way :P
<maz>
I'd have to move office every two weeks...
<j_ey>
>_<
<sven>
what is this office thing you speak of? i have faint memories of such a place :P
<j_ey>
sven: it was pretty weird going back
<sven>
i think i've been in my office uhh... twice since i switched jobs earlier this year
<maz>
I went into the office quite regularly lately. it really felt good being able to design stuff around a white board with actual human beings.
<sven>
true
<sven>
in my case it doesn't help that my office right now is ~1.5 hours away because i've been too lazy to actually move closer
<maz>
for me, the past 18 months have shown that I *can* work fully remotely. but it has also demonstrated that I don't *want* it.
<maz>
yeah, same thing for me. I now have to commute to London, which is a total pain. and I have no intention to relocate there!
<maz>
I'm happy to go in 2/3 days a week. so far, it feels like a balance I can live with.
<j_ey>
i thought engineers were meant to be antisocial!!
<maz>
I can be antisocial face-to-face!
<sven>
yeah, 2/3 days per week sounds perfect on average.
<j_ey>
maz: lol
<sven>
let's see if my employers agrees with that once they go back to "normal". otherwise i'll just switch again.
<marcan>
maz: I was with human beings and a white board earlier, we were discussing chord progressions during the jazz jam ;)
<marcan>
I haven't been to an actual office since march 2020...
<maz>
marcan: :D
<eta>
I've never had a job in an office
<eta>
...then again, I only started working in 2020 :p
<eta>
<maz> yeah, same thing for me. I now have to commute to London, which is a total pain. and I have no intention to relocate there! ← enjoy spending shitloads on train fares
<j_ey>
it's either that or a shitload on a house in london :P
<marcan>
is it worse than tokyo these days? :p
<maz>
eta: the nice thing is that you lay a lot for trains that don't show up.
<eta>
oh, I know
<maz>
s/lay/pay/
<eta>
maz, you can get money back for those ones though
<marcan>
at least the trains are on time here
<eta>
I just went up to Glasgow
<sven>
.jp trains are pretty awesome in general
<eta>
both trains were ~30 minutes late >.>
<eta>
in general the UK is pretty good for punctuality though
<eta>
and there's delay repay, so you can claim money back for delays
<maz>
eta: compared to other European countries, the UK trains are pretty crap. even France does better, even with the strikes! ;-)
<eta>
"we did it first, and now we're the worst"
<chadmed>
what a rousing success the neoliberal experiment has been :-{
<j_ey>
is it normal to just do review comments you agree with, without replying to everyone?
<sven>
i usually try to at least try to reply to everyone
<sven>
erm
<sven>
remove one "try to" there :D
<j_ey>
sven: like your interrupt-cells example comment.. I'll just do it and mention it in the 'changes' line for v4..
<sven>
oh, sure
<sven>
alright, sent the cursed usb quirk series as well
<sven>
time for 4k pages now i guess
<j_ey>
sven: did you send a cover letter for the quirk? (might just be slow to reach lore.kernel..)
<sven>
no
<sven>
i feel like the explanation in the commit is enough
<j_ey>
feel free to give me a reported-by or something tag :P
<marcan>
send a PR? :D
<j_ey>
ehhh
<j_ey>
seems to fix my issues, no panics yet..
<j_ey>
after 5+ boots
<marcan>
you could probably pinpoint the exact moment in the "let me just make the HV do SMP" stream where I copypasta'd that and neglected to edit it :)
<j_ey>
Glanzmann: ^ git branch -r or git branch -a to show remote stuff
<Glanzmann>
j_ey: Thanks, will keep that in mind, I thought when I do a git pull it will mention new branches, but maybe I have already pulled before ...
* Glanzmann
is ashamed as a git early adopter who once wrote is own frontend to git ...
<j_ey>
Glanzmann: ok I see what you mean, yeah I think you probably just had it already
<Glanzmann>
j_ey: You certainly teach an old dog some new tricks. :-) (infra) [/scratch/linux-allysa] ./scripts/faddr2line vmlinux dcp_flush+0x2a0/0x400 | pbot -
<alyssa>
but then how do you ensure the display subsystem doesn't probe until both coprocessors boot?
<alyssa>
The "obvious" way is to have an "is_booted()" call on the DCP driver
<alyssa>
and in the apple-display driver probe(), check if all the coprocessors from the DT are booted and if not return -EPROBE_DEFER
<alyssa>
and then the core logic will try again later when the DCPs come up
<j_ey>
I dont under DEFER, how does it know when to reprobe?
<alyssa>
This is racy-- the core logic will stop trying to probe after a while if you DEFER too many times. Depending how fast the DCPs come up, this can be racy
<j_ey>
*understand
<alyssa>
j_ey: it just keeps trying
<sven>
iirc EPROBE_DEFER effectively moves the device to a "wait list". and whenever another device has successfully probed everything from that "wait list" is tried again
<alyssa>
Ahhhhh
<alyssa>
sven: so it's sae to DEFER on "another device has probe()d" ubut not safe to DEFER on "another device has booted after probing"
<alyssa>
?
<sven>
uh... maybe? :D
<alyssa>
that makes sense
<alyssa>
thank you
<j_ey>
the display could maybe have a timeout? / check N times
<Glanzmann>
alyssa: I tried to boot again with the older monitor, now it comes up alright.
<Glanzmann>
alyssa: Did you improve the DCP code? I think the tiering in firefox is gone or might it be because I currently don't have my display rotated?
rohin has quit [Ping timeout: 480 seconds]
<Glanzmann>
alyssa: no even with a rotated display no tiering.
jmr2 has joined #asahi
<j_ey>
Glanzmann: tearing
<Glanzmann>
Okay, when I scroll with the mouse I have tearing. But with the page up/down, I don't.
<Glanzmann>
j_ey: yep. :-)
aleasto has quit [Quit: Konversation terminated!]
<jmr2>
alyssa: for when you'll be bored ;) I hink you'll find this interesting.
<Glanzmann>
alyssa: I hit bed now, if you have anything for me to try, let me know and I'll do so.
<alyssa>
jmr2: parse tag is destructive, that won't work
<alyssa>
(skip is also destructive)
<alyssa>
jmr2: anyway, i'll need the actual dumps of what we're trying to parse
<jmr2>
Ah. OK, thanks. I tried :)
<alyssa>
You did! :)
rohin has joined #asahi
rross101 has joined #asahi
<rross101>
FWIW I've documented what it took for me to get from scratch to a login prompt. This is all really basic but might be useful for other newcomers like me. Thanks Glanzmann and j_ey for their help. https://gist.github.com/rross101/84def12f02e1476a4e6d2fd28a89b1a0
<alyssa>
erasing the mac is definitely not necessary
<rross101>
Fiar enough! I started with a Mac that had too much data on it to partition. And I figured I needed to be prepared to lose all the data.
<rross101>
*Fair
<povik>
alyssa: is there any chance the DCP driver as-is will cope with kexec? (assuming both old and new kernel probe the DCP)
<sven>
nope. anything that uses the rtkit library right now will likely not work
<sven>
nvme definitely won't
<steev>
rross101: if you -b 20211013 to your git clone line, it'll automatically do the checkout
<povik>
darn, was afraid that is the case
<j_ey>
sven: how does that work with uboot loading stuff off nvme?
<povik>
nvme is important in my use case as you can guess
<sven>
j_ey: i don't think it does (unless i commited a hack) but that's fixable at least
<steev>
rross101: also, if you're just gonna accept the default answers, you can use the "olddefconfig" and it should use the defaults instead of prompting you
<sven>
the "proper" way is to shutdown the nvme co-processor and then use that reset provider marcan implemented
<sven>
that'll work for ANS, but i think it didn't work for DCP because DCP then probably speaks the iBoot protocol which we don't know about
<rross101>
steev: Thanks - didn't know either of those things. First time using git branches and compiling a kernel.
<steev>
:)
<j_ey>
steev: what does oldconfig do?
<j_ey>
oldconfig - Update current config utilising a provided .config as base, dont really get that
<steev>
it means "show me all the new entries available since this config was used"
<steev>
so your .config is the base, and if there are any new options, it will prompt you for what you want to do with them
<j_ey>
I seem to get that anyway
<rross101>
so the second time around it wouldn't ask all the questions
<sven>
povik: what exactly is your use case?
<povik>
petitboot
<steev>
if you do "make olddefconfig" it's like saying, use this as the base, and any new options, just take their default settings
<j_ey>
I have to get to grips with config management, it's a mess rn
<rross101>
more importantly - were there any of those questions I should have answered differently?
<steev>
let me clone the kernel stuff and take a looksie
<sven>
povik: so petitboot is another linux kernel? or how does that work?
<povik>
i have already made NixOS play nicely with petitboot on another arm64 board
<j_ey>
rross101: probably not
<povik>
and haven't yet dropped the idea of making it work here also
<j_ey>
povik: which arm board?
<povik>
sven: petitboot is effectively an kexec-based bootloader
<steev>
btw, typo rross101 - 'wget curl https://ab34.de/u/0001-compile-fixes.patch' - you might want to either wget, or curl, but otherwise it'll try to wget the file curl :)
<sven>
povik: what does that mean? does it use a literal linux kernel which would probe DCP, ANS and everything else? or does it just implement the kexec protocol?
<steev>
rross101: you could also "git am 0001-compile-fixes.patch" instead of patch -p1, not that it truly matters since it's unlikely most people will keep the kernel sources around :)
<povik>
well depends on what features and DT nodes i enable in the interim kernel
<povik>
it would be useful by being a linux kernel with minimal userspace appended to m1n1 and fixed in the m1's boot policy
<j_ey>
povik: but petitboot is based on the linux kernel right?
<povik>
j_ey: yeah
<sven>
ok. that's what i was asking :D
<j_ey>
is it just a normal userspace program?
<povik>
j_ey: yeah
<sven>
okay. so that's not impossible but it's going to be bit messy right now
<steev>
wow this linux repo is friggin huge
<sven>
if you send the right commands to e.g. ANS2 it will go to hibernation/deep-sleep mode and then the next linux kernel would be able to wake it up again
<j_ey>
steev: 'this'? all linux repos are :P
<sven>
or, if you wanna do it the proper way, send the commands to shutdown ANS2 and then adjust the nvme driver to issue a reset
<alyssa>
povik: It's worth noting I explicitly think using DCP in the bootloader is... a bit silly.
<steev>
j_ey: nah, it's at 2.83gb and only 53% cloned, my torvalds checkout with built files is only 5.9 and it has 11 remotes
<alyssa>
There is a way to make all of this work of course (1TR -> macOS)
<alyssa>
but for the typical case it ... isn't necessary?
<alyssa>
the iBoot simple-framebuffer ought to be sufficient for the first stage bootloader anyway
<j_ey>
steev: hm, i wonder why then
<steev>
no idea :) i'm just cloning it
<steev>
i just wanna see what rross101 was asking about. it's odd because a bunch of new options shouldn't be added post rc1, but i could be wrong (alyssa's config is for rc1)
rohin2 has joined #asahi
<j_ey>
my linux dir is 5.8G, but I dont have mu-linux as a remote