Hello Vignesh and all,
I am writing you to get some clarification on the way the dts/dtsi
naming and include hierarchy is designed for the TI K3 AM62x SOC family.
I read commit f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC").
I plan to send in the next few weeks some device tree files for
inclusion in the kernel for SOM (or computer on module) based on the
AM62x SOC.
I do envision to have the same dts file for different machine that are
going to use different variant of the AM62x SOC, e.g. AM623 vs AM625 or
just a different number of CPU cores, handling the differences at
runtime (patching the .dtb in U-Boot?) to limit the maintenance effort and
limit the amount of very similar dts files.
Said that we would prefer to stay close with what is considered/agreed
to be the best approach.
Would something like that work or you would have a completely different
expectation?
What would be the expected naming scheme? k3-am62-${board_name}.dts ?
Something else?
k3-am625.dtsi defines the CPU nodes, why are these in a AM625 specific
file? To me this looks like something that would be just the same with
AM623, and at the same time AM6251 has only one core (see [0] Table 5-1).
Am I missing something?
Thanks for your help,
Francesco
[0] https://www.ti.com/lit/ds/symlink/am625.pdf
On 19:44-20230207, Francesco Dolcini wrote:
> Hello Vignesh and all,
> I am writing you to get some clarification on the way the dts/dtsi
> naming and include hierarchy is designed for the TI K3 AM62x SOC family.
>
> I read commit f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC").
>
> I plan to send in the next few weeks some device tree files for
> inclusion in the kernel for SOM (or computer on module) based on the
> AM62x SOC.
>
> I do envision to have the same dts file for different machine that are
> going to use different variant of the AM62x SOC, e.g. AM623 vs AM625 or
> just a different number of CPU cores, handling the differences at
> runtime (patching the .dtb in U-Boot?) to limit the maintenance effort and
> limit the amount of very similar dts files.
>
> Said that we would prefer to stay close with what is considered/agreed
> to be the best approach.
>
> Would something like that work or you would have a completely different
> expectation?
>
> What would be the expected naming scheme? k3-am62-${board_name}.dts ?
> Something else?
>
> k3-am625.dtsi defines the CPU nodes, why are these in a AM625 specific
> file? To me this looks like something that would be just the same with
> AM623, and at the same time AM6251 has only one core (see [0] Table 5-1).
> Am I missing something?
>
> Thanks for your help,
> Francesco
>
> [0] https://www.ti.com/lit/ds/symlink/am625.pdf
>
Typically, our strategy has been to introduce the superset device,
primarily because the device variants are quite a few, and without
actual users, it makes no sense to introduce a dtsi in kernel
in-anticipation of a potential board. Now that said, also keep in mind
the part number definitions do change depending on the market demands
over time (qualification requirements etc..), The initial device tree
was based on the definition we had at the time, as usual, over time,
definitions are changing :(.
Considering the potential combinatorial explosion if we are trying
to constantly catching up with variations of chip configurations as
market definitions change over time, we need to be a bit pragmatic in
the various dtsi files we introduce. With that in mind, If we have
just one board using the part variant, we should reduce the churn in
the tree by keeping the processor variation isolated to the board
(See arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi as an
example), on the other hand, the AM6251 (Single A53 variant) promises
to be a variant that will probably get used in multiple boards, I'd
suggest introducing a dtsi that is reused across the boards.
NOTE: this would be no different from similar strategies we have
followed in OMAP devices, for example.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Thu, Feb 09, 2023 at 09:33:52AM -0600, Nishanth Menon wrote:
> On 19:44-20230207, Francesco Dolcini wrote:
> > Hello Vignesh and all,
> > I am writing you to get some clarification on the way the dts/dtsi
> > naming and include hierarchy is designed for the TI K3 AM62x SOC family.
> >
> > I read commit f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC").
> >
> > I plan to send in the next few weeks some device tree files for
> > inclusion in the kernel for SOM (or computer on module) based on the
> > AM62x SOC.
> >
> > I do envision to have the same dts file for different machine that are
> > going to use different variant of the AM62x SOC, e.g. AM623 vs AM625 or
> > just a different number of CPU cores, handling the differences at
> > runtime (patching the .dtb in U-Boot?) to limit the maintenance effort and
> > limit the amount of very similar dts files.
> >
> > Said that we would prefer to stay close with what is considered/agreed
> > to be the best approach.
> >
> > Would something like that work or you would have a completely different
> > expectation?
> >
> > What would be the expected naming scheme? k3-am62-${board_name}.dts ?
> > Something else?
> >
> > k3-am625.dtsi defines the CPU nodes, why are these in a AM625 specific
> > file? To me this looks like something that would be just the same with
> > AM623, and at the same time AM6251 has only one core (see [0] Table 5-1).
> > Am I missing something?
> >
> > Thanks for your help,
> > Francesco
> >
> > [0] https://www.ti.com/lit/ds/symlink/am625.pdf
> >
>
> Typically, our strategy has been to introduce the superset device,
> primarily because the device variants are quite a few, and without
> actual users, it makes no sense to introduce a dtsi in kernel
> in-anticipation of a potential board. Now that said, also keep in mind
> the part number definitions do change depending on the market demands
> over time (qualification requirements etc..), The initial device tree
> was based on the definition we had at the time, as usual, over time,
> definitions are changing :(.
... and from my point of view this is normal and fine. All good :-)
> Considering the potential combinatorial explosion if we are trying
> to constantly catching up with variations of chip configurations as
> market definitions change over time, we need to be a bit pragmatic in
> the various dtsi files we introduce. With that in mind, If we have
> just one board using the part variant, we should reduce the churn in
> the tree by keeping the processor variation isolated to the board
> (See arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi as an
> example), on the other hand, the AM6251 (Single A53 variant) promises
> to be a variant that will probably get used in multiple boards, I'd
> suggest introducing a dtsi that is reused across the boards.
Our current plan is to have multiple SKUs that will differentiate by the
specific SoC SKU, not sure if this was clear to you, as an example we
will have.
for board in variant1 variant2 variant3
k3-am6251-${board}.dts
k3-am6252-${board}.dts
k3-am6254-${board}.dts
k3-am6231-${board}.dts
k3-am6232-${board}.dts
k3-am6234-${board}.dts
that are just the same apart the AM62x SKU.
Do you expect something like that (18 .dts files, in this example) ?
To me this is absolutely fine, I just want to be sure this is what you
expect.
For example we do have these dts boards file here
arch/arm64/boot/dts/freescale/imx8mm-verdin-*.dts
and the FDT is patched in U-Boot in
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/soc.c#L1245
with the this approach we have 4 dts files instead of the 16 if we would
use the exact SOC SKU variant [0].
Francesco
[0] https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
On 2/10/2023 11:35 PM, Francesco Dolcini wrote:
[...]
>>>
>>
>> Typically, our strategy has been to introduce the superset device,
>> primarily because the device variants are quite a few, and without
>> actual users, it makes no sense to introduce a dtsi in kernel
>> in-anticipation of a potential board. Now that said, also keep in mind
>> the part number definitions do change depending on the market demands
>> over time (qualification requirements etc..), The initial device tree
>> was based on the definition we had at the time, as usual, over time,
>> definitions are changing :(.
>
> ... and from my point of view this is normal and fine. All good :-)
>
>> Considering the potential combinatorial explosion if we are trying
>> to constantly catching up with variations of chip configurations as
>> market definitions change over time, we need to be a bit pragmatic in
>> the various dtsi files we introduce. With that in mind, If we have
>> just one board using the part variant, we should reduce the churn in
>> the tree by keeping the processor variation isolated to the board
>> (See arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi as an
>> example), on the other hand, the AM6251 (Single A53 variant) promises
>> to be a variant that will probably get used in multiple boards, I'd
>> suggest introducing a dtsi that is reused across the boards.
>
> Our current plan is to have multiple SKUs that will differentiate by the
> specific SoC SKU, not sure if this was clear to you, as an example we
> will have.
>
> for board in variant1 variant2 variant3
> k3-am6251-${board}.dts
> k3-am6252-${board}.dts
> k3-am6254-${board}.dts
> k3-am6231-${board}.dts
> k3-am6232-${board}.dts
> k3-am6234-${board}.dts
>
> that are just the same apart the AM62x SKU.
> Do you expect something like that (18 .dts files, in this example) ?
>
> To me this is absolutely fine, I just want to be sure this is what you
> expect.
I am not sure if we need 18 files, IMO having dts for superset SoC per
board variant for each SoC variant is sufficient:
for board in variant1 variant2 variant3
k3-am625-${board}.dts (assume k3-am6254-${board}.dts)
k3-am623-${board}.dts (assume k3-am6234-${board}.dts)
And then fixup num CPUs from U-Boot as per SoC detection as long as
board remains **exactly same** as super set.
This will limit .dts files to 6. Also limits bootloader's role to just
disabling CPU cores instead of fiddling around with too many non
transparent DT fixups.
Nishanth: feel free to chime in if you have different opinion.
>
> For example we do have these dts boards file here
>
> arch/arm64/boot/dts/freescale/imx8mm-verdin-*.dts
>
> and the FDT is patched in U-Boot in
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/soc.c#L1245
>
> with the this approach we have 4 dts files instead of the 16 if we would
> use the exact SOC SKU variant [0].
>
> Francesco
>
> [0] https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
>
Regards
Vignesh