Self-compiled CHDK not working - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: [1]   Go Down

Self-compiled CHDK not working

  • 9 Replies
  • 6133 Views
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Self-compiled CHDK not working
« on: 07 / June / 2008, 17:35:43 »
Advertisements
Hello,

I am trying to compile CHDK r407 for my SD1000. I followed the instructions given in the wiki "Compiling_CHDK_under_Linux", and everything went fine, except that at the end I'm getting .bin and .fir files of 882KB instead of 143KB like the official builds. And of course when I load them in the camera it doesn't work: it doesn't boot.

The problem seems similar to Self compiled CHDK for a720 does't work, except that I always did "make fir" and used files in the bin folder... so I don't understand.

Any idea?
Thanks
« Last Edit: 08 / June / 2008, 14:36:31 by cyril42e »
Logged
*

Offline wontolla

  • ****
  • 413
  • S3 & G9 & A720
Re: Self-compiled CHDK not working
« Reply #1 on: 07 / June / 2008, 18:11:53 »
"make fir"?

AFAIK, that would compile just for the default camera, A610.

To compile for SD1000 you have to execute this:
gmake PLATFORM=ixus70_sd1000 PLATFORMSUB=102a fir
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #2 on: 07 / June / 2008, 18:15:47 »
Quote from: wontolla on 07 / June / 2008, 18:11:53
"make fir"?

AFAIK, that would compile just for the default camera, A610.

To compile for SD1000 you have to execute this:
gmake PLATFORM=ixus70_sd1000 PLATFORMSUB=102a fir

No because I manually modified makefile.inc to change these vars (this is what is advised at Compiling CHDK under Linux). And this is really "ixus70_sd1000-102a.FIR" that is generated in the bin directory.
« Last Edit: 07 / June / 2008, 18:18:27 by cyril42e »
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #3 on: 07 / June / 2008, 22:56:22 »
I tried again from the beginning, this time following carefully the "alternative method" given in Compiling CHDK under Linux - CHDK Wiki, and with binutils 2.15 instead of 2.18. And still my 882KB files.

What I exactly did is:
Code: [Select]
export CFLAGS=""

wget http://ftp.gnu.org/gnu/binutils/binutils-2.15.tar.bz2
tar xjvf binutils-2.15.tar.bz2
cd binutils-2.15
mkdir binutils-arm-elf
cd binutils-arm-elf
../configure --srcdir=../ --target=arm-elf
make && make install

wget http://ftp.gnu.org/gnu/gcc/gcc-3.4.6.tar.bz2
tar xvjf gcc-3.4.6.tar.bz2
cd gcc-3.4.6
patch -p0 < ../gcc-3.4-arm.diff
mkdir gcc-arm-elf
cd gcc-arm-elf
../configure --srcdir=../ --target=arm-elf --with-cpu=arm9 --with-newlib --enable-multilib  --enable-languages=c
make && make install

svn co https://tools.assembla.com/svn/chdk/trunk
cd trunk
gmake PLATFORM=ixus70_sd1000 PLATFORMSUB=102a fir
With no error...

