[PATCH v7 15/17] configs: Add am69_sk_* defconfig fragments

[Nishanth Menon]

On 15:06-20240111, Manorit Chawdhry wrote:
> Hi Nishanth,
> 
> On 11:59-20240103, Nishanth Menon wrote:
> > On 00:45-20231220, Apurva Nandan wrote:
> > > From: Dasnavis Sabiya <sabiya.d at ti.com>
> > > 
> > > Add config fragments for am69_sk A72 and R5 configuration.
> > > 
> > > This applies on to:
> > > j784s4_evm_a72_defconfig -> am69_sk_a72.config
> > > j784s4_evm_r5_defconfig -> am69_sk_r5.config
> > > 
> > > The usage model (with the fragment) would be:
> > > make j784s4_evm_a72_defconfig am69_sk_a72.config
> > > make
> > > 
> > > OR
> > > 
> > > make j784s4_evm_r5_defconfig am69_sk_r5.config
> > > make
> > > 
> > > Signed-off-by: Dasnavis Sabiya <sabiya.d at ti.com>
> > > Signed-off-by: Apurva Nandan <a-nandan at ti.com>
> > > ---
> > >  configs/am69_sk_a72.config | 3 +++
> > >  configs/am69_sk_r5.config  | 3 +++
> > >  2 files changed, 6 insertions(+)
> > >  create mode 100644 configs/am69_sk_a72.config
> > >  create mode 100644 configs/am69_sk_r5.config
> > > 
> > > diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
> > > new file mode 100644
> > > index 0000000000..5668e23b37
> > > --- /dev/null
> > > +++ b/configs/am69_sk_a72.config
> > > @@ -0,0 +1,3 @@
> > > +# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
> > > +
> > > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
> > > diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
> > > new file mode 100644
> > > index 0000000000..9194694393
> > > --- /dev/null
> > > +++ b/configs/am69_sk_r5.config
> > > @@ -0,0 +1,3 @@
> > > +# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
> > > +
> > > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-r5-sk"
> > 
> > See my previous comment. OF_LIST should have been overriden here to just
> > a single dtb.
> 
> Just to get an understanding with this change, so from what I see is
> OF_LIST is used to package multiple DTBs in u-boot but they way binman
> is made, we don't have dtb generator nodes that will pack them
> automatically. Even if that is the case from what I understand is the
> u-boot.dtb that gets generated is based on CONFIG_DEFAULT_DEVICE_TREE so
> how would we know which one is the default? Or are we saying that we'll
> override OF_LIST and always use only one DTB for packing in U-boot.
> 
> The reason am asking this is because with FIT Signature, we embed a
> signature node as well in the u-boot.dtb and not knowing which one is
> the default and having multiple DTBs packed in U-boot have always been
> problematic with this flow. ( In the past based on
> CONFIG_DEFAULT_DEVICE_TREE value we have ended up packing the same DTB
> twice. ) 
> 
> We use u-boot.dtb as a base reference and after adding the signature
> node to it we pack it back in u-boot with EXT_DTB flag in u-boot which
> gets propagated to u-boot.dtb (essentially only one DTB we can pack in
> this way which has the signed node), so essentially if we use OF_LIST
> and end up packing multiple DTBs I don't want use to have a conflicting
> dtb actually getting packed in some other DTBs place..
> 

None of this changes - FIT image still is valid - but the conf-1, 2 etc
makes no sense for a platform build that can only support one board.
there is no board detection logic added. You just need to include the
correct dtb data in. - this will also be exactly the same approach that
customer boards will take when they dont need to deal with board
variations (which is what majority of the customer platforms are) - the
entire idea is to keep things simple and provide a good reference for
customer platforms.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D