Suggestion: Teensyduino Linux ARM download package

Thanks! I read the blog post. It talks a lot about specific problems building CodeSourcery GCC, but not about the library target bits.

All this stuff is found in the Teensyduino core library.
Click to expand...

I read through that as well, and didn't initially find it (I was looking in the Makefile.)
It seems like this is more what I'm after, though:
https://github.com/PaulStoffregen/cores/blob/master/teensy3/mk20dx256.ld
https://github.com/PaulStoffregen/cores/blob/master/teensy3/mk20dx128.c
 
Well, I dusted off my Raspberry Pi and Motorola lapdock and grabbed the latest 2014 Wheezy Raspian.

I'm trying to compile the normal (GUI based) Teensy Loader now. Well, first a custom build of wxwidgets, and before that, a ton of apt-get install for the many GUI dev libraries needed.

Raspberry Pi is indeed terribly slow. I did at some point pick up the newer one with 512 megs, which seems to be helping. It's not quite as horrible as I remember. This time, I'm running on a 16 GB SanDisk Ultra, which probably helps. Last time around (shortly after RPi appeared, during all the hype) it couldn't boot from faster cards like SanDisk Ultra.
 
My poor little Raspberry Pi has been compiling code for well over 2 hours now. The CPU chip is burning hot, but it's still chugging away....
 
I've uploaded an experimental build of Teensy Loader and Teensyduino's 4 utils.

http://www.pjrc.com/teensy/loader_linux.html

I did manage to reprogram a Teensy 2.0 and I confirmed teensy_reboot is able to find and reboot a Teensy. Of course, the udev rules must be installed to run as a non-root user. So far, not much other testing has been done, so it's labeled "experimental".

Please let me know if this works for you?
 
Well, you can compile the command line version, and if you need a command line utility to reboot the Teensy, it's in this one.
 
Also, you probably want to add -ffunction-sections and -fdata-sections to the compile options for Arduino; will strip more unused stuff when using -Wl,--gc-sections!
 
I skipped the RPi when deciding to dabble in ARM and jumped right to the Samsung Exynos 4 and 5 SoCs. Having quad-core Cortex-A9 or A15 CPUs (and 2GB of DDR2 or 3 RAM) makes compilation much, much faster than it is on the Pi. Unfortunately, the Pi is probably so popular that it's armv6 architecture would be used much more than the armv7 arch I would want to target.

In order to configure that teensy-canadian github repo for armv7 would I have to change the options, or would I also have to change the patches, too?
 
I got a .hex file produced with the library files and link script from the teensy3 director, and used the Windows loader to load it, but it didn't work. (Not defining ARDUINO; changing the part defines to target mk20dx256.)
Disassembly shows what seems like proper thumb-mode code -- odd addresses, two-byte opcodes. I'm not accustomed to ARM assembly at all, so I may be missing something here, but I think it's OK.
Doing an objdump -h main.elf file tells me that the linker placed .note.gnu.build-id at 0x24, and .text at 0x28. The working blinky HEX files from the Teensyduino tools have .text starting at 0.
Thus, the problem is: the mk20dx256.ld linker script places .text at 28, not at 0. Tomorrow evening, maybe I'll try to figure out why. Unless this is something you've already run into and have an easy fix for?
 
ALRIGHT! Yeah! Success!

I added a line at the top of SECTIONS that says:
/DISCARD/ { *(.note*) }
Now, the main.cpp "blink" from the teensy3 libraries works.

Also, I pushed the built binaries from the rpi-teensy scripts into github, so you don't have to build them yourself if you don't want to.
Sadly, they are called "arm-jwatte-eabi" not "arm-none-eabi" so they're not a 100% drop-in replacement. That would be easy-ish to re-do with another go of the build scripts, though.
http://github.com/jwatte/teensy-canadian/x64/... has the goods.

Also, I may start using gvim instead of the Arduino IDE for my Windows development. The Arduino IDE is... not gvim :)
 
N0BOX said:
I skipped the RPi when deciding to dabble in ARM and jumped right to the Samsung Exynos 4 and 5 SoCs. Having quad-core Cortex-A9 or A15 CPUs (and 2GB of DDR2 or 3 RAM) makes compilation much, much faster than it is on the Pi. Unfortunately, the Pi is probably so popular that it's armv6 architecture would be used much more than the armv7 arch I would want to target.

