DryOS - some success

DataGhost

jeff666@DataGhost
I just remember that I encountered some strange behaviour that's similar to what you get. It happens in the firmwares own copy_data-code. It fails when executed from boot.c. I didn't find out why and was satisfied when the CHDK-copy-function worked. You can try to rewrite or skip a section of code.

Another thing I had to think hard about was a "STRD"-command which is called in the firmware. GCC complains about "command not supported on this processor" and I had to find out what it does and rewrote it to two single "STR" commands. I left a comment in the source file, so you should see it.

If you have absolutely no clue what's going wrong, it's never a bad idea to load the binary in IDA and look if the code got changed by gcc.

Yes, I also suspected that might be a problem while I was walking to my room again, after not having touched any code for several hours. I'm going to make a note and see when I get to it, I think that either IDA is disassembling stuff differently (which assembles in different code) or that the compiler isn't producing proper code... I'm just going to duplicate the functions and compare them on the byte-level, no disassemblers whatsoever (well, to help me find out where I need to look :p ). I think they must be different, since the code I'm using is 100% the same for the biggest part and fails at totally unexpected locations.

mlaprise

Hi,

I'm currently trying to dump the firmware of my SD870IS. I think the blinker of the S5IS or the A720 would work great with the SD870. I'm wonder if someone could tell me where I can get this blinker.

Thanks !

DataGhost

mlaprise: I think you should look in this thread: https://chdk.setepontos.com/d/263. I can probably help you with some stuff, but I don't have a standard diode, standard output and standard tools, so beware 😉

Ontopic: Strange, though... STRD seems to work fine for me, at least the compiler doesn't complain. I'm now just documenting some code, maybe I'll try running it again today. Anyway, not sure if it's useful, but I do remember seeing the compiler complain about it, though I just can't find where anymore: IDA disassembles 'MVN' as 'MOVL'. The latter is not known to the compiler, it should be replaced with MVN, which is the proper identification.

geekmug

jeff666
To find out the rough location of a function use the DRYOS-IDA-function-list.txt file in my zip and look at the a720-firmware. I did the same using the stubs_entry.S from the a710 to find some of the functions in dryos.

Ah, clever. I started to do this, but got tired and went to bed 😁

In general I find it a good idea to put the IDA-function-list into the archives we post. It helps the other developers to reproduce and/or check our success.

No problem, I would even offer my IDA files to someone if they wanted a head start with my firmware.. I hate to think how many hours I have spent walking that file to mark functions and data.

Actually such things can be found out by using text search. Have IDA search the disassembly of a known camera...

I began down this path last night. I grabbed your firmware and started to disassemble it as well in an attempt to match things up.

Basically, everything you put in "used during init"

Forget this! That was an idea I had when I started, but it turns out that it's nonsense. These are addresses used in uHwSetup. It is one of the duplicated functions in boot.c. These names are used only in boot.c and the code itself is just a duplicate from the original firmware. So just stick to sub_XXXXXXXX and write descriptive names in the comment.

Duly noted. Thanks for the heads-up on that.

I think "SetupTask_x" is misleading. The code you found are the tasks itself.

This is only half true. I located as many "task_x" procedures as I could (I think I named them the same way), but then I also tagged the call site which performed the CreateTask as "SetupTask_x" (who knows why I chose that..). In matching names, I think what I called "SetupTask_x", you called "CreateTaskx"; IOW, SetupTask_Startup is your CreateTaskStartup.. bleh naming! I'll move to your naming scheme since you have already published code and it makes more sense anyways.

For the keyboard you will only need one name: "PhySw".

I figured that out shortly after I posted that. However, your code block showing the naming scheme is priceless, thank you. I'll look into the differences with the keyboard.. I'll keep you posted.

So, I have been working against GrAnd's branch..

Hell! That causes some major headaches 😀

No, actually it's useful if we get a branch that's current. You may just have to figure out some things on your own as you are the first one to do it.

I suspect there are some extra functions used and names changed.. but I'm not sure yet whether fixing the Makefile for the trunk is less work than working against GrAnd's branch 😉

As always, thanks for the info.

-Scott

mx3

jeff666

The entry-points for Open, Close, Read and Write need to be found as they are called from platform/generic/wrappers.c.

