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

2021-12-23 Thread Michael Walle

Hi Sahil,

Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS):

-Original Message-
From: U-Boot  On Behalf Of Michael Walle
Sent: Monday, December 20, 2021 6:23 PM
To: Sahil Malhotra (OSS) 
Cc: ZHIZHIKIN Andrey ; Clément
Faure ; Gaurav Jain ;
Pankaj Gupta ; Priyanka Jain
; u-boot@lists.denx.de; Varun Sethi
; Ye Li 
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.

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.

-michael


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

2021-12-23 Thread Sahil Malhotra (OSS)
Hi Michael,

> -Original Message-
> From: U-Boot  On Behalf Of Michael Walle
> Sent: Monday, December 20, 2021 6:23 PM
> To: Sahil Malhotra (OSS) 
> Cc: ZHIZHIKIN Andrey ; Clément
> Faure ; Gaurav Jain ;
> Pankaj Gupta ; Priyanka Jain
> ; u-boot@lists.denx.de; Varun Sethi
> ; Ye Li 
> 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.

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.

Regards,
Sahil Malhotra