From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Date: Tue, 02 Nov 2010 10:34:12 +0100 [thread overview]
Message-ID: <4CCFDB14.3060809@emk-elektronik.de> (raw)
In-Reply-To: <4CCFD5C4.6040706@free.fr>
Dear Albert ARIBAUD,
> Le 02/11/2010 09:57, Reinhard Meyer a ?crit :
>> Dear Heiko Schocher,
>>> But there is a possibility to prevent one copy, if TEXT_BASE =
>>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
>>>
>>> In this case nand_spl code copies u-boot from nand to
>>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
>>> no need to copy code in relocate_code().
>>>
>>> But as codesize changes (and with it relocation address) this
>>> is not a perfect solution.
>>
>> Worse: it would certainly crash since the original and relocated memory
>> areas must not overlap - they sure would with even the slightest size
>> change.
>
> I'm not sure I get you there. If u-boot was linked for a given address
> and happends to be loaded at that same address, then there is no need to
> relocate, right?
*if* the code size changes, "need" for relocation would arise...
>> I would recommend that we add code to check for overlapping relocation
>> into
>> board.c and print a panic message if an overlap is detected.
>
> I *think* overlap would be correctly handled if we modify the copy code
> to copy from top to bottom, because we know that the destination is
> higher than the source.
No, in above case the (new) destination could be lower than the loaded
address (e.g. code size increased).
In any case it is not worth the effort to plan for overlapping relocations.
We can always load u-boot to a very low address of SDRAM and let it relocate.
> The only tricky case would be when the target address is right in the
> middle of the source relocation code, because then the last iteratons of
> the copy code would corrupt this code; that can be avoided by making
> sure the SPL loads u-boot low enough in RAM.
Exactly.
My original message was: "please to not give people the idea that they can
avoid relocation by loading u-boot at the exact address the relocation would
calculate. That is bound to *really* break at the slightest change to u-boot."
Best Regards,
Reinhard
next prev parent reply other threads:[~2010-11-02 9:34 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-31 17:43 [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert Aribaud
2010-10-31 18:11 ` Alexander Holler
2010-10-31 18:12 ` Wolfgang Denk
2010-10-31 18:31 ` Albert ARIBAUD
2010-10-31 18:36 ` Wolfgang Denk
2010-10-31 18:38 ` Alexander Holler
2010-10-31 19:01 ` Wolfgang Denk
2010-10-31 19:07 ` Albert ARIBAUD
2010-10-31 19:22 ` Wolfgang Denk
2010-10-31 19:40 ` Albert ARIBAUD
2010-10-31 19:59 ` Wolfgang Denk
2010-10-31 20:23 ` Albert ARIBAUD
2010-10-31 20:32 ` Wolfgang Denk
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
2010-10-31 21:51 ` Wolfgang Denk
2010-10-31 21:55 ` Albert ARIBAUD
2010-10-31 22:28 ` Alexander Holler
2010-10-31 23:04 ` Albert ARIBAUD
2010-11-01 5:13 ` sughosh ganu
2010-11-01 8:12 ` Albert ARIBAUD
2010-11-01 9:13 ` Wolfgang Denk
2010-11-01 9:15 ` Wolfgang Denk
2010-11-01 17:03 ` Albert ARIBAUD
2010-11-01 19:23 ` Wolfgang Denk
2010-11-01 19:30 ` Albert ARIBAUD
2010-11-01 19:35 ` Wolfgang Denk
2010-11-01 20:04 ` Albert ARIBAUD
2010-11-01 19:44 ` Graeme Russ
2010-11-01 19:53 ` Albert ARIBAUD
2010-11-01 20:01 ` Wolfgang Denk
2010-11-01 20:19 ` Scott Wood
2010-11-02 6:29 ` Heiko Schocher
2010-11-02 6:54 ` Albert ARIBAUD
2010-11-02 7:10 ` Heiko Schocher
2010-11-02 8:33 ` Wolfgang Denk
2010-11-02 8:55 ` Heiko Schocher
2010-11-02 9:17 ` Stefan Roese
2010-11-09 19:19 ` Scott Wood
2010-11-02 9:21 ` Sughosh Ganu
2010-11-02 8:57 ` Reinhard Meyer
2010-11-02 9:11 ` Albert ARIBAUD
2010-11-02 9:34 ` Reinhard Meyer [this message]
2010-11-02 9:42 ` Albert ARIBAUD
2010-11-03 6:37 ` V, Aneesh
2010-11-03 8:02 ` Wolfgang Denk
2010-11-03 10:39 ` V, Aneesh
2010-11-03 11:27 ` Wolfgang Denk
2010-11-03 12:03 ` V, Aneesh
2010-11-03 12:08 ` Albert ARIBAUD
2010-11-03 12:20 ` V, Aneesh
2010-11-03 13:00 ` Wolfgang Denk
2010-11-03 14:07 ` V, Aneesh
2010-11-03 18:25 ` Wolfgang Denk
2010-11-02 9:38 ` Wolfgang Denk
2010-11-02 9:47 ` Albert ARIBAUD
2010-11-02 9:56 ` Sughosh Ganu
2010-11-02 11:16 ` Albert ARIBAUD
2010-11-02 11:32 ` Sughosh Ganu
2010-11-02 13:28 ` Wolfgang Denk
2010-10-31 19:01 ` [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert ARIBAUD
2010-10-31 18:35 ` Darius Augulis
2010-10-31 18:53 ` Albert ARIBAUD
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=4CCFDB14.3060809@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--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