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