[MVEBU] SPI flash offset was depecrated?
Pali Rohár
pali at kernel.org
Tue Aug 2 14:00:51 CEST 2022
On Tuesday 02 August 2022 07:53:36 Tom Rini wrote:
> On Tue, Aug 02, 2022 at 01:43:07PM +0200, Pali Rohár wrote:
> > On Tuesday 02 August 2022 07:36:45 Tom Rini wrote:
> > > On Tue, Aug 02, 2022 at 11:27:25AM +0200, Pali Rohár wrote:
> > > > Hello! I have tested it without dm-pre-reloc on A385 Turris Omnia and
> > > > you are right. SPL cannot load proper U-Boot and throws error:
> > > >
> > > > Trying to boot from SPI
> > > > Invalid bus 0 (err=-19)
> > > > SPI probe failed.
> > > > SPL: failed to boot from all boot devices
> > > >
> > > > Stefan and Tom, it is possible to somehow "inject" dm-pre-reloc into spi
> > > > DTB SPL node during SPL compile time when CONFIG_SPL_SPI=y is enabled?
> > > >
> > > > Because really CONFIG_SPL_SPI=y option does not work without
> > > > dm-pre-reloc.
> > >
> > > Automatically? Not at this time, that's what -u-boot.dtsi files are for.
> >
> > This issue is arch/arm/mach-mvebu generic, not board specific. SPI NOR
> > node is defined in SoC .dtsi file, not in board dts file. -u-boot.dtsi
> > is board specific, right? Therefore if -u-boot.dtsi is used then this
> > setting needs to be included in every one mvebu soc -u-boot.dtsi file?
> > This does not look as an ideal solution.
>
> There's a few different -u-boot.dtsi files that may be included, see the
> logic in scripts/Makefile.lib. But if there's already a board one, it
> may need to #include the SoC one.
>
> --
> Tom
Now I see. First it tries board specific -u-boot.dtsi and then it
fallbacks to $(CONFIG_SYS_SOC)-u-boot.dtsi
CONFIG_SYS_SOC for Marvell is "mvebu".
So could we create a new file arch/arm/dts/mvebu-u-boot.dtsi and put
there all those dm-pre-reloc stuff and then include mvebu-u-boot.dtsi
into all existing mvebu board's -u-boot.dtsi files? Wold it work or is
there some other issue with it?
More information about the U-Boot
mailing list