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: /config/platform/tqm823l/deployment_instructions.txt.

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

What license is LTIB released under

Where can I get it from

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.

How do I install LTIB using CVS

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)

# mount <bspname.iso> /mnt/cdrom -o loop

Install into a target directory (as a normal user)

$ /mnt/cdrom/install

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:

$ cd <target_dir>/ltib
$ ./ltib

#ConfigurationSection

Configuration

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

./ltib on the very first run for a CVS instance

./ltib -m config configure only

./ltib --configure configure and build

Navigation

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

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

s : 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:

--- Choose the target C library type
C library type (glibc) --->

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.

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: /opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux/bin/arm-linux-gcc
the correct entry would be: /opt/mtwk/usr/local/gcc-3.4.3-glibc-2.3.4/arm-linux

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 powerpc-linux-

CFLAGS : Normally this can be left blank

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

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

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:

Load an Alternate Configuration File

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
config/platform// directory.

Common Package selection screen

--- Package selection
Package list --->

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:

Common Target System Configuration screen

--- Target System Configuration
Options --->

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:

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.

() load these modules at boot

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

[*] start networking
Network setup --->

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:

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:

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

config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config

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

config/platform/mpc8548cds/linux_2.6.11_mpc8548_cds_def.config.dev

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: [ ] Configure the kernel

run:

./ltib -p kernel-2.6.11-pq3 -m prep

build:

./ltib -p kernel-2.6.11-pq3 -m scbuild

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. 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)

./ltib -p kernel-2.6.11-pq3 -m scdeploy

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.

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:

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:
config/platform/tqm823l/deployment_instructions.txt

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

ln -s ~/ltib/rootfs /tftpboot/192.168.0.254

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

Export this directory by editing /etc/exports, add the entry:

/home/<uid>/ltib/rootfs *(rw,no_root_squash)

*NOTE*: this example has all security for this directory turned off!
Any host may access this exported directory.
See man exports for more information

Re-start NFS:

sh /etc/rc.d/init.d/nfs restart

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.

$ ls /usr/sbin/in.tftpd
/usr/sbin/in.tftpd

2 Check to see if inetd is setup to run the tftp server by running the
command below, your output should be similar:

$ netstat -a | grep tftp
udp 0 0 *:tftp *:*

It there is no output, make sure that it's not disabled in
/etc/xinetd.d/tftp. In my copy I note the following
line:

disable = no

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
/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:

$ cp rootfs/boot/uImage /tftpboot

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:

Command line options explained

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

$ ./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

Without any arguments

Running ./ltib 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 rootfs if you have
NFS mounted this directory on your target
(e.g. /var/log/xx

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:

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

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

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

--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
host_config.log

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

--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, pkg 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 rpm/BUILD/xxx

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

bin/listpkgs config/platform/mpc8548cds/defconfig

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:

./ltib -m listpkgs

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

How do I change package selection/configuration and immediately build

How do I change package select/configuration without building

How do I build/install just a single package?

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:

./ltib -m prep -p <package>

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

3. Build the package with your changes:

./ltib -m scbuild -p <package>

4. Once the package builds successfully, check the install phase:

./ltib -m scinstall -p <package>

5. Test your package before committing the changes:

./ltib -m scdeploy -p <package>

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

7. Generate a patch and update the spec file:

./ltib -m patchmerge -p <package>

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

9. Build from scratch and install

./ltib -p <package>

10. Once you're happy with all your changes, upload the patch to the GPP
here

11. Commit the updated specfile. If you have CVS write access:

cvs commit dist/lfs-5.1/<pkg>/<pkg>.spec

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:

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.

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'

Edit config/userspace/packages.lkc, this is in alphabetic order.
Just after the 'PKG_SKELL' entry add:

config PKG_STRACE
bool "strace"

Edit config/userspace/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:

PKG_GDB = gdb
PKG_STRACE = strace

Commit your changes

cvs commit -m "added new_package"

How to add a daemon to init

Add the package that provides your service (see above)

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.

Add entries in dist/lfs-5.1/sysconfig/sysconfig.spec to process this new service:

if [ "$SYSCFG_START_NAMED" = "y" ]
then
named=named
fi

Add 'named' into the all_services= line in the position you want it to be run.

Add 'named' into the all_services_r= line (this is the reverse of the previous line, for shutdown).

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:

$ ./ltib --preconfig config/platform/tqm823l/defconfig --batch

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

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

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 t)

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: