summaryrefslogtreecommitdiff
path: root/common/cmd_dcr.c
diff options
context:
space:
mode:
authorAlexey Brodkin <abrodkin@synopsys.com>2014-01-20 14:30:39 +0400
committerTom Rini <trini@ti.com>2014-01-27 08:28:13 -0500
commit7395398ad273f11569f4c4f3fb45219b916480eb (patch)
tree29968b1fa5bcd5582831adbe200be9ae4b6c3bb2 /common/cmd_dcr.c
parent2b36fe579c975f0e47761e5fcb602b8ae4537c6e (diff)
downloadu-boot-imx-7395398ad273f11569f4c4f3fb45219b916480eb.zip
u-boot-imx-7395398ad273f11569f4c4f3fb45219b916480eb.tar.gz
u-boot-imx-7395398ad273f11569f4c4f3fb45219b916480eb.tar.bz2
board_r - fixup functions table after relocation
This is only required for "PIC" relocation and doesn't apply to modern "PIE" relocation which does data relocation as well as code. "init_sequence_r" is just an array that consists of compile-time adresses of init functions. Since this is basically an array of integers (pointers to "void" to be more precise) it won't be modified during relocation - it will be just copied to new location as it is. As a consequence on execution after relocation "initcall_run_list" will be jumping to pre-relocation addresses. As long as we don't overwrite pre-relocation memory area init calls are executed correctly. But still it is dangerous because after relocation we don't expect initially used memory to stay untouched. Cc: Tom Rini <trini@ti.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Thomas Langer <thomas.langer@lantiq.com> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Diffstat (limited to 'common/cmd_dcr.c')
0 files changed, 0 insertions, 0 deletions