I am getting back to doing some Gentoo building on various arm single board computers.
I have a question concerning if there is any advantages to setting EXTRA_ECONF for cortex a9 or cortex a7.
I have a matrix mini pc that is the Freescale imx6q 4 core cortex a9 as well as a banana pi which is the Allwinner a20 2 core cortex a7. I also have a raspberry pi and beaglebone black, and have already built gentoo on them long ago, but currently running risc os, have no reason to run gentoo, as the other boards have sata and 1000Mbs ethernet. Major improvement overall running the OS off an ssd rather than an sdcard, real shame the raspberry pi 2 lacks sata and 1000Mbs ethernet. I have already run gentoo and arch linux on the banana pi, but getting some new ssd's and new boards, so moving things around and want to do some clean installs, and get everything the way I want it.
Since I do distcc with a number of computers in my network, I would have to make sure to rebuild each with the corresponding cortex number, therefore wondering if it is really worth it. Or some how have two cortex versions of the same armv7a-hardfloat-linux-gnueabihf installed and available.
Which gets to my next question. Some of the manufacturers docs state a preference for armv7a-hardfloat-linux-gnueabihf over armv7a-hardfloat-linux-gnueabi. Which makes me wonder if the CHOST line in the make.conf needs to be changed to reflect the actual version that is being used to compile with.
Even though I do doubt the CHOST needs to be changed, and that setting specific extra's for the cortex number is probably not really necessary. I would appreciate any input or additional details someone might have.
Question about Crossdev EXTRA_ECONF="--with-cpu=cortex9"
Message
Here's an update to what I have found in documents spread out from hell to high water. 
The below pertains specifically to the Banana Pi. The board I just received is different than the older board I have. Various chips are in different locations, though all the connectors are in the same place. They clearly redesigned the board, though it appears the primary specs are the same.
Yes the armv7a-hardfloat-linux-gnueabihf is a CHOST setting, you can change your CHOST setting to that. According to the gentoo arm chost list, it is the future hardfp. It appears as though that might or might not eventually supplant the armv7a-hardfloat-linux-gnueabi hard float release, reading stuff from various people who have been working on the hard float adoption, it may be a split that ends up being the primary hard float release.
Yes setting the cortex a7 or a8, a9, a15 is beneficial, the a8 came out prior to the a7, while the a7 supposedly is faster, if the docs I read are true. An a15 cortex build will run on a7 cortex chip, a bit slower. I am assuming they are referencing to slower than on an a15 chip but not necessary slower than an a7 cortex build on an a7 cortex chip, the a15 build is 100% compatible on the a7 chip. The a15 cortex provides for new virtualization instructions, integer divide support and 40-bit memory addressing. Which makes me wonder if it would be more beneficial to run an a15 build on an a7 chip. This allows for a big.little configuration. a15 chip doing the heavy lifting then when workload requirements are low switching to the a7 chip, on a board with both an a7 and a15 chip.
Also to take advantage of the specific cortex setting you must add "-mtune=cortex-a7" to your CFLAGS. Of course if you are utlilizing distcc, you want to add EXTRA_ECONF="--with-cpu=cortex7 or what ever your chip cortex is when building your cross compile.
This is what I have done so far.
1. Change CHOST to armv7a-hardfloat-linux-gnueabihf
2. Add -mtune=cortex-a7 to the CFLAGS
3. emerge distcc: don't forget to do the wrapper and change links in /usr/lib/distcc/bin per the wiki distcc cross compiling page
2. emerge binutils gcc glibc: per the Changing the CHOST variable wiki page
distcc emerged fine and currently binutils is compiling with no errors for the past 50 mins, long ways to go, as as far as my understanding is, non of these will utilize distcc.
I did place /tmp and /var/tmp in a tmpfs. 65% for /var/tmp and 20% for /tmp, which gives 631m for /var/tmp and 195m for /tmp.
So far I have seen no more than 252m used in /var/tmp and from 135m to 431m free while compiling binutils. gcc will most probably be the real test!
If all goes well, will do a:
emerge -eav system
emerge -eav world
Simply to ensure that everything is built with the chost and cflags change.
Got a no space left on device with gcc. Not unexpected, only one way to find out for sure. Ok back to doing everything off the ssd.
I could set up a nfs off of ram with one of my other box's, but want to run everything natively just to see how it goes.
The below pertains specifically to the Banana Pi. The board I just received is different than the older board I have. Various chips are in different locations, though all the connectors are in the same place. They clearly redesigned the board, though it appears the primary specs are the same.
Yes the armv7a-hardfloat-linux-gnueabihf is a CHOST setting, you can change your CHOST setting to that. According to the gentoo arm chost list, it is the future hardfp. It appears as though that might or might not eventually supplant the armv7a-hardfloat-linux-gnueabi hard float release, reading stuff from various people who have been working on the hard float adoption, it may be a split that ends up being the primary hard float release.
Yes setting the cortex a7 or a8, a9, a15 is beneficial, the a8 came out prior to the a7, while the a7 supposedly is faster, if the docs I read are true. An a15 cortex build will run on a7 cortex chip, a bit slower. I am assuming they are referencing to slower than on an a15 chip but not necessary slower than an a7 cortex build on an a7 cortex chip, the a15 build is 100% compatible on the a7 chip. The a15 cortex provides for new virtualization instructions, integer divide support and 40-bit memory addressing. Which makes me wonder if it would be more beneficial to run an a15 build on an a7 chip. This allows for a big.little configuration. a15 chip doing the heavy lifting then when workload requirements are low switching to the a7 chip, on a board with both an a7 and a15 chip.
Also to take advantage of the specific cortex setting you must add "-mtune=cortex-a7" to your CFLAGS. Of course if you are utlilizing distcc, you want to add EXTRA_ECONF="--with-cpu=cortex7 or what ever your chip cortex is when building your cross compile.
This is what I have done so far.
1. Change CHOST to armv7a-hardfloat-linux-gnueabihf
2. Add -mtune=cortex-a7 to the CFLAGS
3. emerge distcc: don't forget to do the wrapper and change links in /usr/lib/distcc/bin per the wiki distcc cross compiling page
2. emerge binutils gcc glibc: per the Changing the CHOST variable wiki page
distcc emerged fine and currently binutils is compiling with no errors for the past 50 mins, long ways to go, as as far as my understanding is, non of these will utilize distcc.
I did place /tmp and /var/tmp in a tmpfs. 65% for /var/tmp and 20% for /tmp, which gives 631m for /var/tmp and 195m for /tmp.
So far I have seen no more than 252m used in /var/tmp and from 135m to 431m free while compiling binutils. gcc will most probably be the real test!
If all goes well, will do a:
emerge -eav system
emerge -eav world
Simply to ensure that everything is built with the chost and cflags change.
Got a no space left on device with gcc. Not unexpected, only one way to find out for sure. Ok back to doing everything off the ssd.
I could set up a nfs off of ram with one of my other box's, but want to run everything natively just to see how it goes.
gcc failed during the configure phase: checking for armv7a-hardfloat-linux-gnueabihf-gcc... no
The config.log shows:
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
Did some searches and checked bug list, some similar stuff, but nothing conclusive. Changed back to armv7a-hardfloat-linux-gnueabi took out the -mtune=cortex-a7 and same result. Now distcc will not compile with the same errors, despite the ghost and cflags being reverted to the original settings, even though it compiled just fine earlier with the changed ghost and cflags. Something must of got borked. Time to start over.
The config.log shows:
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
Did some searches and checked bug list, some similar stuff, but nothing conclusive. Changed back to armv7a-hardfloat-linux-gnueabi took out the -mtune=cortex-a7 and same result. Now distcc will not compile with the same errors, despite the ghost and cflags being reverted to the original settings, even though it compiled just fine earlier with the changed ghost and cflags. Something must of got borked. Time to start over.
Ok it appears that there is some hardcoding in gcc concerning armv7a-hardfloat-linux-gnueabi, so using armv7a-hardfloat-linux-gnueabihf to compile gcc might not work. I found a number of references to this, as it should not be hardcoded, but apparently gcc in some cases does not take into account the change to the GHOST setting in the make.conf.
Therefore it is probably best to stick with armv7a-hardfloat-linux-gnueabi for now.
As for CFLAGS, there is a considerable amount of flags that can be used, depending on your need, or processor. The -mfpu=vfpv3-d16 is fine for the older cortex processors, but does not provide for full functionality with the cortex-a7 and cortex-a15 processors.
The first link is a short description of the differences and how to get NEON, DSP, SIMD to work. If you are using your board, for music, movies, media center and such, and your processor can use NEON, you want to use it. In the older armv6 NEON provided for a 75% performance increase for audio and video processing.
http://community.arm.com/groups/tools/b ... mand-lines
http://www.arm.com/products/processors/ ... s/neon.php
http://www.arm.com/products/processors/ ... p-simd.php
http://infocenter.arm.com/help/index.js ... IIFHA.html
https://gcc.gnu.org/onlinedocs/gcc-4.8. ... RM-Options
I am getting ready to try with the below cflags, do keep in mind if you are using distcc, you should use the identical in the cxxflags.
CFLAGS="-O3 -pipe -march=armv7-a -mcpu=cortex-a7 -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
Just to see what lemaker is using for their gentoo release. I took a look, they have made no adjustments what so ever to the make.conf. I am not surprised, as when they first came out with the banna pi, they were using the raspbery pi armv6 binary for their arch linux release, despite the banana pi being and armv7. My past discussions with them, I found that the are ignorant when it comes to Linux, despite their claims to be Phd's and undergraduates in computer science. Clearly some of that is due to the language barrier.
Lemaker's gentoo release uses dd to burn the image to an sd card. They have no stage3 or stage4 gentoo release, says a lot about them. The fact that they have made no adjustments to the cflags clearly points out that they have no clue as to what they are doing.
I give them credit for their enthusiasm, though they really should take some time and better understand Linux. Personally, I stay away from their code, because I have seen them get so much wrong. Now that the ethernet issue has been fixed/set in u-boot by upstream, no need to use the lemaker kernel patch. So gentoo-sources will probably work now.
Sunxi is not very ingratiating in their description.
http://linux-sunxi.org/LeMaker_Banana_Pi
Therefore it is probably best to stick with armv7a-hardfloat-linux-gnueabi for now.
As for CFLAGS, there is a considerable amount of flags that can be used, depending on your need, or processor. The -mfpu=vfpv3-d16 is fine for the older cortex processors, but does not provide for full functionality with the cortex-a7 and cortex-a15 processors.
The first link is a short description of the differences and how to get NEON, DSP, SIMD to work. If you are using your board, for music, movies, media center and such, and your processor can use NEON, you want to use it. In the older armv6 NEON provided for a 75% performance increase for audio and video processing.
http://community.arm.com/groups/tools/b ... mand-lines
http://www.arm.com/products/processors/ ... s/neon.php
http://www.arm.com/products/processors/ ... p-simd.php
http://infocenter.arm.com/help/index.js ... IIFHA.html
https://gcc.gnu.org/onlinedocs/gcc-4.8. ... RM-Options
I am getting ready to try with the below cflags, do keep in mind if you are using distcc, you should use the identical in the cxxflags.
CFLAGS="-O3 -pipe -march=armv7-a -mcpu=cortex-a7 -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
Just to see what lemaker is using for their gentoo release. I took a look, they have made no adjustments what so ever to the make.conf. I am not surprised, as when they first came out with the banna pi, they were using the raspbery pi armv6 binary for their arch linux release, despite the banana pi being and armv7. My past discussions with them, I found that the are ignorant when it comes to Linux, despite their claims to be Phd's and undergraduates in computer science. Clearly some of that is due to the language barrier.
Lemaker's gentoo release uses dd to burn the image to an sd card. They have no stage3 or stage4 gentoo release, says a lot about them. The fact that they have made no adjustments to the cflags clearly points out that they have no clue as to what they are doing.
I give them credit for their enthusiasm, though they really should take some time and better understand Linux. Personally, I stay away from their code, because I have seen them get so much wrong. Now that the ethernet issue has been fixed/set in u-boot by upstream, no need to use the lemaker kernel patch. So gentoo-sources will probably work now.
Sunxi is not very ingratiating in their description.
http://linux-sunxi.org/LeMaker_Banana_Pi
Nice post, Vulgar.
Yeah, you need to use gnueabi, and add the vfpu/neon flags to CFLAGS (and CXXFLAGS which is usually the same), as you have done.
Just ensure FFLAGS and FCFLAGS pick up the settings too; see this [post=7513780]post about per-package flags[/post] to see what I mean. You may find you need exactly that for some packages.
#gentoo-embedded on IRC: chat.freenode.net for anyone who's unaware of it.
Yeah, you need to use gnueabi, and add the vfpu/neon flags to CFLAGS (and CXXFLAGS which is usually the same), as you have done.
Just ensure FFLAGS and FCFLAGS pick up the settings too; see this [post=7513780]post about per-package flags[/post] to see what I mean. You may find you need exactly that for some packages.
#gentoo-embedded on IRC: chat.freenode.net for anyone who's unaware of it.
Thanks for the additional tips steveL, that is why I posted. Every little bit helps.
Below are the settings I ended up getting to work compiling everything with but one error for utils-linux. Which was a matter of changing MAKEOPTS="-j41 -l2" to MAKEOPTS="-j1 -l2" as per others having the same problem with multiple con-current streams while compiling. It has to do with distcc running so many threads that a needed directory will not get placed in time for the needs of a different thread (/bin/sh: line 2: misc-utils/uuidd.8.tmp: No such file or directory).
utils-linux was the only ebuild that had this problem, while doing an "emerge --update --deep --with-bdeps=y --newuse world -av" which called for 44 updates after installing some basic tools and distcc from the base stage3 tarball.
One thing I did notice during compiling was a warning: "switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [enabled by default]" After removing -mcpu=cortex-a7 I saw no more warnings.
Here is what I have in my make.conf
CFLAGS="-O3 -pipe -march=armv7-a -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
CXXFLAGS="-O3 -pipe -march=armv7-a -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
CHOST="armv7a-hardfloat-linux-gnueabi"
MAKEOPTS="-j41 -l2"
USE="threads nptl nls bash-completion -systemd"
FEATURES="distcc distcc-pump"
Here is what I used for crossdev. The --with-march=armv7-a might be redundant and not necessary, just wanted to make sure the cortex-a7 switched on.
crossdev -S -P -v EXTRA_ECONF="--with-march=armv7-a --with-mfpu=neon-vfpv4 --with-ffast-math --with-mfloat-abi=hard" -t armv7a-hardfloat-linux-gnueabi
I did eventually find the below notes on the Sunxi wiki in different sections, they are rather conflicting. Not recommended to use gnueabihf in the makefile yet they state it can be used for the cross compiler. But never the less in actual practice the gnueabihf does not currently work, while the gnueabi does work.
["Equally it is possible to edit the default in the Makefile for the compiler used (not recommended) or install the toolchain as arm-linux-gnueabihf (not recommended either)"
"Even though Gentoo normally uses armv7a-hardfloat-linux-gnueabi as the toolchain triplet on ARM, we can also use Debian alike arm-linux-gnueabihf variant in order to be able to use the instructions from the linux-sunxi wiki as-is (without substituting the toolchain name). Building the crosscompiler is easy:"]
Anyways I hope some of this helps someone with getting things working smoothly for their banana pi. I have kept notes on my whole procedure, so I think I will do a banana pi instructions on the wiki.
It's great to see the arm stuff moving along faster, as more people get involved. Though finding the little details that are so important to the Gentoo way, are difficult to find due to so many projects with different needs and know how, spread all over the universe. With the Gentoo Wiki coming along nicely, it is going to get much easier to find Gentoo specific details.
Below are the settings I ended up getting to work compiling everything with but one error for utils-linux. Which was a matter of changing MAKEOPTS="-j41 -l2" to MAKEOPTS="-j1 -l2" as per others having the same problem with multiple con-current streams while compiling. It has to do with distcc running so many threads that a needed directory will not get placed in time for the needs of a different thread (/bin/sh: line 2: misc-utils/uuidd.8.tmp: No such file or directory).
utils-linux was the only ebuild that had this problem, while doing an "emerge --update --deep --with-bdeps=y --newuse world -av" which called for 44 updates after installing some basic tools and distcc from the base stage3 tarball.
One thing I did notice during compiling was a warning: "switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [enabled by default]" After removing -mcpu=cortex-a7 I saw no more warnings.
Here is what I have in my make.conf
CFLAGS="-O3 -pipe -march=armv7-a -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
CXXFLAGS="-O3 -pipe -march=armv7-a -mfpu=neon-vfpv4 -ffast-math -mfloat-abi=hard"
CHOST="armv7a-hardfloat-linux-gnueabi"
MAKEOPTS="-j41 -l2"
USE="threads nptl nls bash-completion -systemd"
FEATURES="distcc distcc-pump"
Here is what I used for crossdev. The --with-march=armv7-a might be redundant and not necessary, just wanted to make sure the cortex-a7 switched on.
crossdev -S -P -v EXTRA_ECONF="--with-march=armv7-a --with-mfpu=neon-vfpv4 --with-ffast-math --with-mfloat-abi=hard" -t armv7a-hardfloat-linux-gnueabi
I did eventually find the below notes on the Sunxi wiki in different sections, they are rather conflicting. Not recommended to use gnueabihf in the makefile yet they state it can be used for the cross compiler. But never the less in actual practice the gnueabihf does not currently work, while the gnueabi does work.
["Equally it is possible to edit the default in the Makefile for the compiler used (not recommended) or install the toolchain as arm-linux-gnueabihf (not recommended either)"
"Even though Gentoo normally uses armv7a-hardfloat-linux-gnueabi as the toolchain triplet on ARM, we can also use Debian alike arm-linux-gnueabihf variant in order to be able to use the instructions from the linux-sunxi wiki as-is (without substituting the toolchain name). Building the crosscompiler is easy:"]
Anyways I hope some of this helps someone with getting things working smoothly for their banana pi. I have kept notes on my whole procedure, so I think I will do a banana pi instructions on the wiki.
It's great to see the arm stuff moving along faster, as more people get involved. Though finding the little details that are so important to the Gentoo way, are difficult to find due to so many projects with different needs and know how, spread all over the universe. With the Gentoo Wiki coming along nicely, it is going to get much easier to find Gentoo specific details.