[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[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 <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;
-- 
1.7.7.3

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Stefan Roese]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Sughosh Ganu]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Simon Glass]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Simon Glass]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Christian Riesch]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Simon Glass]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Sughosh Ganu]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Stefan Roese]

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

[U-Boot] [PATCH] arm: Don't use printf() in SPL builds

[Tom Rini]

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.

-- 
Tom