RE:Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Thursday, December 23, 2021 3:05 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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@lists.denx.de On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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.
Regards, Sahil Malhotra
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.
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.
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.
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?
Andrey, do you know how this works on imx?
-michael
Hi Michael,
Sorry for delayed response. Please find my response inline.
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Thursday, January 6, 2022 1:10 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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
Hi Michael,
Gentle reminder on this patch set.
Regards, Sahil Malhotra
-----Original Message----- From: Sahil Malhotra (OSS) Sent: Friday, February 4, 2022 4:58 PM To: Michael Walle michael@walle.cc; Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@nxp.com Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael,
Sorry for delayed response. Please find my response inline.
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Thursday, January 6, 2022 1:10 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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
Hi Sahil,
sorry I missed this. I'm also putting Tom on CC because I don't really have an answer or maybe I'm lacking the whole picture, too.
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 ?
At least without touching that code path, yes, that is how i read the current code.
But how can we make sure that DTB overlay and DTB on which DTB overlay is applied are compatible ?
I doubt you can do that and therefore, I'm not sure about this whole optee passes us an overlay and we apply it thing. Why don't you just pass the device tree to optee and optee will change it. Because that isn't ready at the moment for any boards but the LS1028A? I'd advise on working on that then and syncing the device trees and use a common one for u-boot and linux (and optee?).
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`
You'd need to get Rob's opinion on that.
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
Or at least on the sl28 (LS1028A) it is: u-boot spl -> u-boot -> linux or u-boot spl -> atf bl31 [-> optee]* -> u-boot -> linux
* I'm really not sure about the optee part though. I just tested it briefly some time ago.
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.
Yeah, I noticed last time that this DTB_OVERLAY is a thing in optee, thus I wrote in the beginning of this mail. I might not have the complete picture here; as in how the dtb is passed around u-boot, optee and linux and where the dtb even comes from. TBH this patch looks like what can we do with what we have *right now*. Like a shortcut to getting the problem solved. But IMHO it is creating a much wider range of different problems then.
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.
This is not true for the LS1028A and it is doable for the other layerscape SoCs too. Ok, I'm not sure about optee here.
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.
I'm not sure about the latest CAAM patches for u-boot which are going to use the device tree in u-boot, so they have the same problem I guess?
-michael
Hi Sahil,
(and happy new year ;-)
On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) < sahil.malhotra@oss.nxp.com> wrote:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Thursday, December 23, 2021 3:05 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément
Faure
clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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@lists.denx.de On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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
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@lists.denx.de On Behalf Of François Ozog Sent: Thursday, January 6, 2022 1:18 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: Michael Walle michael@walle.cc; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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@oss.nxp.com> wrote:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Thursday, December 23, 2021 3:05 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément
Faure
clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain
u- boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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@lists.denx.de On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) sahil.malhotra@oss.nxp.com Cc: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Clément Faure clement.faure@nxp.com; Gaurav Jain gaurav.jain@nxp.com; Pankaj Gupta pankaj.gupta@nxp.com; Priyanka Jain priyanka.jain@nxp.com; u-boot@lists.denx.de; Varun Sethi V.Sethi@nxp.com; Ye Li ye.li@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
participants (3)
-
François Ozog -
Michael Walle -
Sahil Malhotra (OSS)