ROM:FFDD8114                 LDR     R1, =sub_FFC15004
ROM:FFDD8118                 ADR     R0, aOpen       ; "Open"
ROM:FFDD811C                 BL      ExportToEventProcedure
ROM:FFDD8120                 LDR     R1, =sub_FFC150D4
ROM:FFDD8124                 ADR     R0, aRead       ; "Read"
ROM:FFDD8128                 BL      ExportToEventProcedure
ROM:FFDD812C                 LDR     R1, =sub_FFC150D8
ROM:FFDD8130                 ADR     R0, aWrite      ; "Write"
ROM:FFDD8134                 BL      ExportToEventProcedure
ROM:FFDD8138                 LDR     R1, =sub_FFC1502C
ROM:FFDD813C                 ADR     R0, aClose      ; "Close"
ROM:FFDD8140                 BL      ExportToEventProcedure
ROM:FFDD8144                 LDR     R1, =sub_FFC15234
ROM:FFDD8148                 ADR     R0, aLseek      ; "Lseek"
ROM:FFDD814C                 BL      ExportToEventProcedure

GrAnd

DataGhost
Anyway, not sure if it's useful, but I do remember seeing the compiler complain about it, though I just can't find where anymore: IDA disassembles 'MVN' as 'MOVL'. The latter is not known to the compiler, it should be replaced with MVN, which is the proper identification.

IDA uses some macros (by default) which replace some native asm commands. You can switch this option off in the 'Options'->'General'->'Analysis'->'Processor specific analysis options'->'Enable Macros'.

jeff666

Ah, clever. I started to do this, but got tired and went to bed 😁

Yeah, that's the spirit! Just run away when problems arise 😁

No problem, I would even offer my IDA files to someone if they wanted a head start with my firmware..

There's a function to export the database to an .idc file.

I grabbed your firmware and started to disassemble it as well in an attempt to match things up.

After a while every developer will have a zoo of different firmware-versions he uses to match things.

This is only half true. I located as many "task_x" procedures as I could (I think I named them the same way),

Some things are just *to* obvious 😁

but then I also tagged the call site which performed the CreateTask as "SetupTask_x" (who knows why I chose that..). In matching names, I think what I called "SetupTask_x", you called "CreateTaskx"; IOW, SetupTask_Startup is your CreateTaskStartup.. bleh naming! I'll move to your naming scheme since you have already published code and it makes more sense anyways.

You picked the only exception of my naming scheme. Those things around "task_Startup" were found quite at the beginning and I didn't have a proper scheme, than. In fact "CreateTaskStartup" has to be named "CreateTask_Startup" and "Startup" has to be named "task_Startup".

I recently noticed, that in VxWorks-Firmwares the scheme is "taskcreate_X" instead of "CreateTask_X". Although I don't have any specific preference of one over the other I still think we should keep the difference to indicate the OS. Everything with "task" in its name is platform-dependent, anyway.

I suspect there are some extra functions used and names changed.. but I'm not sure yet whether fixing the Makefile for the trunk is less work than working against GrAnd's branch 😉

We need the port matched to a more recent branch, anyway, as trunk is just the basic framework with no funny features to show-off 😁

Cheers.

obsidian

I am glad to see your progress.I read every post with pleasure. Before this topic started, I ordered A710IS. Pity. If there were to chance cancel it , I would order A650 or A720 instead.
Can you send me the idb to explore it?

I make elf programs for my phone(~~Benq-~~Siemens E71). What about the idea to make elf-loader for the Canon? Is it possible?Do you think it will furher enhance cameras' abilities?

jeff666

Before this topic started, I ordered A710IS.

I thought they don't produce them, anymore. That's why I got an A720. At that time I was optimistic that someone would port CHDK to Digic 3. Nobody knew about a changed OS at this time. Fortunately it was simple enough so I could do the port myself (even though some things are still missing).

Can you send me the idb to explore it?

Sure.
Here you are: http://www.zshare.net/download/6245436559b92d/

You need the firmware itself, too. If you don't have it, yet: http://www.zshare.net/download/4675310ed272ee/

I make elf programs for my phone(~~Benq-~~Siemens E71). What about the idea to make elf-loader for the Canon? Is it possible?Do you think it will furher enhance cameras' abilities?

I find the current approach of adding run-time-features by uBasic-scripts pretty much ideal. Adding features to load arbitrary binary code would probably very device-dependent (including the additional programs) and thus not usable for most people (i.e. non-developers).

If a feature is added that enhances the controllability of the camera, it should go into uBasic. If you want to do something entirely different (like running a webserver, or such) you would want to load binary code.

