Difference between revisions of "EBC Exercise 08a Cross-Compiling"

From eLinux.org
Jump to: navigation, search
(Step 3 - Setting up for the BeagleBoard)
m (Cross compiling Hello World: Updated compiler path)
 
(143 intermediate revisions by 21 users not shown)
Line 1: Line 1:
[[Category:ECE597]]
+
[[Category:ECE497]]
 
[[Category: BeagleBoard]]
 
[[Category: BeagleBoard]]
 +
{{YoderHead}}
  
This class is about developing software for embedded Linux. The [http://elinux.org/Main_Page eLinux site] is a good source for embedded Linux in general. There are many ongoing embedded efforts going on many platforms. Poke around the site a while to get a feel for what's happening.
+
This class is about developing software for embedded Linux. So far we have been doing all of our development on the Beagle. This works well for small (and not so small) programs. However, we are now moving into kernel development and that's best done on a more powerful host computer. In [[EBC_Exercise_08_Installing_Development_Tools_4.4]] you learned how to download and install the cross compilers and the source for kernel and u-boot. Now we'll use those tools.
  
We are going to use the [http://www.angstrom-distribution.org Ångström Distribution]It's available many platforms. Look around the site, you may recognize some of them.
+
== Cross compiling Hello World ==
 +
Normally when you compile you compile on the machine that will run the code.  You can compile and run on the Bone, but sometimes (like when compiling the kernel) it's better to use a more powerful machine for the compilingFirst we'll compile ''helloWorld.c'' on the host computer and run it there, then we'll cross compile it on the host to run on the Bone.
  
Instructions for building Ångström are given [http://www.angstrom-distribution.org/building-angstrom here]; however I'm going to present a Beagle-tuned version of those instructions on this page.
+
If you've set up your git repository you will find it in '''helloWorld.c''' when you do a''' git pull'''.  Compile and run it on your host to be sure it works.
  
== Step 1 - get Open Embedded metadata ==
+
host$ '''gcc helloWorld.c'''
 +
host$ '''file a.out'''
 +
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked,
 +
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
 +
BuildID[sha1]=049e80612d5735fda0966f6e23c637d345447f49, not stripped
 +
host$ '''./a.out'''
 +
Hello, World! Main is executing at 0x55f7f41f96aa
 +
This address (0x7ffd98d0ebd0) is in our stack frame
 +
This address (0x55f7f43fa018) is in our bss section
 +
This address (0x55f7f43fa010) is in our data section
  
First install <code>git</code> by running the following on your host computer.
+
Now that you know it's working, let's cross compile it. First figure out what version of the cross compiler was loaded.
<pre>
 
sudo apt-get install git-core
 
</pre>
 
  
Then run the following to load the meta data.
+
host$ '''cd BeagleBoard/bb-kernel/dl'''
<pre>
+
host$ '''ls'''
export OETREE="${HOME}/oe"
+
gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf
mkdir -p ${OETREE} && cd ${OETREE}
+
gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz
git clone git://git.openembedded.org/openembedded.git openembedded
 
cd openembedded
 
git checkout origin/stable/2009 -b stable/2009
 
</pre>
 
If <code>git://git.openembedded.org/openembedded.git</code> does not work, you can also try <code>http://repo.or.cz/r/openembedded.git</code>.<br>
 
The first git transfers some 336,000 object and takes about 18 minutes with the network running at 600 some KiB/s. Keep an eye on it, mine stopped about 23% in and I had to restart it.  The second git takes almost no time.
 
  
Now run the following to update the metadata:
+
Here we see two versions of the compiler have been loadedLet's pick the newer one.
<pre>
 
cd ${OETREE}/openembedded
 
git pull
 
</pre>
 
You've created a directory called <code>oe</code>.  Go explore around it to see what is there.  Be sure to look in <code>oe/openembedded/recipes</code>.  These folders contain instructions on where to get and how to build various things.  Look in <code>recipes/Linux</code>.  Here are instructions for building various Linux kernelsWe'll be using <code>linux-omap-2.6.*</code>.  What's the highest version you can find?
 
  
== Step 2 - Installing bitbake and friends ==
+
Now set the paths to find the cross-compiler. Put the following in a file, call it '''~/crossCompileEnv.sh'''.
  
bitbake is the workhorse that knows where to get everything and how to compile it. The following will install bitbake and additional programs that bitbake needs. This may take 5 minutes.
+
  export ARCH=arm
<pre>
+
  export CROSS_COMPILE=arm-linux-gnueabihf-
sudo apt-get install bitbake
+
export PATH=$PATH:~/BeagleBoard/bb-kernel/dl/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin
sudo apt-get install g++
 
sudo apt-get install help2man diffstat texi2html cvs texinfo subversion gawk
 
sudo apt-get autoremove
 
</pre>
 
If you are running Ubuntu you will have to also do the following:
 
<pre>
 
cd /bin
 
sudo mv sh sh.old
 
sudo ln -s bash sh
 
sudo sh -c "echo 0 > /proc/sys/vm/mmap_min_addr"
 
</pre>
 
Finally edit the file <code>/etc/sysctl.conf</code> using:
 
<pre>
 
sudo gedit /etc/sysctl.conf
 
</pre>
 
Add the following at the end and save.
 
<pre>
 
# This is for bitbake
 
vm.mmap_min_addr = 0
 
</pre>
 
Now you should be ready to run bitbake.
 
  
{{Give
+
Make sure the PATH you use goes to the bin directory where the cross compiler is installed.
|title=Psyco JIT compiler
 
|tip=bitbake suggest loading a compiler.  Load and test the compiler. If it's worth using, write instructions.
 
}}
 
The Psyco JIT compiler should help speed up compilation times. To install, use
 
<pre>
 
sudo apt-get install python-psyco
 
</pre>
 
  
== Step 3 - Setting up for the BeagleBoard ==
+
Now ''source'' the file and compile again. (Note: you only have to source once per terminal session.)
 +
host$ '''source ~/crossCompileEnv.sh'''
 +
host$ '''${CROSS_COMPILE}gcc helloWorld.c'''
 +
host$ '''file a.out'''
 +
a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
 +
dynamically linked, interpreter /lib/ld-linux-armhf.so.3,
 +
for GNU/Linux 3.2.0, BuildID[sha1]=17ab3588195851d9eb444f70e5069376cae3bdec,
 +
with debug_info, not stripped
  
We need a small script to setup the environment, so download [http://www.rose-hulman.edu/~yoder/eLinux/files/source-me.txt source-me.txt] to ${OETREE}.
+
The '''file''' command tells what's in the file. In this case we have an ARM executable. Success!  Now copy to your Beagle and run
  
Now let's setup <code>local.conf</code> for our needs:
+
host$ '''scp a.out debian@192.168.7.2:.'''
<pre>
+
host$ '''ssh debian@192.168.7.2 ./a.out'''
mkdir -p ${OETREE}/build/conf
+
Hello, World! Main is executing at 0x103d5
cp ${OETREE}/openembedded/contrib/angstrom/local.conf ${OETREE}/build/conf/
+
This address (0xbeb83c54) is in our stack frame
</pre>
+
This address (0x21030) is in our bss section
Open <code>${OETREE}/build/conf/local.conf</code> in your favourite editor and add the following to the end of the file.
+
  This address (0x21028) is in our data section
<pre>
 
MACHINE ?= "beagleboard"
 
</pre>
 
Also, look at this block of lines:
 
<pre>
 
# Make use of SMP and fast disks
 
PARALLEL_MAKE = "-j4"
 
BB_NUMBER_THREADS = "4"
 
</pre>
 
Here you can tell it how many parallel threads to run. If you have several cores on your machine, make this number big.  If you have only one core, you might be better performance setting it to 1.  More details are [http://wiki.openembedded.org/index.php/Advanced_configuration here].
 
  
To save you a lot of time, it is useful to disable locale generation for all but the one you need. Add this to local.conf
+
The '''scp''' copies ''a.out'' to the beagle and the '''ssh''' runs the ''a.out'' on the beagle. Notice the addresses are very different from the host version.
<pre>
 
GLIBC_GENERATE_LOCALES = "en_US.UTF-8"
 
</pre>
 
  
== Step 4 - Start building ==
+
{{YoderFoot}}
Do the following...
 
<pre>
 
# set environment variables
 
cd ${OETREE}
 
source source-me.txt
 
 
 
#Go to the OE tree
 
cd ${OETREE}/openembedded
 
 
 
#Make sure it's up to date
 
git pull --rebase
 
 
 
#Start building
 
bitbake nano
 
</pre>
 
 
 
This will take a while.  bitbake is installing everything that is needed to compile the system.  This includes cross compilers, assemblers, source, everything.  I started at 10am and ended around 5:30pm.  It was running on just one of the two cores on my laptop.  How long did it take on your machine?  I notice that an additional 600M of disk space is being used.
 
 
 
{{Give
 
|title=Keep track of you running times and configurations.
 
|tip=We'll use this data to see what the best settings are.
 
}}
 
 
 
{| border="1" cellspacing="0" cellpadding="5"
 
|+ Initial <tt>bitbake nano</tt> runtime
 
! Processor
 
! Settings
 
! Run Time
 
|-
 
| T2600@2.16 GHz
 
| PARALLEL_MAKE = "-j4"<br>BB_NUMBER_THREADS = "2"<br>Psyco? Yes.
 
| 2.5 hours
 
|-
 
| T2600@2.16 GHz
 
| PARALLEL_MAKE = "-j4"<br>BB_NUMBER_THREADS = "4"<br>Psyco? Yes.
 
| ''pending''
 
|-
 
| E5410@2.33 GHz (x2)
 
| PARALLEL_MAKE = "-j8"<br>BB_NUMBER_THREADS = "8"<br>Psyco? No.
 
| ''pending''
 
|}
 
 
 
== Step 5 - Building a complete image ==
 
 
 
Up to this point all we have done is load all the infrastructure needed and compiled the simple '''nano''' text editor.  We don't even have the kernel yet. Do the following to build a basic console image.
 
<pre>
 
bitbake console-image
 
</pre>
 
'''This bitbake took 7 hours and 15 minutes.'''  There are now some 7,700 directories with 67,000 files in the <code>oe</code> directory.  An additional 1.5G of disk space is in use.
 
 
 
How did I know to use '''console-image'''?  I ran the following to find what images were out there:
 
<pre>
 
locate image | grep /oe/
 
</pre>
 
This found every file with '''image''' in the name it that also had '''/oe/''' in the path.  From this I see that '''oe/openembedded/recipes/images''' has a bunch of files ending in '''-image'''.  Take a look at '''console-image.bb''' and see what you can figure out.
 
 
 
== Step 6 - Loading your SD card ==
 
 
 
The output of the bitbake command will ultimately be found under the <code>$OE_HOME/angstrom-dev/deploy/glibc/images/beagleboard</code>. In there you can find at least two interesting files:
 
<pre>
 
console-image-beagleboard.tar.bz2
 
uImage-beagleboard.bin
 
</pre>
 
The console image represents a full and self-contained file system, *including* a kernel. The uImage-beagleboard.bin is a Linux kernel image suitable for loading by the U-boot bootloader.
 
 
 
* Rename '''uImage-beagleboard.bin''' as '''uImage''' and load on your SD as before ([[Getting your Beagle running]]). 
 
* Also load '''console-image-beagleboard.tar.bz2''' on the 2<sup>nd</sup> partition like you did before.  Did you notice it untar's very quickly?  Why?
 
* Boot and explore.  What's there?  What's missing?
 
 
 
Congratulations you've just build Linux from source.  Try this:
 
<pre>
 
beagleboard login: root
 
root@beagleboard:~# cd /sys/class
 
root@beagleboard:/sys/class# ls -F
 
bdi/          hwmon/        misc/        scsi_generic/ usb_device/
 
block/        i2c-adapter/  mmc_host/    scsi_host/    usb_endpoint/
 
bluetooth/    i2c-dev/      mtd/          sound/        usb_host/
 
bmi/          ieee80211/    net/          spi_master/  usbmon/
 
display/      input/        regulator/    spidev/      vc/
 
firmware/    leds/        rtc/          thermal/      vtconsole/
 
gpio/        mdio_bus/    scsi_device/  tty/
 
graphics/    mem/          scsi_disk/    ubi/
 
</pre>
 
This is a list of low-level devices on the Beagle that you can access as files.  Try:
 
<pre>
 
root@beagleboard:/sys/class# cd leds/
 
root@beagleboard:/sys/class/leds# ls -F
 
beagleboard::usr0@ beagleboard::usr1@
 
root@beagleboard:/sys/class/leds# cd beagleboard\:\:usr0
 
root@beagleboard:/sys/devices/platform/leds-gpio/leds/beagleboard::usr0# cat trigger
 
none nand-disk mmc0 mmc1 [heartbeat]
 
</pre>
 
This is a list of values you can assign to trigger.  Notice LED0 is blinking on and off right now. Try:
 
<pre>
 
root@beagleboard:/sys/devices/platform/leds-gpio/leds/beagleboard::usr0# echo none > trigger
 
root@beagleboard:/sys/devices/platform/leds-gpio/leds/beagleboard::usr0# echo 1 > brightness
 
</pre>
 
What happens?  Play around.  [http://groups.google.com/group/beagleboard/msg/c623a16637625685?hl=en Here] are instructions on reading the '''USER''' switch.  Try it.  Can you make the LEDs blink in response to the button being pressed?
 
 
 
== Step 7 - Building a complete Beagle demo image ==
 
 
 
Now let's build the how demo we were running before.  We'll do this via bitbake, but argument do we give it?  Try looking in <code>oe/openembedded/recipes/images</code>, do you see a recipe that might work?  Hint:  It has beagle in the name.  Here's what I tried.
 
<pre>
 
time bitbake beagle????-image
 
</pre>
 
Replace ???? with the recipe name you found.  I added the '''time''' command so I could see how long it takes to run.  My run took some 7.5 hours.
 

Latest revision as of 11:21, 20 September 2019

thumb‎ Embedded Linux Class by Mark A. Yoder


This class is about developing software for embedded Linux. So far we have been doing all of our development on the Beagle. This works well for small (and not so small) programs. However, we are now moving into kernel development and that's best done on a more powerful host computer. In EBC_Exercise_08_Installing_Development_Tools_4.4 you learned how to download and install the cross compilers and the source for kernel and u-boot. Now we'll use those tools.

Cross compiling Hello World

Normally when you compile you compile on the machine that will run the code. You can compile and run on the Bone, but sometimes (like when compiling the kernel) it's better to use a more powerful machine for the compiling. First we'll compile helloWorld.c on the host computer and run it there, then we'll cross compile it on the host to run on the Bone.

If you've set up your git repository you will find it in helloWorld.c when you do a git pull. Compile and run it on your host to be sure it works.

host$ gcc helloWorld.c
host$ file a.out
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=049e80612d5735fda0966f6e23c637d345447f49, not stripped
host$ ./a.out
Hello, World! Main is executing at 0x55f7f41f96aa
This address (0x7ffd98d0ebd0) is in our stack frame
This address (0x55f7f43fa018) is in our bss section
This address (0x55f7f43fa010) is in our data section

Now that you know it's working, let's cross compile it. First figure out what version of the cross compiler was loaded.

host$ cd BeagleBoard/bb-kernel/dl
host$ ls
gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf
gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz

Here we see two versions of the compiler have been loaded. Let's pick the newer one.

Now set the paths to find the cross-compiler. Put the following in a file, call it ~/crossCompileEnv.sh.

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
export PATH=$PATH:~/BeagleBoard/bb-kernel/dl/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin

Make sure the PATH you use goes to the bin directory where the cross compiler is installed.

Now source the file and compile again. (Note: you only have to source once per terminal session.)

host$ source ~/crossCompileEnv.sh
host$ ${CROSS_COMPILE}gcc helloWorld.c
host$ file a.out
a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3,
for GNU/Linux 3.2.0, BuildID[sha1]=17ab3588195851d9eb444f70e5069376cae3bdec,
with debug_info, not stripped

The file command tells what's in the file. In this case we have an ARM executable. Success! Now copy to your Beagle and run

host$ scp a.out debian@192.168.7.2:.
host$ ssh debian@192.168.7.2 ./a.out
Hello, World! Main is executing at 0x103d5
This address (0xbeb83c54) is in our stack frame
This address (0x21030) is in our bss section
This address (0x21028) is in our data section

The scp copies a.out to the beagle and the ssh runs the a.out on the beagle. Notice the addresses are very different from the host version.




thumb‎ Embedded Linux Class by Mark A. Yoder