Eos 400d ( Rebel XTI )

eduperez

And... we have new version!

Sergei

eduperez
And... we have new version!

That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

0xAF

Edu, thanks for the great job on the release !
A lot of new stuff 😀

Sergei
That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

Very good, thanks !
I feel a bit shamed now 😀

Anyway, have you got the chance to trace all the spots where the Cache is cleared.
I mean, if we hijack some routines at later point of execution, i.e. the Transfer_to_VRAM function (it's just an example, not that we need to hijack it with cache hacks), would it be cleared at some point later ?

My ultimate goal with cache hacks was to port the whole booting procedure (like in ML), so our entry point is one routine that just uses cache-hacks and hijacks all cache-clearing routines, then hijack some init routine to start our code.
If we have this, then we get rid of all copied code from canon.

p.s.
Great job, cache-hacks will give us great powers, thanks to you (for porting them) and to g3gg0 for the idea and implementation in first place!

Sergei

Firmware clears caches somewhere in vmBaseGlobalMapInit() at startup. I didn't look too deep in that function. Just disabled it for now. Everything works. I'm using cache hacks to modify original boot process, so no more long copies of code.
Thanks, 0xAF!

eduperez

Sergei

eduperez
And... we have new version!

That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

"Usable in 400plus", you ask? Dear God, that's a gold mine! I just had a look at your code, and you did a fantastic job with the initialization, I liked it very much; it's very clean and smooth now, congratulations.

Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.

Thank you very much!

0xAF

eduperez
Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.

May be with the cache hacks, now we can skip the ASM part.
We may link our entry point to the COPY() routine directly, then from the copy call the EnableCacheHacks() which will do the hijcks, then call the original entry point.

Sergei

Looks like it is possible. I will check on it when I get time.

Sergei

eduperez
Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.

I got rid of ASM code in entry.S but can't convert entry.S to entry.c. Missing GCC flags ?

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

0xAF

Sergei
I got rid of ASM code in entry.S but can't convert entry.S to entry.c. Missing GCC flags ?

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:

      .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)

Sergei

When I have entry.S and ASM code in it, it compiles with no problem.

    .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:

void start()
{  EnableHacks();
}

I had -msoft-float enabled.
Other two, -mfpu=fpa and -mfloat-abi=soft, gives me errors.

cc1: error: invalid option `fpu=fpa'
cc1: error: invalid option `float-abi=soft'

eduperez

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!

Sergei

This source code will compile with no problems and works on my camera.

Sergei
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.

0xAF

eduperez
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 ?

0xAF

Sergei
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:

$(CC) $(CFLAGS) -Wl,-T,link.script -o$@ $^

to look like this:

$(CC) $(CFLAGS) -Wl,-T,link.script -e EnableHacks -o$@ $^

you can remove this line from makefile too:

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...

Sergei

0xAF

eduperez
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?

0xAF

Sergei
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]
$(CC) $(CFLAGS) -Wl,-T,link.script -o$@ $^
[/code]
to look like this:
[code]
$(CC) $(CFLAGS) -Wl,-T,link.script -e EnableHacks -o$@ $^
[/code]

you can remove this line from makefile too:
[code]
entry.o:entry.S
[/code]

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.

eduperez

Sergei
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?

0xAF

eduperez
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

eduperez

0xAF
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.

0xAF

eduperez
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.

Actually, the entry.S that we have so far had nothing to do with other's code 😉
The problem is that we have C code that is not hard to recognize who wrote it... 😀
But that can be changed too ... with not so much effort, we can get rid of these parts and hookup our code with cache-hacks.

Sergei

I think if we convert stubs.S to c code we probably can get rid of entry.S and have our "start" function in C.

« Previous Page Next Page »