[MVEBU] SPI flash offset was depecrated?
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
participants (3)
-
Pali Rohár -
Tom Rini -
Tony Dinh