cedarwhitfield__ has quit [Remote host closed the connection]
cedarwhitfield__ has joined #u-boot
sszy has joined #u-boot
gsz has quit [Ping timeout: 260 seconds]
gsz has joined #u-boot
mripard has joined #u-boot
AshyPinguin has quit [Ping timeout: 247 seconds]
Stat_headcrabbed has quit [Remote host closed the connection]
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #u-boot
prabhakalad has joined #u-boot
gsz has quit [Ping timeout: 260 seconds]
ldevulder has quit [Quit: Leaving]
gsz has joined #u-boot
Guest56 has joined #u-boot
kcxt has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Guest56 has quit [Quit: Client closed]
gsz has quit [Ping timeout: 241 seconds]
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Client Quit]
gsz has joined #u-boot
Hobbes` has quit [Remote host closed the connection]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
gsz has quit [Ping timeout: 255 seconds]
AshyPinguin has joined #u-boot
gsz has joined #u-boot
gsz has quit [Ping timeout: 255 seconds]
Stat_headcrabbed has joined #u-boot
cedarwhitfield__ has quit [Remote host closed the connection]
cedarwhitfield__ has joined #u-boot
niska has quit [Ping timeout: 258 seconds]
gsz has joined #u-boot
glaroque has quit [Quit: Connection closed for inactivity]
niska has joined #u-boot
riabenko has joined #u-boot
<dgilmore>
I am prepping some patches to add a rockchip board. and I am a bit confused about handling the dtb, the board landed in linux 7.3 what exactly do I need to do to ensure that dtb is there?
<qschulz>
specifically the pick part (you're not allowed to pull, only Tom is)
<qschulz>
I'm not sure if we are going to pull 7.3 for 2027.01 as it'll be released after we enter our -rc1 I believe
<qschulz>
so waiting for Tom to do the pull might be asking a bit much :)
mtoy has quit [Ping timeout: 251 seconds]
memset_ has joined #u-boot
memset has quit [Remote host closed the connection]
cbmuser has quit [Quit: WeeChat 4.6.3]
mtoy has joined #u-boot
<Tartarus>
But probably not too much after? I guess it's more or less 5 weeks out
<Tartarus>
(v7.3 itself)
<mps>
i bet it will be in 3-4 weeks
<mps>
though late
gsz has quit [Ping timeout: 241 seconds]
<dgilmore>
I think mps is right on 7.3
<Tartarus>
Alright. 7.1 and 7.2 both had -rc7 and v7.3-rc5 was this past Sunday, was my counting.
<Tartarus>
Regardless, yes, I expect to grab v7.3-dts when it's available, for our v2027.01
<dgilmore>
cool, so I should just leave the dts out and note that it depends on 7.3?
mtoy has quit [Ping timeout: 269 seconds]
gsz has joined #u-boot
memset_ has quit [Remote host closed the connection]
mtoy has joined #u-boot
memset has joined #u-boot
mtoy has quit [Ping timeout: 242 seconds]
<mkorpershoek>
dgilmore: I think that's stated in the doc that qschulz shared
<mkorpershoek>
If you need any of the dt patches that are in 7.3 for your series, you pick them
<mkorpershoek>
> If required, it is also possible to cherry-pick fixes from the devicetree-rebasing repository prior to next sync, usage:
<mkorpershoek>
Does that answers the question?
goliath has joined #u-boot
<qschulz>
dgilmore: you can send patches and write in the cover letter that it depends on a 7.3 sync, I'll not merge before that happens (and I hope to not forget once we have the 7.3 sync :) )
<qschulz>
but you could also just send the patches right now, with patches from devicetree-rebasing which you apply with tools/update-subtree.sh pick <hash>
<qschulz>
and that'll be fine with me too
<qschulz>
then we don't have to wait on Tom
sigmaris_ has joined #u-boot
sigmaris has quit [Ping timeout: 246 seconds]
sigmaris_ is now known as sigmaris
<dgilmore>
cheers, I will work on finishing them up.
<dgilmore>
I hit a bug in the PCIe stack that I have a fix for, as well as some unrelated fixes I did in debugging the hang I hit
memset has quit [Remote host closed the connection]
cedarwhitfield__ has quit [Remote host closed the connection]
cedarwhitfield__ has joined #u-boot
<Kwiboo>
dgilmore: regarding pcie hang on rockchip, you typically must ensure pinctrl is correct for the reset-gpios, the pin must be in gpio func mode or there may be a hang. U-Boot enforces the pin func accordring to DT, Linux is less strict and will change to gpio func when pin is requested
memset has quit [Remote host closed the connection]
<Kwiboo>
the -u-boot.dtsi DT overrides to correct pcie reset pinctrl where later submitted and applied to Linux
<Kwiboo>
now most rockchip boards typically have correct gpio func for pcie in dts/upstream
<dgilmore>
I will take a look. An Issue I see is that the dtb provided by u-boot should work in Linux
cedarwhitfield__ has quit [Remote host closed the connection]
cedarwhitfield__ has joined #u-boot
<Kwiboo>
dgilmore: basic conclusion of that thread was that device tree in linux should be fixed to describe expected pinctrl for the pcie reset pin, i.e. gpio func when the reset-gpios prop is used, and not to implicitly change to gpio func
gsz has quit [Ping timeout: 268 seconds]
memset has quit [Remote host closed the connection]
memset has joined #u-boot
mmu_man has joined #u-boot
<shadow>
dgilmore: for an example of using OF_UPSTREAM look at the 'starfive_visionfive2_defconfig'
<shadow>
it is a somewhat more complex example, so it covers (I think?) more of the questions you might potentially have
memset has quit [Remote host closed the connection]
memset has joined #u-boot
gsz has joined #u-boot
npcomp has quit [Ping timeout: 244 seconds]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
memset_ has joined #u-boot
memset has quit [Remote host closed the connection]
draemon has quit [Read error: Connection reset by peer]
<shadow>
dlan: should the PLL tables fix for K3 in Linux have appeared in Greg's stable updates to 7.2 ?
cedarwhitfield__ has quit [Remote host closed the connection]
cedarwhitfield__ has joined #u-boot
<shadow>
I guess either you have a reason for it not being picked up at this time or it was overlooked
<shadow>
if a patch has a Fixes tag I would expect it to get picked up for the next rc and potentially for the stable release updates
memset_ has quit [Remote host closed the connection]
memset has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
lucascastro has quit [Ping timeout: 265 seconds]
lucascastro has joined #u-boot
<marex>
rc5 is the last rc
<shadow>
I suppose I could have written that to #spacemit channel instead
<shadow>
there's some experimentation going on to get spacemit k3 into mainline u-boot, with respect to devicetree tweaks
lucascastro has quit [Ping timeout: 241 seconds]
<shadow>
I am trying to follow the changes but there seems to be a gap in process for what has been accepted and merged to the Linux kernel spacemit soc tree having Fixes tags and what appears in linux-next/master, that is surprising to me
hightower2 has joined #u-boot
<shadow>
rather it looks like this was folded into linux-next today, okay.
hightower2 has quit [Remote host closed the connection]
hightower3 has joined #u-boot
hightower4 has joined #u-boot
memset has quit [Remote host closed the connection]