<diederik>
wens: It looks like my Rock 5B rebooted while I was trying to compile a kernel :-O I did use a power supply which is (potentially) less good then the one that came with it and I normally use
<diederik>
and you may 'grep' dmesg and/or ``journalctl -k -b <bootnr>`` for ``rockchip-pm-domain``. I see both "sync_state() pending" messages but also "Failed to create device link (0x180) with supplier spi2.0 for /power-management@fd8d8000/power>"
<diederik>
In one of my replies I mentioned having or not having " fw_devlink=off" in your kernel command line may make a difference (at least for the warning). And my Rock 5B does not (yet) have that parameter
<diederik>
The kernel that rebooted actually has Ulf's patch set ...
<wens>
either my nvme is not getting enough power during build or it's broken, but if I build the kernel on it the nvme controller goes down :(
<diederik>
that could have been the case with me too as I'm using an NVMe drive on it
<diederik>
switched back to my normal PSU and added the fw_devlink=off parameter and restarted the build. It has already gone further then the previous attempt
<CounterPillow>
the fw_devlink stuff should have no impact after the system is fully booted as far as I am aware
<diederik>
It does supress the "sync_state()" messages, but I don't know if it has an actual effect
<diederik>
It could very well be that my problem was just the PSU, but I added the fw_devlink parameter 'just in case' as I don't recall having such problems before
<wens>
yeah, I don't think the sync state stuff matters in this case
sigmaris has joined #linux-rockchip
dsimic has quit [Ping timeout: 244 seconds]
dsimic has joined #linux-rockchip
chewitt has joined #linux-rockchip
<chewitt>
Kwiboo looks like RK3566 needs the same plane order hack to show the OSD in Kodi
<chewitt>
so far only H264 decoding works too
<chewitt>
I'm currently assuming that 3566 and 3568 are essentially the same for media capabilties?
<dsimic>
wens: diederik: hmm, all that is quite suspicious... you could try putting the NVMe SSDs into its lowest available power profile, to see would that make it more stable under heavy I/O
<dsimic>
linkmauve: getting the GPU blob(s) REd would be great, but be prepared for a long journey :)
<dsimic>
wens: diederik: similar power-related issues with NVMe SSDs aren't unheard of, usually arising from suboptimal board designs such as on the Pinebook Pro, so it should be worth it to try lowering the power consumption of the drive
<wens>
I switched to a separate power supply, and retrying the build now
<dsimic>
let's see how that works out
<wens>
stable so far
<wens>
I forgot to put a meter in line
<diederik>
I have no idea how to put the NVMe in a power profile; I didn't even know that existed (but I learned there's a lot more to NVMe then I previously knew)
<diederik>
Kernel build succeeded with the other/better PSU btw
<dsimic>
diederik: yup, NVMe drivers are quite complex devices
<diederik>
the spec says it can also have namespaces, but not every drive implements that
<dsimic>
ah, so it was up to the PSU, which is good to hear; with what PSU it failed?
<dsimic>
yes, namespaces aren't mandatory
<diederik>
the small PinePower (65W) where I reported another problem with it some time ago
<dsimic>
huh, that's quite bad
<diederik>
yep, so it seems it's really only good enough for charging things
<dsimic>
it works quite well with the Pinecil, though
<diederik>
Yeah, interruption of power may probably not matter for the Pinecil. But for SBCs it's quite bad
<wens>
building on all 8 cores on the NVMe with a small fan, the board is drawning close to 3A 5V
<wens>
drawing*
<wens>
... and it failed again
<dsimic>
diederik: it also matters for the Pinecil, and I haven't noticed such interruptions... maybe that PSU starts misbehaving only under continous high load, which is an assumption reassured by the Pinecil's pulsed nature, as a load
<qschulz>
wens: can your PSU provide more than 3A on the 5V rail?
<dsimic>
wens: shouldn't the board use a higher-voltage PD profile? I'm actually not surprised by it failing under high CPU load and with not-so-light I/O load on an NVMe SSD, while being limited to about 15 W... let me check the schematic a bit later
<diederik>
dsimic: I thought you needed/should the big PinePower for the Pinecil? It has a port clearly marked for that
<dsimic>
the v2 has such a label, the v1 didn't have it
<dsimic>
the Pinecil works fine with the small PinePower, which is capable of delivering 65 W in that use case
<diederik>
ok. when I bought the v1 it was commonly understood (at least by me) that the USB-C port was (meant) for use by the Pinecil
<dsimic>
it works with the Pinecil, but it's just a standard USB PD port capable of delivering 65 W
<wens>
without the in-line power meter it works fine :(
<wens>
dsimic: the orange pi 5 plus is 5V only with the passive resistor stuff on the CC pins
<dsimic>
wens: perhaps pulling just 15 W works just on the brink of drawing too much power with no inline power meter, and the meter causes just large enough power loss to make it actually fail
<dsimic>
wens: I'm now wondering is the Orange Pi 5 Plus meant to be used with at-the-edge-of-spec USB PD PSUs capable of delivering 5 A at 5 V?
<dsimic>
that's what Raspberry Pi does, as well as some Radxa boards
<wens>
perhaps
<wens>
the schematic says 5V4A
tlwoerner_ has joined #linux-rockchip
detlevc83 has joined #linux-rockchip
ndufresne3 has joined #linux-rockchip
dsimic_ has joined #linux-rockchip
Kwiboo- has joined #linux-rockchip
maz_ has joined #linux-rockchip
Ermine_ has joined #linux-rockchip
catcream_ has joined #linux-rockchip
dsimic has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
dsimic_ is now known as dsimic
<chewitt>
Kwiboo I now have HEVC 'working' on 3566{8} using the vdec node from the 3588
dsimic has quit [Client Quit]
detlevc8 has quit [Read error: Connection reset by peer]
tlwoerner has quit [Read error: Connection reset by peer]
ndufresne has quit [Read error: Connection reset by peer]
Kwiboo has quit [Ping timeout: 256 seconds]
catcream has quit [Ping timeout: 256 seconds]
Ermine has quit [Ping timeout: 256 seconds]
jelly has quit [Ping timeout: 256 seconds]
maz has quit [Ping timeout: 256 seconds]
detlevc83 is now known as detlevc8
catcream_ is now known as catcream
Ermine_ is now known as Ermine
ndufresne3 is now known as ndufresne
dsimic has joined #linux-rockchip
<chewitt>
but I assume the vdec will require specific support for 3568 as capabilities are different, 3566 doesn't have av1 as far as I can see
<chewitt>
detlevc have you done any work on 3566/3568?
<chewitt>
(before I reinvent the wheel)
<CounterPillow>
we're not currently doing any codec work on 3566/3568 as far as I'm aware, no
<diederik>
rk3568 does not have av1, correct
<diederik>
chewitt: I hope/plan to post my RFC later today
<chewitt>
do you have patches in a repo somewhere?
<chewitt>
i'm interested to see what I missed so far :)
<detlevc>
chewitt No, I have done nothing on those
<diederik>
(that was referenced in my HEVC testing reply in which I CC-ed you (on Saturday))
<detlevc>
on 3588, AV1 is driven by the hantro driver. on rk3576, it will be rkvdec, but nothing has been done yet either
<diederik>
my RFC patch will have slightly different and some more notes though
detlevc81 has joined #linux-rockchip
<chewitt>
detlevc do we need to define a new compatible for 3568 due to differences, I think so, yes?
dsimic_ has joined #linux-rockchip
<Ermine>
Does rkvdec need to be adapted for 3566?
rgolledge2 has joined #linux-rockchip
dsimic has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
dsimic_ is now known as dsimic
jelly-home has joined #linux-rockchip
<CounterPillow>
Ermine: probably, rockchip likes to move around registers, but it's closely related hardware just with fewer cores iirc
<diederik>
Today I did some testing with Rock 5B and was quite impressed. I got it working pretty decently on rk3568 though (with just an extra DT patch; linked above)
<linkmauve>
Uh, ALARM still recommends to create the first partition at the default sector (2048 in fdisk), which is much less than the size of U-Boot + TF-A + the DDR binary (9.1 MiB atm). :/
detlevc8 has quit [*.net *.split]
rgolledge has quit [*.net *.split]
detlevc81 is now known as detlevc8
<diederik>
leave the first 16MiB free and you should be fine
<CounterPillow>
I recommend not using ALARM since it's basically just one guy and sometimes he disappears and the kernel isn't updated for 6 months
<linkmauve>
I build my own kernel.
<linkmauve>
But yeah, maintenance has been sub-par. :/
<CounterPillow>
you shouldn't need to take ALARM's advice on the layout anyway, rockchip reads ddr init from sector 64, that's all you need
<diederik>
but f.e. mobian also hasn't figured out that you shouldn't start partition 1 on 2048 sectors (at least last time I looked; which is quite a while now)
<CounterPillow>
everything after that is whatever u-boot does, so your kernel and rootfs can be wherever
<linkmauve>
I haven’t found a better distribution though so far.
<Ermine>
Actually first 64 blocks are enough for default-sized GPT
<diederik>
I probably made a 'typo' with my 2048
<CounterPillow>
I just use GPT with reduced number of partitions instead of 128 so the header fits before 64s, then 64s+16MiB for u-boot, then / after that to the end of the block device. No other partitions
<linkmauve>
Ermine, but not for DOS, which is still the default on most microSD.
<diederik>
yeah, you're right. Starting at sector 64 is what I do
<Ermine>
CounterPillow: 128-partition GPT header also fits
<CounterPillow>
fdisk yelled at me :(
<diederik>
why stick with a/the default (partition table) which the SDcard happen to come with?
<Ermine>
:/
<Ermine>
gdisk works fine and reports sector 34 as the first usable one
<CounterPillow>
Hmmm, interesting
<Ermine>
linkmauve: just overwrite it
Tartarus has quit [*.net *.split]
ungeskriptet has quit [*.net *.split]
tortoise has quit [*.net *.split]
paulk-bis has quit [*.net *.split]
adadad has quit [*.net *.split]
<detlevc>
chewitt we definitely should hav a compatible for each SoC, even if we don't have adaptations for it yet. So if 3568 works very similarly to 3588, it should have "compatible = "rockchip,rk3568-vdec", "rockchip,rk3588-vdec";"
Tartarus has joined #linux-rockchip
paulk-bis has joined #linux-rockchip
ungeskriptet has joined #linux-rockchip
adadad has joined #linux-rockchip
tortoise has joined #linux-rockchip
<chewitt>
I'd guess that 3588 acts like a superset of capabilities so we should be able to copy/paste in rkvdec.c and then just omit the bits that aren't supported
<chewitt>
although I need to go read that file more :)
<detlevc>
yes, to each SoC its rkvdec_config
<detlevc>
but if it work as is with the rk3588 config for now, it can use it and the compatible rockchip,rk3588-vdec will be used, until we add the rockchip,rk3568-vdec in the driver's compatible for specific stuff
<chewitt>
sure, for now it's fine for testing
rgolledge2 has quit [Ping timeout: 256 seconds]
rgolledge has joined #linux-rockchip
paulk-bis has quit [Quit: WeeChat 3.0]
paulk has joined #linux-rockchip
paulk has joined #linux-rockchip
<chewitt>
diederik did you look at mpeg2 support also?
<chewitt>
this is being sw decoded
<CounterPillow>
that'd be done by the hantro stuff, should already be enabled on rk3566/rk3568
<CounterPillow>
unless hantro mpeg2 isn't a thing yet
<dsimic>
BTW, something is going on with Libera recently, there are reconnects and many netsplits
<Ermine>
is rkvdec relevant to rk3288 btw?
<CounterPillow>
Ermine: if anything, it uses rkvdec1 which is already supported upstream
<Ermine>
ah ok
<linkmauve>
Ermine, hmm, now that I have a correctly setup microSD, I press the “SPI recovery switch” button to skip Petitboot, then put the power on, and now I get a blinking cursor on a black screen.
<linkmauve>
The UART doesn’t give me anything, maybe because I have a three-pins one, which doesn’t provide the 3.3V it requires on the fourth.
<linkmauve>
But HDMI is working fine.
<linkmauve>
I don’t know if it’s u-boot or linux providing the blinking cursor though.
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #linux-rockchip
naoki has quit [Quit: naoki]
<chewitt>
I might be doing the connect/disconnect dance at the moment .. due to fibre damage in the red sea impacting middle-east routing
<dsimic>
ah, that explains it
vagrantc has joined #linux-rockchip
<Ermine>
happens
<Ermine>
linkmauve: try earlycon and enable logging in u-boot
erg_ has quit [Read error: Connection reset by peer]
rgolledge has quit [Quit: WeeChat 4.7.0]
psydroid3 has joined #linux-rockchip
<diederik>
chewitt: no I did not look at mpeg2. I think I pretty much only have x264 and x265 files
tlwoerner has quit [Read error: Connection reset by peer]
Hypfer has quit [Quit: Ping timeout (120 seconds)]
tlwoerner has joined #linux-rockchip
dsimic has quit [Ping timeout: 256 seconds]
Hypfer has joined #linux-rockchip
dsimic has joined #linux-rockchip
Hypfer has quit [Ping timeout: 256 seconds]
Hypfer has joined #linux-rockchip
tlwoerner has quit [Read error: Connection reset by peer]
stikonas has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
dsimic has quit [Remote host closed the connection]
dsimic has joined #linux-rockchip
godvino has quit [Ping timeout: 244 seconds]
clarity has quit [Ping timeout: 244 seconds]
urja has quit [Ping timeout: 244 seconds]
Dex_2x has quit [Ping timeout: 244 seconds]
clarity_ has joined #linux-rockchip
godvino has joined #linux-rockchip
Dex2x has joined #linux-rockchip
urja has joined #linux-rockchip
Net147 has joined #linux-rockchip
Net147 has quit [Changing host]
Net147 has joined #linux-rockchip
dsimic has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
dsimic has joined #linux-rockchip
s1b1_ has joined #linux-rockchip
Net147_ has quit [*.net *.split]
s1b1 has quit [*.net *.split]
Tartarus has quit [*.net *.split]
ungeskriptet has quit [*.net *.split]
tortoise has quit [*.net *.split]
adadad has quit [*.net *.split]
Tartarus has joined #linux-rockchip
adadad has joined #linux-rockchip
ungeskriptet has joined #linux-rockchip
tortoise has joined #linux-rockchip
<dsimic>
the issues with Libera seem to be getting much worse :/
<dsimic>
just had three reconnections in about an hour, and other people seem to be in same boat
<dsimic>
s/same/the same/
<dsimic>
at least my latest improvements to the irssi configuration ensure stable and correct nick for me :)
<dsimic>
before those improvements I experienced nick clashing and renaming due to the current issues, which is a totally new issue for Libera... it seems other people are getting that too now