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

[Alexander Stein <alexander.stein@ew.tq-group.com>]

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]

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@kontron.de>
> > > > >>>>
> > > > >>>> 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.

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/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]