ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
<tlwoerner>
robmur01: lol, i'll take a look. i'm not getting to a cmdline so i can't do the /sys/kernel thing, but i'll look over my .config and gpio things :-)
kevery has joined #linux-rockchip
nashpa has joined #linux-rockchip
dliviu has quit [Ping timeout: 252 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 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
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 has quit [Ping timeout: 260 seconds]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
archetyp` has joined #linux-rockchip
archetyp has quit [Ping timeout: 258 seconds]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 260 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
archetyp` has quit [Quit: Leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
leming_ has joined #linux-rockchip
leming has quit [Ping timeout: 260 seconds]
Esmil has quit [Ping timeout: 260 seconds]
leming_ is now known as leming
matthias_bgg has joined #linux-rockchip
Rathann has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
urja has quit [Read error: Connection reset by peer]
urja has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<wens>
tlwoerner: full config: wens.tw/arm64-rk-config . I run hand built custom images (self built u-boot, debootstrap rootfs)
<wens>
tlwoerner: I haven't used that board in a while though.
anarsoul has joined #linux-rockchip
anarsoul|2 has quit [Ping timeout: 265 seconds]
<Rathann>
hi folks
<Rathann>
I've got a weird regression between 5.12 and 5.13
<Rathann>
on a Pinebook Pro
<Rathann>
it has two USB 1.1 OHCI controllers
<Rathann>
one is unused (nothing's connected to it)
<Rathann>
and the other is used for built-in keyboard
<Rathann>
so with 5.12 both get initialized early
<Rathann>
while with 5.13, the second one with the keyboard gets initialized only after switching root from initrd to real root
<Rathann>
which is a real problem since my rootfs is encrypted and I can't type at the LUKS prompt without a keyboard ;)
<LinuxHackerman>
Rathann: probably just a driver that needs to be included in your initramfs
<Rathann>
yes, everyone keeps telling me that, but nobody has a clue which driver is missing
<LinuxHackerman>
If you can find the input device node (in /dev/input), you can look up the sysfs tree to see if there are any other potentially important drivers in parent devices
<Rathann>
hm, ok
<Rathann>
I'll try that once the upgrade is finished
<LinuxHackerman>
so find the node in /dev/input, then `readlink -f /sys/class/input/input$n` to find the "full path" to the device
<Rathann>
fortunately I have a serial console so I'm able to type the password even without the built-in keyboard working
<LinuxHackerman>
then go up from there to see if there are any `driver` links that come from a module tha you need to include
<Rathann>
yeah, I can take it from there, thank you!
<Rathann>
that's quick to check compared to doing a full bisect :)
<LinuxHackerman>
That may not be entirely sufficient though, because there could be some regulator or clock drivers which need to be available in order to set up the USB controller
<Rathann>
robmur01 mentioned /sys/kernel/debug/devices_deferred earlier and I thought I'd boot into emergency shell and check if the second controller init is waiting for something
<LinuxHackerman>
Well, given what I know of robmur01, I'd "defer" to his knowledge in that area ^^
<robmur01>
looking at the PBP DT, phy 0 (the one related to the "slow" controller) is linked to a port on the type C connector, so I'd guess it might be waiting for the fusb302 driver to load to resolve that graph dependency
<Rathann>
robmur01: thanks for the clue, I'll check that once the currently running upgrade completes
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
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
<Rathann>
huh
<Rathann>
what do you know, the Fedora 35 kernel initialized both USB controllers just fine
<Rathann>
and I could type the LUKS password
<Rathann>
from the built-in keyboard
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
Esmil has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 260 seconds]
archetyp has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
warpme__ has quit [Ping timeout: 252 seconds]
warpme__ has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
Rathann has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Ping timeout: 258 seconds]
<tlwoerner>
wens: sweet! your config allows me to boot to the cmdline on my roc-rk3328-cc :-D
<tlwoerner>
so now i have 3 rk3328 devices running (rock64, rock-pi-e, and roc-rk3328-cc) 2 of which have video output (hdmi)
<robmur01>
"CONFIG_GPIO_SYSCON=y" - that's the little bugger!
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
lopsided98 has joined #linux-rockchip
cp- has quit [Ping timeout: 265 seconds]
cp- has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<CounterPumpkin>
tlwoerner: does your rk3328 video output actually provide a useable experience? Mine's super glitchy in something like weston
matthias_bgg has quit [Ping timeout: 258 seconds]
matthias_bgg has joined #linux-rockchip
macromorgan_ has joined #linux-rockchip
macromorgan has quit [Killed (silver.libera.chat (Nickname regained by services))]
<tlwoerner>
CounterPumpkin: i'm not using these devices for anything specific. i build an image, flash the sd card, and run a test like glmark2. half the time i don't even watch the test run, i just come back later and check the console output
<CounterPumpkin>
I see
<tlwoerner>
but i have noticed some glitching with wayland/weston
<tlwoerner>
when glmark2 is about to run the [refract] test the previous test [shadow] visibly halts, there are quite a few full-width horizontal glitches, then [refract] starts
<tlwoerner>
some other tests show this glitching as well, but not anywhere as noticeable as when [refract] is getting read to run
<tlwoerner>
s/read/ready
<CounterPumpkin>
Yeah, I think it's either something broken in vop or in the hdmi. Haven't had time yet to look into it, LibreELEC probably has patches to fix it that they haven't submitted upstream yet
<robmur01>
CounterPumpkin: try running something like "perf bench mem" and watch the display really fall apart ;)
<jakllsch>
heh
<CounterPumpkin>
huh, what's causing that?
<jakllsch>
bad qos on the memory interface?
<tlwoerner>
robmur01: yep, there it is. adding this one option, CONFIG_GPIO_SYSCON, makes my roc-rk3328-cc happy
<tlwoerner>
thanks :-D
<robmur01>
apparently downstream U-Boot tweaks the interconnect QoS to give the VOP higher priority, but memory bandwidth is pretty limited whichever way. Probably moreso if you're using a miniloader/SPL config that leaves the memory clock at down around 333MHz
<CounterPumpkin>
I see, so not easy to fix then
<CounterPumpkin>
I can't find a kconfig option to control the memory clock but the rock64 includes some dram 1666 file in its device tree, so I guess I'm good on that front?
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
<CounterPumpkin>
Can't see any qos nodes in downstream u-boot's rk3328.dtsi, but I am just poking in the dark here
<CounterPumpkin>
ah-hah, but the rk3288 has some CPU_AXI_QOS_PRIORITY_LEVEL stuff going on regarding the vop
<CounterPumpkin>
ok I think I got all the puzzle pieces together to do vop QOS on the rk3328. Too bad I won't have time tomorrow.
<CounterPumpkin>
service register base addresses should be the same as on the rk3228, for which I do have a more complete TRM.
kevery has quit [Ping timeout: 264 seconds]
kevery has joined #linux-rockchip
stikonas has joined #linux-rockchip
macc24_ has quit [Ping timeout: 258 seconds]
macc24 has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
Rathann has joined #linux-rockchip
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
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
warpme__ has quit [Quit: Connection closed for inactivity]
stikonas has quit [Remote host closed the connection]