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
klaus has quit [Read error: Connection reset by peer]
klaus has joined #asahi
HeN has joined #asahi
thestr4ng3r has quit [Read error: Connection reset by peer]
thestr4ng3r has joined #asahi
phiologe has quit [Ping timeout: 250 seconds]
phiologe has joined #asahi
marvin24 has quit [Ping timeout: 245 seconds]
marvin24 has joined #asahi
VinDuv has joined #asahi
ephe_meral1 has joined #asahi
VinDuv has quit [Quit: Leaving.]
zkrx has quit [Ping timeout: 240 seconds]
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
zkrx has joined #asahi
vimal has quit [Ping timeout: 260 seconds]
vimal has joined #asahi
jaalsa has quit [Read error: Connection reset by peer]
suskun has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 240 seconds]
<sven>
marcan: sven: this reminds me, on paper we prooobably need to unmap some high RAM at some point, need to figure out what the sane way of determining what the hole is <-- it's... weird. there's a carveout node in the ADT but it looks like not all ranges are protected in there
<sven>
there's e.g. | <0x00000009 0xffffc000 0x00000000 0x00004000> (/chosen) in there from which i can read just fine
riker77_ has joined #asahi
<sven>
but there's also | <0x00000009 0xe6e84000 0x00000000 0x19000000> (/chosen) from which i get data aborts
riker77 has quit [Ping timeout: 265 seconds]
riker77_ is now known as riker77
<sven>
and then that node also contains some MMIO ranges, e.g. | <0x00000002 0x4ac00000 0x00000000 0x00250000> (/arm-io/aop)
<sven>
and unfortunately i can't find the protected regions (that ones that actually fault) anywhere else in the ADT.
<marcan>
sven: the usable RAM range is in bootargs
<marcan>
not in the ADT
<marcan>
that's what we use to pass to linux
<marcan>
so we should do the same
<marcan>
but it means we need the pagetables to go down to page level, probably
<marcan>
since the ends are probably not guaranteed to be aligned to a larger block
<sven>
huh, so the boot args also contain the reserve regions for e.g. the SEP stuff?
<sven>
oh.. just the mem_size
<marcan>
yeah
VinDuv has joined #asahi
<sven>
so interestingly we *can* access stuff beyond that it seems. there are just some regions in there that give me data aborts
<marcan>
yes, because only stuff like the SEP carveout is actually blocked
<marcan>
the problem is I don't know how to enumerate *only* those
<sven>
pretty sure they are somehow specified in /device-tree/chosen/carveout-memory-map
<sven>
three out of the entries in there result in data aborts, the rest can at least be read though
<sven>
unfortunately that node also contains some random regions at the beginning of ram
<marcan>
IIRC that thing contains all of RAM or something like that too
<sven>
hrm... true.. all those individual ranges might just summarize to all of ram
<sven>
just found it by accident while looking at the DT, heh
choozy has joined #asahi
kubes has joined #asahi
ephe_meral1 has quit [Ping timeout: 252 seconds]
raster has quit [Quit: Gettin' stinky!]
jaalsa has quit [Quit: jaalsa]
kubes has quit [Quit: Leaving]
kubes has joined #asahi
kubes has quit [Remote host closed the connection]