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.kis...@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.kis...@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-9b622e147...@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
signature.asc
Description: PGP signature
