[U-Boot] [PATCH v2] spl: implement CRC check on U-Boot uImage
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com ---
Changes in v2: - added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable checking CRC on legacy images
common/spl/Kconfig | 21 +++++++++++++++------ common/spl/spl.c | 30 +++++++++++++++++++++++++++++- include/spl.h | 5 +++++ 3 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig index d0564621d4..5c6c437ef0 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -80,6 +80,15 @@ config SPL_LEGACY_IMAGE_SUPPORT is y. If this is not set, SPL will move on to other available boot media to find a suitable image.
+config SPL_LEGACY_IMAGE_CRC_CHECK + bool "Check CRC of Legacy images" + depends on SPL_LEGACY_IMAGE_SUPPORT + default y + select SPL_CRC32_SUPPORT + help + Enable this to check the CRC of Legacy images. While this increases + reliability, it affects both code size and boot duration. + config SPL_SYS_MALLOC_SIMPLE bool prompt "Only use malloc_simple functions in the SPL" @@ -207,13 +216,13 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
config SPL_CRC32_SUPPORT bool "Support CRC32" - depends on SPL_FIT + default y if SPL_LEGACY_IMAGE_SUPPORT help - Enable this to support CRC32 in FIT images within SPL. This is a - 32-bit checksum value that can be used to verify images. This is - the least secure type of checksum, suitable for detected - accidental image corruption. For secure applications you should - consider SHA1 or SHA256. + Enable this to support CRC32 in uImages or FIT images within SPL. + This is a 32-bit checksum value that can be used to verify images. + For FIT images, this is the least secure type of checksum, suitable + for detected accidental image corruption. For secure applications you + should consider SHA1 or SHA256.
config SPL_MD5_SUPPORT bool "Support MD5" diff --git a/common/spl/spl.c b/common/spl/spl.c index 12f9359c0a..f2ea87a0ec 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -236,6 +236,14 @@ int spl_parse_image_header(struct spl_image_info *spl_image, #ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT u32 header_size = sizeof(struct image_header);
+ if (CONFIG_IS_ENABLED(LEGACY_IMAGE_CRC_CHECK)) { + /* check uImage header CRC */ + if (!image_check_hcrc(header)) { + puts("SPL: Image header CRC check failed!\n"); + return -EINVAL; + } + } + if (spl_image->flags & SPL_COPY_PAYLOAD_ONLY) { /* * On some system (e.g. powerpc), the load-address and @@ -253,6 +261,13 @@ int spl_parse_image_header(struct spl_image_info *spl_image, spl_image->size = image_get_data_size(header) + header_size; } +#ifdef CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK + /* store uImage data length and CRC to check later */ + spl_image->dcrc_data = image_get_load(header); + spl_image->dcrc_length = image_get_data_size(header); + spl_image->dcrc = image_get_dcrc(header); +#endif + spl_image->os = image_get_os(header); spl_image->name = image_get_name(header); debug("spl: payload image: %32s load addr: 0x%lx size: %d\n", @@ -424,12 +439,25 @@ static struct spl_image_loader *spl_ll_find_loader(uint boot_device) static int spl_load_image(struct spl_image_info *spl_image, struct spl_image_loader *loader) { + int ret; struct spl_boot_device bootdev;
bootdev.boot_device = loader->boot_device; bootdev.boot_device_name = NULL;
- return loader->load_image(spl_image, &bootdev); + ret = loader->load_image(spl_image, &bootdev); +#ifdef CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK + if (!ret && spl_image->dcrc_length) { + /* check data crc */ + ulong dcrc = crc32_wd(0, (unsigned char *)spl_image->dcrc_data, + spl_image->dcrc_length, CHUNKSZ_CRC32); + if (dcrc != spl_image->dcrc) { + puts("SPL: Image data CRC check failed!\n"); + ret = -EINVAL; + } + } +#endif + return ret; }
/** diff --git a/include/spl.h b/include/spl.h index 9a439f468b..1b1d9ebbfb 100644 --- a/include/spl.h +++ b/include/spl.h @@ -33,6 +33,11 @@ struct spl_image_info { u32 size; u32 flags; void *arg; +#if CONFIG_IS_ENABLED(LEGACY_IMAGE_CRC_CHECK) + ulong dcrc_data; + ulong dcrc_length; + ulong dcrc; +#endif };
/*
On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Changes in v2:
- added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable checking CRC on legacy images
common/spl/Kconfig | 21 +++++++++++++++------ common/spl/spl.c | 30 +++++++++++++++++++++++++++++- include/spl.h | 5 +++++ 3 files changed, 49 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Tom,
Am 11.12.2018 um 02:07 schrieb Simon Glass:
On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Changes in v2:
added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable checking CRC on legacy images
common/spl/Kconfig | 21 +++++++++++++++------ common/spl/spl.c | 30 +++++++++++++++++++++++++++++- include/spl.h | 5 +++++ 3 files changed, 49 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
This is assigned to you in patchwork, any reason you did not add it for the 2019.01 release? Is there anything missing or was this just lost?
Thanks, Simon
On Mon, Jan 14, 2019 at 04:38:24PM +0100, Simon Goldschmidt wrote:
Tom,
Am 11.12.2018 um 02:07 schrieb Simon Glass:
On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Changes in v2:
- added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable checking CRC on legacy images
common/spl/Kconfig | 21 +++++++++++++++------ common/spl/spl.c | 30 +++++++++++++++++++++++++++++- include/spl.h | 5 +++++ 3 files changed, 49 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
This is assigned to you in patchwork, any reason you did not add it for the 2019.01 release? Is there anything missing or was this just lost?
I think I might have filed this off mentally as "Did we still want to do this?", so I'll pick it up for the next release, thanks!
Am 14.01.2019 um 17:27 schrieb Tom Rini:
On Mon, Jan 14, 2019 at 04:38:24PM +0100, Simon Goldschmidt wrote:
Tom,
Am 11.12.2018 um 02:07 schrieb Simon Glass:
On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Changes in v2:
added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable checking CRC on legacy images
common/spl/Kconfig | 21 +++++++++++++++------ common/spl/spl.c | 30 +++++++++++++++++++++++++++++- include/spl.h | 5 +++++ 3 files changed, 49 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
This is assigned to you in patchwork, any reason you did not add it for the 2019.01 release? Is there anything missing or was this just lost?
I think I might have filed this off mentally as "Did we still want to do this?", so I'll pick it up for the next release, thanks!
Ping?
Regards, Simon
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
Regards, Simon
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
In general, pine64_plus_defconfig is one that might (as I re-run my build without this patch, I still see some failures but they've scrolled off screen, but 64bit sunxi _is_ very sensitive to SPL growth).
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
OK, so the vyasa-rk3288 uses TPL, that's what I got wrong.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
In general, pine64_plus_defconfig is one that might (as I re-run my build without this patch, I still see some failures but they've scrolled off screen, but 64bit sunxi _is_ very sensitive to SPL growth).
And I also did compile that one but I don't see any error message. How am I supposed to detect the SRAM overflowing?
I assume it's .text or .rodata which makes it grow too big? If so, we could still check the CRC by using a smaller algorithm that does not rely on a precalculated table...
Regards, Simon
On Sat, Feb 09, 2019 at 10:56:40PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
OK, so the vyasa-rk3288 uses TPL, that's what I got wrong.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
In general, pine64_plus_defconfig is one that might (as I re-run my build without this patch, I still see some failures but they've scrolled off screen, but 64bit sunxi _is_ very sensitive to SPL growth).
And I also did compile that one but I don't see any error message. How am I supposed to detect the SRAM overflowing?
I assume it's .text or .rodata which makes it grow too big? If so, we could still check the CRC by using a smaller algorithm that does not rely on a precalculated table...
That could have been the other patch then. Does all of sunxi build for you? If so, we're good then.
On Sun, Feb 10, 2019 at 1:43 AM Tom Rini trini@konsulko.com wrote:
On Sat, Feb 09, 2019 at 10:56:40PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
SPL currently does not check uImage CRCs when loading U-Boot.
This patch adds checking the uImage CRC when SPL loads U-Boot. It does this by reusing the existing config option SPL_CRC32_SUPPORT to allow leaving out the CRC check on boards where the additional code size or boot time is a problem (adding the CRC check currently adds ~1.4 kByte to flash).
The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL support for legacy images is enabled to check the CRC on all boards that don't actively take countermeasures.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
OK, so the vyasa-rk3288 uses TPL, that's what I got wrong.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
In general, pine64_plus_defconfig is one that might (as I re-run my build without this patch, I still see some failures but they've scrolled off screen, but 64bit sunxi _is_ very sensitive to SPL growth).
And I also did compile that one but I don't see any error message. How am I supposed to detect the SRAM overflowing?
I assume it's .text or .rodata which makes it grow too big? If so, we could still check the CRC by using a smaller algorithm that does not rely on a precalculated table...
That could have been the other patch then. Does all of sunxi build for you? If so, we're good then.
Well, I really can't tell: especially with other patches in the queue that might get puhed before mine. text and rodata do grow by ~1.6 KiB summed up, so that might of course trigger some platforms.
On the other hand, I think this is a critical feature for reliable boot unless using FIT. If you don't think so (and in fact, noone seems to have noticed this for some years), then I'm happy to re-post this without default 'y'.
Regards, Simon
On Sun, Feb 10, 2019 at 02:07:28PM +0100, Simon Goldschmidt wrote:
On Sun, Feb 10, 2019 at 1:43 AM Tom Rini trini@konsulko.com wrote:
On Sat, Feb 09, 2019 at 10:56:40PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote:
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini trini@konsulko.com wrote:
On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote:
> SPL currently does not check uImage CRCs when loading U-Boot. > > This patch adds checking the uImage CRC when SPL loads U-Boot. It does > this by reusing the existing config option SPL_CRC32_SUPPORT to allow > leaving out the CRC check on boards where the additional code size or > boot time is a problem (adding the CRC check currently adds ~1.4 kByte > to flash). > > The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL > support for legacy images is enabled to check the CRC on all boards > that don't actively take countermeasures. > > Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com > Reviewed-by: Simon Glass sjg@chromium.org
Really sorry for the delay on this, especially as I've found one or two problems. The first problem is that with this vyasa-rk3288 and a few others fail to build due to a number of errors such as: ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member named 'dcrc_data'
Hmm, let me check what's wrong there.
OK, so the vyasa-rk3288 uses TPL, that's what I got wrong.
Second, I believe this is causing a number of platforms with very tight SPL constraints, namely all of 64bit sunxi, to fail to link as they overflow SRAM now. This can be fixed at least by making the new behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks in advance!
Well, I thought it would be better to have it default to 'y' since I think it is what is expected. Shouldn't we explicitly work on those platforms? I must say I was pretty shocked to see that SPL did not detect an invalid CRC...
Can you point me to a config that fails?
In general, pine64_plus_defconfig is one that might (as I re-run my build without this patch, I still see some failures but they've scrolled off screen, but 64bit sunxi _is_ very sensitive to SPL growth).
And I also did compile that one but I don't see any error message. How am I supposed to detect the SRAM overflowing?
I assume it's .text or .rodata which makes it grow too big? If so, we could still check the CRC by using a smaller algorithm that does not rely on a precalculated table...
That could have been the other patch then. Does all of sunxi build for you? If so, we're good then.
Well, I really can't tell: especially with other patches in the queue that might get puhed before mine. text and rodata do grow by ~1.6 KiB summed up, so that might of course trigger some platforms.
On the other hand, I think this is a critical feature for reliable boot unless using FIT. If you don't think so (and in fact, noone seems to have noticed this for some years), then I'm happy to re-post this without default 'y'.
Yeah, I think we should leave default y off. Thanks!
participants (3)
-
Simon Glass -
Simon Goldschmidt -
Tom Rini