| Message ID | 20240911-j784s4-tps6594-bootph-v2-0-a83526264ab1@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: ti: k3-j784s4: Mark tps659413 regulators as bootph-all | expand |
On Wed, Sep 11, 2024 at 12:19:01PM GMT, Andrew Halaney wrote: > This series marks tps659413's regulators as bootph-all in order for > the nodes (and parent nodes) to be accessible during MCU's u-boot SPL. > > This in turn is desired since the tps659413 needs its MCU ESM > state machine setup in order for the watchdog to reset the board. > > This took me a little while to track down, as enabling the ESM, TPS6594, > etc in u-boot would result in the below boot failure: > > U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500) > SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)') > Initialized 4 DRAM controllers > SPL initial stack usage: 13408 bytes > ### ERROR ### Please RESET the board ### > > Which turns out to actually have failed far earlier in spl_early_init(), > due to these nodes not being accessible in u-boot. That's hard to tell > though since console isn't setup until later (and for that reason I > think spl_early_init()'s return value in j784s4_init.c isn't > evaluated since a panic() at that point would leave a user with *no* > information at all). > > I've tested this in conjunction with a u-boot series which I'll link in > a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing > on the k3-am69-sk at a minimum, as it should suffer the same fate if things > aren't setup appropriately. > > Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Link to the u-boot series: https://lore.kernel.org/all/3bf2177d-178f-46bf-abfe-6f00a52c623b@ti.com/#t Udit, it seems you tested the am69-sk patch from this series in the above u-boot link, thanks! If that's correct mind adding your Tested-by on the patch here then as well? Thanks, Andrew > --- > Changes in v2: > - Only mark the regulator nodes as bootph-all since parents are implied > - Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com > > --- > Andrew Halaney (2): > arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all > arm64: dts: ti: k3-am69-sk: Mark tps659413 regulators as bootph-all > > arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++++++++ > arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++ > 2 files changed, 16 insertions(+) > --- > base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8 > change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a > > Best regards, > -- > Andrew Halaney <ahalaney@redhat.com> >
On 9/12/2024 9:32 PM, Andrew Halaney wrote: > On Wed, Sep 11, 2024 at 12:19:01PM GMT, Andrew Halaney wrote: >> This series marks tps659413's regulators as bootph-all in order for >> the nodes (and parent nodes) to be accessible during MCU's u-boot SPL. >> >> This in turn is desired since the tps659413 needs its MCU ESM >> state machine setup in order for the watchdog to reset the board. >> >> This took me a little while to track down, as enabling the ESM, TPS6594, >> etc in u-boot would result in the below boot failure: >> >> U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500) >> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)') >> Initialized 4 DRAM controllers >> SPL initial stack usage: 13408 bytes >> ### ERROR ### Please RESET the board ### >> >> Which turns out to actually have failed far earlier in spl_early_init(), >> due to these nodes not being accessible in u-boot. That's hard to tell >> though since console isn't setup until later (and for that reason I >> think spl_early_init()'s return value in j784s4_init.c isn't >> evaluated since a panic() at that point would leave a user with *no* >> information at all). >> >> I've tested this in conjunction with a u-boot series which I'll link in >> a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing >> on the k3-am69-sk at a minimum, as it should suffer the same fate if things >> aren't setup appropriately. >> >> Signed-off-by: Andrew Halaney <ahalaney@redhat.com> > Link to the u-boot series: https://lore.kernel.org/all/3bf2177d-178f-46bf-abfe-6f00a52c623b@ti.com/#t > > Udit, it seems you tested the am69-sk patch from this series in the above > u-boot link, thanks! If that's correct mind adding your Tested-by on > the patch here then as well? Yes, Please use for this series on both platforms Tested-by: Udit Kumar <u-kumar1@ti.com> > > Thanks, > Andrew > >> --- >> Changes in v2: >> - Only mark the regulator nodes as bootph-all since parents are implied >> - Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com >> >> --- >> Andrew Halaney (2): >> arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all >> arm64: dts: ti: k3-am69-sk: Mark tps659413 regulators as bootph-all >> >> arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++++++++ >> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++ >> 2 files changed, 16 insertions(+) >> --- >> base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8 >> change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a >> >> Best regards, >> -- >> Andrew Halaney <ahalaney@redhat.com> >>
This series marks tps659413's regulators as bootph-all in order for the nodes (and parent nodes) to be accessible during MCU's u-boot SPL. This in turn is desired since the tps659413 needs its MCU ESM state machine setup in order for the watchdog to reset the board. This took me a little while to track down, as enabling the ESM, TPS6594, etc in u-boot would result in the below boot failure: U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)') Initialized 4 DRAM controllers SPL initial stack usage: 13408 bytes ### ERROR ### Please RESET the board ### Which turns out to actually have failed far earlier in spl_early_init(), due to these nodes not being accessible in u-boot. That's hard to tell though since console isn't setup until later (and for that reason I think spl_early_init()'s return value in j784s4_init.c isn't evaluated since a panic() at that point would leave a user with *no* information at all). I've tested this in conjunction with a u-boot series which I'll link in a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing on the k3-am69-sk at a minimum, as it should suffer the same fate if things aren't setup appropriately. Signed-off-by: Andrew Halaney <ahalaney@redhat.com> --- Changes in v2: - Only mark the regulator nodes as bootph-all since parents are implied - Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com --- Andrew Halaney (2): arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all arm64: dts: ti: k3-am69-sk: Mark tps659413 regulators as bootph-all arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++++++++ arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++ 2 files changed, 16 insertions(+) --- base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8 change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a Best regards,