public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Luca Ellero <lroluk@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr
Date: Tue, 29 Jan 2013 16:16:21 +0100	[thread overview]
Message-ID: <5107E7C5.9050400@gmail.com> (raw)
In-Reply-To: <20130129094827.C94C82005AB@gemini.denx.de>

Dear Wolfgang,

On 29/01/2013 10.48, Wolfgang Denk wrote:
> Dear Luca Ellero,
>
> In message <51078BFD.60906@gmail.com> you wrote:
>>
>> in U-Boot version 2012.10 I used to skip "relocate_code" setting
>> CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command).
>> This since some hardware is able to configure SDRAM and load U-Boot
>> directly to SDRAM, so relocation is useless and time consuming.
>
> You are wrong.  relocation is not useless, even in your case.  there
> are quite a number of configuration options that will put stuff above
> the U-Boot image, directly at the end of RAM (things like protected
> RAM, shared frame buffer, shared log buffer, etc.).  In these cases,
> the relocation address may even be dynamic (i. e. depending on
> settings of environment variables, and thus unknown at compile time).
>
>> Now I'm using latest git version and this isn't working anymore.
>> Can someone explain me way? And what is the suggested way to skip
>> relocation now.
>
> Don't.

Got your point ;-)
Thanks
I'm asking that since I'm digging on ARM SDRAM configuration and found a 
bug on getting top of SDRAM (where u-boot will be relocated).

On ARM architectures top of SDRAM will always be:

CONFIG_SYS_SDRAM_BASE + gd->ram_size

anyway this can be wrong since SDRAM can be composed by more that one 
bank in not-contiguous address space.
(CONFIG_SYS_SDRAM_BASE + gd->ram_size) can land to not existent SDRAM 
addresses and can be very dangerous since it can potentially corrupt 
real SDRAM (in most cases SDRAM is aliased so writing to some 
not-existent address can write to real address).


My proposed patch is something like this:
---------------------------------------------------------

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index cfe32cc..7525caf 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -333,7 +333,18 @@ void board_init_f(ulong bootflag)
  	gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
  #endif

+#if defined(PHYS_SDRAM_2) && defined(PHYS_SDRAM_2_SIZE)
+	if ( CONFIG_NR_DRAM_BANKS > 1 &&
+		(PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE) != PHYS_SDRAM_2 )
+		addr =  PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE;
+	else
+		addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
+#else
  	addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
+#endif
+

---------------------------------------------------------

I know that some arch use more than 2 banks but implementing all macros 
checks to PHYS_SDRAM_* leads to some macro hell. So the point here is:

if (n banks > 2) and they are not contiguous, relocate u-boot at the end 
of 2nd bank even if there are more than 2 banks.

Please suggest me if this is the right way to follow or suggest me some 
more appropriate way to correct this bug
Thanks again
Regards
Luca Ellero

  reply	other threads:[~2013-01-29 15:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29  7:41 [U-Boot] [PULL] : Please pull u-boot-i2c Heiko Schocher
2013-01-29  8:44 ` [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr Luca Ellero
2013-01-29  9:48   ` Wolfgang Denk
2013-01-29 15:16     ` Luca Ellero [this message]
2013-01-29 22:15 ` [U-Boot] [PULL] : Please pull u-boot-i2c Tom Rini

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=5107E7C5.9050400@gmail.com \
    --to=lroluk@gmail.com \
    --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