A580 porting - minor progress - page 4 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 ... 13   Go Down

A580 porting - minor progress

  • 125 Replies
  • 60152 Views
*

Offline mariush

  • **
  • 63
Re: A580 porting - minor progress
« Reply #30 on: 25 / January / 2009, 21:04:33 »
Advertisements
Just a quick note to say thank you guys, reyalp, fudgey, whim and the rest...  I'm sorry to see you feel I'm not reading and feel I'm just asking for stuff... I actually try very hard to understand things before I ask and I really did read that wiki page about 10-15 times before I asked for confirmation.

I guess it's just the difficult to understand due to us not being native english speakers, some phrases in the wiki are hard to comprehend and the "train of thought" is difficult to follow.

For you guys, it's probably very clear what it says, but that's probably just because you did those things lots of time. This happened to me lots of times and I often had to stand back and ask other people to read the documentation I write to provide feedback so that I can make it easier for everybody.

Rest assured I appreciate all your help and I keep trying to port this camera but it takes a long time because I have to earn a living in real life.

Thanks again, guys.
Logged
*

Offline mariush

  • **
  • 63
Re: A580 porting - minor progress
« Reply #31 on: 03 / February / 2009, 12:35:01 »
I went through the Makefile's and realized I need both firmwares (a720 and 1100) in the tools folder as sig_ref_dryos_1.bin and sig_ref_dryos_2.bin.
Someone should correct the line in the makefile to say BOTH .bin files must not be empty, not only the first one, that's what confused me in the first place:

Code: [Select]
if [ -s sig_ref_dryos_1.bin ] && [ -s sig_ref_dryos_2.bin ] ; then \
  $(SH) ./gensigs.sh $(SORT) dryos "1 2" > signatures_dryos.h ; \
else \
  echo CAUTION! \'signatures_dryos.h\' is not updated due to \'sig_ref_dryos_1.bin\` is empty! ; \
  touch signatures_dryos.h ; \
fi

Ok, sorted the problem, but now I have another problem.
When I run gmake to compile everything, sh crashes with an error when running gensig, saying "The instruction at "0x00446539" referenced memory at "0xfd000000". The memory could not be "read".

I think the command line is: c:\gcc346\bin\sh ./gensigs.sh c:/gcc346/bin//sort.exe dryos "1 2"
where the working folder is tools.

Seems weird that there's sort.exe in the parameter, especially with two "/" in the file name but maybe it's a linux thing.

The resulted "signatures_dryos.h" is :

Code: [Select]
FuncsList func_list[] = {
{ "AllocateMemory", func_sig_AllocateMemory_1 },
{ "AllocateMemory", func_sig_AllocateMemory_2 },
{ "AllocateUncacheableMemory", func_sig_AllocateUncacheableMemory_1 },
[...]
{ "vsprintf", func_sig_vsprintf_1 },
{ "write", func_sig_write_1 },
{ NULL }
};


which is just like the ending of signatures_dryos.h in the svn repository. Does this mean that it crashes after everything's done?

Could I avoid this process altogether and just find the hex values manually for all the functions if it wouldn't take forever?

I'm running Windows 2003 as I said, I tried setting sh.exe in WIndows XP or WIndows 2000 compatibility mode but then it's even worse, gmake won't even clean the build properly, nevermind compiling it.
If you don't have an easy fix for this, I'll try to install Windows XP in Virtualbox and try to compile it from there...

later edit: it also crashes on fresh XP install with the same trunk

even later edit:

I modified the makefile and removed from the command to gensigs.sh the dryos_2 part, so it processes only the first file.
This way it works and sh no longer crashes.

I took the second firmware from the wikia page ixus82_sd1100_100c.zip and renamed PRIMARY.BIN to sig_ref_dryos_2.bin and also copied it as PRIMARY.BIN to the platform\ixus80_sd1100\sub\100c\PRIMARY.BIN  so this should be right. I don't understand why it crashes.

Is it enough to let it scan only the first firmware?
« Last Edit: 03 / February / 2009, 14:20:30 by mariush »
Logged
*

Offline reyalp

  • ******
  • 14079
Re: A580 porting - minor progress
« Reply #32 on: 03 / February / 2009, 22:30:02 »
passing sort.exe is normal. I suspect it was done this way to make sure it doesn't pick up the windows sort.exe

I've had issues with the shell crashing/hanging with the windows dev kit in gensigs.sh . I use the workaround described here http://chdk.setepontos.com/index.php/topic,2217.msg21085.html#msg21085 when building with sig_ref_*

I haven't checked it in, because it's not really portable and no one else seemed to be complaining about the crash problem.

Note that unless you are adding new entry points to sig_ref_*.txt, you shouldn't need to build with these in place. Just using the .h files that are in svn should be fine. finsig (which processes the primary.bin files to generate stubs_entry.S for each platform) relies on the compiled in sigs, not the reference bin.

The two slashes are probably an error (having a slash both at the end of the directory and on the filename), although I'm not sure it would cause and problem.
Logged
Don't forget what the H stands for.
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: A580 porting - minor progress
« Reply #33 on: 04 / February / 2009, 04:56:53 »
Quote
I suspect it was done this way to make sure it doesn't pick up the windows sort.exe

i don't understand how that could happen...after all, the  {path-todevkit}\gcc{ver}\bin path should
have been added to the windows PATH as: 'PATH={path-todevkit}\gcc{ver}\bin;%PATH%'

About the double slashes ewavr recently wrote this: http://chdk.setepontos.com/index.php/topic,2509.msg28660.html#msg28660

sidenote: i get 82 (!) hits when searching for '$(topdir)/'  in trunk 701 ...

i got another question though, if (see mariusz' post)  $(SORT) expands to (in his case) c:/gcc346/bin//sort.exe
why is the define for SORT in the 'makefile.inc' so complicated:
Quote
ifndef OSTYPE
  HOSTPLATFORM:=$(patsubst MINGW%,MINGW,$(shell uname -s))
  ifeq ($(HOSTPLATFORM),MINGW)
    OSTYPE = Windows
    EXE = .exe
    SH = sh
    DEVNULL = NUL
    SORT = $(dir $(shell which uniq.exe | sed s/\\\\/\\\//g))/sort.exe
i mean, given that sort.exe is in the same dir as gcc.exe, and this dir is the first searched dir in the PATH,
one could be forgiven for thinking that, in analogy of
HOSTCC = gcc
it would be OK to define sort as
SORT=sort

wim
 
BTW thanks for ref'ing this old post - i hadn't seen it before


edit: aargh ! i see it now - it's because it's passed as param, need to change '\' to '/' ....  :-[
edit2: removing the '/' before 'sort.exe' in root makefile.inc does not provoke errors on a vanilla 701 for me,
         so maybe that helps ...
« Last Edit: 04 / February / 2009, 05:43:28 by whim »
Logged
*

Offline mariush

  • **
  • 63
Re: A580 porting - minor progress
« Reply #34 on: 04 / February / 2009, 07:46:10 »
The sort.exe was running just fine even with those two / slashes in the path. It's not there the problem.
It seems to me sh.exe crashes when it processes the second sig_ref_dryos_2.bin

I edited Makefile to call gensigs only for the first bin file like this:

Code: [Select]
$(SH) ./gensigs.sh $(SORT) dryos "1" > signatures_dryos.h ;

... instead of "1 2" as it was before and it compiled just fine, without crashes.

I could just copy the .h files as you say but I guess when I compile the firmware these would be called again and modify them.
The generated signatures_dryos.h during compile is identical with the one in the SVN, except that it now no longer has as the bottom in the Function_list , the functions with _2 at the end.

The next steps I'm planning to do are:

1. finding  the hex offsets for each entry in stubs_entry.s and adding the correct values to stubs_entry_2.s and of course correcting the values in stubs_entry_2.s

2. checking stubs_min.s and correcting the values if I find out from where are those offsets obtained from

3. check lib.c and try to determine the addresses if changed (I guess these need to be correct to get something shown on the screen?)

3. reviewing platform/sub/101b/boot.c assembly code and make sure it's good

4. compile the firmware and now if all's good I should at least get something on the screen, right ?

I'm yet to determine any led addresses, so far I only managed to freeze the camera..
Logged
*

Offline reyalp

  • ******
  • 14079
Re: A580 porting - minor progress
« Reply #35 on: 04 / February / 2009, 22:57:13 »
Quote from: mariush on 04 / February / 2009, 07:46:10
The sort.exe was running just fine even with those two / slashes in the path. It's not there the problem.
It seems to me sh.exe crashes when it processes the second sig_ref_dryos_2.bin

I edited Makefile to call gensigs only for the first bin file like this:

Code: [Select]
$(SH) ./gensigs.sh $(SORT) dryos "1" > signatures_dryos.h ;

... instead of "1 2" as it was before and it compiled just fine, without crashes.

I could just copy the .h files as you say but I guess when I compile the firmware these would be called again and modify them.
Huh ? You don't need to copy them. Just don't build them in the first place. You only need to generate the .h files if you are adding entry points to sig_ref_*.txt. This is only true if you are adding new features.
Quote
The generated signatures_dryos.h during compile is identical with the one in the SVN, except that it now no longer has as the bottom in the Function_list , the functions with _2 at the end.
This is not what you want, since it means any stubs_entry.S files you generate will be different from what other developers generate.

Quote
1. finding  the hex offsets for each entry in stubs_entry.s and adding the correct values to stubs_entry_2.s and of course correcting the values in stubs_entry_2.s
stubs_entry_2.S should only contain entry points which were incorrect or not present in stubs_entry.S.

Quote
2. checking stubs_min.s and correcting the values if I find out from where are those offsets obtained from
Most of these are not essential to boot the camera, but will be needed eventually
Quote
3. check lib.c and try to determine the addresses if changed (I guess these need to be correct to get something shown on the screen?)
You need to find the bitmap buffer at a minimum. The raw and viewport aren't needed right away.

Quote
3. reviewing platform/sub/101b/boot.c assembly code and make sure it's good
Rather than trying to correct an existing boot.c, I'd suggest working from an existing port, and copying the corresponding asm directly from your firmware dump.

Quote
4. compile the firmware and now if all's good I should at least get something on the screen, right ?

I'm yet to determine any led addresses, so far I only managed to freeze the camera..
You may be better off just finding the LED addresses and blinking at various stages. Getting everything running up to the point where it can draw to the GUI will be a long shot.
Logged
Don't forget what the H stands for.
*

Offline yunxiang

  • *
  • 23
Re: A580 porting - minor progress
« Reply #36 on: 05 / February / 2009, 07:10:45 »
great thax you !!!!
my a580 is waiting ,,,,,
thax again
Logged
*

Offline mariush

  • **
  • 63
Re: A580 porting - minor progress
« Reply #37 on: 05 / February / 2009, 07:24:39 »
Code: [Select]
Huh ? You don't need to copy them. Just don't build them in the first place. You only need to generate the .h files if you are adding entry points to sig_ref_*.txt. This is only true if you are adding new features.
Quote
The generated signatures_dryos.h during compile is identical with the one in the SVN, except that it now no longer has as the bottom in the Function_list , the functions with _2 at the end.
This is not what you want, since it means any stubs_entry.S files you generate will be different from what other developers generate.

Isn't this needed to generate the stubs_entry.S and stubs_entry_2.S files ? That's what I thought it does...
How do I not make them run, just comment out the gensigs.sh line?

Regarding stubs_entry.S and stubs_entry_2.s, I just opened both in the editor and also opened both from 720.
I'm taking one at a time and checking the one found in stubs_entry.s from a580 to the equivalent in a720's firmware. I've done about 50 so far in two hours and I don't mind that it's slow, I feel it's safer just to check each one.

For example, I have functions like GetDrive_ClusterSize which are detected in stubs_entry.S as 70% match but also below it there are three alternatives and i believe the second alternative looks more likely to be the right one.

What's the difference between NSTUB and NHSTUB? NHSTUB only appears in stubs_entry_2.S so does this mean that nhstub functions replace nstub functions? if this is true I could just have all functions I check in stubs_entry.s and have only the functions that are rerouted to nullsub defined in stubs_entry_2.s with nhstub, right?

Thanks for the input on lib.c and stubs.min

The boot.c functions seems to be almost (if not) identical to the ones in my firmware so it will be just a question of parsing the existing code from a720 and checking for any difference, it's just that I didn't get to it yet.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: A580 porting - minor progress
« Reply #38 on: 05 / February / 2009, 13:31:10 »
Quote from: mariush on 05 / February / 2009, 07:24:39
What's the difference between NSTUB and NHSTUB? NHSTUB only appears in stubs_entry_2.S so does this mean that nhstub functions replace nstub functions? if this is true I could just have all functions I check in stubs_entry.s and have only the functions that are rerouted to nullsub defined in stubs_entry_2.s with nhstub, right?

Yes, an NHSTUB overrides NSTUB with the same name, because NSTUB are declared ".weak" in stubs_asm.h.

And another yes, stubs_entry.S is auto generated and overwritten by the signature finder during the build process if applicable firmwares are in place. You must check what's incorrect in stubs_entry.S and place the fixed ones in stubs_entry_2.S, which will not be overwritten by the signature finder.

In CHDK svn trunk, stubs_entry.S must be identical to whatever signature finder results in, otherwise all hell breaks loose or at least random developers start losing their hair :D.
Logged
*

Offline reyalp

  • ******
  • 14079
Re: A580 porting - minor progress
« Reply #39 on: 05 / February / 2009, 18:03:08 »
Quote from: mariush on 05 / February / 2009, 07:24:39
Isn't this needed to generate the stubs_entry.S and stubs_entry_2.S files ? That's what I thought it does...
How do I not make them run, just comment out the gensigs.sh line?
No, the signature .h files are generated by gensig and compiled into finsig, which in turn is used to generate stubs_entry.S (stubs_entry_2.s is manually written). The .h files only need to change if the sig_ref_*.txt files are updated.
Logged
Don't forget what the H stands for.
Pages: 1 2 3 [4] 5 6 7 8 9 ... 13   Go Up
« previous next »
 

Related Topics