<Marijn[m]>
vknecht: Great, thanks - I hadn't bothered to search for `ashmem` on gerrit yet - but will try to pick the pathes and boot Android again if I feel interested to try AOSP again
<Marijn[m]>
For now, deathmist1's void-linux setup has been treating me well
<bamse>
konradybcio: sounds plausible
<bamse>
konradybcio: but that means we have some context banks that are dont-touch...and other's are to repurpose?
<konradybcio>
I remember asking the same question 2y ago
<konradybcio>
But i don't remember the answer..
<konradybcio>
There's only one, very painful way to check it though, and the results may very between oems, devices and firmware versions
<konradybcio>
So I think assuming all of them are dont-touch is actually the sane option
<konradybcio>
bamse: ^
<bamse>
konradybcio: do you know if the bootloader leaves us with all the ones we need pre-programmed?
<konradybcio>
I don't think bootloader has anything to do with this, it's probably hyp enforcing it
<bamse>
could it be that skipping the reset happens to cause the driver to just reuse the already existing stream mappings and thereby just happens to never change the stream mappig registers
<bamse>
well, yeah...so s/boot/hyp/
<konradybcio>
But yes, otherwise we can't alter them so that's the only logical option
<bamse>
konradybcio: there's a different between "let's support pre-programmed, read-only stream mapping" and "let's not reset the stream mapping and hold our hopes that things will work"
<bamse>
i think there's a chance we can argue for supporting the first one...but not the "let's hope for the best"
<bamse>
and i think that this would work for qcs405 as well, where the stream mapping registers are write-ignore, to make it more exciting
<konradybcio>
I think the former is the case.. otherwise the downstream hardcodings would make no sense