head	1.4;
access;
symbols
	import-20090318:1.1.1.10
	import-20081205:1.1.1.10
	rel-8-1-2-sv:1.3
	import-20080404:1.1.1.9
	import-20071105:1.1.1.8
	import-20070116:1.1.1.7
	import-20061124:1.1.1.7
	rel-6-2-2-sv:1.1.1.6
	rel-6-2-1-sv:1.1.1.6
	import-20060615:1.1.1.6
	import-20060530:1.1.1.5
	import-20060516:1.1.1.4
	import-20060421:1.1.1.3
	import-20060406:1.1.1.3
	import-29mar06:1.1.1.3
	import-14mar06:1.1.1.3
	import-13mar06:1.1.1.3
	fixed-post-import-14feb06:1.1.1.3
	import-14feb06:1.1.1.3
	fixed-post-import-6feb06:1.1.1.3
	import-6feb06:1.1.1.3
	import-6sep05:1.1.1.2
	start:1.1.1.1
	freescale:1.1.1;
locks; strict;
comment	@# @;


1.4
date	2008.12.05.16.32.16;	author seh;	state Exp;
branches;
next	1.3;
commitid	URaWZkvY7PTctitt;

1.3
date	2008.04.04.15.48.14;	author seh;	state Exp;
branches;
next	1.2;
commitid	4LGH7zo3sfbm6OXs;

1.2
date	2007.01.29.08.41.21;	author seh;	state Exp;
branches;
next	1.1;

1.1
date	2005.08.23.08.54.22;	author seh;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2005.08.23.08.54.22;	author seh;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	2005.09.06.10.08.01;	author seh;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	2006.02.06.14.19.56;	author seh;	state Exp;
branches;
next	1.1.1.4;

1.1.1.4
date	2006.05.16.14.20.56;	author seh;	state Exp;
branches;
next	1.1.1.5;

1.1.1.5
date	2006.05.30.14.08.32;	author seh;	state Exp;
branches;
next	1.1.1.6;

1.1.1.6
date	2006.06.15.09.35.20;	author seh;	state Exp;
branches;
next	1.1.1.7;

1.1.1.7
date	2006.11.27.11.19.20;	author seh;	state Exp;
branches;
next	1.1.1.8;

1.1.1.8
date	2007.11.06.15.44.46;	author seh;	state Exp;
branches;
next	1.1.1.9;
commitid	AdKoH3Xx8FxdUwEs;

1.1.1.9
date	2008.04.04.10.51.56;	author seh;	state Exp;
branches;
next	1.1.1.10;
commitid	GVikqE6sLnKPsMXs;

1.1.1.10
date	2008.12.05.14.25.49;	author seh;	state Exp;
branches;
next	;
commitid	A4gB7k6PjRrWLhtt;


desc
@@


1.4
log
@resolve conflicts after import-20081205
@
text
@%TOPICTITLE%
---

<verbatim>
Copyright  Freescale Semiconductor, Inc. 2004-2005. All rights reserved.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license is included in the file doc/COPYING
</verbatim>


---+ Freescale GNU/Linux Target Image Builder FAQ

%TOC%

---+ Quick start

For those of you who don't like to read documentation, here are the bare-bones
instructions for installing LTIB.

   * *Getting/installing the software*
<verbatim>
$ cvs -z3 -d:pserver:anonymous@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>
   * *Configuring the software*
<verbatim>
$ cd ltib
$ ./ltib
</verbatim>

You will be prompted if you need to do anything (for instance to add sudo
access for your user).

   * *Running your image*

Having build your target image you'll find a directory call *rootfs*.  This 
contains a sub-directory *boot*, which contains your bootable Linux kernel.
The root filesystem itself can be NFS exported and NFS root mounted by
your kernel.  

The exact details of deployment for each target vary, but often there are
helpful notes under your platform's config directory in a file called
*deployment_details.txt*, for example: <verbatim>/config/platform/tqm823l/deployment_instructions.txt</verbatim>.


---+ Before you begin

---++ What is LTIB

The LTIB (Linux Target Image Builder) project is a simple tool that can be used
to develop and deploy BSPs (Board Support Packages) for various target
platforms. Using this tool a user will be able to develop a GNU/Linux image for
their target platform.  The following features are supported:

---++ Main features

   * Open source (GPL)
   * Runs on most popular Linux host distributions (x86 32/64 and some PPC)
   * Command line interface, with curses configuration screens 
   * Support for multiple target architectures (PPC, ARM, Coldfire)
   * Target platforms selectable from a menu (CVS version)
   * More than 200 userspace packages selectable
   * Common root filesystem package set across architectures
   * Supports building of bootloaders and kernel images
   * All package building as non-root user
   * Configuration/selection of individual packages from a menu
   * Auto package dependency resolution
   * Auto file conflict resolution by package order build scaling
   * Auto re-install/de-install of packages by changes in dependency tree
   * Toolchain selectable at configuration time
   * Configuration of the Linux kernel using it's native config language
   * Kernel selection can easily be changed from choicelist during
   configuration
   * Configuration of target system from host (IP address, services etc)
   * Supports *preconfigs* which allow developers to store different system 
   configurations (e.g. toolchain selection, kernel selection, package
   selection etc).
   * Supports *profiles* this allows just the userspace package set to be
   re-configured.  This is excellent for autobuilding or exchanging the
   non platform specific configuration between targets.
   * All packages are built as rpms and managed using rpm
   * Target image files managed using a private rpm database per LTIB instance
   on the host
   * Supports single package developer mode using prep/scbuild/scdeploy analogs
   * Provides a means of source capture (patches) and auto update of spec files
   * Shell mode available to run all commands in ltib's spec environment
   * Incremental deployment (over NFS) supported
   * RAMDISK and JFFS2 Flash image creation supported
   * Read-only root filesystem supported.
   * LTIB is meta-data only, all sources are pulled using http and locally cached in a common area per-host.
   * Remote source pulls support proxys
   * Support for glibc and uclibc
   * All meta-data formats are open source (rpm, Linux Kernel Config)
   * Modular BSP architecture (easy to add new BSPs)
   * Support *batch* mode and *--continue* for auto-builders
   * Support *--dry* to preview ltib's actions
   * Provides *--dltest* to check for availability of sources/patches 
   * Provides *listpkgs* mode to show all available packages, whether selected
   and their individual licenses.
   * Provides a *release* mode, this encapsulates an LTIB project into an
   iso images that will not require network access.

---++ What license is LTIB released under

