STLinux

How to install and use Linux support packages (LSP)

Linux kernel and application programs may be supplied in the form of RPMs, SRPMs or LSPs. The distribution includes the kernel sources in several forms, and it is not always clear what should be installed and where it will end up. This section explains what these packages are, and what they are used for.

RPMs and SRPMs

An RPM contains everything necessary to install a package. This generally includes:

• the binary code for the program

• a .spec file, which describes how the package should be installed (including any dependencies on other packages)

An SRPM contains everything necessary to build a package. This generally includes:

• an RPM, as above

• a single archive file, usually a .tar file, exactly as provided by the original vendor

• any patches which need to be applied to the source code for any reason (to fix bugs, upgrade to a later version, add a new feature and so on); the most common patches provided add support for a new CPU, or for cross compilation

• a .spec file, which describes how the package should be built and installed (including any dependencies on other packages)

A feature of the RPM system is that it allows a single file to contain all the information needed to build the program, preserved in its original form, so it is plain to see where the source code has been modified and by whom.

All processing of RPMs and SRPMs is performed by the rpm command. The common use of rpm is to install RPMs, but it is also a miniature build system. In this mode, rpm can take source code, either from individual files or from an SRPM, perform all the necessary steps to build and install the program, and then generate both an RPM containing the built program, and an SRPM containing all the sources used.

When an SRPM is installed, rpm will simply unpack the RPM, and place all the individual files into the specified SOURCE and SPECS directories. The location of these directories depends on the distribution (for example in Red Hat, it is /usr/src/redhat).

Kernel sources

It is not usually necessary to rebuild the supplied programs from source. The main exception to this is the Linux kernel, which is expected to be rebuilt frequently when developing ST Linux. This could be supplied as an SRPM, but the kernel tends to be heavily patched and rebuilding from the SRPM can be daunting.

To avoid this problem, the kernel is normally supplied as an RPM which also contains source code. This is the generic kernel source, which can be configured and built for any supported system. This should probably be the starting point when porting the kernel to a new target board.

Linux support packages (LSPs)

To further simplify the kernel build process, kernels are also supplied as Linux Support Packages. These are pre-configured kernels for a particular target board, and may contain additional documentation or tools which are only useful on this target board. In addition, the LSP process supports patching a kernel for a particular board, although this is normally unnecessary.

LSPs are supplied in two forms.

• The cross LSP, which contains the sources for a pre-configured kernel for a particular board. This can be built by entering the commands make dep; make.

• The target LSP, which contains a pre-built version of the kernel for a particular board. This can be downloaded directly onto the target, and executed immediately.

The cross LSP and the generic kernel RPMs are almost identical, except that the LSP will have already been pre-configured for the appropriate board.

As each stage of the build (from generic kernel source, to cross LSP, to target LSP) builds on the sources from the previous build, the SRPMs for each of the LSPs will be very small as they only contain the additional files. Typically, this will just be the documentation, configuration and .spec files for the cross LSP; the target LSP is usually just the .spec file.

Summary

Kernel version numbers

Another area which has caused some confusion is kernel and LSP version numbers. These have an additional version number compared to normal RPMs. For example:

stm-host-kernel-2.4.17_st1.0-4.src.rpm

Here there are several version numbers. These are explained in the following table.