From: Arnout Diels <arnout.diels@dekimo.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Data abort during relocation
Date: Thu, 11 Jul 2019 15:33:05 +0200 [thread overview]
Message-ID: <017301d537ed$2b941700$82bc4500$@dekimo.com> (raw)
Hello all,
I ran into a data abort in uboot during relocation (in relocate_code in
relocate.S), in the "fixloop macro":
ENTRY(relocate_code)
.
/*
* fix .rel.dyn relocations
*/
ldr r2, =__rel_dyn_start /* r2 <- SRC
&__rel_dyn_start */
ldr r3, =__rel_dyn_end /* r3 <- SRC
&__rel_dyn_end */
fixloop:
ldmia r2!, {r0-r1} /*
(r0,r1) <- (SRC location,fixup) */
and r1, r1, #0xff
cmp r1, #23 /*
relative fixup? */
bne fixnext
/* relative fix: increase location by offset */
add r0, r0, r4
ldr r1, [r0] <======== DataAbort
add r1, r1, r4
str r1, [r0]
fixnext:
cmp r2, r3
blo fixloop
relocate_done:
This happened after I added some trivial code somewhere totally different
and unrelated (somewhere in my board.c file, that only gets called after
relocation anyway). The only thing that I can think of, is that this shifted
some sections in size. Anway,
As far as I can tell, the dynamic relocation code checks if some word in
that region is 23, and if so, will try to use the previous word as address
(and add the relocation offset).
For some reason, r0 was zero somewhere in my case. After adding the
relocation offset (of 0x18722000), the dereferencing is invalid (RAM only
starts@0x8000.0000) and causes the abort.
I now patched the code with this, and this fixes the abort for me:
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 475d503..fba30b9 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -98,6 +98,9 @@ fixloop:
and r1, r1, #0xff
cmp r1, #23 /*
relative fixup? */
bne fixnext
+ /* Check that the data is not 0. If so, skip it */
+ cmp r0, #0
+ beq fixnext
/* relative fix: increase location by offset */
add r0, r0, r4
Even though this fixes my issue, I don't understand what exactly this is
trying to relocate in the first place, and what could be the relation with
my seemingly unrelated change. Is this code fully ok? Or is there some edge
case where the data is allowed to be zero?
Does somebody know more about this, so we can check if there is anything
that really needs fixing?
Thanks for any feedback.
Kind regards,
Arnout
reply other threads:[~2019-07-11 13:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='017301d537ed$2b941700$82bc4500$@dekimo.com' \
--to=arnout.diels@dekimo.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