System_Error has quit [Remote host closed the connection]
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
jmabsd has joined #linux-rockchip
jmabsd has left #linux-rockchip [#linux-rockchip]
naoki has quit [Quit: naoki]
<urja>
For some reason on my asus c201 (veyron speedy), in 6.15 (-rc7) the graphics stuff (rockchip drm, rkvdec) wants CONFIG_ROCKCHIP_PM_DOMAINS enabled _or_ it will trip a deferred probe timeout after 15-ish seconds (and the graphics does come up, just very late)
<urja>
But the fun part is CONFIG_ROCKCHIP_PM_DOMAINS needs CONFIG_ARM_PSCI (and as far as i know, i dont have such firmware on the C201...)
System_Error has joined #linux-rockchip
jakllsch has quit [Ping timeout: 244 seconds]
<CounterPillow>
You don't have a TF-A? curious
<urja>
As far as I know, no? Just u-boot SPL and u-boot itself (from 2019)
<Daanct12>
psci isn't a requirement until armv8
<Daanct12>
rk3288 is armv7, but no idea if it is implemented there
<urja>
And as far as i know, coreboot + deptcharge (the default firmware) also wouldnt have that
<urja>
but yeah enabling CONFIG_ARM_PSCI did get the graphics to come up right away (and it seems harmless to have it enabled), it was just a very confusing dependency
<diederik>
I seem to recall a (recent) commit/patch where the check for CONFIG_ROCKCHIP_PM_DOMAINS was removed and the assumption was made it was just there/enabled
xha has quit [Ping timeout: 244 seconds]
<urja>
Yeah i had never enabled it because it was literally not visible in menuconfig until you enable PSCI (which i hadnt enabled because no such fw)
<CounterPillow>
Your U-Boot most likely includes a BL31 like TF-A, which means I'd wager you do have psci since even TF-A has it for the rk3288
<robmur01>
but chances are Linux still wouldn't use it since it's not in any of the standard RK3288 DTs :/
<robmur01>
Basically the "depends on HAVE_ARM_SMCCC_DISCOVERY" fix was suboptimal; the offending SMCCC code should really be #ifdefed or stubbed out to allow building without it
<mmind00>
CounterPillow: no ... the rk3288 (and stuff before) still does its smp without TF-A
<CounterPillow>
alright
<mmind00>
CounterPillow: I did build TF-A support for rk3288 for the fun of it ... so it is _usable_ but not the default
<mmind00>
the CONFIG_ARM_PSCI thing was needed to be _able to test_ for the existence of an smcc "backend"
<mmind00>
but yeah, as robmur01 said, wrapping that in an #ifdef might be the nicer thing
<robmur01>
looking closer, stubbing out arm_smccc_1_1_get_conduit() for !CONFIG_HAVE_ARM_SMCCC, as the arm_smccc_smc() call itself already was, is probably even nicer
jakllsch has joined #linux-rockchip
kevery has quit [Quit: kevery]
<Kwiboo>
CounterPillow: Great!, I will try to send out a rk3528 usb2.0 series followed by DT for rock-2a/2f, sige1 and nanopi zero2 later. I included a very simple rng node in -u-boot.dtsi, will be nice to drop/replace that :-)
wootehfoot has quit [Read error: Connection reset by peer]
<Dex2x>
Hi all, I just got an orange pi 5 ultra, seems there is no orange pi OS for this? I installed debian, but seems the kernel is still a bit behind. Is there any worth in trying the armbian server , which seems to be ubuntu ?
<Dex2x>
Also is rockchip now just dropping out of the SBC game?
<psydroid>
I think Rockchip is working on a tentative RK3688 with ARMv9 cores
<Dex2x>
It's been a while since they released the RK3588 and nothing after that
<psydroid>
that one was already delayed by about 2 years
<psydroid>
but we have Allwinner getting back into the game now
<Dex2x>
There was a rumor that rockchip backed off, due to it's SBC's being used for warfare, thus focusing on AI
<phh>
rk3399 was released in 2016, rk3588 in 2021 (no rk34xx). if we extrapolate, rk3688 is in 2026, so still on track
<CounterPillow>
they're not going to release top-of-their-lineup SoCs every other year. Last year they released RK3576/RK3562/RK3528 as lower spec parts.
<linkmauve>
Hi, I’m using V4L2 to decode H.264 pictures on a rk3588, I got my very first decoded keyframe today, but when I misconfigure the decoder I get a full green NV12 image (= zero-filled) rather than an error, is it something I’m doing badly or is it the way the driver works?
<linkmauve>
I’d much prefer to get an error in the case I’m doing something wrong.
<Dex2x>
diederik, I am currently on the 6.1.43-rockchip-rk3588, from debian
<Dex2x>
But let me then go to experimental
<CounterPillow>
that doesn't sound like a kernel debian ships.
<CounterPillow>
that sounds like a downstream kernel
<Dex2x>
I downloaded the debian image from orangepi, but then switched to the debian mirrors, and testing, and updated
<Dex2x>
I don't see a linux-vendor kernel with rk35xx
<Dex2x>
package is "linux-image-current-rockchip-rk3588"
<diederik>
Yeah, that doesn't have much to do with Debian as I see/meant it
<diederik>
FTR: Right now, Experimental has a 6.14 kernel and that won't work as the OPi 5 ultra DeviceTree only landed in the 6.15-rc1 upstream kernel. But the *next* upload to Debian Experimental should be a 6.15-rcX kernel (or maybe they wait till the release)
<Dex2x>
oh okay
<CounterPillow>
if you download a "Debian image" from Orange Pi or whoever then it will most likely be using the rockchip vendor kernel and a bunch of other stuff that Debian does not ship and is not responsible for maintaining.
<Dex2x>
Oh okay, so better to go to debian directly? Well once the next upload to experimental happens?
<CounterPillow>
Debian does not have ready-made images for your board, I'd imagine.
<diederik>
correct. You could try switching to the Trixie (or Sid) sources and upgrade 'the rest' and see if that (fatally) breaks things. Then when there is a 6.15 kernel in Experimental you could try if that works
<diederik>
So having a proper backup of your current system seems like a good first step before you'd try that
<Dex2x>
I am on testing, but apt hasn't given me a different kernel so things are still running
<diederik>
apt won't upgrade your 6.1.43-rockchip-rk3588 kernel ... ever. You'd need to install the linux-image-arm64 (meta)package or the specific linux-image-6.15*-arm64 package