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

[Francesco Dolcini]

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 <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.

What would be the reason for not wanting to have such memory node in the
first 256MiB defined in this dtsi include?

Francesco