chdk in the DIGIC6 world

  • 152 Replies
  • 65065 Views
*

Offline srsa_4c

  • ******
  • 3725
Re: chdk in the DIGIC6 world
« Reply #10 on: 14 / May / 2014, 18:29:37 »
Advertisements
If the cameras use opengl ES (which seems likely), it might be worth trying to use that to draw. In that case it seems like you ought to be able to make a new backend for the gui_draw* without changing the rest of the code much.
I don't know much about OpenGL and its programming, but using our own framebuffer and draw that on top of Canon's graphics would not be bad (if that's even possible). That, however, would require a bigger memory chunk and it's not yet known how much memory we'll be able to get. The malloc heap seems to be around ~2.5MB total, so it's probably out of the question (did not try to get memory information yet).
The hardware probably supports OpenGL ES 1.1 (based on strings found in ROM - the graphics core can be identified).
I have found the likely parameters of the "big" overlay buffer: some RGBA variant, 720x480 in a 960x480 buffer (this might be double buffered too). I don't yet know whether this one can be written on, but this might be the native resolution.

*

Offline reyalp

  • ******
  • 11583
Re: chdk in the DIGIC6 world
« Reply #11 on: 14 / May / 2014, 22:49:18 »
I don't know much about OpenGL and its programming, but using our own framebuffer and draw that on top of Canon's graphics would not be bad (if that's even possible).
My assumption (quite possibly incorrect) was that the normal canon UI now uses OpenGL to draw. If that is the case, it may be possible to call regular GL drawing functions to set pixels, draw lines, rectangles etc, in the same context the Canon UI uses, without worrying about frame buffers. Since OpenGL is quite well documented, getting the whole API could be relatively easy once you identified a few functions.

This is highly speculative, for initial porting brute force drawing to a framebuffer is probably going to be the better bet.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3725
Re: chdk in the DIGIC6 world
« Reply #12 on: 16 / May / 2014, 15:52:32 »
My assumption (quite possibly incorrect) was that the normal canon UI now uses OpenGL to draw.
I don't think it's an incorrect assumption. They surely don't want to low level program the GPU, and the presence of OpenGL strings suggests OpenGL libraries.
Quote
If that is the case, it may be possible to call regular GL drawing functions to set pixels, draw lines, rectangles etc, in the same context the Canon UI uses, without worrying about frame buffers. Since OpenGL is quite well documented, getting the whole API could be relatively easy once you identified a few functions.
We'll see. Unfortunately, I haven't yet been able to find references to those strings (the disassembly is not 100% correct and there are many more ways of addressing things in thumb-2...).
I think that the firmware uses pieces of "textures" to assemble the overlay (I have found a standalone histogram image in one of the RAM dumps).
It also looks like the "big" RGBA overlay isn't going to be usable for us - my changes do not necessarily end up on screen... So it currently looks like we'll have to draw on YUV :(

Attached is a small program that will display the battery voltage - in millivolts - on the sx280 102b. It's very basic and not configurable. Display is refreshed twice in every second. I'm using the non-eventproc versions of the LCDMsg event procedures.

Code: [Select]
@ compile with:
@ arm-none-eabi-gcc -Wl,-N,-Ttext,0x5ce000 -nostdlib -march=armv7 -mthumb vbatt.s -o vbatt.bin
@ and extract the needed bytes from the binary :/
@ toolchain: [url]https://launchpad.net/gcc-arm-embedded[/url]
@ 0x5ce000 is the start of AdditionAgent RAM

@ this macro is for thumb mode
.macro NHSTUB name addr
.globl _\name
.weak _\name
_\name:
ldr.w pc, [pc, #0]
.long \addr
.endm

.globl _start
.org 0
_start:
.text
@ first byte has to be non-zero (otherwise blob might be treated as encoded)
@ force thumb
.code 16
@ allow new instructions (ldr.w)
.syntax unified

push {r4,r5,lr}
sub sp, sp, #20

@ fw version check first
ldr r0, =0xfc142898
ldr r0, [r0]
ldr r1, =0x4232302e
cmp r0, r1
bne quit

mov r0, #100   @ x coordinate of the string
mov r1, #10    @ y coordinate of the string
mov r2, #0     @ start with NULL string
bl _LCDMsg_Create
mov r5, r0
again:
ldr r0, =500       @ 500msec
bl _SleepTask
bl _VBattGet
adr r1, batfrm
mov r2, r0
mov r0, sp
bl _sprintf
mov r0, r5
mov r1, sp
bic r1, #0x40000000
bl _LCDMsg_SetStr

b again
quit:
add sp, sp, #20
pop {r4,r5,pc}

batfrm:
.asciz "%d mV"
.ltorg

@ sx280 102b
@ ".02b" aka 0x4232302e, significant part of version string, 0xfc142898

NHSTUB SleepTask 0xfc251cb4
NHSTUB ExitTask 0xfc2512b0
NHSTUB sprintf 0xfc2b7f81
NHSTUB LCDMsg_Create 0xfc42ef6d
NHSTUB LCDMsg_Delete 0xfc42ee09
NHSTUB LCDMsg_SwDisp 0xfc42f065
NHSTUB LCDMsg_Move 0xfc42ed93
NHSTUB LCDMsg_SetStr 0xfc42f0af
NHSTUB LCDMsg_ChangeColor 0xfc42f20d
NHSTUB VBattGet 0xfc12ec71
To use it, set up the card to run scripts, copy the 2 files from the zip to the root of the card. Start the cam in play mode and press SET.

*

Offline srsa_4c

  • ******
  • 3725
Re: chdk in the DIGIC6 world
« Reply #13 on: 20 / May / 2014, 17:12:59 »
Reading from the 0xd20bXXXX MMIO area results in an exception (0x10) when done from a CBasic script. The same operation succeeds from AdditionAgentTask...
My first diskboot.bin is crashing somewhere and I haven't yet been able to find a way to access the LED(s) directly... :(


Re: chdk in the DIGIC6 world
« Reply #14 on: 21 / May / 2014, 07:03:17 »
I hope you can provide Canon PowerShot SX275hs cracked support. This is an upgraded version of sx240hs.

Re: chdk in the DIGIC6 world
« Reply #15 on: 21 / May / 2014, 07:09:30 »
I hope you can provide Canon PowerShot SX275hs cracked support. This is an upgraded version of sx240hs.

Re: chdk in the DIGIC6 world
« Reply #16 on: 21 / May / 2014, 07:51:10 »
I hope you can provide Canon PowerShot SX275hs cracked support. This is an upgraded version of sx240hs.
I hope you can provide Canon PowerShot SX275hs cracked support. This is an upgraded version of sx240hs.
Double posted in this thread and cross posted here : http://chdk.setepontos.com/index.php?topic=11529.0;topicseen#msg113021

Please do not do that - it will just annoy people here and not make anything happen faster.

TIA
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 3725
Re: chdk in the DIGIC6 world
« Reply #17 on: 21 / May / 2014, 11:18:57 »
The sx275 appears to be the China-only version of the sx270/280 (with Wi-Fi, without GPS). Since the 100c version of the sx270 and sx280 firmware is identical, there is a chance that the sx275 also shares the same firmware. A firmware dump is always welcome: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper

It turns out I had a typo in my LED routines, direct LED access is now working for me from AdditionAgentTask (details in my earlier post in this thread).
I have however no luck with either diskboot or .fi2.

edit3: I got the file that I wanted, thanks for everyone who helped me!
« Last Edit: 22 / May / 2014, 09:49:40 by srsa_4c »


*

Offline srsa_4c

  • ******
  • 3725
Re: chdk in the DIGIC6 world
« Reply #18 on: 23 / May / 2014, 11:53:52 »
Now it is booting (both methods). No CHDK tasks are started or replaced yet, so I get "memory card locked". That means the CreateTask replacement (it's empty at this point) is usable.
Interestingly, I don't have to do any loader magic (except relocating CHDK to its intended place), I can jump straight to CHDK core and execute the firmware's normal startup sequence (with the usual slight modifications).

The other news is, it is now certain that the sx270/275/280 share the same firmware.

*

Offline philmoz

  • *****
  • 3070
    • Photos
Re: chdk in the DIGIC6 world
« Reply #19 on: 23 / May / 2014, 18:03:07 »
Now it is booting (both methods). No CHDK tasks are started or replaced yet, so I get "memory card locked". That means the CreateTask replacement (it's empty at this point) is usable.
Interestingly, I don't have to do any loader magic (except relocating CHDK to its intended place), I can jump straight to CHDK core and execute the firmware's normal startup sequence (with the usual slight modifications).

The other news is, it is now certain that the sx270/275/280 share the same firmware.

Well done 8)

Guess it's time to look for a Thumb2 disassembler for finsig and codegen.

Phil.
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)

 

Related Topics