<CountPumpkin>
vilmursss: of what SoC? Generally if you want to run up to date code you should run mainline
<vilmursss>
RK3399
<vilmursss>
We encountered some issues when we tried to use this driver these https://github.com/rockchip-linux/kernel/tree/develop-5.10/drivers/video/rockchip/mpp in 6.x kernel. So initially just decided to postpone kernel upgrade but if it is known that such support is not coming any time soon then we might consider patching it by ourselves.
<vilmursss>
However, as we know, home-made solutions / changes usually ain't the best and most tested solution
<vilmursss>
Interesting phh Thank you for providing this road map, I did not find any info anywhere :)
<qschulz>
vilmursss: is there really anything preventing you from using mainline on RK3399?
psydroid has joined #linux-rockchip
<qschulz>
vilmursss: otherwise, Rockchip 6.1 kernel is available for a year almost already, not sure if they test the old SoCs extensively anymore, so YMMV
<qschulz>
i don't know where you could get the official sources though
<vilmursss>
qschulz No, basically everything works just fine with mainline, there was just problems with this mpp driver that it gets stuck or so when using it together with gstreamer
<qschulz>
vilmursss: mainline isn't using MPP so are you rather saying the VPU?
<qschulz>
this is the linux-6.1-stan-rkr3.2 tag from Rockchip kernel sources, unchanged from us
<vilmursss>
Yes mainline is not having MPP, we just included it to our kernel which currently is 5.10 version. But now when we tried to upgrade it using this mpp driver, we encountered above mentioned issues.
<qschulz>
what are you trynig to decode/encode on the VPU?
<qschulz>
maybe it just works now on mainline using gstreamer?
<qschulz>
without porting MPP
<CountPumpkin>
Only decode works atm on mainline, no encode afaik unless something big happened while I was gone
<vilmursss>
That might be possible, might just take quite a huge effort to test that out. We are more or less in limited resources and mostly in "maintaining" mode, however, there are some problems related to our media streams, sometimes encountering mysterious crashes that are pretty much impossible to reproduce. We saw that 6.1 linux kernel included in it's
<vilmursss>
mainline new rockchip ISP drivers. We are currently using manufacturer ISP drivers that are ported to our linux as well. So we are basically just hoping to get +6.x just to test our system out if those ISP drivers have some help.
<qschulz>
But the MPP has nothing to do with the ISP, so I'm getting really confused now. I assume if you're mentioning ISP and MPP you want to do camera stream encoding, and that is sadly not yet supported upstream
<qschulz>
vilmursss: FWIW, I have a bad experience with MPP on Rockchip's kernel already, so on mailine with ported MPP...
<CountPumpkin>
There is an ISP driver for rk3399 in mainline, it's just encoding that's missing
<qschulz>
exactly
<qschulz>
vilmursss: support for stuff in mpp and gstreamer-rockchip just often regresses or breaks
<CountPumpkin>
But yes I think the proper move here would've been to make your company invest in mainlining this soc years ago instead of depending on rockchip's vendor kernel
<vilmursss>
yeah exactly, we wanted to try this ISP driver from the mainline but then we had those problems with encoding where mpp plays a role
<vilmursss>
and yes qschulz we tried to encode on the VPU
<qschulz>
vilmursss: yeah, VPU encoding not supported in mainline on Rockchip SoCs right now. Well, I think the kernel supports it for some formats, just that there exists no userspace tool to actually do anything with it
<qschulz>
or let's say, the userspace tool changes aren't upstreamed in the appropriate repos either
<vilmursss>
I see, and actually returning back to my initial question. Is there any plans/hopes that such a support is coming one day? :D
<qschulz>
vilmursss: for an SoC that is almost 8yo now? Probably not, except if you pay someone to do it
<qschulz>
he was working for collabora a month ago according to the talk he gave at the gstreamer conference
<qschulz>
so maybe contact them
<vilmursss>
So you suggest that we just try to implement it ourselves and hope that we do not cause too many bugs while doing it?
<qschulz>
you can also contact paulk I guess, he presented something on that topic at FOSDEM this year
<qschulz>
vilmursss: I suggest like CountPumpkin you paid moneys 5 years ago or whenever you first released the product so the headache of today wouldn't exist
<qschulz>
but that is too late now
hipboi has quit [Quit: hipboi]
<qschulz>
(and to be fair, I'm also currently relying a lot on the mainline community to do most of the heavy lifting for RK3588, so "do what i say not what i do" kind of situation there :) )
<vilmursss>
Yeah, there are thousands (or tens of thousands) devices now all around the world having this SoC which SW we may update tho but not the HW :D
<qschulz>
if this is a device you are going to sell and maintain for like 5-10 more years, it probably would pay itself to contract someone to do the work
<qschulz>
mainline I mean
<qschulz>
for less, no clue, I have no idea how much effort is still left in the kernel and userspace tools
<vilmursss>
yeah for sure
mriesch has quit [Ping timeout: 276 seconds]
jcarrasco has quit [Ping timeout: 276 seconds]
<qschulz>
also, there's hope that this would be useful for all other SoCs from Rockchip
<vilmursss>
actually we are currently on the point that we can either, have encoding to work or decoding but you can not activate both simultaneously for some, yet, unknown reason
<qschulz>
so if money is an issue, maybe you can get multiple companies to pay the same consulting firm to get the ball rolling on stateless VPU encoding we need on all Rockchip SoCs
<qschulz>
can't speak for him, but I would assume he'd be interested to work on that ;)
<vilmursss>
yeah, unfortunately I do not have required authority to just hire someone to do the job :D, rather finding out if it is even possible to get this working similarly as in 5.10. There are of course some security concerns involved, as obviously there is tons of security fixes implemented in newer kernels.
psydroid has quit [Read error: No route to host]
<vilmursss>
However, I really do appreciate your help!
psydroid has joined #linux-rockchip
<qschulz>
vilmursss: you can however tell your bosses they can hire people which would be a good idea, especially if you plan on making new products based on other SoCs from Rockchip ;)
<qschulz>
vilmursss: if security is an issue, any vendor BSP is a joke
<qschulz>
and worse than that, they may introduce vulns that are never going to be reported as they are just forks
<vilmursss>
that is true but our kernel would come nearly 100% from the mainline just picking drivers / modules here and there to apply required HW support
<qschulz>
drivers that take huge data streams from/to userspace :)
<qschulz>
anyway, **I** cannot help with that, so good luck!
<vilmursss>
But to summarize: There is for sure something that needs to do (we have already seen this) with mpp driver to use it with latest kernel releases. However, problems might also be in userspace tools (gstreamer etc.) that needs to be patched.
<vilmursss>
And very unlikely there will come any support anymore due the legacy SoC
Stat_headcrabbed has joined #linux-rockchip
Stat_headcrabbed has quit [Client Quit]
eballetbo has joined #linux-rockchip
hipboi has joined #linux-rockchip
naoki has quit [Quit: naoki]
<qschulz>
Does anyone have DRAM init issues on RK3399 devices by any chance? I regularly see our Puma failing to boot with the following error message
<qschulz>
pctl_start: Failed to init pctl channel 0
<mmind00>
qschulz: interestingly, I've never seen that on my puma
<qschulz>
mmind00: which puma do you have
<qschulz>
and, are you rebooting or hard power reset for botting?
<qschulz>
booting*
<qschulz>
mmind00: which version of Puma do you have is my question
<mmind00>
qschulz: v2.1 and booting
<mmind00>
qschulz: I don't do reboots that much, because most times it's just power-cycling the boards
<qschulz>
the one that's misbehaving right now is a v2.3
<qschulz>
mmind00: yeah that may be a reason, i'm reboot-looping right now
<qschulz>
mmind00: I'm wondering if this is also some issues with not all registers being reset on RK3399
<beeble>
qschulz: should not be version depending. can be memory model dependent (which one do you have?) but i did ten of thousands of reboots without that issue
<qschulz>
beeble: Micron
<beeble>
with v2.3 you should have with micron even less issues as with older v2.1
Stat_headcrabbed has joined #linux-rockchip
<beeble>
so exchanging the module to be sure i would suggest. otherwise i would blame u-boot and say switch to an older one :)
* qschulz
shrugs
<qschulz>
I've never run a non-mainline U-Boot on Puma, and it's not the first time I see that
Stat_headcrabbed has quit [Client Quit]
<qschulz>
I've always wondered if the sysreset-gpio stuff shouldn't actually be done in TPL instead of SPL
<mmind00>
qschulz: judging by the logo on my memory modules, my puma uses micron too
<qschulz>
doesn't make sense to trigger a reset in SPL
<qschulz>
(was probably judicious when we didn't have a TPL though)
Stat_headcrabbed has joined #linux-rockchip
<beeble>
qschulz: depending on what you want to test, maybe take the 2021-03 u-boot as this was the last one i worked on and did all the testing
<qschulz>
beeble: I want the board to work, regardless of what i'm testing ;)
robmur01 has joined #linux-rockchip
<beeble>
qschulz: that was more of a if you want to test a u-boot feature changing u-boot back to 2021 is not an option
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
<qschulz>
beeble: but that may be a good hint as we only switched to TPL for Puma about 2 years or so ago, before it only had SPL.
<qschulz>
I need to check but if the sysreset-gpio handling was done before the DRAM init back then, we "just" need to move this code up in the boot sequence to hopefully fix this
vilmursss has quit [Quit: Client closed]
<qschulz>
if I read the old code correctly (2021.01), the reset is called after relocation, so necessarily after the DRAM has been initialized
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Perflosopher has quit [Ping timeout: 248 seconds]
franoosh has quit [Ping timeout: 252 seconds]
Perflosopher has joined #linux-rockchip
vagrantc has joined #linux-rockchip
warpme has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
ungeskriptet has quit [Killed (lithium.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
raster has joined #linux-rockchip
<dsimic>
qschulz: I'm working on a kernel patch that will make the kernel perform the PMIC-based reset using OTP on supported boards, instead of rebooting and having U-Boot perform the same reset, which should work better and a bit faster, if nothing because there will be no additional reset
<dsimic>
perhaps you'll be interested in testing that patch when it hits the ML :)
<qschulz>
dsimic: you cannot rely on the kernel though, so if you do implement this (i haven't really gotten what you want to do with that or what this should fix), we would anyway need it in U-Boot
<qschulz>
also, isn't the PMIC supposed to be able to do this already?
<qschulz>
I think the whole issue is that this simply doesn't exist on RK808
<qschulz>
hence why the RK3399 devices have a GPIO to toggle instead
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dsimic>
qschulz: that's for the PMICs that support the restart function directly, which doesn't apply to all PMICs, while I'll "abuse" the overtmeprature protection a bit to perform a hardware reset that way, instead of having the SoC reset itself
<dsimic>
s/overtmeprature/overtemperature (OTP)/
<qschulz>
ah, that's what you meant by OTP, and not OTP, you know One Time Programmable :)
<dsimic>
yes :)
<qschulz>
The only issue with that is that if someone reads the reset cause, they'll get overtemp instead of normal reset
<dsimic>
with that in place, the support in U-Boot for the additional reset should never be reached
<qschulz>
likely yes
<qschulz>
I have something locally to move the sysreset very early in the TPL
<qschulz>
probably should post it
<qschulz>
next week though
<dsimic>
good point about the power-on cause... IIRC, there's a scratchpad in PMICs we could use to pass along some additional information
<qschulz>
yes, but then you break old U-Boot relying on that information
<qschulz>
but I guess similarly, once FUSB support reaches mainline for Rock5B you also need a new U-Boot
<qschulz>
so, don't know where we stand on that tbh
<dsimic>
true, but I think it's better not to have possible issues when rebooting, than having a false power-on cause that probably nobody looks at anyway :)
<qschulz>
you can look at it programmatically, which is my biggest issue
<qschulz>
though, that also would be bad if you actually log the console and want to figure out why something rebooted and you get overtemp while it was a simple reboot
<dsimic>
but if you reboot by hand or programmatically, you know it wasn't an OTP event, right?
<dsimic>
it isn't like planned reboots happen on their own :)
<qschulz>
they actually can, e.g. unattended upgrades
<dsimic>
that would be what I called programmatic
<qschulz>
but yes, please cc me on that patch, I'm not subscribed to linux-rockchip nor do I follow it actively
<dsimic>
sure, and we'll see how it goes
<qschulz>
too much to do on other communities and I have mmind00's eyes on that one anyway ;)
<dsimic>
also, the abuse of OTP would be enabled on a per-board basis, so it wouldn't be forced in any way
<dsimic>
e.g. there's Pinebook Pro that would benefit from that OTP abuse a lot, and its reboots are presumably always attented
<dsimic>
while nobody will force anyone to enable this OTP abuse on their boards that don't benefit from it
<qschulz>
let's see what you come up with
<qschulz>
for now, it is week-end time here and I must go home and pet my cat
<qschulz>
see you next week
* qschulz
waves
<dsimic>
TTYL :)
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
eballetbo has quit [Quit: Connection closed for inactivity]
<phh>
i know it's rather off-topic, but does someone have a sharable android 14 sdk from rockchip? (ideally rk3576, but i'm guessing they are all almost identical)
<phh>
I used to download them from firefly, but nowadays it needs to go through sales to get it
pessimal is now known as Ermine
stikonas has joined #linux-rockchip
<naoki>
qschulz: thanks for comment. I'll make -spi variant for linux. and do same for ROCK 5C too ;)
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<rtp>
dsimic: oh I was wondering if the pinebook pro may benefit from the overtemp abuse. I've to test if it's actually working and to check also the schematics to see if it's "correctly" connected. I'll be happy to know if you managed to get it working
<dsimic>
rtp: I haven't actually tested it yet, but according to the schematic, which I've checked multiple times, the OTP should work as expected
<dsimic>
I'll test it while testing those new patches, of course
<dsimic>
regarding the benefits coming from the OTP abuse, they're already known, e.g. the built-in SDIO WiFi has been reported multiple times as flaky to initialize/probe when a Pinebook Pro is rebooted instead of power cycled
<dsimic>
I've been thkinking about using the PMIC scratchpad a bit further, and it should allow us to fix another issue, which is false OTP alerts in U-Boot when the reset button is used on the RockPro64, for example, because it's wired to actually trigger OTP protection
<dsimic>
passing the additional data via the scratchpad will allow us to have only the real OTP alerts, generated by the kernel handling a thermal runaway
<dsimic>
regarding the benefits of the abuse, the same troubles with the SDIO WiFi+BT (and the fix) should apply to the RockPro64 as well
<dsimic>
lat's also ping qschulz about all this ^^^ :)
raster has quit [Quit: Gettin' stinky!]
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]