BBB - Building the Linux Kernel

That's excellent, shabaz!  I'll follow along on one of my Gentoo boxes and add any Gentoo-specific lines to the document.  I don't expect many differences.

First of all I need to know the provinence of RHEL's ARM gcc variant.  Is it CodeSourcery, or is RedHat validating their own ARM compiler releases?  Gentoo has the following 3 ARM compiler  packages available in Portage, so if yours isn't one of these, Gentoo users will have to install a ggc-arm manually from some repo outside of Portage, not with the package manager:

* dev-embedded/sgpp-lite-arm-eabi-bin
     Available versions:  (2010.09.51) ~2010.09.51
     Homepage:            http://www.codesourcery.com/sgpp/lite/arm
     Description:         regular, validated releases of the GNU Toolchain for arm processors by CodeSourcery

* dev-embedded/sgpp-lite-arm-linux-bin
     Available versions:  (2010.09.50) ~2010.09.50
     Homepage:            http://www.codesourcery.com/sgpp/lite/arm
     Description:         regular, validated releases of the GNU Toolchain for arm processors by CodeSourcery

* dev-embedded/sgpp-lite-arm-uclinux-bin
     Available versions:  (2010.09.58) ~2010.09.58
     Homepage:            http://www.codesourcery.com/sgpp/lite/arm
     Description:         regular, validated releases of the GNU Toolchain for arm processors by CodeSourcery

PS. I sure hope the "2010" isn't a year, otherwise these ARM releases in Portage are clearly prehistoric.   Gentoo's own ARM  installation procedure doesn't use the above, which hints that those 3 packages are a historical relic.

Instead, Gentoo provides these instructions, specifically for BeagleBone, with cross tools installed using crossdev.

Regarding the kernel, the above link advises to get the kernel using:

git clone git://arago-project.org/git/projects/linux-am33x.git

Is that kernel similar to yours in respect of version and patches?  Reading about the Arago Project, I'm a bit worried about kernel biodiversity creeping in here.

If your ARM compiler is maintained and validated by RedHat themselves, I suspect that for full compatibility with your steps, Gentoo users will have to grab your source RPM and unpack it directly.  If so, it would help if you could identify the actual package filepath that your commands install.

[Fixed the almighty cocktail of compiler and kernel topics which made this post barely comprehensible.]

Hi Morgaine,

Morgaine Dinova wrote:

I'll follow along on one of my Gentoo boxes and add any Gentoo-specific lines to the document.  I don't expect many differences.

That's great! I hope the steps make sense, and it will be great to have them refined. I used RHEL for my Linux server, mainly because I'm not familiar with other variants, and the toolchain I used was one that was available pre-compiled via yum. But I did try CodeSourcery originally, and although it compiled the kernel, after TFTP'ing, it didn't work for me, but later I realized I was issuing the wrong u-boot parameters, so it's quite likely CodeSourcery is fine.  The CodeSourcery site (i.e. the Mentor Graphics site) did have much more recent toolchain dates, I had downloaded from there. In fact I've still got those steps because I was writing it as I went, I've pasted below. When it didn't work for me, I moved to the one via yum, and didn't get round to re-checking with CodeSourcery after I'd discovered the u-boot mistake I was making.

From that arago-project, I had only downloaded some blob. The kernel was downloaded using git clone git://github.com/beagleboard/kernel.git

That instruction was based on some websites that had instructions for Debian, but it seemed to work fine on my RHEL VM. I wish I knew how to get the exact tag for the releases though, because if I'm building the head of 3.8, then I'll never be sure what others may have checked-in I guess :-(

----------------------

The compiler is Sourcery CodeBench Lite Edition for ARM GNU/Linux (2013.05-24 version) from Mentor Graphics’ website

http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/lite/?cmpid=7108&lite=arm&target_os=GNU%2FLinux&target_arch=ARM&returnURL=https%253A%252F%252Fsourcery.mentor.com%252FGNUToolchain%252Fsubscription3057%253Flite%253Darm%2526cmpid%253D7108

Note: the current toolchains from the Angstrom site and from TI’s SDK both had issues building the kernel.

From that Mentor Graphics link, use the IA32 GNU/Linux TAR file rather than the installer

The downloaded file was put in the toolchain folder and extracted (it created an arm-2013.05 folder). The folder /home/username/develop/toolchain/arm-2013.05/bin is important, it contains the compile tools. The PATH environment variable needs to be updated to prepend this: (assuming bash shell)

Somehow I managed to conflate compiler and kernel provinence in my reply, so the combined post makes no sense at all.   I'll fix it in a bit and separate the two parts.

Meanwhile, I'm trying to aim for exact replication of your compiler and kernel, ie. specifically not doing your suggestion of using apt-get on a Debian/Ubuntu system for example, as that would produce a different end result.  Likewise, I'm trying to avoid installing the cross-compiler with Gentoo's "crossdev -S armv7a-hardfloat-linux-gnueabi" command, as that would likely be different.  (I might install it just to see where it comes from though.)

To confirm, when you did a "yum install gcc-arm-linux-gnu", that installed Sourcery CodeBench Lite Edition for ARM GNU/Linux (2013.05-24 version) from Mentor Graphics’ website?

The kernel part is clear, you got that from git://github.com/beagleboard/kernel.git

Hi Morgaine,

No, it was not the CodeSourcery version that got installed when I did the yum command, as far as I know.

This is the information that gcc-v and yum info reports (my VM was 32-bit unfortunately, I had the wrong ISO and didn't re-download it):

$ gcc -v

Using built-in specs.

Target: i686-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux

Thread model: posix

gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC)

$

# yum info gcc-arm-linux-gnu

Loaded plugins: refresh-packagekit, security

epel/metalink                                            |  19 kB     00:00    

epel                                                     | 4.2 kB     00:00    

epel/primary_db                                          | 4.4 MB     00:02    

sl                                                       | 2.5 kB     00:00    

sl-security                                              | 2.6 kB     00:00    

Installed Packages

Name        : gcc-arm-linux-gnu

Arch        : i686

Version     : 4.7.2

Release     : 2.aa.20121114svn.el6.1

Size        : 25 M

Repo        : installed

From repo   : epel

Summary     : Cross-build binary utilities for arm-linux-gnu

URL         : http://gcc.gnu.org

License     : GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and

            : LGPLv2+ and BSD

Description : Cross-build GNU C compiler.

            :

            : Only building kernels is currently supported.  Support for

            : cross-building user space programs is not currently provided as

            : that would massively multiply the number of packages.

#

However, some URLs were mentioning using different compilers such as gcc-4.7-arm-linux-gnueabi-base, and Vlad compiled using this one (he was going to try to TFTP it to his BBB last night, he is yet to report if it worked for him): apt-get install gcc-arm-linux-gnueabi

So, it looks like this URL is for the compiler:

http://pkgs.org/centos-6-rhel-6/epel-x86_64/gcc-arm-linux-gnu-4.7.2-2.aa.20121114svn.el6.1.x86_64.rpm.html (assuming RPM can work with Gentoo).

Ah, ok.  So, it seems the gcc-arm biodiversity explosion has already happened, and everyone will be using different versions, hehe.

No worries, I might as well use Gentoo's crossdev then.  Hopefully we won't hit specific compiler version dependencies.

Ah, cool. I'll kick off a build using CodeSourcery too, so we can confirm if it really works or not. You're right, it would be nice for us all to use a consistent compiler. I'll know in an hour to two!

Good news, it worked with the CodeSourcery build, so I think we can modify the notes on the elinux to specify the CodeSourcery one instead of the yum'med one.

Basically, I just changed the make lines to have this:

CROSS_COMPILE=arm-none-linux-gnueabi-

The gcc -v reported this:

$ ./arm-none-linux-gnueabi-gcc -v

Using built-in specs.

COLLECT_GCC=./arm-none-linux-gnueabi-gcc

COLLECT_LTO_WRAPPER=/home/shabaz/dev/toolchain/arm-2013.05/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper

Target: arm-none-linux-gnueabi

Configured with: /scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm} %{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables} -D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5 -D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion='Sourcery CodeBench Lite 2013.05-24' --with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc --with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --disable-libgomp --disable-libitm --enable-poison-system-directories --with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin

Thread model: posix

gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)

$

Here is the output:

U-Boot SPL 2013.04-dirty (May 20 2013 - 14:30:06)

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

musb-hdrc: MHDRC RTL version 2.0

musb-hdrc: setup fifo_mode 4

musb-hdrc: 28/31 max ep, 16384/16384 memory

USB Peripheral mode controller at 47401000 using PIO, IRQ 0

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

musb-hdrc: MHDRC RTL version 2.0

musb-hdrc: setup fifo_mode 4

musb-hdrc: 28/31 max ep, 16384/16384 memory

USB Host mode controller at 47401800 using PIO, IRQ 0

OMAP SD/MMC: 0

mmc_send_cmd : timeout: No status update

reading u-boot.img                                                                

reading u-boot.img                                                                

U-Boot 2013.04-dirty (May 20 2013 - 14:30:06)                                     

I2C:   ready                                                                      

DRAM:  512 MiB                                                                    

WARNING: Caches not enabled                                                       

NAND:  No NAND device found!!!                                                    

0 MiB                                                                             

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1                                             

*** Warning - readenv() failed, using default environment                         

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)    

musb-hdrc: MHDRC RTL version 2.0                                                  

musb-hdrc: setup fifo_mode 4                                                      

musb-hdrc: 28/31 max ep, 16384/16384 memory                                       

USB Peripheral mode controller at 47401000 using PIO, IRQ 0                       

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)    

musb-hdrc: MHDRC RTL version 2.0                                                  

musb-hdrc: setup fifo_mode 4                                                      

musb-hdrc: 28/31 max ep, 16384/16384 memory                                       

USB Host mode controller at 47401800 using PIO, IRQ 0                             

Net:   <ethaddr> not set. Validating first E-fuse MAC                             

cpsw, usb_ether                                                                   

Hit any key to stop autoboot:  0                                                  

U-Boot#                                                                           

U-Boot# setenv autoload no                                                        

U-Boot# dhcp                                                                      

link up on port 0, speed 100, full duplex                                         

BOOTP broadcast 1                                                                 

DHCP client bound to address 192.168.1.70                                         

U-Boot# setenv serverip 192.168.1.77                                              

U-Boot# tftp 0x80200000 uImage-BBB                                                

link up on port 0, speed 100, full duplex                                         

Using cpsw device                                                                 

TFTP from server 192.168.1.77; our IP address is 192.168.1.70                     

Filename 'uImage-BBB'.                                                            

Load address: 0x80200000                                                          

Loading: #################################################################        

         #################################################################        

         #################################################################        

         #################################################################        

         ################################                                         

         398.4 KiB/s                                                              

done                                                                              

Bytes transferred = 4278649 (414979 hex)                                          

U-Boot# setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

U-Boot# bootm 0x80200000                                                          

## Booting kernel from Legacy Image at 80200000 ...                               

   Image Name:   Linux-3.8.13-00653-g952337c                                      

   Image Type:   ARM Linux Kernel Image (uncompressed)                            

   Data Size:    4278585 Bytes = 4.1 MiB                                          

   Load Address: 80008000                                                         

   Entry Point:  80008000                                                         

   Verifying Checksum ... OK                                                      

   Loading Kernel Image ... OK                                                    

OK                                                                                

Starting kernel ...                                                               

Uncompressing Linux... done, booting the kernel.                                  

[    0.193441] omap2_mbox_probe: platform not supported                           

[    0.204099] tps65217-bl tps65217-bl: no platform data provided                 

[    0.276926] bone-capemgr bone_capemgr.8: slot #0: No cape found                

[    0.314034] bone-capemgr bone_capemgr.8: slot #1: No cape found                

[    0.351142] bone-capemgr bone_capemgr.8: slot #2: No cape found                

[    0.388250] bone-capemgr bone_capemgr.8: slot #3: No cape found                

[    0.407992] bone-capemgr bone_capemgr.8: slot #6: BB-BONELT-HDMIN conflict P8.4)

[    0.417594] bone-capemgr bone_capemgr.8: slot #6: Failed verification          

[    0.424362] bone-capemgr bone_capemgr.8: loader: failed to load slot-6 BB-BONEL)

[    0.446866] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed     

[    0.511770] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 47

[    0.523499] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.7) status -22    

[    0.530804] pinctrl-single 44e10800.pinmux: could not request pin 21 on device e

[    4.061736] systemd[1]: Failed to insert module 'autofs4'                      

[    4.329483] systemd[1]: Failed to open /dev/autofs: No such file or directory  

[    4.337096] systemd[1]: Failed to initialize automounter: No such file or direcy

[    4.345311] systemd[1]: Failed to set up automount Arbitrary Executable File Fo.

systemd-fsck[84]: Angstrom: clean, 50561/112672 files, 291946/449820 blocks       

[    8.441064] libphy: PHY 4a101000.mdio:01 not found                             

[    8.446112] net eth0: phy 4a101000.mdio:01 not found on slave 1                

.---O---.                                                                         

|       |                  .-.           o o                                      

|   |   |-----.-----.-----.| |   .----..-----.-----.                              

|       |     | __  |  ---'| '--.|  .-'|     |     |                              

|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |                              

'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'                              

                -'  |                                                             

                '---'                                                             

The Angstrom Distribution beaglebone ttyO0                                        

Angstrom v2012.12 - Kernel 3.8.13-00653-g952337c                                  

beaglebone login: root                                                            

Last login: Mon Jun 17 15:00:12 UTC 2013 on ttyO0                                 

root@beaglebone:~#

Morgaine Dinova wrote:

 

Ah, ok.  So, it seems the gcc-arm biodiversity explosion has already happened, and everyone will be using different versions, hehe.

 

Yes indeed

I have built BBB kernels using the instructions on the eewiki site http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel

and I have built kernels using the Angstrom method http://www.angstrom-distribution.org/building-angstrom, both these use the  Linaro toolchain.

shabaz wrote:

 

[    4.061736] systemd[1]: Failed to insert module 'autofs4'                      

 

[    4.329483] systemd[1]: Failed to open /dev/autofs: No such file or directory  

[    4.337096] systemd[1]: Failed to initialize automounter: No such file or direcy

[    4.345311] systemd[1]: Failed to set up automount Arbitrary Executable File Fo.

                                                                    

I take it these systemd[1]  boot errors are because the correct kernel modules have not been installed in /usr/lib/modules/

Hi Brian,

I'm not sure what is causing that output, you could be right. I also need to understand where to obtain the rest of the filesystem

too. I saw the same output you mention with the toolchain via yum too, so I think it is not related to the toolchain.

I saw that that the TI SDK does contain the rest of the file system, but I don't know how old it is. However, it is necessary to

download the SDK anyway, because it contains the graphics SDK inside it.

Hi Brian,

I'm not sure what is causing that output, you could be right. I also need to understand where to obtain the rest of the filesystem

too. I saw the same output you mention with the toolchain via yum too, so I think it is not related to the toolchain.

I saw that that the TI SDK does contain the rest of the file system, but I don't know how old it is. However, it is necessary to

download the SDK anyway, because it contains the graphics SDK inside it.

I was working with Arch linux earlier and had the exact same errors, it turned out I was running kernel 3.8.13-3-ARCH and when I looked in /usr/lib/modules I saw a subdirectory 3.8.13-1-ARCH  I forced an update of kernel and modules and the subdirectory was replaced to match the kernel...  and all the errors went away.

You need a step in your instructions for installing the modules.

Hi Brian,

I see on this site this instruction, which I seem to be missing:

~/kernel/kernel$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=$HOME/kernel/kernel/rootfs modules_install

I'm not sure what it does, I'll try it. Does it create a file system containing the modules that I will need to tftp do you think?

If you want a RHL/Centos style distro then you could try installing this root file system to go with your kernel from  http://www.redsleeve.org/ no idea if it will work (in theory it should) but I will give it a try when I get chance.

That's great!! I'm looking forward to trying it.

I would be extremely happy with this on the BBB!!

Me too, when I was in gainfull employment I used nothing but Centos and RHEL. I only got into Debian and Ubuntu because of the R-Pi.

It looks like a package repository is being built mainly for R-Pi but at least with RH/Centos the package source RPMs are easily available.

shabaz wrote:
 
~/kernel/kernel$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=$HOME/kernel/kernel/rootfs modules_install
I'm not sure what it does, I'll try it. Does it create a file system containing the modules that I will need to tftp do you think?

building and installing (or packaging) a kernel needs you to do a set of things:

1. make menuconfig (or make oldconfig if you have an appropriate .config already)
2. make  (compile everything)
3. make install (install just the kernel, but be careful with this as it may not do what you expect)
4. make modules_install (install the modules)
5. make headers_install (install the development headers into /usr/include/linux)

and possibly clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git or parts of it into /lib/firmware

The obvious problems start when you find out that by default, modules get installed into /lib/modules/<KERNELVER> on the build system. Largely this isn't what you want, especially if you're cross compiling (or packaging the result for a system that's not the build system).

There are other complications if you use the available features to seperate the source directory from the build directory so that you can use the same source for many different targets.

INSTALL_MOD_PATH lets you specify a prefix for the install location which means you can set it to something like /tmp/kernel-3.8.13 and your files end up under that directory instead of trampling all over the build system.

You can also do:

make headers_install INSTALL_HDR_PATH=/tmp/kernel-3.8.13/usr

in order to get the headers without trashing your build system.

What I do is to install all of the eventual kernel files into a temp directory, then create a tarball of that. This lets me compile once, and deploy that tarball to many different systems.

selsinork wrote:

directory instead of trampling all over the build system.

You can also do:

make headers_install INSTALL_HDR_PATH=/tmp/kernel-3.8.13/usr
in order to get the headers without trashing your build system.

 

I always make sure I am not logged in as root or with root privs when cross compiling kernels, I made that mistake once.

Brian Welsby wrote:

 

I always make sure I am not logged in as root or with root privs when cross compiling kernels, I made that mistake once.

building kernels isn't really that hard, unfortunately there's many traps and assumptions in the process that can catch out the unwary..

like you'll always be building for the running system, and that /lib/modules/'uname -r'/build is a sensible place to be looking for anything.

I almost always do build as root, partially for historic reasons, partially because that's how my build machines are setup. I do have a set of build scripts that have been carefully crafted to deal with the pitfalls though and I currently build about 15 target variations from a single source tree using the O= feature to create seperate build directories. So it's important to get it right or else I'd end up in all sorts of trouble very quickly.

The Kbuild system has lots of useful options to make your life easier, sadly they're not well understood as evidenced by the uname -r hackery that seems all to common.

shabaz wrote:

 

That's great!! I'm looking forward to trying it.

I would be extremely happy with this on the BBB!!

Well I have got it working,   there's a few tweeks required and it's rather late now so will document it all tomorrow.

Oh, wow, you've made my evening. Goodnight!!