Re: [PATCH v2 10/10] arm64: dts: imx93-kontron: Enable ELE firmware driver

[Frieder Schrempf]

On 22.07.26 17:09, Alexander Stein wrote:
> Am Mittwoch, 22. Juli 2026, 16:49:10 CEST schrieb Frieder Schrempf:
>> On 14.07.26 14:37, Alexander Stein wrote:
>>> Am Dienstag, 14. Juli 2026, 14:33:50 CEST schrieb Francesco Dolcini:
>>>> On Tue, Jul 14, 2026 at 02:06:38PM +0200, Alexander Stein wrote:
>>>>> Am Dienstag, 14. Juli 2026, 11:33:54 CEST schrieb Francesco Dolcini:
>>>>>> On Tue, Jul 14, 2026 at 10:43:56AM +0200, Frieder Schrempf wrote:
>>>>>>> On 14.07.26 10:32, Francesco Dolcini wrote:
>>>>>>>> On Tue, Jul 14, 2026 at 10:09:11AM +0200, Frieder Schrempf wrote:
>>>>>>>>> Hi Francesco,
>>>>>>>>>
>>>>>>>>> On 14.07.26 08:59, Francesco Dolcini wrote:
>>>>>>>>>> Hello Frieder,
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 13, 2026 at 04:53:46PM +0200, Frieder Schrempf wrote:
>>>>>>>>>>> From: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>
>>>>>>>>>>>
>>>>>>>>>>> Add the ELE firmware API node and pass its handle to the OCOTP
>>>>>>>>>>> driver. This allows us to gain read/write access to the OTP fuses.
>>>>>>>>>>
>>>>>>>>>> This seems something we should have in the soc dtsi (imx93/imx91), it
>>>>>>>>>> does not seems board specific.
>>>>>>>>>
>>>>>>>>> My original intention was to move as much as possible into the SoC dtsi.
>>>>>>>>> The problem is that the memory node is somewhat board specific due to
>>>>>>>>> the DDR. And I can't move the firmware node into the SoC dtsi and assign
>>>>>>>>> the memory node in the board dts as the checks for all boards not
>>>>>>>>> specifying a memory node would fail then.
>>>>>>>>
>>>>>>>> What is the reason to have this memory address different on various
>>>>>>>> boards? Can we have a default in the soc dtsi, and allow the board to
>>>>>>>> override the address if needed?
>>>>>>>
>>>>>>> There is no real point in having different addresses on different
>>>>>>> boards. But the node describes memory that is physically on the board
>>>>>>> and not on the SoC. And I think that is why DT maintainers want to have
>>>>>>> it in the board DT. It's the same with the memory nodes for the
>>>>>>> remoteproc drivers to communicate with the Cortex M-Cores in the i.MX.
>>>>>>> But maybe I'm wrong and if there is a possibility to move this to the
>>>>>>> SoC DT I will definitely take it.
>>>>>
>>>>> We are talking about reserved memory, so this is highly board-specific.
>>>>> So for different hardware variants with different amount of RAM you have to
>>>>> go for the minimum anyway.
>>>>>
>>>>>>>>
>>>>>>>> Or can't you add the address in all the boards, and keep everything else
>>>>>>>> in the soc dtsi?
>>>>>>> This could be a possible way, yes. In that case maybe we could even
>>>>>>> create a generic dtsi to contain such defaults for all boards.
>>>>>>
>>>>>> I would go for this solution, we could have something like
>>>>>> `k3-am62-ti-ipc-firmware.dtsi`, include it from all the boards, have a
>>>>>> sane default memory address, and have an easy way to override the memory
>>>>>> address from the board dts, if needed.
>>>>>
>>>>> So what is a sane default? At the end of the minimal possible RAM?
>>>>> I'm not really fond of something you have to make sure matches to your
>>>>> hardware, but won't raise an error if you forgot.
>>>>>
>>>>> How about providing defaults for the SoC part and users have to provide their
>>>>> memory on board-level? Similar to the VPU nodes on imx8qm/imx8qxp. There you
>>>>> have to specify memory-region in your board.
>>>>
>>>> I am personally ok with both solution.
>>>>
>>>> I think it is easy to have a sane default in this case. You cannot have
>>>> less than 256MiB in practice, and this is just about the offset, is not
>>>> that you are going to want more memory reserved if the board has more
>>>> memory available.
>>>>
>>>> At the same time, having the memory range in the board dts is also ok to
>>>> me.
>>>
>>> I'm just saying, because we had lots of problem with assumed offsets/length
>>> in code/DT for NXP boards. They usually come with big/huge amount of RAM.
>>> This breaks for all hardware using a small amount of RAM.
>>> So it's better to not have a default than silently breaking things because
>>> the default doesn't match.
>> I'm revisiting this now and think about how to do it. I would like to
>> put a default memory node in the dtsi that dynamically puts the buffer
>> somewhere in the first 256MB. I would include the dtsi in all
>> i.MX91/i.MX93 boards. I think this should work for all boards.
>>
>> If I put everything, but the memory node in the default dtsi, as
>> Alexander proposed, I think I will run into DT validation errors if not
>> all boards provide a memory node, as the property is mandatory.
>>
>> Is there anything I might be missing?
> 
> Mh, isn't that exactly the situation you want to catch as a DT author?
> Raise errors early if something is missing in the DT.
> I would go that way that for all currently existing boards an corresponding
> memory node could be added, no? All coming boards will need to provide it..
> 
Ok, but what would be the benefit compared to putting the node in the
common dtsi and including that for all existing boards? People adding
new boards would just copy the memory node from some other board anyway.
This way we could at least avoid the duplication.

And as I don't know all the details for the existing boards, I can't
provide anything better than a default memory node.