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

[François Ozog]

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
>