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@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@ti.com Signed-off-by: Apurva Nandan a-nandan@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.