Hello Sahil, > -----Original Message----- > From: Sahil Malhotra (OSS) <[email protected]> > Sent: Wednesday, December 8, 2021 7:12 AM > To: Michael Walle <[email protected]>; Sahil Malhotra (OSS) > <[email protected]> > Cc: Clément Faure <[email protected]>; Gaurav Jain <[email protected]>; > Pankaj Gupta <[email protected]>; Priyanka Jain <[email protected]>; u- > [email protected]; Varun Sethi <[email protected]>; Ye Li <[email protected]>; > ZHIZHIKIN Andrey <[email protected]> > Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature > > > Hi Michael, > > -----Original Message----- > From: Michael Walle <[email protected]> > Sent: Monday, November 29, 2021 11:17 PM > To: Sahil Malhotra (OSS) <[email protected]> > Cc: Clément Faure <[email protected]>; Gaurav Jain <[email protected]>; > Pankaj Gupta <[email protected]>; Priyanka Jain <[email protected]>; u- > [email protected]; Varun Sethi <[email protected]>; Ye Li <[email protected]>; > ZHIZHIKIN Andrey <[email protected]> > 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/[email protected]/ > > 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/[email protected]
