08:37 <qschulz> shoragan: and the more_opts would be coming from the conf of SnagrecoverDriver as well? the self.soc cannot always be derived, see rk3566 and rk3568 sharing the same productID

08:38 <qschulz> also, I really want the images passed to snagrecover to be configurable so that one can test U-Boot binaries without hacks

08:49 <Dex_2x> Is the radxa rock 3C relatively new? Because I don't see it listed on armbian

08:50 <qschulz> Dex_2x: announced 2 years ago

08:50 <qschulz> https://radxa.com/blog/ROCK-3C-officially-announced/

08:51 <Dex_2x> Okay so not new, but not that well supported :/

08:51 <qschulz> there's a DTS upstream already, see https://elixir.bootlin.com/linux/v6.16.6/source/arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts

08:51 <qschulz> Dex_2x: it's not because armbian does not support it that it's not well supported

08:53 <Dex_2x> more the rk3566 that is the issue?

08:53 <CounterPillow> no

08:53 <CounterPillow> RK3566 is well supported in mainline

08:54 <CounterPillow> You just don't see an image for this particular device in Armbian, and somehow conclude that everything but Armbian is the problem, when that is not the case.

08:54 <Dex_2x> well radxa only has one image for it as well

08:55 <dsimic> in general, Armbian should be considered for the boards that aren't supported well upstream; otherwise, "plain" Debian is the way to go

08:55 <Dex_2x> I have yet to try plain debian

08:55 <Dex_2x> on a sbc

08:56 <dsimic> the goal high in the sky is that no SBC manufacturer provides some special images, but to have the SBCs "just work" in "vanilla" ARM distros

08:56 <CounterPillow> The DTS is in mainline and SoC support is in mainline as well. The number of poorly copypasted together images made up of vendor stuff is not an indication of how well an SBC is supported

08:57 <qschulz> you may be missing some features as development on RK356x (and possibly Rock 3C) continues, e.g. there's no camera support at the moment if I remember correctly

08:58 <qschulz> so you may need (or even want) to build the mainline kernel yourself

08:58 <qschulz> which is a bit far from "download the image from site Y and flash on my device"

08:59 <qschulz> but we are here if there's any question on the process :)

08:59 <dsimic> Dex_2x: to clarify, regarding Armbian, it's just that people are used a bit too much to having some special images for their SBCs; in the past, Armbian did a great job offering support for the boards that weren't supported well upstream, but as they becomee supported, "vanilla" Debian should be considered instead

08:59 <Dex_2x> dsimic, ah fair enough

08:59 <dsimic> IOW, Armbian could be seen as some kind of staging area

08:59 <CounterPillow> Armbian actually deviates from both mainline and vendor images, doing their own thing, and in the process confusing users

09:00 <dsimic> CounterPillow: true, but for the unsupported boards, there isn't much choice otherwise

09:00 <dsimic> short of hunting down the images provided by the SBC manufacturers, of course

09:18 <CounterPillow> dsimic: there is. Mainline them instead of slapping mud against walls downstream.

09:19 <CounterPillow> Submitting a new board DTS for an already supported SoC is one of the easier ways to contribute towards mainline development

09:20 <CounterPillow> (assuming no excess emotional damage taken from krzk responses)

09:25 <Dex_2x> lol

09:27 <dsimic> CounterPillow: indeed, but there's always a window in which upstream support simply isn't there

09:28 <dsimic> haha, Krzystof does happen to induce some feelings from time to time :)

09:30 <dsimic> though, I wouldn't agree that putting a DT together and submitting it upstream is one of the easiest way to contribute upstream; a lot of knowledge is actually needed, unless one just copies a DT from the downstream blindly

09:30 <dsimic> s/way to/ways to/

09:31 <dsimic> oops, s/Krzystof/Krzysztof/, sorry

09:34 <CounterPillow> copying downstream DTs is a bad idea because the bindings will be different, the much easier method is to "get inspired" by other SBCs using the same SoC that are already upstream, as they all usually have fairly similar designs, owing to many of them being derived from either EVB designs or made by the same contract design houses.

09:34 <dsimic> true, there are many similarities

16:07 <mmind00> Kwiboo: you seem to have a lot of rk3506 patches in https://github.com/Kwiboo/linux-rockchip/commits/next-20250227-rk3528-rk3506 ... are you planning on pushing some of them upstream? :-)

16:18 <Kwiboo> mmind00: I do not think I ever runtime tested any of them, mostly started to pick apart what I picked up from vendor for u-boot at https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3506 (recently rebased)

16:19 <mmind00> Kwiboo: oh ... nice ... because not having a sane u-boot did keep me very much from even looking at my rk3506 board so far

16:20 <CounterPillow> I, too, have a RK3506 board :D

16:20 <Kwiboo> if I remember correctly the new "cpuclk_v2" threw me off a little bit, so I probably just switched focus to rk3528 instead, should re-send some series for rk3528 before ever looking at linux part for rk3506 ;-)

16:21 <mmind00> yeah, looking through that branch, this one stood out a bit ... (me not trusting that a "v2" is needed yet)

16:21 <mmind00> also I'm definitly undecided on that psci smp method .... probably requiring some binary optee thingy right now

16:23 <mmind00> CounterPillow: that arm64 thing will forever stay a fad ;-)

16:24 <mmind00> arm32 FTW

16:24 <CounterPillow> mmind00: you have now been hired by STM

16:24 <Kwiboo> trying to rework that v2 cpuclk is what I got stuck at, trying to merge it with existing or similar without really understand the existing v1 cpuclk and how it would impact, did not want to dive into another rabbit hole ;-)

16:24 <mmind00> noooooooooooooo

16:24 <mmind00> (^^ CounterPillow)

16:25 <CounterPillow> :D

16:25 <mmind00> Kwiboo: yeah ... I did try to stay out of the rk3506 rabbit hole ... but then you showed me that u-boot branch

16:25 <mmind00> darn you

16:26 <mmind00> there is this Sesamestreet clip on youtiube where Ian McKellen is teaching Cookiemonster about the word "resist" ... need to rewatch

16:30 <Kwiboo> hehe :-), I did a boot test with that rk3506 u-boot branch on a luckfox lyra regular/plus/ultra/zero-w and armsom forge1 the other day, boot from sd-card/emmc, usb otg/host and ethernet should be working, spi nand is not, use of correct rk3506 vs rk3506b ddr init blob seem to be important