TOC PREV NEXT INDEX

LynxOS User's Guide


Creating Kernel Downloadable Images (KDIs)

LynxOS supports creating Kernel Downloadable Images (KDIs) with the mkimage utility. KDIs combine the LynxOS kernel and its associated applications into bootable images designed for easy downloading onto development targets.

Overview

Users can create application-ready embedded systems that include the LynxOS kernel and customized application into bootable images, which can then be implemented in one of the following ways:

A LynxOS kernel image is a special boot file that always contains LynxOS, but may also contain a RAM-based file system (called a RAM disk) with minimal files for operating system functions and applications.

mkimage - the LynxOS KDI Creation Utility

The mkimage utility creates a single file - a bootable kernel downloadable image (KDI) - with some or all of the following LynxOS components:

The mkimage utility creates the image with attributes that users set in a specification file. By defining the fields in the specification file, users can create customized images for their specific development targets. For more information on specification files, see "Creating a Specification File".

Note: See the mkimage.spec man page for an explanation of specification files.

The mkimage Syntax and Features

The syntax for mkimage is as follows:

# mkimage spec_file output_file

Note: Additional options are available in the mkimage man page.

LynxOS Kernel

Users can specify that mkimage should use the current LynxOS kernel in /lynx.os when building the KDI. However, users are most likely to create a custom kernel for use in their specific image. For example, users may choose to remove any unused device drivers from the kernel to reduce the size of the kernel, and as a result, of the final image.

(See Chapter 7, "Customizing the Default LynxOS Kernel Configuration" for more information on creating custom kernels.)

To save space, mkimage does not expand the bss section of the kernel in the image. The bss section is expanded and initialized to zeros by kernel code. The starting execution address is always 32 (0x20) bytes after the start of the image in memory.

Embedded File Systems

Embedded file system images can be one of two types:

Embedded Root File Systems

Embedded root file systems can be one of the following three types:

The mkimage utility may be used to create a memory-based root file system. LynxOS accesses this file system using its RAM disk driver. The memory-based file system may physically reside in RAM, ROM or flash memory, depending on how the image is used and created for the target machine. Depending on the set of utilities put into the image, the image may function as a minimal application target or as a complete LynxOS development system.

If the major and minor numbers of a disk drive attached to a target system are specified, that drive may be used as the root file system for the kernel downloadable image (KDI). A disk-based root file system behaves identically to a kernel root file system booted from disk.

For kernels appropriately generated, the image does not contain or reference a file system.

Embedded Stand-Alone File System Images

An embedded standalone file system image is memory-based and may be accessed through the LynxOS RAM disk driver. The file system image may reside in any type of physical memory but is most likely to be in ROM or flash memory. No provision for moving the embedded file system image to RAM is provided by the LynxOS kernel. Application text segments may or may not be resident as required (see "Resident Text Segments" below).

Resident Text Segments

Applications may have resident (execute in place - XIP) text images in an embedded memory-based file system. In a normal file system, the text segment of an application is copied from the file system to RAM for execution. In a memory-based file system, the text segment is copied from the memory-resident file system to memory. Resident text applications do not require this copying process, which in turn, reduces run-time RAM memory requirements. The considerations that should be taken into account when deciding to use resident text are as follows:

When the execution speed of the application is most important, the text of the image should reside in RAM, because, in general, any type of ROM is slower than RAM. There are several ways to accomplish this, depending on how the KDI or File System Image (FSI) is specified, and the type of memory the image resides in.

When the application is in the root FSI, and the KDI is in RAM, resident text should be used to ensure optimal execution speed and RAM conservation.

When the application is in the root FSI and the KDI is in some sort of ROM, the text may or may not need to be resident. When the text is specified as resident and text=ram is also specified, the resident text of the application (and all other resident text applications) is copied to RAM by the kernel during kernel initialization. When the text is not specified resident, the kernel loads the applications text to RAM from the file system at execution, identically to the application text residing on a disk drive. Since there is no provision to move resident text segments to RAM in a standalone FSI, a non-resident text segment is the only way to have the application run out of RAM from a standalone FSI residing in some sort of ROM.

When the root or standalone FSI resides in ROM and execution speed is a priority, leaving the application text segments in the non-resident files system conserves the greatest amount of memory. This causes the kernel to load the text segments on demand into RAM from the FSI. Alternately, when the root FSI resides in RAM, using resident text for applications conserves the greatest amount of memory.

Creating a KDI Image

Procedure Overview

The same basic steps are used to create images for the entire range of boot applications, for network booting to ROM booting:

For information on network booting the image, please read "Network Booting Diskless Clients with LynxOS" in the LynxOS Networking Guide.

The following steps detail creating a Kernel Downloadable Image (KDI). These steps are also explained in the subsections that follow:

  1. Create a copy of /sys/lynx.os by entering the following commands:

$ cp -r /sys/lynx.os /tmp/test.os
$ cd /tmp/test.os
  1. Enable the RAM disk driver in CONFIG.TBL.

  2. Make any other modifications to files such as uparam.h and Makefile.

  3. Create a new kernel with make a.out.

  4. Create a specification file with desired attributes.

  5. Run mkimage.

For information on creating a remotely bootable kernel (including sample scripts), see "Network Booting Diskless Clients with LynxOS" in the LynxOS Networking Guide.

Note: When developing application on a LynxOS cross development host, it is necessary to use $ENV_PREFIX/pathname where absolute paths are shown in this chapter.

Enabling the RAM Disk Driver

