Development Environment

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(New Application)
(Building debian packages with qemu and cross-compiling distccs)
 
(21 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 +
{{Languages| Development Environment}}
 
If you want to create a new application, you might want to look at [[Toolchain]] first.  However, if the dependency is complex or you want to modify something already in system, currently the easiest way to go is still using [[OpenEmbedded]].
 
If you want to create a new application, you might want to look at [[Toolchain]] first.  However, if the dependency is complex or you want to modify something already in system, currently the easiest way to go is still using [[OpenEmbedded]].
  
 
= New Application =
 
= New Application =
 
* [[Toolchain]]
 
* [[Toolchain]]
* [[OpenMokoFramework]]
+
* [[OpenmokoFramework]]
 
* Anjuta plugin[http://free-opensource.qvantel.net/mediawiki/index.php/Preity-plugin]
 
* Anjuta plugin[http://free-opensource.qvantel.net/mediawiki/index.php/Preity-plugin]
 
* [[Host-based development with Xoo and Xephyr]]
 
* [[Host-based development with Xoo and Xephyr]]
  
 
= Develop with OE =
 
= Develop with OE =
After setting up the OE environment, making it build the latest component of OpenMoko is a must to avoid duplicated work.  Refer to [[OpenMoko2007.2#How_to_enable_autorev|How to enable autorev]] to find out how to do itBuilding for the first time will take a lot of time and occupy big disk space, but after that it will be reasonable.  You will also need to '''remove''' the
+
After setting up the OE (OpenEmbedded) environment, making it build the latest component of Openmoko is necessary to avoid duplicated work.  Refer to [[Openmoko2007.2#How_to_enable_autorev|How to enable autorev]] to find out how to do thisThe first build will take a lot of time and occupy a good deal of disk space, but after that it will be faster.  You will also need to '''remove''' the
 
  INHERIT += "rm_work
 
  INHERIT += "rm_work
 
line in your local.conf if it exists.
 
line in your local.conf if it exists.
Line 17: Line 18:
 
  bitbake openmoko-sample2 -c devshell
 
  bitbake openmoko-sample2 -c devshell
 
You will be dropped to a shell that the environment is set to build the package.  After the modification, usually a simple `make' will do the trick.  You should be able to find the new binary under a hidden .libs directory if this package uses autotools.
 
You will be dropped to a shell that the environment is set to build the package.  After the modification, usually a simple `make' will do the trick.  You should be able to find the new binary under a hidden .libs directory if this package uses autotools.
 +
 +
== Use quilt ==
 +
We could make modification and manage it by `quilt'.
 +
 +
$ # no need to mkdir patches.  already exists.
 +
$ quilt new foo.patch
 +
$ quilt add to_be_changed.c
 +
$ vi to_be_changed.c
 +
''<coding monkey is working...>''
 +
$ make
 +
$ scp foobar neo:  # copy it to neo
 +
''<test... wow it works>''
 +
$ quilt refresh
 +
$ cp -r patches ~/miracle  # keep it somewhere
  
 
== Tips ==
 
== Tips ==
* You might find it convenient to replace the source directory with a symlink to the same directory under your OpenMoko svn tree, once you get more understanding to OE.  You need to patch and configure the source again if you go this way.
+
* You might find it convenient to replace the source directory with a symlink to the same directory under your Openmoko svn tree, once you get more understanding of OE.  You need to patch and configure the source again if you go this route.
  
* If you don't want to use devshell, change directory to ${WORKDIR} directly (usually one level higher then the directory that devshell drops you to), do the modification, and invoke ./temp/run.do_compile.xxxx will also compile the source again.
+
* If you don't want to use devshell, change directory to ${WORKDIR} directly (usually one level higher than the directory that devshell drops you to), do the modification, and invoke ./temp/run.do_compile.xxxx will also compile the source again.
  
 
== Make ipkg for distributing ==
 
== Make ipkg for distributing ==
 
Multiple ways to do this:
 
Multiple ways to do this:
* make a patch and add it to the bb file.  Rebuild.
+
* Use quilt patches and add it to the bb file.  Rebuild.
* bitbake oepnmoko-sample2 -c package_write
+
* bitbake openmoko-sample2 -c package_write
 +
 
 +
== Building debian packages with qemubuilder ==
 +
 
 +
See [http://wiki.debian.org/DebianOnFreeRunner debian wiki] on how to configure "sudo qemubuilder --build foo*.dsc" to compile armel binary packages of foo. This is slow since everything is done inside qemu but the results should be fully repeatable. See above for an bit more adventurous example on how this can be transparently combined with distcc and cross-compilers.
 +
 
 +
== Building debian packages with qemu and cross-compiling distccs ==
 +
 
 +
Here are step-by-step instructions on building debian packages with qemu and distcc. Only actual compilation tasks are done with cross compilers so you should not need to edit upstream build scripts to be cross-compilable.
 +
 
 +
1) ssh to a PC with debian unstable. You can easily install it to a
 +
    chroot with http://iki.fi/lindi/schroot.txt if you don't want to
 +
    break your normal installation.
 +
1.2) sudo aptitude install emdebian-tools distcc
 +
1.3) sudo emsetup --arch armel
 +
1.4) sudo emsetup --arch armel
 +
1.5) verify that arm-linux-gnueabi-gcc works:
 +
 +
$ cat > hello.c <<EOF
 +
#include <stdio.h>
 +
int main(void) {
 +
printf("Hello world\n");
 +
return 0;
 +
}
 +
EOF
 +
$ arm-linux-gnueabi-gcc -o hello hello.c
 +
$ file hello
 +
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically  linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
 +
 +
1.6) configure /etc/default/distcc (values below are examples):
 +
1.6.1) STARTDISTCC="true"
 +
1.6.2) ALLOWEDNETS="192.168.1.0/24" # be careful to only allow trusted
 +
        hosts, distcc can run arbirary commands as "distcc" user
 +
1.6.3) LISTENER="192.168.1.8"
 +
1.6.4) ZEROCONF="false" # does not work from chroot since it can't  talk to dbus
 +
1.7) sudo /etc/init.d/distcc start
 +
 +
2) ssh to an ARM with debian unstable. This can be your freerunner but
 +
    you probably want to use
 +
    e.g. http://people.debian.org/~aurel32/qemu/armel/ with qemu. Note
 +
    that you probably want to add e.g. "-redir tcp:5022::22" qemu
 +
    option so that you can "ssh localhost -p 5022 -l root" to access
 +
    the ARM system.
 +
2.1) sudo apt-get install distcc
 +
2.2) export CC="distcc arm-linux-gnueabi-gcc"
 +
2.3) export DISTCC_HOSTS="$address_of_pc1 $address_of_pc2 ..."
 +
2.4) you can now use make -j6 to distribute build to cross-compilers
 +
2.5) note that "apt-get --build" does not support passing parallel build options so
 +
      you need to split build into to parts: first "apt-get source $package" and then
 +
      "cd $package* && dpkg-buildpackage -j6"
 +
 
 +
== Cross-compiling simple debian packages ==
 +
 
 +
If you are lucky something as simple as
 +
apt-get source foo
 +
cd foo*
 +
dpkg-buildpackage -aarmel -rfakeroot -us -uc
 +
might work. See http://iki.fi/lindi/debian/pool/main/a/agps-online for an example of such a simple package.
 +
 
 +
== Building experimental kernels ==
 +
 
 +
If you are on debian the follow the step 1 under qemu+distcc instructions to obtain arm-linux-gnueabi-gcc. Then use
 +
 
 +
1) git clone git://git.openmoko.org/git/kernel.git linux-2.6
 +
2) git branch your-name origin/stable-tracking
 +
3) modify ./build to use your compiler:
 +
-export CROSS_COMPILE=../../cross/bin/arm-angstrom-linux-gnueabi-
 +
+export CROSS_COMPILE=arm-linux-gnueabi-
 +
4) ./build dummy
 +
 
 +
to build a kernel from stable-tracking branch. Note that you might want to change the build script to also save your zImage and .config file with versions:
 +
 
 +
@@ -52,6 +52,8 @@ if make -j5 ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y  EXTRAVERSION=$VERSION; then
 +
        if [ ! -z "`grep CONFIG_USB_USBNET=y .config`" ] ; then
 +
                rm -f uImage-moredrivers*-$PRODUCT.bin modules-*$PRODUCT.tar.gz
 +
                cp uImage-$PRODUCT.bin uImage-moredrivers$VERSION.bin
 +
+              cp arch/arm/boot/zImage zImage$VERSION
 +
+              cp .config config$VERSION
 +
                rm -rf staging
 +
                mkdir -p staging
 +
                if [ ! -z "$1" ] ; then
 +
 +
 
 +
 
  
{{Languages|Development_Environment}}
+
[[Category:Application Developer]]
[[Category:Developer]]
+

Latest revision as of 18:36, 20 July 2010

If you want to create a new application, you might want to look at Toolchain first. However, if the dependency is complex or you want to modify something already in system, currently the easiest way to go is still using OpenEmbedded.

Contents

[edit] New Application

[edit] Develop with OE

After setting up the OE (OpenEmbedded) environment, making it build the latest component of Openmoko is necessary to avoid duplicated work. Refer to How to enable autorev to find out how to do this. The first build will take a lot of time and occupy a good deal of disk space, but after that it will be faster. You will also need to remove the

INHERIT += "rm_work

line in your local.conf if it exists.

Now, for example, if you want to modify openmoko-sample2, you can do this to build it first:

bitbake openmoko-sample2

After that:

bitbake openmoko-sample2 -c devshell

You will be dropped to a shell that the environment is set to build the package. After the modification, usually a simple `make' will do the trick. You should be able to find the new binary under a hidden .libs directory if this package uses autotools.

[edit] Use quilt

We could make modification and manage it by `quilt'.

$ # no need to mkdir patches.  already exists.
$ quilt new foo.patch
$ quilt add to_be_changed.c
$ vi to_be_changed.c
<coding monkey is working...>
$ make
$ scp foobar neo:   # copy it to neo
<test... wow it works>
$ quilt refresh
$ cp -r patches ~/miracle  # keep it somewhere

[edit] Tips

  • You might find it convenient to replace the source directory with a symlink to the same directory under your Openmoko svn tree, once you get more understanding of OE. You need to patch and configure the source again if you go this route.
  • If you don't want to use devshell, change directory to ${WORKDIR} directly (usually one level higher than the directory that devshell drops you to), do the modification, and invoke ./temp/run.do_compile.xxxx will also compile the source again.

[edit] Make ipkg for distributing

Multiple ways to do this:

  • Use quilt patches and add it to the bb file. Rebuild.
  • bitbake openmoko-sample2 -c package_write

[edit] Building debian packages with qemubuilder

See debian wiki on how to configure "sudo qemubuilder --build foo*.dsc" to compile armel binary packages of foo. This is slow since everything is done inside qemu but the results should be fully repeatable. See above for an bit more adventurous example on how this can be transparently combined with distcc and cross-compilers.

[edit] Building debian packages with qemu and cross-compiling distccs

Here are step-by-step instructions on building debian packages with qemu and distcc. Only actual compilation tasks are done with cross compilers so you should not need to edit upstream build scripts to be cross-compilable.

1) ssh to a PC with debian unstable. You can easily install it to a
   chroot with http://iki.fi/lindi/schroot.txt if you don't want to
   break your normal installation.
1.2) sudo aptitude install emdebian-tools distcc
1.3) sudo emsetup --arch armel
1.4) sudo emsetup --arch armel
1.5) verify that arm-linux-gnueabi-gcc works:

$ cat > hello.c <<EOF
#include <stdio.h>
int main(void) {
printf("Hello world\n");
return 0;
}
EOF
$ arm-linux-gnueabi-gcc -o hello hello.c
$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically  linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

1.6) configure /etc/default/distcc (values below are examples):
1.6.1) STARTDISTCC="true"
1.6.2) ALLOWEDNETS="192.168.1.0/24" # be careful to only allow trusted
       hosts, distcc can run arbirary commands as "distcc" user
1.6.3) LISTENER="192.168.1.8"
1.6.4) ZEROCONF="false" # does not work from chroot since it can't  talk to dbus
1.7) sudo /etc/init.d/distcc start

2) ssh to an ARM with debian unstable. This can be your freerunner but
   you probably want to use
   e.g. http://people.debian.org/~aurel32/qemu/armel/ with qemu. Note
   that you probably want to add e.g. "-redir tcp:5022::22" qemu
   option so that you can "ssh localhost -p 5022 -l root" to access
   the ARM system.
2.1) sudo apt-get install distcc
2.2) export CC="distcc arm-linux-gnueabi-gcc"
2.3) export DISTCC_HOSTS="$address_of_pc1 $address_of_pc2 ..."
2.4) you can now use make -j6 to distribute build to cross-compilers
2.5) note that "apt-get --build" does not support passing parallel build options so
     you need to split build into to parts: first "apt-get source $package" and then
     "cd $package* && dpkg-buildpackage -j6"

[edit] Cross-compiling simple debian packages

If you are lucky something as simple as

apt-get source foo
cd foo*
dpkg-buildpackage -aarmel -rfakeroot -us -uc

might work. See http://iki.fi/lindi/debian/pool/main/a/agps-online for an example of such a simple package.

[edit] Building experimental kernels

If you are on debian the follow the step 1 under qemu+distcc instructions to obtain arm-linux-gnueabi-gcc. Then use

1) git clone git://git.openmoko.org/git/kernel.git linux-2.6
2) git branch your-name origin/stable-tracking
3) modify ./build to use your compiler:
-export CROSS_COMPILE=../../cross/bin/arm-angstrom-linux-gnueabi-
+export CROSS_COMPILE=arm-linux-gnueabi-
4) ./build dummy

to build a kernel from stable-tracking branch. Note that you might want to change the build script to also save your zImage and .config file with versions:

@@ -52,6 +52,8 @@ if make -j5 ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y  EXTRAVERSION=$VERSION; then
        if [ ! -z "`grep CONFIG_USB_USBNET=y .config`" ] ; then
                rm -f uImage-moredrivers*-$PRODUCT.bin modules-*$PRODUCT.tar.gz
                cp uImage-$PRODUCT.bin uImage-moredrivers$VERSION.bin
+               cp arch/arm/boot/zImage zImage$VERSION
+               cp .config config$VERSION
                rm -rf staging
                mkdir -p staging
                if [ ! -z "$1" ] ; then
Personal tools

If you want to create a new application, you might want to look at Toolchain first. However, if the dependency is complex or you want to modify something already in system, currently the easiest way to go is still using OpenEmbedded.

New Application

Develop with OE

After setting up the OE environment, making it build the latest component of OpenMoko is a must to avoid duplicated work. Refer to How to enable autorev to find out how to do it. Building for the first time will take a lot of time and occupy big disk space, but after that it will be reasonable. You will also need to remove the

INHERIT += "rm_work

line in your local.conf if it exists.

Now, for example, if you want to modify openmoko-sample2, you can do this to build it first:

bitbake openmoko-sample2

After that:

bitbake openmoko-sample2 -c devshell

You will be dropped to a shell that the environment is set to build the package. After the modification, usually a simple `make' will do the trick. You should be able to find the new binary under a hidden .libs directory if this package uses autotools.

Tips

  • You might find it convenient to replace the source directory with a symlink to the same directory under your OpenMoko svn tree, once you get more understanding to OE. You need to patch and configure the source again if you go this way.
  • If you don't want to use devshell, change directory to ${WORKDIR} directly (usually one level higher then the directory that devshell drops you to), do the modification, and invoke ./temp/run.do_compile.xxxx will also compile the source again.

Make ipkg for distributing

Multiple ways to do this:

  • make a patch and add it to the bb file. Rebuild.
  • bitbake oepnmoko-sample2 -c package_write