diff options
author | Alexey Brodkin <abrodkin@synopsys.com> | 2014-01-20 14:30:39 +0400 |
---|---|---|
committer | Tom Rini <trini@ti.com> | 2014-01-27 08:28:13 -0500 |
commit | 7395398ad273f11569f4c4f3fb45219b916480eb (patch) | |
tree | 29968b1fa5bcd5582831adbe200be9ae4b6c3bb2 /common/cmd_mfsl.c | |
parent | 2b36fe579c975f0e47761e5fcb602b8ae4537c6e (diff) | |
download | u-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_mfsl.c')
0 files changed, 0 insertions, 0 deletions