To enable the RAM disk driver, users must uncomment (by removing the # sign) the line I:ramdisk.cfg in the CONFIG.TBL file.

Modifying Kernel Parameters

One way to reduce the size of a kernel is to remove all superfluous drivers; see Chapter 7, "Customizing the Default LynxOS Kernel Configuration" for examples.

Creating a Specification File

The example specification file in the mkimage.spec man page can be used as a template for creating a specification file.

Some important attributes of mkimage.spec are as follows:

mkimage.spec Attributes  
Attribute
Description
target=target=[x86|ppc]
The target system
osstrip=[local|all|none]
Causes local symbol definitions to be stripped from the kernel text file.
ostext=[ram|rom]
Designates where the kernel resides in the running system.
kernel=path
The path of the LynxOS kernel to be used in the image; This can be /lynx.os, but most likely is a customized kernel that the user has built elsewhere on the system.
nodetab=path
The device node table corresponding to the kernel
flags=
Designates the boot flags.
free=
Designates the number of free blocks.
inodes=
Designates the number of free inodes.
root=[ram|rom]
Specifies that the root file system is either resident in RAM, ROM, mounted from the device, or that there is no file system.
strip=[true|false]
Designates whether or not the application files are to have symbols stripped.
text=[ram|rom]
Designates that the resident application programs will be in ROM, or moved to RAM.
resident=[true|false]
Designates whether or not the application programs are to be resident in memory.
directory=
A directory on the target file system
file=
A file on the target file system
source=
Designates a fully qualified path name to a source file to be copied into the target file system as the file specified in the file=.
owner=
Designates the numeric owner ID of the target file.
group=
Designates the numeric group ID of the target file.
mode=
Designates the file mode for the target filesymlink.
symlink
Designates a symbolic link of pathname1 to pathname2.

Testing Kernel Images

Users can use the LynxOS preboot utility to directly test the kernel images made with mkimage (see the preboot man page for the specific commands used on different platforms). For example, to test the kernel image /tmp/test/images/image1 created on a LynxOS x86 machine, perform the following steps:

  1. Reboot the machine by entering the following command:

$ reboot -a
  1. At the preboot prompt (Command?), enter the following command:

Command? b /tmp/test/images/image1

Booting KDIs

The following sections provide details on:

Booting Images over a Network

To network boot LynxOS (also called to netboot), the image file is stored on a remote server and copied over the network into the RAM of a remote node by the firmwareresident TFTP boot code. Generally, the node is diskless.

Because everything is in RAM, the boot code gives control to the loaded operating system, which in turn, configures the attached RAM disk as its root file system. In this case, because all the executables are in RAM, it is useful if they are executed directly without being copied again into RAM. Thus, the TEXT segments of the executables are loaded as part of system initialization at boot time, rather than on demand from the root file system.

In the remote boot configuration, the RAM memory map is sequential, as shown in the figure below:

INT Vectors
OS TEXT Segment
OS DATA Segment
OS bss Segment
OS Symbols
RAM Disk File System
Application TEXT Segments

Example RAM Memory Map

Booting Images from ROM

The firmwareresident ROM boot code always passes control to the ROM-based kernels. At this point, depending on the options defined in the specification file, all or portions of the image are moved to RAM. LynxOS always moves the DATA and bss sections to RAM.

LynxOS sets up the memory map such that some portions are mapped into ROM and other portions are mapped into RAM. This is required in order to fully utilize the contents of ROM, without copying them into RAM. The previous figure shows an example of this mapping scheme. The LynxOS kernel text segments, root file system, and resident text segments are all in ROM, as shown in the figure below.

Example Memory Map Configuration

As shown in the figure above, the first pages, containing the interrupt and exception vectors, are mapped into RAM. The next few pages are mapped into ROM for the OS TEXT section. The following few pages are mapped into RAM for the OS DATA section (copied from ROM), for the OS bss section (initialized in RAM), and for OS symbols (copied from ROM). The root file system and resident TEXT segments are mapped to ROM.

If the root file system is readonly and the application needs a writable file system, the image must contain a script to create a writable RAM disk. The script should invoke the mkramdisk utility to create the writable RAM disk after the system is up and running.

See also the section "Creating Bootable Installation Media".

KDI Build Templates

To simplify the KDI development process, LynuxWorks provides a KDI build template directory, and a tar file (xx.kdi.tar.gz) of the KDI build template, on the ODE CD-ROM. The build template and the tar.gz files are located in the kdi and tar_images directories, respectively.

The kdi directory allows users to easily build their own KDIs for execution on target hardware. A KDI build template essentially consists of all the binary and source files required to develop a custom application for the user's target system using LynxOS.

Note: The KDI build templates and the tar.gz files are not automatically installed as a part of the default installation; for information on installing KDI build templates and the tar.gz files, see the LynxOS Installation Guide.

The /demo/demo.bsp_name and tar_images/xx.demo_bsp_name.tar.gz directories have prebuilt versions of these KDIs, which can be loaded onto a user's system for evaluation and demonstration.

The sections that follow demonstrate how to set up a KDI project area, build a KDI, and download and execute it on a target. Because the project scripts are written in Bourne Shell, these build steps can be followed on any cross development or native development system.

Template Conceptual Overview

LynuxWorks provides KDI directories to give users a set of templates from which they can jump-start their own development of KDIs. The scripts automate the process of creating a project directory, copying a kernel build directory, installing the appropriate device drivers, building the kernel, selecting the appropriate files from the LynxOS distribution, and generating a KDI.

Included KDI Build Templates

The following table describes the KDIs that are provided with LynxOS.

Build Template
Summary
developer
Contains development and networking utilities that provide a minimal configuration for development. Includes the following utilities:
· disk--Disk formatting and partitioning utilities
· gnutar--gnutar and gnuzip utilities
· shell--Minimal shell configuration
· vm--Virtual memory
· skdb--Simple kernel debugger
· totaldb--TotalDB kernel debugger
· dhcp--DHCP protocol support (not enabled by default)
· rcp--RCP (remote copy) utility
· ftp--FTP (file transfer protocol) utility
· tcpdump--Displays TCP information
· tview--TotalView
· apache--Apache web server
· nfsmount--NFS mount utility

The developer demo can be used with host system IDEs VisualLynux and CodeWarrior. The Developer KDI is documented in the section "Example--Building, Booting, and Using the developer KDI".
hello
Simple configuration demonstrating a full kernel, RAM/ROM file system and a small hello_world.cpp application

Since this is a minimal KDI, users must power down the system to end the demo.
install
This KDI contains basic networking and disk utilities that can be loaded onto a target board with FTP.

install.kdi performs these steps:

  1. Determines what disk you have
  2. Partitions the disk using mkpart.
  3. Prepares a file system on the disk (if needed) and mounts it. Starts disk swapping        (if needed).
  4. Uses FTP to retrieve tar images.
  5. Extracts tar images.
  5. Makes device nodes and sets up networking.
rlogin
This KDI creates a simple TCP/IP configuration, demonstrating the use of rlogin.

On the target board, boot the KDI and log in as root. Use rlogin to log into a system on the network. Use either the hostname (if available in /etc/hosts) or IP address:

     rlogin <hostname | ip_address>

From another system, rlogin to the target.
rootfs
This KDI provides a basic root file system for a target board. This KDI does not contain a RAM disk file system, but boots directly from the hard disk instead. The KDI defaults to mount /dev/ide.2a. If the file system requires a different device, the KDI must be rebuilt to use that device.
tkwish
This KDI demonstrates the use of the WISH shell to create an X Windows-based user interface to the target board. A simple interactive window is displayed to let the user browse several files on the file system.

Use the following instructions to set up tkwish:
1. On the target board, set the DISPLAY variable to point to the X server. If there is an entry in the /etc/hosts file for the X server machine, use the hostname of the system. Otherwise, use the IP address:
     DISPLAY=<hostname | ip_address>:0.0
     export DISPLAY
2. On the X server, enable remote clients:
     xhost +
3. On the target board system, type demo.tkwish.
4. On the X server use the mouse to point and click.
tutorial
This KDI provides an interactive demonstration of processes and threads for LynxOS. Type q to quit the demo.

kdi Directory Structure

The kdi directory includes the following files and directories:

KDI Directory Structure  
KDI Directory/File
Description
[0-9]*
These are KDI build directories.
Makefile
This is the top-level Makefile.
PROJECT.sh
This Bourne Shell script sets up a custom KDI build environment.
README
This file describes contents of the kdi directory.
common
This directory contains shared source code, binaries and scripts.
bsp
This directory contains single port files for target hardware boards.

KDI Build Directories

Additionally, there is a distinct ordering of the KDI build subdirectories. LynuxWorks uses the naming scheme xy.name, according to functionality and complexity. x, y, and name are defined as follows:

KDI Naming Convention
Convention
Description
x =0
KDIs that assist in installing LynxOS on the target
x =1
Simple KDIs that do not require networking (TCP/IP)
x =2
KDIs requiring TCP/IP
x =3
KDIs that use NFS, PPP, SNMP or other networking protocols
x =4-9
Special purpose KDIs
y =0-9, a-z, A-Z
Range of 62 possible unique identifiers
name
Any string summarizing the capability of the KDI

Restrictions

This demonstration harness assumes that a single user is building the KDI. It also assumes that the building of demo KDIs is done one at a time, since all demo KDIs share the same BSP directory where kernels are built; therefore, two KDI directories cannot be built in parallel.

Getting Started

A shell script, PROJECT.sh, is provided to automate the setup process. Before running this script, users must have already installed LynxOS from the distribution CD-ROMs onto the system's hard disk, or have mounted it from a CD-ROM; and have sourced the SETUP.bash or SETUP.csh scripts provided.

These scripts set up the PATH environment variable, and also set ENV_PREFIX to point to the distribution directory. ENV_PREFIX must be set correctly for PROJECT.sh to work.

To set up ENV_PREFIX, source the SETUP.bash or SETUP.csh scripts provided in the LynxOS release directory. To verify that ENV_PREFIX is set correctly, enter the following command, which lists the LynxOS distribution:

$ ls $ENV_PREFIX

If ENV_PREFIX is set correctly, then execute the PROJECT.sh script by entering the following command:

$ ENV_PREFIX/kdi/PROJECT.sh

The following screen output is displayed:

=======================================================
| Project set up script                                |
|                                                      |
| This script will create a customized directory for   |
| building and experimenting with Kernel Downloadable  |
| Images (KDIs.)                                       |
=======================================================
Note: 10MB of available disk space is needed for minimal project directory. 30MB is recommended.
Project directory location? [/tmp/newproj]

Enter a location on disk where the user has write permission (/tmp/newproj is the default) with at least 10 MB of free space available (30 MB is recommended). The following output is displayed:

The following BSPs are supported:
     PPC [pc_drm,pp_drm,cpci_drm,
vmpc,mpc860t_fads,mpc8260_vads,pmc860]
     x86 [x86_at,x86_drm,cpci_x86]
Which BSP should we use? [xxx]
Note: The default selection displayed is $ENV_PREFIX/sys.
Enter target network name and IP address now? [y]

If a machine name and an IP address for the target board has been selected, enter y. The PROJECT.sh script goes through the process of modifying the rc.network file for the specified target. If n is entered, then the rc.network file that gets configured into the system's KDIs interactively prompts the user for the machine name and IP address at boot-time as follows:

What is the network name of the target board? [lynxdemo]
Enter the target machine name:
What is IP address name of the target board? [1.1.1.1]
Enter your target IP address.

Once all questions have been answered, PROJECT.sh proceeds to set up the customized KDI build environment, copying the appropriate files.

Building KDIs

To begin building KDI demos, change the working directory to /tmp/newproj/11.hello, and issue a make all command; the following steps are executed:

#########
# Step 1a. Modify CONFIG.TBL
#########

This step creates a local copy of CONFIG.TBL, which is used by the kernel Makefile to configure device drivers as either in or out. This CONFIG.TBL file is copied to the local Board Support Package (BSP) directory (where the kernel is linked) each time the user issues a make command in this /tmp/newproj/ll.hello directory.

#########
# Step 1b. Modify uparam.h
#########

This step creates a local copy of the uparam.h header file. This file is used to specify the size of user-modifiable kernel data structures and resources.

Like CONFIG.TBL, the uparam.h file is copied to the local BSP build directory each time a make command is issued in the /tmp/newproj/ll.hello directory.

#########
# Step 2: Perform any local build actions defined in desc.bsp_name.sh
#########

This is a hook that allows a KDI build directory to do any special local processing. Look at the desc.* file for details.

#########
# Step 3: Make kernel
#########

This step changes directory to the ./bsp.* directory, and makes the kernel, using the CONFIG.TBL and uparam.h files from the KDI build directory.

#########
# Step 4: Build KDI
#########

This step is run from within the KDI build directory. The mkimage tool is invoked using the KDI mkimage specification file to pull together the appropriate kernel components and applications.

#########
# Step 5: Build Complete
#########

Look at hello.kdi in /tmp/newproj. An output similar to the following is displayed:

-rwxr-xr-x 1 int 774144 May 11 19:38 /tmp/newproj/hello.kdi

The KDI can now be downloaded and executed on the target. For more information on demo KDIs and loading KDI images onto the target, see the appropriate LynxOS Board Support Guide.

Example--Building, Booting, and Using the developer KDI

The Developer KDI includes development and networking components that provide a development environment on a target board. This section describes how to create, boot, and user the Developer KDI. This example uses the following configurations:

Parameter
Host
Target
Platform
Red Hat Linux 7.2
LynxOS 4.0 Cross Development
pc_680
Force PowerCore 680
Hostname
linuxcdk
fpc1
IP Address
192.1.1.1
192.1.1.2
Ethernet Address
Not needed.
08:00:3E:23:8C:BD

Configuring the Developer KDI

The default configuration of the Developer KDI contains many utilities that provides a wide range of functionality for a variety of development tasks. The default configuration of the Developer KDI can change by editing the developer.spec file to add or remove functionality in the KDI.

Removing Unnecessary Components

The size of the Developer KDI demo may be too large for some systems. The default configuration is close to 10 MB. Unnecessary components can be removed from the default KDI image by commenting out the lines in developer.spec and rebuilding the kernel.

Enabling Required Components

Several components are not included in the default KDI. To enable the following components, uncomment the required lines in the developer.spec file:

Check the developer.spec file and uncomment any files that are required by these utilities to enable them in the Developer KDI.

Rebuilding the KDI

After editing the developer.spec file, rebuild the kernel.

# make all

Configuring the Linux Cross Development Host

TFTP is required by the target to load the developer.kdi. Use the following instructions to enable tftp on the host system:

  1. Edit /etc/ethers to include the Ethernet address of the Target board:

# vi /etc/ethers

/etc/ethers File
08:00:3E:23:8C:BD     fpc1

  1. Edit the /etc/hosts file to include the hostname and IP address of the target board:

# vi /etc/hosts

/etc/hosts File
192.168.1.2      fpc1

  1. Create the tftpboot directory:

# mkdir /tftpboot
  1. Enable TFTP by editing the tftp file

# cd /etc/xinetd.d/
# vi tftp
  1. In the disable field, type "no" to enable tftp.

  2. In the server_args field type "/tftpboot". The following provides a sample tftp file.

    Sample TFTP Configuration File
    # default: off
    # description: The tftp server serves files using the trivial file transfer \
    # protocol. The tftp protocol is often used to boot diskless \
    # workstations, download configuration files to network-aware printers, \
    # and to start the installation process for some operating systems.
    service tftp
    {
    socket_type = dgram
    protocol = udp
    wait = yes
    user = root
    server = /usr/sbin/in.tftpd
    server_args = /tftpboot
    disable = no
    }

  3. Restart the xinetd services:

# cd /etc/rc.d/init.d
# ./xinetd restart

Booting the KDI

At the PowerBoot> prompt, type in the following command to netboot the KDI:

PowerBoot> netload developer.kdi 400000 <hostIP> <targetIP>

For this example, type the following:

PowerBoot> netload developer.kdi 400000 192.168.1.1 192.168.1.2

Note: Note that if the Developer KDI will not load, it may be too large to boot. Removing components in the Developer KDI demo will allow it to boot.

Using the KDI

The Developer KDI can be used in a variety of ways. With the Apache component enabled in the developer KDI, a browser can open an http connection to the target. For example:

Apache Web Server Running on Target

This HTTP demonstration provides an example of the different types of development that can be done on the target.

Default Usernames and Passwords

The Developer KDI includes user accounts used to access the target board. LynuxWorks IDEs VisualLynux and CodeWarrior can connect to the target board and perform various development tasks. The following table provides the user name and passwords for these utilities:

Default Username and Passwords in the Developer KDI  
Component
Username
Password
FTP
ftp
ftp_user
VisualLynux
vl
vl_user
CodeWarrior
cw
cw_user
TotalView
tv
tv_user

ROMing Issues

The tools and steps used to burn an image into a PROM are specific to the target hardware. Depending on the PROM burner and target hardware, users may be able to burn the image file as is (with no conversion to an intermediary file format) into a PROM. Refer to the specific hardware documentation for more information.

The GNU objcopy utility may be used to convert the image to the file format required by the user; see the objcopy man page for further information.

Generating PROM Images on x86 Systems

Building the Jump Code

BIOS limitations on the x86 architecture require that a small object module, rkjump, be used to boot up and load a LynxOS kernel from ROM. It must be available within the address range 640 KB to 1 MB at system power up. On most BIOS types, rkjump must reside in the address range 0xC0000 to 0xDFD00 on a 0x200 byte boundary.

After taking control from the system BIOS, the rkjump module initializes the Segment Descriptor Registers, sets the CPU to protected mode, and transfers control to the ROM segment containing the LynxOS image.

rkjump is very specific to the memory architecture and must be tuned to the specific target's needs. The sources and build environment for rkjump are in /src/bin/rkjump386. Before building the rkjump module, users must define the kernel image ROM address in the rkconfig.h file in the /src/bin/rkjump386 directory.

For example, if the kernel image has been created with a load address of 0x00100000, users must specify an address of + 0x20 in /src/bin/rkjump/rkconfig.h. The rkjump module then needs to be rebuilt by entering the following commands:

$ cd /src/bin/rkjump386
$ vi rkconfig.h

Change the value of RKJUMP_ADDRESS as follows:

# define RKJUMP_ADDRESS 0x00100020

Exit the vi text editor, and enter the following commands:

$ touch rkjump.c
$ make all

Converting the Jump Code

After building the customized rkjump for the image being created, use the GNU objcopy utility to prepare the file for transfer to ROM.

Converting the Kernel Image

Convert the kernel image created with mkimage into hex format using the GNU objcopy utility.

Creating Bootable Installation Media

LynxOS facilitates creating bootable installation floppy disks for x86 platforms, and bootable CD-ROMs for x86 and PowerPC platforms; "Creating a Bootable x86 Floppy" and "Creating a Bootable x86 or PowerPC CD-ROM" below detail this, respectively.

Creating a Bootable x86 Floppy

LynxOS users can create bootable LynxOS installation floppies for x86 systems on formatted 1.44 MB disks (for more information on formatting floppies, see "Formatting Floppy Disks" and the fmtflop man page).

To create a bootable LynxOS installation floppy disk, perform the following steps:

  1. Place a formatted 1.44 MB floppy disk in the x86 system's floppy drive.

  2. Run the build script by entering the following command line:

$ /sys/romkit/installation/Build
  1. Follow the on-screen instructions.

The /sys/romkit/installation/Build script assumes that no file systems are mounted on the /mnt directory. Users need be sure that /mnt is available for use before using the script. If a file system is mounted on /mnt, the following command unmounts it:
$ umount /mnt

For more information on mounted file systems, see the mount man page.

Creating a Bootable x86 or PowerPC CD-ROM

LynxOS users can create a bootable LynxOS installation CD-ROM for either x86 or PowerPC systems.

To create a LynxOS installation CD-ROM for either x86 or PowerPC platforms, perform the following steps as root:

Creating CD-ROM Image on Host

  1. Create a directory on a file system partition that has enough free disk space to unload all of the desired tar.gz image files by entering the following command:

$ mkdir -r /media/tar_images
where media is the desired name for the bootable CD-ROM.
  1. Change directory to the newly created directory:

$ cd /media/tar_images
  1. Locate the desired tar.gz image files (originally in the /tar_images directory on the ODE CD-ROM). The following are the required tar.gz image files:

xxxxx.devos.tar.gz
xxxxx.bsp_bsp_name.tar.gz

bsp_name is the type of Board Support Package (BSP) and xxxxx is the LynuxWorks naming scheme for the KDI build subdirectories. (See "KDI Build Directories".)
  1. Copy the desired tar.gz image files into the /media/tar_images directory:

$ cp xxxxx.devos.tar.gz
xxxxx.bsp_bsp_name.tar.gz /media/tar_images
  1. Extract the tar.gz image files into the /media directory by entering the following tar commands:

$ tar zxpf tar_images/xxxxx.devos.tar.gz
$ tar zxpf tar_images/xxxxx.bsp_bsp_name.tar.gz
In the /media/sys directory, create a symbolic link from bsp.bsp_name to lynx.os:
$ cd /media/sys
$ ln -s bsp.bsp_name lynx.os
  1. Copy the nodetab file from /media/sys/lynx.os to /media/etc:

$ cp lynx.os/nodetab ../etc
  1. Change the working directory to /media/dev and create device nodes in /media/dev with the following command:

$ cd /media/dev
$ mknod -a ../etc/nodetab
  1. Change the working directory back to /media and copy the kernel file located in /media/sys/lynx.os/a.out to /media/lynxos:

$ cd /media
$ cp sys/lynx.os/a.out lynx.os

Creating the CD-ROM

  1. Ensure that the CD-ROM is read as bootable by entering the following command (where platform is one of either x86 or ppc):

$ touch tar_images/
.this_is_a_bootable_platform_CD
  1. Create the ISO formatted image using the mkisofs command (see the mkisofs man page for further information):

$ mkisofs -R -b preboot ../iso_image .
  1. Change the working directory up one level:

$ cd ..
  1. Use the makeboot utility to configure the iso_image file:

$ makeboot -r major,minor -b device
-flag autoboot_CD -timeout secs iso_image

Note: makeboot must be run on the platform from which iso_image is to be booted (see the makeboot man page for more information).

  1. Use the cdwrite utility to write the bootable iso_image to a recordable CD-ROM (see the cdwrite man page for further information) by entering the following command:

$ cdwrite -i iso_image -r -v -s speed cdr_device

Note: The command -s speed sets the speed factor used for writing the
CD-ROM.The default speed is 1. This means a data transfer rate of 150 KB per second. It takes 74 minutes to fill a 650 MB CD-ROM at speed factor 1.

The approximate times to write lead-in and lead-out tracks are as follows:

  • -s 1 4 minutes

  • -s 2 2 minutes

  • -s 4 1 minute



LynuxWorks, Inc.
855 Branham Lane East
San Jose, CA 95138
http://www.lynuxworks.com
1.800.255.5969
TOC PREV NEXT INDEX