In order to configure that teensy-canadian github repo for armv7 would I have to change the options, or would I also have to change the patches, too?
Click to expand...

You can change the default target of the cross compiler for the code to run on the A9's with the --with-cpu={cpu} option on the configure line, where {cpu} is the cpu you want to configure for (the value you would give to the -mcpu= option).
 
MichaelMeissner said:
You can change the default target of the cross compiler for the code to run on the A9's with the --with-cpu={cpu} option on the configure line, where {cpu} is the cpu you want to configure for (the value you would give to the -mcpu= option).
Click to expand...

Awesome, and thanks!

I believe I might want to change the fpu setting (this SoC has vfpv3 or 4, plus neon, and it also supports things like thumb... though I'm not sure how useful that might be to a compiler). As long as I don't have to write/modify code I should be OK. Compilers are well outside my level of understanding.
 
GCC actually uses floating point in the register allocation phase to assign a weighted score for each potential register, so if possible, you want to compile for a target that has basic hardware floating point.

In general, GCC is not vectorizable, but there are a few places that could be vectorized. However, automatic vectorization is not turned on until -O3, and typically the compiler is built with -O2. The lexer phase (which is the phase that reads text and decides if it is an identifier, constant, etc.) does have NEON specific optimizations in GCC 4.8 and later (there are also machine specific optimizations for x86 and powerpc in the lexer).
 
Last edited:
Using jwatte's teensy-canadian repo on github, I was able to modify it to target the armv7-a cortex-a9 based ODROID-X2 (which I would like to use as a tiny, mobile Teensy 3.1 dev platform) and build the first two portions of the toolchain. However, I ended up getting a huge wall of errors trying to build the final part, which is what ends up being the toolchain to compile Teensy 3.1 code on the ODROID:

(These are only the last 50 lines of the "Wall of Error"... there are something like 191 errors in total, and if you need to see the whole list, you can find them at http://itwannabe.com/errors.txt)
Code: 
[ERROR]    /usr/include/malloc.h:53:32: error: declaration of 'void free(void*) throw ()' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:531:12: error: from previous declaration 'int vsnprintf(char*, size_t, const char*, __va_list_tag*) throw ()'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:420:13: error: from previous declaration 'void free(void*)'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:500:34: error: declaration of C function 'const char* strsignal(int)' conflicts with
[ERROR]    /usr/include/string.h:564:14: error: previous declaration 'char* strsignal(int)' here
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)'
[ERROR]    /usr/include/string.h:601:26: error: ambiguates old declaration 'const char* basename(const char*)'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/ansidecl.h:308:64: error: declaration of 'int snprintf(char*, size_t, const char*, ...)' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:527:12: error: from previous declaration 'int snprintf(char*, size_t, const char*, ...) throw ()'
[ERROR]    make[1]: *** [build/read-md.o] Error 1
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/ansidecl.h:308:64: error: declaration of 'int vsnprintf(char*, size_t, const char*, __va_list_tag*)' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:531:12: error: from previous declaration 'int vsnprintf(char*, size_t, const char*, __va_list_tag*) throw ()'
[ERROR]    make[1]: *** [build/genmodes.o] Error 1
[ERROR]    make[1]: *** [build/gengtype-lex.o] Error 1
[ERROR]    make[1]: *** [build/gengtype-parse.o] Error 1
[ERROR]    ./auto-build.h:2000:16: error: declaration does not declare anything [-fpermissive]
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:444:23: error: declaration of C function 'void* sbrk(int)' conflicts with
[ERROR]    /usr/include/unistd.h:1043:14: error: previous declaration 'void* sbrk(intptr_t)' here
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:448:48: error: new declaration 'char* strstr(const char*, const char*)'
[ERROR]    /usr/include/string.h:324:20: error: ambiguates old declaration 'const char* strstr(const char*, const char*)'
[ERROR]    /usr/include/malloc.h:53:32: error: declaration of 'void free(void*) throw ()' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:420:13: error: from previous declaration 'void free(void*)'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:500:34: error: declaration of C function 'const char* strsignal(int)' conflicts with
[ERROR]    /usr/include/string.h:564:14: error: previous declaration 'char* strsignal(int)' here
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)'
[ERROR]    /usr/include/string.h:601:26: error: ambiguates old declaration 'const char* basename(const char*)'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/ansidecl.h:308:64: error: declaration of 'int snprintf(char*, size_t, const char*, ...)' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:527:12: error: from previous declaration 'int snprintf(char*, size_t, const char*, ...) throw ()'
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/../include/ansidecl.h:308:64: error: declaration of 'int vsnprintf(char*, size_t, const char*, __va_list_tag*)' has a different exception specifier
[ERROR]    /opt/cross/odroid-teensy/.build/src/gcc-linaro-4.8-2014.04/gcc/system.h:531:12: error: from previous declaration 'int vsnprintf(char*, size_t, const char*, __va_list_tag*) throw ()'
[ERROR]    make[1]: *** [build/genhooks.o] Error 1
[ERROR]    make[1]: *** [build/gengtype-state.o] Error 1
[ERROR]    make[1]: *** [build/gengtype.o] Error 1
[ERROR]   
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing final compiler'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR]  >>        called from: do_cc_core_backend[scripts/build/cc/gcc.sh@456]
[ERROR]  >>        called from: do_cc_for_host[scripts/build/cc/gcc.sh@587]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@638]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      'docs/B - Known issues.txt'
[ERROR]   
[ERROR]  (elapsed: 9:06.61)
[09:07] / make: *** [build] Error 2

Would anyone be able to point me in the right direction in trying to get this cleared up? I did change the directory names and references in the config files to "rpi" to "odroid" (since that it the target hardware). I also changed the config parameter specifying the kernel from 3.10 to 3.8 (since the odroids aren't fully supported in mainline, and 3.8 is the most current kernel version available for them that supports all of the hardware). I was curious if I should have changed the references to versions of the supporting libraries and things like binutils to the versions present on the version of Linux I use on my ODROID-X2, but I left those values unchanged because the libraries are marked to be statically linked.

Any help would be greatly appreciated!
 
Those errors seem like the wrong version headers are included.
It's important that the "bin" directory for the intermediate toolchain is first in the PATH before anything else.
Also, you could at least try running Paul's tool chain -- there's some chance it will work, even though Odroid uses a more modern version of the ARM architecture.
 
jwatte said:
Those errors seem like the wrong version headers are included.
It's important that the "bin" directory for the intermediate toolchain is first in the PATH before anything else.
Also, you could at least try running Paul's tool chain -- there's some chance it will work, even though Odroid uses a more modern version of the ARM architecture.
Click to expand...

My PATH:
Code: 
/opt/cross/x64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Am I supposed to have a single copy of crosstool-ng, trying to use it to generate all three toolchain configs, each in a separate dir under /opt/cross, or is it OK that I cloned crosstool-ng, then copied and built it three times in each of those dirs, adding and building against the configs later?

I am planning on giving Paul's build a try, as it's my understanding that a statically-compiled armv6 binary should run on an armv7-a system (or most other newer arm architectures). I'll report back whether I can get it to work. I will also try to figure out the issue I am having getting a toolchain compiled specifically for the armv7-a/vfpv3-d16 target.
 
N0BOX said:
I am planning on giving Paul's build a try, as it's my understanding that a statically-compiled armv6 binary should run on an armv7-a system (or most other newer arm architectures). I'll report back whether I can get it to work.
Click to expand...

Thanks. I'm really curious to hear an actual, real confirmation whether the armv6 binary actually works on an armv7 linux system.

It'd also be interesting to hear how the compiler's speed compares with a native armv7 build. If you want to try, the source I used for that build is here:

http://www.pjrc.com/teensy/beta/arm_toolchain_raspberrypi_src.tar.bz2

If you have gcc 4.6.x, all you should need to do is run the 2 scripts, build-prerequisites.sh and then build-toolchain.sh. These scripts have minor edits for Raspberry Pi. You can find all the changes by searching for comments containing "for Raspberry Pi".

But really, I'm mostly eager to hear an actual confirmation if the binary compiled on Raspberry Pi actually runs properly on an armv7-a system.
 
Am I supposed to have a single copy of crosstool-ng
Click to expand...

Yes -- crosstool-ng does not, by itself, have any data files. You only need one, and "make install" to install it on your system (like "make" or other build tools.)
 
You must log in or register to reply here.
Back
Top