[EXT] Re: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature

[Sahil Malhotra (OSS)]

Hi Francois.

Sorry for the delayed response.

> > 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?
Yes, Great point you raised, user can be anyone as mentioned by you and yes we lack
the correct definitions of different actors that can exist in firmware software value chain.

As of now I am not aware of any effort going on this direction to formalize, but definitely
we can work together for formalizing this thing.

Regards,
Sahil Malhotra

> -----Original Message-----
> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of François Ozog
> Sent: Thursday, January 6, 2022 1:18 PM
> To: Sahil Malhotra (OSS) <sahil.malhotra at oss.nxp.com>
> Cc: Michael Walle <michael at walle.cc>; ZHIZHIKIN Andrey
> <andrey.zhizhikin at leica-geosystems.com>; Clément Faure
> <clement.faure at nxp.com>; Gaurav Jain <gaurav.jain at nxp.com>; Pankaj
> Gupta <pankaj.gupta at nxp.com>; Priyanka Jain <priyanka.jain at nxp.com>;
> u-boot at lists.denx.de; Varun Sethi <V.Sethi at nxp.com>; Ye Li
> <ye.li at nxp.com>
> Subject: [EXT] Re: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
> 
> Caution: EXT Email
> 
> Hi Sahil,
> 
> (and happy new year ;-)
> 
> On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) <
> sahil.malhotra at oss.nxp.com> wrote:
> 
> > Hi Michael,
> >
> > > -----Original Message-----
> > > From: Michael Walle <michael at walle.cc>
> > > Sent: Thursday, December 23, 2021 3:05 PM
> > > To: Sahil Malhotra (OSS) <sahil.malhotra at oss.nxp.com>
> > > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>;
> > > Clément
> > Faure
> > > <clement.faure at nxp.com>; Gaurav Jain <gaurav.jain at nxp.com>; Pankaj
> > > Gupta <pankaj.gupta at nxp.com>; Priyanka Jain
> <priyanka.jain at nxp.com>;
> > > u- boot at lists.denx.de; Varun Sethi <V.Sethi at nxp.com>; Ye Li
> > > <ye.li at 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-bounces at lists.denx.de> On Behalf Of Michael
> > > >> Walle
> > > >> Sent: Monday, December 20, 2021 6:23 PM
> > > >> To: Sahil Malhotra (OSS) <sahil.malhotra at oss.nxp.com>
> > > >> Cc: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>;
> > > >> Clément Faure <clement.faure at nxp.com>; Gaurav Jain
> > > >> <gaurav.jain at nxp.com>; Pankaj Gupta <pankaj.gupta at nxp.com>;
> > > >> Priyanka Jain <priyanka.jain at nxp.com>; u-boot at lists.denx.de;
> > > >> Varun Sethi <V.Sethi at nxp.com>; Ye Li <ye.li at 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
> >