close

參考來源
http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html

1. Abstract

This is the DENX U-Boot and Linux Guide to Embedded PowerPC, ARM and MIPS Systems.

The document describes how to configure, build and use the firmware Das U-Boot (typically abbreviated as just "U-Boot") and the operating system Linux for Embedded PowerPC, ARM and MIPS Systems.

The focus of this version of the document is on TQM8xxL boards.

This document was generated at 01 Mar 2008 - 16:53.

2. Introduction

This document describes how to use the firmware U-Boot and the operating system Linux in Embedded PowerPC, ARM and MIPS Systems.

There are many steps along the way, and it is nearly impossible to cover them all in depth, but we will try to provide all necessary information to get an embedded system running from scratch. This includes all the tools you will probably need to configure, build and run U-Boot and Linux.

First, we describe how to install the Cross Development Tools Embedded Linux Development Kit which you probably need - at least when you use a standard x86 PC running Linux or a Sun Solaris 2.6 system as build environment.

Then we describe what needs to be done to connect to the serial console port of your target: you will have to configure a terminal emulation program like cu or kermit.

In most cases you will want to load images into your target using ethernet; for this purpose you need TFTP and DHCP / BOOTP servers. A short description of their configuration is given.

A description follows of what needs to be done to configure and build the U-Boot for a specific board, and how to install it and get it working on that board.

The configuration, building and installing of Linux in an embedded configuration is the next step. We use SELF, our Simple Embedded Linux Framework, to demonstrate how to set up both a development system (with the root filesystem mounted over NFS) and an embedded target configuration (running from a ramdisk image based on busybox).

This document does not describe what needs to be done to port U-Boot or Linux to a new hardware platform. Instead, it is silently assumed that your board is already supported by U-Boot and Linux.

The focus of this document is on TQM8xxL boards.

2.1. Copyright

Copyright (c) 2001 - 2007 by Wolfgang Denk, DENX Software Engineering.

You have the freedom to distribute copies of this document in any format or to create a derivative work of it and distribute it provided that you:

  • Distribute this document or the derivative work at no charge at all. It is not permitted to sell this document or the derivative work or to include it into any package or distribution that is not freely available to everybody.
  • Send your derivative work (in the most suitable format such as sgml) to the author.
  • License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used.
  • Give due credit to previous authors and major contributors.

It is requested that corrections and/or comments be forwarded to the author.

If you are considering to create a derived work other than a translation, it is requested that you discuss your plans with the author.

2.2. Disclaimer

Use the information in this document at your own risk. DENX disavows any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk. All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

2.3. Availability

The latest version of this document is available in a number of formats:

2.4. Credits

A lot of the information contained in this document was collected from several mailing lists. Thanks to anybody who contributed in one form or another.

2.5. Translations

None yet.

2.6. Feedback

Any comments or suggestions can be mailed to the author: Wolfgang Denk at wd@denx.de.

2.7. Conventions

Descriptions Appearance
Warnings ALERT!
Hint TIP
Notes Note.
Information requiring special attention Warning
File Names file.extension
Directory Names directory
Commands to be typed a command
Applications Names another application
Prompt of users command under bash shell bash$
Prompt of root users command under bash shell bash#
Prompt of users command under tcsh shell tcsh$
Environment Variables VARIABLE
Emphasized word word
Code Example ls -l

 

 

 

3. Embedded Linux Development Kit

The Embedded Linux Development Kit (ELDK) includes the GNU cross development tools, such as the compilers, binutils, gdb, etc., and a number of pre-built target tools and libraries necessary to provide some functionality on the target system.

It is provided for free with full source code, including all patches, extensions, programs and scripts used to build the tools.

Starting from version 4.1, the ELDK is available in two versions, which use Glibc resp. uClibc as the main C library for the target packages.

Packaging and installation is based on the RPM package manager.

3.1. ELDK Availability

The ELDK is available

3.2. Supported Host Systems

The ELDK can be installed onto and operate with the following operating systems:

Users also reported successful installation and use of the ELDK on the following host systems:

Note: It may be necessary, and is usually recommended, to install the latest available software updates on your host system. For example, on Fedora Core systems, you can use one of yum, apt-get or up2date to keep your systems current.

3.3. Supported Target Architectures

The ELDK includes target components and supports code generation for the following PowerPC types of processors:

  • ppc_4xx = AMCC 4xx processors without FPU
  • ppc_4xxFP = AMCC 4xx processors with FPU (440EP, 440EPx)
  • ppc_6xx = PowerPC processors based on 60x cores
    (This includes support for MPC5xxx, 7xx, 82xx and 83xx processors).
  • ppc_74xx = 74xx processors
    (This includes support for MPC86xx processors).
  • ppc_8xx = MPC8xx processors
  • ppc_85xx = MPC85xx processors

There is also an ELDK for ARM and MIPS systems.

3.4. Installation

3.4.1. Product Packaging

Stable versions of the ELDK are distributed in the form of an ISO image, which can be either burned onto a CD or mounted directly, using the loopback Linux device driver (Linux host only).

For the PowerPC target, the ELDK distribution was split into two independent ISO images: one targeting the 4xx family of processors (AMCC), and another one for the 8xx, 6xx, 74xx and 85xx families (Freescale). This makes the ISO images fit on standard CDROM media.

If you are not bound by the CDROM size limitiation there is still a single image containing all targets.

Development versions of the ELDK are available as directory trees so it is easy to update individual packages; instructions for download of these trees and creation of ISO images from it is described in section 3.4.2. Downloading the ELDK.

The ELDK 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 3.8.1. List of ELDT Packages below.

The target components are pre-built tools and libraries which are executed on the target system. The ELDK 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 ELDK, refer to section 3.8.2. List of Target Packages below.

The ELDK contains several independent sets of the target packages, one for each supported target architecture CPU family. Each set has been built using compiler code generation and optimization options specific to the respective target CPU family.

3.4.2. Downloading the ELDK

You can either download the ready-to-burn ISO-images from one of the mirror sites (see 3.1. ELDK Availability), or you can download the individual files of the ELDK from the development directory tree and either use these directly for installation or create an ISO image that can be burned on CD-ROM.

Change to a directory with sufficient free disk space; for the PowerPC version of the ELDK you need about 780 MB, or twice as much (1.6 GB) if you also want to create an ISO image in this directory.

To download the ISO image from the ppc-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.1/ppc-linux-x86/iso/ppc-2007-01-19.iso

Note: The size of this ISO image is more than 790 MB, so it does not fit on CDROM media. If you don't need support for all PowerPC processors then you can use one of the following alternative images which can be writen to standard CDROM media:

ISO Image Content
ppc-2007-01-19_amcc.iso ISO image including support for
AMCC 4xx / 4xxFP processors
ppc-2007-01-19_freescale.iso ISO image including support for the
remaining PowerPC processors (5xxx, 6xx, 7xx, 74xx, 8xx, 85xx)

If you want to download the whole ELDK directory tree instead you can - for example - use the ncftp FTP client:

bash$ ncftp ftp.sunet.se...ncftp / > cd /pub/Linux/distributions/eldk/4.1ncftp /pub/Linux/distributions/eldk/4.1 > binncftp /pub/Linux/distributions/eldk/4.1 > get -R ppc-linux-x86/distribution...ncftp /pub/Linux/distributions/eldk/4.1 > bye

Depending on your combination of host and target architecture, you should download one of the following directories:  

  • ppc-linux-x86/iso    resp.
    ppc-linux-x86/distribution for PowerPC targets and x86 Linux hosts,
  • mips-linux-x86/iso    resp.
    mips-linux-x86/distribution for MIPS targets and x86 Linux hosts, or
  • arm-linux-x86/iso    resp.
    arm-linux-x86/distribution for ARM targets and x86 Linux hosts.

If you don't find the ncftp tool on your system you can download the NcFTP client from http://www.ncftp.com/download/

There are a few executable files (binaries and scripts) in the ELDK tree. Make sure they have the execute permissions set in your local copy:

bash$ for file in \>       tools/bin/rpm \>       tools/usr/lib/rpm/rpmd \>       install \>       ELDK_MAKEDEV \>       ELDK_FIXOWNER> do> chmod +x ppc-linux-x86/distribution/$file> done

Now create an ISO image from the directory tree:

