mirror of
git://projects.qi-hardware.com/openwrt-xburst.git
synced 2024-11-16 18:57:31 +02:00
Trivial patch to correct typos and spelling errors in OpenWRT documentation.\nPlease Apply.\nSigned-off-by: Jesper Dangaard Brouer <hawk@diku.dk>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@10129 3c298f89-4303-0410-b956-a3cf2f4a3e73
This commit is contained in:
parent
8f46721f9b
commit
93e5cbd712
@ -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
|
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
|
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
|
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}
|
\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
|
may not always be relevant, so that you have to clean up those patches to only
|
||||||
let the "must have" code into them.
|
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
|
initialized at startup, as well as processor detection and other boot time
|
||||||
specific fixes.
|
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 ...
|
kernel granularity, redefinitions, processor family and features ...
|
||||||
|
|
||||||
The third patch may contain drivers for: serial console, ethernet NIC, wireless
|
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
|
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
|
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
|
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 them to behave the same way.
|
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
|
of running a custom firmware on your device, because this is sometimes a blocking
|
||||||
part of the flashing process.
|
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 and/or compressed kernel image
|
\item Binary and/or compressed kernel image
|
||||||
\item Binary and/or compressed root filesystem 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}
|
\end{itemize}
|
||||||
|
|
||||||
Once you have figured out how the firmware format is partitioned, you will have
|
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
|
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.
|
firmware and the device that will be flashed using this binary firmware.
|
||||||
|
|
||||||
@ -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);
|
simple_map_init(&device_map);
|
||||||
|
|
||||||
/* MTD informations are closely linked to the flash map device
|
/* MTD informations are closely linked to the flash map device
|
||||||
@ -474,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_LICENSE("GPL");
|
||||||
MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
|
MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
@ -45,7 +45,7 @@ A ticket might be closed by a developer because:
|
|||||||
\item the problem cannot be reproduced by the developers (worksforme)
|
\item the problem cannot be reproduced by the developers (worksforme)
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
A the same time, the reporter may want to get the ticket closed since he is not
|
At 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.
|
longer able to trigger the bug, or found it invalid by himself.
|
||||||
|
|
||||||
When a ticket is closed by a developer and marked as "fixed", the comment contains
|
When a ticket is closed by a developer and marked as "fixed", the comment contains
|
||||||
|
Loading…
Reference in New Issue
Block a user