G9 porting progress

bitdivision

14

Re: G9 porting progress

« Reply #30 on: 25 / September / 2008, 17:59:00 »

Advertisements

Thank you reyalp, much clearer now.
So I assume from that wiki page that when I build with the firmware in there as PRIMARY.BIN, it will try to find signatures and generate stubs_entry.S? In which case I have generated them.
So I will need to go through those stubs and the ones in stubs_entry_2.S and check to see if the functions look right for 100h since my camera bricks. This could take a while....

Thanks again for your help

Logged

bitdivision

14

Re: G9 porting progress

« Reply #31 on: 25 / September / 2008, 18:21:52 »

OK, worked out one of the problems I've been having, the ND Filter thing. Uvvv obviously was making changes to the stubs_entry.S file and not the stubs_entry_2.S file, therefore, when I first built it for 1.00h and placed the correct primary.bin in there, it regenerated the signatures and lost all of the changes uvv had made!!!

Logged

Supernovah

31

Re: G9 porting progress

« Reply #32 on: 25 / September / 2008, 21:08:59 »

Wait so is CHDK 100% ported?

Logged

bitdivision

14

Re: G9 porting progress

« Reply #33 on: 26 / September / 2008, 06:08:23 »

Supernovah,
Not sure but I think there are still some bugs.

Reyalp or others,
I am going to go through everything in the stubs (1 and 2) tonight and also boot.c and lib.c. I'm not sure what I should be looking for in boot and lib though. Like at the beginning of the boot() function in boot.c, there is:

Code: [Select]

    long *canon_data_src = (void*)0xFFB2E3F4; // OK	//canon_data_src!!!  @FF810130
    long *canon_data_dst = (void*)0x1900;	// OK  //MEMBASEADDR   @FF810134
    long canon_data_len = 0x140E4- 0x1900; // data_end - data_start     
    long *canon_bss_start = (void*)0x140e4; // just after data 	// OK	//@FF810138
    long canon_bss_len = 0xb0b68 - 0x140e4; //  MEMISOSTART -

Presumably these adresses refer to the firmware on the camera once it has been loaded? do I need to change these? What are the most likely problems that would stop the camera booting but still flash the blue led once?

Sorry for all the questions.

« Last Edit: 26 / September / 2008, 07:17:09 by bitdivision »

Logged

bongo_bingo

167

Re: G9 porting progress

« Reply #34 on: 26 / September / 2008, 12:22:42 »

Hello,
I've compiled for the 100f.

There are some problems I have found:

- jogdial doesn't work
- zebra (which displays unusefull mask),
- video options not applied,
- the only working override is the shutter speed,
- raw doesn't work,
- scripts are loaded and seems to be executed but no jpg are produced,
- grids doesn't work.

I compiled the src for the 100g putting the 100f primary.bin in the directory, and modifying few addresses in stubs_entry_2.S

100f.zip (31.55 kB - downloaded 80 times.)

Logged

reyalp

14003

Re: G9 porting progress

« Reply #35 on: 26 / September / 2008, 16:58:59 »

Quote from: bitdivision on 26 / September / 2008, 06:08:23

Reyalp or others,
I am going to go through everything in the stubs (1 and 2) tonight and also boot.c and lib.c. I'm not sure what I should be looking for in boot and lib though. Like at the beginning of the boot() function in boot.c, there is:

Code: [Select]
long *canon_data_src = (void*)0xFFB2E3F4; // OK //canon_data_src!!! @FF810130 long *canon_data_dst = (void*)0x1900; // OK //MEMBASEADDR @FF810134 long canon_data_len = 0x140E4- 0x1900; // data_end - data_start long *canon_bss_start = (void*)0x140e4; // just after data // OK //@FF810138 long canon_bss_len = 0xb0b68 - 0x140e4; // MEMISOSTART -

Presumably these adresses refer to the firmware on the camera once it has been loaded?

Yes, you need to have the right values for your camera. Look at the first function in firmware (starting with the B at the beginning of ROM). After it plays with P15 for a while, it copies some data from ROM, and then zeros a chunk of memory after that. You want to find the values so your code can do the equivalent. BSS is the zeroed chunk.

The a590 thread has some related information.

Logged

Don't forget what the H stands for.

bitdivision

14

Re: G9 porting progress

« Reply #36 on: 27 / September / 2008, 13:16:28 »

I think I need a hand here...

I'm going through boot.c and checking where the camera is crashing using the leds. I have found the point at which it crashes but I don't have a clue how to fix it...
I have attached my boot.c. The line which crashes is 233. I can see some compares in that sub called and then a couple of DryOSPanic calls which I guess is what's happening but I'm not sure why. Can someone take a look please?
On another note, I've gone through all the stubs and checked/changed them against 1.00h so things are progressing very slowly....

Cheers

boot.c (66.04 kB - downloaded 88 times.)

Logged

reyalp

14003

Re: G9 porting progress

« Reply #37 on: 27 / September / 2008, 15:37:21 »

I gather this was discussed and resolved on IRC, but it's an important point a lot of people don't seem to realize offhand:
you can't just throw C function call (whether as a BL in the asm, or outside) somewhere in the canon asm and expect it to work.

GCC assumes you are adhering to some variant of the arm calling convention, which leave subroutines free to modify r0-r3 and the flags register (or return a value in r0 and modify the rest). See "Using the Procedure Call Standard" in http://infocenter.arm.com/help/topic/com.arm.doc.dui0056d/DUI0056.pdf

This means that when you do something like

Code: [Select]

...
                "MOV     R0, SP\n"
                "MOV     R2, #0\n"
                               				);
				d_my_blink_green(); //6
...

You are going to get in trouble.

There are several ways you can avoid this:
- write your sub in ASM (or with ASM that saves and restores the regs that gcc doesn't do automatically)
- place your call somewhere that you know it won't have undesired side effects. This is what most of the CHDK code does. Typically, if you call your function directly after an existing subroutine call, the firmware code already assumes r1-r3 are trashed, and you can preserve r0 by making your code accept one argument and return it unchanged.

Somewhat related, there are GCC inline asm features that let your inform the compiler about what registers are changed etc ARM GCC Inline Assembler Cookbook

Logged

Don't forget what the H stands for.

bitdivision

14

Re: G9 porting progress

« Reply #38 on: 27 / September / 2008, 19:24:54 »

Thanks for clarifying that stuff Reyalp.

I've gone through boot.c and all the stubs and it all seems to be OK. It seems to reach the end of boot.c and doesn't crash but the lcd doesn't do anything. I set up the led_blinker task for fun and it seems to only blink twice before stopping, not sure what this means... Anyone have any ideas?

I've attached my boot.c if its any help. Only other thing I can think of is that when I build it I get this warning:

Code: [Select]

boot.c: In function `_time':
boot.c:1697: warning: control reaches end of non-void function

But I don't think that _time gets called anywhere within boot.c so that should be ok shouldn't it?

Cheers

edit: attached platform dir

boot.c (65.58 kB - downloaded 78 times.)

100h.zip (106.67 kB - downloaded 79 times.)

« Last Edit: 27 / September / 2008, 20:17:03 by bitdivision »

Logged

bitdivision

14

Re: G9 porting progress

« Reply #39 on: 28 / September / 2008, 08:29:03 »

Well, finally, after some more changes to boot.c, I get the boot screen! So far I can't do anything and the chdk logo stays on the screen but its some progress....
Since there are a couple of people working on this now, ReyalP suggested I set up a space on assembla for it. The Svn URL is Revision 2: / and if you want to browse it then go to / - chdk-G9 - Trac. I don't quite know how assembla works since this is the first time I've used it but I think if you register and then request to join the team for chdk_G9, I should be able to give you dev access.

Thanks again ReyalP for all the help.

Logged