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
<chadmed>
marcan: late to the party but yeah DCP is probably more important at this stage than an install script. imo the kind of people who would want to play around with the WIP stuff (i.e. people who dont mind that they cant boot a live usb and look at plasma desktop just yet) dont mind the extra work required to set it up at this stage, so getting everything working is a better use of time than making what is done more
<amw>
I can't link the Linux code names with the relevant ARM64 Exception terms - e.g. e1h_64_error -> is that Hypervisor exception, PL1 ?
<amw>
Linux code has an esr register - what should I look at in the ARM manual to decode that?
<amw>
PSTATE is clear enough - but is that exception because it accessed a bad address, illegal (PAN active?) address and if so what address?
<chadmed>
EL2 is the hypervisor exception level
<chadmed>
by the looks of it its the mbox driver thats causing a bad interrupt
<amw>
Great - is there a way to point to how I can learn how to decode this - the disconnect of the linux info from the ARM manuals is very frustrating
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
<chadmed>
looking at the stack dump it seems like apple_mbox_hw_can_send is what is offending the system. serrors are caused by illegal memory access so if the error is infinitely reproducible the easiest way would be to just trace the stack while you let it happen and see what the mbox driver is trying to do. kdebug maybe?
<chadmed>
since serrors are asynchorous theres no easy way to tell exactly when it occurs either
<amw>
chadmed: Thanks - my ARM64 manual doesn't have the term SERROR in it at all - but google found another ARM document on Exception types that says it is an System Error -> memory system
<amw>
It's very reproducible so that's my way in - at least now thanks to you I have some idea of what it is complaining about
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<chadmed>
no problems mate. id love to be able to help out with debug work but we're locked down right now and i dont have access to hardware
<chadmed>
envy of the world to laughingstock in under a year :)
<alyssa>
chadmed: AU?
<chadmed>
yeah, queensland. we had life basically back to normal for most of 2020 and into this year too, but because the federal government (here responsible for procuring and administering vaccines) did not procure or administer vaccines because its full of anti vaxxers we are currently at 16% vax rate and having Delta outbreaks everywhere
<alyssa>
𝛅
<marcan>
amw: I think SPI is another smasung derivative, needs some digging to see if we already have a driver for similar enough hardware
<marcan>
(as we did for serial, and i2c)
<marcan>
amw: re SError, unfortunately there's no useful info there. Usually SError is a fabric error on M1, and to decode that you need a dump of some proprietary registers
<marcan>
I should add a patch for that to a branch somewhere, probably won't ever get merged but we should be running it for debugging
<marcan>
the proprietary registers tell you exactly what address and access type caused the SError
<amw>
marcan: So I'm ok to patch another (Samsung based?) spi driver et cetera based on my readings of corellium code
<amw>
Perhaps similarly with the SError register info
marvin24_ has joined #asahi
<marcan>
amw: the question is whether such driver exists and how close it is to this hardware
<marcan>
corellium wrote their own uart driver which was dumb, as linux already had a samsung uart driver we could adapt
<marcan>
so I suspect the same might be true for SPI but I haven't looked at it yet
<marcan>
they also did that for i2c which again was silly, we know there's a driver that is nearly identical already :p
<marcan>
the SError stuff is another story, that's core arch code and I don't know if there is any precedent for having SoC-specific syndrome register dumps in there
marvin24 has quit [Ping timeout: 480 seconds]
<marcan>
the reason why I usually avoid reading corellium code is not because I hate them, it's because it's often wrong and would lead to red herrings or point toward the wrong approach
<marcan>
I would treat it as license-incompatible out of an abundance of caution, but reading it is not banned or anything
<marcan>
I'm more worried about it leading people down wrong paths than about the licensing question
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi
roxfan has quit [Read error: Connection reset by peer]
roxfan has joined #asahi
<marcan>
oh and if you meant reading corellium code for the SError stuff: I don't know if they have that at all, but it's in m1n1's exception handler, so use that as a reference (the L2C_* registers)
<marcan>
the field descriptions are on the docs wiki (as far as I figured out)
<marcan>
I don't think they cared about SErrors, seeing as they actually disabled them, presumably to work around driver bugs ;)
<marcan>
ok, I'm going to do a cleanup pass on the DCP commits then spend a day or two looking into an install script. worth giving it that much time.
boardwalk has joined #asahi
<amw>
I think I might try and get this error under the hypervisor as it might be a much better way to debug exceptions
<marcan>
the hypervisor does not forward SErrors, so yes, you'll get the m1n1 dump in that case with the L2C registers
<marcan>
actually, it'll throw you into the python handler, let me check if the L2C regs are dumped there
<marcan>
but if they aren't, you're in a shell so you can just mrs() them anyway
<marcan>
ah yeah, not in the handler
<marcan>
but easy enough to get as I said
<marcan>
just mrs(L2C_ERR_STS_EL1) and L2C_ERR_ADR_EL1 and L2C_ERR_INF_EL1
<amw>
ok - will have a go and report back. I think I need to disable the first USB port in the device tree so m1n1 can use it
<marcan>
yes
<marcan>
and run with 1 cpu only of course
<amw>
No special kernel cmdline for 1 cpu? Just a edited ds
<marcan>
smp=off should work
<marcan>
but you need to run m1n1 under the hv first to be able to boot linux; you should be able to use the second USB port to talk to the inner m1n1 and launch linux that way
<marcan>
alternatively, concatenate m1n1 and linux using payload mode and load it directly under the hv
<amw>
pipcet[m]: Thanks - my MBP is down doing an update/charging (run it out of battery under m1n1 I think)
<amw>
*Sorry that was MBA - I think it might have been running m1n1 when I closed the lid till the battery went flat - it wouldn't start up till I plugged in a power cable to a good USB charger
<marcan>
yeah, it might not charge properly under m1n1
<pipcet[m]>
do we know it's charging properly under linux? :-)
<pipcet[m]>
(the SMC stuff to query battery status and all that stuff isn't hard, but I'm waiting for the ASC mailbox stuff to work properly)
VinDuv_ is now known as VinDuv
bps has quit [Ping timeout: 480 seconds]
<sven>
at this point i think the mailbox driver should probably really only implement the "dumb" mailbox interface. that's at least what all other drivers in there also do
<sven>
still not sure where the other rtkit stuff (syslog, etc.) should go
<pipcet[m]>
how "dumb", though? single-channel mailbox or one channel for each endpoint?
<sven>
one channel for each endpoint
<sven>
can be used for all rtkit stuff and also for the SEP then
<amw>
I'm getting a ImportError on "python3.9 ./proxyclient/m1n1/adt.py --retrieve dt.bin" - attempted relative import with no known parent package
<amw>
Removing the '.' from .utils just pushes the problem further down to "from .setup import *"
<amw>
and further removing that leads to other ones in ./proxyclient/m1n1/setup.py ...?
<rkjnsn[m]>
For the installer, would it be at all reasonable to build a self-contained binary using, e.g., Rust, rather than the install script needing to download a full Python interpreter?
<marcan>
I'll clean up the commits and push to main later
<sven>
"push some more wtf" "hope that makes more sense now" :D
<marcan>
rkjnsn[m]: what's the difference?
<marcan>
a stripped down python isn't that large, you can throw away most of the modules
<marcan>
installation is going to involve a 1GB recovery image, so 50MB or whatever for python is rounding error
<rkjnsn[m]>
Smaller download, conceptually simpler (to my brain, at least) would be the advantages that would push me that way. Not relevant, since I probably won't be hacking on it, but I also find compiled languages to be more productive for me personally since the kinds of mistakes I tend to make most are the ones compilers are good at catching before even running the code.
bps has joined #asahi
<rkjnsn[m]>
Not having to maintain the stripped-down Python package, I guess. Since the project already has a lot of Python code, though, I will readily admit that's a good point for using it rather than introducing a new language.
<j_ey>
amw: it's "el1h_64_error", EL1H is in the armarm
<sven>
it's definitely the missing clock gate :-)
<sven>
we still need to figure out those clock bindings :/
<amw>
I think my changes to proxyclient/m1n1/shell.py have broken proxyclient/tools/shell.py :-( sorry
<sven>
you can also add the call to main.c
<amw>
sven: Yep - this fixes my boot up with the nvme tree: pmgr_adt_clocks_enable("/arm-io/ans")
<amw>
Under shell.py - I had to fix the broken help code though - just did a try to catch the exception when no Signature found
<chadmed>
rkjnsn: there are ways to package/bundle the python interpreter and whatever modules you need with your script and have it run in a self-contained way. as marcan said, the size added by doing this is insignificant
<chadmed>
now if it were _just_ the script required as a self-contained program without such a huge external dependency then i think most would agree that writing a proper program would be beneficial. but as it stands, its more work for questionable benefit
<amw>
marcan: Just made PR for the fix to shell.py
<sven>
i strongly recommend against doing that for now fwiw. the mailbox driver is still quite a hack and the co-processor is not shut down cleanly. now if you're still brave enough to continue: if you follow that general setup guide you should have two FAT partitions there
<sven>
just format one of them with ext4 or whatever system you prefer
<sven>
probably p5 in your case
<j_ey>
why is it FAT?
<sven>
because i think that's the closest thing you can select in disk util :d
<sven>
*:D
<sven>
doesn't matter either way
_alice has quit [Quit: Bridge terminating on SIGTERM]
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
perigoso[m] has quit [Quit: Bridge terminating on SIGTERM]
maxim[m] has quit []
davay[m] has quit [Quit: Bridge terminating on SIGTERM]
angustrau[m] has quit [Quit: Bridge terminating on SIGTERM]
jammie[m] has quit [Quit: Bridge terminating on SIGTERM]
bfredl[m] has quit [Quit: Bridge terminating on SIGTERM]
brentr123[m] has quit [Quit: Bridge terminating on SIGTERM]
noc0lour[m] has quit [Quit: Bridge terminating on SIGTERM]
PthariensFlame[m] has quit [Quit: Bridge terminating on SIGTERM]
sephamorr[m] has quit [Quit: Bridge terminating on SIGTERM]
stttcccccccccccc[m] has quit [Quit: Bridge terminating on SIGTERM]
sandornagy[m] has quit [Quit: Bridge terminating on SIGTERM]
spot[m] has quit [Quit: Bridge terminating on SIGTERM]
svenpeter[m] has quit [Quit: Bridge terminating on SIGTERM]
Dementor[m] has quit [Quit: Bridge terminating on SIGTERM]
The_DarkFire_[m] has quit [Quit: Bridge terminating on SIGTERM]
YichaoYu[m] has quit [Quit: Bridge terminating on SIGTERM]
ted[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Izumoo[m] has quit [Quit: Bridge terminating on SIGTERM]
ganpa[m] has quit [Quit: Bridge terminating on SIGTERM]
mulderje has quit [Quit: Bridge terminating on SIGTERM]
ovf[m] has quit [Quit: Bridge terminating on SIGTERM]
vivithecanine[m] has quit [Quit: Bridge terminating on SIGTERM]
fluffypup[m] has quit [Quit: Bridge terminating on SIGTERM]
AndrewLee[m] has quit [Quit: Bridge terminating on SIGTERM]
andi-[m] has quit [Quit: Bridge terminating on SIGTERM]
Bastian[m] has quit [Quit: Bridge terminating on SIGTERM]
AkihikoOdaki[m] has quit [Quit: Bridge terminating on SIGTERM]
booffo[m] has quit [Quit: Bridge terminating on SIGTERM]
AlessandroFerrari[m] has quit [Quit: Bridge terminating on SIGTERM]
TypoKign[m] has quit [Quit: Bridge terminating on SIGTERM]
AONeiLL[m] has quit [Quit: Bridge terminating on SIGTERM]
alexanderwillner[m] has quit [Quit: Bridge terminating on SIGTERM]
cepheus has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit []
ll3macorn[m] has quit [Quit: Bridge terminating on SIGTERM]
MingcongBai[m] has quit [Quit: Bridge terminating on SIGTERM]
marcan[m] has quit [Quit: Bridge terminating on SIGTERM]
PeterHilgenfeld[m] has quit [Quit: Bridge terminating on SIGTERM]
nemanjan00[m] has quit [Quit: Bridge terminating on SIGTERM]
MagMell[m] has quit [Quit: Bridge terminating on SIGTERM]
facez[m] has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
SocioProphet[m] has quit [Quit: Bridge terminating on SIGTERM]
rob-3[m] has quit [Quit: Bridge terminating on SIGTERM]
quentincestino[m] has quit [Quit: Bridge terminating on SIGTERM]
uur[m] has quit [Quit: Bridge terminating on SIGTERM]
dpatterbee[m] has quit [Quit: Bridge terminating on SIGTERM]
julianp[m] has quit [Quit: Bridge terminating on SIGTERM]
alicela1n has quit [Quit: Bridge terminating on SIGTERM]
i509vcb[m] has quit [Quit: Bridge terminating on SIGTERM]
fedx[m] has quit [Quit: Bridge terminating on SIGTERM]
ella-0[m] has quit []
Aaron[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Serentty[m] has quit [Quit: Bridge terminating on SIGTERM]
alessandrorzz[m] has quit [Quit: Bridge terminating on SIGTERM]
davidrysk[m] has quit [Quit: Bridge terminating on SIGTERM]
bastilian[m] has quit [Quit: Bridge terminating on SIGTERM]
DanielHuisman[m] has quit [Quit: Bridge terminating on SIGTERM]
NikolaCicmil[m] has quit [Quit: Bridge terminating on SIGTERM]
blazra[m] has quit [Quit: Bridge terminating on SIGTERM]
izzyisles[m] has quit [Quit: Bridge terminating on SIGTERM]
Ferluci[m] has quit [Quit: Bridge terminating on SIGTERM]
PixelyIon[m] has quit [Quit: Bridge terminating on SIGTERM]
anfernee[m] has quit [Quit: Bridge terminating on SIGTERM]
rkjnsn[m] has quit [Quit: Bridge terminating on SIGTERM]
s-urabe[m] has quit [Quit: Bridge terminating on SIGTERM]
pitust[m] has quit [Quit: Bridge terminating on SIGTERM]
xerpi[m] has quit []
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
samfromspace[m] has quit [Quit: Bridge terminating on SIGTERM]
M32thSystem[m] has quit [Quit: Bridge terminating on SIGTERM]
bngs[m] has quit [Quit: Bridge terminating on SIGTERM]
RowanGoemans[m] has quit [Quit: Bridge terminating on SIGTERM]
c1truz[m] has quit [Quit: Bridge terminating on SIGTERM]
pipcet[m] has quit [Quit: Bridge terminating on SIGTERM]
rowang077[m] has quit [Quit: Bridge terminating on SIGTERM]
user1tt[m] has quit []
TellowKrinkle[m] has quit [Quit: Bridge terminating on SIGTERM]
PieroDel[m] has quit [Quit: Bridge terminating on SIGTERM]
CristianMgheruan-Stanciu[m] has quit [Quit: Bridge terminating on SIGTERM]
mmlb[m] has quit [Quit: Bridge terminating on SIGTERM]
ruach[m] has quit [Quit: Bridge terminating on SIGTERM]
ryanhrob[m] has quit [Quit: Bridge terminating on SIGTERM]
haterade[m] has quit [Quit: Bridge terminating on SIGTERM]
mofux[m] has quit [Quit: Bridge terminating on SIGTERM]
Scott[m]1 has quit [Quit: Bridge terminating on SIGTERM]
foxlet has quit [Quit: Bridge terminating on SIGTERM]
ilovetrains[m] has quit [Quit: Bridge terminating on SIGTERM]
hablerentand[m] has quit [Quit: Bridge terminating on SIGTERM]
cavoirom[m] has quit [Quit: Bridge terminating on SIGTERM]
LeviLynch[m] has quit [Quit: Bridge terminating on SIGTERM]
M32thSystem[m] has joined #asahi
<amw>
sven: Thanks - I might just focus on the keyboard/spi for the moment - but fun to get this far...
deed02392 has joined #asahi
<marcan>
amw: thanks, didn't catch that during the review
<marcan>
the installer will bundle a bunch of stuff anyway, we need stuff like img4tool and possibly some userspace filesystem stuff depending on how fancy we want to get with the linux install side
<marcan>
so it'll be python driving the UI and download and file operations, plus some helper tools for specific things that already exist
<sven>
kettenis: thanks for updating the device tree dart nodes in u-boot btw. that made booting with pci support much less painful :-)
<j_ey>
sven: force_bypass and supports_bypass, this would be true and false for PCIe?
<sven>
on 4k kernels, yes :(
<sven>
but i'll fix the dma-iommu api in a follow up
<j_ey>
for example 'def_domain_type' checks force_bypass but not supports_bypass
<sven>
yes
<sven>
so what will happen is that the iommu dev attach for a pcie device will fail
<j_ey>
where will it fail?
<sven>
apple_dart_attach_dev
<j_ey>
Oh, I see it now
<j_ey>
sven: so for 16k kernels, this dart code works fine for pcie?
<sven>
yes
<j_ey>
cool
<deed02392>
what does DCP stand for?
<j_ey>
display controller processor, or something like that
<j_ey>
deed02392: iBoot sets up a framebuffer, but without the DCP resolution can't be changed, brightness, colour grading(I think), stuff like that
<deed02392>
ahh, nice thanks for the info j_ey
<deed02392>
i was watching how it seemed to be responsible for drawing the tiles and cursor etc. on the screen as well, from the framebuffer. this was being re'd in the latest DCP youtube video i watched
<phire>
marcan: you know how you said the actual dcp hardware only supports 3 surfaces? what happens when you set all four?
<phire>
Is there some kind of multiplexing in the DCP firmware?
<j_ey>
there's no way to pass kernel commandline with the hv?
pipcet[m] has joined #asahi
<amw>
j_ey: The boot_args are for the HV. I tried it didn't go through to Linux
<pipcet[m]>
there is, but the kernel takes its command line from one of three locations (built-in, device tree, passed by boot loader) and it's a bit hard to make sure it's using the right one
<j_ey>
yeah, you could try it with bootargs in the chosen node in the dtb
<amw>
j_ey: I tried that and it didn't work for me
<pipcet[m]>
amw: is it possible your .config has CONFIG_CMDLINE_FORCE set?
<alyssa>
marcan: I like more wtf
<amw>
pipcet[m]: That's not set but CONFIG_CMDLINE_FROM_BOOTLOADER=y is set
yuyichao has quit [Ping timeout: 480 seconds]
<alyssa>
marcan: Do we understand what happens when src_rect != dst_rect for swap info?
<alyssa>
does it do the expected blit? (including rescaling up or down as needed?)
<mps>
this page is dated 'May 29, 2021' so maybe in meantime more drivers works
<j_ey>
mps: nothing more in upstream
<mps>
j_ey: thanks for info
<mps>
so not yet read as 'daily driver' computer, except maybe using linux in qemu
<j_ey>
mps: there's branches that have some nvme support, and pipcet[m] has more stuff working based on corelliums code
<mps>
s/read/ready/
<mps>
j_ey: thanks, will wait some time before decide it is good idea to buy one
<mps>
though I tested it with corellium kernel and alpine linux few months ago
<mps>
but it works only from usb disk
<marcan>
mps: I wouldn't recommend anything as a daily driver until we get the GPU working, but maybe that's just me
<mps>
marcan: first thank you for your awesome work
<marcan>
we aren't really prioritizing getting stuff working so much as getting stuff working *right*, so e.g. there is no keyboard support yet, not because it's hard but because we've been busy with more interesting drivers :)
<alyssa>
mps: If you're a linux hat, the M1 isn't a computer, it's an expensive toy for reverse-engineering addicts like marcan and me
<mps>
marcan: maybe gpu is not much important to my use case, I use chromebooks without gpu driver and that is quite fine for me
<marcan>
depends on what you do I guess, e.g. playing video without GPU is, at best, questionable (tearing...)
<mps>
alyssa: well, I understand this I think
<marcan>
but either way I'm going to work on the installation tools a bit this week, which will at least make it less annoying to set up for development
<alyssa>
marcan: that video players need GPU is more of a "linux video players suck" issue and not anything more fundamental
<marcan>
alyssa: good luck playing video without tearing on the iBoot framebuffer
<alyssa>
marcan: that's DCP, though
<marcan>
yes :p
<mps>
marcan: I use old mt8173 (acer R13) chromebook (linux installed first day) for about 5 years without gpu driver and I'm quite satisfied
<j_ey>
marcan: on stream or nah?
<marcan>
j_ey: probably on stream tomorrow
<alyssa>
for video playback, GPU is really only used for colour space conversion and scaling
<alyssa>
both of which suck on the CPU
<marcan>
yup
<marcan>
also something DCP can do
<alyssa>
but ... both of which can be done by the display controller
<alyssa>
yeah
<marcan>
anyway when I said GPU I really wanted to say "not the iBoot framebuffer"
<alyssa>
but in practice none of the linux video players get this right
<alyssa>
Got it.
<marcan>
(which is the current state of affairs)
<alyssa>
marcan: fwiw, since i'm still learning kernel and KMS on top of DCP, i'm planning to start with a dummy driver using the corellium regs and the iboot framebuffer
<mps>
alyssa: sorry for curiosity but are you panfrost driver author
<marcan>
alyssa: lol
<marcan>
sure
<alyssa>
marcan: At minimum, getting no tearing would be an improvement on the current state of affairs. And that's just disp0-dart and twiddle one register back and forth :p
<alyssa>
mps: yes
<marcan>
alyssa: yes but rather useless in the grand scheme of things since we need to use DCP :p
<alyssa>
mps: and that's a good reminder i should get off IRC and get back to panfrost :p
<alyssa>
marcan: meh, that still implies all the KMS driver skeleton and figuring out how to DART
<marcan>
sure
<alyssa>
once that works i can start wiring in DCP stuff
<mps>
alyssa: ah, very good work, it works fine on my rk3399 samsung chromebook
<marcan>
DART is just the iommu API, right?
<alyssa>
i think so
<marcan>
though the current DART driver won't work for disp0
<marcan>
due to the lock
<alyssa>
ughh
<marcan>
oh sorry
<marcan>
not sure about disp0
<marcan>
definitely not dcp
<alyssa>
(and there next milestone would be running the python dcp client on boot, then booting linux and issueing set_matrix() from linux side)
<j_ey>
yeah sven mentioned the dcp locked dart a few days ago
<brentr123[m]>
I can create a portable python .zip if necessary
Andalu30 has quit [Quit: Konversation terminated!]
<marcan>
alyssa: ah yeah, disp is not locked
<marcan>
however, I expect the driver will probably tear down the iBoot mappings on init... so that should probably be fixed
<marcan>
alyssa: that would be one heck of a hack and not very useful IMO. the problem is you need to carry over state and the linux ASC driver isn't designed to get instantiated on an already initialized device.
Andalu30 has joined #asahi
<alyssa>
grumble. ok.
<alyssa>
fair enough
<alyssa>
this sounds like an excellent reason for me to close irc and work on mali.
<marcan>
and for me to put my bedsheets back on and go to sleep
<mps>
marcan: alyssa: j_ey: thank you all for fast answer to my question
<marcan>
alyssa: you can probably just call printRegs or other dummy stuff without doing the actual high level init sequence on DCP though
<j_ey>
hm there's a "IOMMU_DOMAIN_UNMANAGED"
<marcan>
and the stuff below that is trivial, just setting up the shmem buffer, which you need to do anyway
<j_ey>
that sounds like it might be useful with a 'locked' dart?
<marcan>
and once that works you can move on to working through the init sequence, which you can do incrementally (the very first thing it's going to require you to do is support callbacks)
<sven>
alyssa: disp0 dart isn't locked, only dcp dart
<sven>
so disp0 dart should just work if you can do anything useful with that
<sven>
but i think it only maps the framebuffer
<sven>
j_ey: no
<sven>
j_ey: unmanaged domain just means "translation enabled, but not managed by the iommu-dma layer"
<j_ey>
ah
<sven>
for the locked we'll need to somehow hack the io-pgtable code to not allocate the first level pagetable but just take some pointer instead
<sven>
+dart
<sven>
but first the current driver needs to be accepted anyway :)
<j_ey>
what does 'locked' mean exactly? the ttbr regs are RO?
<sven>
most registers are ro, yes
<sven>
you can still flush the tlb but not much more
<marcan>
so you need to continue to use the L1 pagetable from iBoot
<sven>
and ack errors
<marcan>
but that pagetable is writable
<sven>
pretty much. and force a DMA domain. but that's all easily possible
<marcan>
so it just means the kernel needs to adopt that PT as is
<marcan>
the main thing though is that we also need to support seamlessly adopting all mappings
<marcan>
even for non-locked DARTs like disp0
<sven>
yeah, that's gonna be more tricky
<marcan>
I was thinking we could walk the page table, re-adding those mappings to the kernel's view
<sven>
or, well, doing that in a sane way is going to be tricky
<marcan>
and then, if !locked, just swap the TTBRs
<marcan>
if locked, copy instead
<marcan>
as long as the copy is word-wise, I think it should be atomic and not bork
<sven>
pretty sure it'll work
<marcan>
and then once that's done you swap out the kernel's idea of what the real L1 is and you're done
<sven>
and then the dcp or whatever drivers need to be made away of the right memory locations as well i guess
<pipcet[m]>
mps: I do have stuff working with Corellium's drivers but really the work marcan and sven and alyssa are doing is just amazing, and you should help them in any way you can :-)
<mps>
pipcet[m]: thanks for info. I don't have M1 and only tested corellium few times on my son machine and had a hope that we will not wait too long for 'working' solution
<mps>
pipcet[m]: these days I contemplated about buying yet another one, but above answers 'explained' to me that is not worth waste of money
<mps>
though display is very good and that was main reason I wanted to buy it (I'm about 13-16 hours behind screen daily)
<sven>
alyssa> mps: If you're a linux hat, the M1 isn't a computer, it's an expensive toy for reverse-engineering addicts like marcan and me <-- that's... very very accurate.
<mps>
sven: yes, now I understand
<marcan>
mps: it'll be really good when it's done, but it's not done yet ;)
<pipcet[m]>
yeah, I'm beginning to wish I had gotten two of them so I could use one and hack on the other (also it would have been really handy that time I ended up putting my machine into I-need-DFU mode)
<marcan>
pipcet[m]: you can DFU from linux
<sven>
i really enjoy my macbook air + mini setup :-)
<marcan>
same (+pro but tbh I don't really use it much)
<sven>
the only thing that's annoying is that compiling the kernel on mac os is not much fun
<j_ey>
+imac?
<mps>
yes, my son uses it daily but with alpine linux in qemu, really fast even in qemu
<marcan>
actually the imac is still in the box because I've been procrastinating figuring out where to mount it
* marcan
hides
<j_ey>
even less used than the pro! :P
<pipcet[m]>
marcan: oh, apple never told me that behind the URL they gave me ;-)
<mps>
marcan: I have no doubt that it will be done :)
<marcan>
haven't tried it yet, but M1 support got merged
<pipcet[m]>
oooh, thanks!
Andalu30 has quit [Quit: Konversation terminated!]
<Emantor>
I have started to put together all necessary parts to boot m1 linux into a Yocto BSP (m1n1, u-boot, merged kernel branches). Next up I'll add an initramfs and than it should be good to go.
<Guest3181>
Hopefully all those merged branches will soon just be torvalds/linux.git ;)
hexchain_ has joined #asahi
BlitzWorks has quit [Ping timeout: 480 seconds]
hexchain has quit [Ping timeout: 480 seconds]
linearcannon has quit [Remote host closed the connection]
<j_ey>
Is this still right? "You need at least 70GB for the stub partition, because the macOS install/update process is very inefficient. " I feel like someone said it might be even bigger now
<brentr123[m]>
does macos automatically reserve storage space for updates/
<brentr123[m]>
* does macos automatically reserve storage space for updates?