SF36-16和SF18-12方案_百度文库
赠送免券下载特权
10W篇文档免费专享
部分付费文档8折起
每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
SF36-16和SF18-12方案
&&条式线圈与圈式线圈的电磁方案
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩1页未读，
定制HR最喜欢的简历
你可能喜欢[EAX]+disp8
[ECX]+disp8
[EDX]+disp8
[EBX]+disp8
[EBP]+disp8
[ESI]+disp8
[EDI]+disp8
[EAX]+disp32
[ECX]+disp32
[EDX]+disp32
[EBX]+disp32
[EBP]+disp32
[ESI]+disp32
[EDI]+disp32
AL/AX/EAX/ST0/MM0/XMM0
CL/CX/ECX/ST1/MM1/XMM1
DL/DX/EDX/ST2/MM2/XMM2
BL/BX/EBX/ST3/MM3/XMM3
AH/SP/ESP/ST4/MM4/XMM4
CH/BP/EBP/ST5/MM5/XMM5
DH/SI/ESI/ST6/MM6/XMM6
BH/DI/EDI/ST7/MM7/XMM7
(In decimal) Base =
(In binary) Base =
Scaled Index
Value of SIB Byte (in Hexadecimal)
EBP+disp32
(In decimal) /digit (Opcode)
(In binary) REG =
Effective Address
Value of ModR/M Byte (in Hex)
[BX+SI]+disp8
[BX+DI]+disp8
[BP+SI]+disp8
[BP+DI]+disp8
[SI]+disp8
[DI]+disp8
[BP]+disp8
[BX]+disp8
[BX+SI]+disp16
[BX+DI]+disp16
[BP+SI]+disp16
[BP+DI]+disp16
[SI]+disp16
[DI]+disp16
[BP]+disp16
[BX]+disp16
AL/AX/EAX/ST0/MM0/XMM0
CL/CX/ECX/ST1/MM1/XMM1
DL/DX/EDX/ST2/MM2/XMM2
BL/BX/EBX/ST3/MM3/XMM3
AH/SP/ESP/ST4/MM4/XMM4
CH/BP/EBP/ST5/MM5/XMM5
DH/SI/ESI/ST6/MM6/XMM6
BH/DI/EDI/ST7/MM7/XMM7
References to debug registers DR4 and DR5 cause an undefined opcode (#UD) exception to be generated when CR4.DE[bit 3] (Debugging Extensions) when clear, processor aliases references to registers DR4 and DR5 to DR6 and DR7 for compatibility with software written to run on earlier IA-32 processors.
Your Notes:拒绝访问 | china.globrand.com | 百度云加速
请打开cookies.
此网站 (china.globrand.com) 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(41fbb1d95e9a4517-ua98).
重新安装浏览器，或使用别的浏览器10.2, 10.3 (32 Bit);
OpenSUSE 11.0 (32 and 64 Bit)
3.0 (Woody), 3.1 (Sarge) and 4.0 (Etch)
4.10, 5.04, 6.10, 8.04, 9.04, 9.10, 10.04
Users also reported successful installation and use of the
the following host systems:
Linux 7.2, 7.3
Linux 2006.1
Note: It may be necessary, and is usually recommended, to install the
latest available software updates on your host system. For example, on
systems, you can use yum or dnf to keep your systems current.
for ARM systems supports processors complying with the ARM architecture version 2 to 6.
This includes ARM7, ARM9, XScale, AT91RM9200, i.MX31, S3C6400 and other ARM based systems.
The version of 4.2 and higher of
has two ARM targets in distribution - one with the soft-float
math support, and another one with the Vector Floating Point math support. Both targets comply with
ARM Embedded Application Binary Interface ().
ARM target architectures are:
arm-linux = soft-float math
armVFP-linux = Vector Floating Point (VFP) math
There is also an
and MIPS systems.
Stable versions of the
are distributed in the form of an ISO
image, which can be either burned onto a DVD or mounted directly,
using the loopback Linux device driver (Linux host only).
Development versions of the
are available as directory trees so
it is easy to update instructions for download
of these trees and creation of ISO images from it is described in section
contains an installation utility and a number of RPM
packages, which are installed onto the hard disk of the cross
development host by the installation procedure. The RPM packages can
be logically divided into two parts:
Embedded Linux Development Tools (ELDT)
Target components
The first part contains the cross development tools that are executed
on the host system. Most notably, these are the GNU cross compiler,
binutils, and gdb. For a full list of the provided ELDT packages,
refer to section
The target components are pre-built tools and libraries which are
executed on the target system. The
includes necessary target
components to provide a minimal working NFS-based environment for the
target system. For a list of the target packages included in the
, refer to section
contains several independent sets of the target packages, one
for each supported target
family. Each set has been built using
compiler code generation and optimization options specific to the
respective target
You can either download the ready-to-burn ISO-images from one of the mirror sites
or you can download the individual files of the
from the development directory tree and either use these directly for installation
or create an ISO image that can be burned on DVD-ROM.
Change to a directory with suffic for the
ARM version of the
you need about 510 MiB, or twice as much (1.1 GiB)
if you also want to create an ISO image in this directory.
To download the ISO image from the
arm-linux-x86/iso
directory of one of the
mirror sites you can use standard tools like wget or ncftpget,
for example:
bash$ wget ftp://ftp.sunet.se/pub/Linux/distributions/eldk/4.2/arm-linux-x86/iso/arm-.iso
If you want to download the whole
directory tree instead you can - for example -
use the ncftp
bash$ ncftp ftp.sunet.se
ncftp / & cd /pub/Linux/distributions/eldk/4.2
ncftp /pub/Linux/distributions/eldk/4.2 & bin
ncftp /pub/Linux/distributions/eldk/4.2 & get -R arm-linux-x86/distribution
ncftp /pub/Linux/distributions/eldk/4.2 & bye
If you don't find the ncftp tool on your system you can download
the NcFTP client from
There are a few executable files (binaries and scripts) in the
tree. Make sure they have the execute permissions set in your local
bash$ for file in \
tools/bin/rpm \
tools/usr/lib/rpm/rpmd \
ELDK_MAKEDEV \
ELDK_FIXOWNER
& chmod +x arm-linux-x86/distribution/$file
Now create an ISO image from the directory tree:
bash$ mkisofs \
& -A "ELDK-4.2 -- Target: ARM -- Host: x86 Linux" \
& -publisher "(C) `date "+%Y"` DENX Software Engineering,
www.denx.de" \
& -p "`id -nu`@`hostname` -- `date`" \
& -V arm-linux-x86 \
& -l -J -R -o eldk-arm-linux-x86.iso arm-linux-x86/distribution
This will create an ISO image
eldk-arm-linux-x86.iso
in your local directory
that can be burned on DVD or mounted using the loopback device and
used for installation as described above. Of course you can use the
local copy of the directory tree directly for the installation, too.
Please refer to section
for instructions on obtaining the
build environment needed to re-build the
from scratch.
The initial installation is performed using the install utility
located in the root of the
ISO image directory tree. The install
utility has the following syntax:
$ ./install [-d &dir&] [&cpu_family1&] [&cpu_family2&] ...
Specifies the root directory of the
being installed. If omitted, the
goes into the current directory.
&cpu_family&
Specifies the target
family the user desires to install. If one or more &cpu_family& parameters are specified, only the target components specific to the respective
families are installed onto the host. If omitted, the target components for all supported target
families are installed.
Note: Make sure that the "exec" option to the mount command is in effect when mounting the
ISO image. Otherwise the install program cannot be executed. On some distributions, it may be necessary to modify the /etc/fstab file, adding the "exec" mount option to the cdrom entry - it may also be the case that other existing mount options, such as "user" prevent a particular configuration from mounting the
DVD with appropriate "exec" permission. In such cases, consult your distribution documentation or mount the DVD explicitly using a command such as "sudo mount -o exec /dev/cdrom /mnt/cdrom" (sudo allows regular users to run certain privileged commands but may not be configured - run the previous command as root without "sudo" in the case that "sudo" has not been setup for use on your particular GNU/Linux system).
You can install the
to any empty directory you wish, the only
requirement being that you have to have write and execute permissions
on the directory. The installation process does not require
superuser privileges.
Depending on the parameters the install utility is invoked with, it
installs one or more sets of target components. The ELDT packages are
installed in any case.
Refer to section
for a sample usage of the .
Note: If you intend to use the installation as a root filesystem exported
over NFS, then you now have to finish the configuration of the
following the instructions in .
Note: Installation of the Glibc- and uClibc-based
versions into one directory is not yet supported.
Note: Installation of the 32-bit and 64-bit
versions into one directory is not yet supported.
has an RPM-based structure. This means that on the ISO
image, individual components of the
are in the form of RPM
packages, and after installation, the
maintains its own database
which contains information about installed packages. The RPM database
is kept local to the specific
installation, which allows you to
have multiple independent
installations on your host system.
(That is, you can install several instances of
under different
directories and work with them independently). Also, this provides
for easy installation and management of individual
To list the installed
RPM packages, use the following command:
bash$ ${CROSS_COMPILE}rpm -qa
To remove an
package, use the following command:
bash$ ${CROSS_COMPILE}rpm -e &package_name&
To install a package, use the following command:
bash$ ${CROSS_COMPILE}rpm -i &package_file_name&
To update a package, use the following command:
bash$ ${CROSS_COMPILE}rpm -U &package_file_name&
For the above commands to work correctly, it is crucial that the
correct rpm binary gets invoked. In case of
installations and RedHat-based host system, there may
well be several rpm tools installed on the host
You must make sure, either by using an explicit path or by having set
an appropriate PATH environment variable, that
when you invoke rpm to install/remove components
installation, it is the 's rpm
utility that gets actually invoked. The rpm
utility is located in the bin subdirectory
relative to the
root installation directory.
To avoid confusion with the host OS (RedHat) rpm
utility, the
creates symlinks to its rpm
binary with the names such that it could be invoked using the
${CROSS_COMPILE}rpm notation, for all supported
The standard (host OS) rpm utility allows various
macros and configuration parameters to specified in
user-specific ~/.rpmrc and ~/.rpmmacros files. The
rpm tool also has this capability, but the names
of the user-specific configuration files
are ~/.eldk_rpmrc and ~/.eldk_rpmmacros, respectively.
To remove the entire
installation, use the following command
while in the
root directory:
bash$ rm -rf &dir&
where &dir& specifies the root directory of the
After the initial installation is complete, all you have to do to
start working with the
is to set and export the
CROSS_COMPILE environment variable.
Optionally, you may wish to add the bin and usr/bin directories of
installation to the value of your PATH
environment variable. For instance, a sample
installation and
usage scenario looks as follows:
Create a new directory where the
is to be installed, say:
bash$ mkdir /opt/eldk
Mount a CD or an ISO image with the distribution:
bash$ mount /dev/cdrom /mnt/cdrom
Run the installation utility included on the distribution to
install into that specified directory:
bash$ /mnt/cdrom/install -d /opt/eldk
After the installation utility completes, export the
CROSS_COMPILE variable:
bash$ export CROSS_COMPILE=arm-linux-gnueabi-
The trailing '-' character
in the CROSS_COMPILE variable value is optional
and has no effect on the cross tools behavior. However, it is required when building Linux kernel and U-Boot images.
Add the directories /opt/eldk/usr/bin and /opt/eldk/bin
bash$ PATH=$PATH:/opt/eldk/usr/bin:/opt/eldk/bin
Compile a file:
bash$ ${CROSS_COMPILE}gcc -o hello_world hello_world.c
You can also call the cross tools using the generic prefix arm-linux-
for example:
bash$ arm-linux-gcc -o hello_world hello_world.c
or, equivalently:
bash /opt/eldk/usr/arm-linux/bin/gcc -o hello_world hello_world.c
The value of the CROSS_COMPILE variable
must correspond to the target
family you want the cross tools to
work for. Refer to the table below for the supported
CROSS_COMPILE variable values:
CROSS_COMPILE Value
Predefined Compiler Flag
FPU present or not
arm-linux-
-mcpu=arm9 -msoft-float
armVFP-linux-
-mfpu=vfp -mfloat-abi=softfp
No special actions are required from the user to switch between
installations on the same host system. Which
installation is used is determined entirely by the filesystem
location of the binary that is being invoked. This approach can be
illustrated using the following example.
Assume the directory
/work/denx_tools/usr/bin, where the arm-linux-gcc
compiler binary has been installed,
is a part of the PATH environment variable. The
user types the command as follows:
$ arm-linux-gcc -c myfile.c
To load the correct include files, find the correct libraries, spec
files, etc., the compiler needs to know the
root directory. The
compiler determines this information by analyzing the shell command it
was invoked with ( arm-linux-gcc
specifying the explicit path in this example) and, if needed, the
value of the PATH environment variable. Thus, the
compiler knows that it has been executed from the
/work/denx_tools/usr/bin directory.
Then, it knows that the compiler is installed in the usr/bin
subdirectory of the root installation directory, so the , the
compiler is a part of, has been installed in the subdirectories of the
/work/denx_tools directory. This means
that the target include files are in
/work/denx_tools/&target_cpu_variant&/usr/include,
and so on.
The target components of the
can be mounted via NFS as the root
file system for your target machine. For instance, for an
AT91-based
target, and assuming the
has been installed into the
/opt/eldk directory, you can
use the following directory as the NFS-based root file system:
/opt/eldk/arm
Before the NFS-mounted root file system can work, you must create
necessary device nodes in the
&ELDK_root&/&target_cpu_variant&/dev
directory. This process requires superuser privileges and thus
cannot be done by the installation procedure (which typically runs as non-root). To facilitate
creation of the device nodes, the
provides a script named
ELDK_MAKEDEV, which is located in the root
distribution ISO image. The script acccepts the following
optional arguments:
Specifies the root directory of the
being installed. If omitted, then the current directory is assumed.
-a&&cpu_family&
Specifies the target
family directory. If omitted, all installed target
directories will be populated with the device nodes.
Prints usage.
# /mnt/cdrom/ELDK_MAKEDEV -d /opt/eldk
NOTE: Compared to older versions of the ,
options and behaviour of this command have been changed significantly.
Please read the documentation.
Some of the target utilities included in the , such as
mount and su, have the SUID bit
set. This means that when run, they will have privileges of the file
owner of these utilities. That is, normally, they will have the
privileges of the user who installed the
on the host system.
However, for these utilities to work properly,
they must have superuser privileges. This means that if the
not installed by the superuser, the file owner of the target
utilities that have the SUID bit set must be changed to
root before a target component may be mounted as
the root file system. The
distribution image contains an
ELDK_FIXOWNER script, which you can use to change
file owners of all the appropriate files of the
installation to
root. The script accepts the same arguments as the ELDK_MAKEDEV script above.
Please note that you must have superuser
privileges to run this script. For instance, if you have installed
in the /opt/eldk
directory, you can use the following commands:
# cd /opt/eldk
# /mnt/cdrom/ELDK_FIXOWNER
Please note, that in the case that the installation directory, where the new
distribution is being installed, is already populated with other
distributions,
the execution of the ELDK_FIXOWNER script without arguments will make the script
work with all installed
directories. This could take some time. To save the time, please use the -a argument
to specify the appropriate target .
For instance:
# cd /opt/eldk
# /mnt/cdrom/ELDK_FIXOWNER -a arm
Components
Source Distribution
is distributed with the full sources of all the components,
so you may rebuild any
package. The sources are provided in the
form of SRPM packages, distributed as a separate ISO image.
To rebuild a target or ELDT package, you must first install the
appropriate source RPM package from the ISO image into the
environment. This can be done using the following command:
$ ${CROSS_COMPILE}rpm -i /mnt/cdrom/SRPMS/&source_rpm_file_name&.src.rpm
source RPM is installed using the above command, its
spec file and sources can be found in the subdirectories of the
&ELDK_root&/usr/src/denx subdirectory.
The sections that follow provide detailed instructions on rebuilding
ELDT and target components of the .
All the target packages can be rebuilt
from the provided source RPM packages.
At first you have to install the Source RPM itself:
bash$ ${CROSS_COMPILE}rpm -iv &package_name&.src.rpm
Then you can rebuild the binary target RPM using the following command
environment:
bash$ ${CROSS_COMPILE}rpmbuild -ba &package_name&.spec
In order for the rebuilding process to work correctly, the following
conditions must be true:
environment variable
must be set as appropriate for the target
The &ELDK_root&/usr/arm-linux/bin
directory must be in PATH before the
/usr/bin directory. This is to make sure that
the command gcc results in the fact that the
cross compiler is invoked, rather than the host
The newly built package can then be installed just as easily:
bash$ ${CROSS_COMPILE}rpm -i &package_name&.rpm
All the ELDT packages allow for rebuilding from the provided source
RPM packages using the following command from the
environment:
$ unset CROSS_COMPILE
$ &ELDK_root&/usr/bin/rpmbuild -ba &package_name.spec&
In order for the rebuilding process to work correctly, make sure all of the following is
environment variable
must NOT be set.
Do NOT use the
command prefix.
The &ELDK_root&/usr/arm-linux/bin
directory must NOT be in PATH. This is to make sure that the command
gcc causes invokation of the host
gcc, rather than the
cross compiler.
Note that the newly built package should be installed with the "global" rpm,
not with the arch specific one:
bash$ &ELDK_root&/bin/rpm -i &package_name&.rpm
crosstool-devel
elocaledef
4.4.2-46_2
4.4.2-46_2
Note: The crosstool 0.43 ELDT package provides the following packages: gcc 4.2.2,
gcc-c++ 4.2.2, gcc-java 4.2.2, cpp 4.2.2 and binutils 2.17.90. For more information about
the crosstool package please refer to .
2.2.39-3.1
9.4.1-8.P1
binutils-devel
0.94.14-0.5.rc21
bzip2-devel
bzip2-libs
cracklib-dicts
crosstool-targetcomponents
cyrus-sasl
cyrus-sasl-devel
cyrus-sasl-lib
4.5.20-5_2
4.5.20-5_2
4.5.20-5_2
device-mapper
device-mapper-devel
device-mapper-libs
dosfstools
e2fsprogs-devel
e2fsprogs-libs
expat-devel
freetype-devel
glib2-devel
glib-devel
4.1.4-12.3
1.18.1.4-2
httpd-devel
httpd-manual
initscripts
iscsitarget
kernel-headers
kernel-source
krb5-devel
libattr-devel
libcap-devel
libpng-devel
libsysfs-devel
libtermcap
2.0.8-46.1
libtermcap-devel
2.0.8-46.1
libtirpc-devel
libtool-ltdl
libtool-ltdl-devel
libusb-devel
libuser-devel
0.12.20-22.1
microwindows
microwindows-fonts
1.07-5.2.2
module-init-tools
3.3-0.pre11.1.0
ncurses-devel
net-snmp-devel
net-snmp-libs
net-snmp-utils
newt-devel
open-iscsi
2.0-865.15
openldap-devel
0.9.8b-12_2
openssl-devel
0.9.8b-12_2
0.99.7.1-5.1
0.99.7.1-5.1
2.5.4-29.2.2
pciutils-devel
pcmciautils
pcsc-lite-devel
pcsc-lite-libs
5.8.8-18_2
5.8.8-18_2
postgresql
postgresql-devel
postgresql-libs
readline-devel
4.4.2-46_2
4.4.2-46_2
4.4.2-46_2
4.4.2-46_2
rsh-server
shadow-utils
4.0.18.1-15
slang-devel
smartmontools
sysfsutils
tcp_wrappers
tcp_wrappers-devel
tcp_wrappers-libs
telnet-server
tftp-server
util-linux
2.13-0.52_2
vim-common
vim-minimal
vixie-cron
2.0.5-16_2
wireless-tools
wpa_supplicant
zlib-devel
Note 1: Not all packages will be ins for example the
boa and thttpd web servers are
mutually exclusive - you will have to remove one package before you
can (manually) install the other one.
Note 2: The crosstool 0.43 target package provides the following packages: glibc 2.6, glibc-common 2.6, glibc-devel 2.6, libstdc++ 4.2.2, libgcj 4.2.2, libgcj-devel 4.2.2
and libstdc++-devel 4.2.2.
For more information about the crosstool package please refer to
Note 3: The Xenomai and gcc-java packages are unavailable in ARM
from Scratch
In this section, you
will find instructions on how to build the
from scratch, using the pristine package sources available on the
Internet, and patches, spec files, and build scripts provided on the
source CD-ROM.
Build Process Overview
Fedora 7 Linux distribution as source code
reference. Any modifications to Fedora's sources the
introduced are in the form of patches applied by the RPM tool while
building the packages. Also, the
uses modified spec files for
its RPM packages. So, the sources of almost every
consist of the following parts:
Fedora pristine sources or
source tarball,
spec file.
The Fedora pristine sources may be obtained from the Internet, see
patches and spec files are available on the
CD-ROM and from the DENX GIT repositories. Also, for convenience,
the pristine Fedora sources are available here, too.
Please use the following commands to check out a copy of one of the modules:
git-clone git://www.denx.de/git/eldk/module
The following
modules are available:
Source tarballs
Build tools, patches, and spec files
Fedora 7 sources
Then you may switch to a specific release of the
using the "git-checkout" for example, to get the files for
release 4.1, please do the following from the module directory:
git-checkout ELDK_4_2
It must be noted that some of the packages which are included in the
are not included in Fedora. Examples of such packages are
appWeb, microwindows, and wu-ftpd. For these
packages tarballs are provided in the DENX GIT repository.
To facilitate building of the , a build infrastructure has been
developed. The infrastructure is composed of the following components:
ELDK_BUILD script
build.sh script
cpkgs.lst file
tpkgs.lst file
SRPMS.lst file
tarballs.lst file
The ELDK_BUILD script is the main script of the
build procedure. It is the tool that you would normally use to
from scratch. In the simplest case, the script may be
invoked without arguments, and it will perform all necessary steps to
in a fully automated way. You may pass the following optional
arguments to the ELDK_BUILD script:
target architecture: "arm", "ppc" or "ppc64", defaults to "ppc".
-n&&build_name&
an identification string for the build. Defaults to the value based on the build architecture and current date, and has the following format: &arch&-YYYY-MM-DD
-v&&version&
version string
build the uClibc-based
version (on the platforms and versions where this is available).
-p&&builddir&
Optional build directory. By default, build will place the work files and results in the current directory.
Warning: The
build scripts rely on standard behaviour of the RPM tool.
Make sure you don't use non-standard settings in your personal ~/.rpmmacros file that
might cause conflicts.
build.sh is a supplementary script that is called
by ELDK_BUILD to accomplish certain steps of the
build. Refer to section
below for more
The cpkgs.lst and tpkgs.lst
files are read by build.sh and must contain lines
describing sub-steps of the eldt and
trg build procedure steps. Essentially, the
files contain the list of the ELDT and target packages to be included
in the . The SRPMS.lst file contains the
list of the Fedora source RPM packages used during the
The tarballs.lst file contains the list of
source tarballs of the packages that are included in the
not present in Fedora 7.
For the ELDK_BUILD script to work correctly, it
must be invoked from a certain build environment created on the host
system. The build environment can be either checked out from the DENX
GIT repository (see section
Build Environment below for details) or copied
build environment CD-ROM.
To be more specific, the following diagram outlines the build
environment needed for correct operation of the
ELDK_BUILD script:
&some_directory&/
build/cross_rpms/&package_name&/SPECS/...
SOURCES/...
target_rpms/&package_name&/SPECS/...
SOURCES/...
install/install.c
misc/ELDK_MAKEDEV
ELDK_FIXOWNER
README.html
ELDK_BUILD
tarballs.lst
tarballs/....
SRPMS/....
SRPMS-updates/....
In subdirectories of the cross_rpms and target_rpms
directories, the sources and RPM spec files of,
respectively, the ELDT and target packages are
stored. The install
subdirectory contains the sources of the installation utility which
will be built and placed in the root of the ISO image.
tarballs directory contains the source
tarballs of the packages that are included in the
but are not
present in Fedora 7.
The SRPMS and SRPMS-updates directories may contain the source RPM packages of Fedora
7. The ELDK_BUILD script looks for a package in the SRPMS directory and then, if the package is
not found, in the SRPMS-updates directory. If some (or all) of the Fedora SRPMs needed for
the build are missing in the directories, the ELDK_BUILD script
will download the source RPMs automatically from the Internet.
build environment CD-ROM provides a ready-to-use
environment. Please refer to section
Build Environment
below for detailed instructions on setting up the build environment.
The ELDK_BUILD script examines the contents of the
ELDK_PREFIX environment variable to determine the
root directory of the
build environment. If the variable is not
set when the script is invoked, it is assumed that the root directory
build environment is /opt/eldk. To build the
example directory layout given above, you must set and export the
ELDK_PREFIX variable &some_directory& prior to invoking
ELDK_BUILD.
After all the build steps are complete, the following subdirectories
are created in the
build environment:
build/&build_name&/work/
- full ELDK environment
build/&build_name&/logs/
- build procedure log files
build/&build_name&/results/b_cdrom/
- binary cdrom tree, ready for mkisofs
results/s_cdrom/
- source cdrom tree, ready for mkisofs
results/d_cdrom/
- debuginfo cdrom tree, ready for mkisofs
On Linux hosts, the binary and source ISO images are created
automatically by the ELDK_BUILD script and placed
in the results directory. On
Solaris hosts, creating the ISO images is a manual step. Use the
contents of the b_cdrom and
s_cdrom directories for the
contents of the ISO images.
Build Environment
For your convenience,
build environment CD-ROM provides full
build environment. All you need to do is copy the contents of
the CD-ROM to an empty directory on your host system. Assuming the
build environment CD-ROM is mounted at /mnt/cdrom,
and the empty directory
where you want to create the build environment is named
/opt/eldk, use the following
commands to create the build environment:
bash$ cd /opt/eldk
bash$ cp -r /mnt/cdrom/* .
These commands will create the directory structure as described in
Build Process Overview above.
All necessary scripts and
specific source files will be placed in the
build subdirectory, and the required
tarballs can be found in the
tarballs subdirectory. In the
SRPMS subdirectory, you will find all
the Fedora 7 SRPMS needed to build the .
Alternatively, you can obtain the
build environment from the
DENX GIT repository. Two modules are provided for check out:
tarballs. The first one contains the files
for the build subdirectory in
the build environment, and the second one contains source tarballs of
the packages that are included in the
but are not present in
Fedora 7. To create the
build environment from the DENX GIT
repository, use the following commands (the example below assumes that
the root directory of the build environment is
/opt/eldk):
bash$ cd /opt/eldk
bash$ git-clone git://www.denx.de/git/eldk/build
bash$ git-clone git://www.denx.de/git/eldk/tarballs
bash$ git-clone git://www.denx.de/git/eldk/SRPMS
To allow to install the
on as many as possible Linux
distributions (including old systems), we use a Red Hat 7.3 host
system for building. Also, Fedora Core 5 is known to work as a build
environment. Other, especially more recent Linux distributions, will
most likely have problems. We therefor provide a Red Hat 7.3 based
root file system image than can run in some virtualization
environment (like qemu etc.). Here is an application note with
detailed instructions:
If you wish
to perform only a part of the
build procedure, for
instance to re-build or update a certain package, it may sometimes be
convenient to invoke the build.sh script manually,
without the aid of the ELDK_BUILD script. Please
note, however, that this approach is in general discouraged.
The whole build procedure is logically divided into six steps, and
the build.sh must be told which of the build steps
to perform. The build steps are defined as follows:
rpm - build RPM
eldt - build ELDT packages
seldt - save ELDT SRPM packages to create a source ISO image later on
trg - build target packages
biso - prepare the file tree to create the binary ISO image
siso - prepare the file tree to create the source ISO image
diso - prepare the file tree to create the debuginfo ISO image
Further, the eldt and trg
build steps are devided into sub-steps, as defined in the
cpkgs.lst and tpkgs.lst
files (see below for details). You may specify which sub-steps of the
build step are to be performed.
The formal syntax for the usage of build.sh is as follows:
bash$ ./build.sh [-a &arch&] [-n &name&] [-p &prefix&] [-r &result&] \
[-w &work&] &step_name& [&sub_step_number&]
target architecture: "ppc", "ppc64", "arm" or "mips", defaults to "ppc".
-n &build_name&
an identification string for the build. It is used as a name for some directories created during the build. You may use for example the current date as the build name.
-p &prefix&
is the name of the directory that contains the build environment. Refer to
above for description of the build environment.
-r &result&
is the name of the directory where the resulting RPMs and SRPMs created on this step will be placed.
is the name of the directory where the build is performed.
&stepname&
is the name of the build step that is to be performed. Refer to the list of the build procedure steps above.
&sub_step_number&
is an optional parameter which identifies sub-steps of the step which are to be performed. This is useful when you want to re-build only some specific packages. The numbers are defined in the cpkgs.lst and tpkgs.lst files discussed below. You can specify a range of numbers here. For instance, "2 5" means do steps from 2 to 5, while simply "2" means do all steps starting at 2.
Please note that you must never use build.sh to
from scratch. For build.sh to work
correctly, the script must be invoked from the build environment
after a successful build using the ELDK_BUILD
script. A possible scenario of build.sh usage is
such that you have a build environment with results of a build
performed using the ELDK_BUILD script and want to
re-build certain ELDT and target packages, for instance, because you
have updated sources of a package or added a new package to the
When building the target packages (during the
trg buildstep), build.sh
examines the contents of the
TARGET_CPU_FAMILY_LIST environment variable, which
may contain a list indicating which target
variants the packages
must be built for.
variants are arm.
For example, the command below rebuilds
the target RPM listed in the tpckgs.lst file
under the number of 47 (see section
description of the tpckgs.lst and
cpkgs.lst files), for the arm :
bash$ TARGET_CPU_FAMILY_LIST="arm" \
& /opt/eldk/build.sh -a arm \
-p /opt/eldk/build/arm- \
-r /opt/eldk/build/arm-/results \
-w /opt/eldk/build/arm-/work \
Note: If you are going to invoke build.sh to re-build a
package that has already been built in the build environment by the
ELDK_BUILD script, then you must first manually
uninstall the package from
installation created by the build
procedure under the work
directory of the build environment.
Note: It is recommended that you use the build.sh script
only at the final stage of adding/updating a package to the . For
debugging purposes, it is much more convenient and efficient to build
both ELDT and target packages using a working
installation, as
described in the sections
Each line of these files has the following format:
&sub_step_number& &package_name& &spec_file_name& \
&binary_package_name& &package_version&
source CD-ROM contains the cpkgs.lst
and tpkgs.lst files used to build this version
distribution. Use them as reference if you want to
include any additional packages into the , or remove unneeded
To add a package to the
you must add a line to either the
cpkgs.lst file, if you are adding a ELDT
package, or to the tpkgs.lst file, if it is a
target package. Keep in mind that the relative positions of packages
in the cpkgs.lst and
tpkgs.lst files (the sub-step numbers) are very
important. The build procedure builds the packages sequentially as
defined in the *.lst files and installs the
packages in the "work" environment as they are built. This
implies that if a package depends on other packages, those packages
must be specified earlier (with smaller sub-step numbers) in the
*.lst files.
Note: For cpkgs.lst, the package_version may be replaced
by the special keyword "RHAUX". Such packages are used as auxiliary when building
4.2 on non-Fedora hosts. These packages will be built and used during the
build process, but will not be put into the
4.2 distribution ISO images.
Some tools are needed to install and configure U-Boot and Linux on
the target system. Also, especially during development, you will want
to be able to interact with the target system. This section describes
how to configure your host system for this purpose.
To use U-Boot and Linux as a development system and to make full use
of all their capabilities you will need access to a serial console
port on your target system. Later, U-Boot and Linux can be
configured to allow for automatic execution without any user
interaction.
There are several ways to access the serial console port on your target system,
such as using a terminal server, but the most common way is to attach it to a
serial port on your host. Additionally, you will need a terminal
emulation program on your host system, such as cu or kermit.
The cu command is part of the
UUCP package and can be used to act as a dial-in
terminal. It can also do simple file transfers, which can be used in
U-Boot for image download.
systems you can check if the UUCP
package is installed as follows:
$ rpm -q uucp
If necessary, install the UUCP package from your distribution media.
To configure cu for use with U-Boot and Linux
please make sure that the following entries are present in the
UUCP depending on your target
configuration the serial port and/or the console baudrate may be
different from the values used in this example:
(/dev/ttyS0, 115200 bps, 8N1):
/etc/uucp/sys:
# /dev/ttyS0 at 115200 bps:
serial0_115200
/etc/uucp/port:
# /dev/ttyS0 at 115200 bps:
serial0_115200
/dev/ttyS0
You can then connect to the serial line using the command
$ cu S0@115200
Connected.
To disconnect, type the escape character '~'
followed by '.' at the beginning of a line.
See also: cu(1), info uucp.
The name kermit stands for a whole family of
communications software for serial and network connections. The fact
that it is available for most computers and operating systems makes
it especially well suited for our purposes.
kermit executes the commands in its
initialization file, .kermrc, in your home
directory before it executes any other commands, so this can be
easily used to customize its behaviour using appropriate
initialization commands. The following settings are recommended for
use with U-Boot and Linux:
~/.kermrc:
set line /dev/ttyS0
set speed 115200
set carrier-watch off
set handshake none
set flow-control none
set file type bin
set file name lit
set rec pack 1000
set send pack 1000
set window 5
This example assumes that you use the first serial port of your host
system (/dev/ttyS0) at a baudrate of
115200 to connect to the target's serial console port.
You can then connect to the serial line:
$ kermit -c
Connecting to /dev/ttyS0, speed 115200.
The escape character is Ctrl-\ (ASCII 28, FS)
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
Due to licensing conditions you will often find two kermit packages
in your GNU/Linux distribution.
In this case you will want to install the
ckermit package.
The gkermit package is only a command line
tool implementing the kermit transfer protocol.
If you cannot find kermit on the distribution
media for your Linux host system, you can download it from
the kermit project home page:
minicom is another popular serial communication
program. Unfortunately, many users have reported problems using it
with U-Boot and Linux, especially when trying to use it for serial
image download. It's use is therefore discouraged.
The terminal emulation program must have write access to the serial
port and to any locking files that are used to prevent concurrent
access from other applications. Depending on the used Linux
distribution you may have to make sure that:
the serial device belongs to the same group as the
cu command, and that the permissions of
cu have the setgid bit set
the kermit belongs to the same group as
cu and has the setgid bit set
the /var/lock directory
belongs to the same group as the cu command, and
that the write permissions for the group are set
The fastest way to use U-Boot to load a Linux kernel or an
application image is file transfer over Ethernet. For this purpose,
U-Boot implements the
TFTP protocol (see the tftpboot command in U-Boot).
support on your host system you must make sure that
daemon program /usr/sbin/in.tftpd is
installed. On
systems you can verify this by running:
$ rpm -q tftp-server
If necessary, install the
daemon program from your distribution media.
Most Linux distributions disable the
service by default. To
enable it for example on
systems, edit the file /etc/xinetd.d/tftp and
remove the line
disable = yes
or change it into a comment line by putting a hash character in front of
# default: off
# description: The tftp server serves files using the trivial file transfer
The tftp protocol is often used to boot diskless
workstations, download configuration files to network-aware printers,
and to start the installation process for some operating systems.
service tftp
socket_type
= /usr/sbin/in.tftpd
server_args
= -s /tftpboot
per_source
Also, make sure that the
/tftpboot directory exists and
is world-readable (permissions at least "dr-xr-xr-x").
On newer Linux distros that use systemd, you would need to start the
service, enable it, then tweak your firewall to allow
traffic, something like this:
$ sudo systemctl start tftp
$ sudo systemctl enable tftp
$ sudo firewall-cmd --permanent --add-service tftp
$ sudo firewall-cmd --reload
BOOTP resp. DHCP can be used to
automatically pass configuration information to the
target. The only thing the target must "know" about itself is its own
Ethernet hardware () address. The following command can be used to check if
support is available on your host system:
$ rpm -q dhcp
If necessary, install the
package from your distribution
Then you have to create the
configuration file
/etc/dhcpd.conf that matches your network setup.
The following example gives you an idea what to do:
subnet 192.168.0.0 netmask 255.255.0.0 {
option routers
192.168.1.1;
option subnet-mask
255.255.0.0;
option domain-name
"local.net";
option domain-name-servers ns.local.
host trgt {
hardware ethernet
00:30:BF:01:02:D0;
fixed-address
192.168.20.38;
option root-path
"/opt/eldk-5.0/armv5te/rootfs";
option host-name
"enbw_cmc";
next-server
192.168.1.1;
"/tftpboot/duts/enbw_cmc/uImage";
With this configuration, the
server will reply to a request from
the target with the ethernet address
00:30:BF:01:02:D0 with the following information:
The target is located in the subnet 192.168.0.0
which uses the netmask 255.255.0.0.
The target has the hostname enbw_cmc
and the IP address 192.168.20.38.
The host with the IP address 192.168.1.1 will
provide the boot image for the target and provide NFS server
function in cases when the target mounts it's root filesystem over
The host listed with the next-server
option can be different from the host that is running the
The host provides the file /tftpboot/duts/enbw_cmc/uImage
as boot image for the target.
The target can mount the directory
/opt/eldk-5.0/armv5te/rootfs on the NFS
server as root filesystem.
For a development environment it is very convenient when the host and
the target can share the same files over the network. The easiest way for
such a setup is when the host provides NFS server functionality and
exports a directory that can be mounted from the target as the root
filesystem.
Assuming NFS server functionality is already provided by your host, the
only configuration that needs to be added is an entry for your target
root directory to your /etc/exports file, for
instance like this:
/opt/eldk-5.0/armv5te/rootfs
192.168.0.0/255.255.0.0(rw,no_root_squash,sync)
This line exports the
/opt/eldk-5.0/armv5te/rootfs directory
with read and write permissions to all hosts on the 192.168.0.0
After modifying the /etc/exports file you must
make sure the NFS system is notified about the change, for instance
by issuing the command:
# /sbin/service nfs restart
Das U-Boot (or just "U-Boot" for short) is Open Source Firmware
for Embedded