Emulating Digicam with QEMU

[chr]

@chr

Mh, I compared with my file. I got:
CONTENTS, ALLOC, LOAD, CODE

So, ALLOC & LOAD sections are missing?

if i understand your last post correctly, i changed disassemble.pl like this:

Code: [Select]

print "create elf file\n";
`$objcopy --change-addresses=$offset -I binary -O elf32-littlearm -B arm $binfile $binfile.elf`;
`$objcopy --set-section-flags .data=load $binfile.elf`;   <--- ADDED THIS
`$objcopy --set-section-flags .data=code $binfile.elf`;
 but "arm-elf-objdump -x dump.bin.elf" output remains the same...

From the objcopy man page:

       --set-section-flags section=flags
           Set  the  flags  for  the  named  section.  The flags argument is a comma separated string of flag names.  The recognized names are alloc, contents, load,
           noload, readonly, code, data, rom, share, and debug.  You can set the contents flag for a section which does not have contents, but it is  not  meaningful
           to  clear the contents flag of a section which does have contents--just remove the section instead.  Not all flags are meaningful for all object file for?
           mats.

[pixeldoc2000]

From the objcopy man page:

       --set-section-flags section=flags
           Set  the  flags  for  the  named  section.  The flags argument is a comma separated string of flag names.  The recognized names are alloc, contents, load,
           noload, readonly, code, data, rom, share, and debug.  You can set the contents flag for a section which does not have contents, but it is  not  meaningful
           to  clear the contents flag of a section which does have contents--just remove the section instead.  Not all flags are meaningful for all object file for?
           mats.

Thanks, it was just to late yesterday... should have look after that myself...

disassemble.pl :

Code: [Select]

print "create elf file\n";
`$objcopy --change-addresses=$offset -I binary -O elf32-littlearm -B arm $binfile $binfile.elf`;
`$objcopy --set-section-flags .data=content,alloc,load,code $binfile.elf`;
worked correctly! now i can load symbol-file without error into gdb!

"arm-elf-objdump -x dump.bin.elf" output:

Code: [Select]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         0036a640  ff810000  ff810000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, CODE
SYMBOL TABLE:
ff810000 l    d  .data 00000000
ff810000 g       .data 00000000 _binary_dump_bin_start
ffb7a640 g       .data 00000000 _binary_dump_bin_end
0036a640 g       *ABS* 00000000 _binary_dump_bin_size
looks good!

Now i must deal with gdb...
Thanks!

[chr]

@pixeldoc How is it going with gdb?

Meanwhile I hacked a new way to create an elf file with symbols from the sub files!

Here we go:

stubs_2_elf.S

Code: C

1. .text
2. .org 0
3. .align 2
4. .globl _start
5.  
6. // stubs_2_elf.S
7. // (c) 2008 chr
8. // GPL v3+
9. // create elf file from a binary blob
10. // and mix with symbols from stubs files
11.  
12. // compile with:
13. // arm-linux-gnu-gcc -Wl,-N,-Ttext,0xff810000 -nostdlib stubs_2_elf.S -o rom.elf
14.  
15.  
16. // cheat around gdb ignoring absolute symbols
17. here = .
18. #define offs 0xff810000
19. #define NSTUB(name, addr) name = here + addr - offs
20. #define NHSTUB NSTUB
21. #define __STUBS_ASM__H__
22. #include "stubs_entry.S"
23. #include "stubs_entry_2.S"
24.  
25.  
26. // test test ...
27. NSTUB(Jump, 0xff81000c)
28. NSTUB(Whatever, 0xff810164)
29.  
30. // include rom dump
31. _start:
32. .text
33.  
34. blob_start:
35. .incbin "PRIMARY.BIN"
36. blob_end:
37.  

usage:
* put this file in the platform/camera/firmware directory, where are the sub_entry*.S files are
* edit stubs_asm.h, put this lines at the top:

Code: [Select]

#ifndef __STUBS_ASM__H__
#define __STUBS_ASM__H__
and this at the end

Code: [Select]

#endif
* change 0xff810000to the rom start address
* I presume, PRIMARY.BIN is the camera's rom dump or a link to it
* Compile and link with:
arm-linux-gnu-gcc -Wl,-N,-Ttext,0xff810000 -nostdlib stubs_2_elf.S -o rom.elf

Now an objdump -d looks like his:

Code: ASM