I'm using gentoo x86_64, and used gcc 4.2.2 to compile the arm toolchain...
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #4 on: 08 / June / 2008, 07:52:26 »
I analyzed my DISKBOOT.BIN file, and I found some interesting things :
- data and code are swapped. In the official builds, code is roughly at offset 476 (beginning of the file) and data at offset 111743 (end of the file). In my build, data is at offset 160 (beginning of the file), and code at offset 781912 (end of the file)
- in my build the file is filled with 0x00 between data and code (from offset 26079 to 781912, that's 700KB of 0x00 !)
- the code and data are basically the same, with some small differences at some places, but I compared r408 and r410, so the problem is probably only this swap and bunch of 0x00...

Does this information call up something to someone ?
Thanks for your help...
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #5 on: 08 / June / 2008, 09:47:48 »
Ok, I found the SILENT variable, and I saw that gcc was actually used instead of gcc-arm-elf. All that's left to do is to find out why now...

« Last Edit: 08 / June / 2008, 09:53:15 by cyril42e »
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Self-compiled CHDK not working
« Reply #6 on: 08 / June / 2008, 09:51:02 »
It's supposed to be arm-elf-gcc (not gcc-arm-elf). Are you sure it's in your PATH? What do you see when you execute arm-elf-gcc --version ?
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #7 on: 08 / June / 2008, 10:01:05 »
Quote from: DataGhost on 08 / June / 2008, 09:51:02
It's supposed to be arm-elf-gcc (not gcc-arm-elf). Are you sure it's in your PATH? What do you see when you execute arm-elf-gcc --version ?

Yes it's arm-elf-gcc, I wrote that from memory and made a mistake.

Actually I'm sorry I posted too fast. It's the finsig tool that is compiled with gcc, the rest is actually compiled with arm-elf-gcc, and it runs perfectly.
Code: [Select]
# arm-elf-gcc --version
arm-elf-gcc (GCC) 3.4.6
I'll keep looking at the output now it is verbose...
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #8 on: 08 / June / 2008, 12:50:21 »
So after further investigation, it seems that the problem is from core/main.elf to core/main.bin.

Explanation:

core/main.elf is created with the following command:
Code: [Select]
arm-elf-gcc -fno-inline -Os -fno-strict-aliasing -mthumb-interwork -I../include -DMEMBASEADDR=0x1900 -DMEMISOSTART=0xBEF70 -DMEMISOSIZE=0x40000 -DRESTARTSTART=0x50000  -DPLATFORM=\"ixus70_sd1000\" -DPLATFORMSUB=\"102a\" -DHDK_VERSION=\"allbest\" -DBUILD_NUMBER=\"51\" -DCAMERA_ixus70_sd1000=1 -Wall -Wno-unused -Wno-format -mthumb -o main.elf --start-group entry.o nothumb.o main.o gui_draw.o gui_menu.o gui_palette.o gui_mbox.o gui_reversi.o gui_debug.o gui_fselect.o gui_read.o gui.o kbd.o conf.o histogram.o gui_batt.o gui_space.o gui_osd.o script.o raw.o gui_sokoban.o gui_calendar.o gui_lang.o gui_bench.o gui_mpopup.o gui_grid.o motion_detector.o raw_merge.o ../platform/ixus70_sd1000/libplatform.a ../platform/ixus70_sd1000/sub/102a/libplatformsub.a ../lib/font/libfont.a ../lib/math/libmath.a ../lib/ubasic/libubasic.a ../lib/lang/liblang.a  -lgcc --end-group -L../lib/math -L../lib/font -L../lib/libc -L../lib/ubasic -L../platform/ixus70_sd1000 -L../platform/ixus70_sd1000/sub/102a -nostdlib -Wl,--allow-shlib-undefined -Wl,-T,../tools/link-boot.ld -Wl,-N,-Ttext,0xBEF70
Then main.elf is 232KB, and the analysis of its size is:
Code: [Select]
   text    data     bss     dec     hex filename
 136903    8412   56728  202043   3153b main.elf
which is coherent with what the guy here got. So core/main.elf is probably correct. However, after the command:
Code: [Select]
arm-elf-objcopy -O binary main.elf main.bin
the file core/main.bin obtained is 881KB... with the 700KB at zero in the middle. Then it is included in loader/ixus70_sd1000/blob.o, loader/ixus70_sd1000/main.bin which becomes bin/DISKBOOT.BIN.
The verbose command says:
Code: [Select]
# arm-elf-objcopy -O binary -v main.elf main.bin
copy from main.elf(elf32-littlearm) to main.bin(binary)


Info about my arm-elf-objcopy exe:
Code: [Select]
# arm-elf-objcopy --version
GNU objcopy 2.15
Copyright 2004 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
#  arm-elf-objcopy --info
BFD header file version 2.15
elf32-littlearm
 (header little endian, data little endian)
  arm
elf32-bigarm
 (header big endian, data big endian)
  arm
elf32-little
 (header little endian, data little endian)
  arm
elf32-big
 (header big endian, data big endian)
  arm
srec
 (header endianness unknown, data endianness unknown)
  arm
symbolsrec
 (header endianness unknown, data endianness unknown)
  arm
tekhex
 (header endianness unknown, data endianness unknown)
  arm
binary
 (header endianness unknown, data endianness unknown)
  arm
ihex
 (header endianness unknown, data endianness unknown)
  arm

               elf32-littlearm elf32-bigarm elf32-little elf32-big srec
           arm elf32-littlearm elf32-bigarm elf32-little elf32-big srec

               symbolsrec tekhex binary ihex
           arm symbolsrec tekhex binary ihex

Here is the full verbose log of the compilation, if it can help:
http://crteknologies.free.fr/publish/compil_CHDK_2008-06-08.log

Does someone know what could be the problem with arm-elf-objcopy ? Wrong binutils version ? (I tried with 2.15 and 2.18)
Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Self-compiled CHDK not working
« Reply #9 on: 08 / June / 2008, 14:35:50 »
Ok ... solved.
I recompiled the arm toolchain with gcc 4.1.2 instead of gcc 4.2.2, and now it works. Curiously, recompiling binutils didn't change anything, it's the recompilation of gcc that solved the problem.

I'll try again with gcc 4.2.2 to check that it is reproducible, and then update my system to gcc 4.2.4 (hum, using gcc 4.1.2...). I should have known that it wasn't a good idea to keep a version which was removed from the package manager... But strangely enough,  I used this compiler to compile my whole system for 8 months (gentoo) and never got any problem before...

Sorry to those who have read this thread, and that I have annoyed with this problem they couldn't possibly solve...
Logged
Pages: [1]   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal