OpenWrt Buildroot – Uso

1. Haga todo como usuario normal (Como Root NO!)
2. Realize todos los comandos en el directorio <buildroot dir>, por ejemplo ~/openwrt/trunk/
  1. Actualize las fuentes de OpenWrt.
  2. Actualize e instale los paquetes feeds.
  3. Configure la construcción.
  4. Comienze la construcción. Automaticamente esto compilará el toolchain, realizará una compilacion-cruzada sobre las fuentes, empaquetará los paquetes, y finalmente generará una imagen lista para ser flasheada.
  5. Proceder a la instación de OpenWrt

Actualizar fuentes:

svn update

El código fuente de OpenWrt cambia frecuentemente. se recomienda trabajes con las ultimas fuentes.

  1. Actualizar feeds:
    ./scripts/feeds update -a
  2. Instalar los paquetes descargados:

Note que instalando en el contexto de los scripts ./scripts/feeds significa “haciendo los paquetes disponibles en make menuconfig” mas que realmente instalarlos o compilarlos.

  • Para instalar un solo paquete:
    ./scripts/feeds install <PACKAGENAME>
  • Alternativamente, instalar todos los paquetes:
    ./scripts/feeds install -a

Inicie la interfaz de configuraciónbasada en texto(ncurses) del Buildroot de OpenWrt:

make menuconfig

Similar a la configuración del kernel de Linux, casi todas las opciones tienen tres opciones, y, m, n las cuales representan como sigue:

  • presionando y yields to <*> label
    This package will be included in the firmware image
  • pressing m yields to <M> label
    This package will be compiled (to be installed with opkg after Flashing OpenWrt) but the package will not be included in the firmware-image
  • pressing n yields to < > label
    This package will not be compiled.

When you save your configuration, the file ~/openwrt/trunk/.config will be created according to your configuration.

The devs offer such a file for OpenWrt 'Backfire' 10.03.1-RC5, e.g. for ar71xx.

  • The menu above allows you to select the target platform, which version of toolchain you want to use to build and what packages you want included in the firmware image.
  • Run this configuration interface after updating sources and feeds to ensure that the latest packages are included in your configuration.

select your target before issuing defconfig

make defconfig

will produce a general purpose configuration of the build system including a check of dependencies and prerequisites for the build environment etc

will check for dependencies. Install missing and run again.

Menuconfig has a TUI, which handles the selection of the target, packages to be compiled, packages to be included in the firmware file, some kernel options etc.

make menuconfig

This will update the dependencies of your existing configuration automatically and you can now proceed to build your updated images.

It has from the beginning on been the intention, with the development of 'menuconfig', to create a simple yet powerful environment for the configuration of individual OpenWrt images. Menuconfig is more or less self-explanatory, and even the most specialized configuration needs can be solved with its help. Depending on the the particular target platform, package requirements and kernel module needs, the standard process of configuration will include modifying:

  1. Target system
  2. Package selection
  3. Build system settings
  4. Kernel modules

Target system is selected from the extensive list of supported platforms, with the numerous target profiles – ranging from specific devices to generic profiles, all depending on the particular device at hand. Package selection has the option of either 'selecting all package', which might be un-practical in certain situation, or relying on the default set of packages will be adequate or make an individual selection. It is here needed to mention that some package combinations might break the build process, so it can take some experimentation before the expected result is reached. Added to this, the OpenWrt developers are themselves only maintaining a smaller set of packages – which includes all default packages – but, the feeds-script makes it very simple to handle a locally maintained set of packages and integrate them in the build-process.

You have three option at most:

  • < > the source code will not be processed
  • <M> the source code of the package will be crosscompiled into binaries and a opkg package will be built and placed in /buildsystem/bla/bla/bla, but the ImageGenerator will not put it onto the Firmware-Image!
  • <*> that the package will built into the firmware (on the SqashFS partition)

The final step before the process of compiling the intended image(s) is to exit 'menuconfig' – this also includes the option to save a specific configuration or load an already existing, and pre-configured, version.

Exit the TUI, and choose to save your settings.

Kernel configuration

While you won't typically need to do this, you can do it:

make kernel_menuconfig

Note that make kernel_menuconfig modifies the Kernel configuration templates of the build tree, clearing the build_dir will not revert them. The changes can be reviewed with svn diff target/linux/ and reverted with svn revert -R target/linux/.

See: Customizing the kernel options

Source Mirrors

The 'Build system settings' include some efficient options for changing package locations which makes it easy to handle a local package set:

  1. Local mirror for source packages
  2. Download folder

In the case of the first option, you simply enter a full URL to the web or ftp server on which the package sources are hosted. Download folder would in the same way be the path to a local folder on the build system (or network). If you have a web/ftp-server hosting the tarballs, the OpenWrt build system will try this one before trying to download from the location(s) mentioned in the Makefiles . Similar if a local 'download folder', residing on the build system, has been specified.

The 'Kernel modules' option is required if you need specific (non-standard) drivers and so forth – this would typically be things like modules for USB or particular network interface drivers etc.

In many cases, you may want to have a custom image that has been pre-configured. If so, place your custom files in

<buildroot dir>/files/

For example, let's say that you want an image with a pre-configured /etc/config/firewall, then place your modified firewall config in here:

<buildroot dir>/files/etc/config/

E.g. if your <buildroot dir> is /openwrt/trunk and you want some files to be copied into firmware image's /etc/config directory, the correct place to put them is /openwrt/trunk/files/etc/config.

Everything is now ready for building the image(s), which is done with one single command:

make

This simple command will trigger a cascade of activity. As already stated, it will

  1. compile the toolchain
  2. then crosscompile the sources with this toolchain
  3. create opkg-packages
  4. create a firmware image file ready to be flashed.

Building on multi-core CPU

The build process can be accelerated by running multiple concurrent job processes using the -j-option:

make -j 3
  • Use the standard formula <your number of CPUs + 1>
  • If this produces random build errors try compiling again without the -j-option

Building in the background

If you intend to use your system while building, you can have the build process use only idle I/O and CPU capacity like this (dualcore CPU):

ionice -c 3 nice -n 20 make -j 2

Building single Packages

When developing or packaging software for OpenWrt, it is convenient to be able to build only the package in question (e.g. with package cups):

make package/cups/compile V=s

For the package mc (midnight commander), which is contained the feed packages it looks like this:

make package/feeds/packages/mc/compile V=s

Note that the path start in package directory and package/feeds may not have exactly the same structure as feeds. For example package in ~/openwrt/trunk/feeds/packages/net/snort will be compiled using make ~/openwrt/trunk/package/feeds/packages/snort/compile V=s.

Spotting build errors

If for some reason the build fails, the easiest way to spot the error is to do:

make V=s 2>&1 | tee build.log | grep -i error

The above saves a full verbose copy of the build output (with stdout piped to stderr) in /openwrt/trunk/build.log and only shows errors on the screen.

Another example:

ionice -c 3 nice -n 20 make -j 2 V=s CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 | tee build.log | egrep -i '(warn|error)'

The above saves a full verbose copy of the build output (with stdout piped to stderr) in build.log and outputs only warnings and errors while building using only background resources on a dual core CPU.

Getting beep notification

Depending on your CPU, the process will take a while, or while longer. If you want an acoustic notification, you could use echo -e '\a':

make V=s ; echo -e '\a'

After a successful build, the freshly built image(s) can be found in the newly created <buildroot dir>/bin directory. The compiled files are additionally classfied by the target platform, so e.g. a firmware built for an ar71xx device will be located in <buildroot dir>/bin/ar71xx directory.

E.g. if your <buildroot dir> is /openwrt/trunk, the binaries are in /openwrt/trunk/bin/ar71xx.

You might need to clean your build environment every now and then. The following make-targets are useful for that job:

make clean

deletes contents of bin and build_dir directories.

make dirclean

deletes contents of /bin and /build_dir directories and additionally /staging_dir and /toolchain (=the cross-compile tools). 'Dirclean' is your basic “Full clean” operation.

make distclean

nukes everything you have compiled or configured and also deletes all downloaded feeds contents and package sources.

CAUTION: In addition to all else, this will erase your build configuration (.config), your toolchain and all other sources. Use with care!

There are numerous other functionalities in the OpenWrt build system, but the above should have covered some of the fundamentals.

First get more information on the problem using the make option “make V=s”.

First check if the URL path in the make file contains a trailing slash, then try with it removed (helped several times). Otherwise try to download the source code manually and put it into “dl” directory

Try to update the main source and all the feeds (Warning! May result in other problems). Check for a related bug in (TRAC), use the filters to find it. Otherwise report the problem there, by mentioning the package, the target data (CPU, image, etc.) and the code revisions (main & package). Compiling with make -j ... sometimes gives random errors. Try compiling without -j first before reporting the problem.

  • GREP_OPTIONS should not have --initial-tab or other options affecting its output
  • SED should not be set. If it is, run `unset SED` before compiling. (See Ticket 10612.)
  1. Have you run this command? See this.
    ./scripts/feeds install <package>
  2. Maybe you are not looking for it in the right submenu. See Makefile of the package to find out.
    cat package/feeds/packages/<package>/Makefile

You are looking for this:

define Package/<package>/Default SUBMENU:=Firewall SECTION:=net CATEGORY:=Network

Make sure the path starts with package directory and that the path actually exist. The structure of feeds and package/feeds directory is different. See this.

  • Wrong: make feeds/packages/utils/screen/compile V=s
  • Correct: make package/feeds/packages/screen/compile V=s

Run make menuconfig and enable compilation for your package. It should be labeled with <*> or <M> to work correctly. See this.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2021/10/15 09:06
  • by bobafetthotmail