[MVEBU] SPI flash offset was depecrated?

[MVEBU] SPI flash offset was depecrated?

[Tony Dinh]

Hi Stefan and Pali,

Sorry the question might be a bit trivial, but I could not find it in
the source tree. It's been a long time and I'm not up to date on this
subject. I recall a long time ago we needed to specify a SPI flash
offset for the u-boot image so SPL would know where to load it from. I
vaguely remember something about "return to BootROM and let the
BootROM load the u-boot image"? Is this applicable only when we kwboot
the u-boot-spl.kwb image, or also applicable to the u-boot payload on
SPI flash?

I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README

Update from original Marvell U-Boot to mainline U-Boot:
-------------------------------------------------------
The resulting image including the SPL binary with the full DDR setup
is "u-boot-spl.kwb".
To update the SPI NOR flash, please use the following command:
=> sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\
sf update 2000000 0 60000
...

But building this board I got 642K u-boot-spl.kwb. So perhaps the
instructions above are out of date, or 60000  meant to be just an
example to be adjusted to the real image size?

Could you point me in the right direction,  ie. which Kconfig option
deals with this at the moment, or is it automatically set when we
build MVEBU -boot-spl.kwb?

Thanks,
Tony

Re: [MVEBU] SPI flash offset was depecrated?

[Pali Rohár]

On Saturday 30 July 2022 15:13:05 Tony Dinh wrote:
> Hi Stefan and Pali,
> 
> Sorry the question might be a bit trivial, but I could not find it in
> the source tree. It's been a long time and I'm not up to date on this
> subject. I recall a long time ago we needed to specify a SPI flash
> offset for the u-boot image so SPL would know where to load it from.

Hello! Now upstream U-Boot build process does not need to know offset
where the proper U-Boot starts in SPI flash. SPL image determinate it at
runtime (by looking into kwbimage header stored in SPI flash) and load
proper U-Boot correctly.

> I vaguely remember something about "return to BootROM and let the
> BootROM load the u-boot image"? Is this applicable only when we kwboot
> the u-boot-spl.kwb image, or also applicable to the u-boot payload on
> SPI flash?

Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI
flash driver is compiled into SPL) or it can "return to BootROM" and let
BootROM to load proper U-Boot into RAM.

This is configurable by defconfig options at compile time. We have
tested that both options work fine. Using BootROM for loading U-Boot
from SPI flash is slower than using dedicated SPL drivers (probably
because BootROM read SPI at lower speed). But SPI flash drivers increase
SPL binary (usage of BootROM does not). So you can choose which option
you want -- either smaller SPL binary or faster U-Boot loading and
booting. To disable SPI flash drivers in SPL, just disable option
CONFIG_SPL_SPI.

UART booting requires BootROM for loading proper U-Boot. But now
upstream U-Boot generates universal u-boot-spl.kwb image which can be
either flashed into SPI flash or booted via kwboot tool.

You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It
is combined image of SPL and proper U-Boot with Marvell kwbimage header
(required by BootROM). So never flash u-boot.bin or spl.bin separately.

> I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README
> 
> Update from original Marvell U-Boot to mainline U-Boot:
> -------------------------------------------------------
> The resulting image including the SPL binary with the full DDR setup
> is "u-boot-spl.kwb".
> To update the SPI NOR flash, please use the following command:
> => sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\
> sf update 2000000 0 60000
> ...
> 
> But building this board I got 642K u-boot-spl.kwb. So perhaps the
> instructions above are out of date, or 60000  meant to be just an
> example to be adjusted to the real image size?

60000 should be there just "example" and you should replace it by real
image size.

> Could you point me in the right direction,  ie. which Kconfig option
> deals with this at the moment, or is it automatically set when we
> build MVEBU -boot-spl.kwb?
> 
> Thanks,
> Tony

Default Kconfig options for u-boot-spl.kwb should produce flashable
SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.

Re: [MVEBU] SPI flash offset was depecrated?

[Tony Dinh]

Hi Pali,

"flash u-boot.bin or spl.bin separately"

That's what we used to do many years ago! glad that we have a single
flashable image now, much more robust. Thanks for a clear and detailed
explanation!

Tony

