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)

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!!

Brian Welsby wrote:

 

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

Hmm..  effectively they're due to systemd trying to do all sorts of unnecessary "I'm-a-resource-hungry-desktop-app" nonesense. A huge chunk of what systemd does could easily be considered a simple waste of precious resources on a small embedded system.

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:

 

Brian Welsby wrote:

 

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

Hmm..  effectively they're due to systemd trying to do all sorts of unnecessary "I'm-a-resource-hungry-desktop-app" nonesense. A huge chunk of what systemd does could easily be considered a simple waste of precious resources on a small embedded system.

Yes one of the first things I did with Angstrom was use systemctl to disable/remove unnecessary stuff,  just like MS Windoze really .. (sorry for swearing).

I too hate systemd.

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!!

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

Ok this is how I got the redsleeve distro working.

First create a bootable SD card, I followed the instructions here and installed Ubuntu 12.04.2 LTS then checked it booted up and worked

When I plugged this into my desktop it appears as /dev/sdb1 and /dev/sdb2 devices. /dev/sdb2 is the one we are interested in.

Download the redsleeve root file system http://ftp.redsleeve.org/pub/yum/os/rsel6-rootfs.tar.bz2

extract with tar -xvf rsel6-rootfs.tar.bz2 and this creates a directory rsel6-rootfs containing the file system.

Mount /dev/sdb2 somewhere - on my system it auto mounted as /media/rootfs_

Now copy the kernel boot, modules and firmware into the rsel6-rootfs file system

cp -R /media/rootfs_/boot rsel6-rootfs

cp -R /media/rootfs_/lib/modules rsel6-rootfs/lib

cp -R /media/rootfs_/lib/firmware rsel6-rootfs/lib

Now make some changes to the configs.

Edit rsel6-rootfs/etc/fstab:  remove or comment out  the line for /dev/sda1 and the last two lines beginning with raiden: and change the / mount entry.

what I ended up with is this:

#---------------------

/dev/mmcblk0p2          /               ext4    noatime         1 1

devpts                  /dev/pts        devpts  gid=5,mode=620  0 0

tmpfs                   /dev/shm        tmpfs   defaults        0 0

proc                    /proc           proc    defaults        0 0

sysfs                   /sys            sysfs   defaults        0 0

#----------------------

I then enabled the serial console port:

Add /dev/ttyO0 to the end of rsel6-rootfs/etc/securetty

create rsel6-rootfs/etc/init/ttyO0.conf with the following content

#-------------------

start on runlevel [2345]

stop on runlevel [!2345]

respawn

exec /sbin/agetty 115200 ttyO0 vt102

#------------------

Now I replaced the ubuntu file system.

rm -fR /media/rootfs_/*

cp -R rsel6-rootfs/* /media/rootfs_

sync

remove the SD and boot in the BBB

There were still a few errors but it still came up.

login as root password password

I then manually configured eth0 with a static IP for my network

ifconfig eth0 192.168.1.4

route add default gw 192.168.1.254

I also used vim to create /etc/resolv.conf with

#---------------

nameserver 192.168.1.254

nameserver 127.0.0.1

#---------------

To make the network configuration permanent you will need to create some missing files:

/etc/sysconfig/network

/etc/sysconfig/network-scripts/ifcfg-eth0

That's it, it works, yum works but be careful installing packages so as not to overwrite /boot /lib/modules /lib/firmware

Also note all the software has been compiled for ARM5.

Enjoy!

Brian

Thanks for the detailed information!

I'm looking forward to trying this. I'm on a work trip+short vacation from tomorrow, so I may have to wait ten days or so to try it sadly.