warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 260 seconds]
lurchi_ has joined #linux-rockchip
lurchi_ is now known as lurchi__
montjoie has quit [Remote host closed the connection]
psydroid has joined #linux-rockchip
Net147 has quit [Ping timeout: 264 seconds]
Net147 has joined #linux-rockchip
Net147 has quit [Changing host]
Net147 has joined #linux-rockchip
macromorgan_ has joined #linux-rockchip
macromorgan has quit [Ping timeout: 264 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
stikonas has joined #linux-rockchip
Rathann has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
jaganteki has quit [Quit: Client closed]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
psydroid has quit [Read error: Connection reset by peer]
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #linux-rockchip
jaganteki has joined #linux-rockchip
psydroid has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
Stat_headcrabed has joined #linux-rockchip
jaganteki has quit [Quit: Client closed]
<linkmauve>
Alright, my Rock-5B boots with Collabora’s rk3588 u-boot branch… until “Starting kernel ...”
<linkmauve>
Or perhaps just the kernel doesn’t know to continue printing its dmesg to the serial console.
raster has joined #linux-rockchip
<raster>
o/
<linkmauve>
Putting the correct UUID in the cmdline is surprisingly useful to get the kernel to find its rootfs. :D
<raster>
bizarre issue i encountered for the first day on my rk3399... built a new kernel etc. and problems start before the kernel even starts in u-boot... loading the kernel and initrd is like 1/20th of the speed of my older ones.... (and then when booted i'm missing cpufreq and so on) what on earth would cause this? same u-boot. nothing changed there
<raster>
i can boot into my older kernel and it loads up fast.
<raster>
like
<raster>
24114567 bytes read in 1232 ms (18.7 MiB/s)
<raster>
vs
<raster>
24283676 bytes read in 21439 ms (1.1 MiB/s)
<raster>
(loading the initrd's - same story with vmlinuz)
<raster>
what on earth could be related to this?
<linkmauve>
Hmm, there is no thermal driver for the rk3588 in 6.7 yet…
<linkmauve>
I feel quite uneasy letting it run without any thermal supervision with my handmade heatsink. :s
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<raster>
linkmauve: there seem to be a lot of missing drivers ... :)
<linkmauve>
There is the main one I wanted to play with: the AV1 hardware decoder. \o/
<raster>
i have to get onto mainline on my 3588 ... but as i kind of need hdmi - that seems ot be missing ... along with a lot of others.. i'm going to have to go internet patch hunting :(
<raster>
but first.. why my 3399 now is running like molasses on 6.7 :(
<linkmauve>
raster, perhaps try to bisect for your kernel issue?
<linkmauve>
Are you familiar with git bisect?
<raster>
linkmauve: but why does the slow load begin before the kernel in uboot land?
<linkmauve>
Ah hmm, that’s weird indeed. :o
<raster>
and yeah - yeah.. .i know about git bisect... but the problem starts with slowness with uboot extlinux loading kernel and initrd super-slowly just for the new image - the older kernel i have loads fast as usual
warpme has joined #linux-rockchip
<raster>
yeah... so before i bisect a kernel... i have a big red flag there before kernel even starts up... and i'm scratching my head as to why this would happen.
<raster>
as u-boot will have already gotten up to the point of having emmc drivers etc. up and thus should load at the same speed...
<raster>
oh wait....
<raster>
has compression method changed?
<linkmauve>
Run `file` on both kernel images, it should tell you how they are compressed.
<raster>
so its not the i/o thats slow but the decompress?
<raster>
hmm nope
jaganteki has joined #linux-rockchip
<raster>
initrd's are both gzip still...
<raster>
(both initrd and kernel are super slow)
Stat_headcrabed has quit [Quit: Stat_headcrabed]
daniels__ is now known as daniels
<daniels>
raster: hdmi is nowhere near mainline yet ...
<mmind00>
linkmauve: there is also no cpufreq for rk3588 yet, so thermal wouldn't help you anyway
<mmind00>
daniels: yep ... and seeing glmark run using panthor via hdmi on the rk3588 is just beautiful :-)
<daniels>
:D
<daniels>
that integration tree does have cpufreq tho?
<mmind00>
yep it does
* mmind00
is currently trying to make the dp via type-c work
camus has quit [Quit: camus]
macromorgan_ is now known as macromorgan
ldevulder has quit [Quit: Leaving]
<raster>
daniels: so i had gathred. it was a WIP....
<raster>
daniels: i was beating my 3588 to finally load the rught uboot which didnt have serial disabled...
<raster>
now i finally have it... i can consider a different kernel :) but my 3399 now is holding my attention :(
jaganteki has quit [Quit: Client closed]
<daniels>
yeah, that's really weird - our 3399s are holding up pretty well on 6.6 at least
<raster>
yeah - mine has held up well too... until today when suddenly wtf... u-boot loads kernel image+ initrd at 1/2th of the speed - only the new 6.7 initrd+vmlinuz - not my older one....
<raster>
and then linux boots with no cpufgreq working and running like garbage (incredibly slow - i assume (as i dont really know) that the cpu is cloced to lowest clock rate etc.)
<CounterPillow>
tf-a broken? Could mess with the clocks. Would affect both kernels though
<raster>
i'm guessing for now the initial slow image load is where everything starts going wrong...
<raster>
CounterPillow: yeah - would affect both. i literally can select my older kernel in extlinux menu and it boots fine - intird + vmlinuz load in fast at like 18mb/sec and everything is normal
<raster>
i simply select mmy 6.7 image and the u-boot load is slow like 1.1m/sec
<raster>
and everything from there is slow
<raster>
i didnt change the bootloader at all - its the same one as i've always used...
<raster>
so i'm a bit baffled right now as to where to poke to find out. if u-boot was working the same i'd be probably considering a bisect
jaganteki has joined #linux-rockchip
<linkmauve>
daniels, I just tested that rk3588-v6.7 branch, but there is still nothing in /dev/dri, the rockchipdrm doesn’t load automatically, and panthor isn’t present in that tree.
<linkmauve>
That’s probably on another branch, and hasn’t been backported to that v6.7 branch.
Stat_headcrabed has joined #linux-rockchip
<raster>
there are certainly patches on-list for panthor
<daniels>
raster: I bet you’ve got the wrong DT
<daniels>
linkmauve: maybe!
<daniels>
sre: ^ ?
<raster>
daniels: but why would u-boot be slow?
<daniels>
raster: it couldn’t have anything to do with the kernel at that point …
<daniels>
(btw a panthor v4 is coming pretty soon)
<raster>
i know...\
<raster>
thats why i'm wtf-ing
<raster>
why would u-boot be 20x slower at loading the initrd + vmlinuz from emmc when thsoe are selected vs my older ones?
<raster>
just that alone flips to being slow before kernel and initrd start
<raster>
the extlinux.conf actually automatically has the right fdt entry per image - but this should only be relevant after kernel boots anyway - not before...
<raster>
the dtb file reverred to is the one built from the upstream src and the older dtb is fine
<raster>
and yeah - dmesg certainly indicates it cant find some regulators and that's probably why cpufreq is not there
<raster>
but interestingly enough the dtb's are binary idential between older kernel tree and 6.7 build ...
<raster>
same md5 :/
<CounterPillow>
Wild guess: your new kernel is built without PMIC support because when RK806 support was added, somebody messed up the defoldconfig mechanism and made it turn off RK8xx support for everyone who had it turned on previously. Go into your kernel kconfig, search for RK8, and turn it on
<CounterPillow>
as for why it loads slower, no clue, could be entirely unrelated.
<raster>
thats what baffles me - why that is slower... its like a red flag i can't ignore
<raster>
but ... i didnt make defconfig
<raster>
i literally copied over my old .config ...
<raster>
and all the PMIC options between the 2 kernels are the same
<raster>
at least a grep PMIC and compare says so
Rathann has quit [Ping timeout: 260 seconds]
<CounterPillow>
if you use your old .config and build a newer kernel against it it will ask you to update your config with all the new options that are added
<raster>
hmm but yeah
<raster>
its under RK8...
<raster>
odd
<raster>
yeah it did
<raster>
but a lot of previous pinctrl, etc. RK8xx options have gone?
<raster>
only ones now are CONFIG_MFD_RK8XX_I2C and CONFIG_MFD_RK8XX_SPI - right?
<CounterPillow>
don't edit the .config manually, use a kconfig editor like "make xconfig"
<raster>
there are dependencies i need to turn on?
<CounterPillow>
Which a kconfig editor will do for you
<raster>
menuconfig... here i come
<raster>
but still
<raster>
why the hell is u boot loading them slowly?
<raster>
or have i somehow gottne lucky and managed to trigger 2 completely separate "bugs" at the same time :)
<raster>
just CONFIG_MFD_RK8XX=y also a dep :)
jaganteki has quit [Quit: Client closed]
<CounterPillow>
You'll also want CONFIG_REGULATOR_RK808 et al
<raster>
and in fact all of those did not get set :/
<raster>
why they aren't in defconfig ... :(
<CounterPillow>
they are in the arm64 defconfig, but if you had them enabled in an old config and transitioned to a new kernel they got flipped off again because KConfig is a massive trash fire
<raster>
well yeah the trashfire thing is the problem :)
<raster>
kind of a pain ... but i'll get past that
<raster>
i did kind of assume i possibly either had a dt break or some change in config isue
<raster>
but ... the whole u-boot slow load is creaming at me making me stop and stare at that as a "well if this is slow... this smells of being related... but how?"
chewitt has quit [Quit: Zzz..]
<raster>
well the config changes fix the slow after linux boot problem
<raster>
still... wth ... u-boot... whyyyyyy? :/
<CounterPillow>
if the same code loads two different files at different speeds I'd suspect either the filesystem or the precise blocks they're stored on, either is bad news
<raster>
yeah... that thought crossed my mine - emmc blocks somehow being ... bad
<raster>
but its reads not writes... so thats why i was "hmmm"
Rathann has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Stat_headcrabed>
Is there someone working on rkvdec2 mainline support?
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<CounterPillow>
If they are then they haven't told anyone
raster has quit [Read error: Connection reset by peer]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
eballetbo has quit [Quit: Connection closed for inactivity]
shailangsa_ has quit [Remote host closed the connection]
<macromorgan>
CounterPillow: Finished testing and I added my comments on that page. I got it to work but until we support SCMI clocking with A-TF I can't replace the BSP A-TF just yet.
<macromorgan>
Note that if you don't disable SCMI in U-Boot you will get a hard lock, so make sure you disable that before you test
<CounterPillow>
Oh, is it still missing the SCMI stuff? :(
<macromorgan>
yes
<CounterPillow>
urgh
<macromorgan>
I can use it on a few of my devices though
cmjx has quit [Ping timeout: 256 seconds]
cmjx has joined #linux-rockchip
<diederik>
AFAIUI the plan was to add SCMI in a later patch, but the initial patch seems stuck for some (unknown) reason ...
<diederik>
comment from power-xsf from 2023-07-09
linkmauve has quit [Quit: Gateway shutdown]
a1batross has quit [Quit: Gateway shutdown]
vagrantc has quit [Quit: leaving]
Rathann has quit [Quit: Leaving]
cmjx has quit [Ping timeout: 276 seconds]
cmjx has joined #linux-rockchip
<macromorgan>
I added my comment today that things are "more or less okay" which I hope will move it along. I guess if more people test it and chime in things will move faster?