adding.tex 25 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590
  1. Linux is now one of the most widespread operating system for embedded devices due
  2. to its openess as well as the wide variety of platforms it can run on. Many
  3. manufacturer actually use it in firmware you can find on many devices: DVB-T
  4. decoders, routers, print servers, DVD players ... Most of the time the stock
  5. firmware is not really open to the consumer, even if it uses open source software.
  6. You might be interested in running a Linux based firmware for your router for
  7. various reasons: extending the use of a network protocol (such as IPv6), having
  8. new features, new piece of software inside, or for security reasons. A fully
  9. open-source firmware is de-facto needed for such applications, since you want to
  10. be free to use this or that version of a particular reason, be able to correct a
  11. particular bug. Few manufacturers do ship their routers with a Sample Development Kit,
  12. that would allow you to create your own and custom firmware and most of the time,
  13. when they do, you will most likely not be able to complete the firmware creation process.
  14. This is one of the reasons why OpenWrt and other firmware exists: providing a
  15. version independent, and tools independent firmware, that can be run on various
  16. platforms, known to be running Linux originally.
  17. \subsection{Which Operating System does this device run?}
  18. There is a lot of methods to ensure your device is running Linux. Some of them do
  19. need your router to be unscrewed and open, some can be done by probing the device
  20. using its external network interfaces.
  21. \subsubsection{Operating System fingerprinting and port scanning}
  22. A large bunch of tools over the Internet exists in order to let you do OS
  23. fingerprinting, we will show here an example using \textbf{nmap}:
  24. \begin{Verbatim}
  25. nmap -P0 -O <IP address>
  26. Starting Nmap 4.20 ( http://insecure.org ) at 2007-01-08 11:05 CET
  27. Interesting ports on 192.168.2.1:
  28. Not shown: 1693 closed ports
  29. PORT STATE SERVICE
  30. 22/tcp open ssh
  31. 23/tcp open telnet
  32. 53/tcp open domain
  33. 80/tcp open http
  34. MAC Address: 00:13:xx:xx:xx:xx (Cisco-Linksys)
  35. Device type: broadband router
  36. Running: Linksys embedded
  37. OS details: Linksys WRT54GS v4 running OpenWrt w/Linux kernel 2.4.30
  38. Network Distance: 1 hop
  39. \end{Verbatim}
  40. nmap is able to report whether your device uses a Linux TCP/IP stack, and if so,
  41. will show you which Linux kernel version is probably runs. This report is quite
  42. reliable and it can make the distinction between BSD and Linux TCP/IP stacks and others.
  43. Using the same tool, you can also do port scanning and service version discovery.
  44. For instance, the following command will report which IP-based services are running
  45. on the device, and which version of the service is being used:
  46. \begin{verbatim}
  47. nmap -P0 -sV <IP address>
  48. Starting Nmap 4.20 ( http://insecure.org ) at 2007-01-08 11:06 CET
  49. Interesting ports on 192.168.2.1:
  50. Not shown: 1693 closed ports
  51. PORT STATE SERVICE VERSION
  52. 22/tcp open ssh Dropbear sshd 0.48 (protocol 2.0)
  53. 23/tcp open telnet Busybox telnetd
  54. 53/tcp open domain ISC Bind dnsmasq-2.35
  55. 80/tcp open http OpenWrt BusyBox httpd
  56. MAC Address: 00:13:xx:xx:xx:xx (Cisco-Linksys)
  57. Service Info: Device: WAP
  58. \end{verbatim}
  59. The web server version, if identified, can be determining in knowing the Operating
  60. System. For instance, the \textbf{BOA} web server is typical from devices running
  61. an open-source Unix or Unix-like.
  62. \subsubsection{Wireless Communications Fingerprinting}
  63. Although this method is not really known and widespread, using a wireless scanner
  64. to discover which OS your router or Access Point run can be used. We do not have
  65. a clear example of how this could be achieved, but you will have to monitor raw
  66. 802.11 frames and compare them to a very similar device running a Linux based firmware.
  67. \subsubsection{Web server security exploits}
  68. The Linksys WRT54G was originally hacked by using a "ping bug" discovered in the
  69. web interface. This tip has not been fixed for months by Linksys, allowing people
  70. to enable the "boot\_wait" helper process via the web interface. Many web servers
  71. used in firmwares are open source web server, thus allowing the code to be audited
  72. to find an exploit. Once you know the web server version that runs on your device,
  73. by using \textbf{nmap -sV} or so, you might be interested in using exploits to reach
  74. shell access on your device.
  75. \subsubsection{Native Telnet/SSH access}
  76. Some firmwares might have restricted or unrestricted Telnet/SSH access, if so,
  77. try to log in with the web interface login/password and see if you can type in
  78. some commands. This is actually the case for some Broadcom BCM963xx based firmwares
  79. such as the one in Neuf/Cegetel ISP routers, Club-Internet ISP CI-Box and many
  80. others. Some commands, like \textbf{cat} might be left here and be used to
  81. determine the Linux kernel version.
  82. \subsubsection{Analysing a binary firmware image}
  83. You are very likely to find a firmware binary image on the manufacturer website,
  84. even if your device runs a proprietary operating system. If so, you can download
  85. it and use an hexadecimal editor to find printable words such as \textbf{vmlinux},
  86. \textbf{linux}, \textbf{ramdisk}, \textbf{mtd} and others.
  87. Some Unix tools like \textbf{hexdump} or \textbf{strings} can be used to analyse
  88. the firmware. Below there is an example with a binary firmware found other the Internet:
  89. \begin{verbatim}
  90. hexdump -C <binary image.extension> | less (more)
  91. 00000000 46 49 52 45 32 2e 35 2e 30 00 00 00 00 00 00 00 |FIRE2.5.0.......|
  92. 00000010 00 00 00 00 31 2e 30 2e 30 00 00 00 00 00 00 00 |....1.0.0.......|
  93. 00000020 00 00 00 00 00 00 00 38 00 43 36 29 00 0a e6 dc |.......8.C6)..??|
  94. 00000030 54 49 44 45 92 89 54 66 1f 8b 08 08 f8 10 68 42 |TIDE..Tf....?.hB|
  95. 00000040 02 03 72 61 6d 64 69 73 6b 00 ec 7d 09 bc d5 d3 |..ramdisk.?}.???|
  96. 00000050 da ff f3 9b f7 39 7b ef 73 f6 19 3b 53 67 ea 44 |???.?9{?s?.;Sg?D|
  97. \end{verbatim}
  98. Scroll over the firmware to find printable words that can be significant.
  99. \subsubsection{Amount of flash memory}
  100. Linux can hardly fit in a 2MB flash device, once you have opened the device and
  101. located the flash chip, try to find its characteristics on the Internet. If
  102. your flash chip is a 2MB or less device, your device is most likely to run a
  103. proprietary OS such as WindRiver VxWorks, or a custom manufacturer OS like Zyxel ZynOS.
  104. OpenWrt does not currently run on devices which have 2MB or less of flash memory.
  105. This limitation will probably not be worked around since those devices are most
  106. of the time micro-routers, or Wireless Access Points, which are not the main
  107. OpenWrt target.
  108. \subsubsection{Pluging a serial port}
  109. By using a serial port and a level shifter, you may reach the console that is being shown by the device
  110. for debugging or flashing purposes. By analysing the output of this device, you can
  111. easily notice if the device uses a Linux kernel or something different.
  112. \subsection{Finding and using the manufacturer SDK}
  113. Once you are sure your device run a Linux based firmware, you will be able to start
  114. hacking on it. If the manufacturer respected the GPL, it will have released a Sample
  115. Development Kit with the device.
  116. \subsubsection{GPL violations}
  117. Some manufacturers do release a Linux based binary firmware, with no sources at all.
  118. The first step before doing anything is to read the license coming with your device,
  119. then write them about this lack of Open Source code. If the manufacturer answers
  120. you they do not have to release a SDK containing Open Source software, then we
  121. recommend you get in touch with the gpl-violations.org community.
  122. You will find below a sample letter that can be sent to the manufacturer:
  123. \begin{verse}
  124. Miss, Mister,
  125. I am using a <device name>, and I cannot find neither on your website nor on the
  126. CD-ROM the open source software used to build or modify the firmware.
  127. In conformance to the GPL license, you have to release the following sources:
  128. \begin{itemize}
  129. \item complete toolchain that made the kernel and applications be compiled (gcc, binutils, libc)
  130. \item tools to build a custom firmware (mksquashfs, mkcramfs ...)
  131. \item kernel sources with patches to make it run on this specific hardware, this does not include binary drivers
  132. \end{itemize}
  133. Thank you very much in advance for your answer.
  134. Best regards, <your name>
  135. \end{verse}
  136. \subsubsection{Using the SDK}
  137. Once the SDK is available, you are most likely not to be able to build a complete
  138. or functional firmware using it, but parts of it, like only the kernel, or only
  139. the root filesystem. Most manufacturers do not really care releasing a tool that
  140. do work every time you uncompress and use it.
  141. You should anyway be able to use the following components:
  142. \begin{itemize}
  143. \item kernel sources with more or less functional patches for your hardware
  144. \item binary drivers linked or to be linked with the shipped kernel version
  145. \item packages of the toolchain used to compile the whole firmware: gcc, binutils, libc or uClibc
  146. \item binary tools to create a valid firmware image
  147. \end{itemize}
  148. Your work can be divided into the following tasks:
  149. \begin{itemize}
  150. \item create a clean patch of the hardware specific part of the linux kernel
  151. \item spot potential kernel GPL violations especially on netfilter and USB stack stuff
  152. \item make the binary drivers work, until there are open source drivers
  153. \item use standard a GNU toolchain to make working executables
  154. \item understand and write open source tools to generate a valid firmware image
  155. \end{itemize}
  156. \subsubsection{Creating a hardware specific kernel patch}
  157. Most of the time, the kernel source that comes along with the SDK is not really
  158. clean, and is not a standard Linux version, it also has architecture specific
  159. fixes backported from the \textbf{CVS} or the \textbf{git} repository of the
  160. kernel development trees. Anyway, some parts can be easily isolated and used as
  161. a good start to make a vanilla kernel work your hardware.
  162. Some directories are very likely to have local modifications needed to make your
  163. hardware be recognized and used under Linux. First of all, you need to find out
  164. the linux kernel version that is used by your hardware, this can be found by
  165. editing the \textbf{linux/Makefile} file.
  166. \begin{verbatim}
  167. head -5 linux-2.x.x/Makefile
  168. VERSION = 2
  169. PATCHLEVEL = x
  170. SUBLEVEL = y
  171. EXTRAVERSION = z
  172. NAME=A fancy name
  173. \end{verbatim}
  174. So now, you know that you have to download a standard kernel tarball at
  175. \textbf{kernel.org} that matches the version being used by your hardware.
  176. Then you can create a \textbf{diff} file between the two trees, especially for the
  177. following directories:
  178. \begin{verbatim}
  179. diff -urN linux-2.x.x/arch/<sub architecture> linux-2.x.x-modified/arch/<sub architecture> > 01-architecture.patch
  180. diff -urN linux-2.x.x/include/ linux-2.x.x-modified/include > 02-includes.patch
  181. diff -urN linux-2.x.x/drivers/ linux-2.x.x-modified/drivers > 03-drivers.patch
  182. \end{verbatim}
  183. This will constitute a basic set of three patches that are very likely to contain
  184. any needed modifications that has been made to the stock Linux kernel to run on
  185. your specific device. Of course, the content produced by the \textbf{diff -urN}
  186. may not always be relevant, so that you have to clean up those patches to only
  187. let the "must have" code into them.
  188. The first patch will contain all the code that is needed by the board to be
  189. initialized at startup, as well as processor detection and other boot time
  190. specific fixes.
  191. The second patch will contain all useful definitions for that board: addresses,
  192. kernel granularity, redefinitions, processor family and features ...
  193. The third patch may contain drivers for: serial console, ethernet NIC, wireless
  194. NIC, USB NIC ... Most of the time this patch contains nothing else than "glue"
  195. code that has been added to make the binary driver work with the Linux kernel.
  196. This code might not be useful if you plan on writing drivers from scratch for
  197. this hardware.
  198. \subsubsection{Using the device bootloader}
  199. The bootloader is the first program that is started right after your device has
  200. been powered on. This program, can be more or less sophisticated, some do let you
  201. do network booting, USB mass storage booting ... The bootloader is device and
  202. architecture specific, some bootloaders were designed to be universal such as
  203. RedBoot or U-Boot so that you can meet those loaders on totally different
  204. platforms and expect them to behave the same way.
  205. If your device runs a proprietary operating system, you are very likely to deal
  206. with a proprietary boot loader as well. This may not always be a limitation,
  207. some proprietary bootloaders can even have source code available (i.e : Broadcom CFE).
  208. According to the bootloader features, hacking on the device will be more or less
  209. easier. It is very probable that the bootloader, even exotic and rare, has a
  210. documentation somewhere over the Internet. In order to know what will be possible
  211. with your bootloader and the way you are going to hack the device, look over the
  212. following features :
  213. \begin{itemize}
  214. \item does the bootloader allow net booting via bootp/DHCP/NFS or tftp
  215. \item does the bootloader accept loading ELF binaries ?
  216. \item does the bootloader have a kernel/firmware size limitation ?
  217. \item does the bootloader expect a firmware format to be loaded with ?
  218. \item are the loaded files executed from RAM or flash ?
  219. \end{itemize}
  220. Net booting is something very convenient, because you will only have to set up network
  221. booting servers on your development station, and keep the original firmware on the device
  222. till you are sure you can replace it. This also prevents your device from being flashed,
  223. and potentially bricked every time you want to test a modification on the kernel/filesystem.
  224. If your device needs to be flashed every time you load a firmware, the bootlader might
  225. only accept a specific firmware format to be loaded, so that you will have to
  226. understand the firmware format as well.
  227. \subsubsection{Making binary drivers work}
  228. As we have explained before, manufacturers do release binary drivers in their GPL
  229. tarball. When those drivers are statically linked into the kernel, they become GPL
  230. as well, fortunately or unfortunately, most of the drivers are not statically linked.
  231. This anyway lets you a chance to dynamically link the driver with the current kernel
  232. version, and try to make them work together.
  233. This is one of the most tricky and grey part of the fully open source projects.
  234. Some drivers require few modifications to be working with your custom kernel,
  235. because they worked with an earlier kernel, and few modifications have been made
  236. to the kernel in-between those versions. This is for instance the case with the
  237. binary driver of the Broadcom BCM43xx Wireless Chipsets, where only few differences
  238. were made to the network interface structures.
  239. Some general principles can be applied no matter which kernel version is used in
  240. order to make binary drivers work with your custom kernel:
  241. \begin{itemize}
  242. \item turn on kernel debugging features such as:
  243. \begin{itemize}
  244. \item CONFIG\_DEBUG\_KERNEL
  245. \item CONFIG\_DETECT\_SOFTLOCKUP
  246. \item CONFIG\_DEBUG\_KOBJECT
  247. \item CONFIG\_KALLSYMS
  248. \item CONFIG\_KALLSYMS\_ALL
  249. \end{itemize}
  250. \item link binary drivers when possible to the current kernel version
  251. \item try to load those binary drivers
  252. \item catch the lockups and understand them
  253. \end{itemize}
  254. Most of the time, loading binary drivers will fail, and generate a kernel oops.
  255. You can know the last symbol the binary drivers attempted to use, and see in the
  256. kernel headers file, if you do not have to move some structures field before or
  257. after that symbol in order to keep compatibily with both the binary driver and
  258. the stock kernel drivers.
  259. \subsubsection{Understanding the firmware format}
  260. You might want to understand the firmware format, even if you are not yet capable
  261. of running a custom firmware on your device, because this is sometimes a blocking
  262. part of the flashing process.
  263. A firmware format is most of the time composed of the following fields:
  264. \begin{itemize}
  265. \item header, containing a firmware version and additional fields: Vendor, Hardware version ...
  266. \item CRC32 checksum on either the whole file or just part of it
  267. \item Binary and/or compressed kernel image
  268. \item Binary and/or compressed root filesystem image
  269. \item potential garbage
  270. \end{itemize}
  271. Once you have figured out how the firmware format is partitioned, you will have
  272. to write your own tool that produces valid firmware binaries. One thing to be very
  273. careful here is the endianness of either the machine that produces the binary
  274. firmware and the device that will be flashed using this binary firmware.
  275. \subsubsection{Writing a flash map driver}
  276. The flash map driver has an important role in making your custom firmware work
  277. because it is responsible of mapping the correct flash regions and associated
  278. rights to specific parts of the system such as: bootloader, kernel, user filesystem.
  279. Writing your own flash map driver is not really a hard task once you know how your
  280. firmware image and flash is structured. You will find below a commented example
  281. that covers the case of the device where the bootloader can pass to the kernel its partition plan.
  282. First of all, you need to make your flash map driver be visible in the kernel
  283. configuration options, this can be done by editing the file \
  284. \textbf{linux/drivers/mtd/maps/Kconfig}:
  285. \begin{verbatim}
  286. config MTD_DEVICE_FLASH
  287. tristate "Device Flash device"
  288. depends on ARCHITECTURE && DEVICE
  289. help
  290. Flash memory access on DEVICE boards. Currently only works with
  291. Bootloader Foo and Bootloader Bar.
  292. \end{verbatim}
  293. Then add your source file to the \textbf{linux/drivers/mtd/maps/Makefile}, so
  294. that it will be compiled along with the kernel.
  295. \begin{verbatim}
  296. obj-\$(CONFIG_MTD_DEVICE_FLASH) += device-flash.o
  297. \end{verbatim}
  298. You can then write the kernel driver itself, by creating a
  299. \textbf{linux/drivers/mtd/maps/device-flash.c} C source file.
  300. \begin{verbatim}
  301. // Includes that are required for the flash map driver to know of the prototypes:
  302. #include <asm/io.h>
  303. #include <linux/init.h>
  304. #include <linux/kernel.h>
  305. #include <linux/mtd/map.h>
  306. #include <linux/mtd/mtd.h>
  307. #include <linux/mtd/partitions.h>
  308. #include <linux/vmalloc.h>
  309. // Put some flash map definitions here:
  310. #define WINDOW_ADDR 0x1FC00000 /* Real address of the flash */
  311. #define WINDOW_SIZE 0x400000 /* Size of flash */
  312. #define BUSWIDTH 2 /* Buswidth */
  313. static void __exit device_mtd_cleanup(void);
  314. static struct mtd_info *device_mtd_info;
  315. static struct map_info devicd_map = {
  316. .name = "device",
  317. .size = WINDOW_SIZE,
  318. .bankwidth = BUSWIDTH,
  319. .phys = WINDOW_ADDR,
  320. };
  321. static int __init device_mtd_init(void)
  322. {
  323. // Display that we found a flash map device
  324. printk("device: 0x\%08x at 0x\%08x\n", WINDOW_SIZE, WINDOW_ADDR);
  325. // Remap the device address to a kernel address
  326. device_map.virt = ioremap(WINDOW_ADDR, WINDOW_SIZE);
  327. // If impossible to remap, exit with the EIO error
  328. if (!device_map.virt) {
  329. printk("device: Failed to ioremap\n");
  330. return -EIO;
  331. }
  332. // Initialize the device map
  333. simple_map_init(&device_map);
  334. /* MTD informations are closely linked to the flash map device
  335. you might also use "jedec_probe" "amd_probe" or "intel_probe" */
  336. device_mtd_info = do_map_probe("cfi_probe", &device_map);
  337. if (device_mtd_info) {
  338. device_mtd_info->owner = THIS_MODULE;
  339. int parsed_nr_parts = 0;
  340. // We try here to use the partition schema provided by the bootloader specific code
  341. if (parsed_nr_parts == 0) {
  342. int ret = parse_bootloader_partitions(device_mtd_info, &parsed_parts, 0);
  343. if (ret > 0) {
  344. part_type = "BootLoader";
  345. parsed_nr_parts = ret;
  346. }
  347. }
  348. add_mtd_partitions(devicd_mtd_info, parsed_parts, parsed_nr_parts);
  349. return 0;
  350. }
  351. iounmap(device_map.virt);
  352. return -ENXIO;
  353. }
  354. // This function will make the driver clean up the MTD device mapping
  355. static void __exit device_mtd_cleanup(void)
  356. {
  357. // If we found a MTD device before
  358. if (device_mtd_info) {
  359. // Delete every partitions
  360. del_mtd_partitions(device_mtd_info);
  361. // Delete the associated map
  362. map_destroy(device_mtd_info);
  363. }
  364. // If the virtual address is already in use
  365. if (device_map.virt) {
  366. // Unmap the physical address to a kernel space address
  367. iounmap(device_map.virt);
  368. // Reset the structure field
  369. device_map.virt = 0;
  370. }
  371. }
  372. // Macros that indicate which function is called on loading/unloading the module
  373. module_init(device_mtd_init);
  374. module_exit(device_mtd_cleanup);
  375. // Macros defining license and author, parameters can be defined here too.
  376. MODULE_LICENSE("GPL");
  377. MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
  378. \end{verbatim}
  379. \subsection{Adding your target in OpenWrt}
  380. Once you spotted the key changes that were made to the Linux kernel
  381. to support your target, you will want to create a target in OpenWrt
  382. for your hardware. This can be useful to benefit from the toolchain
  383. that OpenWrt builds as well as the resulting user-space and kernel
  384. configuration options.
  385. Provided that your target is already known to OpenWrt, it will be
  386. as simple as creating a \texttt{target/linux/board} directory
  387. where you will be creating the following directories and files.
  388. Here for example, is a \texttt{target/linux/board/Makefile}:
  389. \begin{Verbatim}[frame=single,numbers=left]
  390. #
  391. # Copyright (C) 2009 OpenWrt.org
  392. #
  393. # This is free software, licensed under the GNU General Public License v2.
  394. # See /LICENSE for more information.
  395. #
  396. include $(TOPDIR)/rules.mk
  397. ARCH:=mips
  398. BOARD:=board
  399. BOARDNAME:=Eval board
  400. FEATURES:=squashfs jffs2 pci usb
  401. LINUX_VERSION:=2.6.27.10
  402. include $(INCLUDE_DIR)/target.mk
  403. DEFAULT_PACKAGES += hostapd-mini
  404. define Target/Description
  405. Build firmware images for Evaluation board
  406. endef
  407. $(eval $(call BuildTarget))
  408. \end{Verbatim}
  409. \begin{itemize}
  410. \item \texttt{ARCH} \\
  411. The name of the architecture known by Linux and uClibc
  412. \item \texttt{BOARD} \\
  413. The name of your board that will be used as a package and build directory identifier
  414. \item \texttt{BOARDNAME} \\
  415. Expanded name that will appear in menuconfig
  416. \item \texttt{FEATURES} \\
  417. Set of features to build filesystem images, USB, PCI, VIDEO kernel support
  418. \item \texttt{LINUX\_VERSION} \\
  419. Linux kernel version to use for this target
  420. \item \texttt{DEFAULT\_PACKAGES} \\
  421. Set of packages to be built by default
  422. \end{itemize}
  423. 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/}.
  424. This kernel configuration will only contain the relevant symbols to support your target and can be changed using \texttt{make kernel\_menuconfig}.
  425. 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
  426. 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}
  427. with the same directory structure that the kernel uses (e.g: drivers/mtd/maps, arch/mips ..).
  428. The build system will require you to create a \texttt{target/linux/board/image/Makefile}:
  429. \begin{Verbatim}[frame=single,numbers=left]
  430. #
  431. # Copyright (C) 2009 OpenWrt.org
  432. #
  433. # This is free software, licensed under the GNU General Public License v2.
  434. # See /LICENSE for more information.
  435. #
  436. include $(TOPDIR)/rules.mk
  437. include $(INCLUDE_DIR)/image.mk
  438. define Image/BuildKernel
  439. cp $(KDIR)/vmlinux.elf $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.elf
  440. gzip -9n -c $(KDIR)/vmlinux > $(KDIR)/vmlinux.bin.gz
  441. $(STAGING_DIR_HOST)/bin/lzma e $(KDIR)/vmlinux $(KDIR)/vmlinux.bin.l7
  442. dd if=$(KDIR)/vmlinux.bin.l7 of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma bs=65536 conv=sync
  443. dd if=$(KDIR)/vmlinux.bin.gz of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.gz bs=65536 conv=sync
  444. endef
  445. define Image/Build/squashfs
  446. $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
  447. endef
  448. define Image/Build
  449. $(call Image/Build/$(1))
  450. dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/openwrt-$(BOARD)-root.$(1) bs=128k conv=sync
  451. -$(STAGING_DIR_HOST)/bin/mkfwimage \
  452. -B XS2 -v XS2.ar2316.OpenWrt \
  453. -k $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma \
  454. -r $(BIN_DIR)/openwrt-$(BOARD)-root.$(1) \
  455. -o $(BIN_DIR)/openwrt-$(BOARD)-ubnt2-$(1).bin
  456. endef
  457. $(eval $(call BuildImage))
  458. \end{Verbatim}
  459. \begin{itemize}
  460. \item \texttt{Image/BuildKernel} \\
  461. This template defines changes to be made to the ELF kernel file
  462. \item \texttt{Image/Build} \\
  463. This template defines the final changes to apply to the rootfs and kernel, either combined or separated
  464. firmware creation tools can be called here as well.
  465. \end{itemize}