the sx10 porting thread

cormac

MacDaddy
Cormac, thanks for getting us the latest beta build for 1.00C, I'll admit that I'm a newbie to CHDK but finally being able to play with the advanced features is great. I've been real excited to try bracketing with RAW images but may have found a possible bug? My SX10 chokes just after taking the second shot when I'm shooting RAW in bracket mode. I tried with both the SX10's built in bracket modes and with the CHDK's. I have to remove the batteries to recover. Shooting in bracket mode still works fine when shooting JPG.

I'm I the only one seeing this?

Thanks,

Confirmed. I managed to get the same crash.

I'll look into it in the morning, and see if I can build a test case.

tool46

reyalp I installed the new autobuild and bracketed with RAW and the canon side worked and also the CHDK side worked ok for me. Although its late at night not much to take pictures of. Later

gexplorer

cormac

martinhamersky
Sorry i´m a newbie,here is the Bin file for GM1.03a
http://drop.io/1u4p3st

Perfect! Thanks!

Hi, only now did I see your tutorial on how to get the dump for 1.03a . Since someone already uploaded the file, do you still need it?

cormac

gexplorer

cormac

martinhamersky
Sorry i´m a newbie,here is the Bin file for GM1.03a
http://drop.io/1u4p3st

Perfect! Thanks!

Hi, only now did I see your tutorial on how to get the dump for 1.03a . Since someone already uploaded the file, do you still need it?

No, one is usually good enough 😀

tool46

hey guys new autobuild 1.00c does crash when bracketing.

cormac

Bracketing in Tv mode works ok.
Bracketing with RAW turned on crashes in Tv after 2-3 shots.

It looks like this has been already reported and is a general CHDK error:
http://chdk.kernreaktor.org/mantis/view.php?id=258

0000258: Camera stop responding when using Focus Bracketing
Description When Focus Bracketing is activated the camera stops responding after the first shot is made.
Symptoms:
1)the LCD is turned off.
2)Camera does not react to any button. It can be only switched off by power off button.
3)1 second after the LCD turns off one uncommon mechanical click can be heard from the device.

other info:
CHDK is set to default settings
This behaviour is the seame regardless of values of "Subj. Dist. Bracket Val", "Value factor (mm)" and "bracketing type"
Tv and Av bracketing work fine.

For some reason in the SX10 this seems to happen in combination with Raw mode.

Edit: This happens only in continuous shooting mode. Scripted bracketing seems to work ok.

Testcase: Camera in continuous Tv mode, Raw Parameters -> Save Raw, DNG Format, DNG extension, and Raw buffer cached set; Extra Photo Operations -> Bracketing in continuous mode -> TV bracketing value=1 Ev, Bracketing type=+/- Add Raw-suffix set.
Two-three shots it locks and shuts down.

Further edit: It seems more stable when I turn off "DNG format" and "RAW buffer cached". With DNG on it crashes every time; with DNG off it crashed only once, and that was a reboot as opposed to have to pop batteries.

The upside is that you can get raw bracketing working, the downside is that you will have to convert the CRW files to use them in anything.

reyalp

Did you try with "Add raw suffix" off ?

cormac

reyalp
Did you try with "Add raw suffix" off ?

Wow. That fixed it. Apparently don't use that combination of options 😀

reyalp

cormac

reyalp
Did you try with "Add raw suffix" off ?

Wow. That fixed it. Apparently don't use that combination of options 😀

Raw suffix uses a LFN :/

cormac

reyalp

cormac

reyalp
Did you try with "Add raw suffix" off ?

Wow. That fixed it. Apparently don't use that combination of options 😀

Raw suffix uses a LFN :/

Sounds like we need to find a fix for the LFN in DryOS...

MacDaddy

cormac

reyalp

cormac

reyalp
Did you try with "Add raw suffix" off ?

Wow. That fixed it. Apparently don't use that combination of options 😀

Raw suffix uses a LFN :/

Sounds like we need to find a fix for the LFN in DryOS...

Thanks for jumping on this issue. As for me, I was originally doing it in CRW and still crashing, may have been the RAW Suffix mode that I was in as well. Would like to test it without the suffix, but I've gone to DNG because I could not find anything that would convert my CRW's. I tried Picasa3, DNG4PS-2 and even the Canon CRW codecs and nothing would recognize them.

Now my next goal is to read up on using scripted bracketing..

reyalp

MacDaddy
I tried Picasa3, DNG4PS-2 and even the Canon CRW codecs and nothing would recognize them.

Please read the stickies in the raw processing subforum if you want to know why.

yvesson

Hej,
Anyone managed to load the 1.01b beta ? I tryed and I'm like stuck in replay mode and can't do anything. I'm wondering if this is just me having done something wrong (4 Gb SDHC card maybe, formatted in FAT as I read in the faq).
The led blinks and I get the logo, but then nothing else work, trying to update the firmware blinks the led again but doesn't help any other way.

reyalp

yvesson
Hej,
Anyone managed to load the 1.01b beta ? I tryed and I'm like stuck in replay mode and can't do anything. I'm wondering if this is just me having done something wrong (4 Gb SDHC card maybe, formatted in FAT as I read in the faq).
The led blinks and I get the logo, but then nothing else work, trying to update the firmware blinks the led again but doesn't help any other way.

Maybe this will help ? https://chdk.setepontos.com/d/3835/7

yvesson

Hej,
Ah yes thanks for the fast answer, I should have read that one. Not too annoying to half press once.

achurch

Apologies for jumping in on the topic, but in case it's of any use, I've slightly modified the 1.02b source code and obtained a build that seems to work with 1.03a. Source diff (against SVN r782, with the platform/sx10/sub/102b directory copied to 103a) and DISKBOOT.BIN here.

reyalp

achurch
Apologies for jumping in on the topic, but in case it's of any use, I've slightly modified the 1.02b source code and obtained a build that seems to work with 1.03a. Source diff (against SVN r782, with the platform/sx10/sub/102b directory copied to 103a) and DISKBOOT.BIN here.

I'm confused as to what you are doing with the custom finsig there. If you want to use your own tools to generate the values for stubs_entry_2.S that's fine, but using a different system for the auto-detected entry points will cause a lot of pain later on. Nor should perl be part of the normal build process.

