ELPH300HS aka IXUS220HS - Porting Thread - page 21 - DryOS Development - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 ... 16 17 18 19 20 [21] 22 23 24 25 26 ... 90   Go Down

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 399426 Views
*

Offline sush

  • *
  • 29
  • ixus220 300hs firmware 1.01c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #200 on: 24 / November / 2011, 21:39:15 »
Advertisements
nice progress, Tommi!! 


I'm trying to debug using the heap, as recommended, but I end up with the following compilation errors:

Code: [Select]
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `exmem_malloc_init':
wrappers.c:(.text+0x818): undefined reference to `suba_init'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `malloc':
wrappers.c:(.text+0x858): undefined reference to `suba_alloc'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `free':
wrappers.c:(.text+0x890): undefined reference to `suba_free'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetExMemInfo':
wrappers.c:(.text+0x8fc): undefined reference to `suba_getmeminfo'

I'm likely missing a library but which library is it and where do I specify it?

edit: nevermind, found the suba.c file in core.  I think the problem is related to the rules to build wrapper.o

« Last Edit: 24 / November / 2011, 22:39:09 by sush »
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #201 on: 25 / November / 2011, 00:14:32 »
Sush, could you please provide your complete code package (loader + platform) like I did some posts ago? Please remove PRIMARY.BIN before.  ;)

I would like to reproduce your error on my pc. Without reproducing it's hard to say what could be the problem.

Don't understand why you run into problems which I never had!?


Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #202 on: 25 / November / 2011, 02:07:44 »
Quote from: sush on 24 / November / 2011, 21:39:15
nice progress, Tommi!! 


I'm trying to debug using the heap, as recommended, but I end up with the following compilation errors:

Code: [Select]
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `exmem_malloc_init':
wrappers.c:(.text+0x818): undefined reference to `suba_init'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `malloc':
wrappers.c:(.text+0x858): undefined reference to `suba_alloc'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `free':
wrappers.c:(.text+0x890): undefined reference to `suba_free'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetExMemInfo':
wrappers.c:(.text+0x8fc): undefined reference to `suba_getmeminfo'

I'm likely missing a library but which library is it and where do I specify it?

edit: nevermind, found the suba.c file in core.  I think the problem is related to the rules to build wrapper.o



Looks like a problem with your makefile or makefile.inc.
Make sure you don't have any overrides for EXMEM values in your makefile.inc - you won't be able to set these up until you have a working port.
Have a look at the makefile.inc in tommi2water's version.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline unARMed

  • *
  • 9
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #203 on: 25 / November / 2011, 05:11:10 »
Cheers for the tips.  I have firmware version 1.01c.  I've dumped my firmware and am now setting up the devel environment (on ubuntu/linux).  Cross compiler is compiling...
Logged
*

Offline sush

  • *
  • 29
  • ixus220 300hs firmware 1.01c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #204 on: 25 / November / 2011, 07:33:36 »
I am using 0.9.9 on an ubuntu platform.  I've been having issues with this environment: make clean's don't really clean the tree, the compilation issue mentioned above (which disappeared now).  In the past, the stubs_entry.S wasn't being built.    I might just wipe it all and start again.



Logged
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #205 on: 25 / November / 2011, 08:00:20 »
I got tommi's 100c port to build.  Had to make a few changes to core\kbd.c (to define ZSTEP_TABLE_SIZE/nTxtbl; I borrowed the one from the 500hs for now, even though I'm almost certain it's wrong), and core\gui.c (for CAM_ADJUSTABLE_ALT_BUTTON; I borrowed the one from the sx200hs because it looked closest--the 500hs doesn't appear in this table, because its platform_camera.h doesn't have CAM_ADJUSTABLE_ALT_BUTTON in it, presumably because it's got a touchscreen).

