Hi Michael
Le lun. 29 nov. 2021 à 18:47, Michael Walle michael@walle.cc a écrit :
Hi Sahil,
Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY.
I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP.
Ok. What will the overlay do? Could you give an example?
This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it.
Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too?
Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting.
If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no?
Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot.
But we should do the correct thing, so that u-boot and linux doesn't see a different version of the device tree.
Outside any runtime context there should be a reference for hardware description. That non-runtime reference need to be firmware and OS agnostic and document what devices are seen by each. For instance a board with serdes should have serdes nodes and disabled nodes that corresponds to possible nodes (pci, network, storage…) created as a result of the serdes configuration. One would expect firmware does it but nothing prevent an OS to do it. Those nodes should not refer to U-Boot or Linux, just firmware and operating system. Furthermore, there may be multiple totally independent computing domains on a single board: Cortex-a + r/m, multiple cortex-a and cortex-r/m and other cores. So the reference hardware description should encompass all and provide consistent description of resources available in multiple domains (say some hardware mail box and why not some sram). To be consumed by different operating systems. Linux, if the operating system of choice for that platform, will only see a portion of the total hardware description. That part may be further reduced at runtime for various legislative reasons, one of them being presented by Sahil.
For your above comment, were you referring to this reference hardware description of the cortex-a domain of the board ?
Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/
-michael