From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Question about relocation
Date: Sun, 17 Apr 2011 19:04:18 +0200 [thread overview]
Message-ID: <4DAB1D92.3080907@aribaud.net> (raw)
In-Reply-To: <20110417011939.GA18636@mail.gnudd.com>
Hi Alessandro,
Le 17/04/2011 03:19, Alessandro Rubini a ?crit :
> Hello.
> I'm trying to make at91sam9261ek working again, but relocation
> overlaps the destinatin address.
>
> In this board, u-boot runs already in RAM. This is exactly like the
> nhk8815 that I ported a few hours ago, but while there the IPL
> loaded our code at the beginning of RAM, in this case the IPL
> loaded us already at end of RAM.
>
> Now, this is the printout of the situation:
>
> U-Boot code: 23F00000 -> 23F36EFC BSS: -> 23F78570
> monitor len: 00078570
> ramsize: 04000000
> TLB table at: 23ff0000
> Top of RAM usable for U-Boot at: 23ff0000
> Reserving 481k for U-Boot at: 23f64000
> Reserving 180k for malloc() at: 23f37000
> Reserving 24 Bytes for Board Info at: 23f36fe8
> Reserving 144 Bytes for Global Data at: 23f36f58
> New Stack Pointer is: 23f36f50
> RAM Configuration:
> Bank #0: 20000000 64 MiB
> relocation Offset is: 00064000
>
> Since "tor len: 00078570" and "relocation Offset is: 00064000" the
> system data-aborts during relocation, as code overwrites relocation
> tables.
>
> What is the suggested solution? Changing the IPL is not acceptable for
> me, because it is an external tool used by everyone: everybody knows
> it loads and runs code at 23f0.0000.
>
> Thanks
> /alessandro
IIUC, the issue is with the moving of the image. One solution I see, and
which is not 100% perfect, would be that the copy code perform either a
beginning-to-end copy or an end-to-beginning copy depending on the
source and destination addresses and size.
So, when copying say 256K from 0x01000000 to 0x03FC0000, the code could
do the copy either way, beginning-to end (0x01000000 to 0x0103FFFF) or
end-to-beginning (0x0103FFFF to 0x01000000); but when copying from
0x03FB0000 to 0x03FC0000, only the end-to-beginning copy would be possible.
This still leaves holes in that copying U-Boot from RAM to RAM where the
source is *really* near the end might actually trash the copy code
itself. Maybe the instruction cache will help, but I won't bet on this
without heavy testing.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-04-17 17:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-17 1:19 [U-Boot] Question about relocation Alessandro Rubini
2011-04-17 17:04 ` Albert ARIBAUD [this message]
2011-04-17 17:57 ` Alessandro Rubini
2011-04-17 18:23 ` Albert ARIBAUD
2011-04-17 19:30 ` Alessandro Rubini
2011-04-17 19:47 ` Albert ARIBAUD
2011-04-18 9:16 ` Alessandro Rubini
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=4DAB1D92.3080907@aribaud.net \
--to=albert.u.boot@aribaud.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.