I've built the toolchain, had to use -mlong-calls in Makefile.inc, but I got ML compiled.
In platforms/, there is a folder 50D.109. Does this mean I need firmware 1.0.9 on my 50D? I currently have 1.0.8 and the ML release from December.
If you had to use -mlong-calls chances are you're using a 64bit compiler.
In order to test and develop Magic Lanter properly, I suggest you use a 32bit arm compiler. If you're on linux there's no need to use a 32 bit distrubtion, you just need to install libc6-i386
I thought I might be better off with a 32bit compiler. I'm running ubuntu 12.04, and I have libc-i386 installed. Is there a way to modify summon-arm to force it to build a 32bit toolchain, or should I just use the vmware image?
If you can force the arm-toolchain to build a 32-bit compiler, please post the patch so I can commit it.
I'm using the codesourcery toolchain for my 1100D work. It's pre-built and works fine.
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/
Didn't work for me, but that was back in 2010... http://magiclantern.wikia.com/wiki/Build_instructions/550D#Compilers_which_do_not_work
Now it works fine. Both at my home and on ML server :)
thanks for the tips, I will try out that toolchain :D
I had a problem running make docs. On ubuntu, rst2latex is just installed as rst2latex not rst2latex.py. I created a symlink in /usr/bin and that sorted it out.
I downloaded Codesourcery ARM EABI (http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/arm-eabi), choosing 'IA32 GNU/Linux TAR'. Extracted to my home directory and updated Makefile.inc:
ARM_ABI = none-eabi
ARM_PATH=~/arm-2012.03
and it all builds fine.
Great, so there is now an easy way of building ML!
Quote from: a1ex on July 03, 2012, 04:59:13 PM
Great, so there is now an easy way of building ML!
At least as long as Codesurcery keeps offering the ARM GCC compiler for free ;)
ARM also maintain a gcc toolchain (https://launchpad.net/gcc-arm-embedded), I use the same one for ARM CM4 development. I didn't realise I could use it to compile ML, but it works. Binary is a bit smaller than the one produced by the code sourcery toolchain (~365kb vs 328kb)
Well, well, well. A prebuilt stock GCC toolchain mantained by ARM. We should definitely move to this
Thanks :)
Works for me too (just compiled, did not run). RAM usage for 5D2 binary: 341k (prebuilt GCC) vs 339k (32-bit arm toolchain).
Quote from: trsaunders on July 03, 2012, 04:16:23 PM
thanks for the tips, I will try out that toolchain :D
I had a problem running make docs. On ubuntu, rst2latex is just installed as rst2latex not rst2latex.py. I created a symlink in /usr/bin and that sorted it out.
It was renamed for Osx compatibility, if you know a better way to deal with it...(maybe adding the symlink to Osx with prepare.Lion.sh ?)
In the makefile, check if OS is darwin or not and set the executable name accordingly
it could be that non OSX platforms also get named with .py. a simple way to check could be to look at the output of `which rst2latex.py`
Quote from: trsaunders on July 03, 2012, 11:56:52 PM
it could be that non OSX platforms also get named with .py. a simple way to check could be to look at the output of `which rst2latex.py`
yep, that is good, i've used it for MLTools (https://bitbucket.org/600Dplus/magic-lantern-for-600d/raw/e8d392c584c5/toolchain/MLTools), can you take a look at it to see if could be made more "POSIX" than now, if you want?
EDIT:
in makefile there is already a check for osx but I can't figure how to add:
ifeq ($(UNAME), Darwin)
# Variable declaration for Mac OS X
UMOUNT=hdiutil unmount
CF_CARD=/Volumes/EOS_DIGITAL
else
# Default settings for remaining operating systems
CF_CARD=/media/EOS_DIGITAL
UMOUNT=umount
endif
I can't use this code for the check:
if [ ! $(which rst2latex) ] && [ $(which rst2latex.py) ]; then
alias rst2latex=rst2latex.py
fi
nor this inserted in the already present check:
alias rst2latex=rst2latex.py
Quote from: trsaunders on July 03, 2012, 07:16:31 PM
ARM also maintain a gcc toolchain (https://launchpad.net/gcc-arm-embedded), I use the same one for ARM CM4 development. I didn't realise I could use it to compile ML, but it works. Binary is a bit smaller than the one produced by the code sourcery toolchain (~365kb vs 328kb)
from what I can understand no osx, true?
Quote from: scrax on July 04, 2012, 01:09:30 AM
from what I can understand no osx, true?
Unfortunately, that is true. YAGARTO (http://www.yagarto.de/) could be an alternative, but I've not tested with ML.
I've ran Yagarto under Windows (also had to install msys) and worked fine.
I just made a long post in General Development Discussion about my difficulty building ML using the ARM toolchain I built in my 64-bit Ubuntu 10.04 VM.
From reading this thread I gather that it's because my Ubuntu 10.04 is 64-bit and building a correctly functioning ARM toolchain for ML is just not yet working in 64-bit Linux distributions? I guess I failed to read the fine print somewhere :) My bad.
Oh well I'm installing Ubuntu 12.04 LTS 32-bit right now. I hope that's a good direction to go in. I would much rather have another Ubuntu VM to backup and maintain that develop ML in Windows 7.
Quote from: vtrandal on July 31, 2012, 02:03:45 AM
I just made a long post in General Development Discussion about my difficulty building ML using the ARM toolchain I built in my 64-bit Ubuntu 10.04 VM.
Use -mlong-calls on 64-bit systems. It will produce slightly larger binaries. From my experience, I have no problems compiling and running ML on 64-bit systems. I use Ubuntu 12.04 64-bit native, not VM.
Quote from: adijiwa on July 31, 2012, 03:30:19 AM
Use -mlong-calls on 64-bit systems. It will produce slightly larger binaries. From my experience, I have no problems compiling and running ML on 64-bit systems. I use Ubuntu 12.04 64-bit native, not VM.
Sounds good to me. But I have no clue what that is. Can you explain?
Quote from: vtrandal on July 31, 2012, 04:56:33 AM
Sounds good to me. But I have no clue what that is. Can you explain?
In Makefile.inc, look for CFLAGS variable. Mine looks like this:
CFLAGS=\
$(FLAGS) \
-Os \
-Wall \
-W \
-mstructure-size-boundary=32 \
-Wno-unused-parameter \
-Wno-implicit-function-declaration \
-Wno-unused-function \
-Wno-missing-field-initializers \
-Wno-format \
-std=gnu99 \
-D__ARM__ \
-I$(PLATFORM_INC) \
-I$(SRC_DIR) \
-mlong-calls \Notice the
-mlong-calls at the end of variable.
Thank you.
With that change the build does seem to progress further.
But it now terminates with an error similar to that described here:
http://www.magiclantern.fm/forum/index.php?topic=1768.0
So, a little progress.