[U-Boot] Some puzzles about u-boot.lds

Peter Chen hzpeterchen at gmail.com
Sat Jul 11 12:34:31 CEST 2009


Dear lists,

I met some problems about integrate our bootloader to u-boot, my working
CPU is ARM1136EJ-S.
Our boot routine likes below:

1. Rom code, and copy the first 4KB u-boot to ITCM (0x70000000), switch
to u-boot. ( cpu/arm1136/start.S)

2. u-boot running at ITCM, and config PLL, and memory, and switch to
romcode. (board/xxx/lowlevel_init.S)

3. If it is cold boot, copy the whole u-boot to Ram (the address ram
address is 0xc1000000)

4. Back from the rom code, and running first part of u-boot at ITCM.
(board/xxx/lowlevel_init.S, and cpu/arm1136/start.S)

5. After finishing setup stack and clear bss, jump to the start_armboot
(cpu/arm1136/start.S), the VMA of start_armboot is ram address
(0xc1000xxx)
   
I would like the first part is at 0x70000000( both VMA and LMA), and the
second part is at 0xc1000000 + sizeof(first boot), so I design the
u-boot.lds like
below:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
          
        . = ALIGN(4);
        . = 0x70000000; 
            
        .textboot :
        {
          cpu/arm1136/start.o   (.text)
          board/atlas5cb/lowlevel_init.o        (.text)
        }   

        . = ALIGN(4);
        _textram_start = 0xC1000000 + SIZEOF(.textboot);
            
        .textram 0xC1000000 + SIZEOF(.textboot):
        AT ( _textram_start )
        {
          *(.text)
        }   

        . = ALIGN(4);
        .rodata : { *(.rodata) }
        .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
        __exidx_start = .;
        .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
        __exidx_end = .;
       . = .;
        __u_boot_cmd_start = .;
        .u_boot_cmd : { *(.u_boot_cmd) }
        __u_boot_cmd_end = .;

        . = ALIGN(4);
        __bss_start = .;
        .bss : { *(.bss) }
        _end = .;

}
        
But it can't finish the link, it stops at: 
arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O
srec /home/nchen/work/L27EVB/Dev/bootloader/uboot/u-boot /home/nchen/work/L27EVB/Dev/out/bootloader/uboot/u-boot.srec

Why I can't set two LMA for two different text sections?

It can work after  I change the second text section's LMA just near to
the first one

     ...        
    . = 0x70000000;

        .textboot :
        {
          cpu/arm1136/start.o   (.text)
          board/xxx/lowlevel_init.o        (.text)
        }

        . = ALIGN(4);
        .textram 0xC1000000 + SIZEOF(.textboot):
      
        AT ( ADDR(.textboot) + SIZEOF(.textboot) )
        {
          *(.text)
        }


After that my output layout like to be:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .textboot     00000950  70000000  70000000  00008000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .textram      000130e0  c1000950  70000950  00008950  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00001858  c1013a30  70013a30  0001ba30  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rodata.str1.1 00003442  c1015288  70015288  0001d288  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .data         000407a4  c10186cc  700186cc  000206cc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .u_boot_cmd   00000348  c1058e70  70058e70  00060e70  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .bss          00004cb4  c10591b8  700591b8  000611b8  2**2
                  ALLOC

It should be ok If I set pc to VMA of start_armboot, as all parts of
u-boot is at correct ram regions now, although I did not do relocate.
After executing:
ldr pc, [r0] /* r0 stores VMA of start_armboot)
The pc goes to the undefined address, but I can set pc to start_armboot
using realview debugger.
Do you have any clues for such problems, Is it possible that my
u-boot.lds is not correct?

Although I can set pc to start_armboot, and let it run, but the system's
behavior is incorrect, and can't output anything.

By the way, the old structure ( our bootloader + u-boot + Linux ) is
work well, so the second part of u-boot should be ok.

Thank you

Best Regards,
Peter Chen



More information about the U-Boot mailing list