Difference between revisions of "BeagleBoard Ubuntu"

From eLinux.org
Jump to: navigation, search
m (Kernel Source: 2.6-stable link)
(Replaced content with "Category: Linux Category: OMAP Category: Development Boards Category: BeagleBoard Category: DSP This page can be found at [http://www.elinux.org/BeagleBo...")
Line 5: Line 5:
 
[[Category: DSP]]
 
[[Category: DSP]]
  
= Introduction =
+
This page can be found at [http://www.elinux.org/BeagleBoard_Ubuntu_%26_DSP_From_Sources BeagleBoard Ubuntu & DSP From Sources].  This current page was removed because it was somehow an exact duplicate of the link provided.
 
 
The purpose of this page is to demonstrate how to build and run a DSP enabled (ARM EABI) Ubuntu distribution for the BeagleBoard.  We will build two variants of the Ubuntu distribution: an xfce GUI-based version and a minimal console-based version.  The following guidelines apply.
 
:*Build everything from sources when possible.
 
:*Be on the "''bleeding edge''", be it compilers, source code, whatever.
 
This page is not meant to duplicate any previous work and I will link to existing work whenever possible.  I used the page [http://elinux.org/BeagleBoardUbuntu BeagleBoardUbuntu] that is hosted at this site as my main reference.
 
 
 
This page was written on a generic Intel Core2 running a fresh installation of 64-bit Xubuntu 10.04 Lucid Lynx.  My BeagleBoard is a rev C3 version.
 
 
 
Please note that along the way, you will need to install any dependencies that are not present on your machine.  This is a straightforward process.  In cases where a script dies without warning due to a missing dependency, I will warn you ahead of time.
 
 
 
= Compilers =
 
We will need three cross-compilers for the OMAP 3530.  We will use both the ARM GNU/LINUX and the ARM EABI versions of the latest GNU compiler collection from CodeSourcery for the ARM Cortex A8 general purpose microcontroller.  We will use the latest TI C6000 Code Generation Tools for the C64x digital signal processor.
 
 
 
== ARM Cross Compiler ==
 
[http://www.codesourcery.com CodeSourcery] is one of the leading contributors to the ARM GCC cross-compiler.  They regularly push their updates upstream for inclusion into the main branch.  They provide a LITE version of their ARM GCC cross-compiler for free.  They provide 32-bit binaries, but the sources are available.  It would be an interesting project to compile 64-bit binaries, but we'll save that for another day.
 
 
 
''Take care to install the two CodeSourcery versions into separate directories.''
 
 
 
=== ARM GNU/LINUX ===
 
We will need the ARM GNU/LINUX cross-compiler to compile the kernel, modules, and user-space applications and libraries.  At the time of this writing, the latest version is [http://www.codesourcery.com/sgpp/lite/arm/portal/release1293 Sourcery G++ Lite 2010q1-202 for ARM GNU/Linux].  All [http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057 previous versions] are also available.
 
 
 
=== ARM EABI ===
 
We will need the ARM EABI cross-compiler to compile the U-Boot bootloader.  At the time of this writing, the latest version is [http://www.codesourcery.com/sgpp/lite/arm/portal/release1294 Sourcery G++ Lite 2010q1-188 for ARM EABI].  All [http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3053 previous versions] are also available.
 
 
 
=== Other Compilers ===
 
I have used two other cross compilers with good results.  If you prefer, these will work too:
 
:*[http://wiki.openembedded.net/index.php/Main_Page Open Embedded] will let you build a compiler as well as the [http://www.angstrom-distribution.org/ Angstrom Distribution].  These folks have great BeagleBoard support and the DSP examples below will probably work just fine.
 
:*[http://www.pengutronix.de/index_en.html Pengutronix] provides the [http://www.oselas.com/oselas/toolchain/index_en.html Oselas.Toolchain()] environment that will allow you to build your own cross compiler.  You will need to install [http://www.ptxdist.org/software/ptxdist/index_en.html PTXdist] first.
 
 
 
== TI DSP Compiler ==
 
Good news for open source fans!  On April 17, 2010, CodeSourcery announced that they are partnering with TI to create a [http://www.codesourcery.com/news/press_releases/gnu_toolchain_for_c6000_press_release.html C6000 GNU Toolchain].
 
CodeSourcery is working with Texas Instruments to port the GNU Toolchain to TI's C6000 family of processors.
 
TI's proprietary compiler has been in use for a long time and is the standard for C6000 DSPs.  At the time of this writing, the latest version is [https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm C6000 Code Generation Tools v7.0.2].  You will need to register with TI before you can access the downloads.
 
'''''Recommendation: The scripts to build the [http://www.elinux.org/BeagleBoard_Ubuntu_%26_DSP_From_Sources#DSP_Bridge_Userspace_Utilities DSP Bridge Userspace Utilties] require that [http://www.elinux.org/BeagleBoard_Ubuntu_%26_DSP_From_Sources#DSP_BIOS DSP BIOS] and the compiler be installed in the same directory.  I chose to keep the default /opt/TI.'''''
 
 
 
= SD Card Boot =
 
We will boot the Beagleboard from an SD card.  A [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat great tutorial] exists and doesn't need any further explanation.  I named my boot partition "boot" and my root file system partition "rootfs".
 
 
 
 
 
= BootLoaders =
 
The OMAP 3530 boots in three stages.  The first stage is the ROM boot vector.  This stage then jumps to the X-Loader that comes pre-installed in the onboard Flash memory.  The X-Loader will then jump to a U-Boot bootloader that is installed in Flash or to a U-Boot bootloader that is on a properly configured SD card if present.  The second and third stage bootloaders can be replaced or configured as needed.
 
 
 
== X-Loader ==
 
I have not had a need to modify or replace the X-Loader that comes stock with the rev C3 BeagleBoard.  The [http://gitorious.org/x-load-omap3 x-load-omap3] page will get you started if you choose to do so.
 
 
 
== U-Boot ==
 
There are several U-Boot trees for the BeagleBoard.  I chose to use the mainline tree from [http://www.denx.de/wiki/U-Boot Denx] because its support for the BeagleBoard is already included and works well enough.
 
 
 
A great example of how to build the omap3 branch of the mainline U-Boot can be found [http://elinux.org/BeagleBoard#U-Boot here].  '''''But there is a problem'''''.  The example indicates that we should use the ARM GNU/LINUX cross compiler.  This may work with cross-compilers from other providers, but will fail when using the CodeSourcery cross-compiler.  The CodeSourcery ARM EABI compiler works just fine.
 
git clone git://git.denx.de/u-boot.git u-boot-main
 
cd u-boot-main
 
git checkout --track -b omap3 origin/master
 
 
make CROSS_COMPILE=$(YOUR_PATH)/arm-none-eabi- distclean
 
make CROSS_COMPILE=$(YOUR_PATH)/arm-none-eabi- omap3_beagle_config
 
make CROSS_COMPILE=$(YOUR_PATH)/arm-none-eabi-
 
The advantage to building U-Boot this way is that you end up with a binary that was compiled for the Cortex A8.
 
 
 
The result is a u-boot.bin in the main directory.  Copy this to the boot partition of your SD card.
 
 
 
=== U-Boot Parameters ===
 
Once booting from the SD card, I halt the auto-boot to the kernel and set these parameters.  This only needs to be done once.
 
setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootwait rootfstype=ext3'
 
setenv bootcmd 'mmc init 0; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000'
 
 
 
 
 
= Build & Prepare the Kernel =
 
== Kernel Source ==
 
Using the recommendation found [http://elinux.org/BeagleBoardUbuntu#Official_Ubuntu_Kernel here], I have chosen to use the kernel source provided by the [https://launchpad.net/~beagleboard-kernel BeagleBoard Kernel] project.  They have several [https://code.launchpad.net/~beagleboard-kernel branches].  In keeping with being on the "bleeding edge", I have chosen to use the [https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable 2.6-stable] branch.
 
bzr branch lp:~beagleboard-kernel/+junk/2.6-stable
 
cd 2.6-stable
 
bzr merge
 
 
 
== Build the Kernel ==
 
We will be using '''rootstock''' to build the root file system.  In order to include the kernel, modules, and associated kernel headers into the root file system, rootstock requires that the kernel and associated files be bundled into a .deb package that is served from a webserver.  The Ubuntu kernel repository has a facility for this, but it is spread among a couple of files.
 
 
 
You will need to copy the file "system.sh.sample" to "system.sh" and the modify it as follows.  ''Note: Neither xfce nor lxde can be built at this time for a lucid distribution.  If you require these, then you may want to build a karmic distribution.  ''
 
--- system.sh.prev 2010-05-07 15:19:05.106817451 -0400
 
+++ system.sh 2010-05-07 22:21:19.576814569 -0400
 
@@ -9,19 +9,24 @@
 
  #Use CodeSourcery: http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite (GNU/Linux)
 
  #Just download and extract...
 
 
 
-CC=/OE/angstrom-dev/cross/armv7a/bin/arm-angstrom-linux-gnueabi-
 
+CC=/opt/Sourcery_G++_Lite/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
 
 
 
To build the kernel, simply enter: (script will warn and stop if missing dependices)
 
./build_kernel.sh (for uImage and modules)
 
./build_deb.sh (for *.deb)
 
 
 
On a 64-bit system, fakeroot will repeatedly issue a bunch of errors as follows.
 
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.
 
This error is generated because the cross-compiler is a 32-bit binary and 'libfakeroot-sysv.so' is a 64-bit binary.  I have extracted the kernel image from the .deb bundle and it boots.  So the error is just an annoyance.
 
 
 
== Deploy the Kernel ==
 
=== Copy Kernel uImage to SD Card ===
 
In the "2.6-dev/deploy" folder you will find a uImage.  The uImage kernel version will be prepended to the filename.  Copy this to the boot partition of your SD card.  An example is given below.
 
cp deploy/2.6.37-x2.uImage /media/boot/uImage
 
 
 
=== Put .deb bundle on a webserver ===
 
As previously mentioned, rootstock needs to access a .deb bundle that contains the kernel, modules, and kernel headers from a webserver.  These are essential to correctly build a root filesystem.  If you don't have access to one, install "lighttpd" - a fast and simple webserver.  You can access your new homepage by entering "localhost" in your browser.  This page will give you lots of helpful information to include the fact that your webserver root is located at ''/var/www/''.  You can copy your .deb files to this location whenever you need them.
 
 
 
An example is given below.  Note that the prepended kernel version will change over time.
 
sudo cp deploy/linux-image-2.6.37-x2_1.0cross_armel.deb /var/www/
 
 
 
= Userspace File System =
 
== Build the root filesystem ==
 
A great overview of building the Ubuntu root filesystem can be found [http://elinux.org/BeagleBoardUbuntu#RootStock:_Build_an_Ubuntu_root_file_system here].  This is the second time in the process where we don't compile something for ourselves (the first being the cross-compiler).  Rootstock downloads pre-compiled user space applications and libraries.  I am not too worried about this because these are not in the kernel space.  Rootstock is an Ubuntu supported ARM root filesystem builder, so I will trust that their user space binaries are up to par.
 
 
 
Before we proceed, you will need to install rootstock and dctrl-tools (to process .deb bundles on the command line).  You will also need to create a new folder to hold the root filesystem and then cd into it.
 
 
 
=== xfce root filesystem ===
 
The following will build a root filesystem for a '''''lucid''''' distribution running the xfce window manager.  At the time of this writing, neither xfce or lxde for ARM is working with lucid.  This example will incorporate the kernel, modules, and kernel headers from the webserver that we set up in the [http://www.elinux.org/BeagleBoard_Ubuntu_%26_DSP_From_Sources#Put_.deb_bundle_on_a_webserver previous section].  Also, please note that the following example references the specific .deb file from the examples above.  This will change over time.  ''Note: If you want to build for karmic, make sure to set '''--dist karmic''' and include a karmic kernel from above.''
 
sudo rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --dist lucid \
 
--serial ttyS2 --seed xfce4,gdm,xubuntu-gdm-theme,xubuntu-artwork \
 
--components "main universe multiverse" \
 
--kernel-image http://localhost/linux-image-2.6.33.2-dl8_1.0cross_armel.deb
 
 
 
=== minimal root filesystem ===
 
The following will build a root filesystem for a '''''lucid''''' minimal distribution that boots to a command prompt.  Again, please note that the following example references the specific .deb file from the examples above. This will change over time.  ''Note: The BeagleBoard will boot to a lucid command line at this time.''
 
sudo rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --dist lucid \
 
--serial ttyS2 --seed wget,nano,linux-firmware,wireless-tools,usbutils \
 
--components "main universe multiverse" \
 
--kernel-image http://localhost/linux-image-2.6.33.2-dl8_1.0cross_armel.deb
 
 
 
== Deploy the root filesystem ==
 
First, we need to erase the old root filesystem.  When the SD card is mounted in the host machine, it is located at /media/rootfs.  To erase the old contents, enter:
 
sudo rm -Rf /media/rootfs/*
 
Next, untar the newly created root filesystem tarball into the SD card rootfs partition.  The root filesystem tarball is date/time stamped.
 
sudo tar -xzf armel-rootfs-201005080031.tgz -C /media/rootfs/
 
 
 
 
 
= DSP =
 
Finally, we are ready to start working on DSP.  There are several approaches to this.  Please have a look at [[BeagleBoard/DSP Clarification]].  I have chosen to pursue the dsp-bridge approach at this time.  This is mainly because it is supported in the Ubuntu kernel.  Ultimately I want to use the DSP in the most efficient manner with GStreamer.  I want to minimize dsp-kernel-user space transfers, so I will evaluate all of the approaches and settle on one.  At this time, for simplicity, let's go with dsp-bridge.
 
 
 
But before we do, if you are interested in using dsp-bridge, please read [[BeagleBoard/DSP Howto]].
 
 
 
If you followed the directions up to this point, the kernel has the dsp-bridge driver.  We now need to get the DSP BIOS operating system for the C64x DSP controller and we need to build the user space binaries and libraries.  From this point forward, we will be following the writeup for the omapzoom at [http://omappedia.org/wiki/DSPBridge_Project DSPBridge Project].
 
 
 
== DSP BIOS ==
 
DSP BIOS is the operating system that runs on the DSP.  [http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/bios/index.html DSP BIOS can be downloaded here].  Currently, the latest version is 5.4x, but for once we won't be on the bleeding edge.  The reason is because scripts to build the userspace files require version 5.33.x.  This will be a project to move to the latest DSP BIOS version.
 
 
 
At this time, we will use [http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/bios/bios_5_33/bios_5_33_06/index_FDS.html DSP BIOS 5.33.06].  Download the installer and install into a location of your choice. '''''(Note: The DSP Bridge Userspace Utilties require that DSP BIOS and [http://www.elinux.org/BeagleBoard_Ubuntu_%26_DSP_From_Sources#TI_DSP_Compiler Code Generation Tools] are installed into the same directory.  To work with the compiler default install directory, I installed into /opt/TI)'''''
 
 
 
== DSP Bridge Userspace Utilities ==
 
DSP Bridge requires user space binaries.  At some point, I will investigate whether this is the most efficient way to use the DSP in Linux.  But for the time being, I am using this setup because it is well supported.  To build the DSP Bridge user space binaries, create a folder, cd into it and do the following:
 
git clone git://dev.omapzoom.org/pub/scm/tidspbridge/userspace-dspbridge.git
 
cd userspace-dspbridge
 
git checkout -b my_userspace --track origin/master
 
 
 
=== Host Machine Dependencies ===
 
Before we get started, now is a good time to point out the the build script has a dependency on the 32-bit version of libstdc++.  If you are using a 32-bit system, then you have no problem here.  If you are using a 64-bit system, you will need to install the 32-bit version of the library.  Debian provides a [http://packages.debian.org/lenny/i386/libstdc++5/download 32-bit version of libstdc++].  Once downloaded, the following command will add this library to your system.  ''Note: The version of this library will update over time.''
 
sudo dpkg --force-architecture -i libstdc++5_3.3.6-18_i386.deb
 
 
 
=== Host Machine Permissions ===
 
The build script will fail due to permissions in the ''xdctools'' folder of your DSP BIOS installation.  To fix this, I added 544 permissions to the required folders.
 
cd ($YOUR_PATH)/bios_5_33_06/xdctools/
 
chmod 544 *
 
cd bin/
 
chmod 544 *
 
 
 
=== Files to Patch ===
 
There are several bugs in the build scripts.  These are fixed in the following patch: [[File:Dspbridge-userspace-cgt7_0_2-bios5-33-06.patch‎]]
 
 
 
To apply the patch, save the patch file one directory level higher than your DSP Bridge user space binaries directory and then do the following:
 
$patch -p0 < Dspbridge-userspace-cgt7_0_2-bios5-33-06.patch
 
  patching file userspace-dspbridge/source/config.bld
 
  patching file userspace-dspbridge/source/Makefile
 
  patching file userspace-dspbridge/source/product.mak
 
  patching file userspace-dspbridge/source/samplemakefile
 
  patching file userspace-dspbridge/source/samples/mpu/make/start.mk
 
  patching file userspace-dspbridge/source/samples/mpu/src/dynreg/dload_internal.h
 
  patching file userspace-dspbridge/source/samples/mpu/src/dynreg/start.mk
 
$
 
 
 
=== Files to Modify ===
 
You will need to modify ''''source/Makefile'''' as follows.
 
*Modify the line that points to where your CROSS_COMPILE is installed (e.g. ''''CROSS_COMPILE ?= ($YOUR_PATH)/arm-none-linux-gnueabi-'''').
 
 
 
=== Compile the package ===
 
cd source
 
make clean
 
make all
 
 
 
=== Deploy the package ===
 
sudo cp -r target/dspbridge/ /media/rootfs/
 
sudo cp target/lib/* /media/rootfs/lib/
 
 
 
== Putting it to the test ==
 
If you followed the Kernel configuration instructions above, then the DspBridge driver is already running in the kernel.  Two simple checks will verify the presence of the driver.
 
cat /proc/interrupts
 
ls /dev
 
 
 
To try the simple ping, first load a base image and then execute the ping example.
 
$cd /dspbridge
 
$sudo ./cexec.out ddspbase_tiomap3430.dof64P
 
  DSP device detected !!
 
  DSPProcessor_Start succeeded.[ 2093.332366] procwrap_detach: deprecated dspbridge ioctl
 
 
 
  Hit any key to terminate cexec.
 
 
 
$sudo ./ping.out
 
  DSP device detected !!
 
  DSPNodeCreate succeeded
 
  DSPNode_registerNotify succeeded
 
  DSPNode_run succeeded
 
  Ping: Id 1.000000 Msg 0.000000 Mem 15408.000000
 
    ...
 
  Ping: Id 1.000000 Msg 49.000000 Mem 15408.000000
 
 
 
= In Closing =
 
Ok now that we are up and running, there are quite a few things to work on:
 
:How to port to the latest version of DSP BIOS?
 
:How to work with GStreamer?
 
:What else?
 

Revision as of 18:14, 14 March 2011


This page can be found at BeagleBoard Ubuntu & DSP From Sources. This current page was removed because it was somehow an exact duplicate of the link provided.