no-gui development on OS X « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

no-gui development on OS X

(9 posts) (3 voices)

Started 5 years ago by pichenettes
Latest reply from betovar

pichenettes
Member

I'm planning to use my leaf board on OS X 10.5.8 with standard command line tools.

I've tried to follow the linux how2 but I am stuck at the stage where the codesourcery tools have to be installed. The arm-2010q1-188-arm-none-eabi-toolchain-macosx32.tar archive contains prebuilt binaries which seem to have something wrong (eg launching bin/arm-none-eabi-g++ yields a "dyld: unknown required load command 0x80000022" error) - maybe because they have been built on 10.6? Is there a source-only distribution of the toolchain that I can download somewhere and build?

Thanks!

Posted 5 years ago #
bnewbold
Ex-Leaflabs

Hi pichenettes!

Those binaries are indeed intended only for 10.6 (and should probably be labeled as such). I had a great deal of trouble trying to cross compile for 10.5/10.6 and 32bit/64bit at the same time and decided to just go with 10.6 in the end.

The most popular way to get the arm-none-eabi toolchain going on OSX is to use this makefile:
http://github.com/jsnyder/arm-eabi-toolchain

Note that this also is intended for 10.6 but "should also work on 10.5". If I recall it did work eventually but I had to make some tweaks.

You can grab the codesourcery source from our mirror (http://static.leaflabs.com/pub/codesourcery/originals/ ) or I think the makefile will grab it from their website. You can use either the 2010q1 or 2009q3 releases.

Good luck! And please post if you have success.

Posted 5 years ago #
pichenettes
Member

Still stuck at building the code from http://github.com/jsnyder/arm-eabi-toolchain . I've installed mpfr and gmp (got them built with make install-deps) but I still get:

configure:4708: gcc -o conftest -g -O2 conftest.c -lmpfr -lgmp >&5
ld warning: in /usr/lib/libmpfr.a, file is not of required architecture
ld warning: in /usr/local/lib/libgmp.a, file is not of required architecture
Undefined symbols:
"_mpfr_erfc", referenced from:
_main in ccmc7m95.o
"_mpfr_atan2", referenced from:
_main in ccmc7m95.o
"_mpfr_init", referenced from:
_main in ccmc7m95.o
_main in ccmc7m95.o
"_mpfr_subnormalize", referenced from:
_main in ccmc7m95.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
configure:4714: $? = 1

Posted 5 years ago #
pichenettes
Member

Finally got the toolchain working!

The core of the problem is that mpfr and gmp must be compiled for 32 bits. I have no idea if the problem is specific to 10.5.8, to my machine (late 2007 Core 2 Duo iMac) or to the hodge-podge of compilers and development tools that have accumulated on my system since then.

Here's how I did it:

- Grabbed jsnyder's makefile and patches
- sudo make install-deps . It will fail at the steps described above, because arm-none-eabi-gcc will be attempted to be built for 32 bits, while make install-deps will build mpfr and gmp have just been built for 64 bits.
- cd gmp-2010q1-188 ; ./configure ABI=32 ; sudo make install ; cd .. to force gmp to be built for 32 bits
- cd mpfr-2010q1-188 ; ./configure ABI=32 ; sudo make install ; cd .. to force mpfr to be built for 32 bits
- now you can resume the global install procedure with mkdir -p $HOME/arm-cs-tools/bin ; export PATH=$HOME/arm-cs-tools/bin:$PATH ; make install-cross

The files produced in arm-cs-tools can now be copied over the files in /Applications/MapleIDE.app/Contents/Resources/Java/hardware/tools/arm .

I could compile Blink. Now waiting for my board to arrive!

If you're interested in getting the pre-built binaries:
http://dl.dropbox.com/u/612135/dev/tools.zip

Posted 5 years ago #
bnewbold
Ex-Leaflabs

Awesome!

I hope your binaries produce the correct bins; we had trouble with this initially on OSX, but jsnyder's process seems to give reliable compiler tools.

If you're interested I think you can get a 10.5-compatible dfu-util from the OpenMoko project; note that if you use their binary you need to grab at least one dynlib as well and preserve the relative path.

The other upload mechanism is the stm32loader.py script; if you compile programs for the JTAG target you should then be able to upload the bin out of ./build using that script (search these forums for the correct syntax).

Posted 5 years ago #
pichenettes
Member

Yes, I built dfu-util from the sources on the OpenMoko site - no build problem. Runs, but can't tell if it really works without a board...

What's the difference between an upload with dfu-util and with stm32loader? Do they rely on any specific bootloader to be present on the chip?

My goal is to use the board to validate that the STM32 is the right platform for what I want to do, and then migrate to a custom board - so there will come a point where I will have to know what is needed to get a bare chip running. Given a "blank" chip straight from ST, is there any other way of programming it without using a JTAG interface (a bootbootloader?)

Posted 5 years ago #
bnewbold
Ex-Leaflabs

The STM32 has a hard-coded bootloader mode that lets you upload programs over a serial interface (which from a PC would require, eg, an FTDI chip, or a second Maple or an arduino, or ____). That's what the stm32loader.py method does; the script talks to the chip and uploads binary files. You need to do some button mashing to get in to this mode; see http://forums.leaflabs.com/topic.php?id=32#post-115 . We find this simpler than JTAG and it's actually what we use to upload our bootloader program "at the factory".

The second bootloader is our custom written 'maple-bootloader' which allows programs to be uploaded via dfu-util over the USB port either at boot time or via auto-reset.

High-density STM32 devices actually support something like DFU in their hard-coded bootloader, but the medium-density device in the Maple does not.

Posted 5 years ago #
pichenettes
Member

Thanks for the info! Having a low-level, built-in, permanent bootloader is great.

Posted 5 years ago #
betovar
Member

I've had the same error for awhile now and I wondered if maybe i had done something to the board. I too have an iMac 24" 2.4GHz Intel Core 2 Duo running 10.5.8 and originally thought it was something wrong with Xcode. After reinstalling that with no success, I turned over to my Linux machine which worked like a charm (in terms of compiling, I haven't yet had the chance to upload code to the device).

Pichenettes, your instructions for getting the patches installed and the cross compiler running went quite smoothly. thanks a bunch!

Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.