[PATCH] arm: dts: k3-am625-beagleplay: Fix boot

[Tom Rini]

On Thu, Oct 05, 2023 at 06:18:08AM +0200, Jan Kiszka wrote:
> On 04.10.23 14:15, Nishanth Menon wrote:
> > On 22:26-20231003, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka at siemens.com>
> >>
> >> Since commit [1] A53 u-boot proper is broken. This is because nodes
> >> marked as 'bootph-pre-ram' are not available at u-boot proper before
> >> relocation.
> >>
> >> To fix this we mark all nodes as 'bootph-all'.
> >>
> >> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation")
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> >> ---
> >>
> >> This may overshoot, but at least the board boots again. Could it be that 
> >> [1] broke even more boards?
> > 
> > Jan: https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147975@kernel.org/
> > 
> > I got boot without r5-beagleplay.dts modified. and it is in line with
> > the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti:
> > k3-am625-beagleplay: Add boot phase tags marking")
> > 
> 
> Yeah, no problem, missed that.
> 
> Meanwhile, I can fix our IOT2050 because I was unfortunatenly right:
> more havoc in sight. Did anyone tried to look at the fallouts
> systematically already? Is it only affecting the TI family?

Well, I'm pretty confused right now.  The visible breakage has been
traced back to a commit that was in -next and is fine on my J721E EVM
and is fine on my AM65x EVM.  I can't figure out where my Beagleplay
ended up, so I can't check that one as easily.  But given how the
breakage is described, mine too should be failing.  But they aren't.  In
both cases, I have the GP versions of the chips, and am booting the
unsigned files.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231005/f20edf76/attachment.sig>