[U-Boot] [PATCH 3/3] powerpc, 8xx: adapt a few linker scripts so it will build.

Wolfgang Denk wd at denx.de
Sun Apr 24 22:48:09 CEST 2011


Dear Joakim Tjernlund,

In message <1303633774-22961-4-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
> Seems like recent linker/fpic changes broke a few 8xx boards.
> This makes them build again.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> ---
>  board/LEOX/elpt860/u-boot.lds |    2 +-
>  board/etx094/u-boot.lds       |    2 +-
>  board/svm_sc8xx/u-boot.lds    |    2 +-
>  board/tqc/tqm8xx/u-boot.lds   |    2 ++
>  4 files changed, 5 insertions(+), 3 deletions(-)

Sorry, but isn't this just papering over the original problem?
In the reverted commit you claimed:

    -msingle-pic-base is a new gcc option for ppc and
    it reduces the size of my u-boot with 6-8 KB.
    While at it, add -fno-jump-tables too to save a
    few more bytes.

This promises to reduce the overall code size, but instead the
observation is that it is growing, which is the reson for the build
problem on some boards.

For example TQM860L (top of tree, with 8c4734e reverted (i. e. your
old 39768f7 reapplied) and this patch here applied, I see:

   text    data     bss     dec     hex filename
 258663   14676   27228  300567   49617 ./u-boot

and

                0x00008000                . = DEFINED (env_offset)?env_offset:.
 *fill*         0x40007d28      0x2d8 00
 common/env_embedded.o(.ppcenv*)
 .ppcenv        0x40008000     0x8000 common/env_embedded.o

Without these two changes we have:

   text    data     bss     dec     hex filename
 257955   14744   27228  299927   49397 ./u-boot

and

 670                 0x00008000                . = DEFINED (env_offset)?env_offset:.
 671  *fill*         0x40007fb4       0x4c 00
 672  common/env_embedded.o(.ppcenv*)
 673  .ppcenv        0x40008000     0x8000 common/env_embedded.o


The gap before the embedded environment which is just 76 bytes
without your patches now grows to 728 bytes (i. e. by a factor of
nearly 10), and the total image sie grows, too.


I will not apply either of these commits - neither the reverted one,
nor this additional one, as both of them grow the memory footprint
instead of redusing it as you promised in the commit message.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The complexity of software is an essential property, not an  acciden-
tal  one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence.    - Fred Brooks, Jr.


More information about the U-Boot mailing list