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

[Tom Rini]

On Thu, Oct 05, 2023 at 10:49:19AM -0400, Tom Rini wrote:
> 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.

OK, I think I might have solved my own unexpected success here in that
it seems like I had the wrong files being copied to the device and so
that somehow ended up working.  I have replicated failure finally.

> 
> -- 
> Tom



-- 
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/6a9f7349/attachment.sig>