| Message ID | 13311000.Ut1nIK35EQ@phil |
|---|---|
| State | Superseded |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Heiko, On 26 March 2017 at 16:38, Heiko Stuebner <heiko@sntech.de> wrote: > Am Sonntag, 26. März 2017, 15:28:44 CEST schrieb Simon Glass: >> Hi Heiko, >> >> On 26 March 2017 at 15:00, Heiko Stuebner <heiko@sntech.de> wrote: >> > Am Sonntag, 26. März 2017, 22:52:16 CEST schrieb Heiko Stuebner: >> >> Am Sonntag, 26. März 2017, 22:41:35 CEST schrieb Heiko Stuebner: >> >> > Am Sonntag, 26. März 2017, 22:13:08 CEST schrieb Heiko Stuebner: >> >> > > Am Sonntag, 26. März 2017, 14:00:51 CEST schrieb Simon Glass: >> >> > > > Hi Heiko, >> >> > > > >> >> > > > On 26 March 2017 at 13:59, Simon Glass <sjg@chromium.org> wrote: >> >> > > > > Hi Heiko, >> >> > > > > >> >> > > > > On 26 March 2017 at 13:06, Heiko Stuebner <heiko@sntech.de> wrote: >> >> > > > >> Hi Simon, >> >> > > > >> >> >> > > > >> Am Samstag, 25. März 2017, 20:39:08 CEST schrieb Simon Glass: >> >> > > > >>> On 23 March 2017 at 17:41, Heiko Stuebner <heiko@sntech.de> wrote: >> >> > > > >>> > The Rock is a RK3188 based single board computer by Radxa. >> >> > > > >>> > Currently it still relies on the proprietary DDR init and >> >> > > > >>> > cannot use the generic SPL, but at least is able to boot >> >> > > > >>> > a linux kernel and system up to a regular login prompt. >> >> > > > >>> > >> >> > > > >>> > Signed-off-by: Heiko Stuebner <heiko@sntech.de> >> >> > > > >>> > Reviewed-by: Simon Glass <sjg@chromium.org> >> >> > > > >>> > Tested-by: Kever Yang <kever.yang@rock-chips.com> >> >> > > > >>> > --- >> >> > > > >>> > arch/arm/dts/Makefile | 1 + >> >> > > > >>> > arch/arm/dts/rk3188-radxarock.dts | 382 ++++++++++++++++++++++++++++++++++ >> >> > > > >>> > arch/arm/mach-rockchip/rk3188/Kconfig | 11 + >> >> > > > >>> > board/radxa/rock/Kconfig | 15 ++ >> >> > > > >>> > board/radxa/rock/MAINTAINERS | 6 + >> >> > > > >>> > board/radxa/rock/Makefile | 7 + >> >> > > > >>> > board/radxa/rock/rock.c | 7 + >> >> > > > >>> > configs/rock_defconfig | 58 ++++++ >> >> > > > >>> > include/configs/rock.h | 30 +++ >> >> > > > >>> > 9 files changed, 517 insertions(+) >> >> > > > >>> > create mode 100644 arch/arm/dts/rk3188-radxarock.dts >> >> > > > >>> > create mode 100644 board/radxa/rock/Kconfig >> >> > > > >>> > create mode 100644 board/radxa/rock/MAINTAINERS >> >> > > > >>> > create mode 100644 board/radxa/rock/Makefile >> >> > > > >>> > create mode 100644 board/radxa/rock/rock.c >> >> > > > >>> > create mode 100644 configs/rock_defconfig >> >> > > > >>> > create mode 100644 include/configs/rock.h >> >> > > > >>> >> >> > > > >>> I am still having trouble applying this patch. I get build errors: >> >> > > > >>> >> >> > > > >>> arm: + rock >> >> > > > >>> +arch/arm/Makefile:22: CONFIG_CPU_V7 -march=armv7-a >> >> > > > >>> +make[2]: *** No rule to make target 'dts/dt.dtb', needed by >> >> > > > >>> 'tpl/u-boot-tpl.dtb'. Stop. >> >> > > > >>> +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 >> >> > > > >>> +make: *** [sub-make] Error 2 >> >> > > > >>> 0 0 1 /1 rock >> >> > > > >>> >> >> > > > >>> Also there seems to be a duplicate config: >> >> > > > >>> >> >> > > > >>> arm: + rock >> >> > > > >>> +In file included from include/configs/rock.h:11:0, >> >> > > > >>> + from include/config.h:5, >> >> > > > >>> + from include/common.h:21, >> >> > > > >>> + from arch/arm/lib/asm-offsets.c:15: >> >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD >> >> > > > >>> + ^ >> >> > > > >>> + from lib/asm-offsets.c:15: >> >> > > > >>> +In file included from include/linux/kconfig.h:4:0, >> >> > > > >>> + from <command-line>:0: >> >> > > > >>> +include/generated/autoconf.h:10:0: note: this is the location of the >> >> > > > >>> previous definition >> >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD 1 >> >> > > > >> >> >> > > > >> looks like this got run over by another Kconfig migration on march-18. >> >> > > > >> New patches (migration + rock board) coming up shortly. >> >> > > > > >> >> > > > > Thanks - what toolchain are you using to test this? >> >> > > > >> >> > > > Also I am still getting this error: >> >> > > > >> >> > > > buildman rock$ >> >> > > > boards.cfg is up to date. Nothing to do. >> >> > > > Building current source for 1 boards (1 thread, 8 jobs per thread) >> >> > > > arm: + rock >> >> > > > +make[2]: *** No rule to make target 'dts/dt.dtb', needed by >> >> > > > 'tpl/u-boot-tpl.dtb'. Stop. >> >> > > > +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 >> >> > > > +make: *** [sub-make] Error 2 >> >> > > > 0 0 1 /1 rock >> >> > > >> >> > > that is really strange. >> >> > > >> >> > > I'm building with the armhf cross-compiler from Debian testing, which is >> >> > > >> >> > > arm-linux-gnueabihf-gcc (Debian 6.3.0-5) 6.3.0 20170124 >> >> > > >> >> > > My git history also is up-to-date it seems: >> >> > > 14ef0b180b rockchip: rk3188: Add Radxa Rock board >> >> > > d0348986cc rockchip: rk3188: follow THUMB_BUILD Kconfig migration >> >> > > 3bffe88d68 rockchip: video: Split out HDMI controller code >> >> > > a188a5a35c rockchip: i2c: Add compatibles for Rockchip Cortex-A9 socs >> >> > > 903fae5666 rockchip: rk3188: Setup the armclk in spl >> >> > > 7957cc4bd0 rockchip: clk: rk3188: Allow configuration of the armclk >> >> > > >> >> > > with 3bffe88d68 being your current head and my build commands being >> >> > > >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- clean >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rock_defconfig >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- >> >> > >> >> > that also works with a "make mrproper" before everything else. >> >> > >> >> > >> >> > > Strangely the tpl shouldn't require a dtb at all, as it needs to use >> >> > > OF_PLATDATA. Am I missing some config option somewhere? >> >> > >> >> > I also did play around a bit with buildman just now: >> >> > >> >> > At first I forgot the "$" after rock, so build everything with rock in the >> >> > name and the radxarock failed because the somewhat old 4.9 toolchain >> >> > used seems to produce a TPL image that is over the size constraints. >> >> > I.e. 1020 bytes on 4.9 vs. 792 bytes on 6.3.0 . >> >> > >> >> > When I drop the SPL_MAX_SIZE from rk3188_common.h for the TPL build >> >> > tools/buildman/buildman -P rock >> >> > builds 14 boards and finishes sucessfully including the radxarock. >> >> > >> >> > >> >> > Now when I try buildman -P rock$ I seem to also get the error about the >> >> > missing dts/dt.dtb , which does not occur in my regular builds and also >> >> > not when building the bigger number of boards. I guess I need to figure >> >> > out what is different in that case. >> >> >> >> sorry for spamming, but >> >> >> >> also when entering .bm-work/rock where buildman failed and doing just my >> >> >> >> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- >> >> >> >> in that directory created by buildman, produces perfectly fine images. >> >> (buildman does create the .config, so I'm just finishing the build, buildman >> >> failed at for unknown reasons) >> > >> > and a >> > tools/buildman/buildman -PVv -T1 -j1 rock$ >> > >> > also finishes sucessfully, so it looks like that is more some sort of build >> > concurrency issue, with the platdata not being created in time for some >> > reason. >> >> Yes I think that is right. I will see if I can fix that. >> >> Re the toolchain, if I pull in this patch then I will likely cause a >> build breakable on common toolchains. What do you think is the best >> option? Can the TPL be shrunk a little with gcc 4.9? > > I've added Tom for comments, executive summary: > - rk3188-tpl is size limited to 1020 bytes > - gcc 6.3 produces a rk3188-tpl of 792 bytes > - gcc 4.9 makes it 1020 bytes > - buildman seems to always use gcc-4.9 > - rk3188 board does not compile with buildman > > > Isn't holding on to a pretty old compiler for everything somewhat > strange? ;-) Well it's not that old. 4.6 would be old. We do need to be careful not to drop old toolchains too aggressively, although for new platforms such as this is doesn't matter. I try to test with older things to avoid problems applying things to mainline (with Tom's automated tests, etc.) Regards, Simon
On Fri, Mar 31, 2017 at 10:24:07PM -0600, Simon Glass wrote: > Hi Heiko, > > On 26 March 2017 at 16:38, Heiko Stuebner <heiko@sntech.de> wrote: > > Am Sonntag, 26. März 2017, 15:28:44 CEST schrieb Simon Glass: > >> Hi Heiko, > >> > >> On 26 March 2017 at 15:00, Heiko Stuebner <heiko@sntech.de> wrote: > >> > Am Sonntag, 26. März 2017, 22:52:16 CEST schrieb Heiko Stuebner: > >> >> Am Sonntag, 26. März 2017, 22:41:35 CEST schrieb Heiko Stuebner: > >> >> > Am Sonntag, 26. März 2017, 22:13:08 CEST schrieb Heiko Stuebner: > >> >> > > Am Sonntag, 26. März 2017, 14:00:51 CEST schrieb Simon Glass: > >> >> > > > Hi Heiko, > >> >> > > > > >> >> > > > On 26 March 2017 at 13:59, Simon Glass <sjg@chromium.org> wrote: > >> >> > > > > Hi Heiko, > >> >> > > > > > >> >> > > > > On 26 March 2017 at 13:06, Heiko Stuebner <heiko@sntech.de> wrote: > >> >> > > > >> Hi Simon, > >> >> > > > >> > >> >> > > > >> Am Samstag, 25. März 2017, 20:39:08 CEST schrieb Simon Glass: > >> >> > > > >>> On 23 March 2017 at 17:41, Heiko Stuebner <heiko@sntech.de> wrote: > >> >> > > > >>> > The Rock is a RK3188 based single board computer by Radxa. > >> >> > > > >>> > Currently it still relies on the proprietary DDR init and > >> >> > > > >>> > cannot use the generic SPL, but at least is able to boot > >> >> > > > >>> > a linux kernel and system up to a regular login prompt. > >> >> > > > >>> > > >> >> > > > >>> > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > >> >> > > > >>> > Reviewed-by: Simon Glass <sjg@chromium.org> > >> >> > > > >>> > Tested-by: Kever Yang <kever.yang@rock-chips.com> > >> >> > > > >>> > --- > >> >> > > > >>> > arch/arm/dts/Makefile | 1 + > >> >> > > > >>> > arch/arm/dts/rk3188-radxarock.dts | 382 ++++++++++++++++++++++++++++++++++ > >> >> > > > >>> > arch/arm/mach-rockchip/rk3188/Kconfig | 11 + > >> >> > > > >>> > board/radxa/rock/Kconfig | 15 ++ > >> >> > > > >>> > board/radxa/rock/MAINTAINERS | 6 + > >> >> > > > >>> > board/radxa/rock/Makefile | 7 + > >> >> > > > >>> > board/radxa/rock/rock.c | 7 + > >> >> > > > >>> > configs/rock_defconfig | 58 ++++++ > >> >> > > > >>> > include/configs/rock.h | 30 +++ > >> >> > > > >>> > 9 files changed, 517 insertions(+) > >> >> > > > >>> > create mode 100644 arch/arm/dts/rk3188-radxarock.dts > >> >> > > > >>> > create mode 100644 board/radxa/rock/Kconfig > >> >> > > > >>> > create mode 100644 board/radxa/rock/MAINTAINERS > >> >> > > > >>> > create mode 100644 board/radxa/rock/Makefile > >> >> > > > >>> > create mode 100644 board/radxa/rock/rock.c > >> >> > > > >>> > create mode 100644 configs/rock_defconfig > >> >> > > > >>> > create mode 100644 include/configs/rock.h > >> >> > > > >>> > >> >> > > > >>> I am still having trouble applying this patch. I get build errors: > >> >> > > > >>> > >> >> > > > >>> arm: + rock > >> >> > > > >>> +arch/arm/Makefile:22: CONFIG_CPU_V7 -march=armv7-a > >> >> > > > >>> +make[2]: *** No rule to make target 'dts/dt.dtb', needed by > >> >> > > > >>> 'tpl/u-boot-tpl.dtb'. Stop. > >> >> > > > >>> +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 > >> >> > > > >>> +make: *** [sub-make] Error 2 > >> >> > > > >>> 0 0 1 /1 rock > >> >> > > > >>> > >> >> > > > >>> Also there seems to be a duplicate config: > >> >> > > > >>> > >> >> > > > >>> arm: + rock > >> >> > > > >>> +In file included from include/configs/rock.h:11:0, > >> >> > > > >>> + from include/config.h:5, > >> >> > > > >>> + from include/common.h:21, > >> >> > > > >>> + from arch/arm/lib/asm-offsets.c:15: > >> >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD > >> >> > > > >>> + ^ > >> >> > > > >>> + from lib/asm-offsets.c:15: > >> >> > > > >>> +In file included from include/linux/kconfig.h:4:0, > >> >> > > > >>> + from <command-line>:0: > >> >> > > > >>> +include/generated/autoconf.h:10:0: note: this is the location of the > >> >> > > > >>> previous definition > >> >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD 1 > >> >> > > > >> > >> >> > > > >> looks like this got run over by another Kconfig migration on march-18. > >> >> > > > >> New patches (migration + rock board) coming up shortly. > >> >> > > > > > >> >> > > > > Thanks - what toolchain are you using to test this? > >> >> > > > > >> >> > > > Also I am still getting this error: > >> >> > > > > >> >> > > > buildman rock$ > >> >> > > > boards.cfg is up to date. Nothing to do. > >> >> > > > Building current source for 1 boards (1 thread, 8 jobs per thread) > >> >> > > > arm: + rock > >> >> > > > +make[2]: *** No rule to make target 'dts/dt.dtb', needed by > >> >> > > > 'tpl/u-boot-tpl.dtb'. Stop. > >> >> > > > +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 > >> >> > > > +make: *** [sub-make] Error 2 > >> >> > > > 0 0 1 /1 rock > >> >> > > > >> >> > > that is really strange. > >> >> > > > >> >> > > I'm building with the armhf cross-compiler from Debian testing, which is > >> >> > > > >> >> > > arm-linux-gnueabihf-gcc (Debian 6.3.0-5) 6.3.0 20170124 > >> >> > > > >> >> > > My git history also is up-to-date it seems: > >> >> > > 14ef0b180b rockchip: rk3188: Add Radxa Rock board > >> >> > > d0348986cc rockchip: rk3188: follow THUMB_BUILD Kconfig migration > >> >> > > 3bffe88d68 rockchip: video: Split out HDMI controller code > >> >> > > a188a5a35c rockchip: i2c: Add compatibles for Rockchip Cortex-A9 socs > >> >> > > 903fae5666 rockchip: rk3188: Setup the armclk in spl > >> >> > > 7957cc4bd0 rockchip: clk: rk3188: Allow configuration of the armclk > >> >> > > > >> >> > > with 3bffe88d68 being your current head and my build commands being > >> >> > > > >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- clean > >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rock_defconfig > >> >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >> >> > > >> >> > that also works with a "make mrproper" before everything else. > >> >> > > >> >> > > >> >> > > Strangely the tpl shouldn't require a dtb at all, as it needs to use > >> >> > > OF_PLATDATA. Am I missing some config option somewhere? > >> >> > > >> >> > I also did play around a bit with buildman just now: > >> >> > > >> >> > At first I forgot the "$" after rock, so build everything with rock in the > >> >> > name and the radxarock failed because the somewhat old 4.9 toolchain > >> >> > used seems to produce a TPL image that is over the size constraints. > >> >> > I.e. 1020 bytes on 4.9 vs. 792 bytes on 6.3.0 . > >> >> > > >> >> > When I drop the SPL_MAX_SIZE from rk3188_common.h for the TPL build > >> >> > tools/buildman/buildman -P rock > >> >> > builds 14 boards and finishes sucessfully including the radxarock. > >> >> > > >> >> > > >> >> > Now when I try buildman -P rock$ I seem to also get the error about the > >> >> > missing dts/dt.dtb , which does not occur in my regular builds and also > >> >> > not when building the bigger number of boards. I guess I need to figure > >> >> > out what is different in that case. > >> >> > >> >> sorry for spamming, but > >> >> > >> >> also when entering .bm-work/rock where buildman failed and doing just my > >> >> > >> >> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >> >> > >> >> in that directory created by buildman, produces perfectly fine images. > >> >> (buildman does create the .config, so I'm just finishing the build, buildman > >> >> failed at for unknown reasons) > >> > > >> > and a > >> > tools/buildman/buildman -PVv -T1 -j1 rock$ > >> > > >> > also finishes sucessfully, so it looks like that is more some sort of build > >> > concurrency issue, with the platdata not being created in time for some > >> > reason. > >> > >> Yes I think that is right. I will see if I can fix that. > >> > >> Re the toolchain, if I pull in this patch then I will likely cause a > >> build breakable on common toolchains. What do you think is the best > >> option? Can the TPL be shrunk a little with gcc 4.9? > > > > I've added Tom for comments, executive summary: > > - rk3188-tpl is size limited to 1020 bytes > > - gcc 6.3 produces a rk3188-tpl of 792 bytes > > - gcc 4.9 makes it 1020 bytes > > - buildman seems to always use gcc-4.9 > > - rk3188 board does not compile with buildman > > > > > > Isn't holding on to a pretty old compiler for everything somewhat > > strange? ;-) > > Well it's not that old. 4.6 would be old. We do need to be careful not > to drop old toolchains too aggressively, although for new platforms > such as this is doesn't matter. I try to test with older things to > avoid problems applying things to mainline (with Tom's automated > tests, etc.) wrt buildman using certain toolchains, it comes down to the order in which it finds matches for a given arch and then it picks (and I don't recall which off the top of my head) the first or last match. I do agree that gcc-4.9 isn't something we can drop just yet (as for example it's what'll be used in travis-ci today. But it's getting pretty long in the tooth and we will have to at some point say that "platform X requires gcc-6.x or later" as we start running into hard walls that are solved in 6.x. Finally, I have no objection to adding TPL_USE_ARCH_MEMSET as an option so that in cases like this it can be disabled due to space just as it is on SPL.
Am Dienstag, 4. April 2017, 12:29:53 CEST schrieb Tom Rini: > On Fri, Mar 31, 2017 at 10:24:07PM -0600, Simon Glass wrote: > > On 26 March 2017 at 16:38, Heiko Stuebner <heiko@sntech.de> wrote: > > > I've added Tom for comments, executive summary: > > > - rk3188-tpl is size limited to 1020 bytes > > > - gcc 6.3 produces a rk3188-tpl of 792 bytes > > > - gcc 4.9 makes it 1020 bytes > > > - buildman seems to always use gcc-4.9 > > > - rk3188 board does not compile with buildman > > > > > > > > > Isn't holding on to a pretty old compiler for everything somewhat > > > strange? ;-) > > > > Well it's not that old. 4.6 would be old. We do need to be careful not > > to drop old toolchains too aggressively, although for new platforms > > such as this is doesn't matter. I try to test with older things to > > avoid problems applying things to mainline (with Tom's automated > > tests, etc.) > > wrt buildman using certain toolchains, it comes down to the order in > which it finds matches for a given arch and then it picks (and I don't > recall which off the top of my head) the first or last match. > > I do agree that gcc-4.9 isn't something we can drop just yet (as for > example it's what'll be used in travis-ci today. But it's getting > pretty long in the tooth and we will have to at some point say that > "platform X requires gcc-6.x or later" as we start running into hard > walls that are solved in 6.x. > > Finally, I have no objection to adding TPL_USE_ARCH_MEMSET as an option > so that in cases like this it can be disabled due to space just as it is > on SPL. The problem wasn't ARCH_MEMSET - which already was way outsize the size constraints, but the general memset also being somewhat big, with its slight speed optimizations. But thanks to Simon's recent patches [0] we got a really nice size- reduction on the Rock's TPL (from 1020 to 488 bytes) . So with these we're really good with all toolchains now. Heiko [0] https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html
On 4 April 2017 at 11:06, Heiko Stuebner <heiko@sntech.de> wrote: > Am Dienstag, 4. April 2017, 12:29:53 CEST schrieb Tom Rini: >> On Fri, Mar 31, 2017 at 10:24:07PM -0600, Simon Glass wrote: >> > On 26 March 2017 at 16:38, Heiko Stuebner <heiko@sntech.de> wrote: >> > > I've added Tom for comments, executive summary: >> > > - rk3188-tpl is size limited to 1020 bytes >> > > - gcc 6.3 produces a rk3188-tpl of 792 bytes >> > > - gcc 4.9 makes it 1020 bytes >> > > - buildman seems to always use gcc-4.9 >> > > - rk3188 board does not compile with buildman >> > > >> > > >> > > Isn't holding on to a pretty old compiler for everything somewhat >> > > strange? ;-) >> > >> > Well it's not that old. 4.6 would be old. We do need to be careful not >> > to drop old toolchains too aggressively, although for new platforms >> > such as this is doesn't matter. I try to test with older things to >> > avoid problems applying things to mainline (with Tom's automated >> > tests, etc.) >> >> wrt buildman using certain toolchains, it comes down to the order in >> which it finds matches for a given arch and then it picks (and I don't >> recall which off the top of my head) the first or last match. >> >> I do agree that gcc-4.9 isn't something we can drop just yet (as for >> example it's what'll be used in travis-ci today. But it's getting >> pretty long in the tooth and we will have to at some point say that >> "platform X requires gcc-6.x or later" as we start running into hard >> walls that are solved in 6.x. >> >> Finally, I have no objection to adding TPL_USE_ARCH_MEMSET as an option >> so that in cases like this it can be disabled due to space just as it is >> on SPL. > > The problem wasn't ARCH_MEMSET - which already was way outsize the size > constraints, but the general memset also being somewhat big, with its > slight speed optimizations. > > But thanks to Simon's recent patches [0] we got a really nice size- > reduction on the Rock's TPL (from 1020 to 488 bytes) . So with these > we're really good with all toolchains now. > > Heiko > > > [0] https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html Well, hopefully for the last time, this patch: Applied to u-boot-rockchip, thanks!
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds index 068163b73a..c9643efd96 100644 --- a/arch/arm/cpu/u-boot-spl.lds +++ b/arch/arm/cpu/u-boot-spl.lds @@ -72,7 +72,7 @@ SECTIONS } #if defined(CONFIG_SPL_MAX_SIZE) -ASSERT(__image_copy_end - __image_copy_start < (CONFIG_SPL_MAX_SIZE), \ +ASSERT(__image_copy_end - __image_copy_start <= (CONFIG_SPL_MAX_SIZE), \ "SPL image too big"); #endif