1. Disassembly of section .text:
2.  
3. ff810000 <_start>:
4. ff810000:   ea000001    b   ff81000c <Jump>
5. ff810004:   6e6f6167    powvsez f6, f7, f7
6. ff810008:   796f7369    stmvcdb pc!, {r0, r3, r5, r6, r8, r9, ip, sp, lr}^
7.  
8. ff81000c <Jump>:
9. ff81000c:   e59f1150    ldr r1, [pc, #336]  ; ff810164 <Whatever>
10. ff810010:   e3a00000    mov r0, #0  ; 0x0
11. ff810014:   e5810000    str r0, [r1]
12. ff810018:   e3a01078    mov r1, #120    ; 0x78
13. ff81001c:   ee011f10    mcr 15, 0, r1, cr1, cr0, {0}
14. ff810020:   e3a01000    mov r1, #0  ; 0x0
15. ff810024:   ee071f9a    mcr 15, 0, r1, cr7, cr10, {4}
16.  

However, my disassemble.pl script makes a better output, also we don't have string references.
But this is file is cool stuff for the gdb/qemu stuff!

Apropos mcr/mrc ... I also found out, why qemu becomes crasy on some of these: there's no TCM support, yet
A basic support for the LED's was quite easy, let's see what we can do for the missing arm coprocessor stuff.

--
edit: usage

[brake]

I'm not really sure whether it will help anyone bar myself, but I was able to find the same Encoder function (and DiskBoot function) in the firmware from the ixus90is camera that I recently dumped. It's exactly the same as the one from the ixus860is_dump.

I was able to use qemu as you described in your 2nd post in this thread after I found the correct location of this function in the firmware (start *0xff866ad4 and end *0xff866b94 | cf. 0xff865008 0xff8650c8 from the ixus860is) to encode/decode stuff.

Kinda neat.

[Jar]

I'm trying to use qemu+gdb for decoding/encoding (with 860IS firmware) and I get "Value being assigned to is no longer active." from gdb. I found out this happens on assignments, i.e. x $r0=$r1. I googled the error message, found some emails at a mailing list about the same problem, but still no solution. Any ideas?

[MrSpoon]

I too had this problem and from random googling it seems to be some general GDB issue with stack frames. I resolved it by letting gdb run the firmware (skipping the instruction(s) that cause it to hang) until it gets to the delay loop and *then* defining things. Im not too knowledgable on the matter but I think you need to get into a call and have something on the stack before GDB behaves...

Hope that helps

[fudgey]

I seem to have a problem with arm-elf-objdump (and consequently with disassemble.pl) for some firmwares. I kind of solved it, but I have no idea why this happens...

I have binutils-2.18.tar.gz gcc-3.4.6.tar.bz2 gdb-6.8.tar.gz set up on 64-bit Ubuntu Hardy.

arm-elf-objcopy --change-addresses=0xFFC00000 -I binary -O elf32-littlearm -B arm PRIMARY.BIN primary.elf
arm-elf-objcopy --set-section-flags .data=code primary.elf
arm-elf-objdump -d primary.elf |head

Now, for a530 100a dump this gives me:

Code: [Select]

primary.elf:     file format elf32-littlearm

Disassembly of section .data:

ffc00000 <_binary_PRIMARY_BIN_start>:
   0:   e3a00002        mov     r0, #2  ; 0x2
   4:   ea000012        b       ffc00054 <_binary_PRIMARY_BIN_start+0x54>
   8:   79706f43        ldmdbvc r0!, {r0, r1, r6, r8, r9, sl, fp, sp, lr}^
   c:   68676972        stmdavs r7!, {r1, r4, r5, r6, r8, fp, s

and for a570is 100e:

Code: [Select]

primary.elf:     file format elf32-littlearm

Disassembly of section .data:

ffc00000 <_binary_PRIMARY_BIN_start>:
ffc00000: e3a00002 mov r0, #2 ; 0x2
ffc00004: ea000012 b ffc00054 <_binary_PRIMARY_BIN_start+0x54>
ffc00008: 79706f43 ldmdbvc r0!, {r0, r1, r6, r8, r9, sl, fp, sp, lr}^
ffc0000c: 68676972 stmdavs r7!, {r1, r4, r5, r6, r8, fp, sp, lr}^

So, for a570is I get nice row numbers with the offset that I wanted, and for a530 I just get a label in the start of the disassembly file, and row numbers start from 0.

Both dumps start with the same ARM copyright message at offset 8 (0xffc00008 in the camera). I noticed that the dumps were almost the same size. The a530 dump file size is 4194304 while the a570 one is 4194303. That last byte is 0xFF (both dumps end with a bunch of those). The a530 dump size divides with our word length 4 and the a570 dump of course doesn't.

The funny thing is, if I remove that one last byte from the a530 dump, it works like a charm! Have I encountered a bug or are we just not using these tools properly?

[chr]

The funny thing is, if I remove that one last byte from the a530 dump, it works like a charm! Have I encountered a bug or are we just not using these tools properly?

Meep! U found a bug.

integer overflow

I felt too lazy to fix that, sorry ....  yes, that already happened to me too, while feeding a complete rom dump.

ps: the trick question is:

0xffffffff + 1 = ?

edit:

I have binutils-2.18.tar.gz gcc-3.4.6.tar.bz2 gdb-6.8.tar.gz set up on 64-bit Ubuntu Hardy. 

[fudgey]

Ahhhhhhhhh should've noticed that

But this isn't really a bug is it? I mean, your script doesn't have anything to do with this really does it? If I'm not mistaken, this is objdump cleverly not taking dangerously stupid orders for renumbering . Of course the script could warn about a dump too big compared to ROMBASEADDR or even stop generating things at 0xFFFFFFFF.

I'm just going to clean up my dumps I think...

[chr]

new version:

GPL:disassemble.pl - CHDK Wiki

 

[fudgey]

disassemble_with_stubs_funcs-v1.0.sh

Attached is a batch mode (or single mode if you wish) bash shell script which pretty much automatically does a number of things for one or more firmware dumps:

1) If functions.txt files (function list exported from IDA) are available, it processes them into stub files so that they can be included in the disassemblies (PhyrePhoX did the hard work for us with IDA for cameras which have already been ported, see http://chdk.setepontos.com/index.php/topic,288.msg27742.html#msg27742).

2) Truncates oversized dumps (but doesn't check for validity otherwise!).

3) Gets ROMBASEADDR from makefile.inc and stubs from several stub files (see script for more info), disassembles
and adds strings and stubs using Chr's disassembly tools disassemble.pl (v0.2) and stubs2dis.pl (http://chdk.wikia.com/wiki/GPL_Tools).

It appears to run fine on Ubuntu 8.10 but some of it is quite horrible use of shell tools and I find it likely that parts of it will fail to work on some other operating systems... but this one suits me for now, feel free to improve/rewrite it.

[foofighter69]

Trying QEmu in windows:

Code: [Select]

c:\qemu-0.9.1-windows\bin>qemu-system-arm.exe  -kernel PRIMARY_A470-102c.bin
qemu: fatal: Unimplemented cp15 register write (c5, c0, {0, 2})

R00=03333330 R01=00000000 R02=00000100 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00010078
PSR=400001d3 -Z-- A svc32
s00=00000000(       0) s01=00000000(       0) d00=0000000000000000(       0)
s02=00000000(       0) s03=00000000(       0) d01=0000000000000000(       0)
s04=00000000(       0) s05=00000000(       0) d02=0000000000000000(       0)
s06=00000000(       0) s07=00000000(       0) d03=0000000000000000(       0)
s08=00000000(       0) s09=00000000(       0) d04=0000000000000000(       0)
s10=00000000(       0) s11=00000000(       0) d05=0000000000000000(       0)
s12=00000000(       0) s13=00000000(       0) d06=0000000000000000(       0)
s14=00000000(       0) s15=00000000(       0) d07=0000000000000000(       0)
s16=00000000(       0) s17=00000000(       0) d08=0000000000000000(       0)
s18=00000000(       0) s19=00000000(       0) d09=0000000000000000(       0)
s20=00000000(       0) s21=00000000(       0) d10=0000000000000000(       0)
s22=00000000(       0) s23=00000000(       0) d11=0000000000000000(       0)
s24=00000000(       0) s25=00000000(       0) d12=0000000000000000(       0)
s26=00000000(       0) s27=00000000(       0) d13=0000000000000000(       0)
s28=00000000(       0) s29=00000000(       0) d14=0000000000000000(       0)
s30=00000000(       0) s31=00000000(       0) d15=0000000000000000(       0)
FPSCR: 00000000

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Of course without success...

[MrSpoon]

Qemu doesn't emulate all the instructions so you have to jump past any that crash it. Alternatively you could edit them out of the ROM you're emulating.

chr put up some info on the wiki.

[lorenzo353]

hi,

is there a working 'ixus' patch against qemu 0.11 ?

this one http://chdk.setepontos.com/index.php/topic,1918.msg17500.html#msg17500
is not working

[root@t qemu-0.11.0]# patch -p1 <../qemu.ixus.patch
patching file Makefile.target
Hunk #1 FAILED at 498.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.target.rej
patching file hw/boards.h
Hunk #1 FAILED at 82.
1 out of 1 hunk FAILED -- saving rejects to file hw/boards.h.rej
patching file hw/ixus.c
patching file vl.c
Hunk #1 FAILED at 7912.
1 out of 1 hunk FAILED -- saving rejects to file vl.c.rej

thank you

[hudson]

is there a working 'ixus' patch against qemu 0.11 ?

I've written a patch for qemu-0.11 as part of the Magic Lantern project.  You can download the patch from: bitbucket.org - magiclantern/patches/qemu-0.11.patch

It no longer emulates the ixus, even though I haven't renamed the architecture.  The memory layout and console device are for the 7D and 5D Mark II.