Tom Rini <tr...@konsulko.com> writes: > On Sat, Feb 24, 2024 at 11:34:36AM -0600, Jon Humphreys wrote: >> Tom Rini <tr...@konsulko.com> writes: >> >> > On Fri, Feb 23, 2024 at 06:17:02PM -0600, Jonathan Humphreys wrote: >> >> Add bootph DT tags to enable OSPI in SPL. >> >> Set OSPI regs for R5 SPL to address OSPI's boot region. >> >> >> >> Signed-off-by: Jonathan Humphreys <j-humphr...@ti.com> >> >> --- >> >> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 16 ++++++++++++++++ >> >> arch/arm/dts/k3-am642-r5-evm.dts | 5 +++++ >> >> arch/arm/dts/k3-am642-r5-sk.dts | 5 +++++ >> >> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 16 ++++++++++++++++ >> >> 4 files changed, 42 insertions(+) >> >> >> >> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi >> >> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi >> >> index b843078243..60b219c0be 100644 >> >> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi >> >> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi >> >> @@ -182,3 +182,19 @@ >> >> &cpsw_port2 { >> >> status = "disabled"; >> >> }; >> >> + >> >> +&ospi0_pins_default { >> >> + bootph-all; >> >> +}; >> >> + >> >> +&fss { >> >> + bootph-all; >> >> +}; >> >> + >> >> +&ospi0 { >> >> + bootph-all; >> >> + >> >> + flash@0 { >> >> + bootph-all; >> >> + }; >> >> +}; >> > >> > So this gets back to what I was asking in the first series, is this >> > needed in SPL or full U-Boot as well? The bootph-* properties are >> > supposed to be transitive, but originally the tooling didn't handle this >> > and now the tooling handles SPL but not full U-Boot. Which also brings >> > back the is this _needed_ question and is bootph-all right, rather than >> > just the big hammer? >> > >> By "this", are you referring to the original phypattern partition nodes, >> or the ospi0 node itself? The partition nodes are not needed at all, so >> removed. The ospi node is needed in both SPL and U-Boot. In that case, >> using the bootph-all tag is the proper way, correct? >> >> What do you mean by the 'big hammer'? >> >> Please advise and thanks. > > So, part of the answer is that the documentation isn't as clear and well > formatted as I'd like (aside, include/dm/ofnode.h::ofnode_pre_reloc > comment should be reworded to render better). First, I want to point to > the schema itself: > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > and then next: > https://docs.u-boot.org/en/latest/develop/driver-model/design.html#pre-relocation-support > > And in this case, the "pre" options are a bit less clear as TI platforms > don't do the TPL->SPL->Full U-Boot dance that others like say Rockchip > do but instead the Cortex-R/Cortex-A dance for the K3 architecture. > > Which gets back to what I was trying to ask. What, functionally, > requires that property to be present? And then, for the cortex-a > platforms these should be in the upstream dtb and I forget if you said > that's in progress for these platforms or not.
Without those properties, the on-board OSPI flash is not available to u-boot. There is a separate action to move the bootph properities (not just the above) to the upstream DT. > > -- > Tom