hak5
/
openwrt-owl
mirror of https://github.com/hak5/openwrt-owl.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add some more documentation : how to add a new target to OpenWrt, howto report bugs, change the svn:ignore property on the docs/ repository 

SVN-Revision: 5981
owl
Florian Fainelli 2007-01-05 15:26:38 +00:00
parent 75894edf2f
commit 600dace307
5 changed files with 412 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/Makefile
View File

@ -1,4 +1,4 @@
openwrt.pdf: Makefile openwrt.tex config.tex network.tex network-scripts.tex network-scripts.tex wireless.tex build.tex
openwrt.pdf: Makefile openwrt.tex config.tex network.tex network-scripts.tex network-scripts.tex wireless.tex build.tex adding.tex bugs.tex
$(MAKE) cleanup
pdflatex openwrt.tex
pdflatex openwrt.tex

324
docs/adding.tex Normal file
View File

@ -0,0 +1,324 @@
Linux is now one of the most widespread operating system for embedded devices due to its openess as well as the wide variety of platforms it can run on. Many manufacturer actually use it in firmware you can find on many devices : DVB-T decoders, routers, print servers, DVD players ... Most of the time the stock firmware is not really open to the consumer, even if it uses open source software.
You might be interested in running a Linux based firmware for your router for various reasons : extending the use of a network protocol (such as IPv6), having new features, new piece of software inside, or for security reasons. A fully open-source firmware is de-facto needed for such applications, since you want to be free to use this or that version of a particular reason, be able to correct a particular bug. Few manufacturers do ship their routers with a Sample Developpment Kit, that would allow you to create your own and custom firmware and most of the time, when they do, you will most likely not be able to complete the firmware creation process.
This is one of the reasons why OpenWrt and other firmware exists : providing a version independent, and tools independent firmware, that can be run on various platforms, known to be running Linux originaly.
\subsection{Which Operating System does this device run ?}
There is a lot of methods to ensure your device is running Linux. Some of them do need your router to be unscrewed and open, some can be done by probing the device using its external network interfaces.
\subsubsection{Operating System fingerprinting and port scanning}
A large bunch of tools over the Internet exists in order to let you do OS fingerprinting, we will show here an example using \textbf{nmap} :
\begin{Verbatim}
nmap -P0 -O <IP address>
Not shown: 1694 closed ports
PORT STATE SERVICE
631/tcp open ipp
1033/tcp open netinfo
6000/tcp open X11
Device type: general purpose
Running: Apple Mac OS X 10.4.X
OS details: Apple Mac OS X 10.4.8 (Tiger)
\end{Verbatim}
nmap is able to report whether your device uses a Linux TCP/IP stack, and if so, will show you which Linux kernel version is probably runs. This report is quite reliable and it can make the distinction between BSD and Linux TCP/IP stacks and others.
Using the same tool, you can also do port scanning and service version discovery. For instance, the following command will report which IP-based services are running on the device, and which version of the service is being used :
\begin{verbatim}
nmap -P0 -sV <IP address>
\end{verbatim}
The web server version, if identified, can be determining in knowing the Operating System. For instance, the \textbf{BOA} web server is typical from devices running an open-source Unix or Unix-like.
\subsubsection{Wireless Communications Fingerprinting}
Although this method is not really known and widespread, using a wireless scanner to discover which OS your router or Access Point run can be used. We do not have a clear example of how this could be achieved, but you will have to monitor raw 802.11 frames and compare them to a very similar device running a Linux based firmware.
\subsubsection{Web server security exploits}
The Linksys WRT54G was originally hacked by using a "ping bug" discoverd in the web interface. This tip has not been fixed for months by Linksys, allowing people to enable the "boot\_wait" helper process via the web interface. Many web servers used in firmwares are open source web server, thus allowing the code to be audited to find an exploit. Once you know the web server version that runs on your device, by using \textbf{nmap -sV} or so, you might be interested in using exploits to reach shell access on your device.
\subsubsection{Native Telnet/SSH access}
Some firmwares might have restricted or unrestricted Telnet/SSH access, if so, try to log in with the web interface login/password and see if you can type in some commands. This is actually the case for some Broadcom BCM963xx based firmwares such as the one in Neuf/Cegetel ISP routers, Club-Internet ISP CI-Box and many others. Some commands, like \textbf{cat} might be left here and be used to determine the Linux kernel version.
\subsubsection{Analysing a binary firmware image}
You are very likely to find a firmware binary image on the manufacturer website, even if your device runs a proprietary operating system. If so, you can download it and use an hexadecimal editor to find printable words such as \textbf{vmlinux}, \textbf{linux}, \textbf{ramdisk}, \textbf{mtd} and others.
Some Unix tools like \textbf{hexdump} or \textbf{strings} can be used to analyse the firmware. Below there is an example with a binary firmware found other the Internet :
\begin{verbatim}
hexdump -C <binary image.extension> | less (more)
00000000 46 49 52 45 32 2e 35 2e 30 00 00 00 00 00 00 00 |FIRE2.5.0.......|
00000010 00 00 00 00 31 2e 30 2e 30 00 00 00 00 00 00 00 |....1.0.0.......|
00000020 00 00 00 00 00 00 00 38 00 43 36 29 00 0a e6 dc |.......8.C6)..??|
00000030 54 49 44 45 92 89 54 66 1f 8b 08 08 f8 10 68 42 |TIDE..Tf....?.hB|
00000040 02 03 72 61 6d 64 69 73 6b 00 ec 7d 09 bc d5 d3 |..ramdisk.?}.???|
00000050 da ff f3 9b f7 39 7b ef 73 f6 19 3b 53 67 ea 44 |???.?9{?s?.;Sg?D|
\end{verbatim}
Scroll over the firmware to find printable words that can be significant.
\subsubsection{Amount of flash memory}
Linux can hardly fit in a 2MB flash device, once you have open the device and located the flash chip, try to find other the Internet its characteristics. If your flash chip is a 2MB or less device, your device is most likely to run a proprietary OS such as Windriver VxWorks, or a custom manufacturer OS like Zyxel ZynOS.
OpenWrt does not currently run on devices which have equal or less than 2MB of flash memory. This limitation will probably not be worked around since those devices are most of the time micro routers, or Wireless Access Points, which are not the main OpenWrt target.
\subsubsection{Pluging a serial port}
By using a serial port, you may reach the console that is being shown by the device for debugging or flashing purposes. By analysing the output of this device, you can easily notice if the device uses a Linux kenrel or something different.
\subsection{Finding and using the manufacturer SDK}
Once you are sure your device run a Linux based firmware, you will be able to start hacking on it. If the manufacturer respect the GPL, it will have release with the device, a Sample Developpment Kit.
\subsubsection{GPL violations}
Some manufacturers do release a Linux based binary firmware, with no sources at all. The first step before doing anything is to read the license coming with your device, then write them about this lack of Open Source code. If the manufacturer answers you they do not have to release a SDK containing Open Source software, then we recommend you get in touch with the gpl-violations.org community.
You will find below a sample letter that can be sent to the manufacturer :
\begin{verse}
Miss, Mister,
I am using a <device name>, and I cannot find neither on your website nor on the CD-ROM the open source software used to build or modify the firmware.
In conformance to the GPL license, you have to release the following sources :
- complete toolchain that made the kernel and applications be compiled (gcc, binutils, libc)
- tools to build a custom firmware (mksquashfs, mkcramfs ...)
- kernel sources with patches to make it run on this specific hardware, this does not include binary drivers
Thank you very much in advance for your answer.
Best regards, <your namne>
\end{verse}
\subsubsection{Using the SDK}
Once the SDK is available, you are most likely not to be able to build a complete or functionnal firmware using it, but parts of it, like only the kernel, or only the root filesystem. Most manufacturers do not really care releasing a tool that do work every time you uncompress and use it.
You should anyway be able to use the following components :
\begin{itemize}
\item kernel sources with more or less functionnal patches for your hardware
\item binary drivers linked or to be linked with the shipped kernel version
\item packages of the toolchain used to compile the whole firmware : gcc, binutils, libc or uClibc
\item binary tools to create a valid firmware image
\end{itemize}
Your work is now divided into the following tasks :
\begin{itemize}
\item create a clean patch of the hardware specific part of the linux kernel
\item spot potential kernel GPL violations especially on firewall and USB stack stuff
\item make the binary drivers work, until there are open source drivers
\item use standard a GNU toolchain to make working executables
\item understand and write open source tools to generate a valid firmware image
\end{itemize}
\subsubsection{Creating a hardware specific kernel patch}
Most of the time, the kernel source that comes along with the SDK is not really clean, and is not a standard Linux version, it also has architecture specific fixes backported from the \textbf{CVS} or the \textbf{git} repository of the kernel developpment trees. Anyway, some parts can be easily isolated and used as a good start to make a vanilla kernel work your hardware.
Some directories are very likely to have local modifications needed to make your hardware be recognized and used under Linux. First of all, you need to find out the linux kernel version that is used by your hardware, this can be found by editing the \textbf{linux/Makefile} file.
\begin{verbatim}
head -5 linux-2.x.x/Makefile
VERSION = 2
PATCHLEVEL = x
SUBLEVEL = y
EXTRAVERSION = z
NAME=Avast! A bilge rat!
\end{verbatim}
So now, you know that you have to download a standard kernel tarball at \textbf{kernel.org} that matches the version being used by your hardware.
Then you can create a \textbf{diff} file between the two trees, especially for the following directories :
\begin{verbatim}
diff -urN linux-2.x.x/arch/<sub architecture> linux-2.x.x-modified/arch/<sub architecture> > 01-architecture.patch
diff -urN linux-2.x.x/include/ linux-2.x.x-modified/include > 02-includes.patch
diff -urN linux-2.x.x/drivers/ linux-2.x.x-modified/drivers > 03-drivers.patch
\end{verbatim}
This will constitute a basic set of three patches that are very likely to contain any needed modifications that has been made to the stock Linux kernel to run on your specific device. Of course, the content produced by the \textbf{diff -urN} may not always be relevant, so that you have to clean up those patches to only let the "must have" code into them.
The fist patch will contain all the code that is needed by the board to be initialized at startup, as well as processor detection and other boot time specific fixes.
The second patch will contain all useful definitions for that board : adresses, kernel granularity, redifinitions, processor family and features ...
The third patch may contain drivers for : serial console, ethernet NIC, wireless NIC, USB NIC ... Most of the time this patch contains nothing else than "glue" code that has been added to make the binary driver work with the Linux kernel. This code might not be useful if you plan on writing from scratch drivers for this hardware.
\subsubsection{Making binary drivers work}
As we have explained before, manufacturers do release binary drivers in their GPL tarball. When those drivers are statically linked into the kernel, they become GPL as well, fortunately or unfortunately, most of the drivers are not statically linked. This anyway lets you a chance to dynamically link the driver with the current kernel version, and try to make them work together.
This is one of the most tricky and grey part of the fully open source projects. Some drivers require few modifications to be working with your custom kernel, because they worked with an earlier kernel, and few modifications have been made to the kernel in-between those versions. This is for instance the case with the binary driver of the Broadcom BCM43xx Wireless Chipsets, where only few differences were made to the network interface structures.
Some general principles can be applied no matter which kernel version is used in order to make binary drivers work with your custom kernel :
\begin{itemize}
\item turn on kernel debugging features such as :
\begin{itemize}
\item CONFIG\_DEBUG\_KERNEL
\item CONFIG\_DETECT\_SOFTLOCKUP
\item CONFIG\_DEBUG\_KOBJECT
\item CONFIG\_EMBEDDED
\item CONFIG\_KALLSYMS
\item CONFIG\_KALLSYMS\_ALL
\end{itemize}
\item link binary drivers when possible to the current kernel version
\item try to load those binary drivers
\item catch the lockups and understand them
\end{itemize}
Most of the time, loading binary drivers will fail, and generate a kernel oops. You can know the last symbol the binary drivers attempted to use, and see in the kernel headers file, if you do not have to move some structures field before or after that symbol in order to keep compatibily with both the binary driver and the stock kernel drivers.
\subsubsection{Understanding the firmware format}
You might want to understand the firmware format, even if you are not yet capable of running a custom firmware on your device, because this is sometimes a blocking part of the flashing process.
A firmare format is most of the time composed of the following fields :
\begin{itemize}
\item header, containing a firmare version and additionnal fields : Vendor, Hardware version ...
\item CRC32 checksum on either the whole file or just part of it
\item Binary or compressed kernel image
\item Binary or compressed root filesystem image
\item potential garbage
\end{itemize}
Once you have figured out how the firmware format is partitionned, you will have to write your own tool that produces valid firmare binaries. One thing to be very careful here is the endianness of either the machine that produces the binary firmware and the device that will be flashed using this binary firmware.
\subsubsection{Writing a flash map driver}
The flash map driver has an important role in making your custom firmware work because it is responsible of mapping the correct flash regions and associated rights to specific parts of the system such as : bootloader, kernel, user filesystem.
Writing your own flash map driver is not really a hard task once you know how your firmware image and flash is structured. You will find below a commented example that covers the case of the device where the bootloader can pass to the kernel its partition plan.
First of all, you need to make your flash map driver be visible in the kernel configuration options, this can be done by editing the file \textbf{linux/drivers/mtd/maps/Kconfig} :
\begin{verbatim}
config MTD_DEVICE_FLASH
tristate "Device Flash device"
depends on ARCHITECTURE && DEVICE
help
Flash memory access on DEVICE boards. Currently only works with
Bootloader Foo and Bootloader Bar.
\end{verbatim}
Then add your source file to the \textbf{linux/drivers/mtd/maps/Makefile}, so that it will be compiled along with the kernel.
\begin{verbatim}
obj-\$(CONFIG_MTD_DEVICE_FLASH) += device-flash.o
\end{verbatim}
You can then write the kernel driver itself, by creating a \textbf{linux/drivers/mtd/maps/device-flash.c} C source file.
\begin{verbatim}
// Includes that are required for the flash map driver to know of the prototypes :
#include <asm/io.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/mtd/map.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/vmalloc.h>
// Put some flash map definitions here :
#define WINDOW_ADDR 0x1FC00000 /* Real address of the flash */
#define WINDOW_SIZE 0x400000 /* Size of flash */
#define BUSWIDTH 2 /* Buswidth */
static void __exit device_mtd_cleanup(void);
static struct mtd_info *device_mtd_info;
static struct map_info devicd_map = {
.name = "device",
.size = WINDOW_SIZE,
.bankwidth = BUSWIDTH,
.phys = WINDOW_ADDR,
};
static int __init device_mtd_init(void)
{
// Display that we found a flash map device
printk("device: 0x\%08x at 0x\%08x\n", WINDOW_SIZE, WINDOW_ADDR);
// Remap the device address to a kernel address
device_map.virt = ioremap(WINDOW_ADDR, WINDOW_SIZE);
// If impossible to remap, exit with the EIO error
if (!device_map.virt) {
printk("device: Failed to ioremap\n");
return -EIO;
}
// Initlialise the device map
simple_map_init(&device_map);
/* MTD informations are closely linked to the flash map device
you might also use "jedec_probe" "amd_probe" or "intel_probe" */
device_mtd_info = do_map_probe("cfi_probe", &device_map);
if (device_mtd_info) {
device_mtd_info->owner = THIS_MODULE;
int parsed_nr_parts = 0;
// We try here to use the partition schema provided by the bootloader specific code
if (parsed_nr_parts == 0) {
int ret = parse_bootloader_partitions(device_mtd_info, &parsed_parts, 0);
if (ret > 0) {
part_type = "BootLoader";
parsed_nr_parts = ret;
}
}
add_mtd_partitions(devicd_mtd_info, parsed_parts, parsed_nr_parts);
return 0;
}
iounmap(device_map.virt);
return -ENXIO;
}
// This function will make the driver clean up the MTD device mapping
static void __exit device_mtd_cleanup(void)
{
// If we found a MTD device before
if (device_mtd_info) {
// Delete every partitions
del_mtd_partitions(device_mtd_info);
// Delete the associated map
map_destroy(device_mtd_info);
}
// If the virtual address is already in use
if (device_map.virt) {
// Unmap the physical address to a kernel space address
iounmap(device_map.virt);
// Reset the structure field
device_map.virt = 0;
}
}
// Macros that indicate which function is called on loading/unloading the module
module_init(device_mtd_init);
module_exit(device_mtd_cleanup);
// Macros defining licence and author, parameters can be defined here too.
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
\end{verbatim}

46
docs/bugs.tex Normal file
View File

@ -0,0 +1,46 @@
OpenWrt as an open source software opens its developpment to the community by having a publicly browseable subversion repository. The Trac software which comes along with a Subversion frontend, a Wiki and a ticket reporting system is used as an interface between developpers, users and contributors in order to make the whole developpment process much easier and efficient.
We make distinction between two kinds of people within the Trac system :
\begin{itemize}
\item developpers, able to report, close and fix tickets
\item reporters, able to add a comment, patch, or request ticket status
\end{itemize}
\subsubsection{Opening a ticket}
A reporter might want to open a ticket for the following reasons :
\begin{itemize}
\item a bug affects a specific hardware and/or software and needs to be fixed
\item a specific software package would be seen as part of the official OpenWrt repository
\item a feature should be added or removed from OpenWrt
\end{itemize}
Regarding the kind of ticket that is open, a patch is welcome in those cases :
\begin{itemize}
\item new package to be included in OpenWrt
\item fix for a bug that works for the reporter and has no known side effect
\item new features that can be added by modifying existing OpenWrt files
\end{itemize}
In order to include a patch, you need to produce it, this can be done by using the \textbf{svn diff} command which generates the differences between your local copy (modified) and the version on the OpenWrt repository (unmodified yet). Then attach the patch with a description, using the "Attach" button.
Once the ticket is open, a developper will take care of it, if so, the ticket is marked as "accepted" with the developper name. You can add comments at any time to the ticket, even when it is closed.
\subsubsection{Closing a ticket}
A ticket might be closed by a developper because :
\begin{itemize}
\item the problem is already fixed (wontfix)
\item the problem described is not judged as valid, and comes along with an explanation why (invalid)
\item the developpers know that this bug will be fixed upstream (wontfix)
\item the problem is very similar to something that has already been reported (duplicate)
\item the problem cannot be reproduced by the developpers (worksforme)
\end{itemize}
A the same time, the reporter may want to get the ticket closed since he is not longer able to trigger the bug, or found it invalid by himself.
When a ticket is closed by a developper and marked as "fixed", the comment contains the subversion changeset which corrects the bug.

62
docs/build.tex
View File

@ -1,19 +1,19 @@
One of the biggest challenges to getting started with embedded devices is that you
can't just install a copy of Linux and expect to be able to compile a firmware.
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 wouldn't have the basic set of tools needed to produce a firmware image.
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
incompatible with the hardware on your development machine, so in a process called
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's not something that's
regularly attempted and so there's a certain amount of mystery and black magic
associated with it. In many cases when you're dealing with embedded devices you'll
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's a time saving step but at the same time
often means you'll be using a rather dated set of tools. Likewise, it's also common
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.
@ -22,17 +22,17 @@ modified to make the kernel run on the embedded platform.
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 doesn't contain any executables or even sources, it's an
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's no work to be done trying to track down an unmodified
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 doesn't
just apply to the kernel, but to anything included with OpenWrt -- It's this one
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.
@ -48,7 +48,7 @@ subversion using the following command:
$ svn co https://svn.openwrt.org/openwrt/trunk kamikaze
\end{Verbatim}
Additionally, there's a trac interface on \href{https://dev.openwrt.org/}{https://dev.openwrt.org/}
Additionally, ther 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 sources.
@ -64,12 +64,12 @@ There are four key directories in the base:
\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.
used to build the firmware image, the compiler, and the C library.
The result of this is three new directories, \texttt{tool\_build}, which is a temporary
directory for building the target independent tools, \texttt{toolchain\_build\_\textit{<arch>}}
which is used for building the toolchain for a specific architecture, and
\texttt{staging\_dir\_\textit{<arch>}} where the resulting toolchain is installed.
You won't need to do anything with the toolchain directory unless you intend to
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}
@ -96,6 +96,13 @@ kamikaze packages
$ ln -s packages/net/nmap kamikaze/package/nmap
\end{Verbatim}
To include all packages, issue the following command :
\begin{Verbatim}
$ ln -s packages/*/* kamikaze/package/
\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 and contains the kernel config and patches
@ -171,12 +178,15 @@ in OpenWrt you'll find two things:
\begin{itemize}
\item \texttt{package/\textit{<name>}/Makefile}
\item \texttt{package/\textit{<name>}/patches}
\item \texttt{package/\textit{<name>}/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
@ -239,13 +249,13 @@ and abstracted to the point where you only need to specify a few variables.
\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're downloading
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)
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} \\
@ -256,9 +266,9 @@ and abstracted to the point where you only need to specify a few variables.
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.
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 is used to verify the package was downloaded correctly and
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)}.
@ -281,7 +291,7 @@ directly as the Nth argument to \texttt{BuildPackage}.
\item \texttt{SECTION} \\
The type of package (currently unused)
\item \texttt{CATEGORY} \\
Which menu it appears in menuconfig
Which menu it appears in menuconfig : Network, Sound, Utilities, Multimedia ...
\item \texttt{TITLE} \\
A short description of the package
\item \texttt{URL} \\
@ -289,7 +299,7 @@ directly as the Nth argument to \texttt{BuildPackage}.
\item \texttt{MAINTAINER} (optional) \\
Who to contact concerning the package
\item \texttt{DEPENDS} (optional) \\
Which packages must be built/installed before this package
Which packages must be built/installed before this package. To reference a dependency defined in the same Makefile, use \textit{<dependency name>}. If defined as an external package, use \textit{+<dependency name>}. For a kernel version dependency use: \textit{@LINUX\_2\_<minor version>}
\end{itemize}
\textbf{\texttt{Package/\textit{<name>}/conffiles} (optional):} \\
@ -302,8 +312,8 @@ directly as the Nth argument to \texttt{BuildPackage}.
\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{<args>})}" as above to
pass in additional arguments for a standard configure script.
"\texttt{\$(call Build/Configure/Default,\textit{<first list of arguments, second list>})}" 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 : $--arg 1$ $--arg 2$. The second list contains arguments that should be defined before running the configure script such as autoconf or compiler specific variables.
\textbf{\texttt{Build/Compile} (optional):} \\
How to compile the source; in most cases you should leave this undefined.
@ -311,7 +321,7 @@ directly as the Nth argument to \texttt{BuildPackage}.
\textbf{\texttt{Package/\textit{<name>}/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
3 defined install macros:
4 defined install macros:
\begin{itemize}
\item \texttt{INSTALL\_DIR} \\
install -d -m0755
@ -319,6 +329,8 @@ directly as the Nth argument to \texttt{BuildPackage}.
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{<name>}}"
@ -329,7 +341,7 @@ desired. Since you only need to compile the sources once, there's one global set
"\texttt{Build}" defines, but you can add as many "Package/<name>" defines as you want
by adding extra calls to \texttt{BuildPackage} -- see the dropbear package for an example.
After you've created your \texttt{package/\textit{<name>}/Makefile}, the new package
After you have created your \texttt{package/\textit{<name>}/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.

4
docs/openwrt.tex
View File

@ -33,7 +33,11 @@
\subsection{Image Builder}
\subsection{SDK}
\section{Adding platform support}
\input{adding}
\section{Debugging and debricking}
\subsection{Adding a serial port}
\subsection{JTAG}
\section{Reporting bugs}
\subsection{Using the Trac ticket system}
\input{bugs}
\end{document}