From 882f4d2d63272abce8c1966983aa10178e2e971f Mon Sep 17 00:00:00 2001 From: Alberto Bursi Date: Mon, 28 Nov 2016 20:28:12 +0100 Subject: docs: deleting docs because they are obsolete the docs in /docs folder are pretty much obsolete and in a not very friendly format (latex, that requires to be compiled), leaving them there only causes confusion. LEDE documentation's place is the wiki, or the site. Signed-off-by: Alberto Bursi --- docs/build.tex | 594 --------------------------------------------------------- 1 file changed, 594 deletions(-) delete mode 100644 docs/build.tex (limited to 'docs/build.tex') diff --git a/docs/build.tex b/docs/build.tex deleted file mode 100644 index 6e1539a..0000000 --- a/docs/build.tex +++ /dev/null @@ -1,594 +0,0 @@ -One of the biggest challenges to getting started with embedded devices is that you -cannot just install a copy of Linux and expect to be able to compile a firmware. -Even if you did remember to install a compiler and every development tool offered, -you still would not have the basic set of tools needed to produce a firmware image. -The embedded device represents an entirely new hardware platform, which is -most of the time incompatible with the hardware on your development machine, so in a process called -cross compiling you need to produce a new compiler capable of generating code for -your embedded platform, and then use it to compile a basic Linux distribution to -run on your device. - -The process of creating a cross compiler can be tricky, it is not something that is -regularly attempted and so there is a certain amount of mystery and black magic -associated with it. In many cases when you are dealing with embedded devices you will -be provided with a binary copy of a compiler and basic libraries rather than -instructions for creating your own -- it is a time saving step but at the same time -often means you will be using a rather dated set of tools. Likewise, it is also common -to be provided with a patched copy of the Linux kernel from the board or chip vendor, -but this is also dated and it can be difficult to spot exactly what has been -modified to make the kernel run on the embedded platform. - -\subsection{Building an image} - -OpenWrt takes a different approach to building a firmware; downloading, patching -and compiling everything from scratch, including the cross compiler. To put it -in simpler terms, OpenWrt does not contain any executables or even sources, it is an -automated system for downloading the sources, patching them to work with the given -platform and compiling them correctly for that platform. What this means is that -just by changing the template, you can change any step in the process. - -As an example, if a new kernel is released, a simple change to one of the Makefiles -will download the latest kernel, patch it to run on the embedded platform and produce -a new firmware image -- there is no work to be done trying to track down an unmodified -copy of the existing kernel to see what changes had been made, the patches are -already provided and the process ends up almost completely transparent. This does not -just apply to the kernel, but to anything included with OpenWrt -- It is this one -simple understated concept which is what allows OpenWrt to stay on the bleeding edge -with the latest compilers, latest kernels and latest applications. - -So let's take a look at OpenWrt and see how this all works. - - -\subsubsection{Download OpenWrt} - -OpenWrt can be downloaded via subversion using the following command: - -\begin{Verbatim} -$ svn checkout svn://svn.openwrt.org/openwrt/trunk openwrt-trunk -\end{Verbatim} - -Additionally, there is a trac interface on \href{https://dev.openwrt.org/}{https://dev.openwrt.org/} -which can be used to monitor svn commits and browse the source repository. - - -\subsubsection{The directory structure} - -There are four key directories in the base: - -\begin{itemize} - \item \texttt{tools} - \item \texttt{toolchain} - \item \texttt{package} - \item \texttt{target} -\end{itemize} - -\texttt{tools} and \texttt{toolchain} refer to common tools which will be -used to build the firmware image, the compiler, and the C library. -The result of this is three new directories, \texttt{build\_dir/host}, which is a temporary -directory for building the target independent tools, \texttt{build\_dir/toolchain-\textit{}*} -which is used for building the toolchain for a specific architecture, and -\texttt{staging\_dir/toolchain-\textit{}*} where the resulting toolchain is installed. -You will not need to do anything with the toolchain directory unless you intend to -add a new version of one of the components above. - -\begin{itemize} - \item \texttt{build\_dir/host} - \item \texttt{build\_dir/toolchain-\textit{}*} -\end{itemize} - -\texttt{package} is for exactly that -- packages. In an OpenWrt firmware, almost everything -is an \texttt{.ipk}, a software package which can be added to the firmware to provide new -features or removed to save space. Note that packages are also maintained outside of the main -trunk and can be obtained from subversion using the package feeds system: - -\begin{Verbatim} -$ ./scripts/feeds update -\end{Verbatim} - -Those packages can be used to extend the functionality of the build system and need to be -symlinked into the main trunk. Once you do that, the packages will show up in the menu for -configuration. You would do something like this: - -\begin{Verbatim} -$ ./scripts/feeds search nmap -Search results in feed 'packages': -nmap Network exploration and/or security auditing utility - -$ ./scripts/feeds install nmap -\end{Verbatim} - -To include all packages, issue the following command: - -\begin{Verbatim} -$ make package/symlinks -\end{Verbatim} - -\texttt{target} refers to the embedded platform, this contains items which are specific to -a specific embedded platform. Of particular interest here is the "\texttt{target/linux}" -directory which is broken down by platform \textit{} and contains the patches to the -kernel, profile config, for a particular platform. There's also the "\texttt{target/image}" directory -which describes how to package a firmware for a specific platform. - -Both the target and package steps will use the directory "\texttt{build\_dir/\textit{}}" -as a temporary directory for compiling. Additionally, anything downloaded by the toolchain, -target or package steps will be placed in the "\texttt{dl}" directory. - -\begin{itemize} - \item \texttt{build\_dir/\textit{}} - \item \texttt{dl} -\end{itemize} - -\subsubsection{Building OpenWrt} - -While the OpenWrt build environment was intended mostly for developers, it also has to be -simple enough that an inexperienced end user can easily build his or her own customized firmware. - -Running the command "\texttt{make menuconfig}" will bring up OpenWrt's configuration menu -screen, through this menu you can select which platform you're targeting, which versions of -the toolchain you want to use to build and what packages you want to install into the -firmware image. Note that it will also check to make sure you have the basic dependencies for it -to run correctly. If that fails, you will need to install some more tools in your local environment -before you can begin. - -Similar to the linux kernel config, almost every option has three choices, -\texttt{y/m/n} which are represented as follows: - -\begin{itemize} - \item{\texttt{<*>} (pressing y)} \\ - This will be included in the firmware image - \item{\texttt{} (pressing m)} \\ - This will be compiled but not included (for later install) - \item{\texttt{< >} (pressing n)} \\ - This will not be compiled -\end{itemize} - -After you've finished with the menu configuration, exit and when prompted, save your -configuration changes. - -If you want, you can also modify the kernel config for the selected target system. -simply run "\texttt{make kernel\_menuconfig}" and the build system will unpack the kernel sources -(if necessary), run menuconfig inside of the kernel tree, and then copy the kernel config -to \texttt{target/linux/\textit{}/config} so that it is preserved over -"\texttt{make clean}" calls. - -To begin compiling the firmware, type "\texttt{make}". By default -OpenWrt will only display a high level overview of the compile process and not each individual -command. - -\subsubsection{Example:} - -\begin{Verbatim} -make[2] toolchain/install -make[3] -C toolchain install -make[2] target/compile -make[3] -C target compile -make[4] -C target/utils prepare - -[...] -\end{Verbatim} - -This makes it easier to monitor which step it's actually compiling and reduces the amount -of noise caused by the compile output. To see the full output, run the command -"\texttt{make V=99}". - -During the build process, buildroot will download all sources to the "\texttt{dl}" -directory and will start patching and compiling them in the "\texttt{build\_dir/\textit{}}" -directory. When finished, the resulting firmware will be in the "\texttt{bin}" directory -and packages will be in the "\texttt{bin/packages}" directory. - - -\subsection{Creating packages} - -One of the things that we've attempted to do with OpenWrt's template system is make it -incredibly easy to port software to OpenWrt. If you look at a typical package directory -in OpenWrt you'll find several things: - -\begin{itemize} - \item \texttt{package/\textit{}/Makefile} - \item \texttt{package/\textit{}/patches} - \item \texttt{package/\textit{}/files} -\end{itemize} - -The patches directory is optional and typically contains bug fixes or optimizations to -reduce the size of the executable. The package makefile is the important item, provides -the steps actually needed to download and compile the package. - -The files directory is also optional and typicall contains package specific startup scripts or default configuration files that can be used out of the box with OpenWrt. - -Looking at one of the package makefiles, you'd hardly recognize it as a makefile. -Through what can only be described as blatant disregard and abuse of the traditional -make format, the makefile has been transformed into an object oriented template which -simplifies the entire ordeal. - -Here for example, is \texttt{package/bridge/Makefile}: - -\begin{Verbatim}[frame=single,numbers=left] - -include $(TOPDIR)/rules.mk - -PKG_NAME:=bridge -PKG_VERSION:=1.0.6 -PKG_RELEASE:=1 - -PKG_SOURCE:=bridge-utils-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=@SF/bridge -PKG_MD5SUM:=9b7dc52656f5cbec846a7ba3299f73bd -PKG_CAT:=zcat - -PKG_BUILD_DIR:=$(BUILD_DIR)/bridge-utils-$(PKG_VERSION) - -include $(INCLUDE_DIR)/package.mk - -define Package/bridge - SECTION:=net - CATEGORY:=Base system - TITLE:=Ethernet bridging configuration utility - URL:=http://bridge.sourceforge.net/ -endef - -define Package/bridge/description - Manage ethernet bridging: - a way to connect networks together to form a larger network. -endef - -define Build/Configure - $(call Build/Configure/Default, \ - --with-linux-headers="$(LINUX_DIR)" \ - ) -endef - -define Package/bridge/install - $(INSTALL_DIR) $(1)/usr/sbin - $(INSTALL_BIN) $(PKG_BUILD_DIR)/brctl/brctl $(1)/usr/sbin/ -endef - -$(eval $(call BuildPackage,bridge)) -\end{Verbatim} - -As you can see, there's not much work to be done; everything is hidden in other makefiles -and abstracted to the point where you only need to specify a few variables. - -\begin{itemize} - \item \texttt{PKG\_NAME} \\ - The name of the package, as seen via menuconfig and ipkg - \item \texttt{PKG\_VERSION} \\ - The upstream version number that we are downloading - \item \texttt{PKG\_RELEASE} \\ - The version of this package Makefile - \item \texttt{PKG\_SOURCE} \\ - The filename of the original sources - \item \texttt{PKG\_SOURCE\_URL} \\ - Where to download the sources from (no trailing slash), you can add multiple download sources by separating them with a \\ and a carriage return. - \item \texttt{PKG\_MD5SUM} \\ - A checksum to validate the download - \item \texttt{PKG\_CAT} \\ - How to decompress the sources (zcat, bzcat, unzip) - \item \texttt{PKG\_BUILD\_DIR} \\ - Where to compile the package -\end{itemize} - -The \texttt{PKG\_*} variables define where to download the package from; -\texttt{@SF} is a special keyword for downloading packages from sourceforge. There is also -another keyword of \texttt{@GNU} for grabbing GNU source releases. If any of the above mentionned download source fails, the OpenWrt mirrors will be used as source. - -The md5sum (if present) is used to verify the package was downloaded correctly and -\texttt{PKG\_BUILD\_DIR} defines where to find the package after the sources are -uncompressed into \texttt{\$(BUILD\_DIR)}. - -At the bottom of the file is where the real magic happens, "BuildPackage" is a macro -set up by the earlier include statements. BuildPackage only takes one argument directly -- -the name of the package to be built, in this case "\texttt{bridge}". All other information -is taken from the define blocks. This is a way of providing a level of verbosity, it's -inherently clear what the contents of the \texttt{description} template in -\texttt{Package/bridge} is, which wouldn't be the case if we passed this information -directly as the Nth argument to \texttt{BuildPackage}. - -\texttt{BuildPackage} uses the following defines: - -\textbf{\texttt{Package/\textit{}}:} \\ - \texttt{\textit{}} matches the argument passed to buildroot, this describes - the package the menuconfig and ipkg entries. Within \texttt{Package/\textit{}} - you can define the following variables: - - \begin{itemize} - \item \texttt{SECTION} \\ - The section of package (currently unused) - \item \texttt{CATEGORY} \\ - Which menu it appears in menuconfig: Network, Sound, Utilities, Multimedia ... - \item \texttt{TITLE} \\ - A short description of the package - \item \texttt{URL} \\ - Where to find the original software - \item \texttt{MAINTAINER} (optional) \\ - Who to contact concerning the package - \item \texttt{DEPENDS} (optional) \\ - Which packages must be built/installed before this package. To reference a dependency defined in the - same Makefile, use \textit{}. If defined as an external package, use - \textit{+}. For a kernel version dependency use: \textit{@LINUX\_2\_} - \item \texttt{BUILDONLY} (optional) \\ - Set this option to 1 if you do NOT want your package to appear in menuconfig. - This is useful for packages which are only used as build dependencies. - \end{itemize} - -\textbf{\texttt{Package/\textit{}/conffiles} (optional):} \\ - A list of config files installed by this package, one file per line. - -\textbf{\texttt{Build/Prepare} (optional):} \\ - A set of commands to unpack and patch the sources. You may safely leave this - undefined. - -\textbf{\texttt{Build/Configure} (optional):} \\ - You can leave this undefined if the source doesn't use configure or has a - normal config script, otherwise you can put your own commands here or use - "\texttt{\$(call Build/Configure/Default,\textit{})}" as above to - pass in additional arguments for a standard configure script. The first list of arguments will be passed - to the configure script like that: \texttt{--arg 1} \texttt{--arg 2}. The second list contains arguments that should be - defined before running the configure script such as autoconf or compiler specific variables. - - To make it easier to modify the configure command line, you can either extend or completely override the following variables: - \begin{itemize} - \item \texttt{CONFIGURE\_ARGS} \\ - Contains all command line arguments (format: \texttt{--arg 1} \texttt{--arg 2}) - \item \texttt{CONFIGURE\_VARS} \\ - Contains all environment variables that are passed to ./configure (format: \texttt{NAME="value"}) - \end{itemize} - -\textbf{\texttt{Build/Compile} (optional):} \\ - How to compile the source; in most cases you should leave this undefined. - - As with \texttt{Build/Configure} there are two variables that allow you to override - the make command line environment variables and flags: - \begin{itemize} - \item \texttt{MAKE\_FLAGS} \\ - Contains all command line arguments (typically variable overrides like \texttt{NAME="value"} - \item \texttt{MAKE\_VARS} \\ - Contains all environment variables that are passed to the make command - \end{itemize} - -\textbf{\texttt{Build/InstallDev} (optional):} \\ - If your package provides a library that needs to be made available to other packages, - you can use the \texttt{Build/InstallDev} template to copy it into the staging directory - which is used to collect all files that other packages might depend on at build time. - When it is called by the build system, two parameters are passed to it. \texttt{\$(1)} points to - the regular staging dir, typically \texttt{staging\_dir/\textit{ARCH}}, while \texttt{\$(2)} points - to \texttt{staging\_dir/host}. The host staging dir is only used for binaries, which are - to be executed or linked against on the host and its \texttt{bin/} subdirectory is included - in the \texttt{PATH} which is passed down to the build system processes. - Please use \texttt{\$(1)} and \texttt{\$(2)} here instead of the build system variables - \texttt{\$(STAGING\_DIR)} and \texttt{\$(STAGING\_DIR\_HOST)}, because the build system behavior - when staging libraries might change in the future to include automatic uninstallation. - -\textbf{\texttt{Package/\textit{}/install}:} \\ - A set of commands to copy files out of the compiled source and into the ipkg - which is represented by the \texttt{\$(1)} directory. Note that there are currently - 4 defined install macros: - \begin{itemize} - \item \texttt{INSTALL\_DIR} \\ - install -d -m0755 - \item \texttt{INSTALL\_BIN} \\ - install -m0755 - \item \texttt{INSTALL\_DATA} \\ - install -m0644 - \item \texttt{INSTALL\_CONF} \\ - install -m0600 - \end{itemize} - -The reason that some of the defines are prefixed by "\texttt{Package/\textit{}}" -and others are simply "\texttt{Build}" is because of the possibility of generating -multiple packages from a single source. OpenWrt works under the assumption of one -source per package Makefile, but you can split that source into as many packages as -desired. Since you only need to compile the sources once, there's one global set of -"\texttt{Build}" defines, but you can add as many "Package/" defines as you want -by adding extra calls to \texttt{BuildPackage} -- see the dropbear package for an example. - -After you have created your \texttt{package/\textit{}/Makefile}, the new package -will automatically show in the menu the next time you run "make menuconfig" and if selected -will be built automatically the next time "\texttt{make}" is run. - -\subsection{Creating binary packages} - -You might want to create binary packages and include them in the resulting images as packages. -To do so, you can use the following template, which basically sets to nothing the Configure and -Compile templates. - -\begin{Verbatim}[frame=single,numbers=left] - -include $(TOPDIR)/rules.mk - -PKG_NAME:=binpkg -PKG_VERSION:=1.0 -PKG_RELEASE:=1 - -PKG_SOURCE:=binpkg-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=http://server -PKG_MD5SUM:=9b7dc52656f5cbec846a7ba3299f73bd -PKG_CAT:=zcat - -include $(INCLUDE_DIR)/package.mk - -define Package/binpkg - SECTION:=net - CATEGORY:=Network - TITLE:=Binary package -endef - -define Package/bridge/description - Binary package -endef - -define Build/Configure -endef - -define Build/Compile -endef - -define Package/bridge/install - $(INSTALL_DIR) $(1)/usr/sbin - $(INSTALL_BIN) $(PKG_BUILD_DIR)/* $(1)/usr/sbin/ -endef - -$(eval $(call BuildPackage,bridge)) -\end{Verbatim} - -Provided that the tarball which contains the binaries reflects the final -directory layout (/usr, /lib ...), it becomes very easy to get your package -look like one build from sources. - -Note that using the same technique, you can easily create binary pcakages -for your proprietary kernel modules as well. - -\subsection{Creating kernel modules packages} - -The OpenWrt distribution makes the distinction between two kind of kernel modules, those coming along with the mainline kernel, and the others available as a separate project. We will see later that a common template is used for both of them. - -For kernel modules that are part of the mainline kernel source, the makefiles are located in \textit{package/kernel/modules/*.mk} and they appear under the section "Kernel modules" - -For external kernel modules, you can add them to the build system just like if they were software packages by defining a KernelPackage section in the package makefile. - -Here for instance the Makefile for the I2C subsytem kernel modules : - -\begin{Verbatim}[frame=single,numbers=left] - -I2CMENU:=I2C Bus - -define KernelPackage/i2c-core - TITLE:=I2C support - DESCRIPTION:=Kernel modules for i2c support - SUBMENU:=$(I2CMENU) - KCONFIG:=CONFIG_I2C_CORE CONFIG_I2C_DEV - FILES:=$(MODULES_DIR)/kernel/drivers/i2c/*.$(LINUX_KMOD_SUFFIX) - AUTOLOAD:=$(call AutoLoad,50,i2c-core i2c-dev) -endef -$(eval $(call KernelPackage,i2c-core)) -\end{Verbatim} - -To group kernel modules under a common description in menuconfig, you might want to define a \textit{MENU} variable on top of the kernel modules makefile. - -\begin{itemize} - \item \texttt{TITLE} \\ - The name of the module as seen via menuconfig - \item \texttt{DESCRIPTION} \\ - The description as seen via help in menuconfig - \item \texttt{SUBMENU} \\ - The sub menu under which this package will be seen - \item \texttt{KCONFIG} \\ - Kernel configuration option dependency. For external modules, remove it. - \item \texttt{FILES} \\ - Files you want to inlude to this kernel module package, separate with spaces. - \item \texttt{AUTOLOAD} \\ - Modules that will be loaded automatically on boot, the order you write them is the order they would be loaded. -\end{itemize} - -After you have created your \texttt{package/kernel/modules/\textit{}.mk}, the new kernel modules package -will automatically show in the menu under "Kernel modules" next time you run "make menuconfig" and if selected -will be built automatically the next time "\texttt{make}" is run. - -\subsection{Conventions} - -There are a couple conventions to follow regarding packages: - -\begin{itemize} - \item \texttt{files} - \begin{enumerate} - \item configuration files follow the convention \\ - \texttt{\textit{}.conf} - \item init files follow the convention \\ - \texttt{\textit{}.init} - \end{enumerate} - \item \texttt{patches} - \begin{enumerate} - \item patches are numerically prefixed and named related to what they do - \end{enumerate} -\end{itemize} - -\subsection{Troubleshooting} - -If you find your package doesn't show up in menuconfig, try the following command to -see if you get the correct description: - -\begin{Verbatim} - TOPDIR=$PWD make -C package/ DUMP=1 V=99 -\end{Verbatim} - -If you're just having trouble getting your package to compile, there's a few -shortcuts you can take. Instead of waiting for make to get to your package, you can -run one of the following: - -\begin{itemize} - \item \texttt{make package/\textit{}/clean V=99} - \item \texttt{make package/\textit{}/install V=99} -\end{itemize} - -Another nice trick is that if the source directory under \texttt{build\_dir/\textit{}} -is newer than the package directory, it won't clobber it by unpacking the sources again. -If you were working on a patch you could simply edit the sources under the -\texttt{build\_dir/\textit{}/\textit{}} directory and run the install command above, -when satisfied, copy the patched sources elsewhere and diff them with the unpatched -sources. A warning though - if you go modify anything under \texttt{package/\textit{}} -it will remove the old sources and unpack a fresh copy. - -Other useful targets include: - -\begin{itemize} - \item \texttt{make package/\textit{}/prepare V=99} - \item \texttt{make package/\textit{}/compile V=99} - \item \texttt{make package/\textit{}/configure V=99} -\end{itemize} - - -\subsection{Using build environments} -OpenWrt provides a means of building images for multiple configurations -which can use multiple targets in one single checkout. These \emph{environments} -store a copy of the .config file generated by \texttt{make menuconfig} and the contents -of the \texttt{./files} folder. -The script \texttt{./scripts/env} is used to manage these environments, it uses -\texttt{git} (which needs to be installed on your system) as backend for version control. - -The command -\begin{Verbatim} - ./scripts/env help -\end{Verbatim} -produces a short help text with a list of commands. - -To create a new environment named \texttt{current}, run the following command -\begin{Verbatim} - ./scripts/env new current -\end{Verbatim} -This will move your \texttt{.config} file and \texttt{./files} (if it exists) to -the \texttt{env/} subdirectory and create symlinks in the base folder. - -After running make menuconfig or changing things in files/, your current state will -differ from what has been saved before. To show these changes, use: -\begin{Verbatim} - ./scripts/env diff -\end{Verbatim} - -If you want to save these changes, run: -\begin{Verbatim} - ./scripts/env save -\end{Verbatim} -If you want to revert your changes to the previously saved copy, run: -\begin{Verbatim} - ./scripts/env revert -\end{Verbatim} - -If you want, you can now create a second environment using the \texttt{new} command. -It will ask you whether you want to make it a clone of the current environment (e.g. -for minor changes) or if you want to start with a clean version (e.g. for selecting -a new target). - -To switch to a different environment (e.g. \texttt{test1}), use: -\begin{Verbatim} - ./scripts/env switch test1 -\end{Verbatim} - -To rename the current branch to a new name (e.g. \texttt{test2}), use: -\begin{Verbatim} - ./scripts/env rename test2 -\end{Verbatim} - -If you want to get rid of environment switching and keep everything in the base directory -again, use: -\begin{Verbatim} - ./scripts/env clear -\end{Verbatim} -- cgit v1.1