Skip to content
Snippets Groups Projects
Forked from Reform / reform-boundary-uboot
Source project has a limited visibility.
  • Alexey Brodkin's avatar
    7395398a
    board_r - fixup functions table after relocation · 7395398a
    Alexey Brodkin authored
    
    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: default avatarSimon Glass <sjg@chromium.org>
    Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
    7395398a
    History
    board_r - fixup functions table after relocation
    Alexey Brodkin authored
    
    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: default avatarSimon Glass <sjg@chromium.org>
    Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>