分类： WINDOWS
2010-07-21 16:58:38
2.3.2 Finding and using the manufacturer SDK
2.3.2 寻找并使用制造商SDK
Once you are sure your device run a Linux based firmware, you will be able to start hacking on it. If the manufacturer respected the GPL, it will have released a Sample Development Kit with the device.
一旦你确定你的设备运行的是基于Linux的固件，你就能够开始侵入它了。如果生厂商考虑到GPL，它会给设备发布一个 Sample Development Kit。
GPL violations
GPL侵犯
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.
一些生厂商的确会发布基于Linux的二进制固件，而完全不带任何资源。首先需要阅读你的设备许可，然后给他们写信告知缺少公共资源编码。如果生产商回复说他们不发布包含SDK的公共资源软件，那么我们建议你和 gpl-violations.org团体取得联系。
You will find below a sample letter that can be sent to the manufacturer:
以下是一篇信件例文，你可以把它发送给生厂商：
Miss, Mister,
I am using a
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,
您好，
我正在使用<设备名>，但是我在你们的网站和CD-ROM上都找不到用于创建或者修改固件的公共资源软件。
为了和GPL许可相一致，你需要发布如下资源：
· 编制内核和应用软件的完整工具链（gcc, binutils, libc）
· 用于创建常规固件的工具(mksquashfs, mkcramfs ...)
· 用于在特定硬件上运行的有补丁的内核资源，不包括二进制驱动
对您的回答我提前表示感谢。
最好的祝愿， <你的姓名>
Using the SDK
使用SDK
Once the SDK is available, you are most likely not to be able to build a complete or functional 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.
一旦SDK可用，你通常都不能创建一个使用它的完整、实用的固件，而只能是它的部件，比如内核或者根文件系统。对于发布一个在解压或者使用时都起作用的工具，大多数生产商并不重视。
You should anyway be able to use the following components:
你至少要能使用如下部件：
Your work can be divided into the following tasks:
你的工作可以被分为以下几部分：
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 CVS or the git repository of the kernel development trees. Anyway, some parts can be easily isolated and used as a good start to make a vanilla kernel work your hardware.
大多数时候，和SDK在一起的内核资源并不清洁，它不是标准的Linux版本，它也有从CVS 或者是 内核发展树的git 目录中相反移植的architecture specific fixes。总之，一些部分可以被轻易地隔离，作为一个让普通内核运转硬件的良好开端。
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 linux/Makefile file.
head -5 linux-2.x.x/Makefile
VERSION = 2
PATCHLEVEL = x
SUBLEVEL = y
EXTRAVERSION = z
NAME=A fancy name
许多目录都很可能会存在使硬件在Linux之下被认证和使用所需的本地修改。首先，你需要找出硬件所使用的linux内核版本，它可以通过编辑 linux/Makefile文件找到。
head -5 linux-2.x.x/Makefile
VERSION = 2
PATCHLEVEL = x
SUBLEVEL = y
EXTRAVERSION = z
NAME=A fancy name
So now, you know that you have to download a standard kernel tarball at kernel.org that matches the version being used by your hardware.
Then you can create a diff file between the two trees, especially for the following directories:
diff -urN linux-2.x.x/arch/
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
所以现在，你需要在kernel.org下载一个标准内核tarbll，它和你的硬件所用的版本相一致。
然后你就能在两个树之间特别为以下目录创建一个diff文件：
diff -urN linux-2.x.x/arch/
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
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 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.
这可以组建一套基本的三补丁，它们很有可能包含任何所需的修改，这些修改已经被做入常用Linux内核用于继续你的特定设备。当然，由diff -urN所创造的内容也许并不总是相关的，为了让"must have"编码进入，你需要清除这些补丁。
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.
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. This code might not be useful if you plan on writing drivers from scratch for this hardware.
第一个补丁将包含在启动中初始化的board、处理器检测以及其他启动时间的特定修补程序所需的全部编码。
第二个补丁将包含对于此board的所有有用说明：地址，内核间隔，再定义， 处理器族和特性......
第三个补丁包含的补丁有：串行控制台，以太网网卡，无线网卡 USB 网卡...。大多数时候这个补丁只包含为使二进制驱动和Linux内核一起工作而增加的"glue" 编码。如果你想从抓取中为此硬件编写驱动，这个编码也许是没用的。
Using the device bootloader
使用装置引导加载程序
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 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.
引导加载程序是在装置启动后第一个立即开始的程序。这个程序，多少都有点复杂，某些的确会让你做网络引导，USB大容量存储引导.......引导加载程序是特别的装置和结构，一些引导加载程序是被设计用以广泛使用的，例如 RedBoot或者U-Boot，这样你就能在完全不同的平台上迎合载入器，反过来也让它们这么做。
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).
如果你的装置在一个专利的操作系统运行，你也很可能要处理专利引导载入器。它也许不会总是成为一个限制条件，一些专利引导加载程序甚至可以拥有可用的资源编码（即: Broadcom CFE）
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 following features :
根据引导加载程序特性，侵入设备会变得更加简单。甚至是非本地和稀少的引导加载程序都能在互联网上找到程序说明书。为了了解你的引导加载程序的可能性和你正在入侵设备的方法，看看以下的特性：
Net booting is something very convenient, because you will only have to set up network booting servers on your development station, and keep the original firmware on the device till you are sure you can replace it. This also prevents your device from being flashed, and potentially bricked every time you want to test a modification on the kernel/filesystem.
网络引导非常方便，因为你只需要在你的开发站建立起网络引导服务器，然后把设备上的原始固件保存下来直到你确定可以替换它。这也阻止了你的设备发光，或者在每次你想测试内核/文件系统修改时很可能出现的堆叠。
If your device needs to be flashed every time you load a firmware, the bootlader might only accept a specific firmware format to be loaded, so that you will have to understand the firmware format as well.
如果你的装置在每次装载固件时都需要发光，引导加载程序也许只会接受加载特定的固件格式，这样，你也需要了解固件格式。
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.
正如我们之前所说的，生产商的确会在他们的GPLtarbll中发布二进制驱动。当这些驱动被静态地连接到内核中，它们也成为了GPL，幸运地或者说不幸地是，大多数驱动并没有被静态地连接。这使你能够把驱动动态地与当前内核版本相连接，并让它们一同工作。
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.
这是整个公共资源项目中最为棘手和单调的一部分。有些驱动需要一些修改和你的常用内核一起工作，因为它们曾和早期的内核一起工作，而在这两个版本中/间很少有对于内核的修改。例子就是Broadcom BCM43xx无线芯片集的二进制驱动，在这个芯片集中，网络接口构造只有少许的不同。
Some general principles can be applied no matter which kernel version is used in order to make binary drivers work with your custom kernel:
为了使二进制驱动同你的惯用内核一起工作，无论使用的是哪一个内核版本都可以使用这些普遍原则：
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.
大多数时候，装载二进制驱动都会失败并生成内核错误。为了把compatibily同二进制驱动和存储内核驱动放在一起，在二进制驱动试图使用的最后一个标志之前或者之后，如果你没必要移动一些构造文件，你可以了解这个标志，然后在内核头文件里查找。
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 firmware format is most of the time composed of the following fields:
即使你还不能运行装置上的惯用固件，你也许想了解固件格式，因为有时候这是闪光程序中的阻滞部分。
固件格式通常都存在于以下的文件中：
Once you have figured out how the firmware format is partitioned, you will have 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.
一旦你指出了固件格式是如何分开的，你就得写入你自己的工具用于生成有效的固件二进制。无论是生成二进制固件的机器还是使用此二进制固件会闪光的设备，它们的字节存储顺序都需要小心对待。
Writing a flash map driver
编写一个flash绘制驱动
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 linux/drivers/mtd/maps/Kconfig:
首先，你需要使自己的光绘制驱动在内核配置选项中可见，可以通过编辑文件 linux/drivers/mtd/maps/Kconfig实现：
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.
Then add your source file to the linux/drivers/mtd/maps/Makefile, so that it will be compiled along with the kernel.
obj-\$(CONFIG_MTD_DEVICE_FLASH) += device-flash.o
You can then write the kernel driver itself, by creating a linux/drivers/mtd/maps/device-flash.c C source file.
// Includes that are required for the flash map driver to know of the prototypes:
#include
#include
#include
#include
#include
#include
#include
// 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;
}
// Initialize 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 license and author, parameters can be defined here too.
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Me, myself and I
2.4 Debugging and debricking
2.4 调试和debricking
2.4.1 Adding a serial port
2.4.1 增加串行端口
2.4.2 JTAG
2.4.2 JTAG
2.5 Reporting bugs
2.5 报告错误
2.5.1 Using the Trac ticket system
2.5.1 使用追踪标签系统
OpenWrt as an open source software opens its development 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 developers, users and contributors in order to make the whole development process much easier and efficient.
We make distinction between two kinds of people within the Trac system:
通过建立一个公开浏览的子版本存储库，作为一种公开资源，OpenWrt对于公众开放了它的发展。为了使整个开发过程更加简单有效，与Subversion 前端、Wiki和标签报告系统一同出现的追踪软件被用作是开发者、用户和撰稿人之间的接口。
在此追踪系统内部我们区分出两种人：
Opening a ticket
开标签
A reporter might want to open a ticket for the following reasons:
因为如下原因，报告者也许想开一份标签：
Regarding the kind of ticket that is open, a patch is welcome in those cases:
关于开出的标签种类，在如下情况下需要补丁：
Once the ticket is open, a developer will take care of it, if so, the ticket is marked as "accepted" with the developer name. You can add comments at any time to the ticket, even when it is closed.
一旦标签被打开，开发者就要管理好，之后，标签同开发者的名字一起被标记为"accepted"。即使标签出于关闭状态，你也可以在任何时候给它加上评论。
Closing a ticket
关闭标签
A ticket might be closed by a developer because:
标签也许会因为如下原因被开发者关闭：
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.
When a ticket is closed by a developer and marked as "fixed", the comment contains the subversion changeset which corrects the bug.
同时，由于报告者再也不能引发错误或者自己发现它无效，他或许想关闭标签。
当开发者关闭标签并标记为 "fixed"时，注释包含改正错误的子版本更改集。
2.6 Submitting patches
2.6 提交补丁
2.6.1 How to contribute
2.6.1 怎样捐助
OpenWrt is constantly being improved. We’d like as many people to contribute to this as we can get. If you find a change useful, by all means try to get it incorporated into the project. This should improve OpenWrt and it should help carry your changes forward into future versions
OpenWrt不断被改进。我们希望得到尽可能多的人进行捐助。如果你发现一个有用的更改，尽量将它包含进这个项目中。这可以改进OpenWrt，它会有助于你将自己的更改带入将来的版本之中。
This section tries to lay out a procedure to enable people to submit patches in a way that is most effective for all concerned.
这部分试图显示的是在所有情况下最有效的提交补丁的方法。
It is important to do all these steps repeatedly:
反复做以下步骤是很重要的：
2.6.2 Where to listen and talk
2.6.2 倾听和交流的地方
It is often best to document what you are doing before you do it. The process of documentation often exposes possible improvements. Keep your documentation up to date.
在开始之前最好记录下正在做的事情。程序说明书的过程通常可以显示可能的改进办法。保持你的程序说明书经常更新。
2.6.3 Patch Submission Process
2.6.3 提交补丁的过程
1.用 git 或者 svn创建补丁。用diff -urN 手动创建补丁也是可行的，但是通常没必要这么做。
2.给openwrt-devel@lists.openwrt.org发送邮件，内容包括如下部分：
a.Subject中的[PATCH]
b.(optional)在正文部分一段较长的关于补丁的描述
c.像这样结尾：姓名
d.实际的补丁，内联，没有修饰的词汇，没有损毁的空白。
3.请参阅
以此来确保你的邮件委托人没有损毁你的补丁。
4.请在你的签名行使用你的真名和邮箱地址，遵守Linux Kernel patch submission guidelines 中的准则。
5.如下是正确编排过的补丁提交的例子： http://lists.openwrt.org/pipermail/openwrt-devel/2007-November/001334.html
