public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] AT91: problems master vs. next
Date: Tue, 21 Sep 2010 16:00:36 +0200	[thread overview]
Message-ID: <4C98BA84.9040104@free.fr> (raw)
In-Reply-To: <4C98A78D.7070407@emk-elektronik.de>

Le 21/09/2010 14:39, Reinhard Meyer a ?crit :
> Just to report on preliminary findings I had:
>
> Rebasing my current TOP9000 port on u-boot/master compiles
> and works fine.
> Code size increased moderately from 223592 to 223976.
>
> Rebasing my current TOP9000 port on u-boot/next compiles
> after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
> Code size increased heavyly from 223592 to 245544.
>
> And U-Boot crashes instantly (I know there is more to be done
> than just defining those two macros).
>
> What bothers me really here is the huge increase in code size.

I see numbers similar for orion5x based net5big, where non relocating 
build is 117252 bytes while relocating build is 127120, a 8.4% increase 
(yours is 9.8%).

This is due to the fact that each routine has to recompute the PIC 
register. As a test, I tried adding -msingle-pic-base to -fPIC (this 
computes the PIC register once for the whole code) and the code size 
falls back to 123764 bytes, 'only' 5.5% more than the non relocating 
case. Using -fPIE -pie -msingle-pic-base lowers this again to 5.2%.

Of course you cannot just turn -msingle-pic-base on; you've got to have 
the code in start.S that computes the register. Also, switching from PIC 
to PIE needs to be verified. I've got the code in my local tree, but 
it's not tested yet. I'll test it tonight and post it if it works.

> And, on almost all AT91 systems booting will be through a
> first boot loader, which sets up SDRAM, loads u-boot to the
> "correct" address and jumps to it.
> All low level init and relocation is not required in such cases.
>
> It should be always possible to #define relocation off!

On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and 
CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board, 
always skips lowlevel inits.

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-09-21 14:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-21 12:39 [U-Boot] AT91: problems master vs. next Reinhard Meyer
2010-09-21 14:00 ` Albert ARIBAUD [this message]
2010-09-21 14:18   ` Reinhard Meyer
2010-09-21 14:36     ` Reinhard Meyer
2010-09-21 17:27     ` Wolfgang Denk
2010-09-21 17:27   ` Wolfgang Denk
2010-09-22  7:14   ` [U-Boot] ARM Relocation compiler and linker switches (was: AT91: problems master vs. next) Albert ARIBAUD
2010-09-21 14:40 ` [U-Boot] AT91: problems master vs. next Stefan Roese
2010-09-21 14:50   ` Reinhard Meyer
2010-09-21 17:27 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C98BA84.9040104@free.fr \
    --to=albert.aribaud@free.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox