Hi Sahil, (and happy new year ;-)
On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) < [email protected]> wrote: > Hi Michael, > > > -----Original Message----- > > From: Michael Walle <[email protected]> > > Sent: Thursday, December 23, 2021 3:05 PM > > To: Sahil Malhotra (OSS) <[email protected]> > > Cc: ZHIZHIKIN Andrey <[email protected]>; 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]> > > 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 <[email protected]> On Behalf Of Michael > > >> Walle > > >> Sent: Monday, December 20, 2021 6:23 PM > > >> To: Sahil Malhotra (OSS) <[email protected]> > > >> Cc: ZHIZHIKIN Andrey <[email protected]>; Clément > > >> Faure <[email protected]>; Gaurav Jain <[email protected]>; > > >> Pankaj Gupta <[email protected]>; Priyanka Jain > > >> <[email protected]>; [email protected]; Varun Sethi > > >> <[email protected]>; Ye Li <[email protected]> > > >> 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 >
