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

On 22.07.26 18:12, Francesco Dolcini wrote:
> On Wed, Jul 22, 2026 at 05:27:00PM +0200, Frieder Schrempf wrote:
>> 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 <[email protected]>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
> 
> What would be the reason for not wanting to have such memory node in the
> first 256MiB defined in this dtsi include?
> 
I don't see any at the moment and that's why I'm going to send a v3 that
proposes this solution.