buzzmarshall has quit [Remote host closed the connection]
icecream95 has joined #panfrost
_whitelogger has joined #panfrost
davidlt has joined #panfrost
<endrift>
urgh...so how's Lima on the Pinetab?
<endrift>
I'm kinda eyeing a pinetab for some home automation stuff because everything else is $$$ or old-ass Android tablets that don't even have current OS - 2
<anarsoul>
endrift: wrong channel? :)
<anarsoul>
endrift: it works if you're OK with GLES2
<endrift>
I mean, what else would it support? :P
<endrift>
anarsoul: if there's a lima channel I'm not in it
<endrift>
(and also if there's a lima channel I didn't know it existed oops)
<anarsoul>
#lima
nlhowell has quit [Ping timeout: 240 seconds]
<endrift>
thanks, I'
<endrift>
ll join if I end up getting a pinetab
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
<narmstrong>
alyssa: playablish then
awordnot has quit [Ping timeout: 258 seconds]
<HdkR>
daniels: Do you know of anything going on with AArch64 ILP32 mode these days?
davidlt has quit [Ping timeout: 256 seconds]
<daniels>
HdkR: haven't heard anything of it myself
<HdkR>
Dang
nlhowell has joined #panfrost
awordnot has joined #panfrost
<daniels>
you that hard up for space?
<HdkR>
I'm hard up for running 32bit applications in an emulated environment. Pointers in syscalls and thunked library structures becomes a nightmare
<HdkR>
and no way can I run as an AArch32 host at this point
<daniels>
heh, ouch
<HdkR>
32bit support is an interesting problem
robmur01 has joined #panfrost
<robmur01>
HdkR: ILP32 is pretty much EOL at this point
<robmur01>
we stopped maintaining it at 5.1; not sure if the Marvell guy has carried on
<HdkR>
hm
<robmur01>
as far as I'm aware the supposed demand for upstreaming never appeared - I guess the networking folks did manage to update their legacy software stacks (that was the only big argument)
<HdkR>
How likely am I to break the world if I make a userspace toggle for swapping the MSR bit in a process at runtime? :P
brads has quit [Read error: Connection reset by peer]
brads has joined #panfrost
<robmur01>
MSR bit?
<HdkR>
Doesn't TCR_EL3 have a virtual memory size thing that is supposed to be used for ILP32? Masks addresses by 32bits in that mode?
<HdkR>
Granted that's a silly bit. More annoying thing is wrapping any syscall that uses 32bit pointers. Would be nice if I could do the x86 x32 thing and let the kernel handle that for me :P
<robmur01>
oh, "MSR" in x86-speak, not the instruction ;)
<HdkR>
lol, right
<robmur01>
setting T0SZ essentially tells the hardware page table walker how many levels of table to expect, with the bonus of having it generate "sanity check" style faults if fed an out-of-range address
<robmur01>
influencing the kernel's address placement to begin with is a whole other matter...
<HdkR>
:D
<HdkR>
I mostly just wanted to abuse the ILP32 syscall interface from an AArch64 process
<HdkR>
But if it isn't there at all then it kind of loses meaning
<robmur01>
does using the linux32 personality do enough to be useful? (I'm not too familiar with exactly which bits of the compat layer do what)
<robmur01>
hmm, according to `linux32 cat /proc/self/maps`, probably not :(
raster has joined #panfrost
<robmur01>
Also, aren't 32-bit pointers also inherently 64-bit pointers anyway (X-reg/W-reg duality)? I though the big deal with ILP32 ABIs is that passing *64-bit* arguments has to be different :/
* robmur01
adds ILP32 Panfrost to big-endian in the "rich source of troll bug reports" pile... :D
<HdkR>
yea, it's just the structs passing across the syscall boundary that become a pain :P
<robmur01>
...says the guy who's already thunking between stack-based and register-based calling conventions
<HdkR>
I mean, If the linux kernel can take some of the burden off of me, I'll query as much as I can for help
<robmur01>
heh, yeah, conceptually it would be nice to have every option; unfortunately in reality ILP32 would apparently be a significant pain to maintain in the kernel too
warpme_ has joined #panfrost
<HdkR>
Well, good to know it is dead at least
<HdkR>
So now I need to figure out how much pain it'll be to call the 32bit compat syscalls from an aarch64 process :P
<raster>
o/
stikonas has joined #panfrost
<robmur01>
definitely more of a pain when CONFIG_COMPAT=n :P
<robmur01>
expect Arch users to hate you
* raster
begins the hate
<raster>
:)
<HdkR>
If that is set to n then they don't get 32bit x86 emulation then :P
<raster>
i have no idea why i'm hating... but i'm following orders from robmur01 :)
* robmur01
just accepts that building a 32-bit Arch kernel package takes well over 4 hours since I always end up rebuilding the host kernel first to be able to chroot into the 32-bit build environment...
<HdkR>
well, don't need a 32bit kernel, just need 32bit compat :P
<raster>
robmur01: on arm or x86?
gcl has quit [Ping timeout: 240 seconds]
<raster>
my arch arm boxen are al lon 32bit alarm so .. never needed multiarch :)
<robmur01>
it's a choice between compat-building on 2/1.5GHz RK3399 with fan and NVMe vs. natively on the 1.6GHz RK3288 with crap cooling and cheap dodgy eMMC ;)
<raster>
running arch on them? my rp64 i sstill on debian... got it there. never have tried changing once it worked...
<raster>
but the 3399 should be.... better.
<raster>
the pi4 and rk3399 vie for "Fastest build board" for me. my pi4 has rootfs on usb3 sata and rp64 is on emmc.
davidlt has joined #panfrost
<robmur01>
yup, used FriendlyCore and Armbian images to bring up the NanoPC-T4 in the first week or so I had it, then been Arch and mainline kernels ever since
<robmur01>
(and I stopped building custom kernels with extra patches well over a year ago)
<raster>
robmur01: you bad kwrnel dev! not building custom kernels!
<raster>
:)
maciejjo has quit [Remote host closed the connection]
gcl has joined #panfrost
<robmur01>
hey, that's upstream work at its best - get stuff merged, never have to think about it again :D
<raster>
hahahaha
<raster>
speaking of not being merged...
<raster>
back to these dts changes... arrrrgh... the moment i use them everything falls apart and i have no way to know if their content is correct...
<icecream95>
robmur01: Speaking of big endian, I was testing using it for the tiling code in Panfrost but it wasn't any faster than manually doing vrev
<robmur01>
icecream95: I doubt it would be ;)
<robmur01>
the fact that we have to emulate SETEND at all in the arm64 kernel because it happened to be the fastest way to do strcmp on ARM11 is an anachronistic sore point
<HdkR>
I thought about using setend once
<HdkR>
Then I decided that ARMv7 not supporting endian swapping on faults would kill me
<urjaman>
re:32-bit, it's always fun to hear that i have an irrelevant laptop: 'Or, as Torvalds put it: "It's not that 32-bit is irrelevant, it's that 32-bit with large amounts of memory is irrelevant". '
<HdkR>
hah
<robmur01>
urjaman: maybe just remind him that "Linux is obsolete" :P
<HdkR>
Soon to be replaced by Google Zircon
* HdkR
runs
<raster>
HdkR: oh come on, you know linux is obsolete because it'll be replaced with freebsd! :)
<robmur01>
we're only using it while we wait for HURD to be ready, aren't we?
<raster>
oh yes. do not forget the hurd!
<raster>
actually is it just me or has fuchsia essentially gone into quiet mode?
<raster>
like a year ago or so i heard about it all the time.. now... nada
nlhowell has quit [Ping timeout: 272 seconds]
icecream95 has quit [Quit: leaving]
italove has joined #panfrost
<tomeu>
raster: I think they are waiting for Arm to give them a Fuchsia-enabled Mali DDK
* robmur01
genuinely LOLs
nlhowell has joined #panfrost
<robmur01>
is there a Fuchsia port of Angry Birds yet?
<nlhowell>
the real /buffer 14
<nlhowell>
err, was meant to be "the real measure of a mature OS"