Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
And this is to be included in the DT Technical Report.
Cheers
FF
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
Rob
[1] https://lore.kernel.org/linux-devicetree/20201204121137.2966778-1-sudeep.hol...
And this is to be included in the DT Technical Report.
Cheers
FF
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Le lun. 21 déc. 2020 à 18:39, Rob Herring robherring2@gmail.com a écrit :
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective:
https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
well I think it is still valid as Linux will not see the full system device tree. It will only see the part that is related to the partition.
But we may need some clarification...
Rob
[1] https://lore.kernel.org/linux-devicetree/20201204121137.2966778-1-sudeep.hol...
And this is to be included in the DT Technical Report.
Cheers
FF
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Mon, 21 Dec 2020, François Ozog wrote:
Le lun. 21 déc. 2020 à 18:39, Rob Herring robherring2@gmail.com a écrit :
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
well I think it is still valid as Linux will not see the full system device tree. It will only see the part that is related to the partition.
But we may need some clarification...
The example on the mailing list is the following:
ffa { compatible = "arm,ffa-1.0";
ffa_partition0 { compatible = "arm,ffa-1.0-partition"; uuid = "12345678-9abc-def0-1234-56789abcdef0"; }; };
Also looking at [2], it is true that secure partitions look like something that we should be able to describe in system device tree. We have been focusing mostly on AMP in system device tree so far, but the goal is to describe hypervisors and secure world "execution domains" too. Secure partitions seem to be close enough to the concept to be describable with an "openamp,domain" compatible node.
[2] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti...
Rob [1] https://lore.kernel.org/linux-devicetree/20201204121137.2966778-1-sudeep.holla@arm.com/ > > And this is to be included in the DT Technical Report. > > Cheers > > FF > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture-- [uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&export=download] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Mon, Dec 21, 2020 at 10:38:52AM -0700, Rob Herring wrote:
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
Thanks Rob for including me. I wasn't aware of such formal proposal of bindings from the firmware/system perspective. I agree and happy to re-use the bindings if required.
However, the idea with bindings for OSPM(mainly kernel with no hypervisor) was to keep it minimal or even zero(which is not possible as the specification lacks any mechanism to get the UUID list for the partitions.
Also, where are these system/firmware DT bindings getting reviewed ? There are so many bindings used in some of these firmware/systems without much(even zero) review of them on a list, so I am bit worried to use them as is. Should they not get reviewed on some list if not existing device-tree mailing list. Sorry if they are on some list which I am not yet part of, happy to get added to them.
-- Regards, Sudeep
On Mon, 4 Jan 2021, Sudeep Holla wrote:
On Mon, Dec 21, 2020 at 10:38:52AM -0700, Rob Herring wrote:
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
Thanks Rob for including me. I wasn't aware of such formal proposal of bindings from the firmware/system perspective. I agree and happy to re-use the bindings if required.
However, the idea with bindings for OSPM(mainly kernel with no hypervisor) was to keep it minimal or even zero(which is not possible as the specification lacks any mechanism to get the UUID list for the partitions.
Also, where are these system/firmware DT bindings getting reviewed ? There are so many bindings used in some of these firmware/systems without much(even zero) review of them on a list, so I am bit worried to use them as is. Should they not get reviewed on some list if not existing device-tree mailing list. Sorry if they are on some list which I am not yet part of, happy to get added to them.
They have been discussed during the System Device Tree calls and on the system-dt mailing list: https://lists.openampproject.org/mailman/listinfo/system-dt. We have recordings and minutes of the meetings. Have a look at this video for an overview on System Device Tree: https://connect.linaro.org/resources/san19/san19-115/.
Most of the times System Device Tree is not used at runtime and Linux is typically not the primary target. System-DT is most often used at build time / configuration time before the target board is turned on. A tool named "Lopper" (https://github.com/devicetree-org/lopper) generates multiple traditional Device Trees from a single System Device Tree.
Things don't always look exactly the same in System Device Tree compared to regular Device Trees. So, we don't have to necessarely reuse the openamp,domain bindings as they are today. However, it would be good to align them where it makes sense to reduce complexity. We have gone through a similar exercise for the RemoteProc bindings and I think it improved both System-DT and regular DT as a result.
I would like to hear a bit more about your use-case to plot together the best course of action.
Cheers,
Stefano
On Thu, Jan 07, 2021 at 02:03:36PM -0800, Stefano Stabellini wrote:
On Mon, 4 Jan 2021, Sudeep Holla wrote:
On Mon, Dec 21, 2020 at 10:38:52AM -0700, Rob Herring wrote:
On Fri, Dec 18, 2020 at 9:43 PM François Ozog francois.ozog@linaro.org wrote:
Hi
I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manife...
That's not what we're reviewing upstream[1].
Thanks Rob for including me. I wasn't aware of such formal proposal of bindings from the firmware/system perspective. I agree and happy to re-use the bindings if required.
However, the idea with bindings for OSPM(mainly kernel with no hypervisor) was to keep it minimal or even zero(which is not possible as the specification lacks any mechanism to get the UUID list for the partitions.
Also, where are these system/firmware DT bindings getting reviewed ? There are so many bindings used in some of these firmware/systems without much(even zero) review of them on a list, so I am bit worried to use them as is. Should they not get reviewed on some list if not existing device-tree mailing list. Sorry if they are on some list which I am not yet part of, happy to get added to them.
They have been discussed during the System Device Tree calls and on the system-dt mailing list: https://lists.openampproject.org/mailman/listinfo/system-dt. We have
Thanks I have now subscribed.
recordings and minutes of the meetings. Have a look at this video for an overview on System Device Tree: https://connect.linaro.org/resources/san19/san19-115/.
I had a fair understanding of what was happening, wasn't aware the degree of momentum there. Good refresher though.
Most of the times System Device Tree is not used at runtime and Linux is typically not the primary target. System-DT is most often used at build time / configuration time before the target board is turned on. A tool named "Lopper" (https://github.com/devicetree-org/lopper) generates multiple traditional Device Trees from a single System Device Tree.
And I assume and expect the *traditional Device Trees* at-least the ones fed to Linux follow all the bindings discussed on the device-tree mailing list.
Things don't always look exactly the same in System Device Tree compared to regular Device Trees. So, we don't have to necessarely reuse the openamp,domain bindings as they are today.
Good to know, not sure what @Rob would like to see(expect) in terms of alignment here. You seem to have agreed on the FFA Linux bindings I have proposed. Let me know if that is not the case.
However, it would be good to align them where it makes sense to reduce complexity. We have gone through a similar exercise for the RemoteProc bindings and I think it> improved both System-DT and regular DT as a result.
I would like to hear a bit more about your use-case to plot together the best course of action.
Sure. Happy to collaborate and discuss. I wanted to check if we can have a brief discussion on this in the next call on Fri 29th Jan if possible and time permits.
-- Regards, Sudeep
boot-architecture@lists.linaro.org
-
François Ozog -
Rob Herring -
Stefano Stabellini -
Sudeep Holla