[U-Boot] [PATCH] arm: mx6: specify SPL padding
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
---
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/* + * SPL starts at 1KB (ROM offset), hence we need to pad SPL up to 68KB so + * that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD card. + * Required for targets such as u-boot-with-spl.imx. + */ +#define CONFIG_SPL_PAD_TO 0x11000 #endif
/* SATA support */
Hi Stefan
On Mon, 2016-11-14 at 18:06 -0800, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/*
- SPL starts at 1KB (ROM offset), hence we need to pad SPL up to
68KB so
- that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD
card.
- Required for targets such as u-boot-with-spl.imx.
- */
+#define CONFIG_SPL_PAD_TO 0x11000 #endif /* SATA support */
This has been brought up already: https://www.mail-archive.com/u-boot@lists.denx.de/msg228246.html I agreed with Marek that this might disrupt other boot sources (NOR/SPI/ ...) which may or may not decide to use another offset between SPL and U-Boot. Thus it is advisable to move that define to the individual board configuration where one knows for what boot device one wants to use the combined u-boot-with-spl.imx binary.
Max
P.S. Sorry for the noise to your individual mail addresses, I had issues getting to the mailinglist through gmane.
On Tue, Nov 15, 2016 at 09:59:22AM +0000, Max Krummenacher wrote:
Hi Stefan
On Mon, 2016-11-14 at 18:06 -0800, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/*
- SPL starts at 1KB (ROM offset), hence we need to pad SPL up to
68KB so
- that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD
card.
- Required for targets such as u-boot-with-spl.imx.
- */
+#define CONFIG_SPL_PAD_TO 0x11000 #endif /* SATA support */
This has been brought up already: https://www.mail-archive.com/u-boot@lists.denx.de/msg228246.html I agreed with Marek that this might disrupt other boot sources (NOR/SPI/ ...) which may or may not decide to use another offset between SPL and U-Boot. Thus it is advisable to move that define to the individual board configuration where one knows for what boot device one wants to use the combined u-boot-with-spl.imx binary.
I'm going to have to disagree with Marek here then. Looking over the explanation in include/configs/imx6_spl.h we have: 1KiB up front "wasted" for a partition table 4KiB up next for the ROM-mandated header 64KiB for SPL itself, which is our max size, unconditionally set above this bit of context. But it is the lowest common denominator in terms of IRAM size in the families.
Which brings us to the SPL_PAD_TO above, 68KiB. We cannot go lower than this. No one is changing any of this either today nor setting SPL_PAD_TO so u-boot-with-spl.imx isn't usable today. None of this breaks using separate files.
On 2016-11-15 08:12, Tom Rini wrote:
On Tue, Nov 15, 2016 at 09:59:22AM +0000, Max Krummenacher wrote:
Hi Stefan
On Mon, 2016-11-14 at 18:06 -0800, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/*
- SPL starts at 1KB (ROM offset), hence we need to pad SPL up to
68KB so
- that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD
card.
- Required for targets such as u-boot-with-spl.imx.
- */
+#define CONFIG_SPL_PAD_TO 0x11000 #endif /* SATA support */
This has been brought up already: https://www.mail-archive.com/u-boot@lists.denx.de/msg228246.html I agreed with Marek that this might disrupt other boot sources (NOR/SPI/ ...) which may or may not decide to use another offset between SPL and U-Boot. Thus it is advisable to move that define to the individual board configuration where one knows for what boot device one wants to use the combined u-boot-with-spl.imx binary.
I'm going to have to disagree with Marek here then. Looking over the explanation in include/configs/imx6_spl.h we have: 1KiB up front "wasted" for a partition table 4KiB up next for the ROM-mandated header 64KiB for SPL itself, which is our max size, unconditionally set above this bit of context. But it is the lowest common denominator in terms of IRAM size in the families.
Which brings us to the SPL_PAD_TO above, 68KiB. We cannot go lower than this. No one is changing any of this either today nor setting SPL_PAD_TO so u-boot-with-spl.imx isn't usable today. None of this breaks using separate files.
I agree here, the pad seems pretty natural and should be usable across boot devices. In fact, it probably should not be inside CONFIG_SPL_MMC_SUPPORT, but at the top along with CONFIG_SPL_MAX_SIZE.
So far, include/config_fallbacks.h defined SPL_PAD_TO to 64KiB, which renders u-boot-with-spl.imx unusable for SD/eMMC boot. Other boot devices probably know a similar define (CONFIG_SYS_NAND_U_BOOT_OFFS). Judging from existing board files it does not seem that anybody relied on that 64kB padding so far... I guess if a board with a different boot device wants to make use of u-boot-with-spl.imx, then it should make sure that the offset is set correctly in its board file (e.g. using #define CONFIG_SYS_NAND_U_BOOT_OFFS SPL_PAD_TO).
Marek?
-- Stefan
On 11/15/2016 06:42 PM, Stefan Agner wrote:
On 2016-11-15 08:12, Tom Rini wrote:
On Tue, Nov 15, 2016 at 09:59:22AM +0000, Max Krummenacher wrote:
Hi Stefan
On Mon, 2016-11-14 at 18:06 -0800, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/*
- SPL starts at 1KB (ROM offset), hence we need to pad SPL up to
68KB so
- that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD
card.
- Required for targets such as u-boot-with-spl.imx.
- */
+#define CONFIG_SPL_PAD_TO 0x11000 #endif
/* SATA support */
This has been brought up already: https://www.mail-archive.com/u-boot@lists.denx.de/msg228246.html I agreed with Marek that this might disrupt other boot sources (NOR/SPI/ ...) which may or may not decide to use another offset between SPL and U-Boot. Thus it is advisable to move that define to the individual board configuration where one knows for what boot device one wants to use the combined u-boot-with-spl.imx binary.
I'm going to have to disagree with Marek here then. Looking over the explanation in include/configs/imx6_spl.h we have: 1KiB up front "wasted" for a partition table 4KiB up next for the ROM-mandated header 64KiB for SPL itself, which is our max size, unconditionally set above this bit of context. But it is the lowest common denominator in terms of IRAM size in the families.
Which brings us to the SPL_PAD_TO above, 68KiB. We cannot go lower than this. No one is changing any of this either today nor setting SPL_PAD_TO so u-boot-with-spl.imx isn't usable today. None of this breaks using separate files.
I agree here, the pad seems pretty natural and should be usable across boot devices. In fact, it probably should not be inside CONFIG_SPL_MMC_SUPPORT, but at the top along with CONFIG_SPL_MAX_SIZE.
So far, include/config_fallbacks.h defined SPL_PAD_TO to 64KiB, which renders u-boot-with-spl.imx unusable for SD/eMMC boot. Other boot devices probably know a similar define (CONFIG_SYS_NAND_U_BOOT_OFFS). Judging from existing board files it does not seem that anybody relied on that 64kB padding so far... I guess if a board with a different boot device wants to make use of u-boot-with-spl.imx, then it should make sure that the offset is set correctly in its board file (e.g. using #define CONFIG_SYS_NAND_U_BOOT_OFFS SPL_PAD_TO).
Marek?
I'm fine with it, esp. now that the other boot media are checked. Thanks
On 2016-11-15 10:04, Marek Vasut wrote:
On 11/15/2016 06:42 PM, Stefan Agner wrote:
On 2016-11-15 08:12, Tom Rini wrote:
On Tue, Nov 15, 2016 at 09:59:22AM +0000, Max Krummenacher wrote:
Hi Stefan
On Mon, 2016-11-14 at 18:06 -0800, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
When building SPL with eMMC boot support, specify standard padding for payload to match the load sector during boot. This allows to use the u-boot-with-spl.imx build target to generate a direcly flashable image which can be flashed using:
dd if=u-boot-with-spl.imx of=/dev/mmcblk0 bs=512 skip=2
Signed-off-by: Stefan Agner stefan.agner@toradex.com
include/configs/imx6_spl.h | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 76d1ca0..ca3ed19 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -42,6 +42,12 @@ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) #define CONFIG_SPL_ABORT_ON_RAW_IMAGE +/*
- SPL starts at 1KB (ROM offset), hence we need to pad SPL up to
68KB so
- that payload (U-Boot) will be at 69KB (sector 138) on the eMMC/SD
card.
- Required for targets such as u-boot-with-spl.imx.
- */
+#define CONFIG_SPL_PAD_TO 0x11000 #endif
/* SATA support */
This has been brought up already: https://www.mail-archive.com/u-boot@lists.denx.de/msg228246.html I agreed with Marek that this might disrupt other boot sources (NOR/SPI/ ...) which may or may not decide to use another offset between SPL and U-Boot. Thus it is advisable to move that define to the individual board configuration where one knows for what boot device one wants to use the combined u-boot-with-spl.imx binary.
I'm going to have to disagree with Marek here then. Looking over the explanation in include/configs/imx6_spl.h we have: 1KiB up front "wasted" for a partition table 4KiB up next for the ROM-mandated header 64KiB for SPL itself, which is our max size, unconditionally set above this bit of context. But it is the lowest common denominator in terms of IRAM size in the families.
Which brings us to the SPL_PAD_TO above, 68KiB. We cannot go lower than this. No one is changing any of this either today nor setting SPL_PAD_TO so u-boot-with-spl.imx isn't usable today. None of this breaks using separate files.
I agree here, the pad seems pretty natural and should be usable across boot devices. In fact, it probably should not be inside CONFIG_SPL_MMC_SUPPORT, but at the top along with CONFIG_SPL_MAX_SIZE.
So far, include/config_fallbacks.h defined SPL_PAD_TO to 64KiB, which renders u-boot-with-spl.imx unusable for SD/eMMC boot. Other boot devices probably know a similar define (CONFIG_SYS_NAND_U_BOOT_OFFS). Judging from existing board files it does not seem that anybody relied on that 64kB padding so far... I guess if a board with a different boot device wants to make use of u-boot-with-spl.imx, then it should make sure that the offset is set correctly in its board file (e.g. using #define CONFIG_SYS_NAND_U_BOOT_OFFS SPL_PAD_TO).
Marek?
I'm fine with it, esp. now that the other boot media are checked. Thanks
Ok, I will send a v2 which moves it outside CONFIG_SPL_MMC_SUPPORT.
-- Stefan
participants (4)
-
Marek Vasut -
Max Krummenacher -
Stefan Agner -
Tom Rini