summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorAlbert Aribaud <albert.aribaud@free.fr>2010-10-11 13:13:28 +0200
committerWolfgang Denk <wd@denx.de>2010-10-13 10:10:21 +0200
commit92d5ecba47feb9961c3b7525e947866c5f0d2de5 (patch)
treefd0917489d0f6c5b55bc5b32fe1e7247c6817f73 /doc
parent89bca0ab697fc75160dd0d685d7cb2ed26609a6d (diff)
downloadtalos-obmc-uboot-92d5ecba47feb9961c3b7525e947866c5f0d2de5.tar.gz
talos-obmc-uboot-92d5ecba47feb9961c3b7525e947866c5f0d2de5.zip
arm: implement ELF relocations
ELF relocation tables generated with linker option -pie can be used to fixup code and data in a single loop at relocation, removing the need for manual fixups anywhere else in the code. Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
Diffstat (limited to 'doc')
-rw-r--r--doc/README.arm-relocation222
1 files changed, 40 insertions, 182 deletions
diff --git a/doc/README.arm-relocation b/doc/README.arm-relocation
index e3ed60ecdc..b46347bb5b 100644
--- a/doc/README.arm-relocation
+++ b/doc/README.arm-relocation
@@ -1,49 +1,54 @@
To make relocation on arm working, the following changes are done:
-Add new compilerflag:
+At arch level: add linker flag -pie
--fPIC
+ This causes the linker to generate fixup tables .rel.dyn and .dynsym,
+ which must be applied to the relocated image before transferring
+ control to it.
- -> compiler generates position independent code
+ These fixups are described in the ARM ELF documentation as type 23
+ (program-base-relative) and 2 (symbol-relative)
-changes in board code:
+At cpu level: modify linker file and add a relocation and fixup loop
-- dram_init:
- - bd pointer is now at this point not accessible, so only
- detect the real dramsize, and store it in gd->ram_size.
- best detected with get_ram_size();
- ToDo: move there also the dram initialization on boards where
- it is possible.
- - setup the bd_t dram bank info in the new function
- dram_init_banksize().
+ the linker file must be modified to include the .rel.dyn and .dynsym
+ tables in the binary image, and to provide symbols for the relocation
+ code to access these tables
-- board.c code is adapted from ppc code
+ The relocation and fixup loop must be executed after executing
+ board_init_f at initial location and before executing board_init_r
+ at final location.
-- undef CONFIG_RELOC_FIXUP_WORKS
+At board level:
- -> cmdtabl, and subcommand table must be handled from "hand"
- collected in section "__datarellocal_start".
+ dram_init(): bd pointer is now at this point not accessible, so only
+ detect the real dramsize, and store it in gd->ram_size. Bst detected
+ with get_ram_size().
- - How To fixup the sections:
+TODO: move also dram initialization there on boards where it is possible.
- __datarel_start, __datarelrolocal_start, __datarellocal_start and
- __datarelro_start
+ Setup of the the bd_t dram bank info is done in the new function
+ dram_init_banksize() called after bd is accessible.
- automatically? Then it should be possible to define again
- CONFIG_RELOC_FIXUP_WORKS
+At lib level:
-- irq stack setup is now not longer on a fix position, instead it is
- calculated in board_init_f, and stored in gd->irq_sp
+ Board.c code is adapted from ppc code
--------------------------------------------------------------------------------------
+At config level:
-To compile a board without relocation, define CONFIG_SYS_ARM_WITHOUT_RELOC
-This possibility will removed!! So please fix your board to compile without
-CONFIG_SYS_ARM_WITHOUT_RELOC defined!!!
+ Define CONFIG_RELOC_FIXUP_WORKS.
+ Undefine CONFIG_SYS_ARM_WITHOUT_RELOC
--------------------------------------------------------------------------------------
+* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING *
+
+Boards which are not fixed to support relocation will be REMOVED!
+
+Eventually, CONFIG_SYS_ARM_WITHOUT_RELOC and CONFIG_RELOC_FIXUP_WORKS will
+disappear and boards which have to migrated to relocation will disappear too.
+
+-----------------------------------------------------------------------------
-For boards which boot from nand_spl, it is possible to save a copy
+For boards which boot from nand_spl, it is possible to save one copy
if TEXT_BASE == relocation address! This prevents that uboot code
is copied again in relocate_code().
@@ -64,9 +69,9 @@ f) u-boot code steps through board_init_f() and calculates
If TEXT_BASE == relocation address, the copying of u-boot
in f) could be saved.
--------------------------------------------------------------------------------------
+-----------------------------------------------------------------------------
-ToDo:
+TODO
- fill in bd_t infos (check)
- adapt all boards
@@ -80,7 +85,7 @@ ToDo:
- new function dram_init_banksize() is actual board specific. Maybe
we make a weak default function in arch/arm/lib/board.c ?
--------------------------------------------------------------------------------------
+-----------------------------------------------------------------------------
Relocation with NAND_SPL (example for the tx25):
@@ -98,158 +103,11 @@ Relocation with NAND_SPL (example for the tx25):
from the nand_spl code), no need to copy, just go on with bss clear
and jump to board_init_r.
--------------------------------------------------------------------------------------
-
-Relocation:
-How to translate flash addresses in GOT to ram addresses.
-This is automagically done from code, but this example
-shows, how this magic code works ;-)
-(example on the qong board)
-
-Find a variable:
-
-a) search it in System.map
-(for example flash_info)
-
-a005b4c0 B BootpID
-a005b4c4 B BootpTry
-a005b4c8 b slave
-a005b4cc B flash_info
-^^^^^^^^
-a005c908 b saved_sector.4002
-a005c910 b cfi_mtd_info
-a005c9c0 b cfi_mtd_names
-a005c9d0 B mtd_table
-
----------------------------------------
-
-b) create hexdump from u-boot code:
-
-hexdump -C u-boot > gnlmpfhex
-
----------------------------------------
-
-c) search the variables address in the hexdump
-
-
-*
-0005fc80 00 00 00 00 00 00 00 00 2c 06 01 a0 18 cd 05 a0 |........,.......|
-0005fc90 9c d4 05 a0 bc b4 05 a0 1c 7f 05 a0 f0 05 01 a0 |................|
-0005fca0 08 5a 04 a0 1c ab 05 a0 ec a4 05 a0 98 c3 01 a0 |.Z..............|
-0005fcb0 a0 d6 05 a0 04 71 05 a0 c0 f9 00 a0 3c cd 05 a0 |.....q......<...|
-0005fcc0 cc b4 05 a0 f0 fa 00 a0 f0 d6 05 a0 10 86 05 a0 |................|
- ^^^^^^^^^^^
-0005fcd0 a4 16 06 a0 dc 64 05 a0 18 86 05 a0 52 48 05 a0 |.....d......RH..|
-0005fce0 c0 86 05 a0 24 6e 02 a0 b4 6c 05 a0 b0 94 01 a0 |....$n...l......|
-0005fcf0 1c 86 05 a0 50 85 05 a0 d4 0c 06 a0 bc 0b 06 a0 |....P...........|
-
-
--> 0005fcc0
-
-----------------------------------------
-
-d) know we calculate this address in RAM
-
-
- 8ff08000 (new address of code in RAM *1)
-
-+ 0005fcc0
-
-- 00008000 (offset of text *2)
-
-----------
-
- 8ff5fcc0 -> Addr GOT in RAM
-
-*1:
-activate debug and look for the line:
-Now running in RAM - U-Boot at: 8ff08000
- ^^^^^^^^
- new address of u-boot code in RAM
-
-*2:
-Section Headers:
- [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
- [ 0] NULL 00000000 000000 000000 00 0 0 0
- [ 1] .text PROGBITS a0000000 008000 04599c 00 AX 0 0 32
- ^^^^^^
- Offset of text
+-----------------------------------------------------------------------------
-----------------------------------------
+How ELF relocations 23 and 2 work.
-e) now we look in 8ff5fcc0 (RAM)
-
-
-QongEVB>md 0x8ff5fcc0
-8ff5fcc0 : a005b4cc a000faf0 a005d6f0 a0058610 ................
- ^^^^^^^^
- Bingo, here we have the old flash address (when relocation
- is working, here is the fixed ram address. see @ f, how
- it gets calculated)
-
-
-----------------------------------------
-
-f) now translate it in the new RAM address
-
- a005b4cc
-
-- a0000000 TextBase
-
-+ 8ff08000 new address of u-boot in ram
-----------
- 8ff634cc
-
-QongEVB>mm 0x8ff5fcc0 0x8ff634cc 1
-QongEVB>md 0x8ff5fcc0
-8ff5fcc0 : 8ff634cc a000faf0 a005d6f0 a0058610 .4..............
-8ff5fcd0 : a00616a4 a00564dc a0058618 a0054852 .....d......RH..
-
-As this must be done for all address in the GOT, the u-boot
-code did this automagically ... :-)
-
-----------------------------------------------
-
-g) check if the new address is really in the bss section:
-
-bss start:
-8ff6054c (8ff08000 + 0005854C monitorlen)
-
-bss end:
-8ff698ac (8ff08000 + 618AC)
-
-8ff634cc is in bss :-)
-
-----------------------------------------------
-
-h) u-boot prints:
-
-important addresses:
-
-U-Boot code: A0000000 -> A005854C BSS: -> A00618AC TextBase 0xa0000000
-Now running in RAM - U-Boot at: 8ff08000 relocBase 0x8ff08000
-
-
----------
-
-U-Boot 2010.06-rc2-00002-gf8fbb25-dirty (Jun 18 2010 - 17:07:19)
-
-U-Boot code: A0000000 -> A005854C BSS: -> A00618AC
-CPU: Freescale i.MX31 at 398 MHz
-Board: DAVE/DENX Qong
-mon: FFFFFFFF gd->monLen: 000618AC
-Top of RAM usable for U-Boot at: 90000000
-LCD panel info: 640 x 480, 16 bit/pix
-Reserving 600k for LCD Framebuffer at: 8ff6a000
-Reserving 390k for U-Boot at: 8ff08000
-Reserving 1280k for malloc() at: 8fdc8000
-Reserving 28 Bytes for Board Info at: 8fdc7fe4
-Reserving 48 Bytes for Global Data at: 8fdc7fb4
-New Stack Pointer is: 8fdc7fb0
-RAM Configuration:
-Bank #0: 80000000 256 MiB
-mon: 0005854C gd->monLen: 000618AC
-Now running in RAM - U-Boot at: 8ff08000
+TBC
-------------------------------------------------------------------------------------
OpenPOWER on IntegriCloud