mmind00 changed the topic of #linux-rockchip to: Rockchip development discussion | public log at https://libera.irclog.whitequark.org/linux-rockchip
stikonas has quit [Remote host closed the connection]
hexdump0815 has quit [Ping timeout: 265 seconds]
hexdump0815 has joined #linux-rockchip
serdarth_ has joined #linux-rockchip
serdarth has quit [Ping timeout: 272 seconds]
serdarth_ is now known as serdarth
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
ungeskriptet is now known as Guest4242
Guest4242 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
kevery1 has quit [Ping timeout: 252 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
warpme 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 [Ping timeout: 276 seconds]
kevery1 is now known as kevery
ldevulder has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
raster has joined #linux-rockchip
cp-- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #linux-rockchip
<qschulz> naoki: no product page yet for rock-5t?
<naoki> qschulz: yes...
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
warpme has joined #linux-rockchip
<qschulz> beeble: got a DRAM init issue even when rebooting very early in TPL, in the second TPL boot (after the one that forcefully reset it)
Danct12 has quit [Quit: ZNC 1.9.1 - https://znc.in]
Danct12 has joined #linux-rockchip
asriel has joined #linux-rockchip
asriel has quit [Client Quit]
asriel has joined #linux-rockchip
<mmind00> qschulz: currious question, what happens when you reboot in TPL on such DDR init failures? ... trying to find out if the issue persists (= controller config thing) or does it go away (= some timing thing)
<qschulz> mmind00: wdym?
<qschulz> it's stuck
<qschulz> so not sure how I would be able to reboot?
<mmind00> qschulz: ah, so it is fully stuck
<mmind00> qschulz: was remembering from last week there being some ddr-init-fail message ... so was somehow assuming the TPL was still running somewhat
<qschulz> mmind00: apparently, stuck on purpose!
<qschulz> while(1) in there
<mmind00> qschulz: issue a reboot from there? Before entering that loop?
<qschulz> yeah, can do that
<mmind00> I.e. not meant as a permanent thing, just to find out of the issue persists to the next try
System_Error has quit [*.net *.split]
System_Error has joined #linux-rockchip
Stat_headcrabbed has joined #linux-rockchip
<helene> hi! i've been getting a lot of "swiotlb buffer is full" messages coming from dwmmc_rockchip on rk3588, is there no smmu/iommu for mmc?
<qschulz> what are supposed to do if the DRAM init fails?
<helene> i know there's one for the GPU but i'm surprised about this one
<qschulz> board_init_f seems to not care?
<dsimic> qschulz: naoki: huh, what's ROCK 5T? :)
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mripard has joined #linux-rockchip
warpme has joined #linux-rockchip
<Kwiboo> qschulz: maybe reset to maskrom could be an option? played around with reset to maskrom at hang() in https://patchwork.ozlabs.org/project/uboot/patch/20240202001221.531207-1-jonas@kwiboo.se/
<Kwiboo> helene: could be that gpu/drm driver is using too much from swiotlb and that is causing issues for other devices?, rk drm driver and the custom rk drm gem code was causing swiotlb issues for me some time ago: see https://lore.kernel.org/linux-rockchip/4c2ebf98-7c0b-418a-a9de-ebe54acd21af@kwiboo.se/
<helene> Kwiboo: possible... though I'm using this headless, so... (maybe I have something to turn off?)
<helene> i'm not getting any warnings from rockchip-drm in my dmesg (in fact, rockchip-drm complains that it can't find an available VOP)
<helene> i have two nvme SSDs that each use 32MiB of host memory, but i feel like memory should still be plentiful under the 4GiB boundary...
<qschulz> Kwiboo: i would see that maskrom/hang thingy more of a debug thing especially since it doesn't "fix" anything
<Kwiboo> when I played around I ended up limiting ram to ~4gb with `mem=3838M` at cmdline to work around my issue :-D, not ideal
<qschulz> Kwiboo: for context, I have a misbehaving RK3399 Puma that sometimes fails DRAM init
<qschulz> we have a PMIC reset line that we toggle when rebooting
<qschulz> but only in SPL, so after the TPL has failed to init the DRAM
<qschulz> so I thought I should just move that code before the DRAM init, but it still fails
<qschulz> and now I figured that my specific error is calling while(1); in the sdram driver
<qschulz> and if we were to use panic() instead, the board would reboot on its own
<qschulz> which is IMO better than just getting stuck forever
<helene> Kwiboo: i'm looking a bit closer now and it's quite suspicious; I have 8GiB of RAM total on the board (CM3588), u-boot detects 8GiB, Linux only has 5.5GiB total recognised
<qschulz> Kwiboo: what's the U-Boot veorsion you're using?
<qschulz> helene: ^
<helene> qschulz: U-Boot 2024.10-rc2-00058-g7bc9005b9750 so I would presume it is if it was merged for 2024.10-rc2
<qschulz> yeah ok, that commit has been merged for a while already
<qschulz> helene: no patch of yours I assume for U-Boot?
<helene> i didn't add any patches, no
<qschulz> helene: maybe look into the reserved-memory nodes in the DT in Linux
<qschulz> and try to figure out if U-Boot is patching the FDT it passes to Linux and if yes, what makes this happen
<helene> i don't seem to have any reserved-memory nodes under /proc/device-tree (but maybe i'm looking at it the wrong way)
<helene> u-boot is clearly patching the FDT as i can see /chosen/u-boot,version however
<qschulz> yeah it's required anyway, e.g. for inserting the reserved memory area for TF-A/OP-TEE OS for example
<helene> i do see reserved regions under /proc/iomem but it's not clear as to whether those are reserved for kernel purposes or by the DT
<helene> here's my iomem: https://brpaste.xyz/O9DQLw/raw
<helene> welp, removing the swiotlb kernel parameter restored my memory, so it was taken by the kernel... but it still complained about a full buffer with so much ram given to it!
dsimic has quit [Ping timeout: 246 seconds]
Stat_headcrabbed has joined #linux-rockchip
dsimic has joined #linux-rockchip
eballetbo has joined #linux-rockchip
<Kwiboo> qschulz: re dram init, noticed https://github.com/rockchip-linux/u-boot/commit/e1652d3918b182e107addd5e6f451655f239efbc and "capacity detection anomalies" in rkbin release notes in the push from last week, a related issue?
<qschulz> Kwiboo: interesting, because we have capacity detection issues on our PX30, sometimes it shows 1.5GiB sometimes 2GiB
<qschulz> but I don't think we actually got any capacity issue on RK3399, only that sometimes the DRAM init fails
<qschulz> mmind00: swapped while(1) with panic() in the SDRAM driver and it seems to be happy
<qschulz> got one fail but it recovered nicely
ldevulder has quit [Quit: Leaving]
<mmind00> qschulz: so, some timing thing?
* qschulz shrugs
<qschulz> but I assume
rah has joined #linux-rockchip
<qschulz> since this is after I toggle the hard reset of the PMIC
<rah> I have a Firefly ROC-3399-PC Plus board which displays nothing at all over the serial port if I boot without an SD card inserted. Apparently the board has eMMC flash which I presume is empty. (How) can I prepare and flash an image to the eMMC without using proprietary tools noted by the Firefly wiki? https://wiki.t-firefly.com/en/ROC-RK3399-PC-PLUS/loader_mode.html
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz> rah: you can use rkdeveloptool for that (or rockusb from Collabora)
<qschulz> you need to upload the USB loader first (db for rkdeveloptool, download-boot for rockusb)
<qschulz> then you can flash with wl 0 (if you want to flash at offset 0) for rkdeveloptool or write-image for rockusb
vagrantc has joined #linux-rockchip
<qschulz> Kwiboo: let's see if it fixes anything on my RK3399 (I doubt, but I really should test that on PX30, but it was really difficult to reproduce :/)
<Kwiboo> hehe, I can imagine that being a difficult issue to reproduce, I mostly just noticed lots of ddr init blobs being updated with a similar change entry in release notes and then that commit when peeking that latest push
<Kwiboo> https://github.com/rockchip-linux/u-boot/compare/d44623ab9f98...5de689627e81/ may also be interesting for mainline rk3588
<rah> qschulz: where does the binary loaded with "db" come from?
<rah> is it proprietary
<rah> ?
<qschulz> rah: c.f. instructions in the u-boot docs
<qschulz> rah: the one we use is proprietary, but I believe collabora generates their own
<qschulz> boot_merger is a blob also, but you can find the sources that should work for RK3399 in Rockchip's U-Boot fork
<rah> ooof
<rah> thanks
<qschulz> No sources for rk3588 though
<qschulz> i wanted to generate this USB image with buildman in U-Boot upstream but haven't had the time to look at it so far :/
<Kwiboo> https://github.com/xboot/xrock also have some tools for bootrom usb mode
<Kwiboo> qschulz: agree, would be really nice to have some sort of rkloader support in upstream mkimage or similar
<qschulz> Kwiboo: what I'm a bit pissed about is that Rockchip stopped updating the boot_merger sources in the U-Boot git repo
<qschulz> so no support for RK35xx
System_Error has quit [Remote host closed the connection]
mripard has quit [Quit: WeeChat 4.4.2]
<Kwiboo> yeah, that is a real bummer, a few weeks back I played around with adding idb v2 signing to rkimage: https://github.com/Kwiboo/u-boot-rockchip/commit/cb2827f096975a4aa255c3c6915b4fe6f58824af, and can remember it was really hard trying to find information about the expected format
<qschulz> Kwiboo: is that for secureboot?
<Kwiboo> yeah for secureboot, signing seem to work and generate similar result as other tools, but no idea if I want to take it any further
<qschulz> why not?
<Kwiboo> hehe, working with certificates and private keys was anoying, possible I also took some shortcuts and used deprecated openssl functions, so cleanup is needed and docs on how to use etc, alos I already have lots of other areas I want/should focus my time on :-)
<qschulz> Kwiboo: some sort of docs would be very nice, and then someone can take this over if desired :)
<qschulz> could post as an RFC and saying you don't plan on continuing for now but putting out there if anyone wants to have a shot at it
<qschulz> (but thanks for the link, at least it's out there :) )
<Kwiboo> hehe, yeah, will see what I can do, did not find my command history at first but was able to find it now: https://gist.github.com/Kwiboo/6847d4c83ad768bacf47a162f99a24e2 or similar was what I was playing around with
<qschulz> ah so we still have this rk_sign_tool blob we need to use I guess
<Kwiboo> not needed but was using that to compare and validate result
<qschulz> ah that's cool
<Kwiboo> I think https://lore.kernel.org/u-boot/20240916082446.32082-1-al.kochet@gmail.com/ originally triggered me to explore full secure boot ;-), however burning signing cert in OTP would still require rk tools/blobs
raster has quit [Quit: Gettin' stinky!]
<Kwiboo> having signing of FIT does not seem that useful without also having a signed TPL+SPL, else current sha256 checksum provide similar good enough validation in my mind, but I may be missing something
<qschulz> Kwiboo: I agree, your root of trust is as weak as any element in it
<qschulz> so being to replace the bootloader...
<qschulz> being able*
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
macromorgan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
macromorgan has joined #linux-rockchip
System_Error has joined #linux-rockchip
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
digetx has quit [Ping timeout: 252 seconds]
digetx has joined #linux-rockchip
psydroid has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
psydroid has joined #linux-rockchip
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
<naoki> oh rk3588 dsi...
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip