chdk in the DIGIC6 world

c10ud

chdk in the DIGIC6 world

« on: 16 / March / 2014, 06:56:35 »

Advertisements

This is a spin-off of the discussion going on over here: http://chdk.setepontos.com/index.php?topic=9992.40

I am trying to get the tools right for some progression with the newer cameras and starting from the s120_100e dump I made some changes in order to accomodate a thumb2 build.

Here's a list of issues I found (and remember) in no particular order (probably you already know some of those):
- chdk (and modules) isn't really modular
- arm-none-eabi compilers cannot handle what's going on in elf2flt
- gcc 4.8.x isn't probably needed
- older binutils cannot really handle some thumb2 code
- ..

With that in mind, here's my current toolchain-setup script based on srsa4c's version: http://pastebin.com/ssbtrwQt

And a link to the branch where I'm pushing my experiments: https://github.com/c10ud/CHDK/tree/s120_thumb2

My goal: let a DISKBOOT.BIN "dance"

Which means I just want to crash the camera or blink some led so we can confirm that the toolchain is correct (and we can use it as a reference version) and the cameras, other than changing their ICs, still have the same "backdoors".

Here's a link to my current changes to trunk: https://github.com/c10ud/CHDK/commit/0e12a2c2cadff0b6fd569eb4b02153aea317b05e
All the platform/s120 stuff comes from s110, however I deleted almost anything, I just care about loader and early boot (since it's tiny).
You'll notice (offtopic) the camera isn't messing with caches in the reset code anymore, comparing to other camera.

Anyway, at the moment the code is compiling almost correctly with
"make PLATFORM=s120 PLATFORMSUB=100e firsub"
and then
"make SKIP_MODULES=1 PLATFORM=s120 PLATFORMSUB=100e firsub"
so you don't have undefined references (see "chdk isn't really modular")
but the newest issue is a linker error: http://pastebin.com/VRNrLqrS

I tried setting soft float here and there but no luck so far, suggestions, hints, whatever else are welcome

Logged

reyalp

13880

Re: chdk in the DIGIC6 world

« Reply #1 on: 16 / March / 2014, 15:16:40 »

Good call starting a digic6 thread.

For reference, other digic6 related threads:
sx280, with some useful research and entry points found http://chdk.setepontos.com/index.php?topic=9992.0

s120 dump http://chdk.setepontos.com/index.php?topic=11293.0

Another sx280 thread http://chdk.setepontos.com/index.php?topic=9743.0

Other digic6 cameras
G1X MK2 http://www.dpreview.com/products/canon/compacts/canon_g1xii
SX700 http://www.dpreview.com/products/canon/compacts/canon_sx700
N100 http://www.dpreview.com/products/canon/compacts/canon_n100/specifications

Quote

Which means I just want to crash the camera or blink some led so we can confirm that the toolchain is correct (and we can use it as a reference version) and the cameras, other than changing their ICs, still have the same "backdoors".

Given that the diskboot code still exists this seems very likely but as always, the proof is in doing. As a mentioned on IRC, if you aren't sure whether you have the right method to blink LEDs, you can verify it using Canon basic poke.

Quote

You'll notice (offtopic) the camera isn't messing with caches in the reset code anymore, comparing to other camera.

In the armv7 docs, it appears that control of this kind of stuff is no longer done the same way.

Quote

but the newest issue is a linker error: http://pastebin.com/VRNrLqrS

This looks like your toolchain isn't configured for the kind of binary you are trying to build. Unfortunately, about the only thing I remember about these issues was they were confusing

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #2 on: 16 / March / 2014, 19:42:28 »

My guess on LEDs:

sx280, 101b

ref to "LEDCon" @ 0xfc0c4318
task_LEDCon @ 0xfc0c407c (0xfc0c407d with the thumb bit set)
taskcreate_LEDCon @ 0xfc0c427e

LED table init function @ 0xfc078454
interesting values in the function:
0x65 (stored at offset 4)
4 (stored at offset 0x104)

task_LEDCon:
'switch off'(?) @ loc_fc0c415e -> loc_fc07843e (magic value 0x4c0003) -> loc_fc0c362c (sets GPIO)
'switch on'(?) @ loc_fc0c4170 -> loc_fc078428 (magic value 0x4d0002) -> loc_fc0c362c

Code: [Select]

loc_fc0c362c: ; 125 refs
fc0c362c:   4a07        ldr r2, [pc, #28]           ; 0xfc0c364c: (d20b0000) 
fc0c362e:   eb02 0080   add.w   r0, r2, r0, lsl #2
fc0c3632:   f8c0 1800   str.w   r1, [r0, #2048]     ; 0x800
fc0c3636:   4770        bx  lr

So, switching LEDs on/off (r0 is the LED number from the LED init func):

*(int*)(0xd20b0800 + r0 * 4) = 0x4c0003
*(int*)(0xd20b0800 + r0 * 4) = 0x4d0002

About the toolchain: IMHO interworking is probably not needed and I'm not sure if --disable-hardfloat is needed. I'm just guessing though.

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #3 on: 05 / May / 2014, 16:07:37 »

First impressions and questions.
It appears that the OpenGL strings are not a joke. I have found (in a RAM dump) multiple different versions of the "bitmap overlay": 8 bit paletted 640x480, higher resolution versions with some yet unknown pixel format.
I was able to dump 256MB of RAM from 0x00000000 (didn't try more), but I don't know if all of that is physical. How can I tell whether there is memory mapping? Also, does anyone have an idea how to query the ARM CPU's properties?

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #4 on: 07 / May / 2014, 16:59:46 »

I'm able to run (simple) binaries on the camera. I'm using the AdditionAgentRAM eventproc to load my plain, unencoded binary and run it as a task.
This has allowed me to dump the RAM in rec mode, and do some experiments on some of the found overlay buffers. I haven't been able to blink an LED by using MMIO though, my above "guess" is somehow not right.
About the overlays: the main one has a 16 bit/pixel format (probably some kind of YUV), the other is 8 bit/pixel. The latter may be used as transparency layer or something, I don't have a better idea. Both kind of overlays have 640x480 pixel resolution, and both are double buffered.
The attached image shows the effect of 64kB random data copied over the main overlay (noise at the top), the same data is copied to the 8bpp overlay (luma noise below).
The Canon Basic script is this:

Code: [Select]

private sub Initialize()
 System.Create()
 AdditionAgentRAM("A/MY.BIN","WHAT")
end sub

The source for the binary is

Code: [Select]

@ compile with:
@ arm-elf-gcc -Wl,-N,-Ttext,0x5ce000 -nostdlib -march=armv7 -mthumb try2.s -o try2.bin
@ and extract the needed bytes from the binary :/
@ 0x5ce000 is the start of AdditionAgent RAM
.globl _start
.org 0
_start:
.text
@ first byte has to be non-zero (otherwise blob might be treated as encoded)
push {r4,lr}
ldr r0, =10000      @ 10sec
ldr r3, =0xfc251cb4 @ SleepTask, arm
blx r3
mov r0, #0
mov r1, #4
mov r2, #0x80
ldr r3, =0xfc1a73d9 @ LEDDrive, thumb
blx r3
ldr r2, =0x1b6
ldr r1, =0x101      @ O_TRUNC, O_WRONLY
adr r0, fname
ldr r3, =0xfc2a50fb @ Open, thumb
blx r3
mov r4, r0
mov r1, #0
ldr r2, =0x10000000 @ 256 MB
ldr r3, =0xfc2a51a3 @ Write, thumb
blx r3
mov r0, r4
ldr r3, =0xfc2a50fd @ Close, thumb
blx r3
mov r0, #0
mov r1, #1
mov r2, #0x80
ldr r3, =0xfc1a73d9 @ LEDDrive, thumb
blx r3
ldr r3, =0xfc2512b1 @ ExitTask, thumb
blx r3
pop {r4,pc}

fname:
.asciz "A/RAM.BIN"

@ sx280 102b
@ DebugAssert, 0xfc251d14
@ ReceiveMessageQueue, 0xfc251bfc
@ GetNumberOfPostedMessages 0xfc251bf4
@ Close 0xfc2a50fc
@ GiveSemaphore 0xfc251c3c
@ Open 0xfc2a50fa
@ Write 0xfc2a51a2
@ SleepTask 0xfc251cb4
@ ExitTask 0xfc2512b0
@ LEDDrive 0xfc1a73d8

The first byte of the binary has to be non-zero.

Uncached addresses are OR'd with 0x40000000.

IMG_1403a.jpg (810.14 kB, 1722x1214 - viewed 212 times.)

Logged

c10ud

Re: chdk in the DIGIC6 world

« Reply #5 on: 07 / May / 2014, 17:36:01 »

nice test and findings srsa

I don't have any camera so from time to time I tried getting the toolchain to build the new source, but no progress so far.. still stuck in the linking process (toolchain built with FPA etc.)

also trying to rebuild the toolchain with some different options lead to nowhere..maybe you could take a look since you seem motivated

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #6 on: 07 / May / 2014, 18:01:10 »

Quote from: c10ud on 07 / May / 2014, 17:36:01

I don't have any camera so from time to time I tried getting the toolchain to build the new source

Oh. I thought you had access to that s120

I will probably try the existing CHDK toolchain at some point, although the floating point formats will probably cause trouble. I'll also have make a utility that can put the objdump output into (re-)usable assembly format. The disassembly made by the current script also has mistakes due to the variable length instructions, that will have to be dealt with too.

As it currently seems, CHDK will need new display routine(s) and everything that read from framebuffers will need to be changed too.
And there's a lot to change in the CHDK build support routines (macros, makefiles, ...).

Logged

hacksawz12

Re: chdk in the DIGIC6 world

« Reply #7 on: 12 / May / 2014, 23:55:33 »

srsa,

I've played with your script for a little while and got the leds to work, while still dumping the ram.

Code: [Select]


@ compile with:
@ arm-elf-gcc -Wl,-N,-Ttext,0x5ce000 -nostdlib -march=armv7 -mthumb try2.s -o try2.bin
@ and extract the needed bytes from the binary :/
@ 0x5ce000 is the start of AdditionAgent RAM
.globl _start
.org 0
_start:
.text
@ first byte has to be non-zero (otherwise blob might be treated as encoded)
push {r4,lr}
ldr r0, =10000      @ 10sec
ldr r3, =0xfc251cb4 @ SleepTask, arm
blx r3
mov r0, #0x46
mov r1, #7
mov r2, #0x44
ldr r3, =0xfc1a73d9 @ LEDDrive, thumb
blx r3
ldr r2, =0x1b6
ldr r1, =0x101      @ O_TRUNC, O_WRONLY
adr r0, fname
ldr r3, =0xfc2a50fb @ Open, thumb
blx r3
mov r4, r0
mov r1, #0
ldr r2, =0x10000000 @ 256 MB
ldr r3, =0xfc2a51a3 @ Write, thumb
blx r3
mov r0, r4
ldr r3, =0xfc2a50fd @ Close, thumb
blx r3
mov r0, #0
mov r1, #1
mov r2, #0x80
ldr r3, =0xfc1a73d9 @ LEDDrive, thumb
blx r3
ldr r3, =0xfc2512b1 @ ExitTask, thumb
blx r3
pop {r4,pc}

fname:
.asciz "A/RAM.BIN"

@ sx280 102b
@ DebugAssert, 0xfc251d14
@ ReceiveMessageQueue, 0xfc251bfc
@ GetNumberOfPostedMessages 0xfc251bf4
@ Close 0xfc2a50fc
@ GiveSemaphore 0xfc251c3c
@ Open 0xfc2a50fa
@ Write 0xfc2a51a2
@ SleepTask 0xfc251cb4
@ ExitTask 0xfc2512b0
@ LEDDrive 0xfc1a73d8

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #8 on: 14 / May / 2014, 14:04:35 »

Quote from: hacksawz12 on 12 / May / 2014, 23:55:33

srsa,

I've played with your script for a little while and got the leds to work, while still dumping the ram.

The LEDDrive function is working of course, it's the LED's direct access (through the 0xd20bXXXX MMIO area) that didn't when I tried from a Canon Basic script.
The current plan is to make a regular "minimal" port (that includes finding all stubs and addresses manually) then adjust the build system to be able to compile CHDK.
I'm still concerned about the display - drawing will be painful if the overlay turns out to be YUV with subsampled chroma...

Logged

reyalp

13880

Re: chdk in the DIGIC6 world

« Reply #9 on: 14 / May / 2014, 16:06:35 »

Quote from: srsa_4c on 14 / May / 2014, 14:04:35

I'm still concerned about the display - drawing will be painful if the overlay turns out to be YUV with subsampled chroma...

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.

Logged

Don't forget what the H stands for.