Now I'm trying to use CHDK-PT to adapt to my camera's firmware version, 101a.  (FWIW: I put a note in the wiki to mention the fact that camera models don't appear in Makefile/Makefile.inc anymore, and you need to instead edit cameras.csv.  You may want to touch up my edit.)

During the convert phase, I get the following popup at 8 percent:
Error : requested address FF16C62C is outside the specified ROM range for camera model [FF810000 to FFFFFFFF]

I had selected "S series camera @ FF810000" from the menu, recalling seeing that number elsewhere in this thread and noting that an 8MB firmware jutting up against the top of the address space would start about there.  If I try "other camera @ FF000000", then I get a stubs_entry_2.S out, but it appears to be rubbish (it's full of "WARNING: too many matches for DebugAssert" and the like, and then it lists a dozen stubs at the same address later on).

I'm out of time at the moment, but I should be able to get back to this later today.  I think I'll just try hacking on stubs_entry_2.S manually.  Diffing the stubs_entry.S files generated for the two versions only shows 12 entries under "Stubs below should be checked".
Logged
*

Offline waterwingz

  • ******
  • 12139
    • Waterwingz
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #206 on: 25 / November / 2011, 10:07:51 »
Quote from: jstanley0 on 25 / November / 2011, 08:00:20
Had to make a few changes to core\kbd.c (to define ZSTEP_TABLE_SIZE/nTxtbl; I borrowed the one from the 500hs for now, even though I'm almost certain it's wrong),
Its only used if you have a USB remote switch enabled and are attempting to use the remote zoom function.

Quote
and core\gui.c (for CAM_ADJUSTABLE_ALT_BUTTON; I borrowed the one from the sx200hs because it looked closest--the 500hs doesn't appear in this table, because its platform_camera.h doesn't have CAM_ADJUSTABLE_ALT_BUTTON in it, presumably because it's got a touchscreen).
Enabling an alternate ALT button is up to the individual developer's preference.  Some ports have it,  some don't . There does not seem to be any rhyme or reason to why.

Quote
Now I'm trying to use CHDK-PT to adapt to my camera's firmware version, 101a.  (FWIW: I put a note in the wiki to mention the fact that camera models don't appear in Makefile/Makefile.inc anymore, and you need to instead edit cameras.csv.  You may want to touch up my edit.)
Thanks - missed that.  I took the liberty of doing the suggested "touch up".   Might as well make the default description apply to the current build structure.

Quote
During the convert phase, I get the following popup at 8 percent:
Error : requested address FF16C62C is outside the specified ROM range for camera model [FF810000 to FFFFFFFF]
I had selected "S series camera @ FF810000" from the menu, recalling seeing that number elsewhere in this thread and noting that an 8MB firmware jutting up against the top of the address space would start about there.  If I try "other camera @ FF000000", then I get a stubs_entry_2.S out, but it appears to be rubbish (it's full of "WARNING: too many matches for DebugAssert" and the like, and then it lists a dozen stubs at the same address later on)..
I haven't had a "bug report" in a long time.   :o

 I assume you were trying to convert the stubs_entry_2.S file from tommi2water's zip file ?  It gets tied up if it finds too many matching code sections for a short routines in  NHSTUB entry - DebugAssert and Nullsubs ( BX LR ) for example.  Ignore the warnings. 

You could probably delete everything in your stubs_entry_2.S file,  recompile and then add back in only the things that show up as misssing.  Then convert that file (ignoring the repeated warnings).  A much easier process.

The labels in the code in boot.c indicate the firmware starts at FF000000. So does this post http://chdk.setepontos.com/index.php?topic=6341.msg76229#msg76229

« Last Edit: 25 / November / 2011, 10:38:21 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #207 on: 25 / November / 2011, 11:59:02 »
Hi all,

for physw_status[2] I could print out the following values in function my_kbd_read_keys() (line 192 in attached kbd.c):
// 10cfff "no key is pressed"
// 10cfbf DISPLAY key is pressed
// 10cffd SET key is pressed
// 10cfbd SET + DISPLAY keys are pressed at the same time

This means that mykbd_task is really running and analyzing the key presses.  :)

DISPLAY key was not available from entry_stubs.S and was configured with 0x800. But it seems that it has value 0x40 (0x10cfff[no key pressed] - 0x10cfbf [DISPLAY key pressed] = 0x40).

SET key has value 0x02.

Both keys pressed together should activate the ALT menu.

Therefore the answer is 0x42. I assume that in "The Hitchhiker's Guide to the Galaxy" the answer also was in hex value?  :D

I changed values for ALT_mode_key_mask and KEY_PRINT to 0x42 (like it is now in attached kbd.c).

When I press the SET key a second time after pressing together with DISPLAY key I only see:
// 10cfff when SET key is pressed, means the value is not changing!?

It is somehow ignoring further presses of SET key after I have pressed SET key once together with DISPLAY key.
DISPLAY key is still executed. If I press DISPLAY key I still see value 0x10cfbf.

No ALT mode available for now.

btw:
Quote from: waterwingz on 24 / November / 2011, 16:03:50
Quote from: tommi2water on 24 / November / 2011, 15:32:53
I had to change in platform/kbd.c:
from: _SleepTask(*((int*)(0x1c40+0x8)));//10);
to:     _SleepTask(*((int*)(0x1c3C+0x8)));//10);
I'm not sure why they do it that way.  This works too : _SleepTask(10) ;

In the meantime I tried this as well and I can confirm, the _SleepTask(10) variant works as well.  :)
« Last Edit: 25 / November / 2011, 12:45:16 by tommi2water »
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #208 on: 25 / November / 2011, 13:13:18 »
I changed KEYS_MASK2 to (0x00000000)

Now the buttons are changing the keypress value also after pressed in combination.

But no ALT mode.

As I don't really know how it works I try to play around with some values and I'm hopefully lucky (at some day ...).  ;)
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #209 on: 25 / November / 2011, 13:36:32 »
Ok, ALT mode is now available, too.  :D

I looked at the back of some Canon cameras and the ixus120_sd940 looked similar regarding the buttons.

ALT mode can be reached with KEY_ZOOM_OUT when using attached kbd.c

Next step will be to adapt to a better key for entering ALT mode because zoom_out_button is not really useful for this.  ;)
Logged
Pages: 1 ... 16 17 18 19 20 [21] 22 23 24 25 26 ... 90   Go Up
« previous next »
 

Related Topics