SX280 / 275 / 270 porting - page 22 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 17 18 19 20 21 [22] 23 24 25 26 27 ... 37   Go Down

SX280 / 275 / 270 porting

  • 365 Replies
  • 239915 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: SX280 / 275 / 270 porting
« Reply #210 on: 21 / August / 2015, 11:37:33 »
Advertisements
Quote from: iax on 20 / August / 2015, 16:56:59
- as of today, what is the ideal build environment (OS + gcc + cross compiler + build tools) for a D6 camera? Is there anything like a virtual machine we can download with anything we need pre-installed?
Since there are not many developers working on DIGIC 6 cameras, getting their opinion is not easy. Here's mine.
- I'm on Linux. I get all needed tools from the official OS repo. An exception is the toolchain, I'm using a precompiled one (arm-none-eabi) from here: https://launchpad.net/gcc-arm-embedded .
However, Linux is not a requirement, we have developers using Windows and even OSX. So, the OS is your choice. I'm not aware of suitable pre-made VMs.
Quote
- what are the recommended tools? Many years ago I've been using IDA, is this still recommended  or are there better options?
If you know how to use IDA, that's probably the best choice (our GPL tools are not advanced enough, and most of them are not usable on Thumb-2 firmware). However, I don't know any IDA scripts that would make decompilation easier (the ones we have are very likely not compatible with Thumb-2 code).

You can use a working copy from the following repo to determine whether compilation works (for the sx280): https://subversion.assembla.com/svn/chdk-s1.d6try2/trunk
Logged
*

Offline iax

  • *
  • 45
Re: SX280 / 275 / 270 porting
« Reply #211 on: 22 / August / 2015, 19:59:09 »
Thanks, I've a working environment now, and have successfully compiled the sx280 and have created a skeleton for the sx60.

I'm currently looking into the results of the disassembled dumps (via the perl script) of both cameras. While I can make sense of values in stubs_min.S (I can map similar portion of code across the sx280 and the sx60), I am not understanding the addresses I find in stubs_entry_2.S.

For instance in the stubs_entry_2.S for the sx280_102b I read:

Code: [Select]
NHSTUB(AllocateUncacheableMemory ,0xfc15a7e5)
however in the dump for the same sx280_102b I cannot see anything meaningful at that location (while I seem to have an entry at fc15a7e4):

Code: [Select]
loc_fc15a7e4: ; 15 refs
"...F@0]
":
fc15a7e4: b570      push {r4, r5, r6, lr}
fc15a7e6: 4606      mov r6, r0
fc15a7e8: 3040      adds r0, #64
fc15a7ea: f15d f9c7 bl loc_fc2b7b7c
loc_fc15a7ee:
fc15a7ee: 0004      movs r4, r0
fc15a7f0: d00d      beq.n loc_fc15a80e

Do you have any hint about how to interpret the addresses in stubs_entry_2.S and how to map those to the results of the disassembler perl script?

Also, I would like to better understand the meaning of the remark "thumb functions NEED the thumb bit in the below list". How can I distinguish arm/thumb functions?

Thanks a lot, apologies if the questions are really basic
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX280 / 275 / 270 porting
« Reply #212 on: 22 / August / 2015, 20:31:21 »
Quote from: iax on 22 / August / 2015, 19:59:09
Do you have any hint about how to interpret the addresses in stubs_entry_2.S and how to map those to the results of the disassembler perl script?
Bit0 of those addresses is not part of the address. Bit0 is set when the code at that address is to be treated as Thumb. Bit0 is the Thumb bit.
Quote
How can I distinguish arm/thumb functions?
The perl disassembly script can only disassemble thumb code (it treats everything as thumb code). If what you're seeing is reasonable, then that part of the code is Thumb.
If you look at disassemblies a lot, you'll mostly know when something looks reasonable (look at disassembled ARM firmwares or the main.bin.dump file you get after building CHDK).
The DIGIC 6 firmware consists of mainly Thumb-2 code, but it contains some ARM parts too:
- some of the kernel functions are ARM
- there are lot of veneers/thunks which use ARM instructions

I have thrown together a small howto for IDA (for the demo, but should work on the full version too), it does a better job at disassembling. http://filebin.net/eg824w49ha
Logged
*

Offline iax

  • *
  • 45
Re: SX280 / 275 / 270 porting
« Reply #213 on: 23 / August / 2015, 18:47:28 »
thanks, I'm able to locate functions in the sx60hs dump now, hope to be able to crash my camera soon...
Logged
*

Offline karmantyu

  • *
  • 6
Re: SX280 / 275 / 270 porting
« Reply #214 on: 26 / August / 2015, 10:22:03 »
Excuse me if I report some obvious thing here, but I am new on the forum.
Just tested the new sx280hs-102c_102d-1.4.0-4196-full build (what I am very grateful for) on my sx280hs which has 102c firmware installed. I'm mostly interested in using the RAW - DNG mode.
So here are my findings using the build above:
- If my native (Hungarian) languages set I get unknown language ID (21) error from default script.
- Most JPG pictures became garbage. I mean the about 40% of the upper side of the picture is mostly purple garbage.
- The saved DNG pictures are mostly purple garbage. Sometimes the sx280 manages to save a good DNG, sometimes it’s saving DNG not at all.

