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

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

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/