PowerPC uboot link Script Big makeover

After the completion of the Linux from ARM processor core to the PPC processor core work, but also need to carry out uboot porting, before the analysis of Uboot is based on the arm platform, interested friends can see, links are as follows:
Http://blog.csdn.net/column/details/uboot-note.html
Take this PPC transplant work, also learned the PPC Uboot related knowledge, by writing several articles recorded.
The working background is that the company processor is replaced by the ARM processor core Cortex A8 for the PPC processor core ppc460s, which is now in the FPGA simulation verification phase, the peripheral controller of the SOC has not changed.

uboot Version number: 2014.04
Platform: powerpc460s

Based on the porting experience of previous arm version uboot, a complete uboot transplant I think can be divided into 3 steps:
(1) According to the requirements, uboot configuration, links and other aspects of the changes, add the necessary board-level support function (first empty function), to ensure that the uboot can compile the link through.
(2) Starting from START.S, the functions of each key function are debugged according to the Uboot initiation process. Ensure that the uboot normally starts into the command line.
(3) separate debugging for each module driver.

So I modify the boards.cfg, modify the configuration file, determine the first address of the code snippet, memory header address and other basic elements. Expectations can be directly compiled.
But after looking at the link script for the ppc460s processor, I think the problem is a little more complicated than I thought. The
changes the link script for PPC According to my actual needs, in fact, to re-layout the sections in the Uboot image. Take the 11 vacation today to record the transformation process of PPC uboot link script.
first to analyze the layout of each section of the original uboot, ppc460s belongs to the PPC4XX series, so the link script is arch/powerpc/cpu/ppc4xx/u-boot.lds. Combined with Arch/powerpc/cpu/ppc4xx/start. s and other code, I drew the PPC4XX series processor Uboot section layout is as follows. The

Bootpg and Resetvec are located in 4k space at the top of the address space, and the remaining segments are at the specified address. The dashed line indicates the processor's power-on execution process.
Here you need to briefly explain the next PPC4XX series of processor features, the PPC4XX series processor is a large feature of the MMU is normally open, power on is turned on. After power-up, Ppc4xx has a shadow tlb that maps the top 4k of the address space to where it's mapped, depending on how the internal logic of the processor fills the TLB, and the address arbitration of the external bus, which asks the IC design to know. Therefore, the first power on the PPC4XX processor can only access the top 4K, and the power-on address is 0XFFFFFFFC, so in the PPC4XX series processor, bootloader design is generally 0XFFFFFFFC for the jump instruction, jump to the 4k start address execution, In this 4k code, the address space that needs to be accessed is TLB mapped, and then jumps to the main code snippet execution. It can be seen that the design of Uboot is to follow this feature, the power on the first execution of the jump _start_440, jumping to the beginning of the 4k execution, after initiating the TLB _start, enter the code segment execution. The
therefore uboot can be used entirely as a bootloader of the PPC4XX processor, and the power-up directly executes the uboot.

But for our company's processors, problems arise, as follows:
(1) The company's processor logic will map the top 4k space to the on-chip 64k ROM, the ROM storage company developed bootloader,uboot too big to put in
(2) Uboot is actually equivalent to a level two bootloader, by the company bootloader load uboot Start, uboot make the necessary configuration and parameter preparation, then to start kernel
(3) The needs of the company's processor is uboot directly in memory, just a connecting link to the role of kernel for the transfer of parameters.
From the requirements of the company's processor, the required uboot is not a complete bootloader, but only in memory, to prepare parameters for kernel, load boot kernel can be. So the Uboot section layout needs to be reformed.

According to this demand, the uboot of the link layout I proposed to improve the program as follows:
(1) The task of top jump and address space mapping is completed by first level bootloader, uboot only need to run directly in memory, so consider removing BOOTPG and Resetvec.
(2) The original code snippet execution is by _start_440–>_start jump to cut into, now need to manually specify the Uboot entry for _start.

For the first improvement scenario, the retention Bootpg was initially considered, but since BOOTPG is in the top 4k of the address space, according to the actual processor address space distribution, my Code snippet start address Config_sys_text_base is in memory 0x80e80000, In this way, when the final link is delivered to U-boot.bin, there will be a 1G size, because the top position of the segment BOOTPG and the lowest position of the segment text between nearly 1G, the gap between the time the image is generated to be reserved, to ensure that the load is able to load each segment in the correct position.

Here is a question, what other ppc4xx processor, if using Uboot as a first-class Bootloader,text segment in memory, and memory address is far from the top of the address space, the compiled u-boot.bin will be very large?
Looking at the code for another ppc4xx processor, the workaround is to map the memory in 4k code to an address close to the top 4k, while modifying config_sys_text_base as the address. This compiles the link to come out U-boot.bin is not big.