If you can submit a patch (or just zip of the 103a sub, since it's all going to be adds anyway) that works like the normal builds, I would be happy to check that in.

edit:
I should add that finding stuff based on already ported versions of the same camera is a great idea. If generalized and tidied up a bit we could put it in the tools directory.

achurch

reyalp
I'm confused as to what you are doing with the custom finsig there. If you want to use your own tools to generate the values for stubs_entry_2.S that's fine, but using a different system for the auto-detected entry points will cause a lot of pain later on. Nor should perl be part of the normal build process.

That was just a quick-and-dirty hack to get things running after I couldn't get the regular finsig tool to work (I tested on the 1.02b firmware and got a lot more "not found"s than I should have).

If you can submit a patch (or just zip of the 103a sub, since it's all going to be adds anyway) that works like the normal builds, I would be happy to check that in.

edit:
I should add that finding stuff based on already ported versions of the same camera is a great idea. If generalized and tidied up a bit we could put it in the tools directory.

Since I can't seem to get the standard method to work, what I could do is clean up and generalize the entry point finder to work from any firmware X to firmware Y, then perhaps add a Makefile variable which selects which entry point generation method to use, standard or single-firmware. Something like (this is just off the cuff):

=== platform/XXX/sub/YYY/Makefile ===
STUBS_METHOD=single
STUBS_PLATFORM=ZZZ  # Use platform/ZZZ/...
STUBS_SUBPLATFORM=WWW  # .../sub/WWW/PRIMARY.BIN
STUBS_ROMBASEADDR=0xFF810000  # or 0xFFC00000
STUBS_FILES=stubs_entry.S stubs_entry_2.S  # sub/WWW/* files with stubs

=== platform/makefile_sub.inc ===
ifeq ($(STUBS_METHOD),single)
SOURCE_PRIMARY=$(PRIMARY_ROOT)/$(STUBS_PLATFORM)/sub/$(STUBS_SUBPLATFORM)/PRIMARY.BIN
stubs_entry.S: $(TARGET_PRIMARY) $(SOURCE_PRIMARY) $(topdir)tools/finsig$(EXE)
        @echo \-\> $@
        if [ -s $(TARGET_PRIMARY) -a -s $(SOURCE_PRIMARY) ] ; then \
          $(topdir)tools/finsig-single $(TARGET_PRIMARY) $(ROMBASEADDR) $(SOURCE_PRIMARY) $(STUBS_ROMBASEADDR) $(STUB_FILES:%=../../../$(STUBS_PLATFORM)/sub/$(STUBS_SUBPLATFORM)/%) > stubs_entry.S ; \
        else \
          echo CAUTION! \'stubs_entry.S\' is not updated due to target or source firmware binary not found! ; \
          touch stubs_entry.S ; \
        fi ; \
        if [ "X`grep 'ERROR' stubs_entry.S`" != "X" ] ; then \
          grep "ERROR" stubs_entry.S | $(ESED) "s/\/\/ ERROR: ([^ ]+) is not found.*/\1/" | $(SORT) | uniq > stubs_nf.names ; \
          grep -E "NH?STUB" stubs_entry_2.S | $(ESED) "s/ *NH?STUB\( *([^ ,]+).*/\1/" | $(SORT) | uniq > stubs_mn.names ; \
          comm -23 stubs_nf.names stubs_mn.names > stubs_not_found_names.err ; \
          rm -f stubs_nf.names stubs_mn.names ; \
          if [ -s stubs_not_found_names.err ] ; then \
            echo ERROR! There are unresolved addresses in \'stubs_entry.S\' \($(PLATFORM)-$(PLATFORMSUB)\) for the following names: ; \
            cat stubs_not_found_names.err ; \
            echo Please, add them into \'stubs_entry_2.S\' manually! ; \
            mv stubs_entry.S stubs_entry.S.err ; \
            exit 1 ; \
          fi ; \
          rm -f stubs_not_found_names.err ; \
        fi
else
# The usual code
endif

This of course fails to check whether the source stub files are up to date, but something along those lines.

cormac

achurch

reyalp
I'm confused as to what you are doing with the custom finsig there. If you want to use your own tools to generate the values for stubs_entry_2.S that's fine, but using a different system for the auto-detected entry points will cause a lot of pain later on. Nor should perl be part of the normal build process.

That was just a quick-and-dirty hack to get things running after I couldn't get the regular finsig tool to work (I tested on the 1.02b firmware and got a lot more "not found"s than I should have).

I found the findsig tool to be a bit confusing.

Once I figured out that I had to drop the camera rom file into the directory along with the stubs file and called it PRIMARY.BIN everything went a lot better.

The renaming was what I missed out on.
Cormac

Edit: The main problem I see with the 1.03a diff is that the subs_entry_2 is pretty much null. I moved the correct values back into this and it compiles without complaint as long a valid PRIMARY.BIN is in the subs directory. I'll run 1.03 through IDA and check the addresses and post my version in the morning. Yes, finsig should find most of the addresses it needs, but this will work for now.

achurch

cormac
I found the findsig tool to be a bit confusing.

Once I figured out that I had to drop the camera rom file into the directory along with the stubs file and called it PRIMARY.BIN everything went a lot better.

That's what I tried, but unfortunately it didn't work correctly, and I ended up deciding it would be easier to adjust the 1.02b code on the assumption that the firmwares would be similar.

Edit: The main problem I see with the 1.03a diff is that the subs_entry_2 is pretty much null. I moved the correct values back into this and it compiles without complaint as long a valid PRIMARY.BIN is in the subs directory. I'll run 1.03 through IDA and check the addresses and post my version in the morning. Yes, finsig should find most of the addresses it needs, but this will work for now.

Actually, subs_entry_2 is mostly empty because the custom finsig found everything that was originally in there by looking at the 1.02b firmware; the stubs are all in stubs_entry_1 instead. That said, it's a quick hack and (as reyalp says) doesn't work well as a general build process, so if you can get it working with the standard process, that'd be great.

For reference, it looks like 5 words were inserted at 0xFF974028 and another 1 word somewhere in the middle of the 0xFFBxxxxx range (there was one variable pointer toward the high end of 0xFFB that was offset 24 bytes instead of 20).

« Previous Page Next Page »