NSLU2-Linux
view · edit · print · history

OpenEmbedded.GettingStarted History

Hide minor edits - Show changes to markup

August 21, 2005, at 11:26 AM by rwhitby --
Changed lines 1-2 from:

This whole page is mostly obsolete. See the Development HomePage instead.

to:

This whole page is mostly obsolete. See the Development HomePage instead.

August 21, 2005, at 11:25 AM by rwhitby --
Added lines 1-2:

This whole page is mostly obsolete. See the Development HomePage instead.

August 21, 2005, at 05:22 AM by wiml -- mention of bitkeeper is obsolete.
Changed lines 74-75 from:

Your next job is to download the OE-related openembedded/ directory. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/cgi-bin/moin.cgi/BitKeeper, but you must get them from the following nslu2-linux repository instead of the ones stated on that page:

to:

Your next job is to download the OE-related openembedded/ directory. You get them from the BitKeeper repo. (no you don't. the project no longer uses bitkeeper.) The process for doing this is documented at http://openembedded.org/cgi-bin/moin.cgi/BitKeeper, but you must get them from the following nslu2-linux repository instead of the ones stated on that page:

July 17, 2005, at 12:21 PM by Matthew Buickett -- Removed dot to prevent copy and paste problems
Changed lines 62-63 from:

After downloading BitBake you will need to install the BitBake software. To install, cd into the BitBake directory you just created and type ./setup.py install --prefix=/usr/local --install-data=/usr/local/share.

to:

After downloading BitBake you will need to install the BitBake software. To install, cd into the BitBake directory you just created and type ./setup.py install --prefix=/usr/local --install-data=/usr/local/share

July 16, 2005, at 07:13 PM by willpost -- Install python to run setup.py script
Added lines 64-65:

(If you get an error: "./setup.py: No such file or directory", then you might have to install python and then use the command # python setup.py install --prefix=/usr/local --install-data=/usr/local/share) - willpost

May 29, 2005, at 01:24 PM by Tim --
Changed lines 72-73 from:

Your next job is to download the OE-related openembedded/ directory. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/oe_wiki/index.php/BitKeeper, but you must get them from the following nslu2-linux repository instead of the ones stated on that page:

to:

Your next job is to download the OE-related openembedded/ directory. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/cgi-bin/moin.cgi/BitKeeper, but you must get them from the following nslu2-linux repository instead of the ones stated on that page:

May 15, 2005, at 10:36 PM by Jimmy Desai -- There was a minor mistake in the text for the bb.env file. In the export BBPATH=${BUILDDIR}...., there was one D missing
Changed lines 157-158 from:

export BBPATH=${BUILDIR}:${PKGDIR}

to:

export BBPATH=${BUILDDIR}:${PKGDIR}

March 23, 2005, at 11:37 PM by nav --
Changed line 44 from:

You now have the otion of following the StepByStepSetup, which will tell you what to do, without explaining much of the reasoning, or you can continue with the following steps, which give extra information, but require you to fill in some blanks.

to:

You now have the option of following the StepByStepSetup, which will tell you what to do, without explaining much of the reasoning, or you can continue with the following steps, which give extra information, but require you to fill in some blanks.

March 17, 2005, at 04:08 PM by n1xnx --
Changed line 68 from:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded. BBPATH and other necessary variables that were set by oe.env can now be set with the script bitbake/contrib/bbdev.sh.

to:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded. (The path to your build directory should come first.) BBPATH and other necessary variables that were set by oe.env can now be set with the script bitbake/contrib/bbdev.sh.

March 08, 2005, at 10:00 PM by djfoobarmatt --
Added lines 185-186:

Use the usual upgrade method to load the openslug-nslu2-timestamp.flashdisk.img file, see HowTo.InstallUnslungFirmware.

February 12, 2005, at 02:41 AM by jbowler --
Added lines 64-65:

Important: once you have installed the bitbake software the installed version takes precedence over the version in the svn tree. If you subsequently follow the StepByStepSetup instructions these do not install the software, but python will find the old installed versions. Either reinstall or remove or rename the installed bb directory.

Added lines 191-192:

Under some circumstances changes in bitbake itself may result in the system not building after a pull. You will then have to update the bitbake source code from svn. One example of the effects of this is at the end of StepByStepSetup. In general this is worth double checking if the build starts giving mysterious python tracebacks after a pull.

January 28, 2005, at 07:21 AM by jbowler --
Added lines 21-22:

The temp build directory for OpenSlug requires approximately 2GB (2005-01-25).

January 19, 2005, at 10:01 PM by robertd --
Changed line 18 from:

As of 2005-01-18 the /home/slung directory need at least 3.3GB. The temp build directory "/home/slug/build/tmp" for "bitbake unslung-image" needs 2.5GB and can be changed by editing /home/slug/build/conf/local.conf and adding TMPDIR=/new/path/to/tmp/dir.

to:

As of 2005-01-18 the /home/slung directory needs at least 3.3GB. The temp build directory "/home/slug/build/tmp" for "bitbake unslung-image" needs 2.5GB and can be changed by editing /home/slug/build/conf/local.conf and adding TMPDIR=/new/path/to/tmp/dir.

Added line 199:
January 19, 2005, at 09:59 PM by robertd --
Changed lines 16-19 from:

You should have at least 512MB RAM to complete this process with reasonable amount of swapping. It is sufficient with 3GB free disk space after installation of the require software.

to:

You should have at least 512MB RAM to complete this process with reasonable amount of swapping.

As of 2005-01-18 the /home/slung directory need at least 3.3GB. The temp build directory "/home/slug/build/tmp" for "bitbake unslung-image" needs 2.5GB and can be changed by editing /home/slug/build/conf/local.conf and adding TMPDIR=/new/path/to/tmp/dir. The tmp dir should not be a symlink as this will break autconf.

Changed lines 186-199 from:
 $ (cd openembedded ; bk pull ; bk -r co -q)
to:
 $ (cd openembedded ; bk pull ; bk -r co -q)

Speeding up the bitbake

It's possible to restrict the bitbake of the OpenEmbedded packages to only Unslung and OpenSlug packages. This reduces the numeber of packages from 2000 to around 330.

The instructions are on the the following page:

http://www.nslu2-linux.org/wiki/OpenEmbedded/NSLU2PackageSymlinks

By using NSLU2PackageSymlinks a Duron 2GHz with 768MB did a bitbake unslung image in 75 minutes.

Problems & Solutions

2005-01-19: There might be a problem doing a "bitbake unslung-image" without the NSLU2PackageSymlinks. Please try using the instructions on http://www.nslu2-linux.org/wiki/OpenEmbedded/NSLU2PackageSymlinks.

January 18, 2005, at 04:08 PM by RobertD --
Changed line 16 from:

You should have at least 512MB RAM to complete this process with reasonable amount of swapping. It is sufficient with 1GB free disk space after installation of the require software.

to:

You should have at least 512MB RAM to complete this process with reasonable amount of swapping. It is sufficient with 3GB free disk space after installation of the require software.

January 09, 2005, at 03:47 PM by bobtm --
Added lines 14-17:

The required hardware

You should have at least 512MB RAM to complete this process with reasonable amount of swapping. It is sufficient with 1GB free disk space after installation of the require software.

January 09, 2005, at 03:08 PM by bobtm --
Changed line 106 from:
 $ chmod o+w ${OEBUILD}/conf/local.conf
to:
 $ chmod u+w ${OEBUILD}/conf/local.conf
January 09, 2005, at 03:07 PM by bobtm --
Changed line 102 from:

Grabbing a template for this file from your openembedded/ directory:

to:

Grabbing a template for this file from your openembedded/ directory and make it writable:

Changed line 106 from:
to:
 $ chmod o+w ${OEBUILD}/conf/local.conf
January 09, 2005, at 03:00 PM by bobtm --
Added lines 65-66:

NOTE: Your host name must be fully qualified (host.domainname) for this process to complete.

December 26, 2004, at 11:42 PM by Forrest --
Changed line 57 from:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded. BBPATH and other necessary variables that were set by oe.env can now be set with the script bitbake/contribe/bbdev.sh.

to:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded. BBPATH and other necessary variables that were set by oe.env can now be set with the script bitbake/contrib/bbdev.sh.

December 11, 2004, at 09:12 PM by perlguru --
Changed line 132 from:

@@OEROOT=/home/slug\\

to:

@@export OEROOT=/home/slug\\

Changed line 135 from:

@@PKGDIR=$(OEROOT)/openembedded\\

to:

@@export PKGDIR=${OEROOT}/openembedded\\

Changed line 138 from:

@@BUILDDIR=$(OEROOT)/build\\

to:

@@export BUILDDIR=${OEROOT}/build\\

Changed line 141 from:

@@PYTHONPATH=/usr/local/lib/python2.3/site-packages/:$PYTHONPATH\\

to:

@@export PYTHONPATH=/usr/local/lib/python2.3/site-packages/:$PYTHONPATH\\

Changed line 144 from:

BBPATH=$(BUILDIR):$(PKGDIR)

to:

export BBPATH=${BUILDIR}:${PKGDIR}

Changed line 146 from:

cd $(BUILDDIR)

to:

cd ${BUILDDIR}

December 11, 2004, at 09:10 PM by perlguru --
Added lines 69-73:

NOTE: If you are upgrading from a pre-bitbake situation. It is better to redo this step.

    cd ${OEROOT}    
    rm -rf packages/
    bk clone bk://nslu2-linux.bkbits.net/openembedded
Changed line 135 from:

@@PKGDIR=$(OEROOT)/openembedded/packages\\

to:

@@PKGDIR=$(OEROOT)/openembedded\\

December 10, 2004, at 09:13 AM by rwhitby --
Changed line 118 from:

The oe.env file can no longer be used to set up the environmental variables. a similar file can be created from the code below. Simply copy and paste it into a file called bb.env and then the command source bb.env will get you going. (Note that this file will need to be modified to match the paths on your system, the OEROOT is probably the only one that needs changed)

to:

Simply copy and paste the sample commands below into a file called bb.env and then the command source bb.env will get you going. (Note that this file will need to be modified to match the paths on your system, the OEROOT is probably the only one that needs changed if you've put your workspace in a different place)

December 10, 2004, at 09:11 AM by rwhitby --
Added lines 37-42:

Set up a workspace

 mkdir /home/slug

 cd /home/slug
Changed line 95 from:

Grabbing a template for this file from your packages/ directory:

to:

Grabbing a template for this file from your openembedded/ directory:

Changed line 104 from:
  OEROOT = (whatever)\\
to:
  OEROOT = /home/slug\\
Changed line 127 from:

@@OEROOT=/...whatever.../(the folder that contains the dir openembbeded)\\

to:

@@OEROOT=/home/slug\\

Changed line 169 from:

If you want to redo a build, or the build failed and you made some fixes, all you need to do is remove the entire .../build/tmp/ directory, and rerun the oemake unslung-image command. Before you do that, however, if you want to keep up to date, you might want to make sure you have the latest versions of everything in your oe/ and packages/ directories by running:

to:

If you want to redo a build, or the build failed and you made some fixes, all you need to do is remove the entire .../build/tmp/ directory, and rerun the oemake unslung-image command. Before you do that, however, if you want to keep up to date, you might want to make sure you have the latest versions of everything in your openembedded/ directory by running:

Changed line 172 from:
 $ bk pull; bk -r co -q
to:
 $ (cd openembedded ; bk pull ; bk -r co -q)
December 10, 2004, at 03:19 AM by ChrisE --
Changed line 110 from:

Creating and running the oe.env environment script

to:

Creating and running the bb.env environment script

Changed line 112 from:

You can grab a sample environment script file from the http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript GettingStartedEnvironmentScript page, and copy it to, say, ${OEROOT}/oe.env. Unless you're doing something unusual, the only change you'll have to make is to set the actual OEROOT variable to the appropriate value. (Any other changes you might have to make should be obvious.)

to:

The oe.env file can no longer be used to set up the environmental variables. a similar file can be created from the code below. Simply copy and paste it into a file called bb.env and then the command source bb.env will get you going. (Note that this file will need to be modified to match the paths on your system, the OEROOT is probably the only one that needs changed)

Changed lines 114-118 from:

After you make that change (or those changes), you can set up your build environment by simply "sourcing" the script with:

to:

Once you do that, your working environment has been set up and you're in the build/ directory, ready to go.

Note that all subsequent =bitbake= commands have to be run from within the build/ directory.

Sample bb.env file:

Changed lines 121-122 from:
 $ . ./oe.env
to:

OEROOT=/...whatever.../(the folder that contains the dir openembbeded)
#the directory into which you downloaded everything

Added lines 124-125:

PKGDIR=$(OEROOT)/openembedded/packages
#the directory that contains all of the packages

Changed lines 127-133 from:

Once you do that, your working environment has been set up and you're in the build/ directory, ready to go.

to:

BUILDDIR=$(OEROOT)/build
#directory where all builds are done

PYTHONPATH=/usr/local/lib/python2.3/site-packages/:$PYTHONPATH
#Setup python to find the bb module

BBPATH=$(BUILDIR):$(PKGDIR)

Changed line 135 from:

Note that all subsequent =bitbake= commands have to be run from within the build/ directory.

to:

cd $(BUILDDIR)

December 10, 2004, at 01:17 AM by ChrisE --
Changed line 129 from:
 $ oemake -cfetch unslung-image
to:
 $ bitbake -cfetch unslung-image
Changed line 139 from:
 $ oemake unslung-image
to:
 $ bitbake unslung-image
Changed line 143 from:
 $ oemake openslug-image
to:
 $ bitbake openslug-image
December 10, 2004, at 01:16 AM by ChrisE --
Changed line 51 from:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded.

to:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded. BBPATH and other necessary variables that were set by oe.env can now be set with the script bitbake/contribe/bbdev.sh.

December 09, 2004, at 11:39 PM by ChrisE --
Added lines 51-52:

You will also need to set up the BBPATH variable. It needs to contain /path/to/build:/path/to/openembedded.

December 09, 2004, at 11:37 PM by ChrisE --
Changed line 55 from:
 bk://nslu2-linux.bkbits.net/packages
to:
 bk://nslu2-linux.bkbits.net/openembedded
December 09, 2004, at 11:35 PM by ChrisE --
Added lines 45-50:

Installing BitBake Software

After downloading BitBake you will need to install the BitBake software. To install, cd into the BitBake directory you just created and type ./setup.py install --prefix=/usr/local --install-data=/usr/local/share.

Now type bitbake at the command line and see if there are any errors. If you get an error about not being able to load the bb module you need to modify your PYTHONPATH variable. To do this type export PYTHONPATH=/usr/local/lib/python2.3/site-packages/:$PYTHONPATH.

December 09, 2004, at 11:27 PM by rwhitby --
Changed lines 9-10 from:
  1. download the oe/ and packages/ source from the nslu2-linux repository
to:
  1. download BitBake from the BitBake SubVersion repository
  2. download the openembedded/ source from the nslu2-linux repository
Changed line 12 from:
  1. $ oemake unslung-image, whose eventual output will be a flashable image for your device
to:
  1. $ bitbake unslung-image, whose eventual output will be a flashable image for your device
Changed line 16 from:

There is already a wiki page that describes what (non-OE) software should already exist on your Linux system -- see OE's http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware Required Software page.

to:

There is already a wiki page that describes what (non-OE) software should already exist on your Linux system -- see our http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware Required Software page.

Changed line 22 from:
  • There is apparently no way to avoid building the documentation packages so, yes, you do need the various DocBook? and SGML tools. This is an unfortunate situation that will eventually be rectified.
to:
  • There is apparently no way to avoid building the documentation packages so, yes, you do need the various DocBook? and SGML tools. This is an unfortunate situation that is out of our hands (talk to the BitBake maintainers if you feel strongly about it).
Changed line 37 from:

Getting the OE software

to:

Getting the BitBake software

Changed line 39 from:

Your first job is to download the OE-related oe/ and packages/ directories into the directory of your choice. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/oe_wiki/index.php/BitKeeper, but you must get them from the following nslu2-linux repositories instead of the ones stated on that page:

to:

Your first job is to download the BitBake software. Install SubVersion, and then run:

Changed line 41 from:

bk://nslu2-linux.bkbits.net/oe

to:
 svn co svn://svn.berlios.de/bitbake/trunk/bitbake
Changed line 43 from:

bk://nslu2-linux.bkbits.net/packages

to:

This will create a bitbake/ directory in the current directory. Remain in this current directory (not the bitbake subdirectory) for the following steps (all the other directories go alongside the bitbake/ directory).

Changed line 45 from:

All you're after is the downloading and creation of two sibling directories:

to:

Getting the OE packages and metadata

Changed lines 47-48 from:
  • oe/ (about 1 M)
  • packages/ (about 95M)
to:

Your next job is to download the OE-related openembedded/ directory. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/oe_wiki/index.php/BitKeeper, but you must get them from the following nslu2-linux repository instead of the ones stated on that page:

 bk://nslu2-linux.bkbits.net/packages

All you're after is the downloading and creation of one sibling directory:

  • openembedded/ (about 100M)
Changed line 57 from:

Once you've downloaded the oe/ and packages/ directories, you need to create a few more directories and files to complete the picture before you can start your build. Here's a fairly generic directory structure you can use for the build, along with some representative variable names that, in some cases, match their usage in some of the configuration files:

to:

Once you've downloaded the bitbake/ and openembedded/ directories, you need to create a few more directories and files to complete the picture before you can start your build. Here's a fairly generic directory structure you can use for the build, along with some representative variable names that, in some cases, match their usage in some of the configuration files:

Changed lines 60-62 from:
   .../myoestuff/             (OEROOT, wherever you downloaded the previous stuff)
          oe/                 (OESYS)
          packages/           (PKGDIR)
to:
   /home/slug/                (OEROOT, wherever you downloaded the previous stuff)
          bitbake/            (OESYS)
          openembedded/       (PKGDIR)
Deleted lines 74-75:
Changed line 92 from:
  OEFILES = ${OEROOT}/packages/*/*.oe\\
to:
  BBFILES = ${OEROOT}/openembedded/packages/*/*.bb\\
Changed line 114 from:

Note that all subsequent =oemake= commands have to be run from within the build/ directory.

to:

Note that all subsequent =bitbake= commands have to be run from within the build/ directory.

December 05, 2004, at 12:49 AM by ka6sox --
Changed line 30 from:

http://www-106.ibm.com/developerworks/linux/library/l-ccache.html?ca=dgr-lnxw09ccache, but you don't really need to know how it works to take advantage of it.

to:

http://www-106.ibm.com/developerworks/linux/library/l-ccache.html?ca=dgr-lnxw09ccache this, but you don't really need to know how it works to take advantage of it.

Changed line 141 from:
 $ bk pull; bk -r co -q
to:
 $ bk pull; bk -r co -q
December 02, 2004, at 02:15 AM by tlhackque --
Changed line 15 from:

There is already a wiki page that describes what (non-OE) software should already exist on your Linux system -- see OE's http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page.

to:

There is already a wiki page that describes what (non-OE) software should already exist on your Linux system -- see OE's http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware Required Software page.

Changed line 19 from:
  • A FC2? system has only version 2.5.4 of the patch utility, but this seems to be adequate. I don't know of any compelling reason to have to upgrade to version 2.5.9 as the http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page suggests; if anyone knows, feel free to add it here, but version 2.5.4 appears to work just fine.
to:
  • A FC2? system has only version 2.5.4 of the patch utility, but this seems to be adequate. I don't know of any compelling reason to have to upgrade to version 2.5.9 as the http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware Required Software page suggests; if anyone knows, feel free to add it here, but version 2.5.4 appears to work just fine.
October 31, 2004, at 06:27 AM by peteru --
Changed line 5 from:

The phases of the build

to:

The phases of the build

Changed line 13 from:

The required software

to:

The required software

Changed lines 32-36 from:

Getting the OE software

to:

Where to next?

You now have the otion of following the StepByStepSetup, which will tell you what to do, without explaining much of the reasoning, or you can continue with the following steps, which give extra information, but require you to fill in some blanks.

Getting the OE software

Changed line 49 from:

The directory structure

to:

The directory structure

Changed line 75 from:

Setting up your build/conf/local.conf file

to:

Setting up your build/conf/local.conf file

Changed line 98 from:

Creating and running the oe.env environment script

to:

Creating and running the oe.env environment script

Changed line 112 from:

Pre-fetching the sources

to:

Pre-fetching the sources

Changed line 122 from:

Building the image(s) and getting the results

to:

Building the image(s) and getting the results

Changed line 136 from:

Redoing the build from scratch

to:

Redoing the build from scratch

October 29, 2004, at 06:57 PM by cc --
Changed line 3 from:

This document represents a step-by-step description of how to build the Unslung firmware using OE. Thanks to Kergoth for writing the first version of this page.

to:

This document represents a step-by-step description of how to build the Unslung or OpenSlug firmware using OE. Thanks to Kergoth for writing the first version of this page.

Added lines 88-90:

In the case you are targeting an OpenSlug build, alternatively set

  DISTRO = openslug
Added lines 124-127:

or

 $ oemake openslug-image
October 07, 2004, at 07:43 AM by rwhitby --
Changed line 93 from:

Once the toolchain is installed, you can grab a sample environment script file from the http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript GettingStartedEnvironmentScript page, and copy it to, say, ${OEROOT}/oe.env. Unless you're doing something unusual, the only change you'll have to make is to set the actual OEROOT variable to the appropriate value. (Any other changes you might have to make should be obvious.)

to:

You can grab a sample environment script file from the http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript GettingStartedEnvironmentScript page, and copy it to, say, ${OEROOT}/oe.env. Unless you're doing something unusual, the only change you'll have to make is to set the actual OEROOT variable to the appropriate value. (Any other changes you might have to make should be obvious.)

October 07, 2004, at 07:43 AM by rwhitby --
Changed line 3 from:

This document represents a step-by-step description of how to build the Unslung firmware using OE.

to:

This document represents a step-by-step description of how to build the Unslung firmware using OE. Thanks to Kergoth for writing the first version of this page.

October 07, 2004, at 07:41 AM by rwhitby --
Changed line 48 from:

<pre>

to:
Changed line 54 from:

</pre>

to:
Changed line 57 from:

<pre>

to:
Changed line 65 from:

</pre>

to:
Changed line 75 from:

<pre>

to:
Changed line 77 from:

</pre>

to:
Changed lines 81-85 from:

<verbatim>

  OEROOT = (whatever)
  DL_DIR = ${OEROOT}/sources
  OEFILES = ${OEROOT}/packages/*/*.oe
  MACHINE = nslu2
to:
  OEROOT = (whatever)
DL_DIR = ${OEROOT}/sources
OEFILES = ${OEROOT}/packages/*/*.oe
MACHINE = nslu2\\
Changed line 87 from:

</verbatim>

to:
Changed line 97 from:

<pre>

to:
Changed line 99 from:

</pre>

to:
Changed line 109 from:

<pre>

to:
Changed line 111 from:

</pre>

to:
Changed line 119 from:

<pre>

to:
Changed line 121 from:

</pre>

to:
Changed line 129 from:

<pre>

to:
Deleted line 130:

</pre>

October 07, 2004, at 07:41 AM by rwhitby --
Changed line 9 from:
  1. download the oe/ and packages/ source from the nslu2-linux repository
to:
  1. download the oe/ and packages/ source from the nslu2-linux repository
Changed line 11 from:
  1. $ oemake unslung-image, whose eventual output will be a flashable image for your device
to:
  1. $ oemake unslung-image, whose eventual output will be a flashable image for your device
Changed line 19 from:
  • A FC2? system has only version 2.5.4 of the =patch= utility, but this seems to be adequate. I don't know of any compelling reason to have to upgrade to version 2.5.9 as the http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page suggests; if anyone knows, feel free to add it here, but version 2.5.4 appears to work just fine.
to:
  • A FC2? system has only version 2.5.4 of the patch utility, but this seems to be adequate. I don't know of any compelling reason to have to upgrade to version 2.5.9 as the http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page suggests; if anyone knows, feel free to add it here, but version 2.5.4 appears to work just fine.
Changed line 21 from:
  • There is apparently no way to avoid building the documentation packages so, yes, you do need the various ~DocBook? and ~SGML tools. This is an unfortunate situation that will eventually be rectified.
to:
  • There is apparently no way to avoid building the documentation packages so, yes, you do need the various DocBook? and SGML tools. This is an unfortunate situation that will eventually be rectified.
Changed line 25 from:
  • The [Psyco JIT Compiler|http://psyco.sf.net] may be optional, but it's *strongly* recommended -- it will speed things up noticeably.
to:
  • The http://psyco.sf.net Psyco JIT Compiler may be optional, but it's *strongly* recommended -- it will speed things up noticeably.
Changed line 27 from:
  • The [ccache|http://ccache.samba.org/] compiler cache program is also optional, but if you're going to use it, note that it will only speed things up after your first build. It won't make any difference when you're starting from scratch. And if you plan on using it, apparently, you have to use it right from the beginning -- adding it later will cause problems with =libtool=. Bottom line -- use it right from the start, or don't use it at all.
to:
  • The http://ccache.samba.org/ ccache compiler cache program is also optional, but if you're going to use it, note that it will only speed things up after your first build. It won't make any difference when you're starting from scratch. And if you plan on using it, apparently, you have to use it right from the beginning -- adding it later will cause problems with libtool. Bottom line -- use it right from the start, or don't use it at all.
Changed line 34 from:

Your first job is to download the OE-related =oe/= and =packages/= directories into the directory of your choice. You get them from the ~BitKeeper repo. The process for doing this is documented at [http://openembedded.org/oe_wiki/index.php/BitKeeper], but you must get them from the following nslu2-linux repositories instead of the ones stated on that page:

to:

Your first job is to download the OE-related oe/ and packages/ directories into the directory of your choice. You get them from the BitKeeper repo. The process for doing this is documented at http://openembedded.org/oe_wiki/index.php/BitKeeper, but you must get them from the following nslu2-linux repositories instead of the ones stated on that page:

Added line 37:
Changed lines 42-43 from:
  • =oe/= (about 1 M)
  • =packages/= (about 95M)
to:
  • oe/ (about 1 M)
  • packages/ (about 95M)
Changed line 47 from:

Once you've downloaded the =oe/= and =packages/= directories, you need to create a few more directories and files to complete the picture before you can start your build. Here's a fairly generic directory structure you can use for the build, along with some representative variable names that, in some cases, match their usage in some of the configuration files:

to:

Once you've downloaded the oe/ and packages/ directories, you need to create a few more directories and files to complete the picture before you can start your build. Here's a fairly generic directory structure you can use for the build, along with some representative variable names that, in some cases, match their usage in some of the configuration files:

Changed line 67 from:

Of the above, you only need to create the =build/conf/local.conf= file; the other two directories will be created automatically when you do a build so you can ignore them for the time being.

to:

Of the above, you only need to create the build/conf/local.conf file; the other two directories will be created automatically when you do a build so you can ignore them for the time being.

Changed line 69 from:
  • NOTE* that you can create the =tmp/= and =sources/= directories elsewhere if you want, just by setting the appropriate variables in your configuration file, as explained in the next section.
to:
  • NOTE* that you can create the tmp/ and sources/ directories elsewhere if you want, just by setting the appropriate variables in your configuration file, as explained in the next section.
Changed line 71 from:

Setting up your =build/conf/local.conf= file

to:

Setting up your build/conf/local.conf file

Changed line 73 from:

Grabbing a template for this file from your =packages/= directory:

to:

Grabbing a template for this file from your packages/ directory:

Changed line 91 from:

Creating and running the =oe.env= environment script

to:

Creating and running the oe.env environment script

Changed line 93 from:

Once the toolchain is installed, you can grab a sample environment script file from the [http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript] page, and copy it to, say, =${OEROOT}/oe.env=. Unless you're doing something unusual, the only change you'll have to make is to set the actual =OEROOT= variable to the appropriate value. (Any other changes you might have to make should be obvious.)

to:

Once the toolchain is installed, you can grab a sample environment script file from the http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript GettingStartedEnvironmentScript page, and copy it to, say, ${OEROOT}/oe.env. Unless you're doing something unusual, the only change you'll have to make is to set the actual OEROOT variable to the appropriate value. (Any other changes you might have to make should be obvious.)

Changed line 101 from:

Once you do that, your working environment has been set up and you're in the =build/= directory, ready to go.

to:

Once you do that, your working environment has been set up and you're in the build/ directory, ready to go.

Changed line 103 from:

Note that all subsequent =oemake= commands have to be run from within the =build/= directory.

to:

Note that all subsequent =oemake= commands have to be run from within the build/ directory.

Changed line 107 from:

When you eventually start a build, part of the build process is to download a pile of sources, by default into the directory =${OEROOT}/sources=. If you want to get that out of the way first, or if you want to pre-fetch those sources in preparation for disconnecting from the net and still being able to do a build later, you can run:

to:

When you eventually start a build, part of the build process is to download a pile of sources, by default into the directory ${OEROOT}/sources. If you want to get that out of the way first, or if you want to pre-fetch those sources in preparation for disconnecting from the net and still being able to do a build later, you can run:

Changed line 113 from:

This will load up your =sources/= directory without actually starting the build process. Of course, this step is entirely optional. (On my system, that directory consumes about 230M of space, so you definitely want to have a fast net connection.)

to:

This will load up your sources/ directory without actually starting the build process. Of course, this step is entirely optional. (On my system, that directory consumes about 230M of space, so you definitely want to have a fast net connection.)

Changed line 117 from:

All of the build intermediate results are placed in the directory =${OEROOT}/build/tmp=, so make sure you have sufficient room for this. To build a minimal flashable image, run:

to:

All of the build intermediate results are placed in the directory ${OEROOT}/build/tmp, so make sure you have sufficient room for this. To build a minimal flashable image, run:

Changed line 127 from:

If you want to redo a build, or the build failed and you made some fixes, all you need to do is remove the entire =.../build/tmp/= directory, and rerun the =oemake bootstrap-image= command. Before you do that, however, if you want to keep up to date, you might want to make sure you have the latest versions of everything in your =oe/= and =packages/= directories by running:

to:

If you want to redo a build, or the build failed and you made some fixes, all you need to do is remove the entire .../build/tmp/ directory, and rerun the oemake unslung-image command. Before you do that, however, if you want to keep up to date, you might want to make sure you have the latest versions of everything in your oe/ and packages/ directories by running:

October 07, 2004, at 07:37 AM by rwhitby --
Changed line 1 from:

openembedded for the NSLU2

to:

Overview

Changed line 3 from:

The following steps should get you started with openembedded for the NSLU2.

to:

This document represents a step-by-step description of how to build the Unslung firmware using OE.

Changed line 5 from:

Check http://openembedded.org/oe_wiki/index.php/GettingStarted for more information and help.

to:

The phases of the build

Changed line 7 from:

0.) Install required software

to:

The entire build is done in several steps (all of which are explained in detail below):

Changed lines 9-18 from:

Required:

  • python
  • ccache
  • patch
  • m4
  • sed
  • docbook
  • bison
  • make
  • openjade
to:
  1. download the oe/ and packages/ source from the nslu2-linux repository
  2. edit one or more configuration files to reflect that you're building for an nslu2
  3. $ oemake unslung-image, whose eventual output will be a flashable image for your device
Changed lines 13-15 from:

Optional:

  • psyco
  • bitkeeper (http://www.bitkeeper.com/Products.Downloads.html)
to:

The required software

Changed line 15 from:

http://openembedded.org/oe_wiki/index.php/RequiredSoftware

to:

There is already a wiki page that describes what (non-OE) software should already exist on your Linux system -- see OE's http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page.

Changed line 17 from:

1.) get the oe files and packages with bitkeeper or get snapshots from http://treke.net/oe/snapshots/

to:

First, regarding the actual _required_ software, a couple of observations:

Changed lines 19-20 from:
 bk clone bk://openembedded.bkbits.net/oe oe
 bk clone bk://openembedded.bkbits.net/packages packages
to:
  • A FC2? system has only version 2.5.4 of the =patch= utility, but this seems to be adequate. I don't know of any compelling reason to have to upgrade to version 2.5.9 as the http://openembedded.org/oe_wiki/index.php/RequiredSoftware RequiredSoftware page suggests; if anyone knows, feel free to add it here, but version 2.5.4 appears to work just fine.
Added line 21:
  • There is apparently no way to avoid building the documentation packages so, yes, you do need the various ~DocBook? and ~SGML tools. This is an unfortunate situation that will eventually be rectified.
Changed line 23 from:

2.) create necessary files:

to:

Regarding what are actually _optional_ packages:

Changed line 25 from:

a. create a file `conf/local.conf` with (at least) the following contents

to:
  • The [Psyco JIT Compiler|http://psyco.sf.net] may be optional, but it's *strongly* recommended -- it will speed things up noticeably.
Changed lines 27-31 from:
 DL_DIR = "/your/path/to/oe/sources"
 OEFILES := "/your/path/to/oe/packages/*/*.oe"
 MACHINE = "nslu2"
 DISTRO = "unslung"
 CACHE=/var/tmp/oe-cache.${USER}
to:
  • The [ccache|http://ccache.samba.org/] compiler cache program is also optional, but if you're going to use it, note that it will only speed things up after your first build. It won't make any difference when you're starting from scratch. And if you plan on using it, apparently, you have to use it right from the beginning -- adding it later will cause problems with =libtool=. Bottom line -- use it right from the start, or don't use it at all.
Changed lines 29-30 from:

b. create a script `env.sh` like this

to:

If you want a tutorial on ccache, I suggest http://www-106.ibm.com/developerworks/linux/library/l-ccache.html?ca=dgr-lnxw09ccache, but you don't really need to know how it works to take advantage of it.

Changed lines 32-36 from:
 BASE=/data/mtx/oe/oe.write
 OEROOT=${BASE}/oe
 PKGDIR=${BASE}/packages
 OEBUILD=${BASE}
 DL_DIR=/data/mtx/oe/sources
to:

Getting the OE software

Changed lines 34-37 from:
 export OEPATH=${OEBUILD}:${PKGDIR}:${OEROOT}
 export PATH=$OEROOT/bin:${PATH}
 export LD_LIBRARY_PATH=
 export LANG=C
to:

Your first job is to download the OE-related =oe/= and =packages/= directories into the directory of your choice. You get them from the ~BitKeeper repo. The process for doing this is documented at [http://openembedded.org/oe_wiki/index.php/BitKeeper], but you must get them from the following nslu2-linux repositories instead of the ones stated on that page:

Changed lines 36-37 from:
 echo "Altered environment for OE Development"
to:

bk://nslu2-linux.bkbits.net/oe bk://nslu2-linux.bkbits.net/packages

Added line 39:

All you're after is the downloading and creation of two sibling directories:

Changed lines 41-42 from:

4.) set up the environment

to:
  • =oe/= (about 1 M)
  • =packages/= (about 95M)
Changed line 44 from:

you'll have to do this every time before you use openembedded!!!

to:

The directory structure

Changed lines 46-47 from:
 . env.sh
to:

Once you've downloaded the =oe/= and =packages/= directories, you need to create a few more directories and files to complete the picture before you can start your build. Here's a fairly generic directory structure you can use for the build, along with some representative variable names that, in some cases, match their usage in some of the configuration files: <pre>

Added lines 49-51:
   .../myoestuff/             (OEROOT, wherever you downloaded the previous stuff)
          oe/                 (OESYS)
          packages/           (PKGDIR)
Changed lines 53-54 from:

5.) build

now you can start building inside openembedded, eg, build the basic nylon image:

to:

</pre>

Changed lines 55-56 from:
 oemake nlsu-image-base
to:

In addition to the above, you'll have to create (or they'll be created for you) the following, also directly under your OEROOT directory: <pre>

Added lines 58-62:
          build/              (OEBUILD)
             conf/
                local.conf
             tmp/             (TMPDIR)
          sources/
Changed line 64 from:

oemake resolves all dependencies of a package. when it run for the first time, it will compile some native tools used by openembedded, then it will compile the toolchain, all required libraries, all required packages and finally create a jffs2 image which can then be loaded to the cube (see InstallFilesystemImages?). this will take some time, especially the first time, when the toolchain has to be build.

to:

</pre>

Changed line 66 from:

You can use oemake it to build any package including it's dependencies:

to:

Of the above, you only need to create the =build/conf/local.conf= file; the other two directories will be created automatically when you do a build so you can ignore them for the time being.

Changed line 68 from:
 oemake PACKAGENAME
to:
  • NOTE* that you can create the =tmp/= and =sources/= directories elsewhere if you want, just by setting the appropriate variables in your configuration file, as explained in the next section.
Added line 70:

Setting up your =build/conf/local.conf= file

Changed line 72 from:

If you want to build a specific version of a package, without all it's dependencies you can use

to:

Grabbing a template for this file from your =packages/= directory:

Changed lines 74-76 from:
 oebuild packages/PACKAGE/PACKAGE_VERSION.oe
to:

<pre>

 $ cp ${PKGDIR}/conf/local.conf.sample ${OEBUILD}/conf/local.conf

</pre>

Added line 78:

customize your copy of that file to reflect your build environment and final image, something along the lines of:

Changed lines 80-86 from:

There are some special directories in the package/ directory, which may be worth of mentioning here:

to:

<verbatim>

  OEROOT = (whatever)
  DL_DIR = ${OEROOT}/sources
  OEFILES = ${OEROOT}/packages/*/*.oe
  MACHINE = nslu2
  DISTRO = unslung

</verbatim>

Changed lines 88-91 from:
conf/distribution and machine configurations
site/autoconf cached results, necessary for cross-compiling badly behaved packaged
meta/filesystem image definitions
classes/reusable code used by .oe files with inherit
to:

Finally, remove or comment out the last line -- the one containing "=REMOVE_THIS_LINE=".

Changed lines 90-130 from:

to:

Creating and running the =oe.env= environment script

Once the toolchain is installed, you can grab a sample environment script file from the [http://openembedded.org/oe_wiki/index.php/GettingStartedEnvironmentScript] page, and copy it to, say, =${OEROOT}/oe.env=. Unless you're doing something unusual, the only change you'll have to make is to set the actual =OEROOT= variable to the appropriate value. (Any other changes you might have to make should be obvious.)

After you make that change (or those changes), you can set up your build environment by simply "sourcing" the script with:

<pre>

 $ . ./oe.env

</pre>

Once you do that, your working environment has been set up and you're in the =build/= directory, ready to go.

Note that all subsequent =oemake= commands have to be run from within the =build/= directory.

Pre-fetching the sources

When you eventually start a build, part of the build process is to download a pile of sources, by default into the directory =${OEROOT}/sources=. If you want to get that out of the way first, or if you want to pre-fetch those sources in preparation for disconnecting from the net and still being able to do a build later, you can run:

<pre>

 $ oemake -cfetch unslung-image

</pre>

This will load up your =sources/= directory without actually starting the build process. Of course, this step is entirely optional. (On my system, that directory consumes about 230M of space, so you definitely want to have a fast net connection.)

Building the image(s) and getting the results

All of the build intermediate results are placed in the directory =${OEROOT}/build/tmp=, so make sure you have sufficient room for this. To build a minimal flashable image, run:

<pre>

 $ oemake unslung-image

</pre>

The results will show up in .../build/tmp/deploy/images/.

Redoing the build from scratch

If you want to redo a build, or the build failed and you made some fixes, all you need to do is remove the entire =.../build/tmp/= directory, and rerun the =oemake bootstrap-image= command. Before you do that, however, if you want to keep up to date, you might want to make sure you have the latest versions of everything in your =oe/= and =packages/= directories by running:

<pre>

 $ bk pull; bk -r co -q

</pre>

October 07, 2004, at 07:23 AM by rwhitby --
Changed lines 38-40 from:
 MACHINE = "Xscale"
 TARGET_OS = "linux"
 DISTRO = "OpenSLUG?"
to:
 MACHINE = "nslu2"
 DISTRO = "unslung"
October 07, 2004, at 06:51 AM by ka6sox --
Changed line 24 from:

http://openembedded.org/oe_wiki/index.php/RequiredSoftware

to:

http://openembedded.org/oe_wiki/index.php/RequiredSoftware

October 07, 2004, at 06:49 AM by ka6sox --
Deleted lines 2-5:

the next version of the MeshCube? distribution will be based on the openembedded build system. openembedded is a very flexible source based meta distribution for embedded systems and cross-compiling. see http://openembedded.org/oe_wiki/ for more info.

our distribution within openembedded is called nylon, our hardware is called mtx-1. both together will be the MeshCube?.

Changed line 66 from:

5.) build ==

to:

5.) build

October 07, 2004, at 06:48 AM by ka6sox --
Changed line 1 from:

Hardware

to:

openembedded for the NSLU2

Changed lines 3-4 from:

Make sure that you have at least 512MB of RAM in machine used for builds. With less memory it will take eons
because current version of oemake takes lots of memory during work so swapping can eat you.

to:

the next version of the MeshCube? distribution will be based on the openembedded build system. openembedded is a very flexible source based meta distribution for embedded systems and cross-compiling. see http://openembedded.org/oe_wiki/ for more info.

Changed lines 5-9 from:

This mostly affects the packaging of glibc. To overcome this issue somewhat, if you have less than 512MB of RAM,you
can use "oebuild" to build glibc instead of oemake (oemake itself uses a lot of memory, so this makes more
of your RAM available to oebuild). To invoke oebuild, you must specify the location of the package
file and not just the package name. Remember that "oebuild" *does not* trace dependencies so you have to take
care of it by yourself (best method is oemake glibc and break when it start glibc unpacking - oebuild clean & oebuild).

to:

our distribution within openembedded is called nylon, our hardware is called mtx-1. both together will be the MeshCube?.

Changed line 7 from:

Doing a build

to:

The following steps should get you started with openembedded for the NSLU2.

Changed line 9 from:

(*Always read oe/doc/* first as this page may easily become outdated!*)

to:

Check http://openembedded.org/oe_wiki/index.php/GettingStarted for more information and help.

Changed lines 11-12 from:

NB Do not build OE as root, you don't need to and strange things can and will happen. If you need root access for something
to work on your machine, the build environment is set up wrong.

to:

0.) Install required software

Changed lines 13-22 from:

to:

Required:

  • python
  • ccache
  • patch
  • m4
  • sed
  • docbook
  • bison
  • make
  • openjade
Changed lines 24-26 from:

To start using OE, first get the code from BitKeeper. You need both the repositories 'oe' and 'packages'.

to:

Optional:

  • psyco
  • bitkeeper (http://www.bitkeeper.com/Products.Downloads.html)
Changed line 28 from:

If you are unable or unwilling to use BitKeeper, there are snapshots at http://treke.net/oe/snapshots/ . There is also [Anonymous CVS] available.

to:

http://openembedded.org/oe_wiki/index.php/RequiredSoftware

Changed line 30 from:

Make sure you have all the RequiredSoftware installed.

to:

1.) get the oe files and packages with bitkeeper or get snapshots from http://treke.net/oe/snapshots/

Changed lines 32-33 from:

Check out or unpack the sources into a location with no symlinks above it. Let's assume that root directory of your OpenEmbedded enviroment
will be in /stuff/. Recommended structure is:

to:
 bk clone bk://openembedded.bkbits.net/oe oe
 bk clone bk://openembedded.bkbits.net/packages packages
Changed lines 36-39 from:
 /stuff/oe/
 /stuff/packages/
 /stuff/build/
 /stuff/sources/
to:

2.) create necessary files:

Added line 38:

a. create a file `conf/local.conf` with (at least) the following contents

Changed lines 40-45 from:

Note: if you are using [Anonymous CVS] then you will get "oe-packages" instead of "packages". Rename it or remember that your enviroment differ a bit from this example.

to:
 DL_DIR = "/your/path/to/oe/sources"
 OEFILES := "/your/path/to/oe/packages/*/*.oe"
 MACHINE = "Xscale"
 TARGET_OS = "linux"
 DISTRO = "OpenSLUG?"
 CACHE=/var/tmp/oe-cache.${USER}
Changed line 47 from:

Create local configuration

to:

b. create a script `env.sh` like this

Added lines 49-53:
 BASE=/data/mtx/oe/oe.write
 OEROOT=${BASE}/oe
 PKGDIR=${BASE}/packages
 OEBUILD=${BASE}
 DL_DIR=/data/mtx/oe/sources
Changed lines 55-58 from:
 cd /stuff/build/
 mkdir conf/
 cat /stuff/packages/conf/local.conf.sample > conf/local.conf
 vi conf/local.conf
to:
 export OEPATH=${OEBUILD}:${PKGDIR}:${OEROOT}
 export PATH=$OEROOT/bin:${PATH}
 export LD_LIBRARY_PATH=
 export LANG=C
Changed lines 60-61 from:

You'll probably want to add some mirrors to the end of =local.conf= --- see UsingMirrors?


to:
 echo "Altered environment for OE Development"
Deleted line 61:

Setup the environment

Changed line 63 from:

Check out the GettingStartedEnvironmentScript sample and customize it to your OE installation.

to:

4.) set up the environment

Changed line 65 from:

Save it as /stuff/env-dev-arm-oe.source or similar

to:

you'll have to do this every time before you use openembedded!!!

Changed line 67 from:

Then source it:

to:
 . env.sh
Deleted line 68:
  $ . /stuff/env-dev-arm-oe.source
Added lines 70-71:

5.) build ==

now you can start building inside openembedded, eg, build the basic nylon image:

Changed line 73 from:

Note: Sourcing this file will put you in your configured build directory. ALL oemake commands should be issue from this directory.

to:
 oemake nlsu-image-base
Deleted line 74:

Changed line 76 from:

Start building

to:

oemake resolves all dependencies of a package. when it run for the first time, it will compile some native tools used by openembedded, then it will compile the toolchain, all required libraries, all required packages and finally create a jffs2 image which can then be loaded to the cube (see InstallFilesystemImages?). this will take some time, especially the first time, when the toolchain has to be build.

Changed line 78 from:

oemake

to:

You can use oemake it to build any package including it's dependencies:

Changed lines 80-81 from:

The primary interface to the build system is the "oemake" command (see the [oemake] page). <code>oemake</code> will download and patch stuff from the network, so it helps if you are on a well connected machine.

to:
 oemake PACKAGENAME
Deleted line 81:

Here are some example invocations:

Changed line 83 from:

Building a single package (e.g. nano):

to:

If you want to build a specific version of a package, without all it's dependencies you can use

Changed line 85 from:
 oemake nano
to:
 oebuild packages/PACKAGE/PACKAGE_VERSION.oe
Changed line 88 from:

Building package sets (e.g. task-bootstrap):

to:

There are some special directories in the package/ directory, which may be worth of mentioning here:

Changed lines 90-93 from:
 oemake task-bootstrap
to:
conf/distribution and machine configurations
site/autoconf cached results, necessary for cross-compiling badly behaved packaged
meta/filesystem image definitions
classes/reusable code used by .oe files with inherit
Changed lines 95-152 from:

Building a group of packages and deploying them into a rootfs image:

GPE:

 oemake gpe-image

OPIE:

 oemake opie-image

Building every package in the repository (Attention! This will take a long time and needs approx. 5 GB disk space):

 oemake world

Note: at least on my system I needed to have =ccache= installed for the build to (mostly) work. (See also the RequiredSoftware page.)

See [UsefulTargets?] for a description of some of the more useful meta-packages.


Output of the build process (temporary files, log files and the binaries) all ends up in the tmp directory. Most interesting is probably the tmp/work/ directory. Just have a look around the DirectoryStructure?.

Once you have managed to build a package, try to [BuildIPKFiles?].

Problems

Try to solve problems first by checking that you have done everything right, that nothing has changed from this description and that you have the latest code (see BitKeeper description). Look also in the log file (referenced in any error message you will receive). If you still have problems, try checking [PossibleFailures?], and if problems persist, ask on [IRC].

Portability issues

Make sure to set TARGET_OS to linux in local.conf if your host isn't linux.

GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils) into your OE development path.

FreeBSD? 4 users: Perl 5.0 is too old. A more recent perl must be available as /usr/bin/perl. Unfortunately just having more recent perl in the path isn't good enough. Some scripts are hard-coded for /usr/bin/perl

FreeBSD? users: Set BUILD_OS in local.conf to freebsdN where N is your major version number. At least the cross gcc wants this.

__Install ccache__ When you rm -rf packages/tmp for the 20th time while trying to get things to work you'll be glad you did.


What's next?

See [OzTODO3?.5.1]

to:

October 07, 2004, at 05:14 AM by ka6sox --
Changed line 4 from:
 because current version of "oemake" takes lots of memory during work so swapping can eat you.
to:
 because current version of oemake takes lots of memory during work so swapping can eat you.
Changed lines 6-10 from:

This mostly affects the packaging of glibc. To overcome this issue somewhat, if you have less than 512MB of RAM,

 you can use "oebuild" to build glibc instead of "oemake" ("oemake" itself uses a lot of memory, so this makes more
of your RAM available to "oebuild"). To invoke "oebuild", you must specify the location of the package
file and not just the package name. Remember that "oebuild" *does not* trace dependencies so you have to take
care of it by yourself (best method is "oemake glibc" and break when it start glibc unpacking - "oebuild clean" & "oebuild").
to:

This mostly affects the packaging of glibc. To overcome this issue somewhat, if you have less than 512MB of RAM,you
can use "oebuild" to build glibc instead of oemake (oemake itself uses a lot of memory, so this makes more
of your RAM available to oebuild). To invoke oebuild, you must specify the location of the package
file and not just the package name. Remember that "oebuild" *does not* trace dependencies so you have to take
care of it by yourself (best method is oemake glibc and break when it start glibc unpacking - oebuild clean & oebuild).

Changed line 14 from:

(*Always read "oe/doc/*" first as this page may easily become outdated!*)

to:

(*Always read oe/doc/* first as this page may easily become outdated!*)

Changed lines 21-22 from:

To start using OE, first get the code from BitKeeper. You need both the repositories 'oe' and 'packages'.

to:

To start using OE, first get the code from BitKeeper. You need both the repositories 'oe' and 'packages'.

Changed lines 31-34 from:

/stuff/oe/ /stuff/packages/ /stuff/build/ /stuff/sources/

to:
 /stuff/oe/
 /stuff/packages/
 /stuff/build/
 /stuff/sources/
Changed lines 41-46 from:

<verbatim> cd /stuff/build/ mkdir conf/ cat /stuff/packages/conf/local.conf.sample > conf/local.conf vi conf/local.conf </verbatim>

to:
 cd /stuff/build/
 mkdir conf/
 cat /stuff/packages/conf/local.conf.sample > conf/local.conf
 vi conf/local.conf
Added line 55:
Changed lines 57-59 from:

<verbatim>

 $ . /stuff/env-dev-arm-oe.source

</verbatim>

to:
  $ . /stuff/env-dev-arm-oe.source
Changed line 75 from:

<verbatim>

to:
Changed line 77 from:

</verbatim>

to:
Changed line 80 from:

<verbatim>

to:
Changed line 82 from:

</verbatim>

to:
Changed line 87 from:

<verbatim>

to:
Changed line 89 from:

</verbatim>

to:
Changed lines 92-94 from:

<verbatim> oemake opie-image </verbatim>

to:
 oemake opie-image
Changed line 98 from:

<verbatim>

to:
Deleted line 99:

</verbatim>

Changed lines 101-102 from:

<b>Note</b>: at least on my system I needed to have =ccache= installed

to:

Note: at least on my system I needed to have =ccache= installed

Changed lines 111-112 from:

all ends up in the <tt>tmp</tt> directory. Most interesting is probably the <tt>tmp/work/</tt> directory. Just have a look around the DirectoryStructure?.

to:

all ends up in the tmp directory. Most interesting is probably the tmp/work/ directory. Just have a look around the DirectoryStructure?.

Deleted lines 114-148:

Flashing your PDA

  • Sharp Zaurus SL-5500 and SL-5000d*:
  Once you have finished building an image (e.g. <tt>opie-image</tt>) look for the image file in <tt>deploy/images</tt> under your TMPDIR (on my system this is called <tt>opie-image-collie-20040721193112.rootfs.jffs2</tt>) and copy it to the root directory of a CF card with name <tt>initrd.bin</tt>.%
  Then look for the kernel image under <tt>staging/arm-linux/kernel</tt>, this should just be called <tt>zImage</tt>, copy this to your CF card with name <tt>zImage</tt>.%
  Then hard reset your PDA holding down C+D buttons with the CF card inserted, this will cause the mail and battery lights to illuminate. Once the procedure has finished the mail and batery lights should turn off, at this point hard reset your PDA again and you should be booting into the system you just built (be it opie, gpe, etc.).

<b>Sharp Zaurus C7x0 and SL-5600</b>

 - Get http://openzaurus.org/official/experimental/c700,c750,c760,c860/3.3.6-pre1/updater.sh
    NOTE:It doesn't worked for me (SL-5600). Instead try http://openzaurus.org/official/experimental/poodle/3.3.6-pre1/updater.sh AND rename zimage.bin to zImage (capital letter i).
 - Rename stuff/build/tmp/deploy/images/gpe-image*.rootfs.img (or opie-image*.rootfs.img) to initrd.bin
 - Rename zImage.-embedix to zimage.bin  (Note: mine was here: stuff/build/tmp/work/openzaurus-pxa-2.4.18-rmk7-pxa3-embedix-r6/image/boot/zImage-2.4.18-rmk7-pxa3-embedix)
 - Copy initrd.bin, zimage.bin and updater.sh to your
   FAT-formatted CF or SD
 - Attach Power Cable
 - Reboot while pressing and holding OK on your machine
 - Choose 4 (Update Kernel)
 - Choose CF or SD (USB not tested, no idea)
 - Choose HAI (YES) (Left)

<b>iPAQ</b> :

  The boot loader distributed with familiar should be able to load the image via serial port, using the traditional "load root" command. To install (or upgrade) the boot loader of the familiar project see: http://familiar.handhelds.org/familiar/releases/latest/install/bootldr.html

  Basically, you just have to follow the installation instructions for familiar substituting the root image file with the one generated by OE rather than the one you obtained from familiar. The other method for flashing an image (using a CF card) should work as well. See http://familiar.handhelds.org/familiar/releases/latest/install/ for more information on the two methods.

<b>SIMpad?</b> :

  There are currently two ways to install the generated linux image onto a simpad.

  The first one uses a download via rs232 as described  here: http://opensimpad.org/wiki/index.php/Docs/SerialInstall . This approach may take half an hour and more to install the image, but it doesn't require a complex setup on the desktop pc.

  The second approach described in http://opensimpad.org/wiki/index.php/Docs/NetworkInstall uses a more complex setup and installs the image via a ne2000 compatible network card. This setup is a little more complicated, but is way faster.

<b>MasterIA? PA-100</b> : ... add me ...

October 07, 2004, at 05:00 AM by ka6sox --
Changed lines 1-177 from:

Describe GettingStarted here.

to:

Hardware

Make sure that you have at least 512MB of RAM in machine used for builds. With less memory it will take eons
because current version of "oemake" takes lots of memory during work so swapping can eat you.

This mostly affects the packaging of glibc. To overcome this issue somewhat, if you have less than 512MB of RAM,

 you can use "oebuild" to build glibc instead of "oemake" ("oemake" itself uses a lot of memory, so this makes more
of your RAM available to "oebuild"). To invoke "oebuild", you must specify the location of the package
file and not just the package name. Remember that "oebuild" *does not* trace dependencies so you have to take
care of it by yourself (best method is "oemake glibc" and break when it start glibc unpacking - "oebuild clean" & "oebuild").

Doing a build

(*Always read "oe/doc/*" first as this page may easily become outdated!*)

NB Do not build OE as root, you don't need to and strange things can and will happen. If you need root access for something
to work on your machine, the build environment is set up wrong.


To start using OE, first get the code from BitKeeper. You need both the repositories 'oe' and 'packages'.

If you are unable or unwilling to use BitKeeper, there are snapshots at http://treke.net/oe/snapshots/ . There is also [Anonymous CVS] available.

Make sure you have all the RequiredSoftware installed.

Check out or unpack the sources into a location with no symlinks above it. Let's assume that root directory of your OpenEmbedded enviroment
will be in /stuff/. Recommended structure is:

/stuff/oe/ /stuff/packages/ /stuff/build/ /stuff/sources/

Note: if you are using [Anonymous CVS] then you will get "oe-packages" instead of "packages". Rename it or remember that your enviroment differ a bit from this example.

Create local configuration

<verbatim> cd /stuff/build/ mkdir conf/ cat /stuff/packages/conf/local.conf.sample > conf/local.conf vi conf/local.conf </verbatim>

You'll probably want to add some mirrors to the end of =local.conf= --- see UsingMirrors?


Setup the environment

Check out the GettingStartedEnvironmentScript sample and customize it to your OE installation.

Save it as /stuff/env-dev-arm-oe.source or similar Then source it: <verbatim>

 $ . /stuff/env-dev-arm-oe.source

</verbatim>

Note: Sourcing this file will put you in your configured build directory. ALL oemake commands should be issue from this directory.


Start building

oemake

The primary interface to the build system is the "oemake" command (see the [oemake] page). <code>oemake</code> will download and patch stuff from the network, so it helps if you are on a well connected machine.

Here are some example invocations:

Building a single package (e.g. nano): <verbatim>

 oemake nano

</verbatim>

Building package sets (e.g. task-bootstrap): <verbatim>

 oemake task-bootstrap

</verbatim>

Building a group of packages and deploying them into a rootfs image:

GPE: <verbatim>

 oemake gpe-image

</verbatim>

OPIE: <verbatim> oemake opie-image </verbatim>

Building every package in the repository (Attention! This will take a long time and needs approx. 5 GB disk space): <verbatim>

 oemake world

</verbatim>

<b>Note</b>: at least on my system I needed to have =ccache= installed for the build to (mostly) work. (See also the RequiredSoftware page.)

See [UsefulTargets?] for a description of some of the more useful meta-packages.


Output of the build process (temporary files, log files and the binaries) all ends up in the <tt>tmp</tt> directory. Most interesting is probably the <tt>tmp/work/</tt> directory. Just have a look around the DirectoryStructure?.

Once you have managed to build a package, try to [BuildIPKFiles?].

Flashing your PDA

  • Sharp Zaurus SL-5500 and SL-5000d*:
  Once you have finished building an image (e.g. <tt>opie-image</tt>) look for the image file in <tt>deploy/images</tt> under your TMPDIR (on my system this is called <tt>opie-image-collie-20040721193112.rootfs.jffs2</tt>) and copy it to the root directory of a CF card with name <tt>initrd.bin</tt>.%
  Then look for the kernel image under <tt>staging/arm-linux/kernel</tt>, this should just be called <tt>zImage</tt>, copy this to your CF card with name <tt>zImage</tt>.%
  Then hard reset your PDA holding down C+D buttons with the CF card inserted, this will cause the mail and battery lights to illuminate. Once the procedure has finished the mail and batery lights should turn off, at this point hard reset your PDA again and you should be booting into the system you just built (be it opie, gpe, etc.).

<b>Sharp Zaurus C7x0 and SL-5600</b>

 - Get http://openzaurus.org/official/experimental/c700,c750,c760,c860/3.3.6-pre1/updater.sh
    NOTE:It doesn't worked for me (SL-5600). Instead try http://openzaurus.org/official/experimental/poodle/3.3.6-pre1/updater.sh AND rename zimage.bin to zImage (capital letter i).
 - Rename stuff/build/tmp/deploy/images/gpe-image*.rootfs.img (or opie-image*.rootfs.img) to initrd.bin
 - Rename zImage.-embedix to zimage.bin  (Note: mine was here: stuff/build/tmp/work/openzaurus-pxa-2.4.18-rmk7-pxa3-embedix-r6/image/boot/zImage-2.4.18-rmk7-pxa3-embedix)
 - Copy initrd.bin, zimage.bin and updater.sh to your
   FAT-formatted CF or SD
 - Attach Power Cable
 - Reboot while pressing and holding OK on your machine
 - Choose 4 (Update Kernel)
 - Choose CF or SD (USB not tested, no idea)
 - Choose HAI (YES) (Left)

<b>iPAQ</b> :

  The boot loader distributed with familiar should be able to load the image via serial port, using the traditional "load root" command. To install (or upgrade) the boot loader of the familiar project see: http://familiar.handhelds.org/familiar/releases/latest/install/bootldr.html

  Basically, you just have to follow the installation instructions for familiar substituting the root image file with the one generated by OE rather than the one you obtained from familiar. The other method for flashing an image (using a CF card) should work as well. See http://familiar.handhelds.org/familiar/releases/latest/install/ for more information on the two methods.

<b>SIMpad?</b> :

  There are currently two ways to install the generated linux image onto a simpad.

  The first one uses a download via rs232 as described  here: http://opensimpad.org/wiki/index.php/Docs/SerialInstall . This approach may take half an hour and more to install the image, but it doesn't require a complex setup on the desktop pc.

  The second approach described in http://opensimpad.org/wiki/index.php/Docs/NetworkInstall uses a more complex setup and installs the image via a ne2000 compatible network card. This setup is a little more complicated, but is way faster.

<b>MasterIA? PA-100</b> : ... add me ...

Problems

Try to solve problems first by checking that you have done everything right, that nothing has changed from this description and that you have the latest code (see BitKeeper description). Look also in the log file (referenced in any error message you will receive). If you still have problems, try checking [PossibleFailures?], and if problems persist, ask on [IRC].

Portability issues

Make sure to set TARGET_OS to linux in local.conf if your host isn't linux.

GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils) into your OE development path.

FreeBSD? 4 users: Perl 5.0 is too old. A more recent perl must be available as /usr/bin/perl. Unfortunately just having more recent perl in the path isn't good enough. Some scripts are hard-coded for /usr/bin/perl

FreeBSD? users: Set BUILD_OS in local.conf to freebsdN where N is your major version number. At least the cross gcc wants this.

__Install ccache__ When you rm -rf packages/tmp for the 20th time while trying to get things to work you'll be glad you did.


What's next?

See [OzTODO3?.5.1]

Page last modified on August 21, 2005, at 11:26 AM