Emulating Digicam with QEMU

  • 46 Replies
  • 15721 Views
*

Offline chr

  • ***
  • 138
  • IXUS 82 IS
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #30 on: 17 / August / 2008, 02:54:37 »
    Advertisements
    @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.

    *

    Offline pixeldoc2000

    • ****
    • 355
    • IXUS900Ti 1.00C, IXUS300HS 1.00D
      • pixel::doc homebase
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #31 on: 17 / August / 2008, 20:45:54 »
    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!

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #32 on: 19 / August / 2008, 06:56:47 »
    @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) [Select]
    .text
    .org 0
    .align 2
    .globl _start

    // stubs_2_elf.S
    // (c) 2008 chr
    // GPL v3+
    // create elf file from a binary blob
    // and mix with symbols from stubs files

    // compile with:
    // arm-linux-gnu-gcc -Wl,-N,-Ttext,0xff810000 -nostdlib stubs_2_elf.S -o rom.elf


    // cheat around gdb ignoring absolute symbols
    here = .
    #define offs 0xff810000
    #define NSTUB(name, addr) name = here + addr - offs
    #define NHSTUB NSTUB
    #define __STUBS_ASM__H__
    #include "stubs_entry.S"
    #include "stubs_entry_2.S"


    // test test ...
    NSTUB(Jump, 0xff81000c)
    NSTUB(Whatever, 0xff810164)

    // include rom dump
    _start:
    .text

    blob_start:
    .incbin "PRIMARY.BIN"
    blob_end:
    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) [Select]
    Disassembly of section .text:

    ff810000 <_start>:
    ff810000:   ea000001    b   ff81000c <Jump>
    ff810004:   6e6f6167    powvsez f6, f7, f7
    ff810008:   796f7369    stmvcdb pc!, {r0, r3, r5, r6, r8, r9, ip, sp, lr}^

    ff81000c <Jump>:
    ff81000c:   e59f1150    ldr r1, [pc, #336]  ; ff810164 <Whatever>
    ff810010:   e3a00000    mov r0, #0  ; 0x0
    ff810014:   e5810000    str r0, [r1]
    ff810018:   e3a01078    mov r1, #120    ; 0x78
    ff81001c:   ee011f10    mcr 15, 0, r1, cr1, cr0, {0}
    ff810020:   e3a01000    mov r1, #0  ; 0x0
    ff810024:   ee071f9a    mcr 15, 0, r1, cr7, cr10, {4}

    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
    « Last Edit: 19 / August / 2008, 08:00:21 by chr »

    *

    Offline brake

    • *
    • 23
    • IXUS90IS / SD790IS
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #33 on: 19 / August / 2008, 11:11:03 »
    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.
    « Last Edit: 21 / August / 2008, 02:06:48 by brake »


    *

    Offline Jar

    • *
    • 2
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #34 on: 21 / August / 2008, 19:49:41 »
    I'm trying to use qemu+gdb for decoding/encoding (with 860IS firmware) and I get "Value being assigned to is no longer active." :blink: 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

  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #35 on: 21 / August / 2008, 20:24:18 »
    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 ???

    *

    Offline fudgey

    • *****
    • 1705
    • a570is
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #36 on: 28 / August / 2008, 15:26:39 »
    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? :blink:

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #37 on: 28 / August / 2008, 18:23:24 »
    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? :blink:

    Meep! U found a bug.

    integer overflow

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

    ps: the trick question is:

    0xffffffff + 1 = ?

    edit:
    Quote
    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.  :haha
    « Last Edit: 28 / August / 2008, 18:26:26 by chr »


    *

    Offline fudgey

    • *****
    • 1705
    • a570is
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #38 on: 28 / August / 2008, 18:59:54 »
    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 :haha. 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...

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: Emulating Digicam with QEMU
    « Reply #39 on: 12 / October / 2008, 11:44:29 »

     

    Related Topics