franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
stikonas has joined #linux-rockchip
raster has joined #linux-rockchip
smaeul has joined #linux-rockchip
smaeul_ has quit [Ping timeout: 256 seconds]
stikonas has quit [Remote host closed the connection]
Tartarus has quit [Ping timeout: 244 seconds]
lvrp16 has quit [Ping timeout: 244 seconds]
mkorpershoek has quit [Ping timeout: 244 seconds]
FergusL7 has joined #linux-rockchip
FergusL has quit [Ping timeout: 244 seconds]
FergusL7 is now known as FergusL
lvrp16 has joined #linux-rockchip
mkorpershoek has joined #linux-rockchip
Tartarus has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
<walter>
Hello, quick question, what could have changed that I now need a logic level converter for UART, when in the past I was able to use my cheap USB serial device without a logic level converter and all worked well?
<walter>
All worked well for a while, and then suddenly, today, I've started seeing jibberish in UART, and the fix seems to have been to add a logic level converter in the mix. -- And I've tried with 3 different USB serial addapters, all worked in the past, now all show jibberish for most of the characters.
<walter>
I did mistakenly put TX to TX at one moment, instead of TX to RX, could that have changed something without actually realising magic smoke?
System_Error has quit [Ping timeout: 272 seconds]
<dsimic>
hmm... what was the voltage of the USB serial device that you used initially?
<walter>
dsimic: if I recall correctly, it was 3.3V.
chewitt has joined #linux-rockchip
<dsimic>
walter: what kind of a voltage level converter are you using now? maybe it actually eliminates some leakage current, which makes all work again
<walter>
It has some SOT-23 + 2 rezistors for each channel
<mmind00>
diederik: correct ... this needs to go through the nvmem tree ... and while I had contact with Srinivas about the qnap nvmem recently, not sure if the 2 things you mentioned are on their radar
<wens>
hmm, rebuilding the debian kernel image on my orange pi 5 plus seems to trip some thermal limit and reboot directly if I run with 8 parallel jobs
<mmind00>
I guess the series from kever should definitly be rebased+resend though
<wens>
it seems safe if I run only with 4 parallel jobs
<wens>
but the core temp is still getting up to 70+ degrees
<dsimic>
walter: maybe you could send some pictures?
<dsimic>
diederik: thanks for linking that series, I was trying to find it again recently
<mmind00>
diederik: oh, Kwiboo 's patch also is from march ... I'd resend in that case ... because 6 months of inbox is not every maintainers way to handle things :-)
<dsimic>
wens: what kind of cooling are you using?
<diederik>
yeah, they're quite old ... but it received various tags and no objections
<mmind00>
diederik: yep, so likely got overlooked somehow
<diederik>
mmind00: I saw you gave your Tested-by tag ... and I was wondering how I could test it (too)
<wens>
some metal case I got off taobao
<dsimic>
wens: huh, overheating should be quite unlikely in that case, because active cooling should be able to handle the load
<wens>
well it already rebooted a couple times :(
<dsimic>
wens: does the fan ramp up when the CPU temperature increases?
<wens>
and it seems to be some hardware trigger
<wens>
dsimic: no, it's fixed 5v. and as I said it's tiny
<mmind00>
diederik: somewhere in sysfs (always can't remember where exactly) nvmem devices show their whole content ... so my testing for Kwiboo 's patch was just making sure that content is the same before and after the patch :-)
<diederik>
wens: I have no such problems on my Rock 5B. The SoC does get quite warm (even without doing anything it's above 50C) but I guess it just throtles when it gets too warm? No cooling solution whatsoever here (but also not in a case yet)
<walter>
It work perfectly since I've added the logic converter. Without it, about 30% of the characters are jibberish.
<dsimic>
wens: I'm not aware of any hardware triggers, all the thermals are handled in software
<wens>
/sys/bus/nvmem/xxx/nvmem ?
<wens>
dsimic: perhaps its the pmic?
<dsimic>
wens: ah, so the fan isn't handled by the board itself?
<diederik>
mmind00: ok, thanks. I'll go look for it :)
<wens>
dsimic: it's a two pin fan connected to 5v directly on the board. no pwm
<wens>
hmm, I suppose the other possibility is that the power supply isn't powerful enough
<dsimic>
wens: I'm now starting to wonder do you have CPU thermal throttling in place?
<dsimic>
it could be that the PSU is insufficient for the load
<wens>
that's my next question. the thermal trip point for CPU thermal throttling is 85 degrees. Maybe its too high?
<dsimic>
it should be fine, and you can try lowering it by hand through /sys
<dsimic>
the PMIC only handles the thermal runaways as indicated by software, but it does nothing on its own
<diederik>
On my q64a I have /sys/bus/nvmem/ and /sys/bus/nvmem-layout and both contain the same named dirs and files ...
<dsimic>
walter: let me check out that level shifter...
<dsimic>
walter: what voltage is it currently converting to and from? I'm inclined to the explanation that the shifter is actually eliminating some leakage current coming from the USB UART adapter, which perhaps was present before and has gradually damaged the SoC a bit, to the point where it no longer works that way
<diederik>
mmind00: looks like Kever's patch depends on Kwiboo's
<dsimic>
diederik: it does :)
<mmind00>
diederik: so I guess both should be "just" combined into one series, re-tested/rebased and sent anew ... which I guess would need way less words to explain, than to bind the two original ones together 6 months after :-)
<diederik>
mmind00: that sounds sensible/practical :)
<mmind00>
"practical" is my middle name :-D
<walter>
I went with 5V on the USB serial adapter side, and 3.3V from pin 17 of the Radxa Rock Pi 4B+.
<diederik>
haha :-D
<walter>
I now tried 3.3V on both sides, and it works. so onlyu a dirrect connection doesn't work.
<diederik>
on my q64-a with kernel 6.16, /sys/bus/nvmem/devices is empty and so it .../drivers and (therefore?) the nvmem and nvmem-layout dirs under /sys/bus are the same ...
dsimic has quit [Ping timeout: 245 seconds]
<chewitt>
Afternoon all
<chewitt>
I'm trying to play with a Rock4D (3576)
dsimic has joined #linux-rockchip
<chewitt>
It boots, runs for 30-secs, then wedges with no visible output
<chewitt>
u-boot 2025.10-rc3 with a load of Kwiboo patches or u-boot 2025.07 with a smaller set (and previously working on the board)
<chewitt>
kernel is 6.17-rc6 with a large patchset, but no issues with that on a bunch of 3588 boards (different SoC, I know)
<chewitt>
any known issues that sound familiar?
<chewitt>
I boot into LibreELEC, can navigate around and do things .. until it freezes
<chewitt>
stopping Kodi from running doesn't change anything .. which points towards something lower in the stack
franoosh has quit [Remote host closed the connection]
<Kwiboo>
mmind00, diederik: I can probably re-send my + Kever's otp patches together with pending rk3528 otp patches in a new/updated series later today/tomorrow, mostly only Kever's dt-bindings patch that needs to be fixed, already have a possible fixup in my rk3528 tree at https://github.com/Kwiboo/linux-rockchip/commits/next-20250910-rk3528/
<chewitt>
sre thanks! .. that sounds highly plausible
<walter>
Hello, does anyone know if the opensource rkdeveloptool knows how to deal with secure boot enabled boards? I'm in MaskROM and try to download a bootloader that has usbplug and I assume is signed, but it hangs, just like in the case of unsigned loaders that I generate from rkbin.
<walter>
does anyone know what's the difference between a signed loader (the one with usbplug) and an unsigned one? I have received one that is old and we assume is signed, but the difference between it and a newly generated one is just 9 bytes, 5 near the start and 4 at the end of the file.
<chewitt>
Kwiboo is the "mem=3838M" that LE uses in boot params for RK images still required?
necessarypinch9 has joined #linux-rockchip
necessarypinch has quit [Read error: Connection reset by peer]
necessarypinch9 is now known as necessarypinch
naoki has quit [Quit: naoki]
raster has joined #linux-rockchip
franoosh has joined #linux-rockchip
helene has quit [Ping timeout: 248 seconds]
mmind00 has quit [Ping timeout: 248 seconds]
raster has quit [Ping timeout: 248 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
_whitelogger_ has joined #linux-rockchip
_whitelogger has quit [*.net *.split]
lorenzb has quit [*.net *.split]
lorenzb has joined #linux-rockchip
mmind00_ is now known as mmind00
mmind00 has quit [Quit: mmind00]
mmind00 has joined #linux-rockchip
<Kwiboo>
chewitt: there was issues importing hw decoded video buffers into drm plane due to "swiotlb buffer is full", limiting to only use 32-bit addressable memory was an easy workaround ;-), not sure it is still needed
<chewitt>
[ 1019.489641] rockchip-drm display-subsystem: swiotlb buffer is full (sz: 372736 bytes), total 32768 (slots), used 5362 (slots)
<chewitt>
[ 1019.489928] failed to map scatterlist
<chewitt>
that kind of thing?
<chewitt>
I see that on RK3576 but not RK3588
<Kwiboo>
yes, that sort of issues
<chewitt>
[ 946.708852] => 3292 free of 16384 total pages
<chewitt>
[ 946.710052] cma: number of available pages:
<chewitt>
^ that's the preceeding log spam, before the swiotlb starts
<Kwiboo>
however that commit cause issues for rk3288, so I abandoned it...
<chewitt>
I haven't done much with 3566/3568 .. need to unpack the Rock3C and see if that's the same
<chewitt>
odd that I don't see the issue with 3588 .. same kernel config and patchset
<Kwiboo>
since RK3576 start of DRAM start at 0x40000000, you may need to limit to around 3 gib mem instead of close to 3 gb
<Kwiboo>
4 gb*
<Kwiboo>
1 gb less than rk3588, or possible exactly 3 GiB should probably work, try to see the Zone ranges: for DMA/DMA32/Normal, nothing should be above 32-bit address
franoosh has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
<chewitt>
mem=3072M seems to avoid it and also makes playback smooth
<chewitt>
it was dropping frames before, presumably due to not being able to read/write them properly (or something like that)
raster- has quit [Quit: Gettin' stinky!]
<mmind00>
I think there was a patch around a while ago where Andy(?) from Rockchip wanted to limit dma addressing for the vop in some way ... but that was not the right solution
<mmind00>
i.e. I see this thing on rk3588 board with more than 4G of ram too
System_Error has joined #linux-rockchip
raster has joined #linux-rockchip
detlevc87 has joined #linux-rockchip
smaeul_ has joined #linux-rockchip
Dex_2x has joined #linux-rockchip
rtp_ has joined #linux-rockchip
phh|new has joined #linux-rockchip
smaeul has quit [Read error: Connection reset by peer]
<Kwiboo>
main issue with switching to core dma fops was that it also removed support for iommu with multi vop, so probably not correct way to go about it :-)
ldevulder has quit [Quit: Leaving]
wens has quit [Quit: leaving]
wens has joined #linux-rockchip
sL1pKn07 has quit [Quit: Client Excited...]
sL1pKn07 has joined #linux-rockchip
norris_ has joined #linux-rockchip
leming has quit [*.net *.split]
norris has quit [*.net *.split]
norris_ is now known as norris
chewitt has quit [Quit: Zzz..]
leming has joined #linux-rockchip
lorenzb has quit [*.net *.split]
lorenzb has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
lorenzb has quit [*.net *.split]
_whitelogger_ has quit [*.net *.split]
Tartarus has quit [*.net *.split]
walter has quit [*.net *.split]
anarsoul has quit [*.net *.split]
dliviu has quit [*.net *.split]
qschulz has quit [*.net *.split]
ungeskriptet has quit [*.net *.split]
Emantor has quit [*.net *.split]
urja has quit [*.net *.split]
tortoise has quit [*.net *.split]
darfo has quit [*.net *.split]
paulk-bis has quit [*.net *.split]
kbingham has quit [*.net *.split]
adadad has quit [*.net *.split]
clarity has quit [*.net *.split]
Emantor_ is now known as Emantor
_walter_32 is now known as walter
walter has quit [Quit: Konversation terminated!]
walter has joined #linux-rockchip
clarity has joined #linux-rockchip
Tartarus has joined #linux-rockchip
adadad has joined #linux-rockchip
ungeskriptet has joined #linux-rockchip
paulk-bis has joined #linux-rockchip
dliviu has joined #linux-rockchip
tortoise has joined #linux-rockchip
urja has joined #linux-rockchip
lorenzb has joined #linux-rockchip
walter has quit [Ping timeout: 260 seconds]
<dsimic>
> I went with 5V on the USB serial adapter side, and 3.3V from pin 17 of the Radxa Rock Pi 4B+.
<dsimic>
> I now tried 3.3V on both sides, and it works. so onlyu a dirrect connection doesn't work.
<dsimic>
huh, walter just quit :/
raster has quit [Quit: Gettin' stinky!]
clarity has quit [Quit: Reconnecting]
clarity has joined #linux-rockchip
stikonas has joined #linux-rockchip
cbeznea has quit [Ping timeout: 250 seconds]
<helene>
they might rely on logs later (or at least that's the kind of thing i'd like to imagine) :)
<dsimic>
perhaps, but I'll wait for walter to appear again :)
System_Error has quit [Remote host closed the connection]
<Ermine>
iirc there were problems with Rockchip IOMMUs being unable to address more than 4G of RAM
System_Error has joined #linux-rockchip
<helene>
i believe i still encounter than on my cm3588 board with the SDMMC devices, but i have an "old" kernel at this point, so it might just be fixed now