[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra sahil.malhotra@nxp.com
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra sahil.malhotra@nxp.com --- arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 + arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++++++++++++++++++ arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +++++ arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++++++ .../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25 ++++++++++++ 5 files changed, 87 insertions(+) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile index 598c36ee66..97f1f291dd 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile @@ -7,6 +7,7 @@ obj-y += lowlevel.o obj-y += soc.o ifndef CONFIG_SPL_BUILD obj-$(CONFIG_MP) += mp.o spintable.o +obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o obj-$(CONFIG_OF_LIBFDT) += fdt.o endif obj-$(CONFIG_SPL) += spl.o diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c new file mode 100644 index 0000000000..2418ad09c7 --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c @@ -0,0 +1,39 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2021 NXP + */ +#include <common.h> +#include <errno.h> +#include <fdt_support.h> +#include <linux/sizes.h> +#include "dt_optee.h" + +int ft_add_optee_overlay(void *fdt, struct bd_info *bd) +{ + int ret = 0; + + /* + * No BL32_BASE passed means no TEE running, so no + * need to add optee node in dts + */ + if (!rom_pointer[0]) { + debug("No BL32_BASE passed means no TEE running\n"); + return ret; + } + + if (rom_pointer[2]) { + debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]); + ret = fdt_check_header((void *)rom_pointer[2]); + if (ret == 0) { + /* Copy the fdt overlay to next 1M and use copied overlay */ + memcpy((void *)(rom_pointer[2] + SZ_1M), (void *)rom_pointer[2], + fdt_totalsize((void *)rom_pointer[2])); + ret = fdt_overlay_apply_verbose(fdt, (void *)(rom_pointer[2] + SZ_1M)); + if (ret == 0) { + debug("Overlay applied with success"); + fdt_pack(fdt); + } + } + } + return ret; +} diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h new file mode 100644 index 0000000000..d1ff25d531 --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2021 NXP + */ +#ifndef __DT_OPTEE_H__ +#define __DT_OPTEE_H__ + +extern unsigned long rom_pointer[]; +int ft_add_optee_overlay(void *fdt, struct bd_info *bd); +#endif diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index f1624ff30a..0824c62264 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -31,6 +31,7 @@ #endif #include <asm/arch/speed.h> #include <fsl_qbman.h> +#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc) { @@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd) fdt_fixup_ecam(blob); #endif } + +#ifdef CONFIG_OF_SYSTEM_SETUP +int ft_system_setup(void *blob, struct bd_info *bd) +{ +#ifdef CONFIG_OF_LIBFDT_OVERLAY + return ft_add_optee_overlay(blob, bd); +#else + return 0; +#endif +} +#endif diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S new file mode 100644 index 0000000000..1d6a2d85fa --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2021 NXP + */ + +#include <config.h> + +.align 8 +.global rom_pointer +rom_pointer: + .space 32 + +/* + * Routine: save_boot_params (called after reset from start.S) + */ + +.global save_boot_params +save_boot_params: + /* The firmware provided FDT address can be found in r2/x0 */ + adr x0, rom_pointer + stp x1, x2, [x0], #16 + stp x3, x4, [x0], #16 + + ldr x1, =save_boot_params_ret + br x1
From: Sahil Malhotra sahil.malhotra@nxp.com
SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB
Signed-off-by: Sahil Malhotra sahil.malhotra@nxp.com --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+)
diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y
From: Sahil Malhotra sahil.malhotra@nxp.com
This patch enables the DTB overlay feature for LS platforms.
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
-michael
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Wednesday, November 17, 2021 1:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; Sahil Malhotra sahil.malhotra@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; Michael Walle michael@walle.cc Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra sahil.malhotra@nxp.com
This patch enables the DTB overlay feature for LS platforms.
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
-michael
Regards, Sahil Malhotra
Hi Sahil,
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
But until you've explained what this is about, this is only guesswork.
-michael
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Wednesday, November 17, 2021 11:51 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
Regards, Sahil Malhotra
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/
-michael
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Monday, November 29, 2021 11:17 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/
Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this job ring. Same job ring can be used by Linux once it boots up.
Regards, Sahil Malhotra
Hello Sahil,
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Wednesday, December 8, 2021 7:12 AM To: Michael Walle michael@walle.cc; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Monday, November 29, 2021 11:17 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a
different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/
Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this job ring. Same job ring can be used by Linux once it boots up.
Just for clarification: by saying "Very first CAAM Job Ring" do you actually mean JR0?
If the BootROM logic with respect to JR reservation for LS family does not differ from i.MX8M family (which I assume does not), then why can't the logic be implemented in the same way proposed by Gaurav [1] here as well?
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over.
This is however valid only if OP-TEE implementation for LS matches to one from i.MX8M family.
If it OP-TEE does differ, then I suggest this should be rather addressed there before U-Boot, since OP-TEE have all facilities in place to reserve JR nodes as they are needed.
Regards, Sahil Malhotra
-- andrey Link: [1]: https://lore.kernel.org/u-boot/20211207074129.10955-9-gaurav.jain@nxp.com
Hi Andrey,
-----Original Message----- From: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Sent: Wednesday, December 8, 2021 3:43 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com; Michael Walle michael@walle.cc Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hello Sahil,
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Wednesday, December 8, 2021 7:12 AM To: Michael Walle michael@walle.cc; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Monday, November 29, 2021 11:17 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a
different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nx p.com/
Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this job ring. Same job ring can be used by Linux once it boots up.
Just for clarification: by saying "Very first CAAM Job Ring" do you actually mean JR0?
Yes, Very first CAAM Job Ring means JR0 for Layerscape.
If the BootROM logic with respect to JR reservation for LS family does not differ from i.MX8M family (which I assume does not), then why can't the logic be implemented in the same way proposed by Gaurav [1] here as well?
BootROM logic with respect to JR reservation is different for both Layerscape and i.MX8M family. On Layerscape Platforms we don't have HAB, so we don’t need to reserve JR0.
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
This is however valid only if OP-TEE implementation for LS matches to one from i.MX8M family.
If it OP-TEE does differ, then I suggest this should be rather addressed there before U-Boot, since OP-TEE have all facilities in place to reserve JR nodes as they are needed.
OP-TEE reserves the JR node needed by it, but it needs to tell that to Normal World entities and that is being done using DTB overlay for now.
Regards, Sahil Malhotra
-- andrey Link: [1]: https://lore.kernel.org/u-boot/20211207074129.10955-9- gaurav.jain@nxp.com
Regards, Sahil Malhotra
Hi Michael/Andrey
Gentle reminder for comment on this patch series.
Regards, Sahil Malhotra
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Friday, December 10, 2021 12:03 PM To: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com; Michael Walle michael@walle.cc Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Andrey,
-----Original Message----- From: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Sent: Wednesday, December 8, 2021 3:43 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com; Michael Walle michael@walle.cc Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hello Sahil,
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Wednesday, December 8, 2021 7:12 AM To: Michael Walle michael@walle.cc; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Monday, November 29, 2021 11:17 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a
different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@ nx p.com/
Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this job ring. Same job ring can be used by Linux once it boots up.
Just for clarification: by saying "Very first CAAM Job Ring" do you actually mean JR0?
Yes, Very first CAAM Job Ring means JR0 for Layerscape.
If the BootROM logic with respect to JR reservation for LS family does not differ from i.MX8M family (which I assume does not), then why can't the logic be implemented in the same way proposed by Gaurav [1]
here as well? BootROM logic with respect to JR reservation is different for both Layerscape and i.MX8M family. On Layerscape Platforms we don't have HAB, so we don’t need to reserve JR0.
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
This is however valid only if OP-TEE implementation for LS matches to one from i.MX8M family.
If it OP-TEE does differ, then I suggest this should be rather addressed there before U-Boot, since OP-TEE have all facilities in place to reserve JR nodes as they are needed.
OP-TEE reserves the JR node needed by it, but it needs to tell that to Normal World entities and that is being done using DTB overlay for now.
Regards, Sahil Malhotra
-- andrey Link: [1]: https://lore.kernel.org/u-boot/20211207074129.10955-9- gaurav.jain@nxp.com
Regards, Sahil Malhotra
Am 17. Dezember 2021 11:19:42 GMT+05:00 schrieb "Sahil Malhotra (OSS)" sahil.malhotra@oss.nxp.com:
Hi Michael/Andrey
Gentle reminder for comment on this patch series.
Regards, Sahil Malhotra
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Friday, December 10, 2021 12:03 PM To: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com; Michael Walle michael@walle.cc Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Andrey,
-----Original Message----- From: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Sent: Wednesday, December 8, 2021 3:43 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com; Michael Walle michael@walle.cc Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hello Sahil,
-----Original Message----- From: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Sent: Wednesday, December 8, 2021 7:12 AM To: Michael Walle michael@walle.cc; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Monday, November 29, 2021 11:17 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com;
Priyanka
Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
> Could you please add some description what this is doing and for > what this is intended? To have a "DTB overlay feature", it is > enough to just enable CONFIG_OF_LIBFDT_OVERLAY. I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
> Apparently you're adding an overlay passed by optee. Doesn't > this have to be applied to u-boot's control dtb too? Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a
different version of the device tree.
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@ nx p.com/
Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this job ring. Same job ring can be used by Linux once it boots up.
Just for clarification: by saying "Very first CAAM Job Ring" do you actually mean JR0?
Yes, Very first CAAM Job Ring means JR0 for Layerscape.
If the BootROM logic with respect to JR reservation for LS family does not differ from i.MX8M family (which I assume does not), then why can't the logic be implemented in the same way proposed by Gaurav [1]
here as well? BootROM logic with respect to JR reservation is different for both Layerscape and i.MX8M family. On Layerscape Platforms we don't have HAB, so we don’t need to reserve JR0.
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
This is however valid only if OP-TEE implementation for LS matches to one from i.MX8M family.
If it OP-TEE does differ, then I suggest this should be rather addressed there before U-Boot, since OP-TEE have all facilities in place to reserve JR nodes as they are needed.
OP-TEE reserves the JR node needed by it, but it needs to tell that to Normal World entities and that is being done using DTB overlay for now.
Regards, Sahil Malhotra
-- andrey Link: [1]: https://lore.kernel.org/u-boot/20211207074129.10955-9- gaurav.jain@nxp.com
Regards, Sahil Malhotra
hey sahil,
I'm on vacation until the end of this week. will comment beginning of next week.
-michael
Hi Sahil,
Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS):
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb?
-michael
Hi Michael,
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Caution: EXT Email
Hi Sahil,
Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS):
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes
over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb?
"wrong" dtb means that uboot will not be aware of CAAM job ring which is taken by OP-TEE and uboot on LS platforms currently use JR0, which is not being used by any other entity in LS bootflow.
We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE reserves One Job Ring for its use and that is communicated to Kernel using DTB overlay.
what if the overlay doesn't match the dtb?
I didn't get this point, can you please elaborate a little.
Regards, Sahil Malhotra
Hi Sahil,
Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS):
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Caution: EXT Email
Hi Sahil,
Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS):
DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World.
OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes
over.
Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ?
But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb?
"wrong" dtb means that uboot will not be aware of CAAM job ring which is taken by OP-TEE and uboot on LS platforms currently use JR0, which is not being used by any other entity in LS bootflow.
I don't know I follow. u-boot and linux should have the same device tree; regardless if that device is used or not. So applying the overlay just for linux isn't enough here.
We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE reserves One Job Ring for its use and that is communicated to Kernel using DTB overlay.
what if the overlay doesn't match the dtb?
I didn't get this point, can you please elaborate a little.
You are merging a dtb fragment with an unknown dtb, right? Who says they match? you might have an old dtb where the supplied dtb fragment doesn't make any sense.
I might be missing something here. Eg. where is the linux dtb supposed to come from? This patchset is really missing an example and a description how things should work.
-michael
Hi Michael
Le lun. 29 nov. 2021 à 18:47, Michael Walle michael@walle.cc a écrit :
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a different version of the device tree.
Outside any runtime context there should be a reference for hardware description. That non-runtime reference need to be firmware and OS agnostic and document what devices are seen by each. For instance a board with serdes should have serdes nodes and disabled nodes that corresponds to possible nodes (pci, network, storage…) created as a result of the serdes configuration. One would expect firmware does it but nothing prevent an OS to do it. Those nodes should not refer to U-Boot or Linux, just firmware and operating system. Furthermore, there may be multiple totally independent computing domains on a single board: Cortex-a + r/m, multiple cortex-a and cortex-r/m and other cores. So the reference hardware description should encompass all and provide consistent description of resources available in multiple domains (say some hardware mail box and why not some sram). To be consumed by different operating systems. Linux, if the operating system of choice for that platform, will only see a portion of the total hardware description. That part may be further reduced at runtime for various legislative reasons, one of them being presented by Sahil.
For your above comment, were you referring to this reference hardware description of the cortex-a domain of the board ?
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/
-michael
participants (5)
-
François Ozog -
Michael Walle -
Sahil Malhotra -
Sahil Malhotra (OSS)
-
ZHIZHIKIN Andrey