buildroot manual中文

buildroot manual中文翻译版，制作嵌入式系统文件系统和内核6282如何从ghub中添加个软件包6.29结论6.3修补一个包7法律通知和许可7.1遵守开放源码许可8 Buildroot之外8.1 Boot the generated images引导生成的图像8.1.1NFS的引导82 Chroot改变根目录9加入我们1。 About buildrootBuildroot是使用交叉编译,为嵌入式系统搭建一个完整的iux系统的工具,操作简单,自动。为了实现这一点, Buildroot够生成一个交叉编泽的工具链、一个根文件系统、一个 Linux内核映像和一个 bootlader为核心板。 Buildroot可以单独使用这些选项的任何组合(例如,您可以使用—个外部的交叉编译工具链,并且只用 Buildroot构建根文件系统)Buildroot主要适用于使用嵌入式系统的人员。嵌入式系统通常使用的处理器不是普通的x86处理器,每个人都习惯在他的电脑上使用。它们可以是 PowerPC处理器,MPS处理器,ARM处理器等。Buildroot攴持大量的处理器和它们的变体;它还提供了几个现成的可用的板子的默认配置。除此之外,许多第三方项目都是基于 Buildroot上的BSP或SDK开发或修改的。BSP: Board Support PackageSDK: Software Development Kit2、 Starting up启动21 System requirements系统需求builtroot是为在nux系统上运行而设计的Buildroot需要在主机系统上安装一些软件以下是强制性和可选的列表软件(软件名在发行版之间可能有所不同)2.1.1 Mandatory packagesBuild tools.make (version 3. 81 or any later)binutilsbuild-essential (only for Debian based systems)gcc (version 2. 95 or any later)g++(version 2. 95 or any laterbashpagzipbzip2ppy thon (version 2.6 or 2.7)unziprsyncSource fetching toolsget212 Optional packages选择软件源码获取工具在官方树中,大多数源码都是使用wge来获取;小部分只有通过他们的gt, mercuria,或者svn储存库。所有其他源抓取方法都被实现,并且可以在开发环境中使用(进一步的细节:参考第6.4节)。tmercurialSCpSubversionConfiguration interface dependencies (requires development libraries配置接口依赖关系(需要开发库):ncurses5 to use the menuconfig interfaceqt4 to use the xconfig interfaceglib2, gtk2 and glade to use the config interface与Java相关的包,如果需要为目标系统构建Java类路径:The javac compilerThe文档生成工具asciidoc2.2 Getting BuildrootBuildroot的版本大约每3个月发布一次。如果您想要更新的,直接的Gti访问和毎日快照也是可用的。发布的正式版本可在htp;/ buildroot net/downloads/上获得。最新的快照总是可以在http://buildroot.net/downloads/snapsho/buildroot-snapshot.tarbz2上找到。以前的快照也可以在htt/ buildroot. net/downloads/snapshots中找到。要使用Gt下载 Buildroot,您可以简单地遵循“访问Gt"页面上描述的规则(htp:/ buildroot.net- git. htm)构建droo网站(http://buildroot.net)对于那些没有耐心的人来说,这里有一个简单的方法S git clone git: //git buildroot. net/buildroot2.3 Using BuildrootBuildroot有一个很好的配置工具,类似于你在Lnux内核或 Busybox中使用的配置工具。注意,你应该使用一个普通用户来对所有软件编译。不需要roo权限来配置和使用 Buildroot。第-一步是运行配置:S make menuconfig运行 curses- based配置器orS make xconfigO工S make config运行Q域基于g配置的配置器所有这些make"命令都需要构建一个配置实用程序(包括接口),所以您可能需要安装“开发”包,用于配置实用程序使用的相关库。检査第2.1节,了解什么是 Buildroot需求,特别是可选的需求第2.1.2,以获得您喜欢的接口的依赖关系。对于配置工具中的每个菜单条目,您可以找到相关的帮助来描述条目的目的配置工具一旦配置好,配置工具就会生成一个 config文件,其中包含对配置的描述。它将被 makefile用来做需要的事情。然后执行make你永远不应该使用內置的make-jN:它不支持top- clevel parallel make。相反使用BR2 JLEVEL选择告诉 Buildroot使用make小N运行每个软件包编译。make命令通常执行以下步骤·下载源文件(按要求);配置、构建和安装使用适当的工貝链后端的交叉编译工具链,或者简单地导入外部工具链;·编译/安装选定的目标包;如果选择的话,建立一个内核映像如果选择的话,建立一个引导加载程序映像以选定的格式创建根文件系统。Buildroot输出存储在单个目录下, output/。这个目录包含几个子目录mages所有映像(内核映像、 bootloader和根文件系统映像)存储目录。ˉ build/除了交叉编译的工具链之外的所有组件,编译(这包括运行所需的工具在主机上的 Buildroo和为目标编译的包)。 build目录包含每个组件的一个子目录。staging其中的层次结构类似于根文件系统层次结构。这个目录包含了安装交叉编译工具链和为目标选择的所有用户空间包。但是,这个目录不是用来成为目标的根文件系统:它包含许多开发文件、未剥离的二进制文件和库,这些文件和库也非常多。对嵌入式系统来说是很大的。这些开发文件用于为所依赖的目标提供编译库和应用程序需要的其他库targ它几乎包含了目标的完鏊根文件系统:除了/ev目录中的设备文件,所有需要的东西都是存在( Buildroot不能创建它们因为 Buildr0伓不会以roo身份运行,也不希望以oo身份运行)。此外,它没有正确的权限(例如, busybox二进制文件的setuid)。因此,该目录不应该用于你的目标。相反,您应该使用 Images/目录中构建的映像之一。如果你霈要在根文件系统中用NFS挂载外部镜像,必须用root用户在 Images/目录中生成镜像。相比对于 staging/, target/只包含运行所选目标应用程序所需的文件和库:开发文件(头文件)不存在,二进制文件被剥离。ˉhost包含为主机编译的工具的安装,这些工具是正确执行 Buildroot所必需的,包括交叉编译工具链。toolchain/包含交叉编译工具链的各个组件的构建目录。这些命令,使用 make menuconfig I config| xconfig和make成为最基本的命令,可以轻松快速地生成适合您的需求的 mages,以及您启用的所有支持和应用程序。关于make"命令用法的更多细节在第3.2节中给出。3、 Working with Buildroot使用 Buildroot本节解释如何定制 Buildr以满足您的需要31关于 Buildroot配置的详细信息make* config中的所有配置选项都有一个帮助文本,提供关于选项的详细信息。然而,许多主题需要额外的细节,这些细节在帮助文本中不容易被覆盖,并且在以下部分中涉及到31.1交叉编译工具链编译工具链是一组工具,它允许您为系统编译代码。它由一个编译器组成(在我们的例,gcc),像汇编程序和链接器(在我们的例子中是 binutils)和C标准库(例如 GNU Libc, u Cibc)。Buildroot需要安装在已经安装好编译工具,并囯编译的应用程序能正常运行的环境中。如果你用的是PC,您的编译工具链运行在×86处理器上并生成×86处理器运行的代码。在大多数 Linux系统下编译工具链使用 GNU libc(gibc)作为标准C库。这个编译工具链称为“主机编译工具链。它运行工作的机器,被称为”主机系统编译工具链是由您的发行版提供的,而 Buildroot与它没有任何关系(除了使用它来构建一个交叉编译工具链和在开发主机上运行的其他工具)。正如上面说的,你电脑上的编译器生成的代码运行在你的电脑上。嵌入式系统有不同的处理器时,您需要一个交叉编译的工具链个编译工具链。交叉编译工具运行在你的电脑上,但生成的代码运行在你的目标板上。例如,如果你的主机系统使用x86和您的目标系统使用ARM,主机上的常规编译工具链在x86上运行,并生成x86代码,而交叉编译的工具链在x86上运行,并为ARM生成代码。Buildroot提供了不同的构建解决方案,或者使用现有的交叉编译工具链ˉ内部工具链后端,在配置界面中称为 Buildroot工具链。外部工具链后端,在配置界面中称为外部工具链。·在配置界面中称为交叉工具链的工具链后端。这三个解决方案之间的选择是在工具链菜单中使用工具链类型选项完成的。一旦一个已经选择了解决方案,出现了许多配置选项,它们在以下部分中详细介绍。3.1.1.1内部工具链端内部工具链后端是内置的后端,在构建之前, Buildr自己构建了一个交叉编译的工具链。用于目标嵌入式系统的用户空间应用程序和库这个后端是 Buildroot的历史后端,并且仅限于 u Cibc c库的使用(ie, glibly和 eglibc c库不受此后端支持,请参阅外部工具链后端和跨界工貝链后端解决方案使用glic或 eglin)。旦您选择了这个后端,就会岀现许多选项。最重要的是:改变用于构建工具链的Linu內核头的版本。这个项目值得—些解释。在构建昑编译工具链的过程,C库已经被枃建了。这个库提供了用户空间应用程序与LnⅨ內核的接口。为了能访问与Lnux内核,C库需要具备访问Liux内核的头文件(来自内核的h文件),它定义了用户空间和内核空间之间的接口函数(系统调用、数据结构等)。由于这个接口是向后兼容的,所以用于编译的inux内核版本和运行在嵌入式系统上的 Linux版本可以不完全—致。它们只需要与您打算运行的 Linux内核版本相同或更老的版本。如果你使用内核版本比您在嵌入式系统上运行的Liux内核更新,使用的C库可能会没有由 Linux内核提供的接口。更改 uClibc c库的版本和配置。默认选项最好。然而如果你真的需要特别定制 uClibc C库的配置,您可以在这里传递一个特定的配置文件。或者,您可以运行 make uclibc- menuconfig命令来访问 uClibc的配置接口。请注意,在 Buildrootl中,所有的包都是在内置的 u click配置中进行测试的:如果您偏离了这个配置通过从 uClibc删除特性,一些包可能不再构建。更改GCC编译器和 binutils的版本ˉ选择一系列工貝链选项∶工具链是否应该有大文件攴持(ⅰ。对大于2GB的文件的支持32位系统上)、支持Pνδ、RPC支持(主要用于NFS)、宽字符攴持、场所支持(用于国际化),支持C十*,多线程编程。根据您选择的选项,用户空间应用程序的数量在 Buildroot楝菜单中可见的库将会改变:许多应用程序和库需要特定的工具链选项启用当需要某种工具链选项来启用这些软件包时,大多数包都显示了注释。值得注意的是,只要其中—个选项被修改,那么整个工具链和系统就必须重新构建。看3.5.1部分。该后台的优点与 Buildroot有良好的兼容性快速,只构建必要的东西这个后台的缺点:在进行清洁工作时,需要重建工具链,这需要时间。如果你想减少你的构建时间,考虑使用外部工具链后端仅限于 uClibc o库31.12外部工具链端外部工具链后端允许使用现有的预构建交叉编译工具链。 Buildroot能识别几种常见的交叉编译工具链(从ARM的 Linaro,ARM的Sourcery Code Bench,x86,x86-64, PowerPC,MPS和 SuperH,来自AD的 Blackfin工具链,Ⅻiinx用于 Microblaze的工具链,等等。)并且能够自动下载它们,或者它可以指向一个自定义的工具链,可以在本地下载或安装。然后,您有三个使用外部工具链的解决方案使用预先定乂的外部工具链概要,让 Buildroot下载、提取和安装工具链。 Buildroot已经知道一些 CodeSourcery, LinaroBlackfin和Xinx的工具链。在工具链中选择工具链配置文件从可用的。这绝对是最简单的解决办法。使用预先定乂的外部工具链配置文件,而不是让 Buildroot下载并提取工具链,在 Buildroot中配置的系统中安装的编译工具的路径在工具链中选择工具链配置文件可用的选项,自动取消选择下载工具链,并填充本地交叉编译工具链的路径。使用一个完全定制的外部工具链。这对于使用 crosstong生成的工具链特别有用。为此在工具链表中选择自定义工具链解决方案。你需要填充工具链路径,工具链前缀和外部工具链C库选项。然后,你必须告诉 Buildroot你的外部工具链支持。如果你的外部工具链使用gibc库,你只需要知道你的工具链是否支持C++以及它是否具有内置RPC支持。如果您的外部工具链使用 uClibc库,那么您必须告诉 Buildroot它是否支持大文件、IPνδ、RPC、宽字符、地区、程序调用、线程和C++。在执行编译前,Buildroot会告诉你,选择的选项是否与工具链配置不匹配。我们的外部工具链支持已经通过 Code sourcer和Lina的工具链进行了测试,由交叉表生成的工具链,以及由 Buildroot己生成的工具链。总之,攴持 sysroot特性的所有工具链都应该工作。如果不是这样尽快与开发人员联系。我们不支持 Denx ElDK的工具链,原因有EDK不包含一个纯粹的工具链(il只是编译器, binutils,C和C艹+库),而是一个工具链有大量的预编译的库和程序。因此, Buildroot不能导入工具链的 sysroot,因为它将包含数百兆字节的预编译库,这些库通常是由 Buildroot构建的ELDK工具链有一个完全非标准的自定义机制来处理多个库变体。而不是使用标准的 GCC multilib机制, ARM ELDK使用不同的符号链接到编译器来区分库的变体(用于ARM软oa和 ARM VEP)和 PowerPC ELDK编译器使用交叉编译环境变量。这种不规范的行为使得在 Buildroot上很难支持ELDKε我们也不支持使用发行版安装的工具链(i。由您的发行版安装的gcc/ binutils库)为目标构建软件的工具链。这是因为发行版安装的工具链不是一个“纯"的工貝链(i。e只有c/c++库),所以我们不能将它正确地导入到 Buildr构建环境中。所以即使你在建立一个系统对于x86或x8664目标,您必须生成一个带有 Buildroot或 crosstong的交叉编译工具链。如果您想为您的项目生成一个定制的工具链,那么它可以作为一个外部工具链在 Buildroot中使用,我们的重新使用肯定是用跨界的方法构建它。我们建议将工具链与 Buildroot分开,然后在 Buildroot中使用外部工具链后端导入它。该后台的优点:允许使用知名的、经过良好测试的交叉编译工具链ˉ避免交叉编译工具链的构建时间,这在嵌入式 Linux系统的总体构建时间中通常非常重要。不局限于 uClibo:gibc和 eglibc工具链得到了支持。这个后台的缺点:如果你的预构建的外部工具链有缺啗,可能很难从工具链倛应商那里得到解决方案,除非你构建外部工具使用交叉的工具链。3.1.13 CrosstooL-NG工具链端跨平台的工具链后端将跨平台的项目与 Buildroot集成在一起。 Crosstab-NG是高度可配置的,多用途和维护良好的工具来构建交叉编译的工具链。如果你在工具链选项中选择了跨平台的工具链,那么你将被提供给:选择你想要使用的C库。 Crosstool-NG支持 Linux系统中使用的三个最重雯的C库: glibc, eglibc uclibcˉ选择一个定制的跨界配置文件。 Bulldogυt有自己的默认配置文件〔毎个￠库选择一个),但你可以提供你自己的。另一种选择是运行ctng- menuconfig来访问 Crosstool-NG。配置界面。但是,请注意,所有的 Buildroot包都只经过默认的跨界配置测试。ˉ选择一系列的工貝链选项(如果使用gibc或 eglibc,或者使用 uClibc,则相当有限)当您开始构建 Buildroot构建过程时, Buildroot将下载并安装 Crosstab-NG工具,构建并安装它所需的依赖关系,然后使用所提供的配置运行 Crosstab|NG。该后台的优点:不局限于 u Clio:gibc和 eglibo得到支持。对工具链结构的巨大可能性。这个后台的缺点:ˉ Crosstool-NG并没有与 Buildr垸完美地集成。例如, Crosstab-NG有自己的下载基础设施,不是集成了 Buildroot中的一个(例如,一个 Buildroot make source不会下载所有的源代码 Tarbat需要通过 Crosstool-NG)如果你做了清洁工作,工具链就会从头开始重建。31.2/dev管理在 Linux系统上,ldev目录包含特殊文件,称为设备文件,允许用户空间应用程序访问由 Linux内核管理的硬件设备。如果没有这些设备文件,您的用户空间应用程序将无法使用硬件设备,即使它们被 Linux内核正确地识别。在系统配置/deν管理下, Buildroot提供了四种不同的解决方案来处理/σeν目录:第一个解决方案是静态使用设备表 Static using device table。这是在Liuκ中处理设备文件的经典方法。用这种方法,设备文件不随设备重启而发生改变(i. e they persist accross reboots),当硬件设备被添加或从系统中删除时没有什么可以自动创建和删除这些设备文件。因此 Buildroot使用存储在 Buildroot源代码中 system/device table_ dev, txt设备表创建一组标准的设备文件。当Buildroot生成最终根文件系统映像时,会处理该文件,因此,设备文件在 output/target目录中是不可见的。BR2 ROOTES_ STATIC_DEⅥCE_ TABLE选项允许更改 Buildroot使用的默认设备表,或者添加一个额外的设备表,因此额外的设备文件是在构建期问由 Buildroot创建的。所以,如果你使用这个方法,你的系统中缺少一个设备文件,你可以创建board∥ device table deⅸt文件包含了描述您的附加设备文件,然后你可以设置BR2 ROOTFS_ STATIC DEVICE TABLE为system/device table dev. txt board/ device table dev txt更多关于设备表文件的格式的细节,参见第111第二个解决方案仅使用动态的 devtmpfs Dynamic using devtmpfs only。 devtmpfs是Liux内核中的一个虚拟文件系统在2.6.32内核中引入(如果您使用的是较旧的內核,则不可能使用此选项)。被挂载到/deν路径后,这个虚拟的文件系统会根据系统中的硬件添加和删除自动的创建设备文件和删除设备文件。设备重启后这个文件系统不是固定不变的,由内核来动态的加载。使用devtmpfs功能需要配置内核 CONFIG_DEⅥ TMPFS和 CONFIG_DEⅥ TMPFS MOUNT选项使能。当 Buildroot负责为嵌入式设备构建Lnux內核,它确保这两个选项是启用的。但是,如果您在 Buildroot之外构建您的Liuκ内核,启用这两个选项会影响你的功能(如果您如果不这样做,您的 Buildroot系统将不会启动)。第三个解决方案是使用mdev进行动态处理 Dynamic using mdev。这个方法还依赖于上面详细介绍的 devtmpfs虚拟文件系统(仍需要在内核配置中启用 CONFIG DEVTMPFS和 CONFIG DEⅥ TMPFS MOUNT选项)。但是在它上面添加了mdev用户空间实用程序。mdev是 BusyboxF的一个程序部分,内核每次都调用它设备被添加或删除。由于/ etc/mdev. conf,例如可以将配置ndev为在设备文件上设置特定的权限或所有权,当设备出现或消失时调用脚本或应用程序等等。基本上,它允许用户空间对设备添加和删除事件作出反应。当系统上有设备岀现在时,mdeν可以自动地加载内核模块。如果你有需要固件的设备,mdev也很重要,因为它将负责将固件内容推送到內核中。mdeν是一个轻量级的实现(减少了udev的特性)。有关mdev的更多细节以及其配置文件的语法见 docs/mdev. txt第四种解决方案是使用udev进行动态处理 Dynamic using udev。这个方法还依赖于上面详细介绍的 devtmpfs,虚拟文件系统,但在上面添加udev用户空间守护进程。υdeν是—个在后台运行的守护进程,当—个设备被添加或从系统中移除时它就会被内核调用。它是比mdeν更重量级的解决方案,但是提供了更高的解决方案灵活性,有时对于某些系统组件(例如 systemd)是强制性的。udev是用于大多数桌面Lnux发行版。关于udev的更多细节见UdevBuildroot的开发者推荐 Dynamic using devtmpfs only解决方案,直到你有了需要为了让用户空间在设备被增加删除时被通知,或者需要固件时,在这种情况下 Dynamic using mdev通常一个好的解决方案。31.3系统初始化 init systemn程序是由内核启动的第一个用户空间程序(它的P|D为1),并负责开始用户空间服务和程序(例如:web服务器、图形应用程序、其他网络服务器等)。Buildroot允许使用三种不同类型的ini系统,它可以从系统配置中选择, Init system:第一个解决方案是 Busybox。在许多程序中, Busybox都有一个基本的n程序的实现,对于大多数嵌入式系统来说已经足够了。启用BR2 INIT BUSYBOX将确保 Busybox能够构建和安装它iηit程序。这是 Buildroot的默认解决方案。 Busybox init程序将读取 etc/inittab文件引导你知道该做什么。这个文件的语法可以在htp:/ it busybox. net/busybox/tre/examples/inittab中找到(请注意 Busybox inittab语法很特别:不要使用来自 iNterne的随机 inittab文档来了解 Busybox inittab)。 Buildroot中的默认 inittab存储在system/skeleton/etc/inittab中。除了挂载一些重要的文件系统,默认的 minitab所做的主要工作是启动 letc/init. d/rcs shel脚本,并启动gety程序(提供登录提示)第二种解决方案是← systemν。这个解决方案使用传统的sysv程序,内置在 Buildσo的 package/sysⅶini中。这是大多数桌面Linux发行版中使用的解决方案,直到他们转向更近期的替代方案比如 Upstart或 Systemd。sysⅶn还可以使用 inittab文件(它的语法与 Busybox略有不同)。安装了这个in解决方案的默认 Minitab位于 package/ sysvinit/inittab。ˆ第三个解决方案是* systenσ system是用于Liυx的新-代init系统。它比传统的ηi程序更重要:积极的并行化能力,使用套接字和D-Bυs激活启动服务,按需提供启动守护进程,跟踪使用Liux控制组的进程,支持系统的快照和恢复状态等。 system将在相对复杂的嵌入式系统中很有用,例如需要D-Bus的系统服务之间相互通信。值得注薏的是, systemd带来了相当大的依赖项:dbus,gb和更多。关于systemd的更多细节,见htp:/www.freedesktop.org/wiki./Software/systemdBuildroot开发人员推荐的解决方案是使用 Busybox init,因为它对于大多数嵌入式系统来说已经足够了。 systemd可用于更复杂的情况。32使用技巧这是一组帮助你充分利用 Buildr均的技巧。配置搜索:make' config命令提供一个搜索工具。阅读不同菜单的帮助信息能知道如何使用它在 menuconfig中,搜索工具按在 xconfig中,通过按Crl+f调用搜索工具。搜索的结果显示了匹配项的帮助消息。显示由make执行的所有命令:S make V=l 显示所有可用的目标并不是所有的目标都是可用的, config文件中的一些设置可能隐藏一些目标linux-menuconfig和 linux-savedefconfig只能在启用inux时起作用;uclibc- menuconfig只有在使用 Buildroot内部工具链后端可用时才可用;ctng- menuconfig只有在使用交叉编译后才可用ˉ barebox- menuconfig和 barebox-savedefconfig只能在启用 barebox引导加载程序时起作用Cleaning:当任何架构或工具链配置选项发生更改时,都需要显式清洗。要删除所有构建产品(包括构建目录、主机、 staging和 target trees、 Images和 toolchain):S make clean要删除所有构建产品以及配置:S make distclean注意,如果 ccache被启用,运行 make clean或 distclean不会清空 Buildroot所使用的编译器缓存。要删除它,请参阅第522节。