ELPH 340 (IXUS 265) - page 4 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 ... 18   Go Down

ELPH 340 (IXUS 265)

  • 174 Replies
  • 73534 Views
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: ELPH 340 (IXUS 265)
« Reply #30 on: 16 / July / 2014, 01:04:07 »
Advertisements
Quote from: Hardware_Hacker on 16 / July / 2014, 00:49:59
Quote from: srsa_4c on 15 / July / 2014, 18:51:27
Quote from: Hardware_Hacker on 15 / July / 2014, 17:45:45
So # Which is the correct version that I should continue with.
Quote
# Is the backward reference important.
0xff020000 is the start of the main firmware. All the ROM addresses you'll encounter during porting are above 0xff020000.

See the Attached ..... BackwardReference.png

H-H

Not a ROM address - that's an absolute value used to program the ARM control registers (memory region if memory serves).

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline Hardware_Hacker

  • ****
  • 322
Re: ELPH 340 (IXUS 265)
« Reply #31 on: 16 / July / 2014, 01:36:06 »
Quote from: Hardware_Hacker on 15 / July / 2014, 17:45:45
Quote from: srsa_4c on 11 / July / 2014, 18:55:01
A partial boot.c is attached. It was done with CHDK-PT, loosely following the sx510 port. The functions are copied straight from CHDK-PT, indentation and comments show where the changes and additions are. I hope it's enough for a "hint".

DumpF is the only version of the three that aligns correctly with your boot.c
DumpF also aligns correctly with the new ELPH 340 Dump.

So

# Which is the correct version that I should continue with.

H-H

Attached DumpF.png

H-H
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH 340 (IXUS 265)
« Reply #32 on: 16 / July / 2014, 17:17:28 »
Quote from: Hardware_Hacker on 16 / July / 2014, 01:36:06
Attached DumpF.png
You can enter the correct start address in ARMu if you switch to "Segment" view and unlock the view with the padlock button (rightmost button).
Logged
*

Offline Hardware_Hacker

  • ****
  • 322
Re: ELPH 340 (IXUS 265)
« Reply #33 on: 16 / July / 2014, 17:29:01 »
Quote from: srsa_4c on 16 / July / 2014, 17:17:28
Quote from: Hardware_Hacker on 16 / July / 2014, 01:36:06
Attached DumpF.png
You can enter the correct start address in ARMu if you switch to "Segment" view and unlock the view with the padlock button (rightmost button).

Thanks I will try again, and continue with the Elph 340 Dump

Should the Dumper code also be Patched, to avoid these issues.

~~~~Using DumpF~~~~

Also most of the offsets I original found were correct but 10000h to low.
there also were some typos and some assorted other differences.

H-H
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH 340 (IXUS 265)
« Reply #34 on: 16 / July / 2014, 18:21:12 »
Quote from: Hardware_Hacker on 16 / July / 2014, 17:29:01
Should the Dumper code also be Patched, to avoid these issues.
If you mean the Canon Basic dumper, it's working as it should.

I have uploaded annotated disassemblies (firmware from 0xff020000 and the kernel in RAM from 0x6b1000): http://filebin.net/1hrve32msl .
Logged
*

Offline MarkR

  • *
  • 5
Re: ELPH 340 (IXUS 265)
« Reply #35 on: 20 / October / 2014, 10:52:42 »
Hi Guys,
I am just about to buy the Ixus 265
I am watching this thread with interest. If there is anything I can do to help testing wise let me know :)
Logged
*

Offline mkjo

  • *
  • 2
ELPH 340 (IXUS 265)
« Reply #36 on: 04 / November / 2014, 12:58:21 »
Hi together,

i tried to port CHDK to the ixus265 also, but I'm stucked a little bit.
I'm new to CHDK, but I should have some experience in embedded development, so the CHDK build process is not really a problem for me.
I was able to extract the ROM and include it into a copy of the SX510,
Also I add some additional stubs for the first step, and I adjusted some stuff like "dancing bits" numbers in various makefiles, etc.
For the first test, I enabled the assembler LED blinking sequence in the entry.S file.
If I write this to the card, the camera does not boot nor blink. Also the power switch does not work, I need to remove the battery to get the camera working again. So something happened, but now I am not sure what happened:
Did the boot process hung up
Do I have just a wrong LED address, and I am blinking "nothing"?

How can I find out the LED's address? Though my camera is a DIGIC 4+ or so, I have seen that most LED addresses in other camera firmwares are the same.
How can I find out the LED addresses, are they somewhere in the ROM dump and I can find them by some signature?

Thanks for any help.
(Btw, If requested, I can upload my stuff somewhere)
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH 340 (IXUS 265)
« Reply #37 on: 04 / November / 2014, 17:48:42 »
Quote from: mkjo on 04 / November / 2014, 12:58:21
For the first test, I enabled the assembler LED blinking sequence in the entry.S file.
If I write this to the card, the camera does not boot nor blink. Also the power switch does not work, I need to remove the battery to get the camera working again. So something happened, but now I am not sure what happened:
Did the boot process hung up
Do I have just a wrong LED address, and I am blinking "nothing"?
Since the power switch stops reacting, my guess is that the camera locks up. Writing to wrong GPIOs usually won't freeze the camera (unless the used MMIO range is not implemented in DIGIC 4+).

Quote
How can I find out the LED's address? Though my camera is a DIGIC 4+ or so, I have seen that most LED addresses in other camera firmwares are the same.
How can I find out the LED addresses, are they somewhere in the ROM dump and I can find them by some signature?
You should search around the task named "LEDCon". The routine that starts the LEDCon task (0xff06dab8 in 100a) also initializes the table of LEDs (not the hardware, the task keeps state information in that table). Unfortunately, this routine has changed again, so the sigfinder can't identify the LEDs. The LEDs are most likely referred to as indexes of a GPIO table. I'll try to locate that table...
Quote
(Btw, If requested, I can upload my stuff somewhere)
Yes, please.

edit:
LEDCon uses sub_ff19bf40 to switch an LED on, sub_ff19bf68 to switch it off. The "poke_GPIO" function is sub_ff06be60, the GPIO table starts at 0xff5f8314. Note that you need to use 0x93d800 and 0x83dc00 to switch the LED on/off. All ROM addresses are from the 100a fw.

edit2:
removed wrong information from the above
« Last Edit: 24 / December / 2014, 17:41:35 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH 340 (IXUS 265)
« Reply #38 on: 05 / November / 2014, 12:50:13 »
There's another (safer) method described here, one could use the LEDDrive event procedure on a known LED and dump the MMIO range 0xc022d000 ... 0xc022d204 to a file 1) when the LED is off 2) when the LED is on. The 2 dumps can be later compared for differences.
Logged
*

Offline mkjo

  • *
  • 2
Re: ELPH 340 (IXUS 265)
« Reply #39 on: 11 / November / 2014, 12:44:44 »
Quote from: srsa_4c on 05 / November / 2014, 12:50:13
There's another (safer) method described here, one could use the LEDDrive event procedure on a known LED and dump the MMIO range 0xc022d000 ... 0xc022d204 to a file 1) when the LED is off 2) when the LED is on. The 2 dumps can be later compared for differences.

Hi, I was able to extract the LED addresss, I see something changing from 0x08 to 0x09 at 0xC022D1FC (green) and 0xC022D200 (AF).

I put these addresses in the boot assembler (entry.s), but I still do not see a reaction.
I think my DISKBOOT.BIN is not recognized as a valid image? If I present a diskboot.bin with just 0x00 inside, The camera will hang also.
Obviously I do something wrong with some very basic settings.
Up to now i just set up some stuff in my diskboot.bin and added some stubs.
How can I verify those very basic settings? Yet I do not understand several stuff like PLATFORMID. I hope I set them right, but I'm not sure.
Here's my makefile.inc

PLATFORMID=12937
PLATFORMOS=dryos
PLATFORMOSVER=54

ROMBASEADDR=0xff010000

# TODO
# Set up size variables for EXMEM
#EXMEM_HEAP_SKIP=0xFD200   #(0x44000000-0x43F02E00) from sub_FF86CAA8 = size of video buffers in EXMEM area (?)
#EXMEM_BUFFER_SIZE=0x300000   # Amount of EXMEM memory to allocate for CHDK = 3MB

MAXRAMADDR=0x07ffffff # 128 MB

# TODO d10 c&p
#ifdef OPT_CHDK_IN_EXMEM
#MEMISOSTART=0x3C02DE0      # MAXRAMADDR+1 - EXMEM_HEAP_SKIP - EXMEM_BUFFER_SIZE - 32 (exmem allocates 64 bytes extra, 32 before and 32 after block allocated)
#else
MEMISOSTART=0x002bebfc
#endif

# type of diskboot encoding
NEED_ENCODED_DISKBOOT=12
# type of FI2 encoding
KEYSYS=d4e

do you see anything which might be wrong?
Logged
Pages: 1 2 3 [4] 5 6 7 8 9 ... 18   Go Up
« previous next »
 

Related Topics