Building and Customizing A Wind River Linux Platform Lab
Building and Customizing A Wind River Linux Platform Lab
Building and Customizing A Wind River Linux Platform Lab
mkdir -p $HOME/myplatform
cd $HOME/myplatform
2. To establish the build environment for building the platform, you must invoke the
Wind River Linux configure script. This script is located within the Wind River
Linux product installation. Using syntax similar to GNU autoconf, configure
supports a number of command-line arguments for selecting a BSP, kernel type, and
file system profile, as well as many other settings. Commonly used options are
summarized in the table below:
Option Name Purpose
--help Display an extensive list of supported options.
--enable-board Specify the target BSP.
--enable-kernel Select the type of Wind River Linux kernel to use.
Select the type of Wind River Linux user space to
--enable-rootfs
use.
--enable-build Select how software should be built.
--with-layer Include an additional layer.
--with-template Include an additional template.
Enable the compiler cache (ccache) to speed up
--enable-ccache
build time.
--with-ccache-dir Specify an external compiler cache directory.
Bitbake shared state cache directory. Using a shared
--with-sstate-dir
state cache significantly improves build times.
View the complete list of options available:
$WIND_BASE/wrlinux/configure --help
3. In this example, you will create a platform similar to the one shipped with the lab
environment. Doing so will significantly reduce build time since the shared state
cache found at /Labs/sstate can be used to accelerate the build.
$WIND_BASE/wrlinux/configure --enable-board=$BSP \
--enable-kernel=$KERNEL \
--enable-rootfs=$ROOTFS \
--with-sstate-dir=/Labs/sstate
The output of configure will stream by. Once configure finishes, your directory will
contain the infrastructure needed to build and deploy your own customized Linux
distribution. Take the time to familiarize yourself with the build environment. There
are a few important directories to note:
The build directory hosts soft links to the build directories for each package. This
subdirectory also hosts a Makefile used to build special targets associated with
the packages. For more details, execute the following command:
make
5. After the build finishes, explore the contents of the export directory. In particular,
take note of export/dist, which contains a complete copy of your target file system.
Note however, that some file attributes aren’t quiet as expected. For example:
ls –l export/dist/dev
-rw-------. 1 wruser wruser 0 Jan 13 22:39 apm_bios
-rw-------. 1 wruser wruser 0 Jan 13 22:39 console
-rw-------. 1 wruser wruser 0 Jan 13 22:39 fb0
-rw-------. 1 wruser wruser 0 Jan 13 22:39 hda
-rw-------. 1 wruser wruser 0 Jan 13 22:39 hda1
-rw-------. 1 wruser wruser 0 Jan 13 22:39 hda10
-rw-------. 1 wruser wruser 0 Jan 13 22:39 hda11
…
Compare this to what you see in /dev on your host:
ls –l /dev
crw-rw----. 1 root video 10, 175 Jan 11 06:26 agpgart
crw-------. 1 root root 10, 235 Jan 11 06:26 autofs
drwxr-xr-x. 2 root root 300 Jan 11 06:26 block
drwxr-xr-x. 2 root root 80 Jan 11 06:26 bsg
c---------. 1 root root 10, 234 Jan 11 06:26 btrfs-control
drwxr-xr-x. 3 root root 60 Jan 11 06:26 bus
lrwxrwxrwx. 1 root root 3 Jan 11 06:26 cdrom -> sr0
drwxr-xr-x. 2 root root 3120 Jan 16 17:05 char
crw-------. 1 root root 5, 1 Jan 11 09:56 console
…
Focus not on the entries themselves, but rather the ownerships and attributes. Notice that
the entries in /dev on your host:
Have root:root ownership
Are primarily pipes or block or character device nodes rather than regular files (as
evidenced by the b , c and p bits in the leftmost column)
The device nodes have major and minor numers associated with them (10,175,
5,1, etc)
Whereas the entries in export/dist/dev all appear as regular files owned by
wruser:wruser.
The reason for this is because the entire build, including the generation of export/dist,
was done as a regular user (wruser). Under these conditions, it would be impossible to
generate device nodes or any files owned by root. Instead, the file system is built in a
fake root environment called pseudo. To see the effect pseudo has on your view of the
files, enter the pseudo environment and then reexamine the directory:
scripts/fakestart.sh
ls –l export/dist/dev
crw-rw---- 1 root 46 10, 134 Jan 13 22:39 apm_bios
crw-rw--w- 1 root tty 5, 1 Jan 13 22:39 console
crw------- 1 root root 29, 0 Jan 13 22:39 fb0
brw-rw---- 1 root disk 3, 0 Jan 13 22:39 hda
brw-rw---- 1 root root 3, 1 Jan 13 22:39 hda1
brw-rw---- 1 root root 3, 10 Jan 13 22:39 hda10
brw-rw---- 1 root root 3, 11 Jan 13 22:39 hda11
…
Like magic, all is as it should be. Always remember that if you want to see the file system
exactly as it was meant to be, that you must first enter the pseudo environment in which it
was generated.
6. To leave the pseudo environment, simply issue the command exit.
make start-target
8. Once your target boots, log in using the credentials root and password root.
9. Feel free to explore your target using the command-line shell. When done, the
preferred method of shutting a Linux system is always using the poweroff command,
although you can use other methods as well, as outlined in the Simulating Targets
with QEMU lab.
NOTE: This is important: the cl action line must be entered as one continuous line.
Due to printing restrictions, it is broken across two lines in this document.
11. Once you have made your changes, rebuild the platform and start the target to test
your changes. Verify that the file /root/README.txt can be found on the target, and
that its contents match those on the host.
echo “Welcome to your Wind River Linux 5.x image” > etc/motd
NOTE: The lack of a leading slash in etc/motd is intentional. The fs_final scripts are
executed in the root directory of the target file system, but are not executed
within a chrooted environment. This allows fs_final scripts to have full
access to the host file system as changelist.xml files do; but careful attention
must be paid when referencing files. In this example, if you inadvertently
wrote /etc/motd, you would actually be referring to /etc/motd in the host file
system.
13. Rebuild your image and redeploy the updated image to your target. Log in to verify
that your changes have taken effect; you should see the contents of the motd file
display after you log in.
14. To see the benefits of the fs_final mechanism, suppose you want to embed
information into your root file system that is not static. Suppose, for example, that
you wanted to embed the build date and board name into the motd. Add the following
code to fs_final_motd.sh:
15. Now rebuild and redeploy the updated image to your target again. Log in to verify
that your changes have taken effect. Notice that the date in the motd is hard-coded to
the exact time that the fs_final_motd.sh script was executed in building the file
system image.
16. Now, apply what you’ve learned to create a new fs_final script that creates a FIFO
entry, /mypipe with mode 0777. If you’re having difficulty, consult the online
manual:
man mkfifo
This will open a new terminal where the busybox source is located with all relevant
patches already applied. Note the name of the directory where the terminal opens,
busybox-1.19.4, which will be used in a later exercise.
18. Edit the code which implements the ls command provided by coreutils/ls.c. Add an
additional message to beginning of the ls_main() function; for example:
init_unicode();
fprintf(stderr, "Hello from ls\n");
if (ENABLE_FEATURE_LS_SORTFILES)
…
19. Once you finish editing the file, exit the development shell by typing exit or pressing
CTRL+D. You will be taken back to your original shell.
20. Now, rebuild busybox with your source changes:
With the package rebuilt, once again rebuild the image and deploy it to the target to
test your changes. Verify that every time you invoke the ls command, your message
appears.
Note that the changes you have made are only temporary. If you do a clean,
distclean, or cleansstate, your changes will be lost, and the original behavior of ls
will be restored.
21. Now that you have seen how to modify software for your platform, clean the build
area as follows:
22. Rebuild busybox, then rebuild the image and deploy it to your target. Now you will
notice that the behavior of ls is restored to its original state.
Again, the syntax might seem a little peculiar, but this is again a fragment of Python
code used by bitbake At a high level, IMAGE_FSTYPES lists the types of images to
build. Refer to local.conf for a full list of supported types.
24. Once you have saved your changes to the file local.conf, rebuilt your project. When
this finishes, you will see three files in the export/images directory with the suffixes
.jffs2 and .cpio.gz.