查看: 7989|回复: 0


发表于 2014-9-4 15:10:10 | 显示全部楼层 |阅读模式

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


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 <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 name>




·         编制内核和应用软件的完整工具链(gcc, binutils, libc)

·         用于创建常规固件的工具(mksquashfs, mkcramfs ...)

·         用于在特定硬件上运行的有补丁的内核资源,不包括二进制驱动


最好的祝愿, <你的姓名>

Using the 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.


You should anyway be able to use the following components:

  •   kernel sources with more or less functional patches for your hardware
  • binary drivers linked or to be linked with the shipped kernel version
  • packages of the toolchain used to compile the whole firmware: gcc, binutils, libc or uClibc
  • binary tools to create a valid firmware image


  • 对你的硬件来说多少带有实用补丁的内核资源
  • 与推出的内核版本相连接的二进制驱动
  • 用于编制整个固件的工具链数据包:gcc, binutils, libc or uClibc
  • 创建有效固件图像的二进制工具

Your work can be divided into the following tasks:

  • create a clean patch of the hardware specific part of the linux kernel
  • spot potential kernel GPL violations especially on netfilter and USB stack stuff
  • make the binary drivers work, until there are open source drivers
  • use standard a GNU toolchain to make working executables
  • understand and write open source tools to generate a valid firmware image


  • 创建一个新的linux内核的特殊硬件部分的补丁
  • 发现潜在的内核GPL侵犯,特别是在防火墙和USB栈材料上
  • 让二进制驱动工作,直到出现公开资源驱动
  • 使用标准的GNU工具链让工作执行
  • 理解并写入公开资源工具以生成有效的固件图像

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  
NAME=A fancy name

许多目录都很可能会存在使硬件在Linux之下被认证和使用所需的本地修改。首先,你需要找出硬件所使用的linux内核版本,它可以通过编辑 linux/Makefile文件找到。

head -5 linux-2.x.x/Makefile  
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/<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



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

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的所有有用说明:地址,内核间隔,再定义, 处理器族和特性......

第三个补丁包含的补丁有:串行控制台,以太网网卡,无线网卡 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 :

  • does the bootloader allow net booting via bootp/DHCP/NFS or tftp
  • does the bootloader accept loading ELF binaries ?
  • does the bootloader have a kernel/firmware size limitation ?
  • does the bootloader expect a firmware format to be loaded with ?
  • are the loaded files executed from RAM or flash ?


  • 引导加载程序是否允许通过 bootp/DHCP/NFS或者tftp的网络引导
  • 引导加载程序是否接受装载ELF二进制?
  • 引导加载程序是否有一个内核/固件大小限制?
  • 引导加载程序是否接受一起载入固件格式?
  • 加载的文件是从RAM还是flash上执行?

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.


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:

  • turn on kernel debugging features such as:
  • link binary drivers when possible to the current kernel version
  • try to load those binary drivers
  • catch the lockups and understand them


  • 启动内核调试特性,如:
  • 可能的话将二进制驱动与当前内核版本相连接
  • 试着装载这些二进制驱动
  • 找到锁定并理解它们

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.


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:

  • header, containing a firmware version and additional fields: Vendor, Hardware version ...
  • CRC32 checksum on either the whole file or just part of it
  • Binary and/or compressed kernel image
  • Binary and/or compressed root filesystem image
  • potential garbage



  • 头,包含固件版本和附件:供应商,硬件版本......
  • 在整个文件中或者是一部分的CRC32校验和
  • 二进制和/或压缩的内核图像
  • 二进制和/或压缩的根文件系统图像
  • 潜在的垃圾

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


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实现:

        tristate "Device Flash device"  
        depends on ARCHITECTURE && DEVICE  
         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 <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;  

   // Initialize the 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;  

       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  
   // Delete the associated map  

// If the virtual address is already in use  
       if (device_map.virt) {  
// Unmap the physical address to a kernel space address  
// Reset the structure field  
              device_map.virt = 0;  

// Macros that indicate which function is called on loading/unloading the module  

// Macros defining license and author, parameters can be defined here too.  
MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");

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:

  • developers, able to report, close and fix tickets
  • reporters, able to add a comment, patch, or request ticket status

通过建立一个公开浏览的子版本存储库,作为一种公开资源,OpenWrt对于公众开放了它的发展。为了使整个开发过程更加简单有效,与Subversion 前端、Wiki和标签报告系统一同出现的追踪软件被用作是开发者、用户和撰稿人之间的接口。


  • 开发者,可以报告、关闭和修复标签
  • 报告者,可以添加注释、 补丁、或询问标签状况

Opening a ticket


A reporter might want to open a ticket for the following reasons:

  • a bug affects a specific hardware and/or software and needs to be fixed
  • a specific software package would be seen as part of the official OpenWrt repository
  • a feature should be added or removed from OpenWrt


  • 影响特定的硬件和/或软件的bug,需要被修复
  • 特定的软件数据包被看做是官方OpenWrt储存库
  • 从 OpenWrt 中添加或者移除特性

Regarding the kind of ticket that is open, a patch is welcome in those cases:

  • new package to be included in OpenWrt
  • fix for a bug that works for the reporter and has no known side effect
  • new features that can be added by modifying existing OpenWrt files


  • 需要在OpenWrt中包含进新的数据包
  • 修补对于报告者起作用的错误,并且没有已知的副作用
  • 通过修改现存的OpenWrt文件可以增加的新特性

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.


Closing a ticket


A ticket might be closed by a developer because:

  • the problem is already fixed (wontfix)
  • the problem described is not judged as valid, and comes along with an explanation why (invalid)
  • the developers know that this bug will be fixed upstream (wontfix)
  • the problem is very similar to something that has already been reported (duplicate)
  • the problem cannot be reproduced by the developers (worksforme)


  • 问题已经解决(wontfix)
  • 问题描述被评为无效,和原因解释一同出现(invalid)
  • 开发者知道此错误会被逆流修改(wontfix)
  • 问题和已经报告过的很相似(duplicate)
  • 开发者不能再现问题(worksforme)

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


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:

  • listen to what other people think.
  • talk explaining what problem you are addressing and your proposed solution.
  • do write useful patches including documentation.
  • test. test. Test.


  • 倾听其他人的想法
  • 谈论你遇到了什么问题提出你的解决办法
  • 编写有用的补丁,包括程序说明书
  • 测试,测试,再测试

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 手动创建补丁也是可行的,但是通常没必要这么做。


a.Subject中的[PATCH] <short description>,下接:





    http://kerneltrap.org/Linux/Email_Clients_and_Patches 以此来确保你的邮件委托人没有损毁你的补丁。

4.请在你的签名行使用你的真名和邮箱地址,遵守Linux Kernel patch submission guidelines 中的准则。

5.如下是正确编排过的补丁提交的例子:         http://lists.openwrt.org/pipermail/openwrt-devel/2007-November/001334.html


使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册


Archiver|手机版|小黑屋|联合无线论坛 ( 豫ICP备07011616号  

GMT+8, 2021-3-8 07:51 , Processed in 0.076167 second(s), 30 queries , Gzip On.

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表