STLinux Distribution version 2.0 Early access release

Please note that these instructions are now obsolete. With the release of the 2.0 distribution, Early Access Releases will no longer be supported. All details from this page which are also relevant to the 2.0 distribution have now been included in the manual.

Over the last few months, we have been working towards ST Linux Distribution version 2.0. This incorporates a large number of improvements, and will form the basis for all major work in the future. Currently these improvement include:

• Updated kernel: 2.6.11
• Support for the ST231 CPU, used on the STi5301.
• Updated toolchain: gcc 3.4.3, binutils 2.15.91.0.2 and glibc 2.3.2. This gives us support for the Native Posix Thread Library (NPTL).
• Some changes to the packageing structure and directory naming, to allow the 1.0, 2.0 and future distributions to co-exist on the same machine.
• Plus numerous other updated packages.

Note that support for the older ST40GX1 and ST40RA (ST40STB1) devices has been dropped from the 2.0 distribution. There is still code for them in the distribution, but they will no longer be officially supported.

Similarly we have updated the build host to RedHat Enterprise Linux version 3, and officially this is the only host we will support. My understanding is that all MCDT Linux products have moved or will be moving to this platform. In practice, we know Fedora Core 3 works, and probably other modern distributions, but support for other host distributions will be limited.

Early Access Release

To give internal developers access to these changes as soon as possible, we will be making available an Early Access Release (EAR). This will ensure that any problems get reported as soon as possible, and fixes can be provided without the overhead of a full release.

The Early Access Release (EAR) is a complete distribution, but instead of being provided as a CD image, it will only be available for download as individual RPMs. These RPMs will be updated individually as required. This means that the EAR will require a little more knowledge to install and configure than a full product release, and so we only recommend that you use it if you have some experience of using Linux.

Downloading the EAR

For more details on where to download the EAR from, please see the project's download page.

As the release is provided as large number of individual files, rather than a single archive, you may want to use the command line version of FTP rather than a GUI, as this supports the mget command. For example:

host% ftp linux.bri.st.com
Connected to linux.bri.st.com (164.129.14.212).
220 mo.bri.st.com FTP server (Version wu-2.6.1-16) ready.
Name (linux.bri.st.com:stuart): ftp
331 Guest login ok, send your complete e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /pub/stlinux/2.0ear/release2.0test3/RPMS/sh4
ftp> prompt
Interactive mode off.
ftp> mget *

Installing the EAR

Installing the EAR is a little different from installing a normal distribution. This is because there is no installation script, and so a little care has to be taken to ensure that packages are installed in the correct order. To some extent RPM handles this automatically, however our RPMS do not currently have full dependencies, so the user needs to make sure a few operations occur in the correct order.

First, if you have an earlier release of the EAR installed, we recommend that you delete it, and install the new release from scratch. The packages should upgrade correctly, but this isn't as well tested as a clean install.

N.B. Before you delete your installation, make sure that there are no files you want to backup first!

First delete the RPMs, and then make sure that the install area is left clear ready for the new installation:

host# rpm --erase --noscripts stlinux20-sh4-gzip
host# rpm --erase `rpm -qa | grep "^stlinux20-" `
host# rm -rf  /opt/STM/STLinux-2.0

Now the new packages can be installed, taking care of some of the interdependencies:

host# rpm -Uhv --ignorearch `/bin/ls *.rpm | sed -e /busybox-links/d`

Building the kernel

To reduce the amount of data which has to be downloaded, no pre-built or pre-configured kernels (called LSP's in the 1.0 distribution) will be provided as part of the EAR. As it is anticipated that most users will be experienced Linux developers, this shouldn't present a problem. However there are a few differences from the kernel source code supplied with the 1.0 distribution which you will need to be aware of.

Currently the compiler and architecture options are left at the default, (which will be appropriate for the host), and so need to be overridden from the command line. For example:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- vmlinux

A number of additional options are supported by the 2.6 kernel build system, for more details run:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- help

In particular V=1 is useful to debug build problems, and O=dir can be used to place object files in a different directory from the source, especially useful if you need to build multiple kernels with different options from the same source tree (note the first time you do this, you will need to copy usr/initramfs_list to $O/usr).

Typical configurations for all supported boards are provided as part of the kernel source code. One of these can be selected to initialise the current kernel configuration by running make with one of the boardname_defconfig targets printed by make help. So for example to generate a kernel for a st220eval, first run make help to find the name of the target:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- help
Cleaning targets:
  clean           - remove most generated files but keep the config
...
Architecture specific targets (sh):
  zImage                   - Compressed kernel image (arch/sh/boot/zImage)

  adx_defconfig            - Build for adx
  cqreek_defconfig         - Build for cqreek
...
  st220eval_defconfig      - Build for st220eval
...

which shows that the required target is st220eval_defconfig. So invoke make again, to set up the kernel configuration:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- st220eval_defconfig

If you want to see what the default configuration has set up, or to change any of the defaults, run make with one of the standard configuration targets, for example:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- menuconfig

Finally, to build the kernel:

host% make ARCH=sh CROSS_COMPILE=sh4-linux- vmlinux

SMC91C111

Many of the current target boards use an SMC91C111 Ethernet controller. This normally would have its Ethernet (MAC) address programmed into a E2PROM attached to the device. However, many of the boards we use have not have the MAC address set up, and thus the device driver will refuse to initialise the device.

To overcome this, a modification has been made to the Linux kernel, which allows the MAC address to be set up from the command line. When building the kernel, enable "Configure network hardware from the command line" (CONFIG_NWHW_CONFIG) in the "Device Drivers" -> "Networking support" menu.

This option has the form:

nwhwconf=device:dev,hwaddr:addr

where:

• dev is the device name, normally eth0.
• addr is the MAC address, which has the form: xx:xx:xx:xx:xx:xx.

For more information on chosing a suitable MAC address, please see the SMC91C111 page, although note that the option described on that page is specific to the 1.0 distribution.