A problem of dumping firmwave A480.

reyalp

13717

Re: A problem of dumping firmwave A480.

« Reply #10 on: 08 / May / 2009, 01:46:23 »

Advertisements

The udumper source is not part of the main CHDK tree. ISTR it is included with cardtricks.

Try a proxy or tor for wikia. http://proxify.com/ works well enough, if you can get to that

Logged

Don't forget what the H stands for.

psjatqpgf

Re: A problem of dumping firmwave A480.

« Reply #11 on: 18 / May / 2009, 10:54:38 »

i got the src of udumper ,but i don not know where should i tweak...

if the Firmware of new cam changed,what MIN_ADDRESS and other Parameters should be?

Logged

reyalp

13717

Re: A problem of dumping firmwave A480.

« Reply #12 on: 22 / May / 2009, 19:01:55 »

Quote from: psjatqpgf on 18 / May / 2009, 10:54:38

i got the src of udumper ,but i don not know where should i tweak...

if the Firmware of new cam changed,what MIN_ADDRESS and other Parameters should be?

If we knew, it would be dumped already. I wrote some suggestions in this post:
http://chdk.setepontos.com/index.php/topic,2766.msg34124.html#msg34124

Logged

Don't forget what the H stands for.

frezik

Re: A problem of dumping firmwave A480.

« Reply #13 on: 07 / July / 2009, 13:39:13 »

I just got an A480 and am anxious to try CHDK on it. Doesn't look like there's been any progress on dumping the firmware since the last post above. I'm willing to make a go at it.

Looking over the A2000 thread reyalp posted above, I think my first order of business is to get a custom build of udumper going and to start trying to find how to activate the LED for debugging, or possibly doing a blinking dump. I'm most of the way through making the build environment for udumper. Any hints on how I should go about finding the LED control?

Logged

frezik

Re: A problem of dumping firmwave A480.

« Reply #14 on: 07 / July / 2009, 18:14:50 »

Have my dev environment done on Linux.

Build for custom udumper (adapted from included dryos.bat):

Code: [Select]

#!/bin/sh

rm -f diskboot.bin
rm -f main.exec
rm -f main.o
rm -f entry.o

arm-elf-gcc -fno-builtin -O2 -Ilib -nostdinc -c entry.s
arm-elf-gcc -fno-builtin -O1 -Ilib -c -DDRYOS main.c
arm-elf-gcc -fno-builtin -O2 -Ilib -nostdlib -Wl,-N,-Ttext,1900 -o main.exec entry.o main.o  -lgcc

arm-elf-objcopy -O binary main.exec diskboot.bin
dd if=/dev/zero bs=1k count=20 >> diskboot.bin

Script to make a bootable SD card with the diskboot.bin created by dryos.sh:

Code: [Select]

#!/bin/bash
BOOT_FILE=diskboot.bin
DEV=/dev/sdb1
MOUNT=/mnt/usb
EMPTY_IMG=../empty.dum

echo -n BOOTDISK | dd  of=${DEV} bs=8 count=1

mount ${MOUNT}
cp ${BOOT_FILE} ${MOUNT}
cp ${EMPTY_IMG} ${MOUNT}
umount ${MOUNT}

My udumper code, with LED code taken from "Grand Blinker" mentioned in Porting the CHDK, along with the LED memory locations tried so far:

Code: [Select]

#define MIN_ADDRESS     0xFFC00000
#define FW_SIZE         0x400000

#define START_SECTOR    2048

//#define LED_PR 0xC02200CC
#define LED_PR 0xC0220080
//#define LED_PR 0xC0220084


typedef int (*f_w)(int, int, int, int); // drive(?), start sector, number of sectors, address
void led_on( void );
void led_off( void );


int main() {
    int i;
    unsigned long sa;
    f_w wr;

    led_on();
    for (i=0x1900;i<0xF0000;i+=4) {
        if ((*(unsigned int*)(i+0x34)==0) &&
            (*(unsigned int*)(i+0x38)==0) &&
            (*(unsigned int*)(i+0x3C)==3) &&
            (*(unsigned int*)(i+0x4C)>MIN_ADDRESS) &&
            (*(unsigned int*)(i+0x50)>MIN_ADDRESS) ) {

            wr=(f_w)*(unsigned int*)(i+0x50);

            #if defined (DRYOS)
            // #warning DRYOS
            // jeff668: fill some memory with zeroes; "simulate" large diskboot
            // WARNING: the starting address is a guess

            for (i = 0x1c00; i<0x30000; i+=4)  *(int*)i=0;

            #elif defined (VXWORKS)
            // #warning VXWORKS
            #else
            #error OS type must be defined
            #endif

            sa=(unsigned long)wr>0xFFC00000 ? 0xFFC00000 : 0xFF810000;

            wr(0, START_SECTOR, FW_SIZE/512, sa);
        }
    }

    while(1);
    return 0;
}


void led_on()
{
    volatile long *p=(void*)LED_PR;
    *p=0x46;
}

void led_off()
{
    volatile long *p=(void*)LED_PR;
    *p=0x44;
}

Procedure:

1. Run "./dryos.sh && ./make_boot.sh"
2. Lock card, put in camera
3. Turn on camera in review mode
4. Wait a minute
5. Turn off camera, put card back in computer, check empty.dum

So far, empty.dum has remained empty, and no LEDs have lit up.

Could I try a program that iterates, say, 0xC0000000 through 0xCFFFFFFF to see if any of them turn the LED on (Edit: and then binary searching the space from there)? Is there a good chance of bricking my camera doing that?

