Loading RTEMS-application with U-boot on Raspberry Pi or MicroZed

[Jan Sommer]

Am Tuesday 12 April 2016, 08:07:35 schrieb Sebastian Huber:
> On 11/04/16 15:43, Jan Sommer wrote:
> > I just tried the same setup with the Xilinx MicroZed board at work.
> > There, the same behaviour appears.
> > If I compile a simple bare metal application I can load the binary to 
> > the correct address and run it or load the elf-file somewhere into the 
> > memory and use the bootelf-command to start the application.
> > If I try to do the same with a compiled RTEMS-application, it won't 
> > work. The same RTEMS-application runs if I put it directly into the 
> > bootimage (without using u-boot).
> >
> > How does it work on other ARM-boards? The BeagleBone uses u-boot to 
> > load all its binaries, doesn't it? 
> 
> You have to specify the correct entry and load addresses for the 
> mkimage.  For example:
> 

Ok. If I try to follow that procedure, I have:
readelf -l  blinker-rtems.exe 
Elf file type is EXEC (Executable file)
Entry point 0x8040
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x010014 0x00100c54 0x00100c54 0x00008 0x00008 R   0x4
  LOAD           0x0000b4 0x00000000 0x00000000 0x00000 0x01440 RW  0x1
  LOAD           0x0000b4 0x00008000 0x00008000 0x0f300 0xf8000 RWE 0x4
  LOAD           0x00f3c0 0x00100000 0x00100000 0x01280 0x7efc000 RW  0x20

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx 
   01     .vector 
   02     .start .text .init .fini .robarrier 
   03     .rodata .ARM.exidx .eh_frame .init_array .fini_array .jcr .rtemsroset .data .bss .work 

.start is in section 02, hence my load address would be 0x8000 and the entry point is 0x8040 (I hope I got that right?).
If I create my image using:
mkimage -A arm -O rtems -T standalone -C none -a 0x8000 -e 0x8040 -d blinker-rtems.exe  blinker-rtems.img
And load it via u-boot with 
fatload mmc 0:1 ${kernel_addr_r} blinker-rtems.img
bootm ${kernel_addr_r}

It either hangs after Transferring control to RTEMS or resets with:
## Booting kernel from Legacy Image at 01000000 ...

   Image Name:   blinker1

   Image Type:   ARM RTEMS Standalone Program (uncompressed)

   Data Size:    3494208 Bytes = 3.3 MiB

   Load Address: 00008000

   Entry Point:  00008040

   Verifying Checksum ... OK

   Loading Standalone Program ... OK

## Transferring control to RTEMS (at address 00008040) ...

data abort

pc : [<19273304>]\0x09   lr : [<1bf59eb0>]

reloc pc : [<fd330304>]\0x09   lr : [<00016eb0>]

sp : 1bb46c00  ip : 00000520\0x09 fp : 1bf59e84

r10: 00000000  r9 : 1bb46ee8\0x09 r8 : 400001d3

r7 : 1bb475bc  r6 : 1bf59e84\0x09 r5 : 1bf912bc  r4 : 00000000

r3 : 00000002  r2 : 00000000\0x09 r1 : 00000000  r0 : 400001d3

Flags: nZcv  IRQs off  FIQs off  Mode SVC_32

Resetting CPU ...

resetting ...

Again, if I follow the same procedure with the simple bare metal application, it works.

Best regards,

   Jan

> readelf -l ticker.exe
> 
> Elf file type is EXEC (Executable file)
> Entry point 0x400145
> There are 5 program headers, starting at offset 52
> 
> Program Headers:
>    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>    EXIDX          0x00ec70 0x0040eb70 0x0040eb70 0x00008 0x00008 R 0x4
>    LOAD           0x000100 0x00400000 0x00400000 0x0ebc4 0x0ebc4 RWE 0x40
>    LOAD           0x00ecc8 0x20401148 0x0040ebc4 0x006a4 0x006a4 RW 0x8
>    LOAD           0x00f380 0x20400000 0x20400000 0x00000 0x5f000 RW 0x20
>    LOAD           0x00f36c 0x2045f000 0x2045f000 0x00000 0x01000 RW 0x1
> 
>   Section to Segment mapping:
>    Segment Sections...
>     00     .ARM.exidx
>     01     .start .text .init .fini .rodata .ARM.exidx .eh_frame 
> .init_array .fini_array .jcr .rtemsroset
>     02     .data
>     03     .vector .bss .work
>     04     .xbarrier .robarrier .rwbarrier .stack .nocachenoload
> 
> Then use:
> 
> mkimage -a 0x00400000 -e 0x400145
> 
>