On 26.07.23 09:25, Manorit Chawdhry wrote:
> On 12:17-20230726, Manorit Chawdhry wrote:
>> Hi Jan,
>>
>> On 08:42-20230726, Jan Kiszka wrote:
>>> On 14.07.23 07:52, Manorit Chawdhry wrote:
>>>> The series focuses on fixes for various boards along with moving to
>>>> standards and enabling the FIT_SIGNATURE for K3 Platforms towards the
>>>> end.
>>>>
>>>> Dependencies:
>>>> https://lore.kernel.org/u-boot/20230712183453.7623-1-n-fran...@ti.com/
>>>>
>>>> Signed-off-by: Manorit Chawdhry <m-chawd...@ti.com>
>>>> ---
>>>> Andrew Davis (4):
>>>> environment: ti: Prefix ARM64 DTB names with directory
>>>> environment: ti: Make get_fdt_mmc common
>>>> configs: Enable setexpr command on TI devices
>>>> arm: k3: Add regex/gsub command handling
>>>>
>>>> Kamlesh Gurudasani (3):
>>>> board: ti: am64x: am64x.env: set fdtfile env variable
>>>> configs: k3: make consistent bootcmd across all k3 socs
>>>> configs: am64: Fix booting of fitImage on AM64x
>>>>
>>>> Manorit Chawdhry (11):
>>>> arch: mach-k3: security: fix the check for authentication
>>>> Kconfig: j721s2: Fix the scratchpad base
>>>> mach-k3: common: correct the calculations for determining firewalls
>>>> include: j7*_evm.h: Cleanups to be done
>>>> configs: k3: Remove saved environments
>>>> env: Make common bootcmd across all k3 devices
>>>> include: armv7: Enable distroboot across all configs
>>>> board: ti: keys: add .key and .crt for fit signature signing
>>>> k3-*-binman: dts: Pack u-boot.dtb instead of soc specific dtb
>>>> lib: Kconfig: k3: Enable SHA512 for fit signature
>>>> Kconfig: Enable FIT_SIGNATURE if ARM64
>>>>
>>>> arch/arm/Kconfig | 2 +
>>>> arch/arm/dts/k3-am625-sk-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-am62a-sk-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-am64x-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-am65x-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-j7200-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-j721e-binman.dtsi | 2 +-
>>>> arch/arm/dts/k3-j721s2-binman.dtsi | 2 +-
>>>> arch/arm/mach-k3/Kconfig | 2 +-
>>>> arch/arm/mach-k3/common.c | 3 +-
>>>> arch/arm/mach-k3/common.h | 2 +-
>>>> arch/arm/mach-k3/security.c | 5 +-
>>>> board/ti/am62ax/am62ax.env | 3 +-
>>>> board/ti/am62x/am62x.env | 3 +-
>>>> board/ti/am64x/am64x.env | 6 +-
>>>> board/ti/am65x/am65x.env | 3 +-
>>>> board/ti/j721e/j721e.env | 9 +-
>>>> board/ti/j721s2/j721s2.env | 7 +-
>>>> board/ti/keys/custMpk.crt | 33 ++++++
>>>> board/ti/keys/custMpk.key | 51 +++++++++
>>>> boot/Kconfig | 3 +-
>>>> configs/am335x_hs_evm_defconfig | 1 -
>>>> configs/am43xx_hs_evm_defconfig | 1 -
>>>> configs/am43xx_hs_evm_qspi_defconfig | 1 -
>>>> configs/am57xx_hs_evm_defconfig | 1 -
>>>> configs/am57xx_hs_evm_usb_defconfig | 1 -
>>>> configs/am62ax_evm_a53_defconfig | 1 +
>>>> configs/am62x_evm_a53_defconfig | 3 +-
>>>> configs/am64x_evm_a53_defconfig | 7 +-
>>>> configs/am65x_evm_a53_defconfig | 1 -
>>>> configs/am65x_hs_evm_a53_defconfig | 1 -
>>>> configs/j7200_evm_a72_defconfig | 7 +-
>>>> configs/j721e_evm_a72_defconfig | 7 +-
>>>> configs/j721s2_evm_a72_defconfig | 6 +-
>>>> doc/board/ti/k3.rst | 172
>>>> +++++++++++++++++++++++++++++
>>>> include/configs/am62ax_evm.h | 71 ------------
>>>> include/configs/am62x_evm.h | 27 -----
>>>> include/configs/j721e_evm.h | 32 ------
>>>> include/configs/j721s2_evm.h | 5 -
>>>> include/configs/ti_armv7_common.h | 50 +++++++++
>>>> include/environment/ti/mmc.env | 5 +-
>>>> include/environment/ti/ti_armv7_common.env | 11 +-
>>>> lib/Kconfig | 1 +
>>>> 43 files changed, 356 insertions(+), 202 deletions(-)
>>>> ---
>>>> base-commit: 26bd02c45a97f77cfb6afac4ee4f61fb9c5c7007
>>>> change-id: 20230713-b4-upstream-fit-image-support-9d3c113ebab7
>>>>
>>>> Best regards,
>>>
>>> This series (at least) completely broke IOT2050 booting, specifically by
>>> dictating EVM-specific settings on our non-EVM board. Still trying to
>>> understand all problems and how to resolve them, either on board level
>>> or via making the side-effects optional. Due to that, our own patches
>>> missed rc1 :(.
>>>
>>
>> Sorry for the inconvenience caused, I have no idea what led to such
>> things but yes, the series wasn't ready to be merged although I have
>> sent incremental fixes for some of the necessary stuff but do let me
>> know the breakage reasons and I will try to address them as soon as
>> possible if I can.
>>
>
> Also, could you elaborate on the place of failure? There are certain
> possibilities coming to my mind for the breakage, please see if those
> are the ones that maybe you can look at w.r.t the failures that you've
> seen.
>
> The series removes the saved environment settings that might have been
> there in your boards due to which the possibility of failure could
> occur, have a look at [0].
>
> The series changes binman nodes for packing u-boot.dtb in u-boot.img, am
> not sure if this can affect you guys but have a look at [1].
>
> The directory paths are being changed for the respective kernel and dtb,
> have a look at [2].
>
> We've migrated to the FIT_SIGNATURE standard completely so things have
> changed w.r.t that and we are enabling it by default in K3 Platforms so
> have a look at [3]. The configuration nodes and other things have also
> changed along with it.
>
> Am assuming that the BOOTCMD change shouldn't affect you guys as you
> might be having custom BOOTCMD maybe but if that is not the case then
> the default bootcmd that we have is not a part of the distroboot and we
> run our legacy boot method in the beginning of it that is defined in
> commit [4].
>
> These all changes had been a part of LTS migration that we had
> internally so I do understand that it can break certain things but maybe
> I can make it easier for you guys to pin point the cause of failure so
> letting you know of all the things that have changed in the series
> without you trying to dig down into each and every commit.
>
> [0]:
> https://lore.kernel.org/u-boot/20230726064659.gzdbinr4hreujz3k@ula0497581/T/#m10379ff5526bf14d719b0f5af69e6e19b7af8a22
> [1]:
> https://lore.kernel.org/u-boot/20230726064659.gzdbinr4hreujz3k@ula0497581/T/#ma7ff630fccc5eecc9f73925728507d3c26e5a0e4
> [2]:
> https://lore.kernel.org/u-boot/20230726064659.gzdbinr4hreujz3k@ula0497581/T/#m03a9289cef98c845dd5929deb9ff54b9b08f6e4a
> [3]:
> https://lore.kernel.org/u-boot/20230726064659.gzdbinr4hreujz3k@ula0497581/T/#m1f7923aa8cb2c2c663a1f0deb03ea701a718d316
> [4]:
> https://lore.kernel.org/u-boot/20230726064659.gzdbinr4hreujz3k@ula0497581/T/#m0c8dd42369339ab2678584ee9043a3cf1642ec43
>
It seems, this helps, at least non-secure boot configuration works
again (secure to be tested):
diff --git a/board/siemens/iot2050/iot2050.env
b/board/siemens/iot2050/iot2050.env
index 02958798b49..7fd836e6285 100644
--- a/board/siemens/iot2050/iot2050.env
+++ b/board/siemens/iot2050/iot2050.env
@@ -6,6 +6,8 @@
* Jan Kiszka <jan.kis...@siemens.com>
*/
+#include <environment/ti/ti_armv7_common.env>
+
usb_pgood_delay=900
watchdog_timeout_ms=CONFIG_WATCHDOG_TIMEOUT_MSECS
diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
index 2177e0dfe38..4968722d18f 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -15,6 +15,17 @@
#include <configs/ti_armv7_common.h>
+/*
+ * This defines all MMC devices, even if the basic variant has no mmc1.
+ * The non-supported device will be removed from the boot targets during
+ * runtime, when that board was detected.
+ */
+#undef BOOT_TARGET_DEVICES
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 1) \
+ func(MMC, mmc, 0) \
+ BOOT_TARGET_USB(func)
+
#ifdef CONFIG_ENV_WRITEABLE_LIST
#define CFG_ENV_FLAGS_LIST_STATIC \
"board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw," \
Jan
--
Siemens AG, Technology
Linux Expert Center
