Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
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 > Reviewed-by: Simon Glass 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! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Fri, Feb 8, 2019 at 8:46 PM Tom Rini 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 > > Reviewed-by: Simon Glass > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote: > On Fri, Feb 8, 2019 at 8:46 PM Tom Rini 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 > > > Reviewed-by: Simon Glass > > > > 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). -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini 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 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 > > > > Reviewed-by: Simon Glass > > > > > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Sat, Feb 09, 2019 at 10:56:40PM +0100, Simon Goldschmidt wrote: > On Fri, Feb 8, 2019 at 10:20 PM Tom Rini 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 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 > > > > > Reviewed-by: Simon Glass > > > > > > > > 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Sun, Feb 10, 2019 at 1:43 AM Tom Rini 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 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 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 > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Sun, Feb 10, 2019 at 02:07:28PM +0100, Simon Goldschmidt wrote: > On Sun, Feb 10, 2019 at 1:43 AM Tom Rini 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 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 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 > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > 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! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
