arm: Don't use printf() in SPL builds

PATCH New Simon Glass 6 participants 12 messages Mar 3, 2012 – May 7, 2012 Arm (32-bit)

Share & tools

Simon Glass

author

2012-03-03 20:33 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

---
 arch/arm/lib/eabi_compat.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/arm/lib/eabi_compat.c +2 -1

index 2028dbd..44eebe0 100644
@@ -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;

Signature · 1 line

1.7.7.3

Stefan Roese

2012-03-05 08:21 UTC #1 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Quoted 8 lines · 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 <[email protected]>

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 at denx.de

Sughosh Ganu

2012-03-10 08:33 UTC #2 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

In reply to Simon Glass

hi Simon,

Quoted 19 lines · Simon Glass

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 <[email protected]>
---
 arch/arm/lib/eabi_compat.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/lib/eabi_compat.c +0 -0
index 2028dbd..44eebe0 100644

arch/arm/lib/eabi_compat.c line 19

Quoted 8 lines

arch/arm/lib/eabi_compat.c +2 -1

@@ -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

Simon Glass

author

2012-03-15 03:47 UTC #3 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Hi Sughosh,

Quoted 23 lines · Sughosh Ganu

hi Simon,
Quoted 20 lines · Simon Glass
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 <[email protected]>
---
?arch/arm/lib/eabi_compat.c | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/lib/eabi_compat.c +0 -0
index 2028dbd..44eebe0 100644
@@ -13,7 +13,8 @@
 

Quoted 12 lines

Quoted 7 lines
arch/arm/lib/eabi_compat.c +2 -1
 ?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.

Quoted 6 lines

? 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

Quoted 2 lines

-sughosh

Heiko Schocher

2012-03-15 05:13 UTC #4 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Hello Simon,

Quoted 46 lines · Simon Glass

Hi Sughosh,
Quoted 23 lines · Sughosh Ganu
hi Simon,
Quoted 20 lines · Simon Glass
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 <[email protected]>
---
 arch/arm/lib/eabi_compat.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/lib/eabi_compat.c +0 -0
index 2028dbd..44eebe0 100644
@@ -13,7 +13,8 @@
 
Quoted 11 lines
arch/arm/lib/eabi_compat.c line 19
Quoted 7 lines
arch/arm/lib/eabi_compat.c +2 -1
 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.
Quoted 5 lines
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.

Quoted 4 lines

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 <[email protected]>
Date:   Tue Nov 1 06:28:21 2011 +0000

image: Support FDTs already loaded at their load address

bye,
Heiko

Signature · 2 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Simon Glass

author

2012-03-15 05:23 UTC #5 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Hi Heiko,

Quoted 61 lines · Heiko Schocher

Hello Simon,
Quoted 46 lines · Simon Glass
Hi Sughosh,
Quoted 23 lines · Sughosh Ganu
hi Simon,
Quoted 20 lines · Simon Glass
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 <[email protected]>
---
?arch/arm/lib/eabi_compat.c | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/lib/eabi_compat.c +0 -0
index 2028dbd..44eebe0 100644
@@ -13,7 +13,8 @@
 
Quoted 11 lines
Quoted 7 lines
arch/arm/lib/eabi_compat.c +2 -1
 ?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.
Quoted 5 lines
? 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.
Quoted 4 lines
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?

Quoted 7 lines

Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730
Author: Stephen Warren <[email protected]>
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

Quoted 6 lines

bye,
Heiko
--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Heiko Schocher

2012-03-15 05:29 UTC #6 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Hello Simon,

Quoted 12 lines · Simon Glass

Hi Heiko,
Quoted 9 lines · Heiko Schocher
Hello Simon,
Quoted 6 lines · Simon Glass
Hi Sughosh,
Quoted 3 lines · Sughosh Ganu
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:

[...]

Quoted 27 lines

Quoted 16 lines
Quoted 9 lines
Quoted 5 lines
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?
Quoted 7 lines
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730
Author: Stephen Warren <[email protected]>
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:

Quoted 9 lines

$ 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

Signature · 2 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Christian Riesch

2012-03-15 07:37 UTC #7 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

In reply to Simon Glass

Hi Simon,

Quoted 12 lines · Simon Glass

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

Simon Glass

author

2012-03-15 16:23 UTC #8 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Hi Christian,

Quoted 16 lines · Christian Riesch

Hi Simon,

Quoted 12 lines · Simon Glass

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....

Quoted 5 lines

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

Quoted 2 lines

Regards, Christian

Sughosh Ganu

2012-03-16 18:20 UTC #9 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

In reply to Simon Glass

hi Simon,

On Wed Mar 14, 2012 at 08:47:43PM -0700, Simon Glass wrote:

<snip>

Quoted 11 lines

Quoted 6 lines
? 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

Stefan Roese

2012-05-07 12:28 UTC #10 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

In reply to Simon Glass

Quoted 8 lines · 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

Tom Rini

2012-05-07 22:51 UTC #11 lore raw

PATCH 1/1 arm: Don't use printf() in SPL builds

Quoted 7 lines · Stefan Roese

Quoted 6 lines · 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.

Quoted 7 lines

Quoted 2 lines
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.

Signature · 1 line

Tom