Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • early-display
  • variant-emmc-nvme-boot
  • 2023-01-25
  • v3
  • variant-emmc-nvme-boot
  • 2020-06-01
7 results

board_r.c

Blame
  • 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>