<lumag_>
Those two should apply on top of linux-next
<DavidHeidelberg[m]>
number three also failing [3]
<lumag_>
[3] is also replaced by the mentioned thread.
<Mis012[m]>
minecrell[m]: smmus and remoteprocs almost fall under kvm don't they?
<Mis012[m]>
guess just because it's in-tree doesn't mean securely shoving random parts of driver code in there would be that easy :(
<minecrell>
I don't understand what you are proposing
<DavidHeidelberg[m]>
lumag_: for [2] you can put my R-b
<Mis012[m]>
minecrell: that part of Linux codebase runs at EL2 when Linux is launched at EL2 and VHE is not used
<DavidHeidelberg[m]>
I'll try to build new kernel and test on N7 2013; but I just hope next didn't broke anything else for me :D
<lumag_>
DavidHeidelberg[m], thanks a lot for your time
<DavidHeidelberg[m]>
np, I appreciate that you put time into improving these early qcoms
dylanusdt[m] has quit [autokilled: Please do not spam on IRC. Email support@oftc.net with questions. (2022-07-04 17:54:24)]
<minecrell>
Mis012[m]: this is the status quo but what do you want to do with smmus and remoteprocs?
<Mis012[m]>
minecrell: it would be very convenient if there was a way to have stuff that qcom's hypervisor normally does done in Linux with proper driver model, but somehow have it hidden away inside EL2 so that you can have small (auditable) amount of code that has the permissions to touch those registers
<minecrell>
Well the EL2 stuff in Linux is probably not designed to be isolated from Linux (just like it wouldn't be isolated at all with VHE)
<minecrell>
so imo you might as well get rid of hyp and just do everything in Linux
<minecrell>
or block hyp like qcom does
<minecrell>
or just put it in EL3 which is more privileged anyway
<Mis012[m]>
but I really don't like the idea of not having the remoteproc drivers in Linux with proper driver model :/
<arnd_>
steev: I merged the version that has the type change, I assume that's v2 but I don't see a version number in the subject in patchwork
<minecrell>
Mis012[m]: What exactly do you mean with "remoteproc drivers [...] with proper driver model"?
<Mis012[m]>
for example SSC bus driver bringing up the bus and remoterproc driver directly loading code on hexagon and putting it out of reset
<minecrell>
If you want to give Linux ownership over everything then just give up the hyp and load Linux normally in EL2?
<Mis012[m]>
while currently both of these are hidden in qcom's hyp, and are done as an opaque init seq
<Mis012[m]>
minecrell: well, the thing is, it would be nice if the part of Linux that has ownership of this was in a different EL than the vast not easily auditable rest of the kernel
<calebccff>
Mis012[m]: maybe get us EL2 access on 835+ before worrying about such implementation details :P
<minecrell>
Mis012[m]: sounds like you want a more minimal hypervisor
<minecrell>
I'm not sure KVM is really designed the way you want it
<Mis012[m]>
minecrell: well, unless we can figure out a way to have each CPU core protect itself autonomously with XPUs...
<Mis012[m]>
minecrell: which would surely be preferable to having a central power that you then need to keep minimal
<Mis012[m]>
but with qcom giving up on XPUs...
<steev>
calebccff: that would be nice... i wish i had it on my flex5g or c630
<steev>
(and whenever lenovo fixes their mistake of sending me the t14 instead of the x13s) and on my x13s
<calebccff>
steev: that would be sweet :>
<calebccff>
oh snap
* calebccff
really wants to play about with an x13s
<Mis012[m]>
steev: well, there are blank SoCs on aliexpress, but PoP is a pain
<steev>
Mis012[m]: i left device development myself a while back
<steev>
poor thing, we're working on a new image too :( (well, for certain definitions of we, that don't actually include me)
<calebccff>
it's ok there's a comment pointing to the patch series at least
<Mis012[m]>
steev: well, since I assume your flex5g and c630 come with crippled fuses, you're not the owner and so you're not supposed to be able to load your own code in EL2 if the actual owner doesn't sign it for you
<steev>
Mis012[m]: hm, how would i be able to poke at those to find out?
<Mis012[m]>
it's practically a given
<steev>
the c630 won't do wsl2 in windows, but the flex5g does
<Mis012[m]>
after aleph security, qcom makes sure nobody sends out SB off devices by accident
<steev>
however, another 850 "laptop" i have here, the galaxybook2 does do wsl2
<Mis012[m]>
only SB off devices with recent SoCs are probably ones by companies which for whatever reason agree that shiping a fused SoC is scummy
<Mis012[m]>
steev: so you would need to get blank SoCs off of the back of some truck (aliexpress seems to have them) and 🔪 the sec partition at minimum so it doesn't refuse itself
<calebccff>
steev: try loading firmware for some remoteproc from a different vendor and see if it at least tries to boot or immediately rejects it due to the mismatching signature
<steev>
calebccff: hm, so maybe grab the firmwares off the galaxybook2 and try them?
<calebccff>
steev: yeah worth a shot
<Mis012[m]>
steev: you can also send you sec partition and I'll see if I can try to decode it with TZ in ghidra
<Mis012[m]>
assuming the format is the same between SoCs
<Mis012[m]>
*your
<calebccff>
if you can replace that firmware you can likely also replace hyp, although monkeypatching the signed binary is a different story
<Mis012[m]>
you can just boot Linux at EL2, probably
<steev>
Mis012[m]: i'm assuming that's the "SECDATA" one ?
<steev>
Mis012[m]: if you want/need any of the others from the list, just let me know, more than willing. i haven't had time to play with ghidra as much as i would like
<Mis012[m]>
steev: mhm, it looks like there's a test certificate in there...
<Mis012[m]>
maybe double signed with qcom's private keys for TZ and "vendor's key"?
<Mis012[m]>
seems too good to be true
<Mis012[m]>
can you send XBL and HYP?
<Mis012[m]>
yup, found the magic `ca 51 72 3b 29 6f 12 2a`
<Mis012[m]>
it definitely doesn't look like a noop let me tell you that...
<DavidHeidelberg[m]>
lumag_: recent `-next` seems to be kinda broken.
<DavidHeidelberg[m]>
at least one board w/ apq8064/msm8960 or something in kernel ci would be nice
<calebccff>
DavidHeidelberg[m]: I have two dead-ish motorola photon Qs (msm8960), display just plain died on one and the other doesn't seem to turn on, would love to get them somewhat working or at least find a use for them
<calebccff>
it's the last generation slide-out keyboard phone with a HDMI port
<DavidHeidelberg[m]>
calebccff: well, depends if you can provide 24/7 connection and some managing machine
<aka_[m]>
calebccff: so they work but displays went ded?
<aka_[m]>
Any chance these are you mentioned during lk2nd porting?
<calebccff>
aka_[m]: display died on one of them some time after i got mainline booting, other one worked when i got it and now just doesn't do anything, never got around to flashing anything custom
<calebccff>
yeahhh, the dead display one i tried lk2nd on, could be the cause
<calebccff>
DavidHeidelberg[m]: aha, can't right now but gonna be working on getting some kind of lab setup by the time i move into my new house
<DavidHeidelberg[m]>
calebccff: I'll have small lab soon too (not in my home thou, since I cannot guarantee 24/7 internet)
<DavidHeidelberg[m]>
currently I count with 2x Librem 5 devkits and few ati r500 for Mesa3D, planing to keep it small to not to have to spend too much time on it
<minecrell>
calebccff: to be fair your lk2nd display changes seemed a bit too hacky
<calebccff>
minecrell: yeahhh i was going a bit fast and dangerous, hopefully i can combine these two into something that works and not take the same risks again, as i doubt i'd be able to get hold of another device
<minecrell>
calebccff: the new WIP lk2nd version supports msm8960 actually, with proper display code similar to the one for newer SoCs :>
<calebccff>
minecrell: oh awesome! any devices have it validated?
<minecrell>
calebccff: well I tested it on a Samsung Galaxy S4 Mini (msm8930), but the msm8960 target in LK covers all of [msm8960, apq8064, msm8930, ...]
<calebccff>
minecrell: ah i see, nice
<DavidHeidelberg[m]>
lumag_: do you need something specific to test: `Linux version 5.19.0-rc4-next-20220704-postmarketos-qcom-apq8064 (tuxmake@tuxmak
<steev>
Mis012[m]: sorry, neighbors came home with their new puppy and puppies trump computers - they're up now, same url
<steev>
i wasn't sure which xbl you wanted, so i grabbed both that are labeled hyp
<steev>
er, xbl
<lumag_>
DavidHeidelberg[m], just that the devices works as expected. A series of Reviewed-by/Tested-by would be perfect.
<steev>
and the ones labeled xbl_config for good measure
<DavidHeidelberg[m]>
lumag_: if I send you `Tested-by: David Heidelberg <david@ixit.cz>` here, is it enough? For DT bindings R-b
<lumag_>
DavidHeidelberg[m], preferably to the ML, please.
<lumag_>
No hurry, if that's the question.
<steev>
Mis012[m]: also... if what you're doing in ghidra is documented anywhere... i'd love a link, i need to practice with it
<steev>
Mis012[m]: also, for good measure - i shot the c630's partitions up there too (prefaced with c630) - the ones you've got that have no preface are from the flex 5g
<DavidHeidelberg[m]>
lumag_: I'm doing it, it's just Thunderbird is somehow stupid not including In-Reply-to...
<lumag_>
Ugh. Strange.
<lumag_>
I'm using thunderbird from Debian here.
<DavidHeidelberg[m]>
lumag_: I meant from the link on the lore.kernel.org pages: "If your mail client supports setting the In-Reply-To header
<DavidHeidelberg[m]>
via mailto: links, try the mailto: link"
<lumag_>
Ah.
<lumag_>
I'd usually download the mbox and then cat it into one of Thunderbird's local folders.