Eos 400d ( Rebel XTI ) - page 173 - DSLR Hack development - CHDK Forum
« previous next »
Pages: 1 ... 168 169 170 171 172 [173] 174 175 176 177 178 ... 188   Go Down

Eos 400d ( Rebel XTI )

  • 1871 Replies
  • 887290 Views
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1720 on: 17 / April / 2013, 14:57:10 »
Advertisements
Quote from: Sergei on 17 / April / 2013, 10:44:38
  I got rid of ASM code in entry.S but can't convert entry.S to entry.c. Missing GCC flags ?
Quote
ld: error: stubs.o uses hardware FP, whereas AUTOEXEC.arm.elf uses software FP
ld: failed to merge target specific data of file stubs.o
Here is the source code:
http://hostr.co/QaDx9TNOxlTi

yeah, sounds like a toolchain problems...
try adding these to CFLAGS
-mfpu=fpa
-msoft-float
-mfloat-abi=soft

and see if it's working...

you can try to put an entry.S with similar code:
Code: [Select]
      .text
      .org 0
      .globl _start, start
  start:
  _start:
LDR     PC, =my_romStart
only this code ... and see if the linker will give errors again...

it's very strange that after removing the entry object file (entry.o) from the linker, it gives strange FPU related errors...


EDIT:
dont forget to "make clean" before compiling ... you can even check if all .o files are removed and remove them just in case (rm *.o)
Logged
// AF
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1721 on: 17 / April / 2013, 16:05:13 »
    When I have entry.S and ASM code in it, it compiles with no problem.
Code: [Select]
    .text
    .org 0
    .globl _start, start

start:
_start:
BL      EnableHacks
.align 2
fin:But it will not compile if I change file to entry.c and put C code in it:
Code: [Select]
void start()
{  EnableHacks();
}
I had -msoft-float enabled.
Other two, -mfpu=fpa and -mfloat-abi=soft, gives me errors.
Quote
cc1: error: invalid option `fpu=fpa'
cc1: error: invalid option `float-abi=soft'
Logged
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1722 on: 17 / April / 2013, 17:10:39 »
I tried to compile it using the "Makefile" and "link.script" files from 400plus (just copied the latest files from our repository), and it compiles with no alarming warnings; but when I tried it on the camera, the blue LED switches on and then the camera locks...

EDIT: Pardon my ignorance, but there was some code in entry.S that I do not see anywhere, now; where have you moved that? or was it unnecessary? Thanks!
« Last Edit: 17 / April / 2013, 17:16:44 by eduperez »
Logged
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1723 on: 17 / April / 2013, 18:06:30 »
  This source code will compile with no problems and works on my camera.
Quote from: Sergei on 17 / April / 2013, 10:44:38
http://hostr.co/QaDx9TNOxlTi
It was a problem when I was renaming entry.S to entry.c. I think "entry.S" and "_start:" are keywords in ASM for program entry point. So it can't be changed.
  All that code in "entry.S" we used to have is gone. "entry.S" now just executes EnableHacks(), which executes cache-hacks, relocates AUTOEXEC in RAM and jumps to original firmware.
 
Logged
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1724 on: 18 / April / 2013, 03:18:13 »
Quote from: eduperez on 17 / April / 2013, 17:10:39
I tried to compile it using the "Makefile" and "link.script" files from 400plus (just copied the latest files from our repository), and it compiles with no alarming warnings; but when I tried it on the camera, the blue LED switches on and then the camera locks...

EDIT: Pardon my ignorance, but there was some code in entry.S that I do not see anywhere, now; where have you moved that? or was it unnecessary? Thanks!

Probably you forgot to call COPY() in the C code, after removing the entry.S ?
Logged
// AF
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1725 on: 18 / April / 2013, 03:34:22 »
Quote from: Sergei on 17 / April / 2013, 18:06:30
It was a problem when I was renaming entry.S to entry.c. I think "entry.S" and "_start:" are keywords in ASM for program entry point. So it can't be changed.
  All that code in "entry.S" we used to have is gone. "entry.S" now just executes EnableHacks(), which executes cache-hacks, relocates AUTOEXEC in RAM and jumps to original firmware.

entry.S is not a special file and _start is not special word. The _start is by default, since you have not specified another name.
I tried to compile our code w/o entry.S and it compiles.

You should try to change your link.script and LDFLAGS line (or the linking line) in makefile too...

change your linking line in makefile which is now:
Code: [Select]
$(CC) $(CFLAGS) -Wl,-T,link.script -o$@ $^
to look like this:
Code: [Select]
$(CC) $(CFLAGS) -Wl,-T,link.script -e EnableHacks -o$@ $^

you can remove this line from makefile too:
Code: [Select]
entry.o:entry.S

and change your link.script...
remove the entry.o from the file, and put init.o in the first place (where entry.o was)


you should be able to compile it without the entry.S at all...
Logged
// AF
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1726 on: 18 / April / 2013, 09:12:46 »
Quote from: 0xAF on 18 / April / 2013, 03:18:13
Quote from: eduperez on 17 / April / 2013, 17:10:39
I tried to compile it using the "Makefile" and "link.script" files from 400plus (just copied the latest files from our repository), and it compiles with no alarming warnings; but when I tried it on the camera, the blue LED switches on and then the camera locks...

EDIT: Pardon my ignorance, but there was some code in entry.S that I do not see anywhere, now; where have you moved that? or was it unnecessary? Thanks!

Probably you forgot to call COPY() in the C code, after removing the entry.S ?
I renamed COPY() to RelocateAutoexec().
Eduperez, can you compile my code with original "Makefile" and "link.script" files? Does it works?

Quote from: 0xAF on 18 / April / 2013, 03:34:22
Quote from: Sergei on 17 / April / 2013, 18:06:30
It was a problem when I was renaming entry.S to entry.c. I think "entry.S" and "_start:" are keywords in ASM for program entry point. So it can't be changed.
  All that code in "entry.S" we used to have is gone. "entry.S" now just executes EnableHacks(), which executes cache-hacks, relocates AUTOEXEC in RAM and jumps to original firmware.

entry.S is not a special file and _start is not special word. The _start is by default, since you have not specified another name.
I tried to compile our code w/o entry.S and it compiles.

You should try to change your link.script and LDFLAGS line (or the linking line) in makefile too...

change your linking line in makefile which is now:
Code: [Select]
$(CC) $(CFLAGS) -Wl,-T,link.script -o$@ $^
to look like this:
Code: [Select]
$(CC) $(CFLAGS) -Wl,-T,link.script -e EnableHacks -o$@ $^

you can remove this line from makefile too:
Code: [Select]
entry.o:entry.S

and change your link.script...
remove the entry.o from the file, and put init.o in the first place (where entry.o was)


you should be able to compile it without the entry.S at all...

It compiles without entry.S and with "$(CC) $(CFLAGS) -Wl,-T,link.script -e EnableHacks -o$@ $^" but camera will not execute it.
I think I get errors like "ld: error: stubs.o uses hardware FP, whereas AUTOEXEC.arm.elf uses software FP" only when I put any C code in front of ASM code (stubs.S). So I will leave entry.S for entry point.
« Last Edit: 18 / April / 2013, 09:26:16 by Sergei »
Logged
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1727 on: 18 / April / 2013, 11:43:31 »
Quote from: Sergei on 18 / April / 2013, 09:12:46
I renamed COPY() to RelocateAutoexec().
Eduperez, can you compile my code with original "Makefile" and "link.script" files? Does it works?

No, it doesn't; I just get the same errors as you.

About the entry point: AFAIK, after the camera loads our AUTOEXEC.BIN file into memory, it jumps into a fixed address inside that file; so whatever the entry point is called, it must be in a fixed address inside the AUTOEXEC.BIN file. Before the cache-hack stuff, we achieved this by putting the entry function at the beginning of the entry.S file, and putting entry.o at the beginning of the link.script. Do you know whether the "-e" parameter works like this?
Logged
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1728 on: 19 / April / 2013, 03:03:02 »
Quote from: eduperez on 18 / April / 2013, 11:43:31
No, it doesn't; I just get the same errors as you.

About the entry point: AFAIK, after the camera loads our AUTOEXEC.BIN file into memory, it jumps into a fixed address inside that file; so whatever the entry point is called, it must be in a fixed address inside the AUTOEXEC.BIN file. Before the cache-hack stuff, we achieved this by putting the entry function at the beginning of the entry.S file, and putting entry.o at the beginning of the link.script. Do you know whether the "-e" parameter works like this?

good point, im not sure -e parameter will relocate some routine to our address ... it probably wont... but i will try to objdumping something to see what goes where ...
we now need a way to instruct the linker that our new C entry routine needs to be placed at our starting address and it will work without the entry.S
Logged
// AF
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1729 on: 19 / April / 2013, 04:31:03 »
Quote from: 0xAF on 19 / April / 2013, 03:03:02
good point, im not sure -e parameter will relocate some routine to our address ... it probably wont... but i will try to objdumping something to see what goes where ...
we now need a way to instruct the linker that our new C entry routine needs to be placed at our starting address and it will work without the entry.S

My only interest to get rid of entry.S was to eliminate all traces of any code that could be suspicious of being remotely derived from code written by others... if you know what I mean. Sergei did most of that job, when he applied the cache hack; but there were some lines in the entry.S file, that I did not know where had originated, and thus my question.

Obviously, an ASM file with a single jump is perfectly fine with respect to my concerns; not as clean as having some "main" function in a C file, but completely safe. Once we have reached this point, I would not spend much time on the issue.
Logged
Pages: 1 ... 168 169 170 171 172 [173] 174 175 176 177 178 ... 188   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal