chdk in the DIGIC6 world

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #20 on: 24 / May / 2014, 11:40:47 »

Advertisements

Quote from: philmoz on 23 / May / 2014, 18:03:07

Well done

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

Thanks. I'm collecting possible disassembler source candidates here. I have not found a ready-to-use disassembler yet, so I'm still using objdump with perl scripts for porting.
I'm currently using a gcc 4.8 based toolchain from here, works fine, but I don't yet know whether there will be floating point related issues with it. I don't seem to notice signs of hw floting point in the disassemblies.
Since arm-elf is obsolete, elf2flt will have to be adjusted to arm-none-eabi (hopefully that target won't produce different results on 32bit vs 64bit or Win vs linux...).

I have since found the pixel format of the YUV overlay: uyvy, 32bit / 2 pixels. The chroma components are 'shifted', 0x80 is their zero level. This overlay shows interesting horizontal artifacts (probably the result of a low quality resize from 720x480 to 640x480).

waves.png (11.01 kB, 696x524 - viewed 155 times.)

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #21 on: 26 / May / 2014, 14:58:42 »

CHDK display is working. Sort of. There are redrawing problems (the current buffer is not always really current), the overlay is transparent (only has good visibility on dark background). The resolution is either too high (640x480) or too low (320x240), depending on how I map the 'CHDK pixels'. Some colors show up differently than expected. I'm packing the color components (Y, U, V) into one byte to avoid having to change everything that relies on 'color' being a 'short'.
Since CHDK is unusable without modules, that is the next thing to do.

sx280_meminfo.jpg (194.3 kB, 1280x959 - viewed 273 times.)

sx280_buildinfo.jpg (180.36 kB, 1280x960 - viewed 264 times.)

Logged

larrycafe2

1

Re: chdk in the DIGIC6 world

« Reply #22 on: 26 / May / 2014, 22:38:44 »

thank you for the great work srsa_4c

looking forward to CHDK with SD UHS card speed and 1080 60p video

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #23 on: 27 / May / 2014, 15:43:44 »

After adding appropriate(?) cache manipulation routines for ARMv7, some modules have started to work. I used modules compiled for regular CHDK, as building them with arm-none-eabi is not possible yet.

@larrycafe2
I'll post into the camera-specific porting thread once there is a usable test build.

Logged

larrycafe

49

Re: chdk in the DIGIC6 world

« Reply #24 on: 28 / May / 2014, 02:27:22 »

except G1X II, all other DIGIC 6 camera has 1080 60p, the video quality should be very good with the DIGIC 6 H.264 high profile compression with quality override (and it can write at UHS speed)

I will buy one as soon as the first CHDK enabled DIGIC 6 camera arrive

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #25 on: 07 / June / 2014, 16:44:50 »

Progress (or not) report.
I'm stuck at searching for a usable screen refresh method. The old, ScreenLock/Screenunlock or RefreshPhysicalScreen based methods only flip the active buffer, but don't erase screen content not made by the Canon firmware.
I have also tried a workaround I once used on the S1IS: I used the fw routines that display and remove the black "busy" screen. This method yields a perfect redraw, but there are severe drawbacks:
- it blinks on redraw, the "busy" text is visible during refresh
- it's slow when the Canon menu is open
- makes the OSD editor unusable (removes everything from the screen)

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #26 on: 14 / June / 2014, 16:42:40 »

The CPU of the sx280 runs 1 million cycles of this

Code: [Select]

002bd560 <busyloop1>:
  2bd560:	3801      	subs	r0, #1
  2bd562:	f63f affd 	bhi.w	2bd560 <busyloop1>

in 20 msecs (measured right before booting CHDK and in playback mode). That's 100 MIPS, assuming most instructions execute with this speed. I was kinda expecting more...

A note: the 1 MHz counter is still the one @ 0xc0242014 .

edit:
For comparison, using 'code' equivalent to the above in playback mode:
DIGIC II and III: 36 MIPS
DIGIC 4 (and 5?): 72 MIPS

edit2:
The jogdial no longer has a separate task, its routines are now called by the PhySw task. The counter hardware is located in the 0xd985xxxx MMIO range.

edit3:
The ARM CPU in DIGIC 6 knows the UDIV and SDIV instructions (integer divide), so it's ARMv7-A or ARMv7-M.

« Last Edit: 13 / July / 2014, 13:07:25 by srsa_4c »

Logged

tnovak

1

Re: chdk in the DIGIC6 world

« Reply #27 on: 17 / June / 2014, 10:00:50 »

Just installed CHDK on my SX280, I am willing todo some testing and help in anyway that I can. Just let me know.

Thanks

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #28 on: 17 / June / 2014, 13:03:41 »

Quote from: tnovak on 17 / June / 2014, 10:00:50

Just installed CHDK on my SX280, I am willing todo some testing and help in anyway that I can.

Well, you can test the various overrides (after reading the list of issues in the porting thread). If you find new problems (for example crash in certain situations), please post them to that thread. Card speed tests are also welcome (if you happen to have any cards with theoretical writing speed above ~20MB/s). One more thing, you could upload a completely overexposed DNG: I'd like to see whether other cameras' black borders match mine.
I'll probably post a newer build with some improvements in a few days.

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #29 on: 06 / November / 2014, 12:31:57 »

I have found the reason why I could not find references to the OpenGL strings: there is a separate CPU (most likely inside the DIGIC) that draws the overlay. It runs DryOS and is little endian. DryOS debug strings suggest it's not ARM and has an FPU (it might be Fujitsu FR as one of its registers is 'PS', but other strings around say otherwise, the FR doesn't have registers named SP or LR). Its firmware is almost 1MB, the ARM CPU copies it to the 0x80a00000 RAM address (both CPUs see that memory at the same address).
All OpenGL strings are inside this CPUs firmware. This CPU also writes a log into RAM which is written to the card whenever a romlog is requested. I currently have no idea how the ARM and this graphic CPU communicates.

That's not all: there appears to be yet another ARM firmware inside the ROM, also running DryOS (the ROM image has 3 separate DryOS shell related string blocks).

I also found out that the ARM (the one CHDK runs on) sees several mirrors of its 256MB RAM (at addresses 0x10000000, 0x20000000, ... even above 0x80010000).

Logged