So for my consideration above, there is a very important premise that I do a flat mapping in the 4k code for the address space that needs to be used. This is true of the first-level bootloader of the company's processor.

So think about it, for my UBOOT,BOOTPG segment there is also a workaround, is to retain the BOOTPG, modify the TLB map, the memory snippet address map to the location near the top 4k, and modify the config_sys_text_base.
However, due to the existence of a first-level bootloader, the jump and the TLB mapping work has been done, so uboot do not need 4k code, in order to transplant simple, I still use the BOOTPG and other paragraphs deleted the method.

So I'm going to arch/powerpc/cpu/ppc4xx/u-boot.lds the code below.

#if 0#ifndef CONFIG_SPL#ifdef config_440. BOOTPGreset_vector_address-0XFFC: {ARCH/POWERPC/CPU/PPC4XX/START.O (. bootpg)/ * * PPC440 Board need a board specific object with the * TLB definitions.     This needs-get included right after * START.O, since the first shadow TLB only covers 4k * of address space. */#ifdef config_init_tlb   config_init_tlb(. Bootpg)#elseCONFIG_BOARDDIR/INIT.O (. Bootpg)#endif}: Text =0xFFFF#endif. Resetvecreset_vector_address: {KEEP (* (. Resetvec)}: Text =0xFFFF. =reset_vector_address+0x4;/ * Make sure that the BSS segment isn ' t linked at 0x0, otherwise its * address won ' t is updated during relocatio  N fixups.  Note that * This is a temporary fix.  Code to dynamically the fixup the BSS * location would be added in the future.   When the BSS relocation * Fixup code was present this workaround should be removed. */#if (reset_vector_address = = 0XFFFFFFFC). |=0x10;#endif#endif/* CONFIG_SPL * /#endif__bss_start =.; . BSS (NOLOAD): {* (. bss*) * (. sbss*) * (COMMON)}: BSS. = ALIGN (4); __bss_end =. ;provide(end =.);

Comment out the BOOTPG resetvec segment definition in U-boot.lds. One thing to note here is the BSS segment. At the end of the discussion.
After you modify the link script, you will also need to start. The BOOTPG section code in s and the Resetvec code in Resetvec.s are also commented out, which is not listed here.
Here, the whole BOOTPG resetvec section is removed, the original U-boot execution is in accordance with the power-on entry address 0XFFFFFFFC, the way to jump into the _start, into the text code snippet execution.
Now, without the BOOTPG Resetvec,u-boot.bin, the entry address needs to be specified.
The linker ld can specify the start address of the text segment through the parameter-ttext, specifying the program entry address via the parameter-E. In the makefile of Uboot, the following:

