projects / openwrt.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
[lantiq] bump kernel to 3.2.12
[openwrt.git] / docs / adding.tex
diff --git a/docs/adding.tex b/docs/adding.tex
index b1712ac..97547ac 100644 (file)
--- a/docs/adding.tex
+++ b/docs/adding.tex
@@ -15,7 +15,7 @@ when they do, you will most likely not be able to complete the firmware creation
 
 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 
 
 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.
+platforms, known to be running Linux originally.
 
 \subsection{Which Operating System does this device run?}
 
 
 \subsection{Which Operating System does this device run?}
 
@@ -135,7 +135,7 @@ OpenWrt target.
 
 By using a serial port and a level shifter, 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
 
 By using a serial port and a level shifter, 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.
+easily notice if the device uses a Linux kernel or something different.
 
 \subsection{Finding and using the manufacturer SDK}
 
 
 \subsection{Finding and using the manufacturer SDK}
 
@@ -238,11 +238,11 @@ 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.
 
 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 
+The first 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.
 
 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, 
+The second patch will contain all useful definitions for that board: addresses, 
 kernel granularity, redefinitions, processor family and features ...
 
 The third patch may contain drivers for: serial console, ethernet NIC, wireless 
 kernel granularity, redefinitions, processor family and features ...
 
 The third patch may contain drivers for: serial console, ethernet NIC, wireless 
@@ -256,7 +256,7 @@ this hardware.
 The bootloader is the first program that is started right after your device has 
 been powered on. This program, can be more or less sophisticated, some do let you 
 do network booting, USB mass storage booting ... The bootloader is device and 
 The bootloader is the first program that is started right after your device has 
 been powered on. This program, can be more or less sophisticated, some do let you 
 do network booting, USB mass storage booting ... The bootloader is device and 
-architeture specific, some bootloaders were designed to be universal such as 
+architecture specific, some bootloaders were designed to be universal such as 
 RedBoot or U-Boot so that you can meet those loaders on totally different 
 platforms and expect them to behave the same way.
 
 RedBoot or U-Boot so that you can meet those loaders on totally different 
 platforms and expect them to behave the same way.
 
@@ -331,10 +331,10 @@ You might want to understand the firmware format, even if you are not yet capabl
 of running a custom firmware on your device, because this is sometimes a blocking
 part of the flashing process.
 
 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:
+A firmware format is most of the time composed of the following fields:
 
 \begin{itemize}
 
 \begin{itemize}
-\item header, containing a firmare version and additional fields: Vendor, Hardware version ...
+\item header, containing a firmware version and additional fields: Vendor, Hardware version ...
 \item CRC32 checksum on either the whole file or just part of it
 \item Binary and/or compressed kernel image
 \item Binary and/or compressed root filesystem image
 \item CRC32 checksum on either the whole file or just part of it
 \item Binary and/or compressed kernel image
 \item Binary and/or compressed root filesystem image
@@ -342,7 +342,7 @@ A firmare format is most of the time composed of the following fields:
 \end{itemize}
 
 Once you have figured out how the firmware format is partitioned, you will have 
 \end{itemize}
 
 Once you have figured out how the firmware format is partitioned, you will have 
-to write your own tool that produces valid firmare binaries. One thing to be very
+to write your own tool that produces valid firmware 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.
 
 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.
 
@@ -357,7 +357,7 @@ 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 
 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 
+configuration options, this can be done by editing the file \
 \textbf{linux/drivers/mtd/maps/Kconfig}:
 
 \begin{verbatim}
 \textbf{linux/drivers/mtd/maps/Kconfig}:
 
 \begin{verbatim}
@@ -418,7 +418,7 @@ static int __init device_mtd_init(void)
                return -EIO;
        }
 
                return -EIO;
        }
 
-          // Initlialise the device map
+          // Initialize the device map
        simple_map_init(&device_map);
 
           /* MTD informations are closely linked to the flash map device
        simple_map_init(&device_map);
 
           /* MTD informations are closely linked to the flash map device
@@ -474,7 +474,117 @@ module_init(device_mtd_init);
 module_exit(device_mtd_cleanup);
 
 
 module_exit(device_mtd_cleanup);
 
 
-// Macros defining licence and author, parameters can be defined here too.
+// Macros defining license and author, parameters can be defined here too.
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
 \end{verbatim}
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
 \end{verbatim}
+
+\subsection{Adding your target in OpenWrt}
+
+Once you spotted the key changes that were made to the Linux kernel
+to support your target, you will want to create a target in OpenWrt
+for your hardware. This can be useful to benefit from the toolchain
+that OpenWrt builds as well as the resulting user-space and kernel
+configuration options.
+
+Provided that your target is already known to OpenWrt, it will be
+as simple as creating a \texttt{target/linux/board} directory
+where you will be creating the following directories and files.
+
+Here for example, is a \texttt{target/linux/board/Makefile}:
+
+\begin{Verbatim}[frame=single,numbers=left]
+#
+# Copyright (C) 2009 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+ARCH:=mips
+BOARD:=board
+BOARDNAME:=Eval board
+FEATURES:=squashfs jffs2 pci usb
+
+LINUX_VERSION:=2.6.27.10
+
+include $(INCLUDE_DIR)/target.mk
+
+DEFAULT_PACKAGES += hostapd-mini
+
+define Target/Description
+        Build firmware images for Evaluation board
+endef
+
+$(eval $(call BuildTarget))
+\end{Verbatim}
+
+\begin{itemize}
+    \item \texttt{ARCH} \\
+        The name of the architecture known by Linux and uClibc
+    \item \texttt{BOARD} \\
+        The name of your board that will be used as a package and build directory identifier
+    \item \texttt{BOARDNAME} \\
+        Expanded name that will appear in menuconfig
+    \item \texttt{FEATURES} \\
+        Set of features to build filesystem images, USB, PCI, VIDEO kernel support
+    \item \texttt{LINUX\_VERSION} \\
+        Linux kernel version to use for this target
+    \item \texttt{DEFAULT\_PACKAGES} \\
+        Set of packages to be built by default
+\end{itemize}
+
+A partial kernel configuration which is either named \texttt{config-default} or which matches the kernel version \texttt{config-2.6.x} should be present in \texttt{target/linux/board/}.
+This kernel configuration will only contain the relevant symbols to support your target and can be changed using \texttt{make kernel\_menuconfig}.
+
+To patch the kernel sources with the patches required to support your hardware, you will have to drop them in \texttt{patches} or in \texttt{patches-2.6.x} if there are specific
+changes between kernel versions. Additionnaly, if you want to avoid creating a patch that will create files, you can put those files into \texttt{files} or \texttt{files-2.6.x}
+with the same directory structure that the kernel uses (e.g: drivers/mtd/maps, arch/mips ..).
+
+The build system will require you to create a \texttt{target/linux/board/image/Makefile}:
+
+\begin{Verbatim}[frame=single,numbers=left]
+#
+# Copyright (C) 2009 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+include $(INCLUDE_DIR)/image.mk
+
+define Image/BuildKernel
+        cp $(KDIR)/vmlinux.elf $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.elf
+        gzip -9 -c $(KDIR)/vmlinux > $(KDIR)/vmlinux.bin.gz
+        $(STAGING_DIR_HOST)/bin/lzma e $(KDIR)/vmlinux $(KDIR)/vmlinux.bin.l7
+        dd if=$(KDIR)/vmlinux.bin.l7 of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma bs=65536 conv=sync
+        dd if=$(KDIR)/vmlinux.bin.gz of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.gz bs=65536 conv=sync
+endef
+
+define Image/Build/squashfs
+    $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+endef
+
+define Image/Build
+        $(call Image/Build/$(1))
+        dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/openwrt-$(BOARD)-root.$(1) bs=128k conv=sync
+
+        -$(STAGING_DIR_HOST)/bin/mkfwimage \
+                -B XS2 -v XS2.ar2316.OpenWrt \
+                -k $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma \
+                -r $(BIN_DIR)/openwrt-$(BOARD)-root.$(1) \
+                -o $(BIN_DIR)/openwrt-$(BOARD)-ubnt2-$(1).bin
+endef
+
+$(eval $(call BuildImage))
+
+\end{Verbatim}
+
+\begin{itemize}
+    \item \texttt{Image/BuildKernel} \\
+        This template defines changes to be made to the ELF kernel file
+    \item \texttt{Image/Build} \\
+       This template defines the final changes to apply to the rootfs and kernel, either combined or separated
+       firmware creation tools can be called here as well.
+\end{itemize}
Personal OpenWRT clone
This page took 0.030219 seconds and 4 git commands to generate.