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

[François Ozog]

Hi Michael

Le lun. 29 nov. 2021 à 18:47, Michael Walle <michael at 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
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog