<naoki>
Kwiboo: May I use "FIT at 2MiB and U-Boot proper at 8MiB" change from your ramboot branch?
<naoki>
^for my DFU in SPL
psydroid has quit [Ping timeout: 252 seconds]
<naoki>
oops, it doesn't work with "rockchip: ROCKCHIP_COMMON_STACK_ADDR improvements"...
psydroid has joined #linux-rockchip
stikonas has quit [Quit: Konversation terminated!]
lvrp16 has quit [Ping timeout: 248 seconds]
lvrp16 has joined #linux-rockchip
repk has quit [Ping timeout: 248 seconds]
repk has joined #linux-rockchip
linkmauve has quit [Ping timeout: 248 seconds]
hexdump0815 has quit [Ping timeout: 265 seconds]
hexdump0815 has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
hexdump0815 has quit [Ping timeout: 265 seconds]
Daanct12 has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
hexdump0815 has joined #linux-rockchip
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
franoosh has joined #linux-rockchip
ldevulder has joined #linux-rockchip
raster has joined #linux-rockchip
naoki has quit [Quit: naoki]
naoki1 has joined #linux-rockchip
naoki1 is now known as naoki
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 248 seconds]
kevery1 is now known as kevery
eballetbo has joined #linux-rockchip
System_Error has quit [Ping timeout: 264 seconds]
System_Error has joined #linux-rockchip
linkmauve has joined #linux-rockchip
paulk-bis has quit [Quit: WeeChat 3.0]
paulk has joined #linux-rockchip
<Kwiboo>
naoki: yes, I pushed an updated version at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3xxx-2025.04 before I went to sleep, did not manage to get the ramboot out before that, want to test on an older armv7 soc before I send it out, should probably hit ML later today :-)
<naoki>
Maybe I should check with older SoCs too. I'm sure there's a Radxa ROCK (RK3188) and a ROCK2 (RK3288) somewhere. ;)
<diederik>
naoki: Please document the *why* in your patch descriptions (like Kwiboo did)
<naoki>
hmm
<diederik>
What you put in the series cover letter does NOT get commited to git (and each commit should describe why that's an improvement)
<Kwiboo>
naoki: ahh, you already sent it out, will take a look later, yesterday I spent too much time trying to unbrick my rk3228a box that I managed to brick just 1-2 hours after it arrived the other day :-)
<naoki>
I once bricked something within minutes of opening the box...
<wens>
at least it didn't go up in a puff of smoke ...
paulk has quit [Ping timeout: 268 seconds]
paulk has joined #linux-rockchip
paulk has joined #linux-rockchip
sfo has quit [Remote host closed the connection]
fleg has quit [Write error: Broken pipe]
<Kwiboo>
hehe, my box did make some funny noises when I tried to ground different pins/resistors, but the box seem to have survived my trail-and-error and I finally got it to go to maskrom mode
<Kwiboo>
at least I finally have a rockchip soc that pre-dates the rk3288 :-)
<dsimic>
the collection is now complete :)
<robmur01>
Nah, 3228 is still newer than 3288 - older is the Cortex-A9 stuff ;)
<maz>
PL310 FTW!
sfo has joined #linux-rockchip
fleg has joined #linux-rockchip
franoosh has joined #linux-rockchip
naoki has quit [Ping timeout: 252 seconds]
<Kwiboo>
robmur01: hehe, true, more correct may have been to say it is my first older rk soc using cortex-a7 :-)
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
<tlwoerner>
dsimic: thanks for the review. interestingly enough i did notice the exact same discrepancy that you mention in your comments
<tlwoerner>
however, since the rk3328 table was obviously using 4096-<table value> i simply continued with the same pattern
psydroid2 has joined #linux-rockchip
psydroid2 has quit [Excess Flood]
<dsimic>
tlwoerner: anytime... yes, something strange is going on, and I suspect one of the TRMs to be wrong
<dsimic>
because 1024 as the "offset" value is simply too small... we'll see, I'll do some more testing, and the patch is fine in the meantime
<dsimic>
qschulz: Kwiboo: tlwoerner: good news, Radxa responed with "just send the list of boards you need"... woohoo! :)
* qschulz
prepares his shopping list
<tlwoerner>
dsimic: nice!
<tlwoerner>
speaking of Radxa... when yocto switched from the 6.6.y kernel to the 6.12.x kernel, i lost PCIe on my rock-pi-4a
<tlwoerner>
i have the radxa penta-sata hat on a rock-pi-4a and it stopped working with the update
<dsimic>
tlwoerner: I saw people complaining about that, and I tried going through the offending patches a few times, to no avail
<dsimic>
any chances, please, to send a complete kernel log from the Penta-hat-equipped board when it has no PCIe working?
<tlwoerner>
someone else reported something similar on the mailing list in Jan also with an rk3399-based device, but that fix was specific to the dts of their specific device (rk3399-gru-chromebook)
<qschulz>
tlwoerner: yeah that was a mistake when renaming DT nodes IIRC
<dsimic>
yes, I saw that back then
<tlwoerner>
okay, i'll grab a log at some point. it's my only setup, and it's a "production" device
<dsimic>
qschulz: I'm so happy that I'll get the boards needed for the SoC binning project... and of course, for the RK3308 thermal stuff :)
<tlwoerner>
dsimic: my point being, ask for a penta-sata hat too! :-)
<dsimic>
tlwoerner: I see, we'll need that log to be able to investigate further
<tlwoerner>
(so you can test PCIe stuff)
<dsimic>
tlwoerner: hmm, not a bad idea at all... maybe not a Penta hat, but an M.2 extender hat, which is smaller but good enough for testing
naoki has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.5.1]
naoki has quit [Client Quit]
raster has quit [Quit: Gettin' stinky!]
<Kwiboo>
does rk3399 also have pcie issue on longterm kernel?, I do know that rk356x has broken pcie, sata and usb3 on v6.1.123+, v6.6.69+ and v6.12.8+, but that combphy issue should not affect rk3399
<qschulz>
Kwiboo: as far as I've been told PCIe is simply broken inside RK3399 silicon, only PCIe gen1 is stable., Don't know how much of that is truth though
<jakllsch>
i mean, it's got quirks, but it's not broken..
<jakllsch>
oh, i guess it was broken for a few kernel versions..
<robmur01>
we should really be better at differentiating "kernel version" and "DTB version"... :P
<Kwiboo>
qschulz: look like rk3399-gru still is a little bit broken in torvalds tree after regulator node rename, I can still see aliases being added to the empty pp3300 node name, other boards was also affected of same or different issue?
<qschulz>
Kwiboo: "aliases being added to the empty pp3300 node name"?
<qschulz>
(I only followed from far, I sadly don't have much time to spend on kernel dev aside from DT stuff for our products :/)
<qschulz>
Kwiboo: rc2 released in U-Boot... wondering if we have time to wait for this patch to land in devicetree-rebasing or if we need to go the hackish way and fix it with /delete-node/ in rk3399-whatever-u-boot.dtsi
<Kwiboo>
not fully sure the impact, but at least one of those labels not pointing to a 1v8 regulator are used for io-domain, so io-domain driver in u-boot may no longer change io-domain voltage
<mmind00>
qschulz: with the amount of "interesting" fixes in that branch, and the two still on the list, I guess I'll do a tag+pull to armsoc this week ... in in master some time next week maybe?
<qschulz>
mmind00: ok that'd work out for U-Boot 2025.04 then :)
<tlwoerner>
wrt PCIe: yes, gru got fixed, but rock-pi-4a is still broken on the 6.12.11 kernel. 6.6.74 works for me
<qschulz>
tlwoerner: would help tremendously if you can do a git bisect I guess
<qschulz>
but that's "a few" commits to bisect :)
<tlwoerner>
my painfully slow build machine is still churning out a 6.12.y build for me :-)
<qschulz>
tlwoerner: is there any change in DT between 6.6.74 and 6.12.11?
<tlwoerner>
bisecting along 2 separate branches is not easy (or sometimes not possible?)
<qschulz>
decompile the DT from both and diff them to check
<tlwoerner>
qschulz: yes, lots, everywhere
<qschulz>
tlwoerner: oof :/
<qschulz>
tlwoerner: let git bisect figure things out for you?
<tlwoerner>
i'll try bisecting. good thing i got rauc working :-)
<qschulz>
Another test could be to use 6.6 DT with 6.12 kernel
<tlwoerner>
okay, i can try that
<qschulz>
this is something that we should actively support
<qschulz>
if not, then we need to fix it anyway
<qschulz>
but at least it could indicate it's not necessarily a driver issue
<tlwoerner>
qschulz: by the way, any comment on the meta-rockchip patch to add Jonas' therm monitoring for rk3308?
<qschulz>
tlwoerner: yes, don't :D ?
<tlwoerner>
no prob. i can carry it in my project-specific layers
<qschulz>
At least have some patch sent upstream instead of just "pending"
<qschulz>
but I don't think it's any hackier than when we had a linux-next recipe
<qschulz>
so up to you
<qschulz>
tlwoerner: BTW, I had a quick look at using this ddrbin_tool.py and I'm hesitating on the implementation a bit
<qschulz>
The script takes a conf file as input
<qschulz>
I can either have bitbake variables and generate the conf file myself
<qschulz>
very bitbakey, i like it, but limits what you can put in this conf file (and there are MANY options)
<qschulz>
also kinda user-friendly
<qschulz>
the other option is rely on the user passing a conf file (via SRC_URI)
<qschulz>
this I like because I have nothing to do except calling the script on it
<tlwoerner>
support both workflows?
<qschulz>
oof
<qschulz>
what happens if I have a file AND a variable that conflict?
<tlwoerner>
they yocto kernel tooling allows users to use the in-kernel defconfigs or specify their own
<tlwoerner>
if the user says "used the in-kernel" but also provides a SRC_URI:defconfig it warns and uses the ... defconfig (?i think?)
<qschulz>
yeah but they are all pointing at a defconfig
<tlwoerner>
in any case, implement the one you like best
<qschulz>
we don't autogenerate the defconfig based on some variable
<tlwoerner>
something is better than nothing
<qschulz>
e.g. we don't have KERNEL_WIFI ?= "1" means I enable all the wifi drivers in defconfig
<qschulz>
yeah, and we can always extend it later on, or simplify it
<tlwoerner>
yep
<qschulz>
let's do instead of think eh
<qschulz>
or rather "overthink"
<qschulz>
thinking is nice, overthinking not
<tlwoerner>
it's a balance
<qschulz>
and my brain clearly doesn't agree with that :D
raster has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
franoosh has joined #linux-rockchip
<tlwoerner>
ooh, the pcie driver is crashing during probe on my 6.12.11 kernel