gcc configure for hardware
-
Most GCC versions of GCC do processor families If you are playing around with the Raspberry Pi again BCM2835 Pi, Pi zero etc flag is -mcpu=arm1176jzf-s BCM2836 Pi 2 flag is -mcpu=cortex-a7 BCM2837 Pi 3 flag is -mcpu=cortex-a53 If you want them with hard float points it's longer BCM2835 Pi, Pi zero etc flag is -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard BCM2836 Pi 2 flag is -mcpu=cortex-a7 -mfpu=neon -mfloat-abi=hard BCM2837 Pi 3 flag is -mcpu=cortex-a53 -mfpu=neon -mfloat-abi=hard If you have a different CPU it's usually -mcpu="ARM CPU ID" Finally version 6 or maybe 7 GCC is current version on Raspbian Stretch sudo apt-get update your version OR download new version sudo apt-get install gcc If you are Crossing from Windows/MAC/other linux variants the newest ARM CORP version is always here GNU Toolchain | GNU-RM Downloads – Arm Developer[^] On version 6 and above GCC you can now ask for supported processors with gcc -mcpu=list It spits something like this
Quote:
arm-none-eabi-gcc: note: valid arguments to '-mcpu=' are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a17 cortex-a17.cortex-a7 cortex-a32 cortex-a35 cortex-a5 cortex-a53 cortex-a57 cortex-a57.cortex-a53 cortex-a7 cortex-a72 cortex-a72.cortex-a53 cortex-a73 cortex-a73.cortex-a35 cortex-a73.cortex-a53 cortex-a8 cortex-a9 cortex-m0 cortex-m0.small-multiply cortex-m0plus cortex-m0plus.small-multiply cortex-m1 cortex-m1.small-multiply cortex-m23 cortex-m3 cortex-m33 cortex-m33+nodsp cortex-m4 cortex-m7 cortex-r4 cortex-r4f cortex-r5 cortex-r52 cortex-r7 cortex-r8 ep9312 exynos-m1 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xgene1 xscale
-mfpu=list
Quote:
arm-none-eabi-gcc: n
Thanks Leon. Here is "MY problem" - as far as I can tell I am ONLY setting "Cross compiler prefix" as "arm-linux-gnueabihf-" and "Path" where it can be found as "/usr/bin". I have no idea where this "prefix" came from - I have been at this project for a while , off and on. It shows up in "include" tree on the Eclipse project form. The code complies and runs on BCM2837 - RPi 3B. Without changing any GCC setting the code compiles and sort of runs on BCM2835. At least it starts. I get a ton of errors and a simple , clean "hello word" obviously does not show in "TCF Debug Process Terminal" where I get all the coded messages and responses when I run same code on BCM2837. I have been advised to check and possibly reinstall TCF Agent when connected to BCM2835. I need to find, again, the real, not 3rd party copies, of TCF Agent installation tutorial. However, if it solves the problem it kinda-of defeats the "universal" purpose of TCF. Many thanks for your input. PS Forgive OF ,senior moment, you are in Holland , right?
-
Thanks Leon. Here is "MY problem" - as far as I can tell I am ONLY setting "Cross compiler prefix" as "arm-linux-gnueabihf-" and "Path" where it can be found as "/usr/bin". I have no idea where this "prefix" came from - I have been at this project for a while , off and on. It shows up in "include" tree on the Eclipse project form. The code complies and runs on BCM2837 - RPi 3B. Without changing any GCC setting the code compiles and sort of runs on BCM2835. At least it starts. I get a ton of errors and a simple , clean "hello word" obviously does not show in "TCF Debug Process Terminal" where I get all the coded messages and responses when I run same code on BCM2837. I have been advised to check and possibly reinstall TCF Agent when connected to BCM2835. I need to find, again, the real, not 3rd party copies, of TCF Agent installation tutorial. However, if it solves the problem it kinda-of defeats the "universal" purpose of TCF. Many thanks for your input. PS Forgive OF ,senior moment, you are in Holland , right?
No I am in Australia .. ancestors are Dutch, South African Anyhow you have many and varied problems ... Now all GCC have a name format called ABC
Quote:
GCC A-B-C name convention A indicates the target (arm for AArch32 little-endian, aarch64 for AArch64 little-endian). B indicates the vendor (none or unknown for generic) . Note that this is optional (Eg: not present in arm-linux-gnueabihf) C indicates the ABI in use (linux-gnu* for Linux, linux-android* for Android, elf or eabi for ELF based bare-metal). C has values which seem odd until you understand the history behind it (basically AArch32 used to have a linux-gnu ABI which got changed so needed a new name so we have linux-gnueabi). For AArch32 we have linux-gnueabi and linux-gnueabihf which indicate soft float, and hard float respectively. The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.
So you have A-C your compiler is linux gnu and the output is hard floats. What it doesn't tell me is if you are compiling on Raspbian Pi or some other linux version because that isn't inbuilt into the name. What I do know is you are putting out the right thing if you are trying to do baremetal. Now the big problem there are big differences between where peripherals are and what they do between a Pi1, Pi2, Pi3. So first the peripheral base address is different on a Pi1 all peripherals are at 0x20000000 on a Pi2/Pi3 they are at 0x3F000000 So that means if you ever see a peripheral with 0x20xxxxxx you know it is for a Pi1 and if you are on a Pi3 you need to change it to 0x3Fxxxxxx. There are no exceptions every peripheral is physically moved to allow for more memory. The converse is also true any address with 0x3Fxxxxxx is for a Pi3 and wont work on a Pi1 and you change the first two to 0x20xxxxxx Generally we #define a variable called PI_IO_BASE or such and we just change that one number the alternative is you can autodetect it by looking for USB hub vendor string which is on every model. The logic goes look at the Pi location if it isnt there its at the other.
volatile uint32_t* vendorid = (uint32_t*)0x20980040;
if (*vendorid == 0x4F54280A) PI_IO_BASE = 0x20000000;
else PI_IO_BASE = 0x3F000000;So you deal with that fi
-
No I am in Australia .. ancestors are Dutch, South African Anyhow you have many and varied problems ... Now all GCC have a name format called ABC
Quote:
GCC A-B-C name convention A indicates the target (arm for AArch32 little-endian, aarch64 for AArch64 little-endian). B indicates the vendor (none or unknown for generic) . Note that this is optional (Eg: not present in arm-linux-gnueabihf) C indicates the ABI in use (linux-gnu* for Linux, linux-android* for Android, elf or eabi for ELF based bare-metal). C has values which seem odd until you understand the history behind it (basically AArch32 used to have a linux-gnu ABI which got changed so needed a new name so we have linux-gnueabi). For AArch32 we have linux-gnueabi and linux-gnueabihf which indicate soft float, and hard float respectively. The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.
So you have A-C your compiler is linux gnu and the output is hard floats. What it doesn't tell me is if you are compiling on Raspbian Pi or some other linux version because that isn't inbuilt into the name. What I do know is you are putting out the right thing if you are trying to do baremetal. Now the big problem there are big differences between where peripherals are and what they do between a Pi1, Pi2, Pi3. So first the peripheral base address is different on a Pi1 all peripherals are at 0x20000000 on a Pi2/Pi3 they are at 0x3F000000 So that means if you ever see a peripheral with 0x20xxxxxx you know it is for a Pi1 and if you are on a Pi3 you need to change it to 0x3Fxxxxxx. There are no exceptions every peripheral is physically moved to allow for more memory. The converse is also true any address with 0x3Fxxxxxx is for a Pi3 and wont work on a Pi1 and you change the first two to 0x20xxxxxx Generally we #define a variable called PI_IO_BASE or such and we just change that one number the alternative is you can autodetect it by looking for USB hub vendor string which is on every model. The logic goes look at the Pi location if it isnt there its at the other.
volatile uint32_t* vendorid = (uint32_t*)0x20980040;
if (*vendorid == 0x4F54280A) PI_IO_BASE = 0x20000000;
else PI_IO_BASE = 0x3F000000;So you deal with that fi
Thanks, I am embarrassed , I think you told me the "prefix format" long time ago. I am just getting too old for all this stuff. My uncle whom I never met "emigrated " in 1948 to Australia after Communists took over. We for obvious reasons we did not keep in touch, but I remember in the only letter we got from him he said he bought Jawa, Czech made, motorcycle and eating prawns was a "shell spitting affair". Of course we knew about Jawa , but prawns? I think with computers abilities I could do some search for relatives still living in "down under". I just reinstalled TCF and can run its diagnostic test. Still no output to TCF terminal. But its a start. I actually build simple "hello world" app and that should (?) work independently from memories of these processors. I think the processor dependencies or in-dependencies is "hidden" somewhere in TCF make. But that is little out of my league. Cheers
-
Thanks, I am embarrassed , I think you told me the "prefix format" long time ago. I am just getting too old for all this stuff. My uncle whom I never met "emigrated " in 1948 to Australia after Communists took over. We for obvious reasons we did not keep in touch, but I remember in the only letter we got from him he said he bought Jawa, Czech made, motorcycle and eating prawns was a "shell spitting affair". Of course we knew about Jawa , but prawns? I think with computers abilities I could do some search for relatives still living in "down under". I just reinstalled TCF and can run its diagnostic test. Still no output to TCF terminal. But its a start. I actually build simple "hello world" app and that should (?) work independently from memories of these processors. I think the processor dependencies or in-dependencies is "hidden" somewhere in TCF make. But that is little out of my league. Cheers
Yes Hello.C just uses all linux calls what may be problematic is if you use floats. GCC still defaults to some standard hard float and they are different on each model. So the very minimum I would specify the flags for the model. What I forgot to tell you is if you use the flags for the Pi1 the produced code will work on all other models. The models are supersets of each other. It a bit like intel processors if we lined i386, i486, i586 code written for i386 runs on i486 and i586 however i586 code wont always run on i386 because it has extra instructions. Same with arm ARM6 < ARM7 < ARM8 so ARM6 code runs on any model but ARM8 code has extra codes and may not run on ARM. So I would start with Pi1 flags which should work on all models
-mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
In vino veritas
-
Yes Hello.C just uses all linux calls what may be problematic is if you use floats. GCC still defaults to some standard hard float and they are different on each model. So the very minimum I would specify the flags for the model. What I forgot to tell you is if you use the flags for the Pi1 the produced code will work on all other models. The models are supersets of each other. It a bit like intel processors if we lined i386, i486, i586 code written for i386 runs on i486 and i586 however i586 code wont always run on i386 because it has extra instructions. Same with arm ARM6 < ARM7 < ARM8 so ARM6 code runs on any model but ARM8 code has extra codes and may not run on ARM. So I would start with Pi1 flags which should work on all models
-mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
In vino veritas
Leon, I have added -mcpu as suggested and got this error. I did put it in both g and g++ compiler options, it shudl be benn in g== only , right ? But it did not "fixed" the error. So it is not there anymore. I think I am looking at the result - no TCF Debug Process Terminal output , but I should be looking at WHY the app really does not start.
19:25:19 **** Build of configuration Debug for project Zero ****
make all
Building file: ../src/Zero.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-g++ -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -v -MMD -MP -MF"src/Zero.d" -MT"src/Zero.o" -o "src/Zero.o" "../src/Zero.cpp"
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-mcpu=arm1176jzf-s' '-mfpu=vfp' '-mfloat-abi=hard' '-v' '-MMD' '-MP' '-MF' 'src/Zero.d' '-MT' 'src/Zero.o' '-o' 'src/Zero.o' '-shared-libgcc' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/cc1plus -quiet -v -imultia -
Leon, I have added -mcpu as suggested and got this error. I did put it in both g and g++ compiler options, it shudl be benn in g== only , right ? But it did not "fixed" the error. So it is not there anymore. I think I am looking at the result - no TCF Debug Process Terminal output , but I should be looking at WHY the app really does not start.
19:25:19 **** Build of configuration Debug for project Zero ****
make all
Building file: ../src/Zero.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-g++ -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -v -MMD -MP -MF"src/Zero.d" -MT"src/Zero.o" -o "src/Zero.o" "../src/Zero.cpp"
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-mcpu=arm1176jzf-s' '-mfpu=vfp' '-mfloat-abi=hard' '-v' '-MMD' '-MP' '-MF' 'src/Zero.d' '-MT' 'src/Zero.o' '-o' 'src/Zero.o' '-shared-libgcc' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/cc1plus -quiet -v -imultiaI just found this It is more complicated than I thought: -mtune, -march in GCC – Daniel Lemire's blog[^] I am not done reading - but I am crosscompiling - from IDE on PC and executable on RPi so -march should identify RPi processor - right? In "G++ crosscompiler" settings? This is giving me a headache...
-
I just found this It is more complicated than I thought: -mtune, -march in GCC – Daniel Lemire's blog[^] I am not done reading - but I am crosscompiling - from IDE on PC and executable on RPi so -march should identify RPi processor - right? In "G++ crosscompiler" settings? This is giving me a headache...
I think what it is complaining about is you are obviously on ubuntu linux and the float and ABI setup is different because it's a different flavour of linux. What would be fastest just to see if we are right is copy the code onto a SD media and try compiling it on the Pi, GCC is pre-installed. If it is sudo apt-get gcc. Just want to confirm it is the cross compiling that is causing the problem. It should compile without any complaining on the Pi itself. If that works I will sort out the issue on ubuntu and I just need version and 32 or 64 bit?
In vino veritas
-
I think what it is complaining about is you are obviously on ubuntu linux and the float and ABI setup is different because it's a different flavour of linux. What would be fastest just to see if we are right is copy the code onto a SD media and try compiling it on the Pi, GCC is pre-installed. If it is sudo apt-get gcc. Just want to confirm it is the cross compiling that is causing the problem. It should compile without any complaining on the Pi itself. If that works I will sort out the issue on ubuntu and I just need version and 32 or 64 bit?
In vino veritas
-
Short reply - same code runs on RPi 3B , perhaps swapping SD between 3B an Zero is not a good idea. But in theory the OS should be smart enough to know what hardware it is running on. I'll try clean OS install on Zero next.
Would you take the boot drive out of a PC and expect it to be able to run inside a different model PC without problems? I don't think so.
The difficult we do right away... ...the impossible takes slightly longer.
-
Would you take the boot drive out of a PC and expect it to be able to run inside a different model PC without problems? I don't think so.
The difficult we do right away... ...the impossible takes slightly longer.
Too simplified reasoning. I am pass evaluating OS , I believe the issue is how GCC interacts with TCF in ARM6. It has been established that RPi 0 an 1 are using ARM6 and RPi 2 and up are using ARM 7. ARM6 "code" will run on ARM7, but ARM7 will not run on ARM6. My code runs fine on ARM7, but not on ARM6. Exactly opposite expectations. I did verify that TCF was build for ARM6 , but it is failing on ARM6 processor- where is should be "native". The whole point of this troubleshooting is to find out - at lest in theory, what is happening. I am in process of comparing compilation outputs on ARM6 versus ARM7. I have not figured out how to verify / debug the running TCF code on either processor. It is little time consuming process keep switching between RPi's. But I do appreciate any input to help solve this.
-
Would you take the boot drive out of a PC and expect it to be able to run inside a different model PC without problems? I don't think so.
The difficult we do right away... ...the impossible takes slightly longer.
Richard .. It is trivial I do it all the time even in baremetal. That is a bit like saying 386 code should not run on 486, 586, 686 etc Val I do the change SD card from Pi1,Pi2, Pi3, Pi ZeroW every day of week it is not an issue. My zero's for example don't have a screen I have to put the SD card into a 2 or 3 to edit configs. I would also add the Raspbian install image doesn't ask you what model you are on or have different installs :-) Throw what you are doing up on Github or a website Val and I will have a look and sort it out. Anything you compile for ARM6 should definitely work on any ARM7/ARM8 model Pi so long as you deal with the couple of small differences if you start poking registers.
In vino veritas
-
Richard .. It is trivial I do it all the time even in baremetal. That is a bit like saying 386 code should not run on 486, 586, 686 etc Val I do the change SD card from Pi1,Pi2, Pi3, Pi ZeroW every day of week it is not an issue. My zero's for example don't have a screen I have to put the SD card into a 2 or 3 to edit configs. I would also add the Raspbian install image doesn't ask you what model you are on or have different installs :-) Throw what you are doing up on Github or a website Val and I will have a look and sort it out. Anything you compile for ARM6 should definitely work on any ARM7/ARM8 model Pi so long as you deal with the couple of small differences if you start poking registers.
In vino veritas
Leon, sorry for late reply. Here is (another) short update . I may have already said that the only option for crosscompliing is the "prefix"
arm-linux-gnueabihf
so this may be dupe. With that "prefix" the crosscompiler comes up with -march=arm7... So I added -march=armv6 ( for Zero) and got this
/usr/arm-linux-gnueabihf/include/c++/5/exception:63:39: sorry, unimplemented: Thumb-1 hard-float VFP ABI
exception() _GLIBCXX_USE_NOEXCEPT { }
^
src/subdir.mk:18: recipe for target 'src/Zero.o' failedAdding -marm gets rid of the problem. I did briefly check what -marm option does and it is related to some switching between things. Unimportant at this time - I just wanted clean compile. The "bottom line" _ I can actually run Eclipse and in "debug" perspective I get "TCF Agent disconnected ' Permission denied. " I have seen this error long time ago when I started with TCF - turned out to be related to running "TCF Agent " as root. BUT TCF Agent runs in root as default while using RPi 3B - so the problem MUST be somewhere else. BTW I am having heck of time using " newest and greatest Eclipse " I would like to try some other C++ IDE to run in crosscompile / TCF mode instead of Eclipse. Cheers and thanks.
-
Leon, sorry for late reply. Here is (another) short update . I may have already said that the only option for crosscompliing is the "prefix"
arm-linux-gnueabihf
so this may be dupe. With that "prefix" the crosscompiler comes up with -march=arm7... So I added -march=armv6 ( for Zero) and got this
/usr/arm-linux-gnueabihf/include/c++/5/exception:63:39: sorry, unimplemented: Thumb-1 hard-float VFP ABI
exception() _GLIBCXX_USE_NOEXCEPT { }
^
src/subdir.mk:18: recipe for target 'src/Zero.o' failedAdding -marm gets rid of the problem. I did briefly check what -marm option does and it is related to some switching between things. Unimportant at this time - I just wanted clean compile. The "bottom line" _ I can actually run Eclipse and in "debug" perspective I get "TCF Agent disconnected ' Permission denied. " I have seen this error long time ago when I started with TCF - turned out to be related to running "TCF Agent " as root. BUT TCF Agent runs in root as default while using RPi 3B - so the problem MUST be somewhere else. BTW I am having heck of time using " newest and greatest Eclipse " I would like to try some other C++ IDE to run in crosscompile / TCF mode instead of Eclipse. Cheers and thanks.
OK, here is the latest. I compile C++ code for armv6 and run ( identical ) TCF Agent software ( the latest) on Raspberry Pi 3B and it works. Produce “hello word” output. Same setup fails on Raspberry Pi Zero. No output whatsoever. The ONLY difference is - I select appropriate WiFI connection for each hardware - on Eclipse TCF configuration - swapping Agent IP ! Same WiFi configuration ! ( Yes, I have BOTH RPi powered and running ) At this point I have exhausted pretty much all software options. I am open to suggestions - one being "ditch Zero"
-
OK, here is the latest. I compile C++ code for armv6 and run ( identical ) TCF Agent software ( the latest) on Raspberry Pi 3B and it works. Produce “hello word” output. Same setup fails on Raspberry Pi Zero. No output whatsoever. The ONLY difference is - I select appropriate WiFI connection for each hardware - on Eclipse TCF configuration - swapping Agent IP ! Same WiFi configuration ! ( Yes, I have BOTH RPi powered and running ) At this point I have exhausted pretty much all software options. I am open to suggestions - one being "ditch Zero"
One more to discuss. To crosscompile C++ code I specify this "prefix"
arm-linux-gnueabihf
Already beaten to death. The output from both "cross" compiler and linker only reference to hardware is "arm7". After reading up on how crosscomplier works - there shoudl be "--host","--build" and " --target" options to specify (what ? OS / hardware ?) somewhere. There are none! The only one is - as mentioned - the "magical " arm7.
-
One more to discuss. To crosscompile C++ code I specify this "prefix"
arm-linux-gnueabihf
Already beaten to death. The output from both "cross" compiler and linker only reference to hardware is "arm7". After reading up on how crosscomplier works - there shoudl be "--host","--build" and " --target" options to specify (what ? OS / hardware ?) somewhere. There are none! The only one is - as mentioned - the "magical " arm7.
OK, I was wrong Here is what is in output - both compiler and linker
--build=x86_64-linux-gnu --host=x86_64-linux-gnu –target=arm-linux-gnueabihf
This is what I am reading ( into it) - in English "build" C++ code ( on OS (?)
x86_64-linux-gnu
) "host" is OS(?)
x86_64-linux-gnu
and "host" does what ? and the code will run on "target "
arm-linux-gnueabihf
So where is the "target" (armv6l) (?) specification - hardware , OS , etc . ? Am I finally asking right questions? Do I need better terminology ? Would it help to post the entire output?
