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 <[email protected]> > > >> > > >> 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 <[email protected]> > > >> --- > > >> > > >> 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/[email protected]/ > > > > > > 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
signature.asc
Description: PGP signature
