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

[Sahil Malhotra (OSS)]

Hi Michael,

Sorry for delayed response.
Please find my response inline.

> -----Original Message-----
> From: Michael Walle <michael at walle.cc>
> Sent: Thursday, January 6, 2022 1:10 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: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
> 
> Hi Sahil,
> 
> Am 2022-01-06 07:09, schrieb Sahil Malhotra (OSS):
> 
> >> 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.
> 
> That doesn't mean it is ok to diverge again. I put a lot of effort in syncing
> uboot's LS1028A device tree with linux.
Yes, that’s true we should not diverge again if they are already synced.


> > 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.
> 
> Sorry I can't advise you with that. There is board_fix_fdt() maybe that will
> help. But I'm not conviced this is the correct approach, see below.
Ok, I looked at the board_fix_fdt() and in that we can put the code for modifying
the uboot DTB.
But the same overlay which we are going to apply on linux DTB should get applied
On uboot DTB, and that can happen only when we have same DTBs both in Linux
and u-boot.

I checked the uboot and Linux DTBs for LS platforms, except LS1028, all other
platforms have a lot of difference in them.

So we will not be able to apply the same DTB overaly which we get from OP-TEE on
both Linux and uboot.

For now this can only happen for LS1028 platform, if you want we can do this,
But it will be incomplete in my opinion as it will not enable all the boards.
We need to work on them again.

> 
> >> > 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.
> 
> I don't think this is what happens here. fdt_overlay_apply() will mark the fdt
> as damaged and there will be no fdt at all.
Ok, got your point, If we have fragment in DTB overlay to modify let's say `status` of
CAAM job ring, and CAAM job ring node does not exist in the DTB on which overlay is 
going to be applied, In that case the DTB will be marked as damaged and it will stop
booting of the board, right ?
But how can we make sure that DTB overlay and DTB on which DTB overlay is applied
are compatible ?
Maybe some DTB version check or something like that, when OP-TEE creates a DTB overlay,
It indicates in the overlay that this can be applied on only DTBs with version more than `X`


> > 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.
> 
> Again. Is there any documentation on how this should all work together?
> Where does optee get its device tree from? Shouldn't it be the same device
> tree as u-boot and linux? Shouldn't optee modify the device tree in place
> before jumping back to u-boot?
Here on LS platforms: Boot Flow is like ATF-> OP-TEE-> ATF->Uboot-> Linux

Currently for LS platforms, OP-TEE don't use DTBs except for LX2160A.
And I am talking about the other platforms except LX2160 for now.
So all peripherals base addresses are currently hardcoded.

But OP-TEE uses some of the peripherals, and this information needs to 
be passed to following components uboot and linux so that they don't use
the same peripherals.

One of the case is CAAM Job Ring. OP-TEE always use CAAM Job Ring 3, and it
needs to communicate this thing to following components uboot so that they don’t
try to use the same peripherals as used by OP-TEE,
So, we enabled DTB_OVERLAY option in OP-TEE and will write CAAM Job Ring 3 to be
disabled in that DTB overlay.

The address where this DTB overlay will be created is passed by ATF which ATF will
pass on to uboot also.

When control reaches uboot, It  will use that DTB overlay and apply it on Linux DTB
which we passed via tftp on board.

Currently there is no common DTB which is being used by all the components,
OP-TEE, Uboot, Linux all are using their own copies of DTB.

Hope I answered your queries, Please let me know if you need more information.

> Andrey, do you know how this works on imx?
Actually, I took reference from imx only, They are also just applying DTB overlay on linux DTB as of now.
They are not modifying the uboot DTB according to the DTB overlay.


Regards,
Sahil Malhotra