<konradybcio>
i think 8150 is the special snowflake that needs gdsc patches first
<konradybcio>
and power stuff in general
<konradybcio>
bamse should know
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
lumag_ has joined #linux-msm
jhovold has joined #linux-msm
<aka_[m]>
if device is secure boot off can it in theory use normal arm-smmu-v2 driver?
<aka_[m]>
without any hacks around just define node
<Mis012[m]>
yes
<Mis012[m]>
as long as you either give up what hyp does with it or find a saner way to accomplish the same level of security
<Mis012[m]>
actually iirc minecrell[m] said Linux doesn't know how to provision the smmus in a way that will make the other cores happy, so you would need to figure *that* out or hardcode it
<minecrell>
cores = remoteprocs?
<Mis012[m]>
well... calling them remoteprocs would make it sound like the hw is made such that Linux manages them, while the hw doesn't really care which cores manage which other cores
<minecrell>
right, but I was thinking of the ARM application cores if you just say "cores"
lumag_ has quit [Ping timeout: 480 seconds]
<minecrell>
The remoteproc subsystem actually seems to have a feature to load IOMMU mappings ("resource table") from the ELF images or something
<minecrell>
but I don't think this is used or works on qcom
<minecrell>
I'm also not sure if it's a good or bad idea to bundle those together with the (potentially malicious) firmware
<minecrell>
aka_[m]: FWIW this is not just "in theory", arm-smmu-v2 works pretty well on 8916 without any hacks with the stupid TZ out of the way
<minecrell>
The "funny" part is that you have even the most basic stuff such as RPM causing IOMMU faults once Linux probes the smmu
anholt__ is now known as anholt
<aka_[m]>
<minecrell> "aka_: FWIW this is not just "..." <- but first you need to yoink tz
<aka_[m]>
what about devices where tz is there but it has secure boot off
<minecrell>
aka_[m]: If SB is off then you can probably replace (or at least modify) whatever is in control of the SMMUs, e.g. tz or hyp
<aka_[m]>
but how do you do that without knowing what org software was doing?
<aka_[m]>
Dump it get into ghidra and guess when smmu are getting programmed and NOP it?
<minecrell>
aka_[m]: Fundamentally both tz (EL3) and hyp (EL2) are standardized by the ARM architecture, so with a bit of luck you can just get rid of the original ones and put something minimal there (e.g. TF-A/ATF on EL3 or Linux/KVM on EL2)
<minecrell>
The problematic part is that it also contains some hardware initialization which may or may not be strictly required
<minecrell>
That's the part where you're kind of screwed if you have no documentation at all
jhovold has quit [Quit: WeeChat 3.4.1]
<Mis012[m]>
aka_: which SoC?
<aka_[m]>
660
<Mis012[m]>
then it's definitely hyp
<Mis012[m]>
fwiw you can just disable smmus in devcfg iirc
<Mis012[m]>
though binary patching that might not be all that much fun
<aka_[m]>
any idea which dongle to use for uart on msm8953 device
<Mis012[m]>
*disable hyp setup of smmus
<aka_[m]>
3.3V or what
<Mis012[m]>
1v8
<Mis012[m]>
qcom IO voltage is always 1v8
<Mis012[m]>
unless they changed it very recentl
<Mis012[m]>
y
<Mis012[m]>
but you can use a 3v3 RX and not connect TX
<Mis012[m]>
raspberry pi is known to register 1v8 signal on RX
<aka_[m]>
and how to find which pin is which?
<aka_[m]>
i mean schematic does not clearly show which pin is RX
<aka_[m]>
or TX
<Mis012[m]>
pinmux tables
<aka_[m]>
it didnt even show where they are placed but i have some assumptions
<Mis012[m]>
I'd assume?
<aka_[m]>
uh
<aka_[m]>
i mean i have two pins
<aka_[m]>
can we use multimeter to somehow notice if it spikes?
<Mis012[m]>
you can probably just try poking with a wire connected to the rpi's RX pin
<aka_[m]>
and for not rpi owners?
<aka_[m]>
some usb uart dongle?
<Mis012[m]>
for example
<Mis012[m]>
fwiw stm32 bluepill is probably cheaper than a dongle :P
<Mis012[m]>
but you need either 1v8 or at least 3v3
<Mis012[m]>
5v RX probably won't see 1v8 as logic high
<Mis012[m]>
aka_: or if you have a samsung phone, you can use it's uart muxed over microUSB
<aka_[m]>
its still about that moto of this guy
<aka_[m]>
which is unable to output pstore or boot lk2nd image
<Mis012[m]>
well... guess he won't have microUSB breakout handy
<Mis012[m]>
most people don't
<Mis012[m]>
what a shame
<Mis012[m]>
iirc xiaomi has uart muxed over headphone jack?
<Mis012[m]>
at least some models
<Mis012[m]>
in some cases with stuff missing on PCB
<konradybcio>
aka_: arduino or rpi
<konradybcio>
If you connect phone tx only, it will work fine
<konradybcio>
If you send 3v3 to phone's rx that wants 1v8.. goodbye sdm
<konradybcio>
(not necessarily instant sepuku but eeeh it's better not to)
<aka_[m]>
something like that was before, now it happens but not that often.
<aka_[m]>
Same behaviour anyway.
<Mis012[m]>
blue is underflow iirc
<Mis012[m]>
it's some code in Linux doing that, you can look it up
<aka_[m]>
Well now it happens at the end of animations like it tries to push too much data at once?
<Mis012[m]>
never saw it happen during normal use I don't think
<Mis012[m]>
aka_: but since you mentioned icc, I guess the QoS being set such that there's not enough bandwidth somewhere in the display pipe would be an issue
<Mis012[m]>
and underflow is precisely what that would result in I guess