On Tue, Jan 24, 2023 at 03:44:53PM -0700, Simon Glass wrote:
Hi Sudeep,
On Tue, 24 Jan 2023 at 04:30, Sudeep Holla sudeep.holla@arm.com wrote:
Hi Simon,
[...]
Not really. I think I have not conveyed the setup details properly. Let me try to explain with 2 hopefully simple examples:
Consider a system with a power controller running its own firmware and OS(or any other application software including U-Boot) interacting with it to get the required power resource access/modification.
One such thing is CPU operating points(OPP). Typically on old systems, these are listing in the DT and OSPM drives them completely. Now on the newer systems like the one I am presenting, ideally we need to get the list of OPP from the f/w at runtime and use the information to drive it.
Suppose we have these information statically built into DT, then if the firmware is upgraded and there is change in the OPP set or if the f/w detects some configuration(bios/similar) that requires change in the OPP set presented to the OSPM(or any other users), then the static info built in the DT is stale or wrong. And hence the use of DT in such a configuation or system is not correct unless DT is populated on the fly interacting with the firmware before DT is consumed by the users.
This was one example which I was referring when I said I don't want to use the DT info over live firmware information.
So you need to rebuild the firmware component to update the information? That's not nice.
Well, I understand the firmware component itself can fetch these data from the DT, but not all firmware are built with DT support to start with(for simple reasons like they need to run with very limited ram in orders of few kB).
Even if they did, they might have independent DT blob with the data required for the firmware to function.
The holy grail of system DT is yet to see the reality IMO.
And this rebuild is very much needed during development and updating DT for the data makes no sense to me when the Linux kernel can query the same through standard interfaces defined by the firmware. There can be no argument to no use the interface to fetch the data runtime as it will be most accurate than any other data. DT may have more data or data that firmware decided not to support runtime for various reasons(I think I mentioned couple earlier). So, strict no to static data from the DT and even if some boot code updates it, I trust getting it from the firmware if and when possible. The interface has been added considering all these. It is agnostic of firmware designs and implementation. Assuming DT support in the firmware just makes these unnecessarily hard.
These parameters need to be factored out of the code. The best way to do that is to put them in the DT. The DT should configure all of firmware. It should not be necessary to rebuild all the code to update a few parameters in the build.
Completely agreed in terms of design, but in reality not all implementations want to follow that for reasons of their own.
Also these parameters should not be 'buried' in the code. I'd really like you to consider the difference between code and data, with the (configurable) data being in DT.
Again agreed, but this is something we are enforcing in the Linux kernel and U-Boot. It is not universal and IMO it may never be. The firmware interfaces are defined to cope up with these and they are bound to stay. DT can never replace it. Further like ACPI, these firmware interface don't just provide static data, it also supports run-time. So there is some advantage and are here to stay. Preferring DT data for sake of uniformity and simplicity are not going to sway the wind away from these interface to the DT. I am definitely not for it for all the reasons I have already mentioned.
- Now the FF-A case, if the list of partitions on the system is listed in the DT and there is change in that list due to various reasons(firmware upgrade, reconfiguration, resource disabled for a specific reason,...etc) then the list will be stale when presented to the user(OSPM/Linux/U-Boot) if it is not updated on the fly before the DT data is consumed.
U-Boot can set this up in the DT if that is what you want, but I think you are confusing two things:
- what is available to use (i.e. drivers or code that is compiled in)
- what we actually want to use and how each piece if configured (this
should be handled at runtime)
No I understand all these and advantages you have been mentioning. But there is also other side of the story and that's what I have been trying to group as firmware interface.
Imagine your code is a Linux kernel. We don't hard-code these sorts of settings in Linux.
Yes definitely and I agree as mentioned quite a few times above. But that doesn't change a bit as already mentioned.
Since in both the cases the firmware provides interface to the users to get the information at runtime, I am against using the DT as source of information.
Well we should figure out a time or place to talk about this, as I believe this is heading down the wrong path.
If you strongly believe that, then you need to speak with architects who are designing and standardising these interfaces taking with the various Arm silicon vendors/partners. I am also sure your employer is one of them and have their means to get in touch with the right people.
As firmware gets more complex,
Indeed, they are already getting complex and it is necessitating the need for such interfaces as we are dealing with dynamic component as well not just static to use DT as standard and unified mechanism.
we need a unified configuration mechanism and proper visibility into each component and what it is doing. They need to act as a unified whole, not as a collection of blobs that might conflict.
Well that would be ideal and I would have agreed with that few years back but not now as I have seen the evolution in the firmware space(that I am involved and visible to me) and involved in the development of some of these interface.
Main point based on these discussion is that you are looking at just the static data needed and how DT can be used. The interfaces are also dealing with the dynamic configurations and while at it they better deal with static data as well instead of using alternatives like DT. I am not against DT for the reasons you think it must be used, it is just that here it is not sufficient.
-- Regards, Sudeep