IXUS 130 (SD1400 IS) Porting Thread - page 4 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 ... 29   Go Down

IXUS 130 (SD1400 IS) Porting Thread

  • 288 Replies
  • 130726 Views
*

Offline reyalp

  • ******
  • 14080
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #30 on: 16 / September / 2010, 16:37:16 »
Advertisements
Quote from: emlyn on 16 / September / 2010, 13:36:42
So if it executes the "ldr    r0, =0xffbf837c" from boot.c it fails, but if it executes it from the original fw it continues. How could it make any difference? Could it be a corrupted dump?
Unlikely. This was dumped with the cbasic dumper, right ? Blinking can give you a corrupt dump, but I'd be very surprised if the cbasic one did... it uses normal canon IO functions without any dirty tricks. I guess a bad SD card could do it, but that's stretching. I've seen the original udumper give incomplete dumps (zeros after certain point far into the dump), but never bad data.

The 100c dump looks OK to me.
Quote
Or something to do with endianness (I read that ARM can use either big or little endian)?
Unlikely, chances are you wouldn't get this far if you messed this up, and you would have to do something very weird.

I'm not clear this is actually the point where you are running into the problem, because in your earlier posts it sounded like you got as far as sub_FF813404. I've certainly had cases where my test code caused a crash, leading me to think I'd found the source of a crash, when in fact I'd just introduced a new one...

I guess if your toolchain is messed up somehow, you could be getting the wrong thing from ldr    r0, =0xffbf837c
I really doubt this is the case (you wouldn't get this far) but you can inspect core/main.dump to verify.

The code you are looking at here is a simple loop that copies initialized data (i.e. the .data segment) from ROM to RAM. This is the equivalent of the for(i=0;i<canon_data_len/4;i++)... loop you posted earlier. If the source, destination or size were wrong, that could cause problems, but otherwise there's very little that could fail.

Note, you only need one or the other: either copy everything from FF81000C to FF810160 to inline ASM or use the for loops and inline ASM to turn on the caches.

Logged
Don't forget what the H stands for.
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #31 on: 16 / September / 2010, 18:00:00 »
Quote from: reyalp on 16 / September / 2010, 16:37:16
This was dumped with the cbasic dumper, right ?
Yes that's right

Quote
Quote
Or something to do with endianness (I read that ARM can use either big or little endian)?
Unlikely, chances are you wouldn't get this far if you messed this up, and you would have to do something very weird.
I thought so, but I was running out of ideas...

Quote
I'm not clear this is actually the point where you are running into the problem, because in your earlier posts it sounded like you got as far as sub_FF813404. I've certainly had cases where my test code caused a crash, leading me to think I'd found the source of a crash, when in fact I'd just introduced a new one...
With the C version it did get further. I replaced it with the ASM copy from the dump, as I though that maybe it was crashing because something was missing from the C version.
At the moment it is all a bit confusing, I'll keep on investigating, hopefully I'll be able to make some sense of it soon.
Logged
*

Offline oskretc

  • *
  • 3
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #32 on: 20 / September / 2010, 06:52:11 »
I just bought this camera to complement my dslr also

I have some experience with embedded programming, and hardware. but no experience with chdk porting process

I can help to do some testing if you need.
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #33 on: 21 / September / 2010, 07:44:46 »
Quote from: oskretc on 20 / September / 2010, 06:52:11
I can help to do some testing if you need.

I'm not yet at the stage where I have something to test, I'll keep the forum updated with any progress, but be aware it will be slow as I don't have a lot of time for this.
If you (or anyone else) want to help with the porting, you are welcome to have a go :-) just let me know and I'll send you what I have so far, or wait a bit and I should have it up on github soon. Don't worry that you have no experience porting chdk, I don't either, there is some useful info on the wiki and people on the forum are very helpful.
Logged
*

Offline oskretc

  • *
  • 3
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #34 on: 21 / September / 2010, 08:59:08 »
Quote from: emlyn on 21 / September / 2010, 07:44:46
Quote from: oskretc on 20 / September / 2010, 06:52:11
I can help to do some testing if you need.

I'm not yet at the stage where I have something to test, I'll keep the forum updated with any progress, but be aware it will be slow as I don't have a lot of time for this.
If you (or anyone else) want to help with the porting, you are welcome to have a go :-) just let me know and I'll send you what I have so far, or wait a bit and I should have it up on github soon. Don't worry that you have no experience porting chdk, I don't either, there is some useful info on the wiki and people on the forum are very helpful.

Yeah that will be fun...
So far I have installed IDA Pro disassembled the FW and running the idc scripts... should start looking for something special?
Logged
*

Offline reyalp

  • ******
  • 14080
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #35 on: 21 / September / 2010, 12:48:25 »
Quote from: oskretc on 21 / September / 2010, 08:59:08
Yeah that will be fun...
So far I have installed IDA Pro disassembled the FW and running the idc scripts... should start looking for something special?
Read http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera and skim the rest of http://chdk.wikia.com/wiki/For_Developers if you haven't already.
Logged
Don't forget what the H stands for.
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #36 on: 22 / September / 2010, 04:12:36 »
You should install the arm-elf-gcc toolchain to be able to compile things for the camera. I have now put up my code on github, you can get it here: http://github.com/emlyn/chdk. I assume you have version 100c of the firmware in your camera, that is what I have, and I think it will be easier if we both have the same.

At the moment I am stuck with the boot process, there is some odd behaviour that I don't understand: I have copied the first function from the start of the firmware (at 0xff810000) into the boot function (in platform/ixus130_sd1400/sub/100c/boot.c), but when my copy runs, the camera hangs. If instead I jump to 0xff810000, the camera boots properly (from DISKBOOT.BIN it goes into a boot loop, from PS.FI2 it boots up normally).

By jumping into the original firmware from different points in my copy, I have narrowed it down to one instruction that seems to cause the problem ("ldr    r0, =0xffbf837c", at 0xff810130 in the firmware). If I jump just before this it boots properly, but just after it and the camera hangs.
This doesn't seem to make much sense, so there is probably something I have missed, but I can't find it. Maybe another pair of eyes will help spot it...

EDIT:
I just tried dumping the ROM log, but it only contained an assertion failure from August 17th (with stack dump), nothing more recent. The camera date is set correctly, so I don't think this relates to the boot process.
I tried changing the second parameter to GetLogToFile from a 1 to a 2, but it generates an identical file.

EDIT2:
I tried building it on my Linux VM, in case the problem was caused by the toolchain, but the camera still hangs when I jump into the original firmware just after the offending ldr instruction. So it looks like it's probably not the build tools, unless I have the same problem with both...
« Last Edit: 22 / September / 2010, 17:28:33 by emlyn »
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #37 on: 24 / September / 2010, 04:38:53 »
I haven't done much more testing, but I've thought a bit about the problem: it cannot be with the ldr instruction, there is no way that itself could cause the problem. It must be to do with the address of that instruction - either it gets overwritten by something, or not enough gets copied in the first place.

One other thing I am not sure about: the CHDK code gets copied from one address to another - does the compiler already compile it for the destination address, or is it position independent and this does not matter? I just thought if there is a mismatch somewhere between the addresses and the code is position dependent, this could also cause the problem.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #38 on: 24 / September / 2010, 12:34:08 »
Quote from: emlyn on 24 / September / 2010, 04:38:53
One other thing I am not sure about: the CHDK code gets copied from one address to another - does the compiler already compile it for the destination address, or is it position independent and this does not matter? I just thought if there is a mismatch somewhere between the addresses and the code is position dependent, this could also cause the problem.
Everything is compiled at a fixed location, as determined by the various MEM* values in makefile.inc

If you have MEMISOSTART wrong, that loop could copy over the CHDK code. The correct value of MEMISOSTART comes from the second loop in that chunk of code.
Logged
Don't forget what the H stands for.
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #39 on: 12 / October / 2010, 10:24:35 »
OK, I've finally been able to have another look at this, and I am still unable to get it booting properly, and still as confused as ever...
I checked and rechecked MEMISOSTART, MEMBASEADDR etc, and it all looks OK to me.
It still crashes somewhere in the original firmware unless I jump into it early enough.
I have flashed out the ram around the problem area to check that it was copied correctly and not overwritten, and it all matches what is in core/main.dump.

So now I have this that boots normally:
Code: [Select]
void boot() {
  (code to enable caches)
  (code copied from dump, up to 0xff81012c)
  "b sub_ff810130\n" (or "ldr pc, =0xff810130\n")
  "ldr r0, =0xffbf837c\n" (from dump 0xff810130)
  (more irrelevant code)
}

or the following that crashes:
Code: [Select]
void boot() {
  (code to enable caches)
  (code copied from dump, up to 0xff81012c)
  "ldr r0, =0xffbf837c\n" (from dump 0xff810130)
  "b sub_ff810134\n" (or "ldr pc, =0xff810134\n")
  (more irrelevant code)
}

I really don't understand how this can be happening, if the first one boots properly, how can the second one not? I am sure there must be something stupid I am overlooking, but I can't figure out what it could be.
I am not sure what to look at next, the only thing I can think of is to try and run both versions in Qemu and see what the difference is, but that looks like a lot of work to set up, and I'm not sure how useful it would be.
So if anyone has any ideas what is going on or is able to look into it further I would be very grateful :)

Thanks.
« Last Edit: 12 / October / 2010, 10:26:26 by emlyn »
Logged
Pages: 1 2 3 [4] 5 6 7 8 9 ... 29   Go Up
« previous next »
 

Related Topics