$(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%)     $($(CONFIG_SYS_TEXT_BASE)

The default is that the Uboot entry address is the same as the code snippet start address. However, according to the above U-boot section distribution map can be seen, the real entry address of the text segment is _start, the front 0x2100 size code is the version string and the exception vector table.
Therefore, you need to specify the entry address for the next uboot. My method of modification is to add the following code to the U-boot.lds.

ENTRY(_start)

Specify the entry address at the _start,_start address that is the text segment start address plus 0x2100.
After the link script as modified, compile through uboot also need some board-level support function, for PowerPC platform, such as Initsdram Board_early_init_r, can be empty function, wait for the function debugging and perfect, finally uboot compiled through.
I view the generated u-boot through Readelf, as follows:

[Email protected]:~/u-boot$ powerpc-linux-readelf-h u-bootelf header:magic:7f 4c 46 01 02 01 00 00 00 00 00 00 00                           XX class:elf32 data:2 ' s complement, big endian Version:                       1 (current) Os/abi:unix-system V ABI Version:                           0 type:exec (executable file) Machine:powerpc Version: 0x1 Entry Point address:0x80e82100Start  ofProgram headers: the(bytes intoFileStart  of  SectionHeaders600904(bytes intoFile) Flags:0x18000, Relocatable, Relocatable-libSize  ofThis header: the(bytes)Size  ofProgram headers: +(bytes) Number  ofProgram headers:2  Size  of  SectionHeaders +(bytes) Number  of  SectionHeaders -   SectionHeader stringTableIndex -

As you can see, the entry address is exactly the _start address that I specified, and then we look at the distribution of each segment, as follows:

[Email protected]:~/u-boot$ powerpc-linux-readelf-s U-bootthere is -section headers, starting at offset0x92b48: section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [0] NULL00000000 000000 000000 xx      0   0  0[1]. TextProgbits80e80000 000074 017510 xxAx0   0  4[2]. RodataProgbits80e97510 017584 005717 xxA0   0  4[3]. RelocProgbits80e9Cd00 onCd740014B8GenevaWAX0   0  4[4]. DataProgbits80e9E1b801e22C001120 xxWA0   0  4[5]. U_boot_list progbits80e9F2d8 onf34c0004F8xxWA0   0  4[6]. BSSNobits80e9f800 onf844002798 xxWA0   0  4[7]. Debug_line progbits00000000  onf844xxc63cxx      0   0  1[8]. Debug_info progbits00000000  GenevaBe800338e8 xx      0   0  1[9]. Debug_abbrev progbits00000000  tof768xxb114xx      0   0  1[Ten]. Debug_aranges progbits00000000  .a8800018D8xx      0   0  8[ One]. CommentProgbits00000000  .c158000027  onMs0   0  1[ A]. GNU. AttributesLoos+ffffff500000000  .c17f000012 xx      0   0  1[ -]. Debug_frame progbits00000000  .c1940046dcxx      0   0  4[ -]. Debug_str progbits00000000 070870 0063F9 onMs0   0  1[ the]. Debug_loc progbits00000000 076C6901934Fxx      0   0  1[ -]. Debug_ranges progbits00000000  ,Ffb8002Ac8xx      0   0  8[ -]. ShstrtabStrtab00000000 092A800000C7xx      0   0  1[ -]. SymtabSymtab00000000 092e68 004080 Ten      + 533  4[ +]. StrtabStrtab00000000 096Ee80031B5xx      0   0  1Key to Flags:w (write), A (Alloc),X(execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude),x(unknown) O (extra OS processing required) O (OS specific), p (processor specific)

The code snippet starts at 0x80e80000. All meet my requirements.
The transformation of the U-boot link script is done for the needs of the company's processors.

In the process of transformation I think there are 2 places worth thinking about.
1 BSS questions
when modifying u-boot.lds to remove BOOTPG Resetvec, I noticed that the BSS definition is above Resetvec and Resetvec has reached the vertex of the address space where BSS went.
later actually compiled I found that, according to U-boot.lds definition, Resetvec at 0XFFFFFFFC, BSS is located in (0xfffffffc+4) | 0x10 position, The address is 0x10. If Resetvec is defined in another location, the BSS is above the Resetvec.
based on the elf file U-boot generated by the compilation, gets the size of each segment, compared with U-boot.bin, as follows:

zk@server2:~/u-boot$ size u-boot   text    data     bss     dec     123103    5656   10136  138895   21e8f u-bootzk@server2:~/u-boot$ 11262015-10-0115:22 u-boot.bin

U-boot.bin is basically equal to the sum of text and data paragraphs, the question is, where is the BSS section?

Find information on the Internet only to know that the original in the final program image, there is no BSS segment.
Why get rid of the BSS section, think about it, I understand that the BSS section includes uninitialized and initialized to 0 global variables and static variables, the data is all 0, but occupy a large space, in order to reduce the mirror size, the BSS segment is deleted when the image is generated.
According to the Uboot code can be known, for uboot such a naked program, in its startup process will open the BSS segment, and the BSS section is emptied to ensure that the data is all 0.
This will not affect the use of subsequent global variables and static variables.

Then my question came again, in the process of opening and emptying the BSS section, how to know the address range of the BSS segment.

This is a question to think about the answer, in the process of compiling links, we can determine the starting and ending address of the BSS section, in U-boot.lds with __bss_start and __bss_end to express.
And the start and end address is recorded in the u-boot of this elf file in the table, that is, the above readelf see the results of the list of segments,
The final generation of U-boot.bin when the BSS is removed, and indeed should be removed, occupy a large space is also all 0, fully can be run in the program and then according to __bss_start and __bss_end to allocate empty.

In summary, the process of generating BSS in Uboot can be divided into the following steps:
(1) The link script defines the BSS segment address range __bss_start __bss_end.
(2) When compiling the link elf, the absolute address of the next __bss_start __bss_end is determined according to the link script, which is recorded in the section table of the Elf file.
(3) When Elf Objcopy generates U-boot.bin, the BSS segment is removed.
(4) Load U-boot.bin start operation, according to __bss_start __bss_end open BSS section, and all emptied to 0.
(5) A global variable that accesses uninitialized and initialized to 0 in subsequent run code, and static variables are accessed into the BSS segment.
Therefore, the BSS segment is deleted in the image, but the dynamic allocation is emptied at runtime to reduce the image size.

2 The relationship between the starting address of the program and the entry address
From this revision of the PPC U-boot connection script, it can be seen that the program start address and the entry address is not a concept, completely can not be equal. Since the definition of the text segment is placed at the beginning of the U-boot.lds, the start address of the text segment is the starting address for the entire uboot image, and the code snippet is the most commonly used link. The entry address of the program can be specified by the linker's parameter-E.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

PowerPC uboot link Script Big makeover