[U-Boot] [PATCH] elf: use program header for loading

[Tom Rini <trini@konsulko.com>]

On Mon, Dec 12, 2016 at 11:50:31AM +0100, Christian Gmeiner wrote:
> Sorry for the late reply.. had some days off.
> 
> >
> >> The section header address is a VMA whereas the address found in
> >> the program header is a physical one. With this change it is
> >> possible to load and start a vx7 intel generic based image.
> >>
> >> $ readelf -l /tmp/vx7
> >>
> >> Elf file type is EXEC (Executable file)
> >> Entry point 0x408000
> >> There are 2 program headers, starting at offset 52
> >>
> >> Program Headers:
> >>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >>   LOAD           0x001000 0x00408000 0x00408000 0x04000 0x04000 RWE 0x1000
> >>   LOAD           0x005000 0xe040c000 0x0040c000 0x583a84 0x5ccc70 RWE 0x1000
> >>
> >>  Section to Segment mapping:
> >>   Segment Sections...
> >>    00     .text.locore .data.locore
> >>    01     .text .eh_frame .wrs_build_vars .data .tls_data .tls_vars .bss
> >>
> >> $ readelf -S /tmp/vx7
> >> There are 13 section headers, starting at offset 0x588af8:
> >>
> >> Section Headers:
> >>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >>   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
> >>   [ 1] .text.locore      PROGBITS        00408000 001000 00011e 00  AX  0   0 16
> >>   [ 2] .data.locore      PROGBITS        00409000 002000 003000 00  WA  0   0 4096
> >>   [ 3] .text             PROGBITS        e040c000 005000 4802a0 00 WAX  0   0 32
> >>   [ 4] .eh_frame         PROGBITS        e088c2a0 4852a0 0a1ed0 00   A  0   0  4
> >>   [ 5] .wrs_build_vars   PROGBITS        e092e170 527170 000190 00  Ax  0   0  1
> >>   [ 6] .data             PROGBITS        e092f000 528000 060a70 00  WA  0   0 4096
> >>   [ 7] .tls_data         PROGBITS        e098fa70 588a70 000004 00   A  0   0  4
> >>   [ 8] .tls_vars         PROGBITS        e098fa78 588a78 00000c 00  WA  0   0  4
> >>   [ 9] .bss              NOBITS          e098faa0 588a84 0491d0 00  WA  0   0 32
> >>   [10] .shstrtab         STRTAB          00000000 588a84 000074 00      0   0  1
> >>   [11] .symtab           SYMTAB          00000000 588d00 056ee0 10     12 9758  4
> >>   [12] .strtab           STRTAB          00000000 5dfbe0 05f48a 00      0   0  1
> >> Key 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)
> >
> > First, this is within the realm of 'bootvx' and not 'bootelf', this
> > needs to be clear from the commit message.
> >
> 
> Okay.. will send a V2 shortly.
> 
> >> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
> >> ---
> >>  cmd/elf.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/cmd/elf.c b/cmd/elf.c
> >> index 5190cc6..445daa0 100644
> >> --- a/cmd/elf.c
> >> +++ b/cmd/elf.c
> >> @@ -376,7 +376,7 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> >>        * binary image.
> >>        */
> >>       if (valid_elf_image(addr))
> >> -             addr = load_elf_image_shdr(addr);
> >> +             addr = load_elf_image_phdr(addr);
> >
> > Have you tested this with an older VxWorks image as well?  Thanks!
> >
> 
> Yes.. a vx5.5 based image boots too and here is the readelf output:
> 
> $ readelf -l /tmp/vx5
> 
> Elf file type is EXEC (Executable file)
> Entry point 0x308000
> There are 1 program headers, starting at offset 52
> 
> Program Headers:
>  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>  LOAD           0x000060 0x00308000 0x00308000 0x3513a0 0x757860 RWE 0x20
> 
> Section to Segment mapping:
>  Segment Sections...
>   00     .text .data .bss
> [christian at chgm-pc ~]$ readelf -S /tmp/vx5
> There are 12 section headers, starting at offset 0x356580:
> 
> 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        00308000 000060 319b10 00 WAX  0   0 32
>  [ 2] .data             PROGBITS        00621b20 319b80 037880 00  WA  0   0 32
>  [ 3] .bss              NOBITS          006593a0 351400 4064c0 00  WA  0   0 16
>  [ 4] .debug_aranges    PROGBITS        00000000 351400 000060 00      0   0  1
>  [ 5] .debug_pubnames   PROGBITS        00000000 351460 00018b 00      0   0  1
>  [ 6] .debug_info       PROGBITS        00000000 3515eb 003429 00      0   0  1
>  [ 7] .debug_abbrev     PROGBITS        00000000 354a14 000454 00      0   0  1
>  [ 8] .debug_line       PROGBITS        00000000 354e68 0016a4 00      0   0  1
>  [ 9] .shstrtab         STRTAB          00000000 35650c 000071 00      0   0  1
>  [10] .symtab           SYMTAB          00000000 356760 0440e0 10     11 8574  4
>  [11] .strtab           STRTAB          00000000 39a840 03e66c 00      0   0  1
> Key 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)

Great, thanks.  Make sure to mention in the commit message that you've
tested both versions.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161212/83dbf5e5/attachment.sig>