[kernel] netfilter: fix RTSP on 2.6.24

[openwrt.git] / docs / adding.tex

diff --git a/docs/adding.tex b/docs/adding.tex
index 34e13ae..ec14eae 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?}
 


@@ -121,27 +121,27 @@ Scroll over the firmware to find printable words that can be significant.
 
 \subsubsection{Amount of flash memory}
 
 
 \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
+Linux can hardly fit in a 2MB flash device, once you have opened the device and 
+located the flash chip, try to find its characteristics on the Internet. 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.
 
 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.
+OpenWrt does not currently run on devices which have 2MB or less 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}
 
 
 \subsubsection{Pluging a serial port}
 

-By using a serial port, you may reach the console that is being shown by the device
+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
 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}
 
 Once you are sure your device run a Linux based firmware, you will be able to start
 
 \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 Development Kit.
+hacking on it. If the manufacturer respected the GPL, it will have released a Sample
+Development Kit with the device.

 
 \subsubsection{GPL violations}
 
 
 \subsubsection{GPL violations}
 


@@ -188,11 +188,11 @@ You should anyway be able to use the following components:
 \item binary tools to create a valid firmware image
 \end{itemize}
 
 \item binary tools to create a valid firmware image
 \end{itemize}
 

-Your work is now divided into the following tasks:
+Your work can be divided into the following tasks:

 
 \begin{itemize}
 \item create a clean patch of the hardware specific part of the linux kernel
 
 \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 spot potential kernel GPL violations especially on netfilter 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
 \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


@@ -238,17 +238,17 @@ 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, 
-kernel granularity, redifinitions, processor family and features ...
+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 
 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. 
 
 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 code might not be useful if you plan on writing drivers from scratch for 

 this hardware.
 
 \subsubsection{Using the device bootloader}
 this hardware.
 
 \subsubsection{Using the device bootloader}


@@ -256,15 +256,15 @@ 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 
 RedBoot or U-Boot so that you can meet those loaders on totally different 

-platforms and expect to work the same way.
+platforms and expect them to behave the same way.

 
 If your device runs a proprietary operating system, you are very likely to deal 
 with a proprietary boot loader as well. This may not always be a limitation, 
 some proprietary bootloaders can even have source code available (i.e : Broadcom CFE).
 
 
 If your device runs a proprietary operating system, you are very likely to deal 
 with a proprietary boot loader as well. This may not always be a limitation, 
 some proprietary bootloaders can even have source code available (i.e : Broadcom CFE).
 

-According to the bootloader features, hacking on th device will be more or less 
+According to the bootloader features, hacking on the device will be more or less 

 easier. It is very probable that the bootloader, even exotic and rare, has a 
 documentation somewhere over the Internet. In order to know what will be possible 
 with your bootloader and the way you are going to hack the device, look over the 
 easier. It is very probable that the bootloader, even exotic and rare, has a 
 documentation somewhere over the Internet. In order to know what will be possible 
 with your bootloader and the way you are going to hack the device, look over the 


@@ -311,7 +311,6 @@ order to make binary drivers work with your custom kernel:
 \item CONFIG\_DEBUG\_KERNEL
 \item CONFIG\_DETECT\_SOFTLOCKUP
 \item CONFIG\_DEBUG\_KOBJECT
 \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 CONFIG\_KALLSYMS
 \item CONFIG\_KALLSYMS\_ALL
 \end{itemize}


@@ -332,18 +331,18 @@ 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 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 Binary and/or compressed kernel image
+\item Binary and/or compressed root filesystem image

 \item potential garbage
 \end{itemize}
 
 Once you have figured out how the firmware format is partitioned, you will have 
 \item potential garbage
 \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.
 


@@ -358,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}


@@ -419,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


@@ -475,7 +474,7 @@ 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}