s80 anybody? - page 8 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 3 4 5 6 7 [8] 9 10 11 12 13 ... 21   Go Down

s80 anybody?

  • 205 Replies
  • 94960 Views
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #70 on: 01 / November / 2009, 22:33:04 »
Advertisements
So where should I look if I've reached the end of h_usrRoot()? Currently the last few lines of my h_usrRoot are:

    //_taskCreateHookAdd(createHook);
    //_taskDeleteHookAdd(deleteHook);

    drv_self_hide();

 *((volatile int*) 0xc0220088) = 0x46; // turn on LED

    asm volatile (
   "LDMFD   SP!, {R4,R5,LR}\n"
   "B       sub_FF811370\n"
    );

As is, the diskboot method works (it functions normally since the task hooks are commented out), but the fw update method just blinks the led and then the camera turns off. Maybe I should copy and past sub_FF811370 from the firmware dump to see what's going on next?
Logged
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #71 on: 01 / November / 2009, 22:34:35 »
[admin: avoid swearing please], im stupid, I thought h_usrRoot is the last thing to be executed. just found im wrong. i will continue investigating.
Logged
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #72 on: 01 / November / 2009, 22:43:44 »
OK, I found that the fw update method died when executing
"BL      sub_FFB10A78\n"
which is the kernelInit function. But still haven't figured out why.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: s80 anybody?
« Reply #73 on: 01 / November / 2009, 22:44:38 »
Quote from: revivery on 01 / November / 2009, 22:34:35
[admin: avoid swearing please], im stupid, I thought h_usrRoot is the last thing to be executed. just found im wrong. i will continue investigating.
You can also try jumping back into the canon firmware earlier. Since you are loading manually, you don't need drv_self_hide to prevent a bootloop.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: s80 anybody?
« Reply #74 on: 01 / November / 2009, 22:48:31 »
Quote from: revivery on 01 / November / 2009, 22:43:44
OK, I found that the fw update method died when executing
"BL      sub_FFB10A78\n"
which is the kernelInit function. But still haven't figured out why.
Be careful, you can't just stick
Code: [Select]
*((volatile int*) 0xc0220088) = 0x46; // turn on LEDanywhere between some random asm statements. It may trash random registers, causing a new crash.

I'd suggest doing it in asm and keeping track of the registers yourself.
Logged
Don't forget what the H stands for.
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #75 on: 01 / November / 2009, 22:52:48 »
Right, good reminder.
Logged
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #76 on: 02 / November / 2009, 00:43:41 »
Since the kernelInit function seems to be causing the trouble, I made my own version:

    "BL  sub_FFB10A78_my\n" // kernelInit
...
void __attribute__((naked,noinline)) sub_FFB10A78_my() {

and then I basically copy pasted the assembly code from the fw dump to fill it ill. Sadly, now neither diskboot nor fw update works. I did locate the problem, which is during calling
    "BL  0xFFB13C50\n"  // j_taskResume

Here are my questions: first of all, am I doing the right thing by making my own version of the kernelInit function? Since it's basically a copy of the assembly code, I assume it would work. But perhaps I need to offset the addresses?? Second, any idea what j_taskResume is doing?
Logged
*

Offline reyalp

  • ******
  • 14080
Re: s80 anybody?
« Reply #77 on: 02 / November / 2009, 00:58:39 »
Quote from: revivery on 02 / November / 2009, 00:43:41
   "BL  0xFFB13C50\n"  // j_taskResume
This is wrong. You cannot BL to an arbitrary address. You should do BL sub_FFB13C50 which will cause the CHDK build process to generate the appropriate veneer for you in stubs_auto.S

Or roll your own with
Code: [Select]
MOV LR,PC
LDR PC,=FFB13C50

You shouldn't need to copy any more of that function.

edit:
the assembler accepts BL <constant> because it can interpret it as a PC relative offset, but it doesn't do what you want, and doesn't have the range to jump from RAM to ROM.
« Last Edit: 02 / November / 2009, 01:01:20 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #78 on: 02 / November / 2009, 01:04:23 »
Btw, I also verified that the SD_READONLY_FLAG should be 0x20000 and that bit is stored in physw_status[2]. This is verified by reading through sub_FF82737C (kbd_read_keys_r2). Also, if I disable the part of the code in kbd.c that manipulates the readonly bit, the osd debug shows that physw_status[2] is 0x4020005f, so I think this is correct.
Logged
*

Offline revivery

  • *
  • 46
Re: s80 anybody?
« Reply #79 on: 02 / November / 2009, 01:06:07 »
Quote from: reyalp on 02 / November / 2009, 00:58:39
Quote from: revivery on 02 / November / 2009, 00:43:41
    "BL  0xFFB13C50\n"  // j_taskResume
This is wrong. You cannot BL to an arbitrary address. You should do BL sub_FFB13C50 which will cause the CHDK build process to generate the appropriate veneer for you in stubs_auto.S

Or roll your own with
Code: [Select]
MOV LR,PC
LDR PC,=FFB13C50

You shouldn't need to copy any more of that function.

edit:
the assembler accepts BL <constant> because it can interpret it as a PC relative offset, but it doesn't do what you want, and doesn't have the range to jump from RAM to ROM.

Sigh, how could I have forgotten about it... I even read this in another thread...
Logged
Pages: 1 ... 3 4 5 6 7 [8] 9 10 11 12 13 ... 21   Go Up
« previous next »
 

Related Topics