On Sat, Jul 30, 2022 at 3:41 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 30 July 2022 15:13:05 Tony Dinh wrote:
> > Hi Stefan and Pali,
> >
> > Sorry the question might be a bit trivial, but I could not find it in
> > the source tree. It's been a long time and I'm not up to date on this
> > subject. I recall a long time ago we needed to specify a SPI flash
> > offset for the u-boot image so SPL would know where to load it from.
>
> Hello! Now upstream U-Boot build process does not need to know offset
> where the proper U-Boot starts in SPI flash. SPL image determinate it at
> runtime (by looking into kwbimage header stored in SPI flash) and load
> proper U-Boot correctly.
>
> > I vaguely remember something about "return to BootROM and let the
> > BootROM load the u-boot image"? Is this applicable only when we kwboot
> > the u-boot-spl.kwb image, or also applicable to the u-boot payload on
> > SPI flash?
>
> Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI
> flash driver is compiled into SPL) or it can "return to BootROM" and let
> BootROM to load proper U-Boot into RAM.
>
> This is configurable by defconfig options at compile time. We have
> tested that both options work fine. Using BootROM for loading U-Boot
> from SPI flash is slower than using dedicated SPL drivers (probably
> because BootROM read SPI at lower speed). But SPI flash drivers increase
> SPL binary (usage of BootROM does not). So you can choose which option
> you want -- either smaller SPL binary or faster U-Boot loading and
> booting. To disable SPI flash drivers in SPL, just disable option
> CONFIG_SPL_SPI.
>
> UART booting requires BootROM for loading proper U-Boot. But now
> upstream U-Boot generates universal u-boot-spl.kwb image which can be
> either flashed into SPI flash or booted via kwboot tool.
>
> You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It
> is combined image of SPL and proper U-Boot with Marvell kwbimage header
> (required by BootROM). So never flash u-boot.bin or spl.bin separately.
>
> > I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README
> >
> > Update from original Marvell U-Boot to mainline U-Boot:
> > -------------------------------------------------------
> > The resulting image including the SPL binary with the full DDR setup
> > is "u-boot-spl.kwb".
> > To update the SPI NOR flash, please use the following command:
> > => sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\
> > sf update 2000000 0 60000
> > ...
> >
> > But building this board I got 642K u-boot-spl.kwb. So perhaps the
> > instructions above are out of date, or 60000  meant to be just an
> > example to be adjusted to the real image size?
>
> 60000 should be there just "example" and you should replace it by real
> image size.
>
> > Could you point me in the right direction,  ie. which Kconfig option
> > deals with this at the moment, or is it automatically set when we
> > build MVEBU -boot-spl.kwb?
> >
> > Thanks,
> > Tony
>
> Default Kconfig options for u-boot-spl.kwb should produce flashable
> SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.

Re: [MVEBU] SPI flash offset was depecrated?

[Tony Dinh]

Hi Pali,

Flashed to SPI and booted successfully! With CONFIG_SPL_SPI=y so SPL
loads u-boot payload.

My observation: dm-preloc is also required using SPL SPI driver method:

&spi0 {
u-boot,dm-pre-reloc;
};

Perhaps it should be implied in Kconfig with a DM_xxx symbol if possible.

Thanks,
Tony

On Sat, Jul 30, 2022 at 4:04 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Pali,
>
> "flash u-boot.bin or spl.bin separately"
>
> That's what we used to do many years ago! glad that we have a single
> flashable image now, much more robust. Thanks for a clear and detailed
> explanation!
>
> Tony
>
> On Sat, Jul 30, 2022 at 3:41 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Saturday 30 July 2022 15:13:05 Tony Dinh wrote:
> > > Hi Stefan and Pali,
> > >
> > > Sorry the question might be a bit trivial, but I could not find it in
> > > the source tree. It's been a long time and I'm not up to date on this
> > > subject. I recall a long time ago we needed to specify a SPI flash
> > > offset for the u-boot image so SPL would know where to load it from.
> >
> > Hello! Now upstream U-Boot build process does not need to know offset
> > where the proper U-Boot starts in SPI flash. SPL image determinate it at
> > runtime (by looking into kwbimage header stored in SPI flash) and load
> > proper U-Boot correctly.
> >
> > > I vaguely remember something about "return to BootROM and let the
> > > BootROM load the u-boot image"? Is this applicable only when we kwboot
> > > the u-boot-spl.kwb image, or also applicable to the u-boot payload on
> > > SPI flash?
> >
> > Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI
> > flash driver is compiled into SPL) or it can "return to BootROM" and let
> > BootROM to load proper U-Boot into RAM.
> >
> > This is configurable by defconfig options at compile time. We have
> > tested that both options work fine. Using BootROM for loading U-Boot
> > from SPI flash is slower than using dedicated SPL drivers (probably
> > because BootROM read SPI at lower speed). But SPI flash drivers increase
> > SPL binary (usage of BootROM does not). So you can choose which option
> > you want -- either smaller SPL binary or faster U-Boot loading and
> > booting. To disable SPI flash drivers in SPL, just disable option
> > CONFIG_SPL_SPI.
> >
> > UART booting requires BootROM for loading proper U-Boot. But now
> > upstream U-Boot generates universal u-boot-spl.kwb image which can be
> > either flashed into SPI flash or booted via kwboot tool.
> >
> > You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It
> > is combined image of SPL and proper U-Boot with Marvell kwbimage header
> > (required by BootROM). So never flash u-boot.bin or spl.bin separately.
> >
> > > I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README
> > >
> > > Update from original Marvell U-Boot to mainline U-Boot:
> > > -------------------------------------------------------
> > > The resulting image including the SPL binary with the full DDR setup
> > > is "u-boot-spl.kwb".
> > > To update the SPI NOR flash, please use the following command:
> > > => sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\
> > > sf update 2000000 0 60000
> > > ...
> > >
> > > But building this board I got 642K u-boot-spl.kwb. So perhaps the
> > > instructions above are out of date, or 60000  meant to be just an
> > > example to be adjusted to the real image size?
> >
> > 60000 should be there just "example" and you should replace it by real
> > image size.
> >
> > > Could you point me in the right direction,  ie. which Kconfig option
> > > deals with this at the moment, or is it automatically set when we
> > > build MVEBU -boot-spl.kwb?
> > >
> > > Thanks,
> > > Tony
> >
> > Default Kconfig options for u-boot-spl.kwb should produce flashable
> > SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.

Re: [MVEBU] SPI flash offset was depecrated?

[Pali Rohár]

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.

On Saturday 30 July 2022 17:02:57 Tony Dinh wrote:
> Hi Pali,
> 
> Flashed to SPI and booted successfully! With CONFIG_SPL_SPI=y so SPL
> loads u-boot payload.
> 
> My observation: dm-preloc is also required using SPL SPI driver method:
> 
> &spi0 {
> u-boot,dm-pre-reloc;
> };
> 
> Perhaps it should be implied in Kconfig with a DM_xxx symbol if possible.
> 
> Thanks,
> Tony
> 
> On Sat, Jul 30, 2022 at 4:04 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >
> > Hi Pali,
> >
> > "flash u-boot.bin or spl.bin separately"
> >
> > That's what we used to do many years ago! glad that we have a single
> > flashable image now, much more robust. Thanks for a clear and detailed
> > explanation!
> >
> > Tony
> >
> > On Sat, Jul 30, 2022 at 3:41 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Saturday 30 July 2022 15:13:05 Tony Dinh wrote:
> > > > Hi Stefan and Pali,
> > > >
> > > > Sorry the question might be a bit trivial, but I could not find it in
> > > > the source tree. It's been a long time and I'm not up to date on this
> > > > subject. I recall a long time ago we needed to specify a SPI flash
> > > > offset for the u-boot image so SPL would know where to load it from.
> > >
> > > Hello! Now upstream U-Boot build process does not need to know offset
> > > where the proper U-Boot starts in SPI flash. SPL image determinate it at
> > > runtime (by looking into kwbimage header stored in SPI flash) and load
> > > proper U-Boot correctly.
> > >
> > > > I vaguely remember something about "return to BootROM and let the
> > > > BootROM load the u-boot image"? Is this applicable only when we kwboot
> > > > the u-boot-spl.kwb image, or also applicable to the u-boot payload on
> > > > SPI flash?
> > >
> > > Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI
> > > flash driver is compiled into SPL) or it can "return to BootROM" and let
> > > BootROM to load proper U-Boot into RAM.
> > >
> > > This is configurable by defconfig options at compile time. We have
> > > tested that both options work fine. Using BootROM for loading U-Boot
> > > from SPI flash is slower than using dedicated SPL drivers (probably
> > > because BootROM read SPI at lower speed). But SPI flash drivers increase
> > > SPL binary (usage of BootROM does not). So you can choose which option
> > > you want -- either smaller SPL binary or faster U-Boot loading and
> > > booting. To disable SPI flash drivers in SPL, just disable option
> > > CONFIG_SPL_SPI.
> > >
> > > UART booting requires BootROM for loading proper U-Boot. But now
> > > upstream U-Boot generates universal u-boot-spl.kwb image which can be
> > > either flashed into SPI flash or booted via kwboot tool.
> > >
> > > You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It
> > > is combined image of SPL and proper U-Boot with Marvell kwbimage header
> > > (required by BootROM). So never flash u-boot.bin or spl.bin separately.
> > >
> > > > I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README
> > > >
> > > > Update from original Marvell U-Boot to mainline U-Boot:
> > > > -------------------------------------------------------
> > > > The resulting image including the SPL binary with the full DDR setup
> > > > is "u-boot-spl.kwb".
> > > > To update the SPI NOR flash, please use the following command:
> > > > => sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\
> > > > sf update 2000000 0 60000
> > > > ...
> > > >
> > > > But building this board I got 642K u-boot-spl.kwb. So perhaps the
> > > > instructions above are out of date, or 60000  meant to be just an
> > > > example to be adjusted to the real image size?
> > >
> > > 60000 should be there just "example" and you should replace it by real
> > > image size.
> > >
> > > > Could you point me in the right direction,  ie. which Kconfig option
> > > > deals with this at the moment, or is it automatically set when we
> > > > build MVEBU -boot-spl.kwb?
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > > Default Kconfig options for u-boot-spl.kwb should produce flashable
> > > SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.

Re: [MVEBU] SPI flash offset was depecrated?

[Tom Rini]

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

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [MVEBU] SPI flash offset was depecrated?

[Pali Rohár]

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.

Re: [MVEBU] SPI flash offset was depecrated?

[Tom Rini]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [MVEBU] SPI flash offset was depecrated?

[Pali Rohár]

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?

Re: [MVEBU] SPI flash offset was depecrated?

[Tom Rini]

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

On Tue, Aug 02, 2022 at 02:00:51PM +0200, Pali Rohár wrote:
> 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?

You'll want to run some tests to make sure that yes you really want
a given change to apply to all mvebu platforms, but yes, that's the
idea.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]