[U-Boot] [PATCH] arm: Don't use printf() in SPL builds
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Signed-off-by: Simon Glass sjg@chromium.org --- arch/arm/lib/eabi_compat.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c index 2028dbd..44eebe0 100644 --- a/arch/arm/lib/eabi_compat.c +++ b/arch/arm/lib/eabi_compat.c @@ -13,7 +13,8 @@
int raise (int signum) { -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT) + /* Even if printf() is available, it's large. Punt it for SPL builds */ +#if !defined(CONFIG_SPL_BUILD) printf("raise: Signal # %d caught\n", signum); #endif return 0;
On Saturday 03 March 2012 21:33:15 Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Thanks. I do have a similar patch in my SPEAr600 SPL patch queue where printf support increases the image size. So:
Acked-by: Stefan Roese sr@denx.de
Thanks, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/eabi_compat.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c index 2028dbd..44eebe0 100644 --- a/arch/arm/lib/eabi_compat.c +++ b/arch/arm/lib/eabi_compat.c @@ -13,7 +13,8 @@
int raise (int signum) { -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
- /* Even if printf() is available, it's large. Punt it for SPL builds */
+#if !defined(CONFIG_SPL_BUILD) printf("raise: Signal # %d caught\n", signum); #endif
I tested with this change on hawkboard, and after applying this change, the spl size increase is 412 bytes against the 4k increase that we get with libcommon changes introduced. So this patch works fine.
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
-sughosh
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/eabi_compat.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c index 2028dbd..44eebe0 100644 --- a/arch/arm/lib/eabi_compat.c +++ b/arch/arm/lib/eabi_compat.c @@ -13,7 +13,8 @@
int raise (int signum) { -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
- /* Even if printf() is available, it's large. Punt it for SPL builds */
+#if !defined(CONFIG_SPL_BUILD) printf("raise: Signal # %d caught\n", signum); #endif
I tested with this change on hawkboard, and after applying this change, the spl size increase is 412 bytes against the 4k increase that we get with libcommon changes introduced. So this patch works fine.
OK good.
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT
Regards, Simon
-sughosh
Hello Simon,
Simon Glass wrote:
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/eabi_compat.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c index 2028dbd..44eebe0 100644 --- a/arch/arm/lib/eabi_compat.c +++ b/arch/arm/lib/eabi_compat.c @@ -13,7 +13,8 @@
int raise (int signum) { -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
/* Even if printf() is available, it's large. Punt it for SPL builds */+#if !defined(CONFIG_SPL_BUILD) printf("raise: Signal # %d caught\n", signum); #endif
I tested with this change on hawkboard, and after applying this change, the spl size increase is 412 bytes against the 4k increase that we get with libcommon changes introduced. So this patch works fine.
OK good.
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT
I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see
http://patchwork.ozlabs.org/patch/145280/
for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT maybe I miss something?
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730 Author: Stephen Warren swarren@nvidia.com Date: Tue Nov 1 06:28:21 2011 +0000
image: Support FDTs already loaded at their load address
bye, Heiko
Hi Heiko,
On Wed, Mar 14, 2012 at 10:13 PM, Heiko Schocher hs@denx.de wrote:
Hello Simon,
Simon Glass wrote:
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/eabi_compat.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c index 2028dbd..44eebe0 100644 --- a/arch/arm/lib/eabi_compat.c +++ b/arch/arm/lib/eabi_compat.c @@ -13,7 +13,8 @@
int raise (int signum) { -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
- /* Even if printf() is available, it's large. Punt it for SPL builds */
+#if !defined(CONFIG_SPL_BUILD) printf("raise: Signal # %d caught\n", signum); #endif
I tested with this change on hawkboard, and after applying this change, the spl size increase is 412 bytes against the 4k increase that we get with libcommon changes introduced. So this patch works fine.
OK good.
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT
I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see
http://patchwork.ozlabs.org/patch/145280/
for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT maybe I miss something?
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730 Author: Stephen Warren swarren@nvidia.com Date: Tue Nov 1 06:28:21 2011 +0000
image: Support FDTs already loaded at their load address
Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get:
$ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs....
Regards, Simon
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Hello Simon,
Simon Glass wrote:
Hi Heiko,
On Wed, Mar 14, 2012 at 10:13 PM, Heiko Schocher hs@denx.de wrote:
Hello Simon,
Simon Glass wrote:
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
[...]
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT
I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see
http://patchwork.ozlabs.org/patch/145280/
for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT maybe I miss something?
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730 Author: Stephen Warren swarren@nvidia.com Date: Tue Nov 1 06:28:21 2011 +0000
image: Support FDTs already loaded at their load address
Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get:
$ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs....
Ah, Ok. Currently I have no access to the hw, so I could not test this :-(
bye, Heiko
Hi Simon,
On Thu, Mar 15, 2012 at 6:23 AM, Simon Glass sjg@chromium.org wrote:
Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get:
$ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs....
relocate_code is also called in the da850evm and hawkboard configurations from spl.c, so I guess we will get this error for these boards as well. I would like to test your generic relocation patches also on my board. Which patchsets are required, what's their latest version?
Regards, Christian
Hi Christian,
On Thu, Mar 15, 2012 at 12:37 AM, Christian Riesch christian.riesch@omicron.at wrote:
Hi Simon,
On Thu, Mar 15, 2012 at 6:23 AM, Simon Glass sjg@chromium.org wrote:
Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get:
$ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs....
relocate_code is also called in the da850evm and hawkboard configurations from spl.c, so I guess we will get this error for these boards as well. I would like to test your generic relocation patches also on my board. Which patchsets are required, what's their latest version?
Yes, please take a look here:
http://patchwork.ozlabs.org/bundle/sjg/reloc/
Regards, Simon
Regards, Christian
hi Simon,
On Wed Mar 14, 2012 at 08:47:43PM -0700, Simon Glass wrote:
<snip>
Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT
Ok. In that case, i guess you would be submitting the series with a new version? With addition of the libcommon support for cam_enc_4xx board, you don't need this patch.
http://patchwork.ozlabs.org/patch/142220/
-sughosh
On Saturday 03 March 2012 21:33:15 Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Simon (or anybody else), what was the outcome of this patch discussion? Is it still pending for mainline inclusion? I'm asking since it fixes a problem (image too big) with the SPEAr SPL support which I'm currently rebasing for submission.
Thanks, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
On 05/07/2012 05:28 AM, Stefan Roese wrote:
On Saturday 03 March 2012 21:33:15 Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it either is not available, or adds a large chunk to the resulting image size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for example, using generic relocation.
Simon (or anybody else), what was the outcome of this patch discussion? Is it still pending for mainline inclusion? I'm asking since it fixes a problem (image too big) with the SPEAr SPL support which I'm currently rebasing for submission.
Got lost along the way? Just include it in whatever series you end up posting I think.
participants (6)
-
Christian Riesch -
Heiko Schocher -
Simon Glass -
Stefan Roese -
Sughosh Ganu -
Tom Rini