00:12 <macc24> is this supposed to do anything besides changing voltage?

00:12 <macc24> https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/devfreq/rockchip_bus.c#L181

00:12 <macc24> mmind00: any ideas on ^ ?

01:01 <macromorgan> looks like that bus driver changes the voltage/frequency?

01:06 <macc24> it doesn't change frequency from what i see

08:23 <mmind00> macc24: what makes you think this doesn't change voltages? ... i.e. from what I see, it attaches to cpufreq notifications and sets that bus clk+voltage before or after cpu frequency changes

08:25 <mmind00> see the cpufreq notifier, foo_set_target call + opp handling inside

08:25 <mmind00> though I can't remember if someone was working on upstreaming that in the past

08:38 <macc24> mmind00: i don't really see anything besides regulator_set_voltage in rockchip_bus_clkfreq_target

08:39 <macc24> and the way px30 dtsi is set in rockchip's kernel makes it use only clkfreq stuff

08:39 <mmind00> macc24: how about https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/devfreq/rockchip_bus.c#L278 ?

08:41 <macc24> mmind00: rockchip_bus_cpufreq_target is not used, as https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/px30.dtsi#L241 is making rockchip_bus executerockchip_bus_clkfreq which does not use cpufreq functions

08:46 <mmind00> macc24: ok

08:49 <mmind00> macc24: I guess there it's really only to adjust the vdd_logic supply

08:49 <mmind00> depending on the cpu frequency

08:50 <macc24> guess it does nothing ¯\_(ツ)_/¯

09:16 <robmur01> macc24: it's using a clock notifier, so presumably some other consumer is controlling the bus clock, then this just wiggles the voltages to match

09:19 <robmur01> oh, yeah, dtsi says the notifier will be on APLL which is also the CPU clock, so it's effectively just a cpufreq follower

09:26 <macc24> a bee flew into my room o.o

09:27 <macc24> anyway, robmur01: when there's a high cpu usage, dram would be stressed to and that runs off vdd_logic so it can be just ignored or am i getting something wrong???

09:31 <robmur01> Why must high CPU usage mean high DRAM load? Many compute-intensive workloads can run mostly or entirely out of L1/L2

09:32 <macc24> oh ok

09:32 <robmur01> also, performance governor ;)

09:36 <robmur01> certain embedded applications may value interrupt response latency over power saving, for instance

10:37 <Viche> hey, i have an RK3128, a lot of documentation and SDKs are for the RK3328, are they compatible?

10:50 <warpme_> guys: can somebody point me for (or help to find) rksd_loader.img blob download for rk3399 orangepi-4?

10:59 <stikonas> warpme_: does orangepi4 not work without blob?

11:01 <stikonas> I would rather use upstream U-boot and no blobs

11:12 <robmur01> Viche: no, they are significantly different (32-bit vs. 64-bit for one thing)

11:14 <warpme_> stikonas: well - mainline uboot was my first idea. but afaik to build i need atf and to build atf i need toolchain for m0 target (dram.o). I'll go probably with vendor bl31.elf copied to mainline u-boot build directory. but for testing purposes it will be nice to have handy working rksd_loader.img blob ready to just dd to sd card...

11:14 <Viche> ah ok, docs only say how to make android

11:15 <Viche> i can't find a linux sdk for 3128

11:15 <Viche> does anyone know where I can find it?

11:15 <stikonas> warpme_: you need atf either way...

11:20 <warpme_> just wonder - what will be simplest method to acquire working rksd_loader.img blob Maybe getting armbian sd card image for orangepi-4 and do dd from sd card image to file?

11:23 <stikonas> is armbian even using rksd_loader?

11:25 <stikonas> warpme_: btw, I have atf 2.4 compiled for rk3399 https://stikonas.eu/files/gentoo-sources/u-boot/bl31.elf

11:25 <stikonas> if you don't want to build it yoruself

11:30 <warpme_> stikonas: for sure armbian was in past as armbian guys provided me blob when i was adding support for rockpi4 year ago in my dostro. now i want to add support for orangepi4. as i don't this hw to test - i want to do one-steep in time. 1\create sd image for orangepi4 based on rockpi4 image by just replacing bootloader blob from rockpi4->orangepi4; 2\add sources built uboot booloader for orangepi4 image

11:31 <stikonas> well, wait a bit here and see if somebody else knows more. I only worked with upstream u-boot...

11:32 <stikonas> (I did these steps to get my rockpro64 to boot https://stikonas.eu/wordpress/2019/09/15/blobless-boot-with-rockpro64/)

11:52 <warpme_> stikonas: very nice doc!! thx!

11:52 <stikonas> a bit oldish now, but things should only work better with newer versions...

12:07 <Viche> robmur01 do you know where the best place to download a linux sdk for a 3128?

12:17 <robmur01> for standalone BSP bits like kernel/U-boot, probably Rockchip's Github. For the full vendor package, looks like Firefly have shared the "Android SDK" in the support files for their 3128 boards - no idea if an actual "Linux SDK" even exists :/

12:20 <Viche> robmur01 it's been puzzling me for a while, especially with Rockchip's image packing system and multi level bootloader, I was hoping for an "idiot proof" way of getting linux on the 3128.

12:23 <Viche> ls

12:23 <Viche> ffs >.>

13:17 <phh> Rockchip's Linux SDK is https://github.com/rockchip-linux/meta-rockchip's yocto layer

22:09 <warpme_> stikonas: fyi: got rockpi4 fully booting/working with mainline uboot. thx for your nice guide. orangepi-4 should be now just snap!

22:12 <stikonas> warpme_: yeah, they should all be pretty similar

22:38 <warpme_> and i'm now with your AFT bin :-)

22:38 <warpme_> ATF

23:13 <warpme_> fyi: orangepi-4 also boot nicely with mainline uboot... thx guys!