15 replies to this topic

[MarkRVMurray]

Hi *

I got coptercontrol to mostly compile on FreeBSD. The changes I needed (attached) to do the build aren't too onerous, and some of them are a bit hacky, but they got me to the point of linking, where things went pear-shaped.

Before I roll my sleeves up and dive into the details, are there any simple (known?) solutions to this?

[groundzero] /usr/local/src/OpenPilot $ gmake coptercontrol
clang++ -c -pipe -g -Wall -W -DQT_XML_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-clang -I../../../ground/uavobjgenerator -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4 -I. -I../../../ground/uavobjgenerator -I/usr/local/include/qt4 -I/usr/local/include -I. -o main.o ../../../ground/uavobjgenerator/main.cpp
clang++ -c -pipe -g -Wall -W -DQT_XML_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-clang -I../../../ground/uavobjgenerator -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4 -I. -I../../../ground/uavobjgenerator -I/usr/local/include/qt4 -I/usr/local/include -I. -o uavobjectparser.o ../../../ground/uavobjgenerator/uavobjectparser.cpp
:
<SnipSnip>
:
CC flight/PiOS/STM32F10x/Libraries/FreeRTOS/Source/list.c
CC flight/PiOS/STM32F10x/Libraries/FreeRTOS/Source/queue.c
CC flight/PiOS/STM32F10x/Libraries/FreeRTOS/Source/tasks.c
CC flight/PiOS/STM32F10x/Libraries/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c
CC flight/PiOS/STM32F10x/Libraries/FreeRTOS/Source/portable/MemMang/heap_1.c
LD build/fw_coptercontrol/fw_coptercontrol.elf
../PiOS/STM32F10x/link_STM32103CB_CC_Rev1_sections.ld:152 cannot move location counter backwards (from 200049d0 to 00000630)
collect2: ld returned 1 exit status
gmake[1]: *** [/usr/local/src/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf] Error 1
gmake: *** [fw_coptercontrol_opfw] Error 2


 CopterControl.txt   6.35K   11 downloads

[D-Lite]

That's interesting because FreeBSD is my favourite free UNIX system . Never tried to get OP running though. What toolchain are you using?

[MarkRVMurray]

I've fixed 2 ports (devel/arm-eabi-binutils and devel/arm-eabi-gcc) to be more recent than the current releases.

[groundzero] ~ $ arm-eabi-ld --version
GNU ld (GNU Binutils) 2.22

[groundzero] ~ $ arm-eabi-gcc --version
arm-eabi-gcc (GCC) 4.5.2
They are pretty much stock GNU tools, built for cross-compilation.

To build gcs, I'm using some other light source hacks and QT4 from ports. This mostly builds, but USB doesn't build because FreeBSD doesn't have libudev.

Glad its your favourite! I'm not very active any more, but in the past, I was an enthusiastic FreeBSD committer, for my sins!

M

[D-Lite]

Running the LINUX version of the CodeSourcery toolchain would probably work but a native solution is of course much nicer. The only thing I notice at a first glance is that ld is slighty newer than the one from the CS toolchain. Another possible source of problems may be the options used for compiling gcc. Here's the version information from my WinXP, maybe you can spot some options that are different.

Quote

D-Lite@FIREBIRD ~
$ arm-none-eabi-ld.exe --version
GNU ld (Sourcery G++ Lite 2011.03-42) 2.20.51.20100809
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

D-Lite@FIREBIRD ~
$ arm-none-eabi-gcc.exe  -v
Using built-in specs.
COLLECT_GCC=o:\Programme\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gcc.ex
e
COLLECT_LTO_WRAPPER=o:/programme/codesourcery/sourcery g++ lite/bin/../libexec/g
cc/arm-none-eabi/4.5.2/lto-wrapper.exe
Target: arm-none-eabi
Configured with: /scratch/janisjo/arm-eabi-lite/src/gcc-4.5-2011.03/configure --
build=i686-pc-linux-gnu --host=i686-mingw32 --target=arm-none-eabi --enable-thre
ads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra
-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fve
rbose-asm} -D__CS_SOURCERYGXX_MAJ__=2011 -D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURC
ERYGXX_REV__=42 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:
%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enab
le-languages=c,c++ --disable-shared --enable-lto --with-newlib --with-pkgversion
='Sourcery G++ Lite 2011.03-42' --with-bugurl=https://support.codesourcery.com/G
NUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-
sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/janisjo/ar
m-eabi-lite/install/host-i686-mingw32/arm-none-eabi --with-libiconv-prefix=/scra
tch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-mingw32/us
r --with-gmp=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-ea
bi-i686-mingw32/usr --with-mpfr=/scratch/janisjo/arm-eabi-lite/obj/host-libs-201
1.03-42-arm-none-eabi-i686-mingw32/usr --with-mpc=/scratch/janisjo/arm-eabi-lite
/obj/host-libs-2011.03-42-arm-none-eabi-i686-mingw32/usr --with-ppl=/scratch/jan
isjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-mingw32/usr --wit
h-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-clo
og=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-arm-none-eabi-i686-mi
ngw32/usr --with-libelf=/scratch/janisjo/arm-eabi-lite/obj/host-libs-2011.03-42-
arm-none-eabi-i686-mingw32/usr --disable-libgomp --enable-poison-system-director
ies --with-build-time-tools=/scratch/janisjo/arm-eabi-lite/obj/tools-i686-pc-lin
ux-gnu-2011.03-42-arm-none-eabi-i686-mingw32/arm-none-eabi/bin --with-build-time
-tools=/scratch/janisjo/arm-eabi-lite/obj/tools-i686-pc-linux-gnu-2011.03-42-arm
-none-eabi-i686-mingw32/arm-none-eabi/bin
Thread model: single
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42)

[MarkRVMurray]

I tried running the Linux one, and it was a bit messy as I didn't have a complete enough Linux development environment. I could try it again, but I'f far rather try to get the native stuff to work. I'm currently upgrading gcc to 4.6.2 (not that I think it will help much!).

[MarkRVMurray]

Hmm. A thought; the FreeBSD ports cross compiler is bundled with newlib. Is it possible that anything in there is introducing something undesirable?

[naiiawah]

I would look at the changes (ifdefs) involved with the "CODE_SOURCERY" define that you've change to NO in several spots in the patch.  I'm thinking that you probably should leave it yes as the FreeBSD compiler is going to be closer to CodeSourcery than not.

[MarkRVMurray]

Hi

The only practical difference that makes is

ifeq ($(CODE_SOURCERY), YES)
CFLAGS += -fpromote-loop-indices
endif

... and only the CodeSourcery GCC compiler has that option.

M

[MarkRVMurray]

I'm getting a handle on this. I'm not brilliant with *.ld scripts, and I think this is where the problem may lie.

The OpenPilot linker scripts (*.ld files in flight/...) have two chunks; the *memory*.ld and the *section*.ld. I have ZERO experience of using the MEMORY { ... } method of laying out the ELF object, instead I prefer to use LMA and VMA. If I comment out the SRAM line in the *memory*.ld file, the link completes (but I doubt it would work, as the RAM location is then rubbish). I suspect that these *.ld files were built with some CodeSourcery-specific dependancy, and that regular GNU tools don't like this.

I'm going to experiment with LMA/VMA now. I think I have the memory map sorted out in my head; does the very first bit of memory beginning at 0x00000000 have any boot-time paging on OpenPilot? After that comes ROM, and RAM is at 0x20000000, and the I/O space is not given an ELF segment. How am I doing?

Thanks!

M

[peabody124]

This won't help too much for the solution but I know Oleg has seen this problem actually running gcc 4.6 on the current code base.

[stac]

MarkRVMurray, on 18 January 2012 - 06:39 PM, said:

I'm getting a handle on this. I'm not brilliant with *.ld scripts, and I think this is where the problem may lie.

The OpenPilot linker scripts (*.ld files in flight/...) have two chunks; the *memory*.ld and the *section*.ld. I have ZERO experience of using the MEMORY { ... } method of laying out the ELF object, instead I prefer to use LMA and VMA. If I comment out the SRAM line in the *memory*.ld file, the link completes (but I doubt it would work, as the RAM location is then rubbish). I suspect that these *.ld files were built with some CodeSourcery-specific dependancy, and that regular GNU tools don't like this.

I'm going to experiment with LMA/VMA now. I think I have the memory map sorted out in my head; does the very first bit of memory beginning at 0x00000000 have any boot-time paging on OpenPilot? After that comes ROM, and RAM is at 0x20000000, and the I/O space is not given an ELF segment. How am I doing?

Thanks!

M

This is on my list of things to look at.  The currently supported toolchain is using gcc 4.5.2 and ld 2.20.

In case you're interested, the annoying fact that ld blames the line after the end of the ld script is an open bug against ld 2.22.

The BOOT0/1 pins are strapped on CC to alias the flash space (0x08000000) onto the boot memory space (0x00000000).  The memory layout used during linking is specified in flight/PiOS/STM32F10x/link_STM32F103CB_CC_Rev1_memory.ld:

MEMORY
{
	BL_FLASH (rx) : ORIGIN = 0x08000000,		LENGTH = 0x03000 - 0x00080
	BD_INFO (r)   : ORIGIN = 0x08003000 - 0x80, LENGTH =		   0x00080
	FLASH (rx)	: ORIGIN = 0x08003000,		LENGTH = 0x20000 - 0x03000
	SRAM (rwx)	: ORIGIN = 0x20000000,		LENGTH = 0x05000
}

Our bootloaders are linked at the reset vector (BL_FLASH) and our applications are linked at an offset from there (FLASH) to leave space for a bootloader.

SRAM is at 0x20000000.

The error is almost certainly triggered by this line:

	. = ORIGIN(SRAM) + LENGTH(SRAM) - _free_ram ;

This line will set "." (current pointer) to be equal to the number of free bytes of RAM.  In this case, the computation would be:

. = 0x20000000 + 0x00005000 - 200049d0

which is equal to 0x00000630, exactly matching your error message.

I'll post a patch here shortly that should get rid of the free_ram section entirely.  I added that to help me get a better handle on the truly free RAM that we had available.

[stac]

I haven't tested this since I'm not using ld-2.22 but I believe the attached patch should fix your issue.  If this works for you, I'll get it merged so please report your results here.

Attached Files

•  ld-2.22-counter-decrement-fix.patch   849bytes   14 downloads

[MarkRVMurray]

Hi stac,

Yup, that worked! Well, the build completed (I don't have hardware to check it with!)

Thanks!

PS: Is there a clean solution to all the ^M (== CR) characters that are in many of the files? Does git have a reliable way of removing those?

[stac]

Glad that helped.  Thanks for testing it.  I've got to follow up on another reported issue with this patch before merging it.

We (unfortunately) still have a mix of dos/unix line ends throughout our source tree.  We'll probably schedule a large cleanup of that section by section so that we don't disrupt work in progress.  We don't really want to do this one file at a time since it just clouds the diffs.

The general rules in the interim go something like this.  New files in the flight tree should be created with unix (LF) line ends.  Changes to existing files should respect the existing line ends.  Commits should not change both code functionality _and_ line endings/whitespace at the same time.

Once we get everything in the flight tree flipped over to LF-only, we can probably just catch CRLF errors in code reviews.  I think we could also implement a check in the git commit hooks but that might be overkill.

[stac]

This fix is under review in http://git.openpilot...ru/OPReview-156 in case you want to comment.  Should be merged soon.

[stac]

Merged to next in 5907022b6d.