Understanding of uboot.lds

I am trying to understand how the porting of uboot is done on powerpc mpc8313 processor based board. During this procedure I came across the file called uboot.lds, linker script file.

I need to understand this file. I mean the significance of the contents mentioned and where the actual addresses are defined in uboot package.

for example; in SECTIONS, where I can find the significance of the following information:

/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash          : { *(.hash)  }
.dynsym        : { *(.dynsym)  }
.dynstr        : { *(.dynstr)  }
.rel.text      : { *(.rel.text)  }
.rela.text     : { *(.rela.text)  }
.rel.data      : { *(.rel.data)  }
.rela.data     : { *(.rela.data)  }
.rel.rodata    : { *(.rel.rodata)  }
.rela.rodata   : { *(.rela.rodata)  }
.rel.got       : { *(.rel.got)  }
.rela.got      : { *(.rela.got)  }
.rel.ctors     : { *(.rel.ctors) }
.rela.ctors    : { *(.rela.ctors) }
.rel.dtors     : { *(.rel.dtors) }
.rela.dtors    : { *(.rela.dtors) }
.rel.bss       : { *(.rel.bss)  }
.rela.bss      : { *(.rela.bss)  }
.rel.plt       : { *(.rel.plt)  }
.rela.plt      : { *(.rela.plt)  }
.init          : { *(.init) }
.plt : { *(.plt) }
.text      :
{
  cpu/mpc83xx/start.o (.text)
  *(.text)
  *(.fixup)
  *(.got1)
  . = ALIGN(16);
  *(.rodata)
  *(.rodata1)
  *(.rodata.str1.4)
  *(.eh_frame)
}
.fini      : { *(.fini)    } =0
.ctors     : { *(.ctors)   }
.dtors     : { *(.dtors)   }

/* Read-write section, merged into data segment: */
. = (. + 0x0FFF) & 0xFFFFF000;
_erotext = .;
PROVIDE (erotext = .);
.reloc   :
{
  *(.got)
  _GOT2_TABLE_ = .;
  *(.got2)
  _FIXUP_TABLE_ = .;
  *(.fixup)
}
__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
__fixup_entr开发者_C百科ies = (. - _FIXUP_TABLE_) >> 2;

.data    :
{
  *(.data)
  *(.data1)
  *(.sdata)
  *(.sdata2)
  *(.dynamic)
  CONSTRUCTORS
}
_edata  =  .;
PROVIDE (edata = .);

. = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;


. = .;
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;

. = ALIGN(4096);
__init_begin = .;
.text.init : { *(.text.init) }
.data.init : { *(.data.init) }
. = ALIGN(4096);
__init_end = .;

__bss_start = .;
.bss       :
{
 *(.sbss) *(.scommon)
 *(.dynbss)
 *(.bss)
 *(COMMON)
}
_end = . ;
PROVIDE (end = .);
}

where to look for this information and how to identify the changes to be done in lds file?

Please acknowledge or atleast give some pointers to read the information, thank you

Regads, Vijay

---

To port u-boot, the u-boot.lds can probably be used from the cpu directory and not the board directory. In other words, there is probably no need to port this file. However, if there is then here is an overview.

You can find lots of information in the LD documentation.

In general, what LD scripts allow you to do is to override the default places that the GCC tool chain places things in memory when run. When you compile an application, the source code is processed and object code files containing machine code are created. During linking the various object files are combined into one file, ELF executable for example, and a header is placed on the file to tell the OS where each object file should be placed in memory so that it can be found when needed (globals, function calls, etc.)

A custom script is needed if you want to place the code in a specific place that you cannot expect the complier/linker to guess. There are many reasons to do this, as I will try to list.

1. Constants may be placed in Read-Only memory if RAM is sparse
2. Memory that is accessed a lot may need to be placed in faster RAM if available
3. Some data may need to be aligned on a certain boundary, such as 64K
4. Some code (.TEXT) should be placed at the reset vector so that it is executed at reset
5. Same for ISR code vectors

Besides this, it can be a way to get convenient access to memory pointers at linkage time. For example, __init_begin is defined as a symbol that has the memory address of any code compiled as *.text.init. You can now call that memory by setting the program counter to the value of __init_begin without having a full C environment configured.

The compiler documentation + u-boot Makefiles should explain how and when the compiler generates object files of each type (ex. .txt, .data, .bss, .fini, .ctors, etc.)