Cheers.

obsidian

I won it in auction-sale(1 year old).
It is right it is device dependent. For each model and firmware exists Function library with ~200 functions.

GrAnd

I've made IDA-signature file for DryOS firmwares (based on functions from A720 dump). Also I've slightly adapted scripts for initial firmware disassembling/analysis.
So, all this stuff can be applied to an another firmware to have a start point.

CanonFW_A-Series_Signatures_for_IDA.rar

70.74KB

mlaprise

DataGhost
mlaprise: I think you should look in this thread: https://chdk.setepontos.com/d/263. I can probably help you with some stuff, but I don't have a standard diode, standard output and standard tools, so beware 😉

Thanks... this is exactly what I was looking for !

geekmug

jeff666
I hope this will get you an Idea. Just ckeck the entrypoints in my stubs_entry_2.S, find them in the a720-firmware and locate the same code in your own. Btw, since I had the S5-firmware opened: your physw_status is 0x11ABC.
It seems like the S5 doesn't have kbd_power_on and kbd_power_off. You might want to have a look how the kbd is handled with the S3.

Does anybody know where I can acquire a copy of the S3's firmware? I tried to google this a bit, but I guess it is a bit obscure. If someone could aide me in finding that, then that would be great. Trying to compare my S5 vs. the A720 leads to issues like the one mentioned above, and I find myself trying to find out what the S3 did instead.. and well, I guess it may even be handy to have a A710 firmware to compare against the A720.. but, certainly having the S3 firmware would be good.

Thanks!
-Scott

jeff666

geekmug wrote:
Does anybody know where I can acquire a copy of the S3's firmware?

You read this thread, did you?

In general it's a good to have as much information as possible, but the port you will be working on is from an A720 to an S5. Just because two DryOS cams of different device series have more in common than two G-series cams with different OS. The kbd is the only exception.

GrAnd wrote:I've made IDA-signature file for DryOS firmwares

Great, thanks.

Here's the current stage of development: http://www.zshare.net/download/62590591cd2690/
Changes:

fixed the naming convention bugs about "Statup" and got rid of unused function names in boot.c and stubs_entry_2.S
started with merging "CaptSeqTask" into CHDK. It's needed for raw-support and NR-suppression. I included the task itself in boot.c and capt_seq.c but I need to gain more information about what this task does and how it does it.
added two debug-functions. #1 is a memory viewer, #2 lists the running tasks. Press <Fn> to reset the Task-offset (else you'll see only junk).
updated DryOS function list.

Cheers.

geekmug

jeff666

geekmug wrote:
Does anybody know where I can acquire a copy of the S3's firmware?

You read this thread, did you?

In general it's a good to have as much information as possible, but the port you will be working on is from an A720 to an S5. Just because two DryOS cams of different device series have more in common than two G-series cams with different OS. The kbd is the only exception.

This is pretty much the exact thing I was working on that made me wonder.. beyond the surface level, the S5's code for handling the keyboard diverges from the A720 pretty drastically.

I've not had much success today.. I copied the relevant bits of the S5 code to the boot.c sequence and modified it all correctly, but I can't get the camera to complete a boot-up no matter where I shortcut out of the edited code. Presumably, I've gotta get at least to the part where I skip StartDiskboot, otherwise it'll be stuck in a loop of reading DISKBOOT.BIN. If I leave the StartDiskboot call in, I get a nice endless loop of flashing my "hacked code start on" LED. Commenting that out that call, like you did, Jeff, gets the thing to finish out the code, but I eventually end up with a locked up camera.. bleh.

I went ahead and made a StartDiskboot function that skips the check for DISKBOOT.BIN, just in case there was some magic in there that was being missed. However, I am still stuck at this point. The only red flag for me was that my task_Startup is slightly different than yours, but that really shouldn't matter that much if I am leaving it alone and just trying to get to a normal booted camera.. bleh (again).

Until another day,
-Scott

jeff666

geekmug wrote:
If I leave the StartDiskboot call in, I get a nice endless loop of flashing my "hacked code start on" LED.

This problem is mentioned in my (lengthy) tutorial-posting.
I had the same problem and needed a way out of the boot-loop. I did it by removing the card after my code has started but before the bootdisk loader would run.

It's your task to build something funny that allows you to run the camera with opened battery/card-case.