« Last Edit: 07 / July / 2009, 18:18:25 by frezik »

Logged

reyalp

13717

Re: A problem of dumping firmwave A480.

« Reply #15 on: 07 / July / 2009, 20:15:50 »

Quote from: frezik on 07 / July / 2009, 18:14:50

Could I try a program that iterates, say, 0xC0000000 through 0xCFFFFFFF to see if any of them turn the LED on (Edit: and then binary searching the space from there)? Is there a good chance of bricking my camera doing that?

If you look at the existing ports, there is a pretty small range of addresses used for LEDs. I'd suggest trying in that range, starting with the ones of the most similar cams (probably a470). This will cut down your search space and risk quite a lot.

Writing to random MMIO addresses does probably have some small risk of bricking your cam, but no one has managed to do that yet.

If you want to make sure you build process is set up right, I'd suggest building from an existing port with a modified loader, like I did.

Since the newer cameras seem to have trouble with diskboot (even after we found the LED address, we weren't able to get diskboot to blink it) you probably need to make a FI2 file. You'll need to set the platform ID correctly for your camera (get it from the vers.req info), and also to extract the keys from the dump. The FI2 thread has information on how to get the keys. See http://chdk.setepontos.com/index.php/topic,2995.0.html

If you do want to try diskboot, it almost certainly has to be the "new" encoded kind, not just a straight copy of the .bin.

Logged

Don't forget what the H stands for.

bugsplatter

Re: A problem of dumping firmwave A480.

« Reply #16 on: 07 / July / 2009, 20:21:48 »

Quote from: frezik on 07 / July / 2009, 18:14:50

Have my dev environment done on Linux.

I got Win7rc + Slackware here

Quote

So far, empty.dum has remained empty, and no LEDs have lit up.

There's a misunderstanding or boo-boo in the documentation, to make a bootable SD card you dont write BOOTDISK to MBR @ 0x40, rather you write to the first partition @ 0x40, like this:
root@deltree:~# printf "BOOTDISK\000" > bootdisk root@deltree:~# dd if=bootdisk bs=1 count=9 seek=64 of=/dev/sdb1 9+0 records in 9+0 records out 9 bytes (9 B) copied, 0.0198781 seconds, 0.5 kB/s
I've also observed using cardtricks-144 on Win7rc trashes the SD card and may crash cam, but cardtricks-144 works fine from WinXP, which is how I got a bootable SD then I found the BOOTDISK string in partition 1 instead of the MBR

Logged

whim

2042
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: A problem of dumping firmwave A480.

« Reply #17 on: 08 / July / 2009, 05:38:32 »

@bugsplatter

Quote

I've also observed using cardtricks-144 on Win7rc trashes the SD card ...

interesting ... but I hope you're not seriously suggesting I should add support for any MS OS before they released at least 1 service pack for it

BTW: did you try CT on Win7 in native or in virtual XP mode (i mean the one that's supposed to be included in Win7) ?

Quote

... and may crash cam

how so ? if the card is trashed, i would imagine the cam will just prompt you to format it

cheers,

wim

« Last Edit: 08 / July / 2009, 06:15:14 by whim »

Logged

*Wikia FAQ *GCC Compiler Shell for Windows

bugsplatter

Re: A problem of dumping firmwave A480.

« Reply #18 on: 08 / July / 2009, 06:14:40 »

Quote from: whim on 08 / July / 2009, 05:38:32

@bugsplatter

Quote
I've also observed using cardtricks-144 on Win7rc trashes the SD card ...
interesting ... but I hope you're not seriously suggesting I should support an
MS OS before they released at least 1 service pack for it
BTW: did you try CT on Win7 in native or in virtual XP mode (i mean the one that's supposed to be included in Win7) ?

Nah, just an observation

No, I've not looked for nor played with that virtual XP mode, I have vmware for a 'proper' VM -- I use windows now as desktop for localnet system, any development, web pages and stuff is done on one of the slackware boxes. I do have a WinXP SP3 box here too, was running that via remote terminal on the other screen today.

Edit: I do write ubasic with notepad++ on windoze, 'cos it's quicker to rewrite the SD card file.

Quote

Quote
... and may crash cam
how so ? if the card is trashed, i would imagine the cam will just prompt you to format it

It's worse, cam refused to turn on with that card, it was toxic! Plug in another card and cam turned on, linux wouldn't mount it either, for a while I thought I'd killed the little thing.

I ended up zeroing the card (only a 32MB) with linux dd, format in camera, then start over. CardTricks doesn't properly format a blank SD card, I've seen it make a superfloppy (no MBR), again on win7 (might have been win7beta). So I use the 'SD Formatter' reference software or the cam to format a zeroed card.

This also explains why I had trouble recently getting a dump -- though CardTricks-141 did produce a working dumper from Win7 after I made the dump file 24MB of zeroes, didn't check what was going on closely once I had the firmware dump.

Cheers,
Grant.

« Last Edit: 08 / July / 2009, 06:34:21 by bugsplatter »

Logged

whim

2042
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: A problem of dumping firmwave A480.

« Reply #19 on: 08 / July / 2009, 06:37:25 »

Quote

CardTricks doesn't properly format a blank SD card, I've seen it make a superfloppy (no MBR), again on win7 (might have been win7beta)

That's interesting, considering CT only uses windows' format.exe to do the job:
"format X: /FS:FAT /V:CANON_DC /X"
They must have changed the way format works then, i guess ...

thanks for the info,

wim

Logged

*Wikia FAQ *GCC Compiler Shell for Windows