executing wrapped binary

Question

I am trying to execute a binary wrapped inside my own assembly code, there are reasons like i want to do some init and see how the binary behaves, however i am unable to execute the binary even without any such init, no output on uart, lcd (I am running an arm cortexa-8 based qsd8250b chipset powering a mdp[mobile development platform]) I know the wrapped binary runs perfectly on my board since i have used it earlier (less than a day ago).

Problem is, i am unsure/info is not available regarding where the binary is loaded in memory.

This is my code so far

.org 0
.type _start,#function
.globl _start
_start:
   b   main
@@ Snipped headers @@
.org   0x1000
main:
   mov r9, pc             @r9= address of loadlk in memory
   ldr r2, =loadlk        @r2= address of loadlk in objfile
loadlk:
   sub r0, r9, r2         @r0= r9-r2 = address of _start in memory
   add r0, r0, #0x1200    @r0= r0 + 0x1200 = lkbin_start (src)
   add r3, r0, #0xD000    @r3= r0 + 0xd000 = lkbin_start + ~sz(lk.bin) = lkbin_end (end)
cpy:
   ldr r1, =0x28000000    @r1= destination (dst)
   ldr r2, [r0],#4
   str r2, [r1],#4
   cmp r0, r3             @current read address ?= end, r0 &lt; r3 -> branch back
   blo cpy
   ldr r9, =0x28000000
   ldr r4, =0xa9000864    @Flashlight
   ldr r5, =0xa9000814
   ldr r4, [r4, #0]
   orr r6, r4, #0x200000
   str r6, [r5, #0]
   dsb sy
   isb sy
   bx  r9
   b   .
.ltorg
.org 0x1200
lkbin_start:
.incbin  "lk.bin"
lkbin_end:
.align 8

and this is my compile script

arm-none-eabi-as bootwrapper.S -o bootwrapper.o
arm-none-eabi-objcopy -O binary bootwrapper.o binary

It sure does reach the flashlight code as i see my flashlight blink, but then nothing happens, from what i can think it copies trash code to the target and tries to execute it.

Any help ?

Hint: Instead of manually calculating addresses, you can use the psuedo-instruction `adr r9, symbol` to get the address. The compiler should replace that with the appropriate mov and add instructions. — tangrs, Apr 03 '12 at 03:47
How different is that from what I'm doing now ? My code does that manually while in your method the compiler will do the same or replace the adr instruction with the same mov pc and subtract 8 to get current instruction address or add/subtract relative to instruction 8 byte ahead for some other label.. I had to give up the PIC capability and finally resorted to use linker to execute my application at a fixed address. — sgupta, Apr 03 '12 at 17:26
It's more maintainable that way. Not only that, it'll end up being easier to code because you won't have to manually calculate every thing. I would be working out how to get PIC to work for you instead. — tangrs, Apr 04 '12 at 01:12

score 0 · Answer 1 · answered Apr 12 '12 at 21:25

0

The directive .org won't place your code in the address you think. It'll generate code that thinks it's in that location. You'd need to place your code and data in the proper layout before the code gets executed.

I'd suggest that you use objdump -d to get an assembly view of what really got generated from your code.

answered Apr 12 '12 at 21:25

hesham_EE

1,125
13
24

I know that already, hence i am not using directly labels, look at the code first please. – sgupta Apr 13 '12 at 03:11
I might be wrong but here is what I see: **" b main"**, the compiler will assume this is a branch to 0x1000. But in reality your code didn't do anything to move "main" to that address but rather it's stuck a little bit away from address 0x0! – hesham_EE Apr 19 '12 at 18:02
LOL, ofcourse I'm using a linker and the @@snipped headers@@ part is used to tell the program which executes my program where to load this program into memory, and to be sure, I can trace code AFTER main by blink my device's flashlight, so that's not a problem for sure. – sgupta Jun 03 '12 at 15:08

score 0 · Accepted Answer · answered Jun 29 '12 at 19:10

Okay, i didn't know i could be this silly at night...

cpy:
   ldr r1, =0x28000000    @r1= destination (dst)
   ldr r2, [r0],#4
   str r2, [r1],#4
   cmp r0, r3             @current read address ?= end, r0 &lt; r3 -> branch back
   blo cpy

As the loop went on, r1 always had the value 0x28000000, so all data was written to one single location in memory overwriting the previous contents... how stupid.

executing wrapped binary

2 Answers2

Linked