bash$ mkisofs \> -A "ELDK-4.1 -- Target: PowerPC -- Host: x86 Linux" \> -P "(C) `date "+%Y"` DENX Software Engineering,   www.denx.de" \> -p "`id -nu`@`hostname` -- `date`" \> -V ppc-linux-x86 \> -l -J -R -o eldk-ppc-linux-x86.iso ppc-linux-x86/distribution

This will create an ISO image eldk-ppc-linux-x86.iso in your local directory that can be burned on CD or DVD (depending on size) 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 3.9.2. Setting Up ELDK Build Environment for instructions on obtaining the build environment needed to re-build the ELDK from scratch.

3.4.3. Initial Installation

The initial installation is performed using the install utility located in the root of the ELDK ISO image directory tree. The install utility has the following syntax:

$ ./install [-d <dir>] [<cpu_family1>] [<cpu_family2>] ...

-d <dir> Specifies the root directory of the ELDK being installed. If omitted, the ELDK goes into the current directory.
<cpu_family> Specifies the target CPU family the user desires to install. If one or more <cpu_family> parameters are specified, only the target components specific to the respective CPU families are installed onto the host. If omitted, the target components for all supported target architecture CPU families are installed.

Note: Make sure that the "exec" option to the mount command is in effect when mounting the ELDK 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 ELDK CD with appropriate "exec" permission. In such cases, consult your distribution documentation or mount the CD 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 ELDK 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 3.5. Working with ELDK for a sample usage of the ELDK.

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 ELDK following the instructions in 3.6. Mounting Target Components via NFS.

Note: Installation of the Glibc- and uClibc-based ELDK versions into one directory is not yet supported.

3.4.4. Installation and Removal of Individual Packages

The ELDK has an RPM-based structure. This means that on the ISO image, individual components of the ELDK are in the form of RPM packages, and after installation, the ELDK maintains its own database which contains information about installed packages. The RPM database is kept local to the specific ELDK installation, which allows you to have multiple independent ELDK installations on your host system. (That is, you can install several instances of ELDK under different directories and work with them independently). Also, this provides for easy installation and management of individual ELDK packages.

To list the installed ELDK RPM packages, use the following command:

bash$ ${CROSS_COMPILE}rpm -qa

To remove an ELDK 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 multiple ELDK installations and RedHat-based host system, there may well be several rpm tools installed on the host system.

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 of a ELDK installation, it is the ELDK's rpm utility that gets actually invoked. The rpm utility is located in the bin subdirectory relative to the ELDK root installation directory.

To avoid confusion with the host OS (RedHat) rpm utility, the ELDK creates symlinks to its rpm binary with the names such that it could be invoked using the ${CROSS_COMPILE}rpm notation, for all supported $CROSS_COMPILE values.

The standard (host OS) rpm utility allows various macros and configuration parameters to specified in user-specific ~/.rpmrc and ~/.rpmmacros files. The ELDK rpm tool also has this capability, but the names of the user-specific configuration files are ~/.eldk_rpmrc and ~/.eldk_rpmmacros, respectively.

3.4.5. Removal of the Entire Installation

To remove the entire ELDK installation, use the following command while in the ELDK root directory:

bash$ rm -rf <dir>

where <dir> specifies the root directory of the ELDK to be removed.

3.5. Working with ELDK

After the initial installation is complete, all you have to do to start working with the ELDK is to set and export the CROSS_COMPILE environment variable. Optionally, you may wish to add the bin and usr/bin directories of your ELDK installation to the value of your PATH environment variable. For instance, a sample ELDK installation and usage scenario looks as follows:

  • Create a new directory where the ELDK 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=ppc_8xx-

    The trailing '-' character in the CROSS_COMPILE variable value is optional and has no effect on the cross tools behavior.

  • Add the directories /opt/eldk/usr/bin and /opt/eldk/bin to PATH:
    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 ppc-linux- for example:
    bash$ ppc-linux-gcc -o hello_world hello_world.c

  • or, equivalently:
    bash$ /opt/eldk/usr/ppc-linux/bin/gcc -o hello_world hello_world.c

The value of the CROSS_COMPILE variable must correspond to the target CPU family you want the cross tools to work for. Refer to the table below for the supported CROSS_COMPILE variable values:

3.5.A Table of possible values for $CROSS_COMPILE

