[U-Boot-Users] booting elf images where VMA != LMA

[U-Boot-Users] booting elf images where VMA != LMA

[Robin Getz]

The elf standard (& the gnu linker) supports two types of memory addresses:
  - virtual memory address (VMA).
     This is the address the section will have when the output file is run.
  - load memory address (LMA)
     This is the address at which the section will be loaded.

In most cases the two addresses will be the same (LMA equal to the VMA). An 
example of when they might be different is when a data section is loaded 
into ROM, and then copied into RAM when the program starts up. In this case 
the ROM address would be the LMA, and the RAM address would be the VMA.

What seems to happen in the 'bootelf' command in U-boot, is it ignores the 
LMA, and loads things at the VMA. This means that any elf image that 
expects things to be at the LMA at run time does not function properly, as 
things have already been relocated. (Normally when LMA != VMA, relocation 
is done in the startup code).

Question is:
  - Do I patch the standard elf relocation code to always load things at 
the LMA?
  OR
  - Do I patch the standard elf relocation code to load at the LMA when 
CONFIG_ELF_LOAD_LMA is set? (or some such thing)

Comments welcome.

Thanks
-Robin

Details of the issue:

Looking at the elf file with objdump and readelf shows a section named 
.text_l1, with a VMA = ffa00000, and a LMA = 000f27c8.

'objdump -h' gives me:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
(--snip--)
   5 .text_l1      00000170  ffa00000  000f27c8  000e4000  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
(--snip--)


'readelf -S' provides:

Section Headers:
   [Nr] Name              Type            Addr     Off    Size ES Flg Lk Inf Al
(--snip--)
   [ 6] .text_l1          PROGBITS        ffa00000 0e4000 
00017000  AX  0   0 16
(--snip--)


'readelf -l' provides

Elf file type is EXEC (Executable file)
Entry point 0x1000
There are 2 program headers, starting at offset 52

Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   LOAD           0x001000 0x00001000 0x00001000 0xe2be0 0xf17c8 RWE 0x1000
   LOAD           0x0e4000 0xffa00000 0x000f27c8 0x00170 0x00170 R E 0x1000

  Section to Segment mapping:
   Segment Sections...
    00     .text .init .data .bss
    01     .text_l1


It looks like the elf relocation loads sections from the section list 
rather than use the segment (program) header (which is where the load 
address and virtual addresses are stored).

uboot with bootelf says :
Bytes transferred = 5328594 (514ed2 hex)
(--snip--)
Loading .text_l1 @ 0xffa00000 (368 bytes)
(--snip--)


Futher reading (and where I snipped some of the above from) is at:
http://sources.redhat.com/binutils/docs-2.15/ld/Basic-Script-Concepts.html#Basic%20Script%20Concepts
http://sources.redhat.com/binutils/docs-2.15/ld/Output-Section-LMA.html

[U-Boot-Users] booting elf images where VMA != LMA

[John W. Linville]

On Fri, Mar 25, 2005 at 09:53:55AM -0500, Robin Getz wrote:
> The elf standard (& the gnu linker) supports two types of memory addresses:

> Question is:
>  - Do I patch the standard elf relocation code to always load things at 
> the LMA?

This certainly seems like the correct thing to me.  What are the
potential disadvantages of this approach?  Are there any?

John
-- 
John W. Linville
linville at tuxdriver.com

[U-Boot-Users] booting elf images where VMA != LMA

[Robin Getz]

> >  - Do I patch the standard elf relocation code to always load things
> > at the LMA?
>
>This certainly seems like the correct thing to me.  What are the potential 
>disadvantages of this approach?  Are there any?

I can only think of two disadvantages:
- if someone is using a old or broken toolchain that does not comply with 
ELF. (which is why I thought of using a config switch).
- may take a little longer (few cycles) to look in the correct place to get 
the LMA.

I am sure other may think of more - which is why I asked the question, 
before the patch.

Thanks
-Robin 

[U-Boot-Users] booting elf images where VMA != LMA

[John W. Linville]

On Fri, Mar 25, 2005 at 06:28:18PM -0500, Robin Getz wrote:

> - if someone is using a old or broken toolchain that does not comply with 
> ELF. (which is why I thought of using a config switch).

How old of a toolchain are we contemplating?  I wouldn't put a lot
of effort into support crufty old tools...

> - may take a little longer (few cycles) to look in the correct place to get 
> the LMA.

I can't imagine this be significant enough to bother with a new
config option...?

Just my $0.02...

John
-- 
John W. Linville
linville at tuxdriver.com