If you did this, you can rollback until you find the code that causes the failure.

Cheers.

DDMan

Because this is my first post, I first want to thank all the CHDK developers for their excellent work and Jeff particularly for progressing the DryOS port! I bought my cam 3 months ago and was sad to hear that Canon changed to DryOS.

I wanted to try your current status with my A720 firmware 1.00c but I think I am a little bit too fast.
I copied the diskboot.bin and the .fir file from the bin folder of your zip on to the root folder of my SD card. But when I start my cam in play mode there is no option to update and therefore start CHDK. 😐:

Could you please help me?

Cheers

DataGhost

Ok, I get some very strange behaviour from my S5. I decided to see if the boot works again after removing the memorycard, I'm unsure why it worked before (with a small led-blink on startup), but if I make the delay after the blink (in boot() ) long enough to have enough time to remove the SD card, the camera starts showing strange behaviour, possibly/probably caused by a timer expiring somewhere... when I turn on my camera, I get the delay and the reboot, as expected (I run the code which is called directly after the 'second' subroutine, the one which is called from sub_????000C, sub_????01B8 in my firmware, and I jump to the rebootcode (or 0xFF810000, doesn't matter) afterwards). Though, when I remove my SD card while the led is still lit, it stops working? It doesn't respond to any keys anymore, while it should actually reboot itself. Even more, if I insert the SD card again, it starts blinking again? I can even recompile the code for another LED, upload that onto the SD and feed it to my camera, it'll blink the other LED. What I notice is, shortly after removing the SD card (so, after the delay has ended), the camera emits a very subtle *tick* noise, it also does that when starting the camera into display mode with no memory card inserted or when turning it off.
Anyway, if I insert a non-bootable SD card in my camera, nothing happens, but if I wait a bit longer before inserting it, the display quickly shows the bootup logo and turns off again. At that point I cannot turn the camera on, with or without non-bootable memory card. If I insert the bootable card again, it'll resume blinking *after* I turn it on again. Very strange. I uploaded two short movies so you can see what I'm talking about 😀

http://stack.dataghost.com/07012008069.mp4 Camera reboots though refuses to run it's own code
http://stack.dataghost.com/07012008070.mp4 Camera goes through a fairly complete initialization, LCD blinks for an instant and it refuses to do anything until I insert my bootdisk again and turn it on.

Oh and grrrr.. for some reason, 'it works again'? I tried shortening the loop while my camera was rebooting itself, it didn't continue (sometimes it doesn't continue :p ), so I cut off the power and turned it on again... it rebooted quickly as expected, it booted into display mode when I removed the memorycard, as expected... so I undid my change to the source and compiled it again to have my initial program back and now it does go into display mode when I remove the card 😐

edit: Never mind, forget this. My camera asked me to change the batteries when I turned it on in picture mode, so I turned it off, started display mode and went to picture mode without a problem... I could also enter picture mode again afterwards... turns out that my battery-construction is crappy (hey, it's just cardboard), the power is sometimes interrupted for a very short time when I touch it right around the SD card area, the thing I'm constantly touching with my thumb. I'm going to build a new one now 😀

jeff666

DDMan wrote:
I wanted to try your current status with my A720 firmware 1.00c but I think I am a little bit too fast.
I copied the diskboot.bin and the .fir file from the bin folder of your zip on to the root folder of my SD card. But when I start my cam in play mode there is no option to update and therefore start CHDK. 😐:

The "traditional" method to start CHDK doesn't work with DryOS since it doesn't have the "Firm Update" Menu. Well, actually it seems like "Firm Update" is still there, but we don't know what enables it, yet.

To start CHDK in a DryOS-Cam you need to make your card "bootable" (see: http://chdk.wikia.com/wiki/Bootable_SD_card, the article also talks about "blinking" - just ignore that). If the card lock is set, the camera will try to load "diskboot.bin" on startup, thus starting CHDK if it is on the card. Forget about the .FIR-file. You just need "diskboot.bin"

Be warned about the lack of features. It still doesn't do much and is "not cool" for most users (it is for developers, though 😁). Nice features (like raw-support and NR-suppression, which are basically the only features) will be available after I figure out how "task_CaptSeqTask" works.

Cheers.

DDMan

Thanks, Jeff! You're the man! Works fine 😉

Hope to see more of your work. Will gladly test it. 😉

So which features are implemented by now? 😁

Cheers

« Previous Page Next Page »