Hi Sahil, (and happy new year ;-)
On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) < sahil.malho...@oss.nxp.com> wrote: > Hi Michael, > > > -----Original Message----- > > From: Michael Walle <mich...@walle.cc> > > Sent: Thursday, December 23, 2021 3:05 PM > > To: Sahil Malhotra (OSS) <sahil.malho...@oss.nxp.com> > > Cc: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com>; Clément > Faure > > <clement.fa...@nxp.com>; Gaurav Jain <gaurav.j...@nxp.com>; Pankaj Gupta > > <pankaj.gu...@nxp.com>; Priyanka Jain <priyanka.j...@nxp.com>; u- > > b...@lists.denx.de; Varun Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com> > > Subject: Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > feature > > > > Hi Sahil, > > > > Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): > > >> -----Original Message----- > > >> From: U-Boot <u-boot-boun...@lists.denx.de> On Behalf Of Michael > > >> Walle > > >> Sent: Monday, December 20, 2021 6:23 PM > > >> To: Sahil Malhotra (OSS) <sahil.malho...@oss.nxp.com> > > >> Cc: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com>; Clément > > >> Faure <clement.fa...@nxp.com>; Gaurav Jain <gaurav.j...@nxp.com>; > > >> Pankaj Gupta <pankaj.gu...@nxp.com>; Priyanka Jain > > >> <priyanka.j...@nxp.com>; u-boot@lists.denx.de; Varun Sethi > > >> <v.se...@nxp.com>; Ye Li <ye...@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. > Ok, I don't think that as of now, in all platforms uboot and linux have > same devie > tree. > But I will try to address your concern, but I don’t know how to apply > overlay to > dtb which is embedded in u-boot binary, Can you please point me to one > reference > which is doing this thing, I will take reference from there. > > > > 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. > If supplied DTB does not match with DTB overlay fragment. then overlay > will not get applied. > We don't have any control on where user picks the DTB, but we can only > make sure DTB > overlay feature must work with DTBs which are upstreamed > If user makes its own customized DTB, we cannot make sure that things will > work. > > Elaborating on a broader context: who is the user in U-Boot? In desktops/laptops context, I understand the user could be the desktop/laptop owner but based on my limited understanding of Chrome, users are quite constrained in what they can do (allowing the user to play with DT is a recipe for costly support). In the embedded case, is the user the one who makes a board based on the SoC ? the product maker that uses the board for a particular solution ? the integrator who places the board in a larger product ? the larger product maker ? the larger product owner ? the larger product maintenance guy? ultimately I think there is a need to empower a number of actors listed above who will take the responsibility based on consultation from the software value chain. All this to say I believe we lack vocabulary to identify actors in the firmware software value chain: has anyone already tried to formalize this? Regards, > Sahil Malhotra >