The LTIB tool is released under the [[http://www.gnu.org/copyleft/gpl.html][GNU General Public License (GPL)]]

---++ Where can I get it from


LTIB is available either as iso images from [[http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP Freescale]] or in CVS format from [[http://savannah.nongnu.org/projects/ltib/ savannah]]

The iso images have the advantage that they are self-contained, the packages
for the target are pre-built and they also have more BSP specific
documentation.  They have the disadvantage that they target only one platform
per iso, and are a snapshot so don't include the latest updates to the LTIB
tool.

LTIB from savannah's CVS has the advantage of being up to date and supporting
multiple platforms.  The disadvantage is that the HEAD of CVS may not always be
stable, and also it does not contain the sources/patches for building.  This
means that if you use CVS, any toolchains/sources/patches needed for the
configuration you select will need to be downloaded from over the Internet.

#SavannahCvs
---+++ Savannah read-only anonymous CVS

This project's CVS repository can be checked out through anonymous CVS
using the following instructions.

Software repository :

<verbatim>
$ cvs -z3 -d:pserver:anonymous@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>

Note: When you update from within the module's directory (with cvs update) you do not need the -d option anymore. 

---+++ Savannah project member CVS acccess over SSH 

Member access is performed using the CVS over SSH method.

The SSHv2 public key fingerprints for the machine hosting the CVS trees are: 

   * RSA: 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 
   * DSA: 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5

Software repository :

<verbatim>
$ export CVS_RSH=ssh
$ cvs -z3 -d <membername>@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>

---++ What is required on your host before installing LTIB 

It is recommended that you have around 1GB of free disk space if you intend
to full BSP builds.

| *package* | *version*  | *comment* |
| perl      | >= 5.6.1   | to run the ltib script |
| glibc     | >= 2.2.x   | to build/run host packages |
| glibc-headers | >= 2.2.x | to build/run host packages |
| glibc-devel   | >= 2.2.x | to build/run host packages |
| binutils  | >= 2.11.93 | to build host packages |
| libstdc++       | any? | to build rpm-fs host package |
| libstdc++-devel | any? | to build rpm-fs host package |
| gcc       | >= 2.96    | to build host packages |
| gcc-c++   | >= 2.26    | to build rpm-fs host package |
| sudo      | any        | to run the 'rpm install' phase on each package |
| zlib       | any       | to build rpm-fs and mtd-utils host packages |
| zlib-devel | any       | to build rpm-fs and mtd-utils host packages |
| rpm       | any        | to build initial rpm-fs host package |
| rpm-build | any        | to build initial rpm-fs host package |
| patch     | any        | used by rpm |
| wget      | any        | to download packages/patches on demand |
| ncurses   | >= 5.1     | to build lkc (config language) host package |
| ncurses-devel | >= 5.1 | to build lkc (config language) host package |
| m4        | any?       | may be needed by bison |
| bison     | any        | to build lkc (config language) host package |
| flex      | any        | Not required we install:for host lkc |
| texinfo   | any        | to build genext2fs host package (requires ncurses-deve|
| gettext   | any        | genext2fs target package |
| autoconf  | >= 2.54    | Not required we install: automake target package |
| libtool   | >= 1.4.2   | Not required we install: libusb target package |
| glib2-devel | any?     | Needed if you want to build glib2 |

---+++ Un-sorted reports

   * Needed bison-1.875-53.2.i586.rpm which needed m4-1.4.2-3.i586.rpm
   * Need byacc: support info on an 8548 install


---+ Installing LTIB

---++ What Linux distributions does LTIB run on

It should run on most Linux host distributions that have glibc-2.2.x
or later.

The following platforms have been tried:

---+++ x86 Linux 

   * Redhat: 7.3, 8.0, 9.0, Enterprise release 4
   * Fedora Core: 1, 2, 3, 4, 5, 8
   * Debian: 3.1r0 (stable), unstable, 4.0
   * Suse: 8.2, 9.1, 9.2, 10.0, 10.2, 10.3
   * Ubuntu 6.10, 7.04, 7.10, 8.04

---+++ PPC Linux

   * Debian: 3.1r0 (stable), unstable


---++ How do I install LTIB using CVS

Checkout ltib from CVS as described [[#SavannahCvs][above]] and run these
commands:

<verbatim>
$ cd ltib
$ ./ltib
</verbatim>


---++ How do I install LTIB from a binary release (iso image)

If you have a binary release, here are the steps needed to install
it:

   * Download the iso image

   * Mount the iso image (as root)
   <verbatim>
# mount <bspname.iso> /mnt/cdrom -o loop
   </verbatim>

   * Install into a target directory (as a normal user)
   <verbatim>
$ /mnt/cdrom/install
   </verbatim>
   Follow the prompts and enter the target directory when prompted,
   This defaults to the current working directory and so you'll end
   up with a sub-directory of ltib.

   * Once ltib has been copied to the target directory, run:
   <verbatim>
$ cd <target_dir>/ltib
$ ./ltib
   </verbatim>


#ConfigurationSection
---+ Configuration

Configuration of ltib is started by using one of the following commands:

   * <verbatim>./ltib</verbatim> on the very first run for a CVS instance
   * <verbatim>./ltib -m config</verbatim> configure only
   * <verbatim>./ltib --configure</verbatim> configure and build

---++ Navigation

Most of the navigation information is show at the top of the configuration.
In addition you may use:

   * <verbatim>/</verbatim> : This searches for a configuration keyword
   and if found shows location and dependency information.

   * <verbatim>s</verbatim> : This searches the text of the menus for key
   words and re-postition you to the location of any matches.  You may
   repeat this operation to continue a search.

   * *page-up/page-dn* keys can be used to jump up and down lists a screen
   at a time.  The mapping for these keys varies from system to system.

---++ Top level platform selection screen

The top level configuration screen shows the platform specific configuration
points.  The exact composition of this screen varies from platform to
platform depending on the available options it offers.  This example
is taken for the mpc8548cds platform, I have broken down each section of
the screen and given an explanation:

<verbatim>
--- Choose the target C library type
    C library type (glibc)  --->
</verbatim>

Most platforms offer both *glibc* or *uClibc* C libraries.  What this option
actually does is condition the choice of available toolchains from which
you can select.

<verbatim>
--- Choose your toolchain
Toolchain (gcc-3.4/glibc-2.3.4 e500 (DPFP))  --->
(-mcpu=8548 -mhard-float -mfloat-gprs=double) Enter any CFLAGS for gcc
</verbatim>

This entry allows you to choose from the available list of toolchains.
The choice you make will drive the CFLAGS entry which follows.  You may
of course override the value for CGLAGS.  When ltib runs, it will download
(if required) and install the toolchain you have selected it

Note that every platform includes an option to select a custom toolchain.
This allows you to use most standard cross compilers that are your 
system.  The most common use of this option is to test new toolchains
before wiring them in to the platforms toolchain selection list permanently.
When using a custom toolchain, you'll be prompted for:

   * *toolchain path* : This is the absolute base path name of your toolchain.
   For instance, if wanted to use: <verbatim>/opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux/bin/arm-linux-gcc</verbatim>
   the correct entry would be: <verbatim>/opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux</verbatim>

   * *cross tools prefix* : This is the value that prefixes all the standard
   toolchain executables for your given cross toolchain.  So for the example
   just given, this would be <verbatim>powerpc-linux-</verbatim>

   * *CFLAGS* : Normally this can be left blank

<verbatim>
--- Bootloader
[*] Build a boot loader
      U-Boot options  --->
</verbatim>

If available, this allows you select and built a bootloader for your platform.

<verbatim>
    kernel (Linux 2.6.11+pq3 patches)  --->
[ ] Include kernel headers
(linux_2.6.11_mpc8548_cds_def.config) kernel preconfig
[ ] Configure the kernel
[ ] Leave the sources after building

</verbatim>

   * *kernel* item lets you select from the list of available kernels for
   the platform.

   * *Include kernel headers* tells ltib to install the header files from
   the kernel you have built into <verbatim>rootfs/usr/src/linux/include</verbatim>

   * *kernel preconfig* shows the kernel config file that will be used
   when building the kernel.  This is automatically selected according to
   choice of kernel.  You may overrride this.

   * *Configure the kernel* will cause ltib to drop into the Linux kernel
   configuration screen when ltib is building the kernel package.

   * *Leave the sources after building* : this option will leave the 
   source for kernel unpacked after the kernel package has been built
   and installed.

<verbatim>
--- Package selection
    Package list  --->
--- Target System Configuration
    Options  --->
--- Target Image Generation
    Options  --->
</verbatim>

These items drop you into the non-package specific configuration screens,
which are discussed in the next section.

*Note:* at the bottom of the screen, you'll see:
<verbatim>
Load an Alternate Configuration File
</verbatim>

This can be used to import a complete configuration for your platform.  For
instance, you may save out a particular config to a named file, for re-use
later.  Alternatively, someone else working on the same platform may send
you their platform configuration.  These should be placed in the 
<verbatim>config/platform/<your_target>/</verbatim> directory.

---++ Common Package selection screen

<verbatim>
--- Package selection
    Package list  --->
</verbatim>

Selecting *Package list* will drop you into the package selection screen.  Use
this screen to add and remove packages as required.  Normally the default
configuration is just fine.

Nearly all packages are common across platforms, with a few exceptions that are
conditioned by the choice of the current platform.  If a package requires
another package, it will auto-select it (auto-dependency resolution).  Here is
an example of the beginning of this screen:

<verbatim>
[*] apptrk binary package for powerpc 
[ ] autoconf
[ ] automake
[*] Include C library
(base_libs) C library package
[ ]   Include libc locale files ?
[ ]   Include header files from toolchain ?
[ ]   Include static libc libraries ?
[ ] alsa-lib
[ ] alsa-utils
[ ] bash
[ ] bind
[ ] binutils
[ ] bison
[*] boa
[ ] bonnie++
[*] busybox 
(busybox.config) busybox preconfig filename
[ ]   Configure busybox at build time
[ ] bzip2
</verbatim>


---++ Common Target System Configuration screen
<verbatim>
--- Target System Configuration
    Options  --->
</verbatim>

Selecting *Options* will drop you into the target system configuration options
screen.  The purpose of this screen is to allow you to configure your
target system.  I have broken down this screen with an explanation of
each item:

<verbatim>
(mpc8548cds) target hostname
</verbatim>

This option lets you configure the host name for your target.

<verbatim>
[*] boot up with a tty and login
(::respawn:/sbin/getty -L ttyS1 115200 vt100) Enter your inittab startup line
</verbatim>

If unchecked, your target will boot straight to the shell prompt.  The 
advantage of this is that you don't need to know the baud rate or tty device
for your target.  Very often this option will be left unchecked during
initial development of a BSP.

If checked, a default entry is shown for the *inittab* startup line. This
will vary from platform to platform.  You may override this entry.

<verbatim>
()  load these modules at boot
</verbatim>

You may enter a list of modules you want loaded at boot time here.

<verbatim>
[*] start networking
      Network setup  --->
</verbatim>

By selecting *start networking*, you will be able to enter and configure
the *Network setup* screen.  This screen allows you to configure up to
5 eth devices.  The following shows the entries for eth0:
<verbatim>
[*] Enable interface 0
(eth0) interface
[ ]   get network parameters using dhcp
(192.168.1.100) IP address
(255.255.255.0) netmask 
(192.168.1.255) broadcast address
(192.168.0.1) gateway address
(192.168.0.1) nameserver ip address
</verbatim>

By default most platforms are configured with a non-routeable fixed local
IP address.  You need to change these as appropriate.  If you are unsure
of what these settings do, please consult with your network administrator.

Back in the target system configuration screen, after the network setup,
you'll see a set of options that let you enable/disable whether or not
the available services will run on the target board.  The exact list 
depends on which packages have been selected.  Here is an example:
<verbatim>
[*] set the system time at startup
(ntp.cs.strath.ac.uk) NTP server name/ipaddress
[*] start syslogd/klogd
[*] start inetd
()    Enter command line arguments for inetd startup
[*] start portmap
[*] start boa (webserver)
(-c /etc) command line arguments for boa
</verbatim>

---++ Common Target Image Generation
<verbatim>
--- Target Image Generation screen
    Options  --->
</verbatim>

Selecting *Options* here will drop you into the target image generation
options screen.  The purpose of thise screen is to allow you to configure
certain aspects of the target image.

By default, an NFS mountable image is always generated, but in addition you
may also choose to package your image as a JFFS2 image or a compressed
ext2 RAMDISK image.

Here is an example screen for a system that is using ext2.gz RAMDISK.

<verbatim>
--- Choose your root filesystem image type
     Target image: (ext2.gz ramdisk)  --->
</verbatim>

Here you can choose between NFS only, JFFS2 or ext2.gz RAMDISK image types

<verbatim>
[ ] read-only root filesystem 
</verbatim>

Selecting this option will cause your root filesytem to be mounted read-only.
Certain directories that must have write permissions will be copied to
a read/write ramfs/tmpfs at boot and bind mounted.

<verbatim>
[*] create a ramdisk that can be used by u-boot
</verbatim>

This option is available if you are using u-boot for your target.  It 
turns the RAMDISK into a format that u-boot can understand (it adds headers)

<verbatim>
()  rootfs target directory
</verbatim>

This copies the output image (RAMDISK or JFFS2 image) to a chosen directory.
You must have write permissions there.

<verbatim>
[ ] Keep temporary staging directory
</verbatim>

This is used mainly during debugging.  It keeps the intermediate directory 
that is used as the staging directory for the RAMDISK/JFFS2 image.

<verbatim>
[*] remove man pages etc from the target image
[*] remove the /boot directory
[*] remove the /usr/src/ directory
[*] remove the /usr/include directory
()  remove these directories
()  remove these files[*] remove the static libraries
[*] strip any remaining binaries or libraries in the target image
</verbatim>

These options allow you to remove certain files/directories from the 
RAMDISK/JFFS2 image.  The idea is to save space on footprint challenged
platforms

<verbatim>
(0) Allocate extra space (Kbytes)
</verbatim>

This option allows you to reserve spare capcity for your JFFS2 image

---++ How can I re-configure the kernel under LTIB

Note: example here shown for the mpc8548cds platform

   * Run ltib and select 'Configure the kernel'

<verbatim>
./ltib --configure
</verbatim>

   * Locate the section that looks like:
<verbatim>
         --- Choose your Kernel
             kernel (Linux 2.6.11+pq3 patches)  --->
         [ ] Include kernel headers
         [ ] Configure the kernel
         [ ] Leave the sources after building
</verbatim>

   * Enable 'Configure the kernel', exit and save.

The kernel will build and stop in  menuconfig.  This will be
set to the values stored in:

<verbatim>
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
</verbatim>

After you've selected and changed any values, ltib will save these back to:

<verbatim>
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev
</verbatim>

If you want to try out a number of different kernel options, but don't want to completely re-build each time:

   * Select the option: <verbatim>    [ ] Configure the kernel</verbatim>

   * run:
<verbatim>
./ltib -p kernel-2.6.11-pq3 -m prep
</verbatim>

   * build:
<verbatim>
./ltib -p kernel-2.6.11-pq3 -m scbuild
</verbatim>

This will stop and let you tune the kernel values.  If there is a file <verbatim>config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev</verbatim>, this will be used as a starting point.  The file gets saved back to the same filename, so you can incrementally change values.  

   * To copy the built kernel to the rootfs/boot directory (optional)
<verbatim>
./ltib -p kernel-2.6.11-pq3 -m scdeploy
</verbatim>

This will also have the side effect of marking the kernel as built, so you
can run <verbatim>./ltib</verbatim> on it's own without it complaining
that the directory is in the way.

*Note:* You can keep running the *scbuild* step until you're done.
If you change any source  code in 'rpm/BUILD/linux-xxx/' you can capture
your changes at the end by running:

<verbatim>
./ltib -p kernel-2.6.11-pq3 -m patchmerge
</verbatim>

This will generate a patch of your changes and update the spec file.

To make your config changes permanent, you can do the following:
<verbatim>
mv config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
</verbatim>

Normally at this point you'd do a cvs commit if you have CVS write access.


---+  Deployment

Some targets have specific instructions in their platform directory, this
file is normally called *deployment_instructions.txt*, for example:
<verbatim>config/platform/tqm823l/deployment_instructions.txt</verbatim>

The following instructions are a general case (based on tqm823l), if you
do find a *deployment_instructions.txt* follow the specific instructions
in their after reading this general overview, that gives strategy pointers.

Additionally, some iso images contain more formal BSP documentation, you
should also consult this, if available.

---++ I ran ltib, where's my bootloader/kernel/root filesystem

This may vary from target to target (depends on the defconfig), but 
here's the general case:

---+++ root filesystem

The root filesystem will be a directory tree found under *rootfs* . The
files under here will generally be owned by root, with groups permissions
etc set as required to run on the actual target board.  The purpose of
this directory is to provide a node that can be NFS exported by your host
and NFS mounted as your target's root filesystem.

---+++ bootloader

The bootloader (if built) will be found under *rootfs/boot/* for example
many powerpc platforms would have the following bootloader components:

   1 *rootfs/boot/u-boot* : the elf version of u-boot (for debug)
   2 *rootfs/boot/u-boot.bin* the binary image of u-boot that could be
   installed into Flash (*normally you don't need to do this*)

---+++ kernel

The kernel (if build) will be found under *rootfs/boot* for example
many powerpc platforms would have the following bootloader components:

   1 *vmlinux*: the elf image of the kernel (for debug if built appropriately)
   2 *uImage*: the bootable kernel image (name depends on the target)
   3 *System.map*: the symbol map file for the built kernel
   4 *linux.config*: the configuration used to build the kernel image

---++ How do get my kernel/root filesystem running on my target

The most common way to deploy your kernel and root filesystem is
to load the kernel on the target using tftp and then boot the
kernel with the appropriate parameters to mount the root filesystem
from the host using NFS.

---+++ Export the root filesystem from your host using NFS

The exact details to do this vary from distribution to distribution,
but in general, here are the typical steps that you need carry out
(you need to be root to do this):

   * Choose an IP address on your network for the target (one not already
   in use).  You need to make sure that you have configured ltib so
   the root filesystem uses this IP address.
   See [[#ConfigurationSection][configuration]]
   The target can even use dhcp to get it's IP address, however if you 
   select DHCP in ltib's config and you are doing NFS deployment,
   what it actually does is bypass setting
   up the eth device, and relies on the current setting inherited by
   the kernel's boot parameters

   * Make a note of the IP address for your host.
   For this example, we'll assume the following values:
      * Target IP address: *192.168.0.254*
      * Host IP address: *192.168.0.204*
      * Root filesystem location: *~/ltib/rootfs*

   * Make a symlink from /tftpboot to the root filesystem:
<verbatim>
ln -s ~/ltib/rootfs /tftpboot/192.168.0.254
</verbatim>

   * Make sure you have the NFS server and portmap installed on your system

   * Export this directory by editing */etc/exports*, add the entry:
<verbatim>
/home/<uid>/ltib/rootfs *(rw,no_root_squash)
</verbatim>
   *NOTE*: this example has all security for this directory turned off!
   Any host may access this exported directory.  
   See <verbatim>man exports</verbatim> for more information

   * Re-start NFS:
 <verbatim>
sh /etc/rc.d/init.d/nfs restart
 </verbatim>

---+++ Make sure you have a tftp daemon running on your host

Most boot loaders load the kernel over a network connection using tftp
protocol.  So your target's bootloader can access the kernel you have built,
you must make sure you have a tftp daemon on your host.  Here are some checks
you can do:

    1 Check that the tftp server program is present on your system.
    by running the command below.  If it is not present you'll need to
    install the tftp-server package.
<verbatim>
$ ls /usr/sbin/in.tftpd
/usr/sbin/in.tftpd
</verbatim>
    2 Check to see if inetd is setup to run the tftp server by running the
    command below, your output should be similar:
<verbatim>
$ netstat -a | grep tftp
udp        0      0 *:tftp                      *:* 
</verbatim>
    It there is no output, make sure that it's not disabled in 
    <verbatim>/etc/xinetd.d/tftp</verbatim>.  In my copy I note the following
    line:
<verbatim>
    disable = no
</verbatim>
    3 Make sure that if you have a firewall on your host it will not block
    incoming packages from your target.  


---+++ Copy your kernel image to a location when tftp can retrieve it

Generally the tftp server will be configured to *chroot* to the directory
<verbatim>/tftpserver</tftpserver></verbatim>.  This means that you need to copy your
kernels to this, or a subdirectory under that directory.  In our example,
we do the following:
<verbatim>
$ cp rootfs/boot/uImage /tftpboot
</verbatim>


---+++ Setup the bootloader arguments for your kernel to use the exported RFS

The example shown is for a system using uboot/ppcboot with the setup
in the earlier section:

   * Setup the network parameters. At the ppcboot prompt:
<verbatim>
=> setenv ipaddr 192.168.0.254
=> setenv serverip 192.168.0.204
=> setenv bootargs root=/dev/nfs nfsaddrs=192.168.0.254:192.168.0.204
</verbatim>


---+++ Load your kernel onto the target board and boot the target

<verbatim>
=> tftp 100000 vmlinux.gz.uboot
.........
=> bootm 100000
</verbatim>


#LtibSupport

---+ Support

---++ Savannah public mailing list

The primary means of getting support if you are using LTIB from Savannah
is to join the mailing list [[http://lists.nongnu.org/mailman/listinfo/ltib][here]] and to submit your questions.

---++ iso images downloaded from freescale.com

If you are using an iso image downloaded from http://www.freescale.com/ you
may post support questions by doing the following:

   * go to http://www.freescale.com
   * click on "Support / Technical support"
   * click on "Submit a Service Request" 
   * register to get a user name and password.
   * login in with your user name and password
   * on the "New Service Request" page:
      * category = Technical Request
      * topic = Linux BSP
      * Click on "Continue"
   * fill out the information for the service request
   * click on the "Submit" button at the bottom of the page.

---+ Command line options explained

If you run the command show below, you'll see the following summary:

<verbatim>
$ ./ltib --help

This script is used to manage the building of BSPs with common target
root filesystems.  The rpms are installed as they are built
in the directory /home/seh/ltib_bsps/ltib-dev/rootfs (unless overriden in the resource file)

Edit the file .ltibrc in this directory to change the default system
configuration, or .ltibrc in your home directory.

ltib [-m <mode>] [options....]
    Where:
        --mode|m
          Where mode is either:
            prep        just prep the package
            scbuild     rpmbuild -bc --short-circuit
            scinstall   rpmbuild -bi --short-circuit
            scdeploy    does an scinstall followed by an install to the rootfs
            patchmerge  generate and merge a patch (requires -p <pkg>)
            clean       clean/uninstall target packages
            distclean   full cleanup, removes nearly everything
            listpkgs    list packages (alphanumeric)
            release     make a binary release iso image
            config      use with --configure to do configuration only
            shell       enter ltib shell mode (sets up spoofing etc)
        --pkg|p       : operate on this package only
        --configure|c : run the interactive configuration
        --preconfig   : configuration file to build from (defaults to .config)
        --profile     : profile file.  This is used to select an alternate
                        set of userspace packages, this is saved and used
                        on later runs of ltib (e.g config/profiles/max.config)
        --rcfile|r    : use this resource file
        --batch|b     : batch mode, assume yes to all questions
        --force|f     : force rebuilds even if they are up to date
        --reinstall|e : re-install rpms (but don't force rebuild)
        --nodeps|n    : turn off install/uninstall dependency checks
        --conflicts|k : don't force install rpms that have file conflicts
        --keepsrpms|s : keep the srpms after the build (deleted by default)
        --verbose|v   : more output
        --dry-run|d   : mostly a dry run (calls to system are just echos)
        --continue|C  : try to continue on package build errors (autobuilds)
        --version|V   : print the application version and quit
        --noredir|N   : do not redirect any output
        --deploy|D    : run the deploy scripts even if build is up to date
        --dlonly      : just download the packages only
        --dltest      : test that the BSP's packages are available
        --leavesrc|l  : leave the sources unpacked (only valid for pkg mode)
        --hostcf      : (re)configure/build/install the host support package set
        --help|h      : help on usage

</verbatim>


---++ Without any arguments

Running <verbatim>./ltib</verbatim> will do the following

   1 Install common host site support packages (first time only)
   2 Prompts the user for the target platform (first time only, CVS only)
   3 Enters the main platform configuration menu (first time only). 
   The initial state is the default config for that platform and is usually
   okay for most users
   4 Builds/installs the chosen packages as required

#OptionConfig
---++ -m config

Bring up the platform configuration menu.  ltib does not continue to build
packages after you exit the configuration menu

#OptionConfigure
---++ --configure

Bring up the platform configuration menu.  After you exit the configuration
menu, ltib build/installs the chosen packages as required

---++ -m clean

This uninstalls all rpm packages for this target.  This effectively
de-populates the rootfs directory.

*Notes:*
   * There may be files left in <verbatim>rootfs</verbatim> if you have
   NFS mounted this directory on your target 
   (e.g. <verbatim>/var/log/xx</verbatim>
   * It does not delete the binary rpm files, so if you re-run ltib, without
   any changes, it will just re-install the currently selected binary rpms.

---++ -m distclean

This mode is used to completely remove all the current ltib project's files,
as they would be found from a fresh cvs checkout.  It does not remove any
files from the shared common areas.

This mode is generally used with CVS versions so you can go back to the 
target platform selection screen and build a different target.

---++ -m release

This encapsulates the current LTIB project into an iso image that will
not require network access.

---++ -m shell

This is a developer function.  What it does is drops you to a shell prompt
with the environment setup exactly as it would be during the building
of an rpm spec file.  In this situation, all the ltib environment variables,
and compiler spoofing are setup for you.

This can be very useful when first developing a package when you are
trying to make changes so that it can cross compile.

#OptionListpkgs
---++ -m listpkgs

This mode is used to show all available packages, whether selected and their
individual licenses.  Here is some sample output from the *tqm823l* platform:
<verbatim>
$ ./ltib -m listpkgs
-----------------------  ----------------         ------- -------     -----------------------------------------
Package                  Spec file                Enabled License     Summary
-----------------------  ----------------         ------- -------     -----------------------------------------
DirectFB-0.9.24-1        DirectFB                    n    LGPL        DirectFB is a graphics library for embedded syst
NAS-config-1.0-1         NAS-config                  n    GPL         NAS setup scripts and instructions
alsa-lib-1.0.10-0        alsa-lib                    n    distributab A libraries for ALSA (Advanced Linux Sound Archi
</verbatim>

---++ --preconfig

Use the specified configuration file to configure and built your target
platform.  This configuration must be consistent with your current target
(e.g. it can't be from another architecture, or use an incompatible
toolchain).

The purpose of this option is to allow a method of quickly swapping between
one set of configuration points and another.  Developers can use this
as a means of exchanging their configuration setting.

---++ --profile

This is similar to preconfig, except it only changes the selection of
userspace packages.

The main purpose of this is to allow the creation of profiles, which are
used to specifiy certain types of system.  For instance, a minimum root
filesytem, a full system (for auto-test) etc.

---++ --rcfile <f>

This rarely used option allows you to override ltib's default resource file.

---++ --batch|-b

This option allows you to run ltib non-interactively.  It uses *conf* instead
of *mconf* when running the configuration stages, and assumes defaults.

The main purpose of this mode is to support auto-building

---++ --force|-f

This option forces either all packages, or the specified package to be
re-built.

---++ --reinstall|-e

This option forces either all packages, or the specified package to be
re-installed.  It does not force a rebuild of the packages.

---++ --nodeps|-n

This rarely used option disables rpm install/uninstall dependency checking.

---++ --conflicts|-k

Normally, ltib will allow packages that have overlapping files to be installed.
This is a deliberate design choice, which allows scaling from small to 
large filesystem footprints.

This rarely used option disables this and will not allow a package to install
if it's files will conflict with another installed package.  

---++ --keepsrpms|-s

Normally, ltib only builds binary rpms.  This rarely used option will
cause ltib to also build srpms.  This may be useful if a developer wants
to share a source package.

---++ --verbose|-v

Using this option will cause ltib to spew out lots of debug information.
It's mainly used for debug purposes

---++ --dry-run|-d

This option is used to test-run ltib.  It will show what commands it will
run, without actually running them.

---++ --continue|-C

Normally, ltib will stop as soon as it encounters an error when building 
packages.  With this option, ltib will report the error, but continue
to build.

The main purpose of this option is to support auto-building.

---++ --version|-V

This option reports the version number of ltib.  The numbering scheme
is <year>.<quarter>.<release>

---++ --noredir|N

Normally, during the first run of ltib, when it is building and installing
the common host-packages, the output will be re-directed to the file
<verbatim>host_config.log</verbatim>

---++ --deploy|-D

This option forces the running of just the deploy sections of ltib, even
if the build is up to date.

---++ --dlonly

This rarely used option provides a way of downloading all the source/patches
that will be required to build the current ltib configuration, without
actually running the build.

The main reason for this option is to support people who have temporary
network connections (for instance over a VPN/proxy).  This allows them
to get all the networking activity out the way before they build,.

---++ --dltest

This option is used to test whether or not the packages that are configured
to be built can be downloaded.

The main purpose of this to to check to see if the required sources/patches
are available at http://bitshrine.org/gpp

---++ --hostcf

This rarely used option allows a user to re-configure/build/install packages
to the common host package support area.

It is mainly used by people developing the ltib tool itself when testing
on different host distributions.

---++ --help

This displays the a summary of the command line options.

---++ Operations on a single package (developer mode)

---+++ -p pkg

Build/install just this package.

The purpose is to allow people to develop new packages and reference 
their spec files, before the package has been fully added to the system.

*Notes:*
   * in this case, <verbatim>pkg</verbatim> is actually the name of the 
   spec file, without the *.spec* extention.
   * this option will not leave the source code unpacked

---+++ -p pkg --leavesrc|-l

This option tells ltib to leave the sources for a package unpacked after
it has been built and installed.


---+++ -p pkg -m prep

In this mode, unpack the spec files sources and apply any patches.  The 
sources will be found in <verbatim>rpm/BUILD/xxx</verbatim>

---+++ -p pkg -m scbuild

In this mode, just run the *%Build* section of the package's spec file.
This is done using rpm's *--scbuild* option.

This mode assumes you have previously done a *prep* of the package.

---+++ -p pkg -m scinstall

In this mode, just run the *%Install* section of the package's spec file.
This is done using rpm's *--scinstall* option.

This mode assumes you have previously done a *prep* and a *scbuild* of 
the package.

---+++ -p pkg -m scdeploy

In this mode, ltib internally runs the *%Install* section of the package's spec file.  It then creates a temporary binary rpm and installs this into
the *rootfs* area.

Note that after running this mode ltib will allow you to run in 
non-package mode, even with the sources for this package unpacked.

This mode assumes you have previously done a *prep* and a *scbuild* of 
the package.

---+++ -p pkg -m patchmerge

In this mode, ltib will generate a patch of the diffs between your currently
unpacked sources (after running *make distclean*) and the sources for
this package before your changes.  This patch is saved into the LPP
and the spec file is updated to reference this new patch.

The purpose is to allow developers to capture their changes to a package
after they have completed their work/testing.


---+ General questions

---++ Do I need root permissions to use LTIB

Yes, but only for the installation rpms after they have been built as your
normal user.  This is because the target image must create device nodes and
other files with particular ownerships and permissions.

The way this is achieved is by using *sudo* for *rpm install*.  All
other operations (building of packages) are performed as the non-root
user.

LTIB should never be run as root.  The main reason is to prevent
mistakes during development from causing damage to the host file system.
To minimise the chance of mistakes during rpm installation, all rpms
have a non-standard re-locatable prefix, which would cause them
to be installed in a benign place if a user accidentally runs a
stand-alone rpm install.

---++ LTIB is rpm based, will it work on Debian

Yes, Debian supports rpms.  The *ltib* script will prompt you if
anything is required to setup rpm on your Debian machine.

---++ Why does it take so long for LTIB to install

LTIB requires some known packages on the host to function correctly
(notably rpm).  Also, there are some packages that are unlikely to 
be on your host that get installed by LTIB (e.g. u-boot-tools, lkc, genext2fs, mtd-utils).

The first time you install ltib on a machine, it will take quite a long time
to build and install the host side packages (mostly rpm-fs).  These host
packages are shared across ltib installs.  If you install (check-out) in
another directory (or another user installs), it will be much quicker the next
time.

---++ How do I get LTIB to continue building, even if there are errors

You have to take care, because sometimes if a package fails to build
a package built later may fail because it needs something from the
earlier packages (e.g. texinfo needs ncurses).

If you really want to do this, add -C or --continue option
to the ltib command line.

---++ I don't see uclibc/glibc get built, what is going on

The strategy in ltib is to always use the C library components that come
from the toolchain.  This allows us to do the following:

   * Ensure that the packages built exactly match the toolchain components
   * Easily switch glibc/uclibc versions, just by toolchain selection

Note that it is possible to build uclibc/glibc within ltib, but particularly
with glibc, great care must be taken to ensure that packages you build 
actually reference the built C library.  uClibc is far less problematic
in that respect.  Either way, it is *highly recommended* that you stick
with the strategy of using the C library components out of the toolchain
(this facilitated by the *base_libs* package).


---+ Packages

---++ How do I know which packages are available/will be installed?

Before configuring ltib, you can run bin/listpkgs on an ltib config file,
for instance, for the mpc8548cds, you could run:

<verbatim>
bin/listpkgs config/platform/mpc8548cds/defconfig
</verbatim>

This will list all the packages that can be selected.  The ones with a 'y'
in the 'Enabled' column will be built/installed by default.

If you have configured ltib already, you can get a more accurate (exact)
listing by running:

<verbatim>
./ltib -m listpkgs
</verbatim>

To select only those packages that are enabled, pipe either of the previous
commands to grep as follows:

<verbatim>
 ./ltib -m listpkgs | grep ' y '
</verbatim>

---++ How do I know what license a package uses

Use the [[#OptionListpkgs][-m listpkgs]] option

---++ How do I change package selection/configuration and immediately build

Use the [[#OptionConfigure][--configure]] option

---++ How do I change package select/configuration without building

Use the [[#OptionConfig][-m config]] option

---++ How do I build/install just a single package?
<verbatim>
./ltib -p <package_name>
</verbatim>

*Note:* When specifying a package *-p*, the package will be force
        re-built, even if it is up-to-date.

*Note:* The build/install will fail if dependent packages are not
        already installed.

---++ How do I make changes to a package and capture them

By default, rpm will unpack, configure, build, install and remove all sources
in one step.  This is a deliberate feature to make sure a package is
fully rebuilt from pristine sources plus patches in a consistent way.

Obviously, if you're trying to work on a package, this scheme is not
helpful.  To facilitate this kind of development process, rpm
provides the notion of short-circuited builds/installs.

---+++ Example work-flow

 1. Unpack the sources and apply all current patches:
<verbatim>
./ltib -m prep -p <package>
</verbatim>

 2. Edit/add files under *rpm/BUILD/package/*

 3. Build the package with your changes:
<verbatim>
./ltib -m scbuild -p <package>
</verbatim>

 4. Once the package builds successfully, check the install phase:
<verbatim>
./ltib -m scinstall -p <package>
</verbatim>

 5. Test your package before committing the changes:
<verbatim>
./ltib -m scdeploy -p <package>
</verbatim>

 6. Repeat steps 2 -> 5  until you are satisfied with your results.

 7. Generate a patch and update the spec file:
<verbatim>
./ltib -m patchmerge -p <package>
</verbatim>

 8. Manually clean up the patch file (as required).

 9. Build from scratch and install
<verbatim>
./ltib -p <package>
</verbatim>

 10. Once you're happy with all your changes, upload the patch to the GPP
[[http://www.bitshrine.org/cgi-bin/gpp_upload.cgi][here]]

 11. Commit the updated specfile. If you have CVS write access:
<verbatim>
cvs commit dist/lfs-5.1/<pkg>/<pkg>.spec
</verbatim>
 If you do not have CVS write access, please send a patch to the
 appropriate LTIB mailing list.

---++ How can I add a completely new package to the root filesystem

The following work-flow examples show the process of importing
new packages to the root filesystem.

---+++  I have a directory with some sources unpacked

 1. First clean your sources (remove any .o, .a, .so generated files)
 and then make a 'tarball', for instance:
 <verbatim>
cd <my_new_package>-x.y
make clean
cd ..
tar zcvf <my_new_package>-x.y.tar.gz <my_new_package>-x.y
</verbatim>

 2. Move this tarball to the LPP so *ltib* can find it.
<verbatim>
mv <my_new_package>-x.y.tar.gz /opt/freescale/pkgs/
</verbatim>

3. Create a specfile using the existing template.
<verbatim>
mkdir dist/lfs-5.1/<my_new_package>
cp dist/lfs-5.1/template/template.spec dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
</verbatim>

 4. Edit and fixup the template to reflect your package.  The fields
 that need changing are:
| *Field* | *Description* |
| Summary | put in a summary of what the package is/does |
| Name    | put in the name of the packge (usually from the tarball name) |
| Version | put in the version (usually from the tarball/directory |
| Release | start at 1 and rev each time you change the spec file |
| License | e.g GPL/LGPL/BSD, look this up in the package's files |
| Group   | If this exists on an rpm based machine, copy from rpm -qi <package> <br> If not, choose something from /usr/share/doc/rpm-<version>/GROUPS |
| %Build  | often you'll need to add *--host=$CFGHOST --build=%{_build}* to the configure clause |

 5. Unpack the new package sources:
<verbatim>
./ltib -m prep -p <my_new_package>
</verbatim>

 6. Make any changes you need to the sources to get them to cross compile

 7. Build the new package with your changes:
<verbatim>
./ltib -m scbuild -p <my_new_package>
</verbatim>

 8. Once the new package builds okay, check the install phase:
<verbatim>
./ltib -m scinstall -p <my_new_package>
</verbatim>

 9. Install the test package in the NFS root filesystem area (rootfs) and test
<verbatim>
./ltib -m scdeploy -p <my_new_package>
</verbatim>

 10. Once you're happy the package is running correctly, capture your
 changes.

<verbatim>
./ltib -m patchmerge <my_new_package>
</verbatim>

Any changes you've made will be put into a patch file and copied to
/opt/freescale/pkgs.  In addition, the spec file will be updated to
reference the new patch.  You should check the patch and eliminate any
bogus diffs.

 11. Upload the sources to the GPP

For external public files, use this link: 
http://www.bitshrine.org/cgi-bin/gpp_upload.cgi.  You must have previously
been blessed as a developer to do this.  For more information, 
contact the mailing list: http://lists.nongnu.org/mailman/listinfo/ltib

The files to be uploaded are your original tarball plus the patch generated
by ltib.  You should take care to fill in the license/distributable/description
fields accurately.

If you do not have project membership and upload permissions, please
send and email to the mailing list explaining what you want to do.

 12. Add your spec file to cvs

<verbatim>
cvs add dist/lfs-5.1/<my_new_package>
cvs add dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
cvs commit -m "added new_package" dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
</verbatim>

If you do not have CVS write access, please send a patch to the LTIB
mailing list.

 13. Follow the steps in the next section on "adding to the config system"

---++ How do I introduce my new package to the config system

Here is an example for package 'strace'

   1. Edit config/userspace/packages.lkc, this is in alphabetic order.
   Just after the 'PKG_SKELL' entry add:
<verbatim>
   config PKG_STRACE
       bool "strace"
</verbatim>
   1. Edit dist/lfs/common/pkg_map. This is in build order.  Put your package where it should go in the
   build order, and add an entry that ties
   the config key, to the directory containing the spec file for the
   package.  For strace, I put this after gdb as shown:
<verbatim>
   PKG_GDB             =   gdb
   PKG_STRACE          =   strace
</verbatim>
   1. Commit your changes
<verbatim>
cvs commit -m "added new_package"
</verbatim>

---++ How to add a daemon to init
   1. Add the package that provides your service (see above)
   1. Write an init script.  This goes into the skell package.  The easiest thing is to copy and modify something that already exists (for instance dropbear). Your script should not have any numeric prefix.  For example etc/rc.d/init.d/named.
   1. Add an entry into config/userspace/sysconfig.lkc, for instance:
<verbatim>
   config SYSCFG_START_NAMED
       depends PKG_NAMED
       bool "start named (nameserver)"
       default y
</verbatim>
   1. Add entries in dist/lfs-5.1/sysconfig/sysconfig.spec to process this new service:
<verbatim>
   if [ "$SYSCFG_START_NAMED" = "y" ]
   then
       named=named
   fi
</verbatim>
   1. Add 'named' into the all_services= line in the position you want it to be run.
   1. Add 'named' into the all_services_r= line (this is the reverse of the previous line, for shutdown).
   1. Add '$named' into cfg_services and cfg_services_r.


---+ Source code

---++ Where are the sources for the packages

If not available in the local common cache area, they are downloaded
and cached in a common area.  If you are using an iso image, these
will have been pre-installed into the local common cache.

---++ Where do the sources get downloaded from (what is the LPP/GPP/PPP)

The primary system used is the GPP/LPP/PPP.

The PPP (Private Package Pool) is a privately accessed http server that
may optionally be used as a storage area for private sources/patches.

The GPP (Global Package Pool) is a publicly available http server that is used
to store sources/patches for LTIB.

The LPP (Local Package Pool) is a local common cache that is used to store
all sources/patches that have been accessed by LTIB.

When ltib needs to build rpms, the spec-file for the
package is parsed.  After parsing, the builder has a list of sources
and patches that are needed to build the package.  The builder then
does the following:

   * Checks if the file/symlink (without any path/URL prefix) is present
   in rpm/SOURCES, if it is that is used.  If not:

   * Checks if the file (without any path/URL prefix) is present in the
   LPP directory (see the *%lpp* entry in *.ltibrc*).  If the
   file exists, a symlink is made from it to rpm/SOURCE and that link
   is used.  If not:

   * The builder tries to download the file from the PPP (if specified
   by the *%ppp_url* tag in *.ltibrc* to the LPP using *wget*.
   If that succeeds, a symlink is made from it to rpm/SOURCE and that link
   is used.  If the download does not succeed:

   * The builder tries to download the file from the GPP (specified by
   the *%gpp_url* tag in *.ltibrc* to the LPP using *wget*
   If that succeeds, a symlink is made from it to rpm/SOURCE and that link
   is used.  If the download does not succeed:

   * If all these final steps fail, the builder gives up and fails with
   an error.

*NOTE:* You may enter your proxy server information into the *.ltibrc*
resource file.  This may be needed if you are working within a 
company VPN environment and want to get at the external GPP on the
Internet.

---+ Auto building (unattended builds)

---++ How do I autobuild a complete BSP

Pass in the --preconfig option.  For example, to do an unattended
build of the default configuration of the tqm823l BSP:

<verbatim>
$ ./ltib --preconfig config/platform/tqm823l/defconfig --batch
</verbatim>

---++ How do I autobuild a BSP but with a full package payload (for testing)

<verbatim>
$ ./ltib --preconfig config/platform/tqm823l/defconfig --profile config/profiles/max.config --batch
</verbatim>

In addition, there is an example autobuilder script that I run from a cron
jobs for my nightly builds, it is located in:
<verbatim>bin/autobuild_ltib</verbatim>


---+ Cross toolchains

---++ Do you supply the target cross-compilers for the LTIB BSPs

Yes, these are stored on the GPP as the binary rpms and will be downloaded and installed as required.

---++ Why don't you build cross toolchains in LTIB

Every package that goes into the root filesystem depends on the 
cross toolchain.  If there are any bugs in the toolchain that is used,
these will have consequences to every package.  By supplying a toolchain
that we have built in a known environment and tested, we can be confident
that it works.

---++ Can I get the sources to the toolchains and build my own

Sources are always available as srpms, but building of toolchains is *NOT*
 supported.

If you have an iso release, the sources for your toolchain will have been
installed into a local common cache area.  If not you 
will find them on http://bitshrine.org/gpp . If you can't find your
sources, please send a support request (see [[#LtibSupport]])

Normally, the srpms provided use crosstool (http://kegel.com/crosstool/)
to build the toolchains.  Crosstool and its patches are encapsulated in
the srpm, but the external GNU components are not.  If you build using
the srpm you will need to make sure that crosstool is able to 
access the Internet to download these pieces.  Normally these pieces can
be also found on http://bitshrine.org/gpp
---+ Root Filesystems

---++ Can I add files to the target root file system without creating a package

Yes, to do this, you need to create a merge directory.  There are 2
options:

    1 Top level merge directory, that applies to all targets
    2 Platform specific merge directory

The platform specific merge directory contents override the top level merge
directory, which overrides the corresponding file(s) in your rootfs

*Example:*

You have a CVS version of LTIB, and you have build the tqm823l default
configuration, now:

   1 You want to add the a platform specific file /home/fred/myfile1
   2 You want all platforms you may build to use your own /etc/hosts file

Here's what you would do:

<verbatim>
$ cd <my_ltib_dir>
$ mkdir -p config/platform/tqm823l/merge/home/fred
$ cp <my_files>/myfile1 config/platform/tqm823l/merge/home/fred
$ mkdir -p merge/etc
$ cp <my_files>/hosts merge/etc
$ ./ltib
</verbatim>

The files from your merge directory will now have been placed into the
corresponding directories under <verbatim>rootfs</verbatim>.

---++ Can I have more than one root file system on my host at the same time

Yes, the system will support multiple root file systems, for the same or
for different target architectures.

If you are using an iso image, install your ltib archive into an different
directory by entering a new directory name for the installation when
prompted by the install script..

If you are using CVS, check-out CVS into a different directory by using the
*-d* option to cvs co.  For example:
<verbatim>
$ cvs -z3 -d:pserver:anonymous@@__SERVER_SPEC__ co -d newname ltib
</verbatim>

If the target architecture is different from the original one, a different
cross compiler will be needed.  It will be downloaded and
installed in the correct location if it isn't already present.

---++ How to add device nodes
Device nodes with static major/minor numbers can be added to the file ltib/bin/device_table.txt.  The format is described in the file itself.

Since there is no dependency checking for device_table.txt, after adding a new entry, force rebuild devices to make sure the new /dev nodes are in the file system:
<verbatim>
$ ./ltib -p dev -f
</verbatim>


---+ Errors output from ltib

---++ syntax error at ./ltib line 811, near "format twiki_top "

Your version of perl is too old.  You need 5.6.1 or later


----

-- Main.StuartHughes
-- Main.JenniferMitchell
-- Main.JohnFaith
@


1.3
log
@import-20080404-conflict-resolution
@
text
@d177 1
d188 1
d207 5
a211 4
   * Redhat: 7.3, 8.0, 9.0
   * Fedora Core: 1, 2, 3, 4
   * Debian: 3.1r0 (stable), unstable
   * Suse: 8.2, 9.1, 9.2, 10.0
@


1.2
log
@fix base_libs so libc.so and libpthread.so get moved to usr/lib
update support proceedure for ltibfaq and FSL
@
text
@a176 1
| patch     | any        | used by rpm |
d208 1
a208 1
   * Suse: 8.2, 9.1, 9.2
d768 1
a768 1
<verbatim>/tftpserver</tftpserver>.  This means that you need to copy your
d812 1
a812 1
   * go to www.freescale.com
d1613 8
@


1.1
log
@Initial revision
@
text
@d5 1
a5 1
Copyright  Freescale Semicondutor, Inc. 2004-2005. All rights reserved.
d15 2
d19 107
a125 1
---+ Freescale GNU/Linux Target Image Builder FAQ
d127 2
a128 1
This is a set of Frequently Asked Questions and answers
d130 2
a131 1
---+ What is LTIB
d133 1
a133 2
LTIB is a tool that allows users to build target images for a number
of platforms.
d135 3
a137 1
---+ Where can I download it from 
d139 1
a139 1
Within freescale you should use CVS:
d141 1
a141 1
---++ read-only anonymous cvs
d143 1
a143 1
---++ read/write cvs access
d145 1
a145 2
You first need to be added as a user by the project admin.  Send
a request to stuarth at freescale.com
d147 2
a148 1
---+ How do I install LTIB
d150 1
a150 1
---++ using CVS
a151 2
You should checkout ltib from cvs as described above.  Once
you have done this run:
d153 2
a154 2
cd ltib
./ltib
d157 1
a157 1
---++ from a binary release
d159 2
a160 4
Binary releases are only intended for external users, and the plan is that
ltib will be moved external and these will be phased out.  However,
if you have a binary release, here are the steps needed to install
it (the example here is for the mpc8548cds)
d162 28
a189 1
   * Download the iso image
d191 2
a192 4
   * Mount the iso image (as root)
   <verbatim>
mount ltib-mpc8548cds-20050614.iso /mnt/cdrom -o loop
   </verbatim>
a193 7
   * Install into a target directory (as a normal user)
   <verbatim>
/mnt/cdrom/install
   </verbatim>
   Follow the prompts and enter the target directory when prompted,
   This defaults to the current working directory and so you'll end
   up with a sub-directory of ltib.
d195 1
a195 5
   * Once ltib has been copied to the target directory, run:
   <verbatim>
cd <target_dir>/ltib
./ltib
   </verbatim>
d197 1
a197 1
---+ What does LTIB run on
d200 1
a200 2
or later.  It does require certain packages though, these are detailed
later.
d204 1
a204 1
---++ x86 Linux 
d207 1
a207 1
   * Fedora Core: 1, 2, 3
d209 1
a209 1
   * Suse-8.2
d211 1
a211 1
---++ PPC Linux
d216 4
a219 1
---++ What are the pre-requisites
d221 4
a224 1
Before you start you need:
a225 2
   * rsync (for the install)
   * perl  (to run ltib)
d227 1
a227 1
Once you have this, you can start to install ltib, ltib will then check as part of the install you have the following:
d229 2
a230 9
   * glibc            >= 2.2.x
   * binutils         >= 2.11.93
   * gcc              >= 2.96
   * ncurses-devel    >= 5.1
   * zlib-devel       any
   * rpm              any
   * wget             any
   * sudo             any
   * texinfo          any
d232 1
d234 4
a237 1
---+ Why does it take so long for LTIB to install 
d239 7
a245 3
LTIB requires some known packages on the host to function correctly
(notably rpm).  Also there are some packages that are unlikely to 
be on your host that get installed (u-boot-tools, lkc, genext2fs, mtd-utils).
d247 5
a251 5
The first time you installed ltib on a machine, it will take quite a long time
to build and install the host side packages (mostly rpm-fs).  These host
packages are shared across ltib installs, so if you install (check-out) in
another directory (or another user installs), it will be much quicker the next
time.
a252 1
---+ Do I need root permissions to use LTIB
d254 2
a255 3
Yes, but only for the installation phase of the built rpms.  This is
because the target image must create device nodes and other files
with particular ownerships and permissions.
d257 1
a257 3
The way this is achieve is by using *sudo* for *rpm install*.  All
other operations (building of packages) are performed as the non-root
user.
d259 3
a261 6
LTIB should never be run as root.  The main reason for this is to prevent
mistakes during development from causing damage to the host file system.
To minimise the chance of mistakes during rpm installation, all rpms
have a non-standard re-locatable prefix, which would cause them
to be installed in a benign place if a user accidentally ran a
stand-alone rpm install.
d263 1
a263 1
---+ Can I build the root filesystem from source
d265 2
a266 2
Yes, provided your Linux host has a reasonable set of up-to-date utilities
required to build these packages (such as make, gcc, etc).
d268 2
a269 1
In practice, most Linux development systems will work.
d271 3
a273 1
---+ Cross toolchains
d275 2
a276 1
---++ Do you supply the target cross-compilers for the LTIB BSPs
d278 1
a278 2
Yes, these are stored on the GPP as the binary rpms for the tested
toolchains will be downloaded and installed as required.
d280 5
a284 1
---++ Why don't you build cross toolchains in LTIB
d286 4
a289 3
Every package that goes into the root filesystem depends on the 
cross toolchain.  If there are any bugs in the toolchain that is used,
these will have consequences to every package.
d291 3
a293 2
By supplying a toolchain that we have built in a know environment and
tested, we can be confident that this fundamental piece is known.
d295 5
a299 1
---++ Can I get the sources to the toolchains and build my own
d301 18
a318 1
Yes but this is *NOT* supported.
d320 1
a320 9
If you want to build the cross toolchains used by ltib, send
a request stating which binary rpm you are using.  We will then
make an srpm available to you. 

These srpms use crosstool (http://kegel.com/crosstool/) to build the 
toolchains.  Crosstool and its patches are encapsulated in the srpm,
but the external GNU componenets are not.  If you build using
the srpm you will need to make sure that crosstool is able to 
access the internet to download these pieces.
d322 5
a326 1
---+ Where are the sources for the packages
d328 1
a328 2
These are downloaded on-demand and cached in a common area on the
machine they are downloaded to.
d330 6
a335 1
---+ Where do the sources get downloaded from (what is the LPP/GPP)
d337 1
a337 5
If you need to build a package, it's component sources and patches
will be downloaded.  The primary system used is the LPP/GPP.
The LPP is a local cache of a global storage area known as the
GPP.  The GPP is simply an http server that will serve out files
to wget.
d339 2
a340 4
When building rpms for the target root filesystem, the spec-file for the
package is parsed.  After parsing, the builder has a list of sources
and patches that are needed to build the package.  The builder then
does the following:
d342 2
a343 2
   * Checks if the file/symlink (without any path/url prefix) is present
   in rpm/SOURCES, if it is that is used.  If not:
d345 10
a354 4
   * Checks if the file (without any path/url prefix) is present in the
   LPP directory (see the *%lpp* entry in *.ltibrc*).  If the
   file exists, a symlink is made from it to rpm/SOURCE and that link
   is used.  If not:
d356 8
a363 4
   * The builder tries to download the file from the GPP (specified by
   the *%gpp_url* tag in *.ltibrc* to the LPP using *wget*
   If that succeeds, a symlink is made from it to rpm/SOURCE and that link
   is used.  If the download does not succeed:
d365 2
a366 5
   * If the entry parsed from the spec-file contains an Internet url prefix
   as part of it's path, the builder will then try to download the
   file from there.  This will be tried first with proxying on (if applicable)
   and then if that fails, with proxying off.  If these final steps fails,
   the builder gives up and fails with an error.
d368 4
a371 1
---+ LTIB is rpm based, will it work on Debian
d373 5
a377 2
Yes, Debian supports rpms.  The *ltib* script will prompt you if
anything is required to setup rpm on your Debian machine.
d379 1
a379 1
---+ How do I know what options are available for LTIB
a380 1
If you run the command as show below, you'll see the summary shown:
d382 3
a384 1
./ltib --help
d386 8
a393 3
s script is used to manage the building of BSPs with common target
root filesystems.  The rpms are installed as they are built
in the directory /home/seh/ltib_bsps/ltib-dev/rootfs (unless overriden in the resource file)
d395 22
a416 2
Edit the file .ltibrc in this directory to change the default system
configuration, or .ltibrc in your home directory.
a417 40
ltib [-m <mode>] [options....]
    Where:
        --mode|m 
          Where mode is either:
            buildrpms   build rpms (default)
            scbuild     rpmbuild -bc --short-circuit
            scinstall   rpmbuild -bi --short-circuit
            scdeploy    does an scinstall followed by an install to the rootfs
            prep        just prep the package
            patchmerge  generate and merge a patch (requires -p <pkg>)
            clean       clean the build area and generated files
            distclean   full cleanup, removes nearly everything
            install     install but don't attempt to upgrade/replace
            uninstall   uninstall all packages
            upgrade     upgrade or install new packages (not forced)
            addsrpms    install an srpm(s) into the build area
                        you need provide a list of srpms on the command line 
            listpkgs    list packages (alphanumeric)
            release     make a binary release iso image
            config      use with --configure to do configuration only
        --pkg|p       : operate on this package only
        --configure|c : run the interactive configuration
        --preconfig   : pre-config to build from (defaults to .config)
        --profile     : Used only with -m configure.  Ths sets the userspace
                        platform profile to use, this will override your
                        current package settings (e.g --profile max.config)
        --rcfile|r    : use this resource file
        --batch|b     : batch mode, assume yes to all questions
        --force|f     : force rebuilds even if they are up to date
        --reinstall|e : re-install rpms (but don't force rebuild)
        --nodeps|n    : turn off install/uninstall dependency checks
        --conflicts|k : don't force install rpms that have file conflicts
        --keepsrpms|s : keep the srpms after the build (deleted by default)
        --verbose|v   : more output
        --dry-run     : mostly a dry run (calls to system are just echos)
        --continue|C  : try to continue on package build errors (autobuilds)
        --version|V   : print the application version and quit
        --noredir|N   : do not redirect any output
        --deploy|d    : run the deploy scripts even if build is up to date
        --help|h      : help on usage
d419 4
d425 8
a432 1
---+ How do I know which packages are available/will be installed
d434 1
a434 2
Before configuring ltib, you can run bin/listpkgs on an ltib config file,
for instance, for the mpc8548cds, you could run:
d437 2
a438 1
bin/listpkgs config/platform/mpc8548cds/defconfig
d441 11
a451 2
This will list all the packages that can be selected.  The ones with a 'y'
in the 'Enabled' column will be built/installed by default.
d453 1
a453 2
If you have configured ltib already, you can get a more accurate (exact)
listing by running:
d456 2
a457 1
./ltib -m listpkgs
d460 13
a472 2
To select only those packages that are enabled, pipe either of the previous
commands to grep as follows:
d474 8
d483 8
a490 1
 ./ltib -m listpkgs | grep ' y '
d493 5
a497 1
---++ How do I know what license a package has 
d499 7
a505 2
Look in the license field from the output of either of the last 2 commands
(e.g ./ltib -m listpkgs or bin/listpkgs)
d507 1
a507 1
---+ Can I change the list of packages to be built
a508 1
Yes.  To do this, run the following command:
d510 2
a511 1
./ltib --configure
d514 2
a515 2
After exiting the *Platform choice* configuration, scroll down
to the *Package list* menu:
d517 1
a517 2
    --- Configure by package
        Package list  --->
d520 3
a522 3
Enter this menu and selected/de-select packages as required.  When you
exit and save the package selection, the targe image will be adjusted
accordingly
a523 1
---+ How do I build/install just a single package
d525 1
a525 1
./ltib -p <package_name>
d528 2
a529 2
Note: when specifying a package *-p*, the package will be force
      re-built, even if it is up-to-date
d531 3
a533 2
Note: the build/install will fail if dependent packages are not
      already installed.
d535 2
a536 4
---+ How do I autobuild a complete BSP

Pass in the --preconfig option.  For example, to do an unattended
build of the default configuration of the tqm823l BSP:
d539 1
a539 1
./ltib --preconfig config/platform/tqm823l/defconfig --batch
d542 2
a543 1
---+ How do I autobuild a BSP but with a full package list (for testing)
d546 7
a552 1
./ltib --preconfig config/platform/tqm823l/defconfig --profile max.config --batch
d555 3
a557 1
---++ How do I get LTIB to carry on if there are errors
d559 3
a561 3
You have to take care, because sometimes if a package fails to build
and package built later will fail because it needs something from the
earlier packages (e.g. texinfo needs ncurses).
d563 1
a563 2
If you really want to do this, add -C or --continue option
to the ltib command line.
d565 1
a565 1
---+ How do I work on a package without losing my changes
d567 1
a567 3
By default, rpm will remove, unpack, configure, build, remove all
in one step.  This is a deliberate feature to make sure a package is
fully rebuilt from pristine sources plus patches in a consistent way.
d569 1
a569 3
Obviously if you're trying to work on a package, this scheme is not
helpful.  To facilitate this kind of development process, rpm
provides the notion of short-circuited builds/installs.
d571 3
a573 1
---++ Example work-flow
d575 8
a582 1
Imagine you want to make some changes to a package, here are the steps:
d584 1
a584 4
 1. Unpack the sources and apply all current patches:
 <verbatim>
./ltib -m prep -p <package>
 </verbatim>
d586 2
a587 1
 2. Edit/add files under *rpm/BUILD/package/*
d589 3
a591 4
 3. Build the package with your changes:
 <verbatim>
./ltib -m scbuild -p <package>
 </verbatim>
d593 1
a593 4
 4. Once the package builds okay, check the install phase:
 <verbatim>
 ./ltib -m scinstall -p <package>
 </verbatim>
d595 3
a597 4
 5. If you want to test your package before commiting the changes:
 <verbatim>
 ./ltib -m scdeploy -p <package>
 </verbatim>
d599 1
a599 1
 6. Repeat steps 2 -> 5  until you're satisfied with your results
d601 1
a601 4
 7. Generate a patch and update the spec file:
 <verbatim>
./ltib -m patchmerge -p <package>
 </verbatim>
d603 4
a606 1
 6. Manually cleanup the patch file (as required).
d608 4
a611 4
 7. Build from scratch and install
 <verbatim>
./ltib  -p <package>
 </verbatim>
d613 1
a613 1
Once you're happy with all your changes.
d615 4
a618 4
 * Commit the updated specfile:
 <verbatim>
 cvs commit
 </verbatim>
d620 3
a622 2
 * sent the patch to the maintainer (stuarth@@freescale.com) for
 inclusion in the GPP.
d624 3
a626 1
---+ How can I add a completely new package to the rootfs
d628 3
a630 2
The following work-flow examples show the process of importing
new packages to the root filesystem.
d632 1
a632 1
---++ I have an existing srpm I want to use
d634 4
a637 4
 1. Import the srpm.  This will place materials under the sub-diretory *rpm*
 <verbatim>
./ltib -m addsrpms <path_of_the_srpm_to_import>
 </verbatim>
d639 1
a639 2
 2. Modify the spec file as required (look at
 *dist/lfs-5.1/template/template.spec* for an example)
a640 4
 3. Make sure the package builds:
 <verbatim>
./ltib -m scbuild -p <new_package>
 </verbatim>
d642 1
a642 1
 4. Modify sources under *rpm/BUILD/new_package* as needed
d644 3
a646 4
 5. Generate and merge a patch that encapsulates your changes:
 <verbatim>
./ltib -m patchmerge -p <new_package>
 </verbatim>
d648 3
a650 1
 6. Manually cleanup the patch file (as required).
d652 2
a653 4
 7. Build from scratch and install
 <verbatim>
./ltib -p <new_package>-x.y
 </verbatim>
d655 1
a655 25
 8. Save your changes:
  8.1. Move the spec-file from the temporary area to a permanent area and
  check into cvs/svn (as appropriate), for example:
  <verbatim>
mkdir dist/lfs-5.1/new_package
mv rpm/SPECS/new_package.spec dist/lfs-5.1/new_package/
cd dist/lfs-5.1/new_package
cvs add new_package.spec
cvs commit -m "added new_package" new_package-x.y.spec
  </verbatim>

  8.2. Copy the sources to your LPP (Local Package Pool), this is the directory
  specified by the entry in *.ltibrc* with the tag: *%lpp*.  For
  example:
  <verbatim>
rsync  -vptgo --ignore-existing  rpm/SOURCES/* /opt/mtwk/pkgs/
  </verbatim>

  8.3. If you have write permissions to the GPP (Global Package Pool), you
  can sync the source/patch files to the GPP.  You need to be an administrator
  to do this (and know the actual host/directory that contains the GPP).  For
  example:
  <verbatim>
rsync -e ssh -av --ignore-existing /opt/mtwk/pkgs 10.82.193.3:/opt/mtwk
  </verbatim>
d657 2
a658 1
---++ I do not have an existing package, and I want to make a package
d660 1
a660 8
 1. First clean your sources (remove any .o, .a, .so generated files)
 and then make a 'tarball', for instance:
 <verbatim>
cd <my_new_package>
make clean
cd ..
tar zcvf <my_new_package>-x.y.tar.gz <my_new_package>
 </verbatim>
d662 5
d668 1
a668 4
 2. Move this tarball to the lpp so *ltib* can find it.
 <verbatim>
mv <my_new_package>-x.y.tar.gz <lpp>
 </verbatim>
d670 2
a671 5
 3. Create a specfile using the existing template.
 <verbatim>
mkdir dist/lfs-5.1/<my_new_package>
cp dist/lfs-5.1/template/template.spec dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
 </verbatim>
d673 3
a675 10
 4. Edit and fixup the template to reflect your package.  The fields
 that need changing are:
 | *Field* | *Description* |
 | Summary | put in a summary of what the package is/does |
 | Name    | put in the name of the packge (usually from the tarball name) |
 | Version | put in the version (usually from the tarball/directory |
 | Release | start at 1 and rev each time you change the spec file |
 | License | e.g GPL/LGPL/BSD, look this up in the package's files |
 | Group   | If this exists on an rpm based machine, copy from rpm -qi <package> <br> If not, choose something from /usr/share/doc/rpm-<version>/GROUPS |
 | %Build  | often you'll need to add *--host=$CFGHOST --build=%{_build}* to the configure clause |
d677 1
d679 2
a680 1
 5. Follows steps 3->8 in the previous section as appropriate.
d682 4
a685 1
---+ How do I introduce my new package to the config system
d687 1
a687 1
Here an example for package 'strace'
d689 4
a692 14
   1. Edit config/userspace/packages.lkc, this is in alphabetic order.
   Just after the 'PKG_SKELL' entry add:
   <verbatim>
   config PKG_STRACE
       bool "strace"
   </verbatim>
   1. Edit dist/lfs/common/pkg_map, this is in build order.  Where in the
   build order your new package should go and add an entry that ties
   the config key, to the directory containing the spec file for the
   package.  For strace, I put this after gdb as shown:
   <verbatim>
   PKG_GDB             =   gdb
   PKG_STRACE          =   strace
   </verbatim>
d694 1
d696 3
a698 1
---+ Can I add files to the target root file system without creating a package?
d700 9
a708 5
Yes, it is possible to add files to be included in the target root file
system without the need to create a new package.
The way to do this is to create a directory named merge at the top level
of the root file system builder, and add the files in the directory structure
that you want.  Then run the ltib script.
d710 5
a714 2
For example if you need to add the following files to the target root file
system:
d716 1
d718 1
a718 2
/home/usr/myfile1
/opt/mtwk/usr/local/myfile2
d721 1
a721 1
Do the following:
d723 1
d725 1
a725 5
mkdir -p merge/home/usr
mkdir -p merge/opt/mtwk/usr/local
cp myfile1 merge/home/usr
cp myfile2 merge/opt/mtwk/usr/local
./ltib
d727 3
d731 237
a967 2
The resultant target root file system will include the specified files,
next time you run *ltib*
d969 2
a970 1
---+ I've built a root filesystem, but where's my kernel ?
d972 3
a974 2
The Linux kernel gets put into the directory *rootfs/boot*, usually
this will be named vmlinux.gz.
d976 237
a1212 1
---+ Can I have more than 1 root file system on my system at the same time
d1214 73
a1286 2
Yes, the system will support multiple root file systems, for the same or
different target architectures.
d1288 1
a1288 3
To build a different root file system without destroying the existing one
create a new directory, extract the ltib archive and run it from the new
directory.
d1290 4
a1293 3
If the target architecture is different from the original one, a different
cross compiler will be needed, the will be downloaded and
installed the correct toolchain if it isn't already present.
d1295 1
a1295 1
---+ I've built a root filesystem and have a kernel, how to I use it ?
d1297 4
a1300 4
The most common way to deploy a root filesystem is to setup an
NFS server on the host providing the root filesystem and then pass
the appropriate parameters to the kernel on the target to mount
this root filesytem.
d1302 2
a1303 3
The exact details to do this vary from distribution to distribution,
but in general, here are the typical steps that you may carry out
(you need to be root to do this):
d1305 6
a1310 1
---++ Export the root filesystem
d1312 1
a1312 2
   * Choose an IP address on your network for the target (one not already
 in use).
d1314 2
a1315 1
   * Make a note of the IP address for your host (use <verbatim>/sbin/ifconfig</verbatim>).
d1317 1
a1317 4
 For this example, we'll assume the following values:
      * Target IP address: *192.168.0.254*
      * Host IP address: *192.168.0.204*
      * Root filesystem localtion: */home/seh/rfs/rootfs*
d1319 2
a1320 1
   * Make a symlink from /tftpboot to the root filesystem:
d1322 52
a1373 2
ln -s /home/seh/rfs/rootfs /tftpboot/192.168.0.254
 </verbatim>
d1375 3
a1377 5
   * Export this directory by editing */etc/exports*, add the entry:
 <verbatim>
/home/seh/rootfs *(rw,no_root_squash)
 </verbatim>
   *NOTE*: this example has all security for this directory turned off!
d1379 15
a1393 4
   * Re-start NFS:
 <verbatim>
sh /etc/rc.d/init.d/nfs restart
 </verbatim>
d1395 2
a1396 1
---++ Setup your kernel to use the exported RFS
d1398 1
a1398 2
The example show is for a system using uboot/ppcboot with the setup
in the previous section:
d1400 5
a1404 6
   * Setup the network parameters, at the ppcboot prompt:
 <verbatim>
=> setenv ipaddr 192.168.0.254
=> setenv serverip 192.168.0.204
=> setenv bootargs root=/dev/nfs nfsaddrs=192.168.0.254:192.168.0.204
 </verbatim>
d1406 2
a1407 6
   * Boot the kernel
 <verbatim>
=> tftp 100000 vmlinux.pkg
.........
=> bootm 100000
 </verbatim>
d1409 1
a1409 1
---+ How can I re-configure the kernel under LTIB
d1411 1
a1411 1
Note: example here shown for the mpc8548cds platform
d1413 1
a1413 1
   * Run ltib and select 'Configure the kernel'
d1415 2
d1418 14
a1431 1
./ltib --configure
d1434 4
a1437 1
   * Locate the section  that looks like:
d1439 11
a1449 4
         --- Choose your Kernel
             kernel (Linux 2.6.11+pq38 patches)  --->
         [ ] Include kernel headers
         [ ] Configure the kernel
d1451 33
d1485 9
a1493 1
   * Enable 'Configure the kernel', exit and save.
d1495 4
a1498 3
The kernel will build and stop in the kernel's menu-config.  This will be
set to the values stored in:
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
d1500 2
a1501 1
After you've selected and changed any values, ltib will save these back to:
d1503 4
a1506 1
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev
d1508 1
d1510 1
a1510 1
If you want to try out a number of different kernel options, but don't want to completely re-build each time.
d1512 2
a1513 1
1. leave on the option: [ ] Configure the kernel
a1514 1
2. run:
d1516 1
a1516 1
./ltib -p kernel-2.6.11-pq38 -m prep
d1519 2
a1520 1
3. build:
d1522 1
a1522 1
./ltib -p kernel-2.6.11-pq38 -m scbuild
d1525 57
a1581 4
Again, this will stop and let you tune the kernel values.  If there is a file
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev, this will
be used as a starting point.  This gets saved back to the same filename, so you
can incrementally change values.
a1582 1
   * To copy the built kernel to the rootfs/boot directory (optional)
d1584 6
a1589 1
./ltib -p kernel-2.6.11-pq38 -m scdeploy
d1592 7
a1598 3
This will also have the side effect of marking the kernel as built, so you
can run ./ltib on it's own without it complaining that the directory is
in the way.
d1600 3
a1602 3
*Note:* You can keep running step 3 until you're done.  If you change any
source  code in 'rpm/BUILD/linux-xxx/' you can capture your changes at the end
by running:
d1604 2
d1607 1
a1607 1
./ltib -p kernel-2.6.11-pq38 -m patchmerge
d1610 8
a1617 1
This will generate a patch of your changes and update the spec file.
d1619 1
a1619 3
To make your config changes permanent, you can mv the
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev file to
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
a1620 1
Normally at this point you'd do a cvs commit if you have cvs write access.
d1622 1
d1624 3
a1626 2
---
-- Main.StuartHughes - %SERVERTIME%
@


1.1.1.1
log
@LTIB external initial import
@
text
@@


1.1.1.2
log
@Import from fsl 6sep05
@
text
@d15 2
d21 1
a21 1
%TOC%
d23 2
a24 1
---+ Before you begin
d26 1
a26 1
---++ What is LTIB?
d28 1
a28 1
LTIB is a tool to manage, configure, extend and build Linux software elements. Using an LTIB-based BSP, you can easily build bootloader, kernel and root filesystem images for your target. The Freescale Linux Target Image Builder, runs on an x86 PC running the Linux OS
d30 1
a30 1
---++ Where can I download it from?
d32 1
d34 2
a35 1
---+++ read-only anonymous cvs
d37 1
a37 1
This project's CVS repository can be checked out through anonymous CVS over SSH with the following instruction set. The module you wish to check out must be specified as the modulename. When prompted for a password for anoncvs, simply press the Enter key. 
d39 1
a39 1
The SSHv2 public key fingerprints for the machine hosting the cvs trees are: 
d41 6
a46 62
   * RSA: 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 
   * DSA: 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5

Software repository :

<verbatim>export CVS_RSH="ssh"</verbatim>

<verbatim>cvs -z3 -d:ext:anoncvs@@savannah.nongnu.org:/cvsroot/ltib co <modulename></verbatim>


Webpages repository :

<verbatim>export CVS_RSH="ssh"</verbatim>

<verbatim>cvs -z3 -d:ext:anoncvs@@savannah.nongnu.org:/webcvs/ltib co <modulename></verbatim>

When you update from within the module's directory (with cvs update) you do not need the -d option anymore. 


---+++ Project Member CVS Access via SSH 

Software repository :

export CVS_RSH=ssh

cvs -z3 -d <membername>@@savannah.nongnu.org:/cvsroot/ltib co <modulename>

Webpages repository :

export CVS_RSH=ssh

cvs -z3 -d <membername>@@savannah.nongnu.org:/webcvs/ltib co ltib


---++ What are the pre-requisites?

Before you start you need:

   * rsync (for the install)
   * perl  (to run ltib)
   * packages required by deployment (e.g. tftp-server, nfs-server)
   * disk space. 1GB available disk space is recommended for installing, building, etc.

Once you have this, you can start to install ltib, ltib will then check as part of the install you have the following:

   * glibc            >= 2.2.x
   * binutils         >= 2.11.93
   * gcc              >= 2.96
   * ncurses-devel    >= 5.1
   * zlib-devel       any
   * rpm              any
   * wget             any
   * sudo             any
   * texinfo          any

---+ Installing LTIB

---++ How do I install LTIB using CVS?

Checkout ltib from cvs as described above and run it like this:

<verbatim>cd ltib</verbatim>
d48 1
a48 1
<verbatim>./ltib</verbatim>
d50 4
a53 5

---++ How do I install LTIB from a binary release?

If you have a binary release, here are the steps needed to install
it:
d59 1
a59 1
mount _bspimage.iso_ /mnt/cdrom -o loop
d76 1
a76 1
---++ What Linux distributions does LTIB run on?
d79 2
a80 1
or later.  LTIB does require certain packages.  See "What are the pre-requisites" under "Before you begin".
d84 1
a84 1
---+++ x86 Linux 
d89 1
a89 1
   * Suse: 8.2, 9.2
d91 1
a91 1
---+++ PPC Linux
a94 1
---++ LTIB is rpm based, will it work on Debian?
d96 18
a113 2
Yes, Debian supports rpms.  The *ltib* script will prompt you if
anything is required to setup rpm on your Debian machine.
d116 1
a116 1
---++ Why does it take so long for LTIB to install?
d119 2
a120 2
(notably rpm).  Also, there are some packages that are unlikely to 
be on your host that get installed by LTIB (e.g. u-boot-tools, lkc, genext2fs, mtd-utils).
d122 1
a122 1
The first time you install ltib on a machine, it will take quite a long time
d124 1
a124 1
packages are shared across ltib installs.  If you install (check-out) in
d128 1
a128 1
---++ Do I need root permissions to use LTIB?
d134 1
a134 1
The best way this is achieved is by using *sudo* for *rpm install*.  All
d138 1
a138 1
LTIB should never be run as root.  The main reason is to prevent
d142 1
a142 1
to be installed in a benign place if a user accidentally runs a
d145 6
d154 1
a154 1
---++ Do you supply the target cross-compilers for the LTIB BSPs?
d156 2
a157 1
Yes, these are stored on the GPP as the binary rpms and will be downloaded and installed as required.
d159 1
a159 1
---++ Why don't you build cross toolchains in LTIB?
d165 2
a166 2
By supplying a toolchain that we have built in a known environment and
tested, we can be confident that it works.
d168 1
a168 1
---++ Can I get the sources to the toolchains and build my own?
d170 1
a170 1
Yes, but this is *NOT* supported.
d173 2
a174 2
a request < to WHOM????> stating which binary rpm you are using.  We will then
make the srpm available to you. 
d182 1
a182 3
---+ LTIB Basics

---++ Where are the sources for the packages?
d187 1
a187 1
---++ Where do the sources get downloaded from? What is the LPP/GPP?
d219 4
d224 1
a224 1
---++ What options are available for LTIB?
a228 1
</verbatim>
d230 1
a230 1
A script is used to manage the building of BSPs with common target
d232 1
a232 1
in the directory <verbatim>~/ltib_bsps/ltib-dev/rootfs</verbatim> (unless overriden in the resource file)
d234 2
a235 2
Edit the file <verbatim>.ltibrc</verbatim> in this directory to change the default system
configuration, or <verbatim>.ltibrc</verbatim> in your home directory.
a236 1
<verbatim>
d280 1
a280 27
---++ How do I autobuild a complete BSP?

Pass in the --preconfig option.  For example, to do an unattended
build of the default configuration of the tqm823l BSP:

<verbatim>
./ltib --preconfig config/platform/tqm823l/defconfig --batch
</verbatim>

---++ How do I autobuild a BSP but with a full package list (for testing)?

<verbatim>
./ltib --preconfig config/platform/tqm823l/defconfig --profile max.config --batch
</verbatim>

---++ How do I get LTIB to carry on if there are errors?

You have to take care, because sometimes if a package fails to build
a package built later will fail because it needs something from the
earlier packages (e.g. texinfo needs ncurses).

If you really want to do this, add -C or --continue option
to the ltib command line.

---+ Packages

---++ How do I know which packages are available/will be installed?
d306 1
a306 1
---++ How do I know what license a package has?
d311 1
a311 1
---++ Can I change the list of packages to be built?
d327 1
a327 1
accordingly.
d329 1
a329 1
---++ How do I build/install just a single package?
d334 2
a335 2
Note: When specifying a package *-p*, the package will be force
      re-built, even if it is up-to-date.
d337 1
a337 1
Note: The build/install will fail if dependent packages are not
d340 23
d364 1
a364 1
---++ How do I make changes to a package and capture them?
d370 1
a370 1
Obviously, if you're trying to work on a package, this scheme is not
d374 3
a376 1
---+++ Example work-flow
d390 1
a390 1
 4. Once the package builds successfully, check the install phase:
d395 1
a395 1
 5. If you want to test your package before committing the changes:
d400 1
a400 1
 6. Repeat steps 2 -> 5  until you are satisfied with your results.
d407 1
a407 1
 6. Manually clean up the patch file (as required).
d421 1
a421 1
 * send the patch to the maintainer (stuarth@@freescale.com) for
d424 1
a424 1
---++ How can I add a completely new package to the rootfs?
d429 1
a429 1
---+++ I have an existing srpm I want to use
d431 1
a431 1
 1. Import the srpm.  This will place materials under the sub-diretory *rpm*.
d436 2
a437 2
 2. Modify the spec file as required. (Look at
 *dist/lfs-5.1/template/template.spec* for an example.)
d444 1
a444 1
 4. Modify sources under *rpm/BUILD/new_package* as needed.
d451 1
a451 1
 6. Manually clean up the patch file (as required).
d453 1
a453 1
 7. Build from scratch and install.
a458 1

d484 1
a484 1
---+++ I do not have an existing package, and I want to make a package
d489 1
a489 1
cd <my_new_package>-x.y
d492 1
a492 1
tar zcvf <my_new_package>-x.y.tar.gz <my_new_package>-x.y
d519 1
a519 34
 5. Unpack the new package sources:
 <verbatim>
./ltib -m prep -p <my_new_package>
 </verbatim>

 6. Build the new package with your changes:
 <verbatim>
./ltib -m scbuild -p <my_new_package>
 </verbatim>

 7. Once the new package builds okay, check the install phase:
 <verbatim>
 ./ltib -m scinstall -p <my_new_package>
 </verbatim>

 8. If you want to test your package before commiting the changes:
 <verbatim>
 ./ltib -m scdeploy -p <my_new_package>
 </verbatim>

 9. Once you're happy with the new package.

 * Commit the updated specfile:
 <verbatim>
 cvs add dist/lfs-5.1/<my_new_package>
 cvs add dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
 cvs commit -m "added new_package" dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
 </verbatim>

 * send the new package to the maintainer (stuarth@@freescale.com) for
 inclusion in the GPP.

10. Follow the steps in the section "How to introduce the new package to the config system?"

d521 1
a521 1
---++ How do I introduce my new package to the config system?
d523 1
a523 1
Here is an example for package 'strace'
d531 2
a532 2
   1. Edit dist/lfs/common/pkg_map. This is in build order.  Put your package where it should go in the
   build order, and add an entry that ties
a538 9
   1. Commit your changes
 <verbatim>
 cvs commit -m "added new_package"
 </verbatim>


---+ Root Filesystems

---++ Can I build the root filesystem from source?
a539 2
Yes, provided your Linux host has a reasonable set of up-to-date utilities
required to build these packages (such as make, gcc, etc).
d541 1
a541 3
In practice, most Linux development systems will work.

---++ Can I add files to the target root file system without creating a package?
d545 1
a545 1
To do this, create a directory named merge/ at the top level
d547 1
a547 1
that you want.  Then, run the ltib script.
d570 4
d575 1
a575 1
---++ Can I have more than 1 root file system on my system at the same time?
d578 1
a578 1
for different target architectures.
d585 2
a586 2
cross compiler will be needed.  It will be downloaded and
installed in the correct location if it isn't already present.
d588 1
a588 1
---++ I've built a root filesystem and have a kernel, how to I use it?
d599 1
a599 1
---+++ Export the root filesystem
d609 1
a609 1
      * Root filesystem localtion: *~/rfs/rootfs*
d613 1
a613 1
ln -s ~/rfs/rootfs /tftpboot/192.168.0.254
d618 1
a618 1
~/rootfs *(rw,no_root_squash)
d627 1
a627 1
---+++ Setup your kernel to use the exported RFS
d646 1
a646 7
---+ Kernel

---++ I've built a root filesystem, but where is my kernel?

The Linux kernel gets put into the directory *rootfs/boot*.

---++ How can I re-configure the kernel under LTIB
d656 1
a656 1
   * Locate the section that looks like:
d666 1
a666 1
The kernel will build and stop in  menuconfig.  This will be
a667 2

<verbatim>
a668 1
</verbatim>
a671 1
<verbatim>
a672 1
</verbatim>
d674 2
a675 1
If you want to try out a number of different kernel options, but don't want to completely re-build each time:
d689 3
a691 3
This will stop and let you tune the kernel values.  If there is a file
<verbatim>config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev</verbatim>, this will
be used as a starting point.  The file gets saved back to the same filename, so you
d713 3
a715 3
To make your config changes permanent, you can ,verbatim>mv</verbatim> the
<verbatim>config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev</verbatim> file to
<verbatim>config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config</verbatim>
a718 1
----
d720 2
a721 2
-- Main.StuartHughes
-- Main.JenniferMitchell
@


1.1.1.3
log
@Import from fsl 6feb06
@
text
@d138 1
a138 1
   * Fedora Core: 1, 2, 3, 4
d140 1
a140 1
   * Suse: 8.2, 9.1, 9.2
d504 1
a504 1
rsync  -vptgo --ignore-existing  rpm/SOURCES/* /opt/freescale/pkgs/
d507 7
a513 7
  8.3. You now need to upload your sources/patches to the GPP.  To do this
point your browser at:
 http://bitshrine.org/ltib-cgi/gpp_upload.cgi

And upload each file not already in the PPP/GPP.


a801 10

---++ I get the following errors
---+++ syntax error at ./ltib line 811, near "format twiki_top "

Your version of perl is too old.  You need 5.6.1 or later





@


1.1.1.4
log
@Import from fsl 20060516
@
text
@d5 1
a5 1
Copyright  Freescale Semiconductor, Inc. 2004-2005. All rights reserved.
d17 2
d21 7
a28 1
---+ Before you begin
d30 1
a30 1
---++ What is LTIB
d32 1
a32 72
The LTIB (Linux Target Image Builder) project is a simple tool that can be used
to develop and deploy BSPs (Board Support Packages) for various target
platforms. Using this tool a user will be able to develop a GNU/Linux image for
their target platform.  The following features are supported:

---++ Main features

   * Open source (GPL)
   * Runs on most popular Linux host distributions (x86 and some PPC)
   * Command line interface, with curses configuration screens (using LKC)
   * Support for multiple target architectures (PPC, ARM, Coldfire)
   * Target platforms selectable from a menu (CVS version)
   * More than 200 userspace packages selectable
   * Common root filesystem package set across architectures
   * Supports building of bootloaders and kernel images
   * All package building is done as non-root user
   * Configuration/selection of individual packages from a menu
   * Auto package dependency resolution
   * Auto file conflict resolution by package order build scaling
   * Auto re-install/de-install of packages by changes in dependency tree
   * Toolchain selectable at configuration time
   * Configuration of the Linux kernel using it's native config language
   * Kernel selection can easilty be changed from choicelist during
   configuration
   * Configuration of target system from host (IP address, services etc)
   * Supports *preconfigs* which allow developers to store different system 
   configurations (e.g. toolchain selection, kernel selection, package
   selection etc).
   * Supports *profiles* this allows just the userspace package set to be
   re-configured.  This is excellent for autobuilding or exchanging the
   non platform specific configuration between targets.
   * All packages are built as rpms and managed using rpm
   * Target image files managed using a private rpm database per LTIB instance
   on the host
   * Supports single package developer mode using prep/scbuild/scdeploy analogs
   * Provides a means of source capture (patches) and auto update of spec files
   * Shell mode available to run all commands in ltib's spec environment
   * Incremental deployment (over NFS) supported
   * RAMDISK and JFFS2 Flash image creation supported
   * Read-only root filesystem supported.
   * LTIB is meta-data only, all sources are pulled using http and locally cached in a common area per-host.
   * Remote source pulls support proxys
   * Support for glibc and uclibc
   * All meta-data formats are open source (rpm, Linux Kernel Config)
   * Modular BSP architecture (easy to add new BSPs)
   * Support *batch* mode and *--continue* for auto-builders
   * Support *--dry* to preview ltib's actions
   * Provides *--dltest* to check for availability of sources/patches 
   * Provides *listpkgs* mode to show all available packages, whether selected
   and their individual licenses.
   * Provides a *release* mode, this encapsulates an LTIB project into an
   iso images that will not require network access.

---++ What license is LTIB released under

The LTIB tool is released under the [[http://www.gnu.org/copyleft/gpl.html][GNU General Public License (GPL)]]

---++ Where can I get it from

LTIB is available either as iso images from [[http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP Freescale]] or in CVS format from [[http://savannah.nongnu.org/projects/ltib/ savannah]]

The iso images have the advantage that they are self-contained, the packages
for the target are pre-built and they also have more BSP specific
documentation.  They have the disadvantage that they target only one platform
per iso, and are a snapshot so don't include the latest updates to the LTIB
tool.

LTIB from savannah's CVS has the advantage of being up to date and supporting
multiple platforms.  The disadvantage is that the HEAD of CVS may not always be
stable, and also it does not contain the sources/patches for building.  This
means that if you use CVS, any toolchains/sources/patches needed for the
configuration you select will need to be downloaded from over the Internet.
d34 1
a34 2
#SavannahCvs
---+++ Savannah read-only anonymous CVS
d36 2
a37 2
This project's CVS repository can be checked out through anonymous CVS
using the following instructions.
d41 1
a41 3
<verbatim>
$ cvs -z3 -d:pserver:anonymous@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>
d43 1
a43 1
Note: When you update from within the module's directory (with cvs update) you do not need the -d option anymore. 
a44 1
---+++ Savannah project member CVS acccess over SSH 
d46 1
a46 1
Member access is performed using the CVS over SSH method.
d48 1
a48 1
The SSHv2 public key fingerprints for the machine hosting the CVS trees are: 
d50 1
a50 2
   * RSA: 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 
   * DSA: 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5
d52 1
a52 1
Software repository :
a53 4
<verbatim>
$ export CVS_RSH=ssh
$ cvs -z3 -d <membername>@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>
d55 1
a55 1
---++ What is required on your host before installing LTIB 
d57 1
a57 2
It is recommended that you have around 1GB of free disk space if you intend
to full BSP builds.
d59 1
a59 21
| *package* | *version*  | *comment* |
| perl      | >= 5.6.1   | to run the ltib script |
| sudo      | any        | to run the 'rpm install' phase on each package |
| wget      | any        | to download packages/patches on demand |
| rpm-build | any        | need by rpm to do actual building of packages |
| rpm       | any        | to build initial rpm-fs host package |
| glibc     | >= 2.2.x   | to build/run host packages |
| libstdc++-devel | any? | to build rpm-fs host package |
| binutils  | >= 2.11.93 | to build host packages |
| gcc       | >= 2.96    | to build host packages |
| gcc-c++   | >= 2.26    | to build rpm-fs host package |
| zlib-devel | any       | to build rpm-fs and mtd-utils host packages |
| ncurses   | >= 5.1     | to build lkc (config language) host package |
| ncurses-devel | >= 5.1 | to build lkc (config language) host package |
| m4        | any?       | may be needed by bison |
| bison     | any        | to build lkc (config language) host package |
| flex      | any        | to build lkc (config language) host package |
| texinfo   | any        | to build genext2fs host package |
| autoconf  | >= 2.54    | to build automake target package |
| libtool   | >= 1.4.2   | to build libusb target package |
| gettext   | any        | to build genext2fs target package |
d61 1
a61 1
---+++ Un-sorted reports
d63 1
a63 2
   * Needed bison-1.875-53.2.i586.rpm which needed m4-1.4.2-3.i586.rpm
   * Need byacc: support info on an 8548 install
d65 1
d67 1
a67 1
---+ Installing LTIB
a68 1
---++ What Linux distributions does LTIB run on
d70 1
a70 2
It should run on most Linux host distributions that have glibc-2.2.x
or later.
d72 1
a72 1
The following platforms have been tried:
d74 4
a77 1
---+++ x86 Linux 
d79 1
a79 4
   * Redhat: 7.3, 8.0, 9.0
   * Fedora Core: 1, 2, 3, 4
   * Debian: 3.1r0 (stable), unstable
   * Suse: 8.2, 9.1, 9.2
d81 9
a89 1
---+++ PPC Linux
d91 1
a91 1
   * Debian: 3.1r0 (stable), unstable
d93 1
d95 1
a95 1
---++ How do I install LTIB using CVS
d97 1
a97 2
Checkout ltib from CVS as described [[#SavannahCvs][above]] and run these
commands:
d99 1
a99 4
<verbatim>
$ cd ltib
$ ./ltib
</verbatim>
d102 1
a102 1
---++ How do I install LTIB from a binary release (iso image)
d111 1
a111 1
# mount <bspname.iso> /mnt/cdrom -o loop
d116 1
a116 1
$ /mnt/cdrom/install
d124 2
a125 2
$ cd <target_dir>/ltib
$ ./ltib
d128 1
d130 2
a131 2
#ConfigurationSection
---+ Configuration
d133 1
a133 1
Configuration of ltib is started by using one of the following commands:
d135 1
a135 3
   * <verbatim>./ltib</verbatim> on the very first run for a CVS instance
   * <verbatim>./ltib -m config</verbatim> configure only
   * <verbatim>./ltib --configure</verbatim> configure and build
d137 4
a140 1
---++ Navigation
d142 1
a142 2
Most of the navigation information is show at the top of the configuration.
In addition you may use:
d144 1
a144 2
   * <verbatim>/</verbatim> : This searches for a configuration keyword
   and if found shows location and dependency information.
d146 1
a146 3
   * <verbatim>s</verbatim> : This searches the text of the menus for key
   words and re-postition you to the location of any matches.  You may
   repeat this operation to continue a search.
d148 2
a149 2
   * *page-up/page-dn* keys can be used to jump up and down lists a screen
   at a time.  The mapping for these keys varies from system to system.
a150 1
---++ Top level platform selection screen
d152 1
a152 5
The top level configuration screen shows the platform specific configuration
points.  The exact composition of this screen varies from platform to
platform depending on the available options it offers.  This example
is taken for the mpc8548cds platform, I have broken down each section of
the screen and given an explanation:
d154 3
a156 4
<verbatim>
--- Choose the target C library type
    C library type (glibc)  --->
</verbatim>
d158 5
a162 3
Most platforms offer both *glibc* or *uClibc* C libraries.  What this option
actually does is condition the choice of available toolchains from which
you can select.
d164 1
a164 24
<verbatim>
--- Choose your toolchain
Toolchain (gcc-3.4/glibc-2.3.4 e500 (DPFP))  --->
(-mcpu=8548 -mhard-float -mfloat-gprs=double) Enter any CFLAGS for gcc
</verbatim>

This entry allows you to choose from the available list of toolchains.
The choice you make will drive the CFLAGS entry which follows.  You may
of course override the value for CGLAGS.  When ltib runs, it will download
(if required) and install the toolchain you have selected it

Note that every platform includes an option to select a custom toolchain.
This allows you to use most standard cross compilers that are your 
system.  The most common use of this option is to test new toolchains
before wiring them in to the platforms toolchain selection list permanently.
When using a custom toolchain, you'll be prompted for:

   * *toolchain path* : This is the absolute base path name of your toolchain.
   For instance, if wanted to use: <verbatim>/opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux/bin/arm-linux-gcc</verbatim>
   the correct entry would be: <verbatim>/opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux</verbatim>

   * *cross tools prefix* : This is the value that prefixes all the standard
   toolchain executables for your given cross toolchain.  So for the example
   just given, this would be <verbatim>powerpc-linux-</verbatim>
d166 3
a168 1
   * *CFLAGS* : Normally this can be left blank
d170 3
a172 5
<verbatim>
--- Bootloader
[*] Build a boot loader
      U-Boot options  --->
</verbatim>
d174 6
a179 1
If available, this allows you select and built a bootloader for your platform.
a180 6
<verbatim>
    kernel (Linux 2.6.11+pq3 patches)  --->
[ ] Include kernel headers
(linux_2.6.11_mpc8548_cds_def.config) kernel preconfig
[ ] Configure the kernel
[ ] Leave the sources after building
d182 1
a182 1
</verbatim>
d184 1
a184 2
   * *kernel* item lets you select from the list of available kernels for
   the platform.
d186 1
a186 2
   * *Include kernel headers* tells ltib to install the header files from
   the kernel you have built into <verbatim>rootfs/usr/src/linux/include</verbatim>
d188 1
a188 3
   * *kernel preconfig* shows the kernel config file that will be used
   when building the kernel.  This is automatically selected according to
   choice of kernel.  You may overrride this.
d190 3
a192 2
   * *Configure the kernel* will cause ltib to drop into the Linux kernel
   configuration screen when ltib is building the kernel package.
d194 2
a195 3
   * *Leave the sources after building* : this option will leave the 
   source for kernel unpacked after the kernel package has been built
   and installed.
d197 1
a197 8
<verbatim>
--- Package selection
    Package list  --->
--- Target System Configuration
    Options  --->
--- Target Image Generation
    Options  --->
</verbatim>
d199 1
a199 2
These items drop you into the non-package specific configuration screens,
which are discussed in the next section.
d201 3
a203 4
*Note:* at the bottom of the screen, you'll see:
<verbatim>
Load an Alternate Configuration File
</verbatim>
d205 5
a209 5
This can be used to import a complete configuration for your platform.  For
instance, you may save out a particular config to a named file, for re-use
later.  Alternatively, someone else working on the same platform may send
you their platform configuration.  These should be placed in the 
<verbatim>config/platform/<your_target>/</verbatim> directory.
d211 1
a211 1
---++ Common Package selection screen
d213 1
a213 4
<verbatim>
--- Package selection
    Package list  --->
</verbatim>
d215 2
a216 8
Selecting *Package list* will drop you into the package selection screen.  Use
this screen to add and remove packages as required.  Normally the default
configuration is just fine.

Nearly all packages are common across platforms, with a few exceptions that are
conditioned by the choice of the current platform.  If a package requires
another package, it will auto-select it (auto-dependency resolution).  Here is
an example of the beginning of this screen:
d218 1
a218 22
<verbatim>
[*] apptrk binary package for powerpc 
[ ] autoconf
[ ] automake
[*] Include C library
(base_libs) C library package
[ ]   Include libc locale files ?
[ ]   Include header files from toolchain ?
[ ]   Include static libc libraries ?
[ ] alsa-lib
[ ] alsa-utils
[ ] bash
[ ] bind
[ ] binutils
[ ] bison
[*] boa
[ ] bonnie++
[*] busybox 
(busybox.config) busybox preconfig filename
[ ]   Configure busybox at build time
[ ] bzip2
</verbatim>
d220 5
d226 4
a229 5
---++ Common Target System Configuration screen
<verbatim>
--- Target System Configuration
    Options  --->
</verbatim>
d231 2
a232 4
Selecting *Options* will drop you into the target system configuration options
screen.  The purpose of this screen is to allow you to configure your
target system.  I have broken down this screen with an explanation of
each item:
d234 4
a237 3
<verbatim>
(mpc8548cds) target hostname
</verbatim>
d239 4
a242 1
This option lets you configure the host name for your target.
d244 5
a248 4
<verbatim>
[*] boot up with a tty and login
(::respawn:/sbin/getty -L ttyS1 115200 vt100) Enter your inittab startup line
</verbatim>
a249 4
If unchecked, your target will boot straight to the shell prompt.  The 
advantage of this is that you don't need to know the baud rate or tty device
for your target.  Very often this option will be left unchecked during
initial development of a BSP.
d251 1
a251 2
If checked, a default entry is shown for the *inittab* startup line. This
will vary from platform to platform.  You may override this entry.
d253 1
d255 1
a255 1
()  load these modules at boot
d258 3
a260 77
You may enter a list of modules you want loaded at boot time here.

<verbatim>
[*] start networking
      Network setup  --->
</verbatim>

By selecting *start networking*, you will be able to enter and configure
the *Network setup* screen.  This screen allows you to configure up to
5 eth devices.  The following shows the entries for eth0:
<verbatim>
[*] Enable interface 0
(eth0) interface
[ ]   get network parameters using dhcp
(192.168.1.100) IP address
(255.255.255.0) netmask 
(192.168.1.255) broadcast address
(192.168.0.1) gateway address
(192.168.0.1) nameserver ip address
</verbatim>

By default most platforms are configured with a non-routeable fixed local
IP address.  You need to change these as appropriate.  If you are unsure
of what these settings do, please consult with your network administrator.

Back in the target system configuration screen, after the network setup,
you'll see a set of options that let you enable/disable whether or not
the available services will run on the target board.  The exact list 
depends on which packages have been selected.  Here is an example:
<verbatim>
[*] set the system time at startup
(ntp.cs.strath.ac.uk) NTP server name/ipaddress
[*] start syslogd/klogd
[*] start inetd
()    Enter command line arguments for inetd startup
[*] start portmap
[*] start boa (webserver)
(-c /etc) command line arguments for boa
</verbatim>

---++ Common Target Image Generation
<verbatim>
--- Target Image Generation screen
    Options  --->
</verbatim>

Selecting *Options* here will drop you into the target image generation
options screen.  The purpose of thise screen is to allow you to configure
certain aspects of the target image.

By default, an NFS mountable image is always generated, but in addition you
may also choose to package your image as a JFFS2 image or a compressed
ext2 RAMDISK image.

Here is an example screen for a system that is using ext2.gz RAMDISK.

<verbatim>
--- Choose your root filesystem image type
     Target image: (ext2.gz ramdisk)  --->
</verbatim>

Here you can choose between NFS only, JFFS2 or ext2.gz RAMDISK image types

<verbatim>
[ ] read-only root filesystem 
</verbatim>

Selecting this option will cause your root filesytem to be mounted read-only.
Certain directories that must have write permissions will be copied to
a read/write ramfs/tmpfs at boot and bind mounted.

<verbatim>
[*] create a ramdisk that can be used by u-boot
</verbatim>

This option is available if you are using u-boot for your target.  It 
turns the RAMDISK into a format that u-boot can understand (it adds headers)
d262 2
a263 63
<verbatim>
()  rootfs target directory
</verbatim>

This copies the output image (RAMDISK or JFFS2 image) to a chosen directory.
You must have write permissions there.

<verbatim>
[ ] Keep temporary staging directory
</verbatim>

This is used mainly during debugging.  It keeps the intermediate directory 
that is used as the staging directory for the RAMDISK/JFFS2 image.

<verbatim>
[*] remove man pages etc from the target image
[*] remove the /boot directory
[*] remove the /usr/src/ directory
[*] remove the /usr/include directory
()  remove these directories
()  remove these files[*] remove the static libraries
[*] strip any remaining binaries or libraries in the target image
</verbatim>

These options allow you to remove certain files/directories from the 
RAMDISK/JFFS2 image.  The idea is to save space on footprint challenged
platforms

<verbatim>
(0) Allocate extra space (Kbytes)
</verbatim>

This option allows you to reserve spare capcity for your JFFS2 image

---++ How can I re-configure the kernel under LTIB

Note: example here shown for the mpc8548cds platform

   * Run ltib and select 'Configure the kernel'

<verbatim>
./ltib --configure
</verbatim>

   * Locate the section that looks like:
<verbatim>
         --- Choose your Kernel
             kernel (Linux 2.6.11+pq38 patches)  --->
         [ ] Include kernel headers
         [ ] Configure the kernel
         [ ] Leave the sources after building
</verbatim>

   * Enable 'Configure the kernel', exit and save.

The kernel will build and stop in  menuconfig.  This will be
set to the values stored in:

<verbatim>
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
</verbatim>

After you've selected and changed any values, ltib will save these back to:
a265 243
config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev
</verbatim>

If you want to try out a number of different kernel options, but don't want to completely re-build each time:

   * Select the option: <verbatim>    [ ] Configure the kernel</verbatim>

   * run:
<verbatim>
./ltib -p kernel-2.6.11-pq38 -m prep
</verbatim>

   * build:
<verbatim>
./ltib -p kernel-2.6.11-pq38 -m scbuild
</verbatim>

This will stop and let you tune the kernel values.  If there is a file <verbatim>config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev</verbatim>, this will be used as a starting point.  The file gets saved back to the same filename, so you can incrementally change values.  

   * To copy the built kernel to the rootfs/boot directory (optional)
<verbatim>
./ltib -p kernel-2.6.11-pq38 -m scdeploy
</verbatim>

This will also have the side effect of marking the kernel as built, so you
can run <verbatim>./ltib</verbatim> on it's own without it complaining
that the directory is in the way.

*Note:* You can keep running the *scbuild* step until you're done.
If you change any source  code in 'rpm/BUILD/linux-xxx/' you can capture
your changes at the end by running:

<verbatim>
./ltib -p kernel-2.6.11-pq38 -m patchmerge
</verbatim>

This will generate a patch of your changes and update the spec file.

To make your config changes permanent, you can do the following:
<verbatim>
mv config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config
</verbatim>

Normally at this point you'd do a cvs commit if you have CVS write access.


---+  Deployment

Some targets have specific instructions in their platform directory, this
file is normally called *deployment_instructions.txt*, for example:
<verbatim>config/platform/tqm823l/deployment_instructions.txt</verbatim>

The following instructions are a general case (based on tqm823l), if you
do find a *deployment_instructions.txt* follow the specific instructions
in their after reading this general overview, that gives strategy pointers.

Additionally, some iso images contain more formal BSP documentation, you
should also consult this, if available.

---++ I ran ltib, where's my bootloader/kernel/root filesystem

This may vary from target to target (depends on the defconfig), but 
here's the general case:

---+++ root filesystem

The root filesystem will be a directory tree found under *rootfs* . The
files under here will generally be owned by root, with groups permissions
etc set as required to run on the actual target board.  The purpose of
this directory is to provide a node that can be NFS exported by your host
and NFS mounted as your target's root filesystem.

---+++ bootloader

The bootloader (if built) will be found under *rootfs/boot/* for example
many powerpc platforms would have the following bootloader components:

   1 *rootfs/boot/u-boot* : the elf version of u-boot (for debug)
   2 *rootfs/boot/u-boot.bin* the binary image of u-boot that could be
   installed into Flash (*normally you don't need to do this*)

---+++ kernel

The kernel (if build) will be found under *rootfs/boot* for example
many powerpc platforms would have the following bootloader components:

   1 *vmlinux*: the elf image of the kernel (for debug if built appropriately)
   2 *uImage*: the bootable kernel image (name depends on the target)
   3 *System.map*: the symbol map file for the built kernel
   4 *linux.config*: the configuration used to build the kernel image

---++ How do get my kernel/root filesystem running on my target

The most common way to deploy your kernel and root filesystem is
to load the kernel on the target using tftp and then boot the
kernel with the appropriate parameters to mount the root filesystem
from the host using NFS.

---+++ Export the root filesystem from your host using NFS

The exact details to do this vary from distribution to distribution,
but in general, here are the typical steps that you need carry out
(you need to be root to do this):

   * Choose an IP address on your network for the target (one not already
   in use).  You need to make sure that you have configured ltib so
   the root filesystem uses this IP address.
   See [[#ConfigurationSection][configuration]]
   The target can even use dhcp to get it's IP address, however if you 
   select DHCP in ltib's config and you are doing NFS deployment,
   what it actually does is bypass setting
   up the eth device, and relies on the current setting inherited by
   the kernel's boot parameters

   * Make a note of the IP address for your host.
   For this example, we'll assume the following values:
      * Target IP address: *192.168.0.254*
      * Host IP address: *192.168.0.204*
      * Root filesystem location: *~/ltib/rootfs*

   * Make a symlink from /tftpboot to the root filesystem:
<verbatim>
ln -s ~/ltib/rootfs /tftpboot/192.168.0.254
</verbatim>

   * Make sure you have the NFS server and portmap installed on your system

   * Export this directory by editing */etc/exports*, add the entry:
<verbatim>
/home/<uid>/ltib/rootfs *(rw,no_root_squash)
</verbatim>
   *NOTE*: this example has all security for this directory turned off!
   Any host may access this exported directory.  
   See <verbatim>man exports</verbatim> for more information

   * Re-start NFS:
 <verbatim>
sh /etc/rc.d/init.d/nfs restart
 </verbatim>

---+++ Make sure you have a tftp daemon running on your host

Most boot loaders load the kernel over a network connection using tftp
protocol.  So your target's bootloader can access the kernel you have built,
you must make sure you have a tftp daemon on your host.  Here are some checks
you can do:

    1 Check that the tftp server program is present on your system.
    by running the command below.  If it is not present you'll need to
    install the tftp-server package.
<verbatim>
$ ls /usr/sbin/in.tftpd
/usr/sbin/in.tftpd
</verbatim>
    2 Check to see if inetd is setup to run the tftp server by running the
    command below, your output should be similar:
<verbatim>
$ netstat -a | grep tftp
udp        0      0 *:tftp                      *:* 
</verbatim>
    It there is no output, make sure that it's not disabled in 
    <verbatim>/etc/xinetd.d/tftp</verbatim>.  In my copy I note the following
    line:
<verbatim>
    disable = no
</verbatim>
    3 Make sure that if you have a firewall on your host it will not block
    incoming packages from your target.  


---+++ Copy your kernel image to a location when tftp can retrieve it

Generally the tftp server will be configured to *chroot* to the directory
<verbatim>/tftpserver</tftpserver>.  This means that you need to copy your
kernels to this, or a subdirectory under that directory.  In our example,
we do the following:
<verbatim>
$ cp rootfs/boot/uImage /tftpboot
</verbatim>


---+++ Setup the bootloader arguments for your kernel to use the exported RFS

The example shown is for a system using uboot/ppcboot with the setup
in the earlier section:

   * Setup the network parameters. At the ppcboot prompt:
<verbatim>
=> setenv ipaddr 192.168.0.254
=> setenv serverip 192.168.0.204
=> setenv bootargs root=/dev/nfs nfsaddrs=192.168.0.254:192.168.0.204
</verbatim>


---+++ Load your kernel onto the target board and boot the target

<verbatim>
=> tftp 100000 vmlinux.gz.uboot
.........
=> bootm 100000
</verbatim>


#LtibSupport

---+ Support

---++ Savannah public mailing list

The primary means of getting support if you are using LTIB from Savannah
is to join the mailing list [[http://lists.nongnu.org/mailman/listinfo/ltib][here]] and to submit your questions.

---++ iso images downloaded from freescale.com

If you are using an iso image downloaded from http://www.freescale.com/ you
may post support questions by doing the following:

   * go to www.freescale.com
   * click on "Support / Technical support"
   * click on "Submit a Service Request" 
   * register to get a user name and password.
   * login in with your user name and password
   * on the "New Service Request" page:
      * category = Technical Request
      * topic = CodeWarrior
      * Click on "Continue"
   * fill out the information for the service request
   * lick on the "Submit" button at the bottom of the page.

---+ Command line options explained

If you run the command show below, you'll see the following summary:

<verbatim>
$ ./ltib --help

This script is used to manage the building of BSPs with common target
root filesystems.  The rpms are installed as they are built
in the directory /home/seh/ltib_bsps/ltib-dev/rootfs (unless overriden in the resource file)

Edit the file .ltibrc in this directory to change the default system
configuration, or .ltibrc in your home directory.

d268 1
a268 1
        --mode|m
d270 1
a270 1
            prep        just prep the package
d274 1
d276 1
a276 1
            clean       clean/uninstall target packages
d278 5
a285 1
            shell       enter ltib shell mode (sets up spoofing etc)
d288 4
a291 4
        --preconfig   : configuration file to build from (defaults to .config)
        --profile     : profile file.  This is used to select an alternate
                        set of userspace packages, this is saved and used
                        on later runs of ltib (e.g config/profiles/max.config)
d300 1
a300 1
        --dry-run|d   : mostly a dry run (calls to system are just echos)
d304 1
a304 5
        --deploy|D    : run the deploy scripts even if build is up to date
        --dlonly      : just download the packages only
        --dltest      : test that the BSP's packages are available
        --leavesrc|l  : leave the sources unpacked (only valid for pkg mode)
        --hostcf      : (re)configure/build/install the host support package set
d309 1
d311 2
a312 1
---++ Without any arguments
d314 3
a316 1
Running <verbatim>./ltib</verbatim> will do the following
d318 1
a318 6
   1 Install common host site support packages (first time only)
   2 Prompts the user for the target platform (first time only, CVS only)
   3 Enters the main platform configuration menu (first time only). 
   The initial state is the default config for that platform and is usually
   okay for most users
   4 Builds/installs the chosen packages as required
d320 3
a322 2
#OptionConfig
---++ -m config
d324 1
a324 2
Bring up the platform configuration menu.  ltib does not continue to build
packages after you exit the configuration menu
d326 3
a328 2
#OptionConfigure
---++ --configure
d330 2
a331 2
Bring up the platform configuration menu.  After you exit the configuration
menu, ltib build/installs the chosen packages as required
d333 1
a333 1
---++ -m clean
d335 1
a335 2
This uninstalls all rpm packages for this target.  This effectively
de-populates the rootfs directory.
d337 2
a338 6
*Notes:*
   * There may be files left in <verbatim>rootfs</verbatim> if you have
   NFS mounted this directory on your target 
   (e.g. <verbatim>/var/log/xx</verbatim>
   * It does not delete the binary rpm files, so if you re-run ltib, without
   any changes, it will just re-install the currently selected binary rpms.
d340 3
a342 1
---++ -m distclean
d344 2
a345 3
This mode is used to completely remove all the current ltib project's files,
as they would be found from a fresh cvs checkout.  It does not remove any
files from the shared common areas.
d347 2
a348 2
This mode is generally used with CVS versions so you can go back to the 
target platform selection screen and build a different target.
d350 3
a352 1
---++ -m release
d354 2
a355 2
This encapsulates the current LTIB project into an iso image that will
not require network access.
d357 3
a359 1
---++ -m shell
d361 1
a361 4
This is a developer function.  What it does is drops you to a shell prompt
with the environment setup exactly as it would be during the building
of an rpm spec file.  In this situation, all the ltib environment variables,
and compiler spoofing are setup for you.
d363 2
a364 2
This can be very useful when first developing a package when you are
trying to make changes so that it can cross compile.
d366 1
a366 2
#OptionListpkgs
---++ -m listpkgs
d368 1
a368 2
This mode is used to show all available packages, whether selected and their
individual licenses.  Here is some sample output from the *tqm823l* platform:
d370 1
a370 7
$ ./ltib -m listpkgs
-----------------------  ----------------         ------- -------     -----------------------------------------
Package                  Spec file                Enabled License     Summary
-----------------------  ----------------         ------- -------     -----------------------------------------
DirectFB-0.9.24-1        DirectFB                    n    LGPL        DirectFB is a graphics library for embedded syst
NAS-config-1.0-1         NAS-config                  n    GPL         NAS setup scripts and instructions
alsa-lib-1.0.10-0        alsa-lib                    n    distributab A libraries for ALSA (Advanced Linux Sound Archi
d373 6
a378 1
---++ --preconfig
d380 3
a382 4
Use the specified configuration file to configure and built your target
platform.  This configuration must be consistent with your current target
(e.g. it can't be from another architecture, or use an incompatible
toolchain).
d384 4
a387 3
The purpose of this option is to allow a method of quickly swapping between
one set of configuration points and another.  Developers can use this
as a means of exchanging their configuration setting.
d389 2
a390 1
---++ --profile
d392 2
a393 2
This is similar to preconfig, except it only changes the selection of
userspace packages.
a394 3
The main purpose of this is to allow the creation of profiles, which are
used to specifiy certain types of system.  For instance, a minimum root
filesytem, a full system (for auto-test) etc.
d396 1
a396 1
---++ --rcfile <f>
d398 3
a400 1
This rarely used option allows you to override ltib's default resource file.
d402 3
a404 1
---++ --batch|-b
d406 1
a406 2
This option allows you to run ltib non-interactively.  It uses *conf* instead
of *mconf* when running the configuration stages, and assumes defaults.
d408 4
a411 1
The main purpose of this mode is to support auto-building
d413 1
a413 1
---++ --force|-f
d415 4
a418 2
This option forces either all packages, or the specified package to be
re-built.
d420 4
a423 1
---++ --reinstall|-e
d425 4
a428 2
This option forces either all packages, or the specified package to be
re-installed.  It does not force a rebuild of the packages.
d430 1
a430 1
---++ --nodeps|-n
d432 4
a435 1
This rarely used option disables rpm install/uninstall dependency checking.
d437 1
a437 1
---++ --conflicts|-k
d439 4
a442 3
Normally, ltib will allow packages that have overlapping files to be installed.
This is a deliberate design choice, which allows scaling from small to 
large filesystem footprints.
d444 1
a444 2
This rarely used option disables this and will not allow a package to install
if it's files will conflict with another installed package.  
d446 4
a449 1
---++ --keepsrpms|-s
d451 2
a452 3
Normally, ltib only builds binary rpms.  This rarely used option will
cause ltib to also build srpms.  This may be useful if a developer wants
to share a source package.
d454 1
a454 1
---++ --verbose|-v
d456 2
a457 2
Using this option will cause ltib to spew out lots of debug information.
It's mainly used for debug purposes
d459 1
a459 1
---++ --dry-run|-d
d461 4
a464 2
This option is used to test-run ltib.  It will show what commands it will
run, without actually running them.
d466 2
a467 1
---++ --continue|-C
d469 4
a472 3
Normally, ltib will stop as soon as it encounters an error when building 
packages.  With this option, ltib will report the error, but continue
to build.
d474 1
a474 1
The main purpose of this option is to support auto-building.
d476 4
a479 1
---++ --version|-V
d481 1
a481 2
This option reports the version number of ltib.  The numbering scheme
is <year>.<quarter>.<release>
d483 4
a486 1
---++ --noredir|N
d488 1
a488 3
Normally, during the first run of ltib, when it is building and installing
the common host-packages, the output will be re-directed to the file
<verbatim>host_config.log</verbatim>
d490 9
a498 1
---++ --deploy|-D
d500 6
a505 2
This option forces the running of just the deploy sections of ltib, even
if the build is up to date.
d507 3
a509 1
---++ --dlonly
d511 1
a511 3
This rarely used option provides a way of downloading all the source/patches
that will be required to build the current ltib configuration, without
actually running the build.
a512 3
The main reason for this option is to support people who have temporary
network connections (for instance over a VPN/proxy).  This allows them
to get all the networking activity out the way before they build,.
a513 1
---++ --dltest
d515 1
a515 2
This option is used to test whether or not the packages that are configured
to be built can be downloaded.
d517 8
a524 2
The main purpose of this to to check to see if the required sources/patches
are available at http://bitshrine.org/gpp
a525 1
---++ --hostcf
d527 4
a530 2
This rarely used option allows a user to re-configure/build/install packages
to the common host package support area.
d532 5
a536 2
It is mainly used by people developing the ltib tool itself when testing
on different host distributions.
d538 10
a547 1
---++ --help
a548 1
This displays the a summary of the command line options.
d550 4
a553 1
---++ Operations on a single package (developer mode)
d555 4
a558 1
---+++ -p pkg
d560 4
a563 1
Build/install just this package.
d565 4
a568 2
The purpose is to allow people to develop new packages and reference 
their spec files, before the package has been fully added to the system.
d570 1
a570 4
*Notes:*
   * in this case, <verbatim>pkg</verbatim> is actually the name of the 
   spec file, without the *.spec* extention.
   * this option will not leave the source code unpacked
d572 6
a577 1
---+++ -p pkg --leavesrc|-l
d579 2
a580 2
This option tells ltib to leave the sources for a package unpacked after
it has been built and installed.
d582 1
a583 1
---+++ -p pkg -m prep
d585 1
a585 2
In this mode, unpack the spec files sources and apply any patches.  The 
sources will be found in <verbatim>rpm/BUILD/xxx</verbatim>
d587 1
a587 1
---+++ -p pkg -m scbuild
d589 18
a606 2
In this mode, just run the *%Build* section of the package's spec file.
This is done using rpm's *--scbuild* option.
a607 1
This mode assumes you have previously done a *prep* of the package.
d609 1
a609 1
---+++ -p pkg -m scinstall
d611 1
a611 2
In this mode, just run the *%Install* section of the package's spec file.
This is done using rpm's *--scinstall* option.
d613 2
a614 2
This mode assumes you have previously done a *prep* and a *scbuild* of 
the package.
d616 1
a616 1
---+++ -p pkg -m scdeploy
d618 1
a618 2
In this mode, ltib internally runs the *%Install* section of the package's spec file.  It then creates a temporary binary rpm and installs this into
the *rootfs* area.
d620 5
a624 2
Note that after running this mode ltib will allow you to run in 
non-package mode, even with the sources for this package unpacked.
d626 2
a627 2
This mode assumes you have previously done a *prep* and a *scbuild* of 
the package.
d629 4
a632 1
---+++ -p pkg -m patchmerge
d634 1
a634 4
In this mode, ltib will generate a patch of the diffs between your currently
unpacked sources (after running *make distclean*) and the sources for
this package before your changes.  This patch is saved into the LPP
and the spec file is updated to reference this new patch.
d636 7
a642 2
The purpose is to allow developers to capture their changes to a package
after they have completed their work/testing.
d644 2
a646 1
---+ General questions
d648 1
a648 1
---++ Do I need root permissions to use LTIB
d650 2
a651 3
Yes, but only for the installation rpms after they have been built as your
normal user.  This is because the target image must create device nodes and
other files with particular ownerships and permissions.
d653 3
a655 3
The way this is achieved is by using *sudo* for *rpm install*.  All
other operations (building of packages) are performed as the non-root
user.
d657 3
a659 6
LTIB should never be run as root.  The main reason is to prevent
mistakes during development from causing damage to the host file system.
To minimise the chance of mistakes during rpm installation, all rpms
have a non-standard re-locatable prefix, which would cause them
to be installed in a benign place if a user accidentally runs a
stand-alone rpm install.
d661 1
a661 1
---++ LTIB is rpm based, will it work on Debian
d663 4
a666 2
Yes, Debian supports rpms.  The *ltib* script will prompt you if
anything is required to setup rpm on your Debian machine.
d668 3
a670 1
---++ Why does it take so long for LTIB to install
d672 1
a672 3
LTIB requires some known packages on the host to function correctly
(notably rpm).  Also, there are some packages that are unlikely to 
be on your host that get installed by LTIB (e.g. u-boot-tools, lkc, genext2fs, mtd-utils).
d674 2
a675 5
The first time you install ltib on a machine, it will take quite a long time
to build and install the host side packages (mostly rpm-fs).  These host
packages are shared across ltib installs.  If you install (check-out) in
another directory (or another user installs), it will be much quicker the next
time.
d677 1
a677 1
---++ How do I get LTIB to continue building, even if there are errors
d679 4
a682 3
You have to take care, because sometimes if a package fails to build
a package built later may fail because it needs something from the
earlier packages (e.g. texinfo needs ncurses).
d684 4
a687 2
If you really want to do this, add -C or --continue option
to the ltib command line.
d689 5
a693 1
---++ How do I know what license a package uses
d695 4
a698 1
Use the [[#OptionListpkgs][-m listpkgs]] option
d700 1
a700 1
---++ How do I change package selection/configuration and immediately build
d702 2
a703 1
Use the [[#OptionConfigure][--configure]] option
d705 6
a710 1
---++ How do I change package select/configuration without building
d712 6
a717 1
Use the [[#OptionConfig][-m config]] option
d719 1
a719 1
---++ I don't see uclibc/glibc get built, what is going on
d721 1
a721 2
The strategy in ltib is to always use the C library components that come
from the toolchain.  This allows us to do the following:
d723 1
a723 2
   * Ensure that the packages built exactly match the toolchain components
   * Easily switch glibc/uclibc versions, just by toolchain selection
d725 1
a725 6
Note that it is possible to build uclibc/glibc within ltib, but particularly
with glibc, great care must be taken to ensure that packages you build 
actually reference the built C library.  uClibc is far less problematic
in that respect.  Either way, it is *highly recommended* that you stick
with the strategy of using the C library components out of the toolchain
(this facilitated by the *base_libs* package).
d727 1
a727 1
---+ Source code
d729 1
a729 1
---++ Where are the sources for the packages
d731 3
a733 3
If not available in the local common cache area, they are downloaded
and cached in a common area.  If you are using an iso image, these
will have been pre-installed into the local common cache.
d735 7
a741 1
---++ Where do the sources get downloaded from (what is the LPP/GPP)
d743 1
a743 1
The primary system used is the GPP/LPP.
d745 2
a746 2
The GPP (Global Package Pool) is a publicly available http server that is used
to store sources/patches for LTIB.
d748 3
a750 2
The LPP (Local Package Pool) is a local common cache that is used to store
all sources/patches that have been accessed by LTIB.
d752 1
a752 4
When ltib needs to build rpms, the spec-file for the
package is parsed.  After parsing, the builder has a list of sources
and patches that are needed to build the package.  The builder then
does the following:
d754 3
a756 2
   * Checks if the file/symlink (without any path/URL prefix) is present
   in rpm/SOURCES, if it is that is used.  If not:
d758 1
a758 4
   * Checks if the file (without any path/URL prefix) is present in the
   LPP directory (see the *%lpp* entry in *.ltibrc*).  If the
   file exists, a symlink is made from it to rpm/SOURCE and that link
   is used.  If not:
d760 1
a760 4
   * The builder tries to download the file from the GPP (specified by
   the *%gpp_url* tag in *.ltibrc* to the LPP using *wget*
   If that succeeds, a symlink is made from it to rpm/SOURCE and that link
   is used.  If the download does not succeed:
d762 4
a765 13
   * If the download from the GPP does not succeed: If the entry parsed
   from the spec-file contains an Internet url prefix
   as part of it's path, the builder will then try to download the
   file from there.  This will be tried first with proxying on (if applicable)
   and then if that fails, with proxying off.  If these final steps fails,
   the builder gives up and fails with an error.

---+ Auto building (unattended builds)

---++ How do I autobuild a complete BSP

Pass in the --preconfig option.  For example, to do an unattended
build of the default configuration of the tqm823l BSP:
d767 1
d769 1
a769 1
$ ./ltib --preconfig config/platform/tqm823l/defconfig --batch
d772 4
a775 1
---++ How do I autobuild a BSP but with a full package payload (for testing)
d777 1
d779 1
a779 1
$ ./ltib --preconfig config/platform/tqm823l/defconfig --profile config/profiles/max.config --batch
d782 3
a784 3
In addition, there is an example autobuilder script that I run from a cron
jobs for my nightly builds, it is located in:
<verbatim>bin/autobuild_ltib</verbatim>
d786 3
a788 53

---+ Cross toolchains

---++ Do you supply the target cross-compilers for the LTIB BSPs

Yes, these are stored on the GPP as the binary rpms and will be downloaded and installed as required.

---++ Why don't you build cross toolchains in LTIB

Every package that goes into the root filesystem depends on the 
cross toolchain.  If there are any bugs in the toolchain that is used,
these will have consequences to every package.  By supplying a toolchain
that we have built in a known environment and tested, we can be confident
that it works.

---++ Can I get the sources to the toolchains and build my own

Sources are always available as srpms, but building of toolchains is *NOT*
 supported.

If you have an iso release, the sources for your toolchain will have been
installed into a local common cache area.  If not you 
will find them on http://bitshrine.org/gpp . If you can't find your
sources, please send a support request (see [[#LtibSupport]])

Normally, the srpms provided use crosstool (http://kegel.com/crosstool/)
to build the toolchains.  Crosstool and its patches are encapsulated in
the srpm, but the external GNU components are not.  If you build using
the srpm you will need to make sure that crosstool is able to 
access the Internet to download these pieces.  Normally these pieces can
be also found on http://bitshrine.org/gpp
---+ Root Filesystems

---++ Can I add files to the target root file system without creating a package

Yes, to do this, you need to create a merge directory.  There are 2
options:

    1 Top level merge directory, that applies to all targets
    2 Platform specific merge directory

The platform specific merge directory contents override the top level merge
directory, which overrides the corresponding file(s) in your rootfs

*Example:*

You have a CVS version of LTIB, and you have build the tqm823l default
configuration, now:

   1 You want to add the a platform specific file /home/fred/myfile1
   2 You want all platforms you may build to use your own /etc/hosts file

Here's what you would do:
d791 1
a791 6
$ cd <my_ltib_dir>
$ mkdir -p config/platform/tqm823l/merge/home/fred
$ cp <my_files>/myfile1 config/platform/tqm823l/merge/home/fred
$ mkdir -p merge/etc
$ cp <my_files>/hosts merge/etc
$ ./ltib
d794 1
a794 2
The files from your merge directory will now have been placed into the
corresponding directories under <verbatim>rootfs</verbatim>.
d796 3
a798 1
---++ Can I have more than one root file system on my host at the same time
d800 1
a800 2
Yes, the system will support multiple root file systems, for the same or
for different target architectures.
a801 3
If you are using an iso image, install your ltib archive into an different
directory by entering a new directory name for the installation when
prompted by the install script..
d803 2
a804 9
If you are using CVS, check-out CVS into a different directory by using the
*-d* option to cvs co.  For example:
<verbatim>
$ cvs -z3 -d:pserver:anonymous@@cvs.savannah.nongnu.org:/sources/ltib co -d newname ltib
</verbatim>

If the target architecture is different from the original one, a different
cross compiler will be needed.  It will be downloaded and
installed in the correct location if it isn't already present.
d806 1
a807 1
---+ Errors output from ltib
a808 1
---++ syntax error at ./ltib line 811, near "format twiki_top "
a809 1
Your version of perl is too old.  You need 5.6.1 or later
@


1.1.1.5
log
@Import from fsl 20060530
@
text
@a18 29
---+ Quick start

For those of you who don't like to read documentation, here are the bare-bones
instructions for installing LTIB.

   * *Getting/installing the software*
<verbatim>
$ cvs -z3 -d:pserver:anonymous@@cvs.savannah.nongnu.org:/sources/ltib co ltib
</verbatim>
   * *Configuring the software*
<verbatim>
$ cd ltib
$ ./ltib
</verbatim>

You will be prompted if you need to do anything (for instance to add sudo
access for your user).

   * *Running your image*

Having build your target image you'll find a directory call *rootfs*.  This 
contains a sub-directory *boot*, which contains your bootable Linux kernel.
The root filesystem itself can be NFS exported and NFS root mounted by
your kernel.  

The exact details of deployment for each target vary, but often there are
helpful notes under your platform's config directory in a file called
*deployment_details.txt*, for example: <verbatim>/config/platform/tqm823l/deployment_instructions.txt</verbatim>.

d32 2
a33 2
   * Runs on most popular Linux host distributions (x86 32/64 and some PPC)
   * Command line interface, with curses configuration screens 
d39 1
a39 1
   * All package building as non-root user
d46 1
a46 1
   * Kernel selection can easily be changed from choicelist during
@


1.1.1.6
log
@Import from fsl 20060615
@
text
@d163 4
d168 1
a168 2
| glibc-headers | >= 2.2.x | to build/run host packages |
| glibc-devel   | >= 2.2.x | to build/run host packages |
a169 2
| libstdc++       | any? | to build rpm-fs host package |
| libstdc++-devel | any? | to build rpm-fs host package |
a171 2
| sudo      | any        | to run the 'rpm install' phase on each package |
| zlib       | any       | to build rpm-fs and mtd-utils host packages |
a172 3
| rpm       | any        | to build initial rpm-fs host package |
| rpm-build | any        | to build initial rpm-fs host package |
| wget      | any        | to download packages/patches on demand |
d177 5
a181 5
| flex      | any        | Not required we install:for host lkc |
| texinfo   | any        | to build genext2fs host package (requires ncurses-deve|
| gettext   | any        | genext2fs target package |
| autoconf  | >= 2.54    | Not required we install: automake target package |
| libtool   | >= 1.4.2   | Not required we install: libusb target package |
a1180 44
---++ I don't see uclibc/glibc get built, what is going on

The strategy in ltib is to always use the C library components that come
from the toolchain.  This allows us to do the following:

   * Ensure that the packages built exactly match the toolchain components
   * Easily switch glibc/uclibc versions, just by toolchain selection

Note that it is possible to build uclibc/glibc within ltib, but particularly
with glibc, great care must be taken to ensure that packages you build 
actually reference the built C library.  uClibc is far less problematic
in that respect.  Either way, it is *highly recommended* that you stick
with the strategy of using the C library components out of the toolchain
(this facilitated by the *base_libs* package).


---+ Packages

---++ How do I know which packages are available/will be installed?

Before configuring ltib, you can run bin/listpkgs on an ltib config file,
for instance, for the mpc8548cds, you could run:

<verbatim>
bin/listpkgs config/platform/mpc8548cds/defconfig
</verbatim>

This will list all the packages that can be selected.  The ones with a 'y'
in the 'Enabled' column will be built/installed by default.

If you have configured ltib already, you can get a more accurate (exact)
listing by running:

<verbatim>
./ltib -m listpkgs
</verbatim>

To select only those packages that are enabled, pipe either of the previous
commands to grep as follows:

<verbatim>
 ./ltib -m listpkgs | grep ' y '
</verbatim>

d1193 1
a1193 4
---++ How do I build/install just a single package?
<verbatim>
./ltib -p <package_name>
</verbatim>
d1195 2
a1196 2
*Note:* When specifying a package *-p*, the package will be force
        re-built, even if it is up-to-date.
d1198 2
a1199 198
*Note:* The build/install will fail if dependent packages are not
        already installed.

---++ How do I make changes to a package and capture them

By default, rpm will unpack, configure, build, install and remove all sources
in one step.  This is a deliberate feature to make sure a package is
fully rebuilt from pristine sources plus patches in a consistent way.

Obviously, if you're trying to work on a package, this scheme is not
helpful.  To facilitate this kind of development process, rpm
provides the notion of short-circuited builds/installs.

---+++ Example work-flow

 1. Unpack the sources and apply all current patches:
<verbatim>
./ltib -m prep -p <package>
</verbatim>

 2. Edit/add files under *rpm/BUILD/package/*

 3. Build the package with your changes:
<verbatim>
./ltib -m scbuild -p <package>
</verbatim>

 4. Once the package builds successfully, check the install phase:
<verbatim>
./ltib -m scinstall -p <package>
</verbatim>

 5. Test your package before committing the changes:
<verbatim>
./ltib -m scdeploy -p <package>
</verbatim>

 6. Repeat steps 2 -> 5  until you are satisfied with your results.

 7. Generate a patch and update the spec file:
<verbatim>
./ltib -m patchmerge -p <package>
</verbatim>

 8. Manually clean up the patch file (as required).

 9. Build from scratch and install
<verbatim>
./ltib -p <package>
</verbatim>

 10. Once you're happy with all your changes, upload the patch to the GPP
http://www.bitshrine.org/cgi-bin/gpp_upload.cgi

 11. Commit the updated specfile:
<verbatim>
cvs commit dist/lfs-5.1/<pkg>/<pkg>.spec
</verbatim>


---++ How can I add a completely new package to the rootf filesystem

The following work-flow examples show the process of importing
new packages to the root filesystem.

---+++  I have a directory with some sources unpacked

 1. First clean your sources (remove any .o, .a, .so generated files)
 and then make a 'tarball', for instance:
 <verbatim>
cd <my_new_package>-x.y
make clean
cd ..
tar zcvf <my_new_package>-x.y.tar.gz <my_new_package>-x.y
</verbatim>

 2. Move this tarball to the LPP so *ltib* can find it.
<verbatim>
mv <my_new_package>-x.y.tar.gz /opt/freescale/pkgs/
</verbatim>

3. Create a specfile using the existing template.
<verbatim>
mkdir dist/lfs-5.1/<my_new_package>
cp dist/lfs-5.1/template/template.spec dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
</verbatim>

 4. Edit and fixup the template to reflect your package.  The fields
 that need changing are:
| *Field* | *Description* |
| Summary | put in a summary of what the package is/does |
| Name    | put in the name of the packge (usually from the tarball name) |
| Version | put in the version (usually from the tarball/directory |
| Release | start at 1 and rev each time you change the spec file |
| License | e.g GPL/LGPL/BSD, look this up in the package's files |
| Group   | If this exists on an rpm based machine, copy from rpm -qi <package> <br> If not, choose something from /usr/share/doc/rpm-<version>/GROUPS |
| %Build  | often you'll need to add *--host=$CFGHOST --build=%{_build}* to the configure clause |

 5. Unpack the new package sources:
<verbatim>
./ltib -m prep -p <my_new_package>
</verbatim>

 6. Make any changes you need to the sources to get them to cross compile

 7. Build the new package with your changes:
<verbatim>
./ltib -m scbuild -p <my_new_package>
</verbatim>

 8. Once the new package builds okay, check the install phase:
<verbatim>
./ltib -m scinstall -p <my_new_package>
</verbatim>

 9. Install the test package in the NFS root filesystem area (rootfs) and test
<verbatim>
./ltib -m scdeploy -p <my_new_package>
</verbatim>

 10. Once you're happy the package is running correctly, capture your
 changes.

<verbatim>
./ltib -m patchmerge <my_new_package>
</verbatim>

Any changes you've made will be put into a patch file and copied to
/opt/freescale/pkgs.  In addition, the spec file will be updated to
reference the new patch.  You should check the patch and eliminate any
bogus diffs.


 11. Upload the sources to the GPP

For external public files, use this link: i
http://www.bitshrine.org/cgi-bin/gpp_upload.cgi.  You must have previously
been blessed as a developer to do this.  For more information, 
contact the mailing list: http://lists.nongnu.org/mailman/listinfo/ltib

The files to be uploaded are your original tarball plus the patch generated
by ltib.  You should take care to fill in the license/distributable/description
fields accurately.

 12. Add your spec file to cvs

<verbatim>
cvs add dist/lfs-5.1/<my_new_package>
cvs add dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
cvs commit -m "added new_package" dist/lfs-5.1/<my_new_package>/<my_new_package>.spec
</verbatim>


 13. Follow the steps in the next section on "adding to the config system"

---++ How do I introduce my new package to the config system

Here is an example for package 'strace'

   1. Edit config/userspace/packages.lkc, this is in alphabetic order.
   Just after the 'PKG_SKELL' entry add:
<verbatim>
   config PKG_STRACE
       bool "strace"
</verbatim>
   1. Edit dist/lfs/common/pkg_map. This is in build order.  Put your package where it should go in the
   build order, and add an entry that ties
   the config key, to the directory containing the spec file for the
   package.  For strace, I put this after gdb as shown:
<verbatim>
   PKG_GDB             =   gdb
   PKG_STRACE          =   strace
</verbatim>
   1. Commit your changes
<verbatim>
cvs commit -m "added new_package"
</verbatim>

---++ How to add a daemon to init
   1. Add the package that provides your service (see above)
   1. Write an init script.  This goes into the skell package.  The easiest thing is to copy and modify something that already exists (for instance dropbear). Your script should not have any numeric prefix.  For example etc/rc.d/init.d/named.
   1. Add an entry into config/userspace/sysconfig.lkc, for instance:
<verbatim>
   config SYSCFG_START_NAMED
       depends PKG_NAMED
       bool "start named (nameserver)"
       default y
</verbatim>
   1. Add entries in dist/lfs-5.1/sysconfig/sysconfig.spec to process this new service:
<verbatim>
   if [ "$SYSCFG_START_NAMED" = "y" ]
   then
       named=named
   fi
</verbatim>
   1. Add 'named' into the all_services= line in the position you want it to be run.
   1. Add 'named' into the all_services_r= line (this is the reverse of the previous line, for shutdown).
   1. Add '$named' into cfg_services and cfg_services_r.
d1201 6
a1368 1
-- Main.JohnFaith
@


1.1.1.7
log
@Import from fsl 20061124
@
text
@a111 1

a175 1
| patch     | any        | used by rpm |
d576 1
a576 1
             kernel (Linux 2.6.11+pq3 patches)  --->
d603 1
a603 1
./ltib -p kernel-2.6.11-pq3 -m prep
d608 1
a608 1
./ltib -p kernel-2.6.11-pq3 -m scbuild
d615 1
a615 1
./ltib -p kernel-2.6.11-pq3 -m scdeploy
d627 1
a627 1
./ltib -p kernel-2.6.11-pq3 -m patchmerge
d821 1
a821 1
   * click on the "Submit" button at the bottom of the page.
d1301 1
a1301 1
[[http://www.bitshrine.org/cgi-bin/gpp_upload.cgi][here]]
d1303 1
a1303 1
 11. Commit the updated specfile. If you have CVS write access:
a1306 2
 If you do not have CVS write access, please send a patch to the
 appropriate LTIB mailing list.
d1308 2
a1309 1
---++ How can I add a completely new package to the root filesystem
d1381 1
d1384 1
a1384 1
For external public files, use this link: 
a1392 3
If you do not have project membership and upload permissions, please
send and email to the mailing list explaining what you want to do.

a1400 2
If you do not have CVS write access, please send a patch to the LTIB
mailing list.
d1457 1
a1457 3
---++ Where do the sources get downloaded from (what is the LPP/GPP/PPP)

The primary system used is the GPP/LPP/PPP.
d1459 1
a1459 2
The PPP (Private Package Pool) is a privately accessed http server that
may optionally be used as a storage area for private sources/patches.
a1479 5
   * The builder tries to download the file from the PPP (if specified
   by the *%ppp_url* tag in *.ltibrc* to the LPP using *wget*.
   If that succeeds, a symlink is made from it to rpm/SOURCE and that link
   is used.  If the download does not succeed:

d1485 6
a1490 7
   * If all these final steps fail, the builder gives up and fails with
   an error.

*NOTE:* You may enter your proxy server information into the *.ltibrc*
resource file.  This may be needed if you are working within a 
company VPN environment and want to get at the external GPP on the
Internet.
d1591 1
a1591 1
$ cvs -z3 -d:pserver:anonymous@@__SERVER_SPEC__ co -d newname ltib
@


1.1.1.8
log
@Import from fsl 20071105
@
text
@d820 1
a820 1
      * topic = Linux BSP
@


1.1.1.9
log
@Import from fsl 20080404
@
text
@d177 1
d209 1
a209 1
   * Suse: 8.2, 9.1, 9.2, 10.0
d769 1
a769 1
<verbatim>/tftpserver</tftpserver></verbatim>.  This means that you need to copy your
d813 1
a813 1
   * go to http://www.freescale.com
a1613 8
---++ How to add device nodes
Device nodes with static major/minor numbers can be added to the file ltib/bin/device_table.txt.  The format is described in the file itself.

Since there is no dependency checking for device_table.txt, after adding a new entry, force rebuild devices to make sure the new /dev nodes are in the file system:
<verbatim>
$ ./ltib -p dev -f
</verbatim>

@


1.1.1.10
log
@Import from fsl 20081205
@
text
@a176 1
| patch     | any        | used by rpm |
a186 1
| glib2-devel | any?     | Needed if you want to build glib2 |
d205 4
a208 5
   * Redhat: 7.3, 8.0, 9.0, Enterprise release 4
   * Fedora Core: 1, 2, 3, 4, 5, 8
   * Debian: 3.1r0 (stable), unstable, 4.0
   * Suse: 8.2, 9.1, 9.2, 10.0, 10.2, 10.3
   * Ubuntu 6.10, 7.04, 7.10, 8.04
@