CROSS_COMPILE Value Predefined Compiler Flag FPU present or not
ppc_4xx- -mcpu=403 No
ppc_4xxFP- -mcpu=405fp Yes
ppc_6xx- -mcpu=603 Yes
ppc_74xx- -mcpu=7400 Yes
ppc_8xx- -mcpu=860 No
ppc_85xx- -mcpu=8540 Yes
For compatibility with older versions of the ELDK and with other toolkits the following values for $CROSS_COMPILE can be used, too: ppc_7xx- and ppc_82xx-. These are synonyms for ppc_6xx.

3.5.1. Switching Between Multiple Installations

No special actions are required from the user to switch between multiple ELDK installations on the same host system. Which ELDK 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 ppc-linux-gcc compiler binary has been installed, is a part of the PATH environment variable. The user types the command as follows:

$ ppc_8xx-gcc -c myfile.c

To load the correct include files, find the correct libraries, spec files, etc., the compiler needs to know the ELDK root directory. The compiler determines this information by analyzing the shell command it was invoked with ( ppc_8xx-gcc - without 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 ELDK, 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.

3.6. Mounting Target Components via NFS

The target components of the ELDK can be mounted via NFS as the root file system for your target machine. For instance, for an 8xx-based target, and assuming the ELDK has been installed into the /opt/eldk directory, you can use the following directory as the NFS-based root file system:

/opt/eldk/ppc_8xx

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 ELDK provides a script named ELDK_MAKEDEV, which is located in the root of the ELDK distribution ISO image. The script acccepts the following optional arguments:

-d <dir> Specifies the root directory of the ELDK being installed. If omitted, then the current directory is assumed.
-a <cpu_family> Specifies the target CPU family directory. If omitted, all installed target architecture directories will be populated with the device nodes.
-h Prints usage.
NOTE: Compared to older versions of the ELDK, options and behaviour of this command have been changed significantly. Please read the documentation.

Some of the target utilities included in the ELDK, 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 ELDK on the host system. However, for these utilities to work properly, they must have superuser privileges. This means that if the ELDK was not installed by the superuser, the file owner of the target ELDK 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 ELDK distribution image contains an ELDK_FIXOWNER script, which you can use to change file owners of all the appropriate files of the ELDK 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 the ELDK 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 ELDK distribution is being installed, is already populated with other ELDK distributions, the execution of the ELDK_FIXOWNER script without arguments will make the script work with all installed ELDK target architecture directories. This could take some time. To save the time, please use the -a argument to specify the appropriate target architecture. For instance:

# cd /opt/eldk# /mnt/cdrom/ELDK_FIXOWNER -a ppc_8xx

3.7. Rebuilding ELDK Components

3.7.1. ELDK Source Distribution

The ELDK is distributed with the full sources of all the components, so you may rebuild any ELDK 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 ELDK environment. This can be done using the following command:

$ ${CROSS_COMPILE}rpm -i /mnt/cdrom/SRPMS/<source_rpm_file_name>.src.rpm

After an ELDK 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 ELDK.

3.7.2. Rebuilding Target Packages

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 from the ELDK environment:

bash$ ${CROSS_COMPILE}rpmbuild -ba <package_name>.spec

In order for the rebuilding process to work correctly, the following conditions must be true:

  • The $CROSS_COMPILE environment variable must be set as appropriate for the target CPU family.
  • The <ELDK_root>/usr/ppc-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 ELDK cross compiler is invoked, rather than the host gcc.

3.7.3. Rebuilding ELDT Packages

All the ELDT packages allow for rebuilding from the provided source RPM packages using the following command from the ELDK 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 true:

  • The $CROSS_COMPILE environment variable must NOT be set.
  • Do NOT use the $CROSS_COMPILE command prefix.
  • The <ELDK_root>/usr/ppc-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 ELDK cross compiler.

3.8. ELDK Packages

3.8.1. List of ELDT Packages

Package Name Package Version
crosstool 0.35-9
gdb 6.3.0.0-1.21_3
genext2fs 1.3-8
ldd 0.1-1
make 3.80-7_1
make-doc 3.80-7_1
mkcramfs 0.0.1-1
mkimage 1.2.0-1
mtd_utils 2-2
rpm 4.4.1-21_5
rpm-build 4.4.1-21_5

Note: The crosstool 0.35 ELDT package provides the following packages: gcc 4.0.0, gcc-c++ 4.0.0, cpp 4.0.0 and binutils 2.16.1. For more information about the crosstool package please refer to http://kegel.com/crosstool.

3.8.2. List of Target Packages

Package Name Package Version
appWeb 1.2.2-1_6
autoconf 2.59-5_1
bash 3.0-31_2
binutils 2.16.1-2
boa 0.94.14rc19-2
busybox 1.3.0-1
byacc 1.9-29_1
bzip2 1.0.2-16_1
bzip2-devel 1.0.2-16_1
bzip2-libs 1.0.2-16_1
coreutils 5.2.1-48.1_1
cpio 2.6-7_1
cpp 4.0.0-4
cracklib 2.8.2-1
cracklib-dicts 2.8.2-1
crosstool 0.35-9
db4 4.3.27-3_1
db4-devel 4.3.27-3_1
db4-utils 4.3.27-3_1
dhclient 3.0.2-12_2
dhcp 3.0.2-12_2
diffutils 2.8.1-15_2
dosfstools 2.10-3_1
dropbear 0.43-1_2
e2fsprogs 1.38-0.FC4.1_2
e2fsprogs-devel 1.38-0.FC4.1_2
expat 1.95.8-6_1
expat-devel 1.95.8-6_1
file 4.13-4_1
findutils 4.2.20-1_1
flex 2.5.4a-34_1
ftp 0.17-26_1
gawk 3.1.4-5_1
gcc 4.0.0-4
gcc-c++ 4.0.0-4
gdb 6.3.0.0-1.21_4
glib 1.2.10-16_1
glib2 2.6.6-1_1
glib2-devel 2.6.6-1_1
glib-devel 1.2.10-16_1
grep 2.5.1-48.2_1
groff 1.18.1.1-5_1
gzip 1.3.5-6_1
httpd 2.0.54-10.2_2
httpd-devel 2.0.54-10.2_2
httpd-manual 2.0.54-10.2_2
initscripts 8.11.1-1_3
iproute 2.6.11-1_1
iputils 20020927-22_2
kernel-headers 2.6.19-1
kernel-source 2.6.19-1
krb5-devel 1.4.1-5_2
krb5-libs 1.4.1-5_2
less 382-7_1
libcap 1.10-22_1
libcap-devel 1.10-22_1
libtermcap 2.0.8-41_1
libtermcap-devel 2.0.8-41_1
libtool 1.5.16.multilib2-2_2
libtool-ltdl 1.5.16.multilib2-2_2
libuser 0.53.7-1_2
libuser-devel 0.53.7-1_2
logrotate 3.7.1-10_2
lrzsz 0.12.20-21_1
m4 1.4.3-1_2
mailcap 2.1.19-1_1
make 3.80-7_1
man 1.5p-4_1
microwindows 0.90-7
microwindows-fonts 0.90-1
mingetty 1.07-5_1
mktemp 1.5-23_1
module-init-tools 3.1-4_1
modutils 2.4.22-8_2
modutils-devel 2.4.22-8_2
mtd_utils 1-4
ncompress 4.2.4-42_1
ncurses 5.4-17_1
ncurses-devel 5.4-17_1
net-snmp 5.2.1.2-1_2
net-snmp-devel 5.2.1.2-1_2
net-snmp-libs 5.2.1.2-1_2
net-snmp-utils 5.2.1.2-1_2
net-tools 1.60-52_2
nfs-utils 1.0.7-12_3
ntp 4.2.0.a.2004061-8_1
openssl 0.9.7f-7.10_1
openssl-devel 0.9.7f-7.10_1
pam 0.79-9.5_2
pam-devel 0.79-9.5_2
passwd 0.69-3_2
patch 2.5.4-24_1
pciutils 2.1.99.test8-10_1
pciutils-devel 2.1.99.test8-10_1
pcmcia-cs 3.2.8-1_1
popt 1.7-3
portmap 4.0-65_2
procps 3.2.5-6.3_2
psmisc 21.5-5_2
rdate 1.4-4_1
readline 5.0-3_1
readline-devel 5.0-3_1
routed 0.17-12_1
rpm 4.4.1-22_4
rpm-build 4.4.1-22_4
rpm-devel 4.4.1-22_4
rpm-libs 4.4.1-22_4
rsh 0.17-29_1
rsh-server 0.17-29_1
sed 4.1.4-1_1
SELF 1.0-11
setup 2.5.44-1.1_1
slang 1.4.9-17_2
slang-devel 1.4.9-17_2
strace 4.5.11-1_3
sysklogd 1.4.1-30_2
SysVinit 2.85-39_1
tar 1.15.1-10_2
tcp_wrappers 7.6-39_2
telnet 0.17-35_1
telnet-server 0.17-35_1
termcap 5.4-7_1
tftp 0.40-6_1
tftp-server 0.40-6_1
u-boot 1.2.0-1
util-linux 2.12p-9.12_3
vim-common 6.3.086-0_1
vim-minimal 6.3.086-0_1
wireless-tools 28-1_1
wu-ftpd 2.6.1-3
xenomai 2.3.0-1
xinetd 2.3.13-6_2
zlib 1.2.2.2-3_1
zlib-devel 1.2.2.2-3_1

Note 1: Not all packages will be installed automatically; 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.35 target package provides the following packages: glibc 2.3.5, glibc-common 2.3.5, glibc-devel 2.3.5, libstdc++ 4.0.0 and libstdc++-devel 4.0.0. For more information about the crosstool package please refer to http://kegel.com/crosstool

3.9. Rebuilding the ELDK from Scratch

In this section, you will find instructions on how to build the ELDK from scratch, using the pristine package sources available on the Internet, and patches, spec files, and build scripts provided on the ELDK source CD-ROM.

3.9.1. ELDK Build Process Overview

The ELDK uses the Fedora Core 4 Linux distribution as source code reference. Any modifications to Fedora Core's sources the ELDK has introduced are in the form of patches applied by the RPM tool while building the packages. Also, the ELDK uses modified spec files for its RPM packages. So, the sources of almost every ELDK package consist of the following parts:

  • Fedora Core pristine sources (SRPMs) or
  • ELDK source tarball,
  • ELDK patches,
  • ELDK spec file.

The Fedora Core pristine sources may be obtained from the Internet, see http://download.fedora.redhat.com/pub/fedora/linux.

The ELDK patches and spec files are available on the ELDK source CD-ROM and from the DENX =git= repository.

Please use the following commands to check out a copy of one of the modules:

$ git-clone git://www.denx.de/git/module_name  your_repository_name/

The following ELDK repositories are available:

Module Name Contents
eldk/build.git Build tools, patches, and spec files
eldk/tarballs.git Source tarballs
eldk/SRPMS.git Source Packages (SRPMS)

After cloning the repository, you can use standard =git= commands to check out any specific release of the ELDK; for example, to get the files for ELDK release 4.1, please run the command

$ git-checkout ELDK_4_1

It must be noted that some of the packages which are included in the ELDK are not included in Fedora Core. Examples of such packages are appWeb, microwindows, and wu-ftpd. For these packages tarballs are provided in the DENX git repository. We also provide a copy of the original Fedora SRPMS to make sure these remain available permanently.

To facilitate building of the ELDK, 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 ELDK build procedure. It is the tool that you would normally use to build the ELDK from scratch. In the simplest case, the script may be invoked without arguments, and it will perform all necessary steps to build the ELDK in a fully automated way. You may pass the following optional arguments to the ELDK_BUILD script:

-d <arch> target architecture: "ppc", "arm" or "mips", 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
-p <build_dir> (optional) the name of a directory that will be used to store all the build results; used for out-of-tree building
-u build the uClibc-based ELDK version.

Warning: The ELDK 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 3.9.3. build.sh Usage below for more details.

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 ELDK. The SRPMS.lst file contains the list of the Fedora Core source RPM packages used during the ELDK build. The tarballs.lst file contains the list of source tarballs of the packages that are included in the ELDK but are not present in Fedora Core 4.

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 CVS (see section 3.9.2. Setting Up ELDK Build Environment below for details) or copied from the ELDK 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                               Makefile                       misc/ELDK_MAKEDEV                            ELDK_FIXOWNER                            README.html                       cpkgs.lst                       tpkgs.lst                       build.sh                       ELDK_BUILD                       SRPMS.lst                       tarballs.lst                 tarballs/....                 SRPMS/....

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 ELDK but are not present in Fedora Core 4.

The SRPMS directory may contain the source RPM packages of Fedora Core 4. If some (or all) of the Fedora Core SRPMs needed for the build are missing in the directory, the ELDK_BUILD script will download the source RPMs automatically from the Internet.

The ELDK build environment CD-ROM provides a ready-to-use ELDK build environment. Please refer to section 3.9.2. Setting Up ELDK 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 ELDK build environment. If the variable is not set when the script is invoked, it is assumed that the root directory of the ELDK build environment is /opt/eldk. To build the ELDK in 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 ELDK build environment:

build/<build_name>/work/            - full ELDK environmentbuild/<build_name>/logs/             - build procedure log filesbuild/<build_name>/results/b_cdrom/  - binary cdrom tree, ready for mkisofs                   results/s_cdrom/  - source 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.

3.9.2. Setting Up ELDK Build Environment

For your convenience, the ELDK build environment CD-ROM provides full ELDK 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 ELDK 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/eldkbash$ cp -r /mnt/cdrom/* .

These commands will create the directory structure as described in section 3.9.1. ELDK Build Process Overview above. All necessary scripts and ELDK 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 Core 4 SRPMS needed to build the ELDK.

Alternatively, you can obtain the ELDK build environment from the DENX git repository. Three modules are provided: eldk/build.git, eldk/tarballs.git and eldk/SRPMS.git. The first one contains the files for the build subdirectory in the build environment; the second one contains source tarballs of the packages that are included in the ELDK but are not present in Fedora, and the last one contains the original Fedora SRPMS. To create the ELDK build environment from the DENX git repository, please use the following commands (the example below assumes that the root directory of the build environment is /opt/eldk):

$ cd /opt/eldk$ git clone git://www.denx.de/git/eldk/build.git build$ git clone git://www.denx.de/git/eldk/tarballs.git tarballs$ git clone git://www.denx.de/git/eldk/SRPMS.git SRPMS

Any Fedora source RPM packages that should be missing will, if required, be automatically downloaded by the ELDK_BUILD script.

3.9.3. build.sh Usage

If you wish to perform only a part of the ELDK 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

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

-a <arch> target architecture: "ppc", "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 build overview 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.
-w <work> 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.

By default, the invocation of build.sh assumes that the Glibc-based ELDK version is being built. For the uClibc-based ELDK build, set the UCLIBC environment variable to 1 prior to running build.sh :

bash$ export UCLIBC=1

Please note that you must never use build.sh to build the ELDK 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 build.

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 CPU variants the packages must be built for. Possible CPU variants are 4xx, 4xxFP, 6xx, 74xx, 8xx and 85xx. For example, the command below rebuilds the target RPM listed in the tpckgs.lst file under the number of 47 (see section 3.9.4. Format of the cpkgs.lst and tpkgs.lst Files for description of the tpckgs.lst and cpkgs.lst files), for the 8xx and 85xx CPUs:

bash$ TARGET_CPU_FAMILY_LIST="8xx 85xx" \> /opt/eldk/build.sh -a ppc \>                    -n 2007-01-19 \>                    -p /opt/eldk/build/ppc-2007-01-19 \>                    -r /opt/eldk/build/ppc-2007-01-19/results \>                    -w /opt/eldk/build/ppc-2007-01-19/work \>                    trg 47 47

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 ELDK 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 ELDK. For debugging purposes, it is much more convenient and efficient to build both ELDT and target packages using a working ELDK installation, as described in the sections 3.7.2. Rebuilding Target Packages and 3.7.3. Rebuilding ELDT Packages above.

3.9.4. Format of the cpkgs.lst and tpkgs.lst Files

Each line of these files has the following format:

<sub_step_number> <package_name> <spec_file_name> <binary_package_name> <package_version>

The ELDK source CD-ROM contains the cpkgs.lst and tpkgs.lst files used to build this version of the ELDK distribution. Use them as reference if you want to include any additional packages into the ELDK, or remove unneeded packages.

To add a package to the ELDK 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 ELDK 4.0 on non-Fedora hosts. These packages will be built and used during the build process, but will not be put into the ELDK 4.0 distribution ISO images.

3.10. Notes for Solaris 2.x Host Environment

If you use a Solaris 2.x host environment, you need additional freeware packages (mostly GNU tools) to install and especially to build the ELDK packages. The following table lists all required packages that must be installed on the Solaris host system before attempting to build and/or install the ELDK. All these files except those marked with (**) (and the RPM and zlib-1.1.2 packages, which are available at ftp://rpmfind.net/linux/solaris are available for free download at ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/

Necessary Freeware Packages:

Package Version Instance File Name
autoconf(**) 2.13 SMCautoc autoconf-2.13-sol26-sparc-local.gz
automake(**) 1.4 SMCautom automake-1.4-sol26-sparc-local.gz
bash 2.05 SMCbash bash-2.05-sol26-sparc-local.gz
binutils 2.11.2 SMCbinut binutils-2.11.2-sol26-sparc-local.gz
bison 1.28 SMCbison bison-1.28-sol26-sparc-local.gz
bzip2 1.0.1 SMCbzip2 bzip2-1.0.1-sol26-sparc-local.gz
ddd(*) 3.0 TUBddd ddd-3.0-sol26-sparc-local.gz
diffutils 2.7 GNUdiffut diffutils-2.7-sol26-sparc-local.gz
expect(*) 5.25 NTexpect expect-5.25-sol26-sparc-local.gz
fileutils 4.0 SMCfileu fileutils-4.0-sol26-sparc-local.gz
flex 2.5.4a FSFflex flex-2.5.4a-sol26-sparc-local.gz
gawk 3.1.0 SMCgawk gawk-3.1.0-sol26-sparc-local.gz
gcc 2.95.3 SMCgcc gcc-2.95.3-sol26-sparc-local.gz
gettext 0.10.37 SMCgtext gettext-0.10.37-sol26-sparc-local.gz
gzip 1.3 SMCgzip gzip-1.3-sol26-sparc-local
libiconv 1.6.1 SMClibi libiconv-1.6.1-sol26-sparc-local.gz
libtool 1.4 SMClibt libtool-1.4-sol26-sparc-local.gz
m4 1.4 SMCm4 m4-1.4-sol26-sparc-local.gz
make(**) 3.79.1 SMCmake make-3.79.1-sol26-sparc-local.gz
ncurses 5.2 SMCncurs ncurses-5.2-sol26-sparc-local.gz
patch 2.5 FSFpatch patch-2.5-sol26-sparc-local.gz
perl(**) 5.005_03 SMCperl perl-5.005_03-sol26-sparc-local.gz
python 1.5.2 SMCpython python-1.5.2-sol26-sparc-local.gz
rpm 2.5.2 RPM rpm-2.5.2.pkg
sed 3.02 SMCsed sed-3.02-sol26-sparc-local.gz
tar 1.13.19 SMCtar tar-1.13.19-sol26-sparc-local.gz
tcl(*) 8.3.3 SMCtcl tcl-8.3.3-sol26-sparc-local.gz
texinfo 4.0 SMCtexi texinfo-4.0-sol26-sparc-local.gz
textutils 2.0 SMCtextu textutils-2.0-sol26-sparc-local.gz
unzip 5.32 IZunzip unzip-5.32-sol26-sparc-local.gz
wget 1.7 SMCwget wget-1.7-sol26-sparc-local.gz
zlib(**) 1.0.4 SMCzlib zlib-1.0.4-sol26-sparc-local.gz
zlib 1.1.2 - zlib-1.1.2.tar.gz

The packages marked "(*)" are not absolutely required, but sooner or later you will need them anyway so we recommend to install them.

The packages marked "(**)" are older versions of the ones currently available at ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/. You can obtain them from the DENX public FTP server.

The following symbolic links must be created in order to be able to build the ELDK on a Solaris machine:

/usr/local/bin/cc  --> /usr/local/bin/gcc/usr/lib/libiconv.so.2 --> /usr/local/lib/libiconv.so.2/usr/lib/libncurses.so.5 --> /usr/local/lib/libncurses.so.5

Additionally, to be able to build the ELDK on Solaris, you must place newer GNU gettext macros to the /usr/local/share/aclocal directory. This can be accomplished as follows:

 

 

 

 

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 BB 的頭像
    BB

    Welkin小窩

    BB 發表在 痞客邦 留言(0) 人氣()