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

[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?

Thanks for your feedback!