Appreciate your work here.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX280 / 275 / 270 porting
« Reply #215 on: 26 / August / 2015, 15:03:29 »
Quote from: karmantyu on 26 / August / 2015, 10:22:03
- If my native (Hungarian) languages set I get unknown language ID (21) error from default script.
I think the script is based on research done by the CHDK-DE team, it only supports a few languages (the source says English, German, Russian).
Quote
- Most JPG pictures became garbage. I mean the about 40% of the upper side of the picture is mostly purple garbage.
- The saved DNG pictures are mostly purple garbage.
Oops  :(
Can you tell me the shooting mode you used for the damaged images? (exiftool should be able to retrieve that information from the EXIF)
I'm mostly using one of the (semi-)manual modes and haven't noticed problems like this.
You're the first person reporting RAW corruption... Nope, has already been reported and I forgot to fix it...

A very quick trial showed that "sports" mode is affected (and I suspect other "smart" modes - such as AUTO - might be affected too). Awaiting your input on this.
Quote
Sometimes the sx280 manages to save a good DNG, sometimes it’s saving DNG not at all.
RAW/DNG is currently disabled in two shooting modes (hybrid auto, hq burst). You get a warning with red letters at the top of the screen when RAW/DNG is disabled.

Once I get more information, I'll post updated builds.
Logged
*

Offline karmantyu

  • *
  • 6
Re: SX280 / 275 / 270 porting
« Reply #216 on: 27 / August / 2015, 03:58:33 »
At first I would like to thank you for the very fast response.
1.   I think there should be an error message only if there happens one. If a language is not supported why not set EN default and stop throwing error messages?
2.   Uploaded some shot’s to my Dropbox.
https://www.dropbox.com/sh/dgco2i353ggbyro/AAD5R-dDUqKAoW29__qyC4Pfa?dl=0
I’ve tried to shoot in every possible set up. And yes the script is correctly showing when RAW mode is not supported but sometimes failing to store RAW while other settings active. Sometimes the image is garbage.
3.   Yesterday I’ve managed to create badpixel.bin with about 466byte size. Today the process either failed or written a 0byte file to the SD. The only change since yesterday – I am aware of – is the DISKBOOT.BIN file. I am using now the one included in the distributed zip package. I can’t remember which one I had before.
Logged
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: SX280 / 275 / 270 porting
« Reply #217 on: 27 / August / 2015, 08:26:38 »
Quote from: karmantyu on 27 / August / 2015, 03:58:33
1.   I think there should be an error message only if there happens one. If a language is not supported why not set EN default and stop throwing error messages?
This is not an error message, it's more a hint. In this case the script uses the default language. We can add the support for hungarian language in CHDK/SCRIPTS/default.lua.

It seems, the SX270/280 supports three more languages because of the ID 21. Older cameras have the ID 18 for Hungarian.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline iax

  • *
  • 45
Re: SX280 / 275 / 270 porting
« Reply #218 on: 27 / August / 2015, 16:25:18 »
Hi, I've done some progress for the sx60 and mapped pretty much all the functions. I'd like to have a quick help about finding values in stubs_min.S, as I'm finding some inconsistencies between what I read in the file for the SX280-102B and what I read in the assember code.

An example is for instance zoom_busy value, which is listed as 0x10814 in stubs_min.S, What I see in the disassembled code however is:

Code: [Select]
ROM:FC1A0998                 PUSH    {R4-R6,LR}
ROM:FC1A099A                 LDR     R4, =0x107F4
ROM:FC1A099C                 LDR     R0, [R4,#0x24]
ROM:FC1A099E                 CBNZ    R0, loc_FC1A09AC
ROM:FC1A09A0                 MOVS    R0, #0
ROM:FC1A09A2                 MOVW    R2, #0x3E7
ROM:FC1A09A6                 ADR     R1, aZoomlenscontro ; "ZoomLensController.c"
ROM:FC1A09A8                 BLX     sub_FC251D14

which suggests 0x107F4 as correct value (or maybe 0x10818 considering the 0x24 offset at the next instruction). Why the value is 0x10814 instead?

Thanks for your help
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX280 / 275 / 270 porting
« Reply #219 on: 27 / August / 2015, 19:17:57 »
Quote from: iax on 27 / August / 2015, 16:25:18
An example is for instance zoom_busy value, which is listed as 0x10814 in stubs_min.S, What I see in the disassembled code however is:

Code: [Select]
ROM:FC1A0998                 PUSH    {R4-R6,LR}
ROM:FC1A099A                 LDR     R4, =0x107F4
ROM:FC1A099C                 LDR     R0, [R4,#0x24]
ROM:FC1A099E                 CBNZ    R0, loc_FC1A09AC
ROM:FC1A09A0                 MOVS    R0, #0
ROM:FC1A09A2                 MOVW    R2, #0x3E7
ROM:FC1A09A6                 ADR     R1, aZoomlenscontro ; "ZoomLensController.c"
ROM:FC1A09A8                 BLX     sub_FC251D14

which suggests 0x107F4 as correct value (or maybe 0x10818 considering the 0x24 offset at the next instruction). Why the value is 0x10814 instead?
If you look farther down, you'll see
Code: [Select]
fc1a09bc: 2500      movs r5, #0
fc1a09be: 6225      str r5, [r4, #0x20]which would be the fw variable in question (perhaps I should have used 0xfc1a09be as the address to look at). 0x107f4 is likely the base address for a block of variables, the +0x24 offset is out of question because
Code: [Select]
fc1a09d0: e9d4 1009 ldrd r1, r0, [r4, #0x24]
fc1a09d4: 4788      blx r1it stores a function pointer.
I probably used some ARM reference firmware (perhaps sx260/sx510?) to locate this variable.
Logged
Pages: 1 ... 17 18 19 20 21 [22] 23 24 25 26 27 ... 37   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal