ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
stikonas_ has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
camus has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 276 seconds]
camus1 is now known as camus
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
UndrWater has joined #linux-rockchip
robmur01 has quit [*.net *.split]
hl has quit [*.net *.split]
robmur01 has joined #linux-rockchip
hl has joined #linux-rockchip
LinuxHackerman has quit [*.net *.split]
hramrach has quit [*.net *.split]
hramrach has joined #linux-rockchip
camus has quit [Remote host closed the connection]
camus has joined #linux-rockchip
anarsoul has joined #linux-rockchip
anarsoul|2 has quit [Ping timeout: 256 seconds]
LinuxHackerman has joined #linux-rockchip
mort5 has joined #linux-rockchip
kevery1 has joined #linux-rockchip
rektide_ has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
rektide has quit [Ping timeout: 272 seconds]
mort has quit [Ping timeout: 272 seconds]
mort5 is now known as mort
camus1 has joined #linux-rockchip
camus has quit [Remote host closed the connection]
camus1 is now known as camus
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 244 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
crabbedhaloablut has quit [*.net *.split]
crabbedhaloablut has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
ldevulder has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
Rathann has joined #linux-rockchip
tinybronca[m] has joined #linux-rockchip
<tinybronca[m]>
Hello all, does anyone here own RK3568 hardware? Please ping my nick or PM me if so!
montjoie has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<montjoie>
I wanted to start on working on rk3588 crypto, but it seems 3588 has no upstream support, right ?
<mriesch_>
tinybronca[m]: surely there are people around with rk3568 hardware, just ask your question :-)
<tinybronca[m]>
Okay I see, well.... I know in some (all?) Rockchip SOCs you need a proprietary blob to get DisplayPort out due do some Cadence Xtensa ISA soft core, but I don't know if this applies to boards with RK3568's that have HDMI ports, does this also use Cadence blobs to get up to 4K res output? As I understand it there is nothing in Panfrost
<tinybronca[m]>
I am not sure if this is explained in datasheets, maybe I should try looking for those...
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
<CounterPillow>
No blobs are needed for HDMI output, also this is not related to panfrost but to rockchip vop2 and the hdmi phy
<robmur01>
the HDMI is from Synopsys, so you can be fairly sure that it doesn't rely on their competitor's firmware ;) Of course there's also an HDCP block as well, which is yet another different kettle of fish, but basically doesn't exist as far as upstream is concerned
<CounterPillow>
As for displayport I haven't looked into it enough yet but it uses a new PHY (naneng)
<CounterPillow>
(I have had a poke at eDP but vop2's habit of silently throwing its toys out of its pram when something isn't to its tastes made this only an evening of fruitless bodgery)
<tinybronca[m]>
What is vop2?
<tinybronca[m]>
oh sorry you just said
kevery1 has joined #linux-rockchip
<tinybronca[m]>
is naneng a company?
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
<tinybronca[m]>
Do I need some HDCP blob to get 4K60 output? If not what exactly is the point of having HDCP?
<phh>
no, hdcp is only to protect some multimedia content from piracy. unless you want to do that (in which case you'll have a lot of another annoying blobs), you don't need hdcp
<tinybronca[m]>
Right that makes no sense to me, I don't know why any end user wants that, it is DRM
<CounterPillow>
VOP2 is how we refer to the new video output hardware rockchip uses, see drivers/gpu/drm/rockchip
<CounterPillow>
Naneng is a company I think, I only know the name from the downstream dp phy driver
<tinybronca[m]>
weird, this is a unique DRM driver? Rockchip wrote this HDL code in their SOC? so is Panfrost not even used? I see reports that there is no 3D with VOP2, that means I am SOL for 3D or even compositing window managers even thought I can have 2D at 4k60?
<robmur01>
Yes, the VOP is a display engine, it does not do 3D rendering. That's what the GPU is for ;)
<tinybronca[m]>
Oh okay so they both used....
<tinybronca[m]>
so every RK3568 has HDMI logic from Synopsys and DP logic from nanengmicro and wether or not one, both, or neither of these are used depends on if the pins are accessed and wired to physical ports on a PCB?
<macc24>
tinybronca[m]: i've got a rk3566 machine
<robmur01>
Yes, the GPU parts render images to display buffers in memory, the display parts scan those buffers out to whichever physical interface(s) are desired, and those generate the appropriate electrical signals at their respective connector(s). That's exactly what your PC graphics card does too, it just hides those distinct functions (plus video, audio, etc.) behind a single massive driver
<tinybronca[m]>
macc24: I have no clue how different this is from a RK3568, but cool
<tinybronca[m]>
robmur01: Speaking of audio, does RK3568 support sending some amount of uncompressed audio channels via it's video ports?
<CounterPillow>
Yes
<CounterPillow>
Hdmi audio is already working
<tinybronca[m]>
or rather these are different parts of the SOC that need to be wired to the physical HDMI or DP ports
<CounterPillow>
i2s0 is connected to HDMI
<tinybronca[m]>
CounterPillow: That is great! Do you have RK3568 hardware to test this? Does it depend on the board wiring it up?
<CounterPillow>
I have RK3566 hardware on which I tested this
<CounterPillow>
It would be supremely weird if any board went out of its way to not wire up the hdmi audio
<CounterPillow>
Aside from HDMI audio, SPDIF is also working
<robmur01>
I'm not sure it would even be possible for a board to do that - isn't the audio just part of the general HDMI data stream?
<tinybronca[m]>
I don't know about HDMI, is the spec even public?
<CounterPillow>
I think it's a few dedicated signal lanes, since hdmi isn't packet based
* tinybronca[m]
wonders if there is such a dongle just to get audio jacks out of an HDMI port
<CounterPillow>
I did buy a little HDMI to 7.1 channel analog decoder box just to test this
<robmur01>
tinybronca[m]: yup, you can pick those up for ~£10 or so - "HDMI audio splitter" is a good search term to start with
<tinybronca[m]>
CounterPillow so you are the only one who said HDMI 4K60 output requires no blobs on RK3568, but you don't own this hardware, so how do you know? You said you do not know about DP
<CounterPillow>
I own RK3566 hardware
<CounterPillow>
The two SoCs are mostly the same
<tinybronca[m]>
hmmmmmmmm
<CounterPillow>
Feel free to look at the source of the vop2 driver yourself, it's in mainline
<tinybronca[m]>
as of 5.19?
<CounterPillow>
Yeah, should be in 5.19
<tinybronca[m]>
robmur01: thanks robmur01, this pics do not seem like dongles, but larger converter boxes I need cables for, but this works I guess
<tinybronca[m]>
CounterPillow: okay you say look at the vop2 driver, but for example on RK3399 the problem is not with vop2, but with the Cadence DisplayPort TX controller, where the analogue here is the HDMI phy from Synopsys and DP phy from nanengmicro (not vop2), or did I misunderstand?
<robmur01>
right, it can't be done passively - the box is an HDMI receiver that decodes the whole HDMI signal to extract the audio packets and output them via its own DAC
<robmur01>
no, RK3399 has Synopsys HDMI and Cadence DP as well (just a different DP phy, I think). They're still unrelated.
<tinybronca[m]>
So while it is great the vop2 DRM drive is mainlined now, there could be problems on the synopsys or nanengmicro side like there is with RK3399 and cadence blobs
<CounterPillow>
The only blobs my board has is TF-A and TPL, and HDMI works just fine
<tinybronca[m]>
Oh okay all the Rk3399 boards I see don't have HDMI so far I just know the USB-C alt mode uses blobs from cadence
rembo10 has joined #linux-rockchip
<CounterPillow>
? Rockpro64 has HDMI output and it needs no blobs
<tinybronca[m]>
robmur01: I was not saying RK3399 has related HDMI and DP phys I am questioning how looking at vop2 driver will help me see if there are blobs or not
<tinybronca[m]>
CounterPillow: oh that is nice I looked at that I forgot the specs, sorry
<robmur01>
it won't. The point is that the display drivers support, and have been tested with, 4K output. The HDMI supports 4K output. Only Cadence DP is problematic, but pretty much nobody is using that because most boards wire it to USB-C alt mode which mainline doesn't support
<tinybronca[m]>
<CounterPillow> "The only blobs my board has is..." <- Interesting you have blobs in TF-A and TPL? I though the rk3399 boards from Pine64 had no blobs for these, you can compile TF-A yourself for example, how do I find which Rockchip SOCs require blobs for TF-A (and TPL)?
<CounterPillow>
I'm talking about rk3566 in that message
<robmur01>
TF-A source for RK356x isn't released yet
<CounterPillow>
We're still waiting for rk3566 firmware sources, yeah
<tinybronca[m]>
oh that's a bit weird, this is code from ARM, correct?
<CounterPillow>
It's modified by the vendor
<tinybronca[m]>
And what is with TPL blobs, this means no mainline U-Boot support for RK3568 (I guess this applied to RK3566 at same time)?
<CounterPillow>
You can get mainline uboot to load rkbin but it's not nice
<tinybronca[m]>
OKay I thought the TF-A code for RK3399 came from ARM (at least it looked like an ARM repo I did not check copyright headers inside invidual source files)
<CounterPillow>
That's because rk3399 tf-a was upstreamed to the arm repo
<tinybronca[m]>
CounterPillow: nice, by whom?
<CounterPillow>
I don't know the entire repository's git history from the top of my head unfortunately, but git does
kevery has quit [Ping timeout: 240 seconds]
<tinybronca[m]>
<CounterPillow> "You can get mainline uboot to..." <- okay I download rkbin to study wtf this is
<tinybronca[m]>
I do not know if this means TPL blob or not
<tinybronca[m]>
I heard there is a way to send video over USB 3.x bus that does not use alt mode, would this depend on support in the RK3399 or in whatever controller chip next to the USB-C ports are on the board (or both??)
<tinybronca[m]>
<robmur01> "the diagram here may help - http..." <- thank you, nice link, but it seems to contrast mainline U-Boot as having full source as opposed to alternate boot path with rkbin blobs, but CounterPillow said mainline U-Boot has rkbin blobs on RK356x?
<robmur01>
yes, it doesn't always work perfectly but you can mix the downstream miniloader with the upstream U-Boot main stage
<tinybronca[m]>
It seems the TF-A code come from ARM..... I guess it is up to them to release source?
<tinybronca[m]>
You cannot boot RK356x without this hmmm?
<robmur01>
if you do that on RK3399, for example, it "works", but booting takes ~3 minutes because in the downstream flow, the main stage initialises the CPU clocks, but in the upstream flow it's the SPL, so downstream miniloader + upstream main stage means you end up with nobody doing it
<robmur01>
I don't think RK356x has the MCU cores (or it has a RISC-V one rather than a Cortex-M0, I forget the details)
<robmur01>
Again, that code is not from Arm, any more than the kernel drivers are from Linus Torvalds
<tinybronca[m]>
okay I got thrown off because every file says Copyright (c) ARM Limited and Contributors. All rights reserved.
<robmur01>
and Rockchip are one of the contributors
<tinybronca[m]>
Okay but what are rk3399m0pmu_bin and rk3399m0_bin these are firmware blobs for power management?
<robmur01>
they're not blobs, the source is right there too, it just has to be built with a different compiler because it's 32-bit
<tinybronca[m]>
<robmur01> "the diagram here may help - http..." <- robmur01: so in the diagram, there is no path with JUST U-Boot and ATF, you always have to have rkbin elements somewhere?
<robmur01>
Only if you want the full downstream Android experience. My RK3399 is just using a BL31 I built from mainline TF-A, with no TEE
<CounterPillow>
Yeah I don't use rkbin on rk3399 either. I only use rkbin on rk356x because there's no other choice
<robmur01>
TBH I don't even know what services the downstream trusted payloads provide, I only care about BL31 for PSCI :)
<CounterPillow>
Anyway, I wish we had sources for rk356x tf-a and tpl
<CounterPillow>
robmur01: correct on risc-v btw, but we have not yet figured out how to poke at that MCU
<tinybronca[m]>
<robmur01> "Only if you want the full..." <- "full android experience" #donotwant ..... do you also have BL32? I see sources for that as well and it is in the diagram, but I have no blue what TEE does
<robmur01>
FWIW, I'd have to guess at mcu_boot_addr in GRF_SOC_CON4 and aresetn_mcu...
<robmur01>
tinybronca[m]: no, BL32 is only relevant for secure payloads, which as I say I have no interest in. If you're curious, https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html is a reasonably accessible overview (note that in this case we're using the alternative flow, with U-Boot SPL serving as "BL2")