SX260 HS Porting Thread - page 10 - DryOS Development - CHDK Forum

SX260 HS Porting Thread

  • 642 Replies
  • 222967 Views
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX260 HS Porting Thread
« Reply #90 on: 17 / April / 2012, 14:07:29 »
Advertisements
addded #define CAM_DETECT_SCREEN_ERASE  1

and the crash is the same, but the romlog includes at the end

Code: [Select]
00000980: UI:Window MuteOff
00000980: UI:MuteOffPhysicalScreen
00000980: UI:DisplayPhysicalScreenCBR
00001190: UI:LogicalEvent:0x666f:adr:0,Para:0
00001310: UI:Button:0x0000085E:PressSetButton
00001310: UI:LogicalEvent:0x320b:adr:0,Para:0
00001310: UI:PB.DPOF
00001310: UI:DSIC:48,0
00001310: UI:PB.Check
00001520: UI:Button:0x0000085F:UnpressSetButton

So will have to check all the boot process to see what's wrong

EDIT:

1.- Even If I comment out all the core_spytask() get the same romlog error.
« Last Edit: 17 / April / 2012, 14:34:50 by asm1989 »

*

Offline srsa_4c

  • ******
  • 4451
Re: SX260 HS Porting Thread
« Reply #91 on: 18 / April / 2012, 16:56:34 »
About your romlog: it's not an assert, it happens at a lower level (kernel?, interrupt?), the task shown may not be directly related.
Look at the addresses of the stack, some of those might give a clue (see also core/main.dump).

Also, don't forget, a large piece of Canon's code is now in RAM, so you could modify some of that (for example CreateTask) instead of using the usual task hook code. But you need to sort out the booting issue first, of course

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX260 HS Porting Thread
« Reply #92 on: 19 / April / 2012, 00:41:04 »
Thanks srsa_4c

Yes looks like interrupt, The addresses at the stack point to a video related fuction called at some point at boot time in our function   task_Startup_my,

But it seams to be something trigered,  I have been testinting enabling and disabling code with no results,

so I may have wrong some of the stubs.

I have for sure wrong the led address, but I don't think its related.

I think that the key is here
Code: [Select]
LogicalEvent:0x666f:....
If I search in the firm for "0x666f" points to a sub FF04B9C0  called by:
- The Gps Task 6 times
- Other sub related to "MTK.c"

So maybe I have left unimplemented something, but used sx230 with gps as a startpoint??

*

Offline reyalp

  • ******
  • 14117
Re: SX260 HS Porting Thread
« Reply #93 on: 19 / April / 2012, 00:42:04 »
About your romlog: it's not an assert, it happens at a lower level (kernel?, interrupt?), the task shown may not be directly related.
Exception, from invalid memory address
Quote
Look at the addresses of the stack, some of those might give a clue (see also core/main.dump).
Since it's an exception, you also have all the registers. PC and LR are good to look at

PC: 0xFF1405D4
LR: 0x00685FA4

Code: [Select]
ROM:FF1405D0                 LDR     R1, =0xD02C3000
ROM:FF1405D4                 STR     R0, [R1]
Which is interesting, 0xD0000000 appears to be a new memory region
Don't forget what the H stands for.


*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX260 HS Porting Thread
« Reply #94 on: 19 / April / 2012, 00:47:06 »
@reyalp

I have also tested exmem with the same results It shows chdk logo but fails with the same romlog.

The 0x006.... ar the n subs the new cams, starting with sx260 load in RAM, so we may have to deal with it anyway at boot.c

Most of the fuctions loaded in ram are irq related.

No clue about the new memory region.

*

Offline reyalp

  • ******
  • 14117
Re: SX260 HS Porting Thread
« Reply #95 on: 19 / April / 2012, 00:49:10 »
One thought, the instruction above is an address hard coded in the firmware. Normally, when you get an 0x10, it means you got some random value in a pointer, but that doesn't seem to be the case here.

This might imply the memory regions aren't being setup correctly.
Don't forget what the H stands for.

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX260 HS Porting Thread
« Reply #96 on: 19 / April / 2012, 00:56:58 »
Quote
This might imply the memory regions aren't being setup correctly.

You mean other than the makefile.inc , I have double checked all the video realaed and seems ok.

I'm also not so sure about this at boot.c, but seams to work:

Code: [Select]
  *(int*)0x1938=(int)taskHook;    //Bigger Hang asm1989 Apr2012
   *(int*)0x193C=(int)taskHook;   //lesser Hang

//SX230: Power-on FF00FCCC+FF056DB4  ->   0xC022012C) & 1
//SX260:  FF00B23C   +    FF04D3EC  -> Must be verified


if ((*(int*) 0xC022C30C) & 1)               //asm1989 FF00B23C -> 0xC022C000 + 0x30C not sure ??  ,  look at play switch
        *(int*)(0x2618+0x4) = 0x200000;         // asm1989 0x2618 @ FF04D3EC - not pressed - start in rec mode
    else
        *(int*)(0x2618+0x4) = 0x100000;         // power pressed - start in play mode
« Last Edit: 19 / April / 2012, 00:58:52 by asm1989 »

*

Offline reyalp

  • ******
  • 14117
Re: SX260 HS Porting Thread
« Reply #97 on: 19 / April / 2012, 01:20:08 »
The protection regions are set up in boot.c boot()

This looks OK to me, but I haven't gone through it line by line.
Don't forget what the H stands for.


*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX260 HS Porting Thread
« Reply #98 on: 20 / April / 2012, 03:18:46 »
The diference between sx260 & s100 the closest cam by date in boot() is

Code: [Select]
        "LDR     R0, =0xFF680924\n"
        "LDR     R1, =0x685000\n"
        "LDR     R3, =0x69544C\n"

Don't know if the 0x6...  are numbers or functions in ram too , in fact at 00685000 there is a sub, and 0069544C seams to be out the copied ram range.

So maybe the key changes are ther or in the sub sub_FF682878 with stuff related to firmware

any clue? ???

PD: Seems to be not related to the crash, since even disabling the 3 lines the crash is the same

« Last Edit: 20 / April / 2012, 06:27:24 by asm1989 »

*

Offline srsa_4c

  • ******
  • 4451
Re: SX260 HS Porting Thread
« Reply #99 on: 20 / April / 2012, 06:32:50 »
Don't know if the 0x6...  are numbers or functions in ram too , in fact at 00685000 there is a sub, and 0069544C seams to be out the copied ram range.
If you're unsure about the RAM, you should be able to dump (a part) of it with a modified Canon Basic dumper.

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal