ELDK(Embedded+Linux+Development+Kit+)手册_甜梦文库
ELDK(Embedded+Linux+Development+Kit+)手册
The DENX U-Boot and Linux Guide (DULG) for canyonlandsTable of contents: ? 1. Abstract ? 2. Introduction ? 2.1. Copyright ? 2.2. Disclaimer ? 2.3. Availability ? 2.4. Credits ? 2.5. Translations ? 2.6. Feedback ? 2.7. Conventions ? 3. Embedded Linux Development Kit ? 3.1. ELDK Availability ? 3.2. Supported Host Systems ? 3.3. Supported Target Architectures ? 3.4. Installation ? 3.4.1. Product Packaging ? 3.4.2. Downloading the ELDK ? 3.4.3. Initial Installation ? 3.4.4. Installation and Removal of Individual Packages ? 3.4.5. Removal of the Entire Installation ? 3.5. Working with ELDK ? 3.5.1. Switching Between Multiple Installations ? 3.6. Mounting Target Components via NFS ? 3.7. Rebuilding ELDK Components ? 3.7.1. ELDK Source Distribution ? 3.7.2. Rebuilding Target Packages ? 3.7.3. Rebuilding ELDT Packages ? 3.8. ELDK Packages ? 3.8.1. List of ELDT Packages ? 3.8.2. List of Target Packages ? 3.9. Rebuilding the ELDK from Scratch ? 3.9.1. ELDK Build Process Overview ? 3.9.2. Setting Up ELDK Build Environment ? 3.9.3. build.sh Usage ? 3.9.4. Format of the cpkgs.lst and tpkgs.lst Files ? 3.10. Notes for Solaris 2.x Host Environment ? 4. System Setup ? 4.1. Serial Console Access ? 4.2. Configuring the &cu& command ? 4.3. Configuring the &kermit& command ? 4.4. Using the &minicom& program ? 4.5. Permission Denied Problems ? 4.6. Configuration of a TFTP Server ? 4.7. Configuration of a BOOTP / DHCP Server ? 4.8. Configuring a NFS Server ? 5. Das U-Boot ? 5.1. Current Versions ? 5.2. Unpacking the Source Code ? 5.3. Configuration The DENX U-Boot and Linux Guide (DULG) for canyonlands 1? 5.4. Installation ? 5.4.1. Before You Begin ? 5.4.1.1. Installation Requirements ? 5.4.1.2. Board Identification Data ? 5.4.2. Installation Using a BDM/JTAG Debugger ? 5.4.3. Installation using U-Boot ? 5.5. Tool Installation ? 5.6. Initialization ? 5.7. Initial Steps ? 5.8. The First Power-On ? 5.9. U-Boot Command Line Interface ? 5.9.1. Information Commands ? 5.9.1.1. bdinfo - print Board Info structure ? 5.9.1.2. coninfo - print console devices and informations ? 5.9.1.3. flinfo - print FLASH memory information ? 5.9.1.4. iminfo - print header information for application image ? 5.9.1.5. help - print online help ? 5.9.2. Memory Commands ? 5.9.2.1. base - print or set address offset ? 5.9.2.2. crc32 - checksum calculation ? 5.9.2.3. cmp - memory compare ? 5.9.2.4. cp - memory copy ? 5.9.2.5. md - memory display ? 5.9.2.6. mm - memory modify (auto-incrementing) ? 5.9.2.7. mtest - simple RAM test ? 5.9.2.8. mw - memory write (fill) ? 5.9.2.9. nm - memory modify (constant address) ? 5.9.2.10. loop - infinite loop on address range ? 5.9.3. Flash Memory Commands ? 5.9.3.1. cp - memory copy ? 5.9.3.2. flinfo - print FLASH memory information ? 5.9.3.3. erase - erase FLASH memory ? 5.9.3.4. protect - enable or disable FLASH write protection ? 5.9.3.5. mtdparts - define a Linux compatible MTD partition scheme ? 5.9.4. Execution Control Commands ? 5.9.4.1. autoscr - run script from memory ? 5.9.4.2. bootm - boot application image from memory ? 5.9.4.3. go - start application at address 'addr' ? 5.9.5. Download Commands ? 5.9.5.1. bootp - boot image via network using BOOTP/TFTP protocol ? 5.9.5.2. dhcp - invoke DHCP client to obtain IP/boot params ? 5.9.5.3. loadb - load binary file over serial line (kermit mode) ? 5.9.5.4. loads - load S-Record file over serial line ? 5.9.5.5. rarpboot- boot image via network using RARP/TFTP protocol ? 5.9.5.6. tftpboot- boot image via network using TFTP protocol ? 5.9.6. Environment Variables Commands ? 5.9.6.1. printenv- print environment variables ? 5.9.6.2. saveenv - save environment variables to persistent storage ? 5.9.6.3. setenv - set environment variables ? 5.9.6.4. run - run commands in an environment variable ? 5.9.6.5. bootd - boot default, i.e., run 'bootcmd' ? 5.9.7. Flattened Device Tree support ? 5.9.7.1. fdt addr - select FDT to work on ? 5.9.7.2. fdt list - print one level The DENX U-Boot and Linux Guide (DULG) for canyonlands 2? 5.9.7.3. fdt print - recursive print ? 5.9.7.4. fdt mknode - create new nodes ? 5.9.7.5. fdt set - set node properties ? 5.9.7.6. fdt rm - remove nodes or properties ? 5.9.7.7. fdt move - move FDT blob to new address ? 5.9.7.8. fdt chosen - fixup dynamic info ? 5.9.8. Special Commands ? 5.9.8.1. i2c - I2C sub-system ? 5.9.9. Storage devices ? 5.9.10. Miscellaneous Commands ? 5.9.10.1. echo - echo args to console ? 5.9.10.2. reset - Perform RESET of the CPU ? 5.9.10.3. sleep - delay execution for some time ? 5.9.10.4. version - print monitor version ? 5.9.10.5. ? - alias for 'help' ? 5.10. U-Boot Environment Variables ? 5.11. U-Boot Scripting Capabilities ? 5.12. U-Boot Standalone Applications ? 5.12.1. &Hello World& Demo ? 5.12.2. Timer Demo ? 5.13. U-Boot Image Formats ? 5.14. U-Boot Advanced Features ? 5.14.1. Boot Count Limit ? 5.14.2. Bitmap Support ? 5.14.3. Splash Screen Support ? 6. Embedded Linux Configuration ? 6.1. Download and Unpack the Linux Kernel Sources ? 6.2. Kernel Configuration and Compilation ? 6.3. Installation ? 7. Booting Embedded Linux ? 7.1. Introduction ? 7.2. Flattened Device Tree Blob ? 7.3. Passing Kernel Arguments ? 7.4. Boot Arguments Unleashed ? 7.5. Networked Operation with Root Filesystem over NFS ? 7.5.1. Bootlog of Linux kernel with Root Filesystem over NFS ? 7.6. Boot from Flash Memory ? 7.7. Standalone Operation with Ramdisk Image ? 8. Building and Using Modules ? 9. Advanced Topics ? 9.1. Flash Filesystems ? 9.1.1. Memory Technology Devices ? 9.1.2. Journalling Flash File System ? 9.1.3. Second Version of JFFS ? 9.1.4. Compressed ROM Filesystem ? 9.2. The TMPFS Virtual Memory Filesystem ? 9.2.1. Mount Parameters ? 9.2.2. Kernel Support for tmpfs ? 9.2.3. Usage of tmpfs in Embedded Systems ? 9.3. Adding Swap Space ? 9.4. Splash Screen Support in Linux ? 9.5. Root File System: Design and Building ? 9.5.1. Root File System on a Ramdisk ? 9.5.2. Root File System on a JFFS2 File System The DENX U-Boot and Linux Guide (DULG) for canyonlands 3? 9.5.3. Root File System on a cramfs File System ? 9.5.4. Root File System on a Read-Only ext2 File System ? 9.5.5. Root File System on a Flash Card ? 9.5.6. Root File System in a Read-Only File in a FAT File System ? 9.6. Root File System Selection ? 9.7. Overlay File Systems ? 9.8. The Persistent RAM File system (PRAMFS) ? 9.8.1. Mount Parameters ? 9.8.2. Example ? 10. Debugging ? 10.1. Debugging of U-Boot ? 10.1.1. Debugging of U-Boot Before Relocation ? 10.1.2. Debugging of U-Boot After Relocation ? 10.2. Linux Kernel Debugging ? 10.2.1. Linux Kernel and Statically Linked Device Drivers ? 10.2.2. Dynamically Loaded Device Drivers (Modules) ? 10.2.3. GDB Macros to Simplify Module Loading ? 10.3. GDB Startup File and Utility Scripts ? 10.4. Tips and Tricks ? 10.5. Application Debugging ? 10.5.1. Local Debugging ? 10.5.2. Remote Debugging ? 10.6. Debugging with Graphical User Interfaces ? 11. Simple Embedded Linux Framework ? 12. Books, Mailing Lists, Links, etc. ? 12.1. Application Notes ? 12.2. Further Reading ? 12.2.1. Linux kernel ? 12.2.2. General Linux / Unix programming ? 12.2.3. Network Programming ? 12.2.4. C++ programming ? 12.2.5. Java programming ? 12.2.6. PowerPC Programming ? 12.2.7. Embedded Topics ? 12.3. Mailing Lists ? 12.4. Links ? 12.5. Tools ? 13. Appendix ? 13.1. Flat Device Tree ? 13.2. BDI2000 Configuration file ? 14. FAQ - Frequently Asked Questions ? 14.1. ELDK ? 14.1.1. ELDK Installation under FreeBSD ? 14.1.2. ELDK Installation Hangs ? 14.1.3. .gvfs: Permission Denied ? 14.1.4. Installation on Local Harddisk ? 14.1.5. ELDK Include Files Missing ? 14.1.6. Using the ELDK on a 64 bit platform ? 14.1.7. GDB Problems with BDI2000/BDI3000 on e500 Cores ? 14.1.8. [[ELDK Installation Aborts][ELDK 2.x Installation Aborts]] ? 14.2. U-Boot ? 14.2.1. Can U-Boot be configured such that it can be started in RAM? ? 14.2.2. Relocation cannot be done when using -mrelocatable ? 14.2.3. U-Boot crashes after relocation to RAM The DENX U-Boot and Linux Guide (DULG) for canyonlands 4? 14.2.4. Warning - bad CRC, using default environment ? 14.2.5. Wrong debug symbols after relocation ? 14.2.6. Decoding U-Boot Crash Dumps ? 14.2.7. Porting Problem: cannot move location counter backwards ? 14.2.8. U-Boot Doesn't Run after Upgrading my Compiler ? 14.2.9. How Can I Reduce The Image Size? ? 14.2.10. Erasing Flash Fails ? 14.2.11. Ethernet Does Not Work ? 14.2.12. Where Can I Get a Valid MAC Address from? ? 14.2.13. Why do I get TFTP timeouts? ? 14.2.14. Why is my Ethernet operation not reliable? ? 14.2.15. How the Command Line Parsing Works ? 14.2.15.1. Old, simple command line parser ? 14.2.15.2. Hush shell ? 14.2.15.3. Hush shell scripts ? 14.2.15.4. General rules ? 14.2.16. How can I load and uncompress a compressed image ? 14.2.17. My standalone program does not work ? 14.2.18. Linux hangs after uncompressing the kernel ? 14.3. Linux ? 14.3.1. Linux crashes randomly ? 14.3.2. Linux crashes when uncompressing the kernel ? 14.3.3. Linux Post Mortem Analysis ? 14.3.4. Linux kernel register usage ? 14.3.5. Linux Kernel Ignores my bootargs ? 14.3.6. Cannot configure Root Filesystem over NFS ? 14.3.7. Linux Kernel Panics because &init& process dies ? 14.3.8. Unable to open an initial console ? 14.3.9. Mounting a Filesystem over NFS hangs forever ? 14.3.10. Ethernet does not work in Linux ? 14.3.11. Loopback interface does not work ? 14.3.12. Linux kernel messages are not printed on the console ? 14.3.13. Linux ignores input when using the framebuffer driver ? 14.3.14. How to switch off the screen saver and the blinking cursor? ? 14.3.15. BogoMIPS Value too low ? 14.3.16. Linux Kernel crashes when using a ramdisk image ? 14.3.17. Ramdisk Greater than 4 MB Causes Problems ? 14.3.18. Combining a Kernel and a Ramdisk into a Multi-File Image ? 14.3.19. Adding Files to Ramdisk is Non Persistent ? 14.3.20. Kernel Configuration for PCMCIA ? 14.3.21. Configure Linux for PCMCIA Cards using the Card Services package ? 14.3.22. Configure Linux for PCMCIA Cards without the Card Services package ? 14.3.22.1. Using a MacOS Partition Table ? 14.3.22.2. Using a MS-DOS Partition Table ? 14.3.23. Boot-Time Configuration of MTD Partitions ? 14.3.24. Use NTP to synchronize system time against RTC ? 14.3.25. Configure Linux for XIP (Execution In Place) ? 14.3.25.1. XIP Kernel ? 14.3.25.2. Cramfs Filesystem ? 14.3.25.3. Hints and Notes ? 14.3.25.4. Space requirements and RAM saving, an example ? 14.3.26. Use SCC UART with Hardware Handshake ? 14.3.27. How can I access U-Boot environment variables in Linux? ? 14.3.28. The =appWeb= server hangs *OR* /dev/random hangs The DENX U-Boot and Linux Guide (DULG) for canyonlands 5? 14.3.29. Swapping over NFS ? 14.4. Self ? 14.4.1. How to Add Files to a SELF Ramdisk ? 14.4.2. How to Increase the Size of the Ramdisk ? 14.5. RTAI ? 14.5.1. Conflicts with asm clobber list ? 14.6. BDI2000 ? 14.6.1. Where can I find BDI2000 Configuration Files? ? 14.6.2. How to Debug Linux Exceptions ? 14.6.3. How to single step through &RFI& instruction ? 14.6.4. Setting a breakpoint doesn't work ? 14.7. Motorola LITE5200 Board ? 14.7.1. LITE5200 Installation Howto ? 14.7.2. USB does not work on Lite5200 board ? 15. Glossary1. AbstractThis 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 canyonlands boards. This document was generated at 12 Apr 2009 - 08:45. ? 2. Introduction ? 2.1. Copyright ? 2.2. Disclaimer ? 2.3. Availability ? 2.4. Credits ? 2.5. Translations ? 2.6. Feedback ? 2.7. Conventions2. IntroductionThis 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.2. Introduction6In most cases you will want to load images into your t 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 canyonlands boards.2.1. CopyrightCopyright (C) 2001 - 2008 by Wolfgang Denk, DENX Software Engineering. Copyright (C) 2003 - 2008 by Detlev Zundel, DENX Software Engineering. Copyright (C) 2003 - 2008 by contributing authors 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. DisclaimerUse 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. AvailabilityThe latest version of this document is available in a number of formats:2.1. Copyright7? HTML http://www.denx.de/wiki/publish/DULG/DULG-canyonlands.html ? plain ASCII text http://www.denx.de/wiki/publish/DULG/DULG-canyonlands.txt ? PostScript European A4 format http://www.denx.de/wiki/publish/DULG/DULG-canyonlands.ps ? PDF European A4 format http://www.denx.de/wiki/publish/DULG/DULG-canyonlands.pdf2.4. CreditsA 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. TranslationsNone yet.2.6. FeedbackAny comments or suggestions can be mailed to the author: Wolfgang Denk at wd@denx.de.2.7. ConventionsDescriptions Warnings Hint Notes Information requiring special attention File Names Directory Names Commands to be typed Applications Names Prompt of users command under bash shell Prompt of root users command under bash shell Prompt of users command under tcsh shell Environment Variables Emphasized word Code Example AppearanceNote. Warning file.extension directory a command another application bash$ bash# tcsh$ VARIABLE word ls -l? 3. Embedded Linux Development Kit ? 3.1. ELDK Availability ? 3.2. Supported Host Systems ? 3.3. Supported Target Architectures ? 3.4. Installation ? 3.4.1. Product Packaging ? 3.4.2. Downloading the ELDK ? 3.4.3. Initial Installation ? 3.4.4. Installation and Removal of Individual Packages ? 3.4.5. Removal of the Entire Installation ? 3.5. Working with ELDK ? 3.5.1. Switching Between Multiple Installations ? 3.6. Mounting Target Components via NFS 2.3. Availability 8? 3.7. Rebuilding ELDK Components ? 3.7.1. ELDK Source Distribution ? 3.7.2. Rebuilding Target Packages ? 3.7.3. Rebuilding ELDT Packages ? 3.8. ELDK Packages ? 3.8.1. List of ELDT Packages ? 3.8.2. List of Target Packages ? 3.9. Rebuilding the ELDK from Scratch ? 3.9.1. ELDK Build Process Overview ? 3.9.2. Setting Up ELDK Build Environment ? 3.9.3. build.sh Usage ? 3.9.4. Format of the cpkgs.lst and tpkgs.lst Files ? 3.10. Notes for Solaris 2.x Host Environment3. Embedded Linux Development KitThe 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. Some versions of ELDK (4.1) are 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 AvailabilityThe ELDK is available ? on DVD-ROM from DENX Computer Systems ? for download on the following server: FTP ftp://ftp.denx.de/pub/eldk/ HTTP http://www.denx.de/ftp/pub/eldk/? for download on the following mirrors: FTP ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/ ftp://mirror.switch.ch/mirror/eldk/ ftp://sunsite.utk.edu/pub/linux/eldk/ ftp://ftp.sunet.se/pub/Linux/distributions/eldk/ HTTP http://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/ http://mirror.switch.ch/ftp/mirror/eldk/ http://sunsite.utk.edu/ftp/pub/linux/eldk/ http://ftp.sunet.se/pub/Linux/distributions/eldk/3.1. ELDK Availability93.2. Supported Host SystemsThe ELDK can be installed onto and operate with the following operating systems: ? Fedora Core 4, 5, 6 Fedora 7, 8, 9 ? Red Hat Linux 7.3, 8.0, 9 ? SuSE Linux 8.x, 9.0, 9.1, 9.2, 9.3 ? OpenSUSE 10.2, 10.3 (32 Bit); OpenSUSE 11.0 (32 and 64 Bit) ? Debian 3.0 (Woody), 3.1 (Sarge) and 4.0 (Etch) ? Ubuntu 4.10, 5.04, 6.10, 8.04 ? FreeBSD 5.0 Users also reported successful installation and use of the ELDK on the following host systems: ? Suse Linux 7.2, 7.3 ? Mandrake 8.2 ? Slackware 8.1beta2 ? Gentoo 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 Fedora Core systems, you can use one of yum, apt-get or up2date to keep your systems current.3.3. Supported Target ArchitecturesThe 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 PackagingStable versions of the ELDK 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). For the PowerPC target, the ELDK distribution was split into three independent ISO images: one targeting the 4xx family of processors (AMCC), one targeting the ppc64 family of processors and another one for the 8xx, 6xx, 74xx and 85xx families (Freescale). This makes the ISO images fit on standard DVDROM media.3.4.1. Product Packaging10If you are not bound by the DVDROM size limitiation there is still a single image containing all 32-bit targets (AMCC and Freescale). Development versions of the ELDK 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 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 ELDKYou 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 DVD-ROM. Change to a directory with suffic for the PowerPC version of the ELDK you need about 1.6 GiB, or twice as much (3.2 GiB) 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.2/ppc-linux-x86/iso/ppc-.iIf you want to download the whole ELDK directory tree instead you can - for example - use the ncftp FTP client:bash$ ... ncftp ncftp ncftp ... ncftp ncftp ftp.sunet.se / & cd /pub/Linux/distributions/eldk/4.2 /pub/Linux/distributions/eldk/4.2 & bin /pub/Linux/distributions/eldk/4.2 & get -R ppc-linux-x86/distribution /pub/Linux/distributions/eldk/4.2 & byeIf you don't find the ncftp tool on your system you can download the NcFTP client from /download/3.4.2. Downloading the ELDK11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 & doneNow create an ISO image from the directory tree:bash$ mkisofs \ & -A &ELDK-4.2 -- Target: PowerPC -- Host: x86 Linux& \ & -publisher &(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/distributionThis will create an ISO image eldk-ppc-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 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 InstallationThe 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 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 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. 3.4.3. Initial Installation 12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. Note: Installation of the 32-bit and 64-bit ELDK versions into one directory is not yet supported.3.4.4. Installation and Removal of Individual PackagesThe 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 -qaTo 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.4. Installation and Removal of Individual Packages133.4.5. Removal of the Entire InstallationTo 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 ELDKAfter 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_4xx-?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 to PATH:bash$ PATH=$PATH:/opt/eldk/usr/bin:/opt/eldk/bin? Compile a file:bash$ ${CROSS_COMPILE}gcc -o hello_world hello_world.cYou 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.cThe 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 not3.5. Working with ELDK14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 ppc64-linux-mcpu=powerpc64 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 InstallationsNo 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.cTo 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 NFSThe 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_8xxBefore 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.# /mnt/cdrom/ELDK_MAKEDEV -d /opt/eldk3.6. Mounting Target Components via NFS15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_FIXOWNERPlease 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_8xx3.7. Rebuilding ELDK Components3.7.1. ELDK Source DistributionThe 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.rpmAfter 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 PackagesAll 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.rpmThen you can rebuild the binary target RPM using the following command from the ELDK environment:3.7. Rebuilding ELDK Components16bash$ ${CROSS_COMPILE}rpmbuild -ba &package_name&.specIn 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 PackagesAll 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 Packages3.8.1. List of ELDT PackagesPackage Name autoconf automake bison crosstool-devel dtc elocaledef ftdump gdb genext2fs info ldd Package Version 2.61-8 1.10-5 2.3-3 0.43-3
6.7-2 1.4.1-1 4.8-15 0.1-13.8. ELDK Packages17libtool make mkcramfs mkimage mtd-utils rpm rpm-build sed texinfo1.5.22-11 3.81-6 1.1-1 1.3.1-1 1.0.1-2 4.4.2-46_2 4.4.2-46_2 4.1.4-1 4.8-15Note: 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 /crosstool.3.8.2. List of Target PackagesPackage Name acl appweb attr autoconf bash bc bind binutils binutils-devel boa busybox byacc bzip2 bzip2-devel bzip2-libs ccid chkconfig coreutils cpio cpp Package Version 2.2.39-3.1 2.2.2-5 2.4.32-2 2.61-8 3.2-9 1.06-26 9.4.1-8.P1 2.17.90-1 2.17.90-1 0.94.14-0.5.rc21 1.7.1-2 1.9. 1.0.4-10 1.0.4-10 1.0.4-10 1.2.1-10 1.3.34-1 6.9-3 2.6-27 4.2.2-2 183.8.1. List of ELDT Packagescracklib cracklib-dicts crosstool-targetcomponents curl cyrus-sasl cyrus-sasl-devel cyrus-sasl-lib db4 db4-devel db4-utils device-mapper device-mapper-devel device-mapper-libs dhclient dhcp diffutils directfb dosfstools dropbear dtc duma e2fsprogs e2fsprogs-devel e2fsprogs-libs ethtool expat expat-devel file file-libs findutils flex freetype freetype-devel ftdump2.8.9-11 2.8.9-11 0.43-3 7.16.2-1 2.1.22-6 2.1.22-6 2.1.22-6 4.5.20-5_2 4.5.20-5_2 4.5.20-5_2 1.02.17-7 1.02.17-7 1.02.17-7 3.0.5-38 3.0.5-38 2.8.1-16 1.0.0-1 2.11-8 0.50-1
2.5.8-2 1.39-11 1.39-11 1.39-11 5-1 1.95.8-9 1.95.8-9 4.21-1 4.21-1 4.2.29-2 2.5.33-9 2.3.4-3 2.3.4-3
193.8.2. List of Target Packagesftp gawk gcc gcc-c++ gcc-java gdb glib glib2 glib2-devel glib-devel gmp grep groff gzip hdparm httpd httpd-devel httpd-manual initscripts iproute iptables iputils iscsitarget kbd kernel-headers kernel-source krb5-devel krb5-libs less libattr libattr-devel libcap libcap-devel libpng0.17-40 3.1.5-15 4.2.2-2 4.2.2-2 4.2.2-2 6.7-1 1.2.10-26 2.12.13-1 2.12.13-1 1.2.10-26 4.1.4-12.3 2.5.1-57 1.18.1.4-2 1.3.11-2 6.9-3 2.2.4-4.1 2.2.4-4.1 2.2.4-4.1 8.54.1-1 2.6.20-2 1.3.8-2
0.4.15-1 1.12-22 2.6.24-1 2.6.24-1 1.6.1-2.1 1.6.1-2.1 394-9 2.4.32-2 2.4.32-2 1.10-29 1.10-29 1.2.16-1 203.8.2. List of Target Packageslibpng-devel libsysfs libsysfs-devel libtermcap libtermcap-devel libtirpc libtirpc-devel libtool libtool-ltdl libtool-ltdl-devel libusb libusb-devel libuser libuser-devel libxml2 logrotate lrzsz lsof ltp lvm2 m4 mailcap make MAKEDEV man mdadm microwindows microwindows-fonts mingetty mktemp module-init-tools mtd-utils ncompress ncurses1.2.16-1 2.1.0-1 2.1.0-1 2.0.8-46.1 2.0.8-46.1 0.1.7-7_2 0.1.7-7_2 1.5.22-11 1.5.22-11 1.5.22-11 0.1.12-7 0.1.12-7 0.56.2-1 0.56.2-1 2.6.29-1 3.7.5-3.1 0.12.20-22.1 4.78-5 -eldk2 2.02.24-1 1.4.8-2 2.1.23-1 3.81-6 3.23-1.2 1.6e-3 2.6.2-4 0.91-2 0.91-1 1.07-5.2.2 1.5-25 3.3-0.pre11.1.0 1.0.1-2 4.2.4-49 5.6-17 213.8.2. List of Target Packagesncurses-devel net-snmp net-snmp-devel net-snmp-libs net-snmp-utils net-tools newt newt-devel nfs-utils ntp open-iscsi openldap openldap-devel openssl openssl-devel oprofile pam pam-devel passwd patch pciutils pciutils-devel pcmciautils pcre pcsc-lite pcsc-lite-devel pcsc-lite-libs perl perl-libs popt portmap postgresql postgresql-devel postgresql-libs5.6-17 5.4-14 5.4-14 5.4-14 5.4-14 1.60-82 0.52.6-30 0.52.6-30 1.1.0-1 4.2.4p2-1 2.0-865.15 2.3.34-3 2.3.34-3 0.9.8b-12_2 0.9.8b-12_2 0.9.2-8_2 0.99.7.1-5.1 0.99.7.1-5.1 0.74-3 2.5.4-29.2.2 2.2.4-3_2 2.2.4-3_2 014-9_2 7.0-2 1.3.3-1.0 1.3.3-1.0 1.3.3-1.0 5.8.8-18_2 5.8.8-18_2 1.12-1 4.0-65_2 8.2.4-1_2 8.2.4-1_2 8.2.4-1_2 223.8.2. List of Target Packagesppp procps psmisc python rdate readline readline-devel routed rpcbind rpm rpm-build rpm-devel rpm-libs rsh rsh-server screen sed SELF setup shadow-utils slang slang-devel smartmontools strace sysfsutils sysklogd sysvinit tar tcp_wrappers tcp_wrappers-devel tcp_wrappers-libs telnet telnet-server termcap2.4.4-7 3.2.7-14 22.3-2 2.5.1-1 1.4-6 5.2-4 5.2-4 0.17-12_1 0.1.4-6 4.4.2-46_2 4.4.2-46_2 4.4.2-46_2 4.4.2-46_2 0.17-40 0.17-40 4.0.3-50 4.1.5-7 1.0-13 2.6.4-1_2 4.0.18.1-15 2.0.7-17 2.0.7-17 5.38-2 4.5.15-1 2.1.0-1 1.4.2-9 2.86-17 1.15.1-26 7.6-48 7.6-48 7.6-48 0.17-38 0.17-38 5.5-1. 233.8.2. List of Target Packagestftp tftp-server thttpd time u-boot udev unixODBC unzip util-linux vim-common vim-minimal vixie-cron vsftpd which wireless-tools wpa_supplicant wu-ftpd xdd xenomai xinetd zip zlib zlib-devel0.42-4 0.42-4 2.25b-13 1.7-29 1.3.1-1 106-4.1 2.2.12-2 5.52-4 2.13-0.52_2 7.1.12-1 7.1.12-1 4.1-82 2.0.5-16_2 2.16-8 28-4 0.5.7-3 2.6.2-1 65. 2.4.2-1 2.3.14-12 2.31-3 1.2.3-10 1.2.3-10Note 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 /crosstool Note 3: The Xenomai and gcc-java packages are unavailable in ARM ELDK version.3.9. Rebuilding the ELDK from ScratchIn 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. Rebuilding the ELDK from Scratch243.9.1. ELDK Build Process OverviewThe ELDK uses the Fedora 7 Linux distribution as source code reference. Any modifications to Fedora'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 pristine sources or ? ELDK source tarball, ? ELDK patches, ? ELDK spec file. The Fedora pristine sources may be obtained from the Internet, see http://download./pub/fedora/linux/core. The ELDK patches and spec files are available on the ELDK source 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/moduleThe following ELDK modules are available: Module Name tarballs build SRPMS Contents Source tarballs Build tools, patches, and spec files Fedora 7 sourcesThen you may switch to a specific release of the ELDK using the &git-checkout& for example, to get the files for ELDK release 4.1, please do the following from the module directory:git-checkout ELDK_4_2It must be noted that some of the packages which are included in the ELDK 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 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:3.9.1. ELDK Build Process Overview25-a &arch& -n &build_name& -v &version& -u -p &builddir&target architecture: &arm&, &ppc& or &ppc64&, defaults to &ppc&. 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 ELDK version string build the uClibc-based ELDK version (on the platforms and versions where this is available). Optional build directory. By default, build will place the work files and results in the current directory.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 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 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 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/.... 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 ELDK but are not present in Fedora 7. 3.9.1. ELDK Build Process Overview 26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. 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/ build/&build_name&/logs/ build/&build_name&/results/b_cdrom/ results/s_cdrom/ results/d_cdrom/ full ELDK environment build procedure log files binary cdrom tree, ready for mkisofs source cdrom tree, ready for mkisofs debuginfo cdrom tree, ready for mkisofsOn 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 EnvironmentFor 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/eldk bash$ 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 7 SRPMS needed to build the ELDK. Alternatively, you can obtain the ELDK build environment from the DENX GIT repository. Two modules are provided for check out: build and 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 ELDK but are not present in Fedora 7. To create the ELDK 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$ bash$ bash$ bash$ cd /opt/eldk git-clone git://www.denx.de/git/eldk/build git-clone git://www.denx.de/git/eldk/tarballs git-clone git://www.denx.de/git/eldk/SRPMS3.9.2. Setting Up ELDK Build Environment27Note: To allow to install the ELDK 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: http://www.denx.de/wiki/DULG/AN2009_02_EldkReleaseBuildEnvironment3.9.3. build.sh UsageIf 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 ? 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&]-a &arch& -n &build_name&target architecture: &ppc&, &ppc64&, &arm& or &mips&, defaults to &ppc&. 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. is the name of the directory that contains the build environment. Refer to build overview above for description of the build environment. 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. is the name of the build step that is to be performed. Refer to the list of the build procedure steps above.-p &prefix& -r &result& -w &work& &stepname&&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 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 3.9.3. build.sh Usage 28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, 85xx and ppc64. 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
\ & -p /opt/eldk/build/ppc- \ & -r /opt/eldk/build/ppc-/results \ & -w /opt/eldk/build/ppc-/work \ & trg 47 47Note: 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 FilesEach 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.2 on non-Fedora hosts. These packages will be built and used during the build process, but will not be put into the ELDK 4.2 distribution ISO images.3.10. Notes for Solaris 2.x Host EnvironmentIf 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 3.10. Notes for Solaris 2.x Host Environment 29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 /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 /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.23.10. Notes for Solaris 2.x Host Environment30/usr/lib/libncurses.so.5 --& /usr/local/lib/libncurses.so.5Additionally, 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: ? Download the http://www.ibiblio.org/pub/packages/solaris/sparc/GNUgettext.0.10.40.SPARC.32bit.Solaris.8.pkg.tgz package. ? Untar the package to a temporary directory and copy the macros to the /usr/local/share/aclocal directory:$ cp GNUgettext/root/usr/local/share/aclocal/*.m4 /usr/local/share/aclocal? 4. System Setup ? 4.1. Serial Console Access ? 4.2. Configuring the &cu& command ? 4.3. Configuring the &kermit& command ? 4.4. Using the &minicom& program ? 4.5. Permission Denied Problems ? 4.6. Configuration of a TFTP Server ? 4.7. Configuration of a BOOTP / DHCP Server ? 4.8. Configuring a NFS Server4. System SetupSome 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.4.1. Serial Console AccessTo 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.4.2. Configuring the &cu& commandThe 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. On RedHat systems you can check if the UUCP package is installed as follows:$ rpm -q uucpIf necessary, install the UUCP package from your distribution media.4. System Setup31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: # system S0@115200 port serial0_115200 time any? /etc/uucp/port:# # /dev/ttyS0 at 115200 bps: # port serial0_115200 type direct device /dev/ttyS0 speed 115200 hardflow falseYou 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.4.3. Configuring the &kermit& commandThe 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 robust set file type bin set file name lit set rec pack 1000 set send pack 1000 set window 54.2. Configuring the &cu& command32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: http://www.columbia.edu/kermit/4.4. Using the &minicom& programminicom 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.4.5. Permission Denied ProblemsThe 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 gr