p4 by cuiliqing


									Embedded Systems Programming                                                  Practical 4

Title:                 Building a root file system for a target board
Author:                Craig Duffy 16/10/06
Module:                Embedded Systems Programming
Awards:                CRTS 4, BSc Computing (Part-Time), MSc ATE
Prerequisites:         Linux kernel source, ARM assembler, running a kernel

This worksheet will take the reader through the stages required to build a minimal
root file system for our target board. This will include the building of the library files
and the application binaries. Details will be given on the installation of the file
system onto the Puppeteer board.

System requirements for an embedded system

To create the kernel we need a copy of the Linux kernel source code. If we want to
do any useful work with the Linux Operating System once we have it on the
Puppeteer boards we also need facilities such as a compiler (with its associated
libraries) and utilities such as the ability to login and perform housekeeping. To set
up these extra facilities we need even more source code!

Since the standard Linux source code is designed for a simple PC (probably i386!) we
need to patch it to be able to deal with the physical devices (UARTs etc) that exist
with our processor. These patches will also be source code.

Embedded systems have some major differences from standard Linux systems.
Firstly they generally don’t have disk storage that is normally associated with file
systems. They frequently won’t have the other peripherals; CDROMS, floppy drives,
that one uses as part of the build process on a Linux system with a new machine.
Later on we will see how flash memory can be used as a substitute for disc on system
boot, but for the moment we will load and run all of our file systems from RAM.

Building the binaries for the root file system

It is possible to find, on the Web, pre-created root file systems for ARM platforms –
the Debian site has some. The problem with these is that they are not created with
our board in mind and will have too many or the wrong selection of libraries and
binaries. Therefore on this worksheet we build our own root file system from scratch.
Before we build the binaries we have to decide on a set of libraries for the system.

Which library?

The library that is used on most Linux systems is glibc, the standard GNU C library.
This is unsuitable for our purposes because it is far too large, as it has been developed
for PC platforms, so it is not aiming for size efficiency and implements far more
functions than we need. There are a number of small/more efficient, embedded
systems targeted libraries around. For example on the department’s Motorola 68307
FM200 boards we ported the Redhat Newlib library to the board for use with the GNU
cross compiler and the Minos operating system. This library is specifically intended
for use with embedded systems with limited resources. Even though Newlib is pretty

Craig Duffy                           Page 1 of 13                            11-Aug-11
Embedded Systems Programming                                                    Practical 4

easy to port, it was rejected because its level of functionality is low and it makes little
use of Linux’s underlying resources. The library, uClibc that has been developed as
part of the uCLinux project, a version of Linux for MMUless machines, which is now
part of the Linux kernel distribution, seemed promising. It is completely compatible
with Glibc, and is completely integrated with Linux. uClibc was developed by the
people who developed Busybox and Tinylogin. These are two of the most popular
applications in embedded Linux.

As we have used buildroot to build our cross compiler tools we can also use it to build
our libraries and applications. In building the compiler you will have already built a
copy of the uClibc library however this version won’t be specifically configured for
our system so will need re-configuring.

Configuring and building a new version of uClibc and Busybox

When we created the cross compiler with buildroot we weren’t interested in the other
options that buildroot has, and we need to consider them now. Buildroot allows us to
build a root file system for a system. It then populates this filesystem with specified
applications. In order to build these applications we require a C library (uCLibc) and
a compiler suite (gcc and binutils). Before we consider configuring these things, we
need to make sure that we have selected them for download. To do this you need to
return to you base buildroot directory and type in

       make menconfig

This will allow us to select more packages to download. You should ensure that you
don’t change the cross compiler or binutils – we don’t want to have to re-download
and make these. You should also ensure that you don’t specify snapshots for any
program – this means that it will always download the most up to date version, which
is not necessary for us. You should also make sure that you are using the linux header
files for a 2.6 series of kernels – the closest to 2.6.16, the kernel version we have built.

Once you have saved these changes you should then quit out of make menuconfig and


You may wish to run script beforehand to save any output. Hopefully your make
should run through and download and build the new version of busybox and create a
root file system. You can check if this has happened by looking in build_arm/root/bin
to see if the busybox binaries have been installed.

Before starting this section you should read the documents on the buildroot web

Configuring uClibc

To configure uClibc with our own more precise settings we need to go into the
directory with its source code. Go into the directory

Craig Duffy                            Page 2 of 13                             11-Aug-11
Embedded Systems Programming                                   Practical 4

      cd buildroot/toolchain_build_arm/uClibc-0.9.NN (where NN is the
      version of uClibc you downloaded)

Once in this directory then you can run the configuration system

      make menuconfig

Below is given a box with the setting that I would recommend. There
are a vast number of possible combinations, and a large number of
them will probably work.    The set below are intended to create a
small workable library and they will not include support for TCP/IP
so the library will be need to be rebuilt when we implement the
Ethernet device driver.

        target arch -> arm
        target arch feature & opts -> proc type -> strongarm sa1100
                              -> top endianess -> little endian
                              -> select has an MMU
                              -> don't select enable floating point
                              -> don't select C99 math
                              -> header location leave as is

        General library settings ->PIC yes (yes = select)
                          -> shared libs yes
                          -> compile native shared ll yes
                          -> only load shared yes
                          -> native ldd yes
                          -> enable shared cache yes
                          -> enable load preload no
                          -> naming prefix ld.so
                          -> enable ELF RUNPATH no
                          -> uClibc 0.9.27 no
                          -> support global const & destr no
                          -> posix thread yes
                          -> thread dbg yes
                          -> large file no
                          -> ldconfig static no
                          -> malloc -> malloc-standard
                          -> malloc returns no
                          -> dynamic atexit no
                          -> shdow password no
                          -> support unix 98 ptys yes
                          -> assume devpts/devfs no
                          -> support struct tm yes
                          -> enable caching TZ yes
                          -> enable /etc/TZ to default yes
                          -> repeatedly read /ect/TZ no
                          -> path to TZ is /etc/TZ

        Networking support
                         -> IP V6 yes
                         -> RPC yes
                         -> full rpc support yes
        string and stdio support
                         -> use glibc yes
                         -> arch-specific yes
                         -> table version of ctype.h yes
                         -> signed chars yes
                                -> ctype args -> detect and handle
                           -> wide char no

Craig Duffy                    Page 3 of 13                    11-Aug-11
Embedded Systems Programming                                                  Practical 4

                              ->   locale support no
                              ->   glibc printf.. no
                              ->   use old vprintf no
                              ->   max no of args =9
                              ->   scanf flag no
                              ->   stdio buffer =1024
                              ->   stdio built-in buffer size -> none
                              ->   shutdown stdio on abort no
                              ->   macro of getc yes
                              ->   macro of putc yes
                              ->   auto r/w trans yes
                              ->   fopen x flag yes
                              ->   fmemopen no
                              ->   support %m yes
                              ->   errno test yes
                              ->   sys_errlist no
                              ->   signum message yes
                              ->   sys_siglist no
                              ->   gnu getopt no
         big and tall
                          ->       reg expr yes
                          ->       wordexpr no
                          ->       ftw nftw no
                          ->       glob yes
         lib install iopts
                          ->       /lib shred lib loader path
                          ->       / uClibc runtime
                          ->       /usr/ uClibc development
         security         ->       enable security no

                              -> leave cross compiler path as is
                              all others unchecked/

Save the settings and don’t whatever you do (especially if you are logged in as root!)
run make. To remake the library we need to copy the .config file into the
uClibc.config file that buildroot uses.

       cp .config buildroot/toolchain_arm/ucblicb/uclibc-9.2.NN/uclibc.config

         What is busybox?

         Busybox was originally created to help make bootable version of Linux that
         could be kept on a floppy disk. It contains all of the binaries that you require
         to run a Linux system in a space optimised form. The system is very
         configurable, so you can easily select what commands and options you
         require. It contains lots of commands and tools which allows a very small
         footprint version of Linux to be run.

Configuring BusyBox

Change into the directory build_arm/busybox-1.2.N (where N is the version you
downloaded). Once in this directory run

Craig Duffy                          Page 4 of 13                            11-Aug-11
Embedded Systems Programming                                             Practical 4

       make menuconfig

Below is given a series of settings to create a small efficient busybox binary. This
configuration doesn’t include network options so we will have to remake it when we
install the Ethernet device driver.

         archival utilities      -> all unchecked
         coreutils               -> check cat chgrp chmod chown chroot
                          cmp cp cut date dd df dirname duenv expr
                          false head hostedid install ln ls (plus opts)
                          mkdir mknod mv pwd rm rmdir sleep sort stty
                          tail tee touch true tty uname usleep wc yes
                          opts for cp & mv preserve hard link.
                          calculate term & col widths support human
                          readable output
         console utils    -> all unchecked
         debian utils     -> mktemp tart-top deamon support additional
         editors          -> sed vi all opts checked
         find utils       -> find enable -print type matching
                          grep check all opts
                          xargs check all opts
         init utils       -> init read inittab     poweroff halt
         login/password   -> getty. login passwd su sulogin
         linux ext2 fs    -> all unchecked
         linux module     -> all unchecked
         linux sys utils -> dmesg getopt hexdump more (plus opt) mount
                          pivot_root rdate umount
         misc utils       -> strings
         network utils    -> all unchecked
         process utils    -> free kill killall pidof ps (plus opts)
         shells           -> ash opts - job control alias posix math
                          echo test optimise for size bourne opts -
                          command line edit history and tab
         sys logging      -> all unchecked
         busbox settings
         general config   -> use devpts fs for UNIX98 ptys
                          -> show terse applet usage
                          -> all unchecked
         build opts       -> if you enabled large file support you can
                          enable it here.
                          -> all others off debugging opts
                          -> check disable obsolete features

         install opts     ->    leave Don't use /usr
                          ->    applets links
                          ->    soft links
                          ->    (,/_install) busybox installation prefix
         busybox lib tuning
                           ->    MD5 trade bytes for speed set to 2

Craig Duffy                        Page 5 of 13                          11-Aug-11
Embedded Systems Programming                                                            Practical 4

Save the settings and copy the config file into the place that buildroot uses.

       cp .config buildroot/package/busybox/busybox.config

It is a good idea to copy both the busybox.config and uclibc.config files into a safe
place as they can be easily deleted by running the buildroot make command.

Creating a root file system

Buildroot creates a root file system in the directory build_arm/root. This is
configured in a generic way which is not suitable for our purposes and will need some
changes. However buildroot creates a very useful framework for our system and can
easily be adapted.

The following 10 directories are mandatory for a root file system:
    dev    etc   etc/init.d          bin    sbin   lib    usr       usr/bin      proc    tmp

If you look at /dev/ and /dev/pts/ on Linux PCs you will find that there are an
enormous number of files and sub-directories. On an embedded system we will only
need the minimum set of files. On my Puppeteer machine these are:

           #ls –l /dev
           lrwxrwxrwx     1   root         root           6   Dec   8   2003   console -> ttySA0
           crw-rw-rw-     1   root         root    205,   5   Dec   8   2003   cusa0
           crw-rw-rw-     1   root         root    205,   6   Dec   8   2003   cusa1
           crw-rw-rw-     1   root         root    205,   7   Dec   8   2003   cusa2

Craig Duffy                                Page 6 of 13                                 11-Aug-11
Embedded Systems Programming                                                   Practical 4

           crw-r-----   1   root   root       1,   2   Dec   16 2003 kmem
           crw-rw----   1   root   root       1,   1   Dec   16 2003 mem
           crw-rw-rw-   1   root   root       1,   3   Feb   29 2004 null
           crw-rw----   1   root   root      96,   0   Feb   18 2004 pt0
           crw-rw----   1   root   root      96,   1   Feb   18 2004 pt1
           crw-rw----   1   root   root      96,   2   Feb   18 2004 pt2
           crw-rw----   1   root   root      96,   3   Feb   18 2004 pt3
           crw-rw-rw-   1   root   root       5,   2   Feb   18 2004 ptmx
           drwxr-xr-x   2   root   root         1024   Feb   18 2004 pts
           crw-rw-rw-   1   root   root       2,   0   Feb   18 2004 ptyp0
           crw-rw-rw-   1   root   root       2,   1   Feb   18 2004 ptyp1
           crw-rw-rw-   1   root   root       2,   2   Feb   18 2004 ptyp2
           crw-rw-rw-   1   root   root       2,   3   Feb   18 2004 ptyp3
           crw-rw-rw-   1   root   root       2,   4   Feb   18 2004 ptyp4
           brw-rw----   1   root   root       1,   1   Dec    8 2003 ram
           crw-rw-rw-   1   root   root       5,   0   Dec    8 2003 tty
           crw-rw-rw-   1   root   root       4,   0   Dec    8 2003 tty0
           crw-rw-rw-   1   root   root       4, 64    Dec    8 2003 ttyS0
           crw-rw-rw-   1   root   root       4, 65    Dec    8 2003 ttyS1
           crw-rw-rw-   1   root   root     204,   5   Jun    6 02:09 ttySA0
           crw--w--w-   1   root   root     204,   6   Jun    6 02:09 ttySA1
           crw-rw-rw-   1   root   root     204,   7   Dec    8 2003 ttySA2
           crw-------   1   root   root       3,   0   Feb   18 2004 ttyp0
           crw-------   1   root   root       3,   1   Feb   18 2004 ttyp1
           crw-------   1   root   root       3,   2   Feb   18 2004 ttyp2
           crw-------   1   root   root       3,   3   Feb   18 2004 ttyp3
           crw-rw-rw-   1   root   root       3,   4   Feb   18 2004 ttyp4
           # ls -l /dev/pts
           crw-------   1   root   root     136,   0   Feb   18   2004   0
           crw-------   1   root   root     136,   1   Feb   18   2004   1
           crw-------   1   root   root     136,   2   Feb   18   2004   2
           crw-------   1   root   root     136,   3   Feb   18   2004   3

As these are device files we need to create them with the mknod command, which
specifies the major and minor number for the device. Care has to be taken with these
numbers as they directly relate to the device driver code in the kernel. To use mknod
you may need to have root access (ask your lab tutor)! The following commands will
create our bare bones /dev. On some systems, where the home directories are nfs
mounted you won’t have permissions even as root to do this and you will need to
copy you root file system across into /tmp to use mknod.

           mknod   -m 0666 tty c 5 0
           mknod   -m 0666 tty0 c 4 0
           mknod   -m 0666 ttyS0 c 64 4
           mknod   -m 0666 ttyS1 c 65 4
           mknod   -m 0666 ttySA0 c 204 5
           mknod   -m 0666 ttySA1 c 204 6
           mknod   -m 0666 ttySA2 c 204 7
           ln -s   ttySA0 console
           mknod   -m 0666 cusa0 c 205 5
           mknod   -m 0666 cusa1 c 205 6
           mknod   -m 0666 cusa2 c 205 7
           mknod   -m 0660 ram b 1 1
           mknod   -m 0640 kmem c 1 2
           mknod   -m 0660 mem c 1 1
           mknod   -m 0666 null c 1 3
           mknod   –m 0666 pt0 c 96 0
           mknod   –m 0666 pt1 c 96 1
           mknod   –m 0666 pt2 c 96 2
           mknod   –m 0666 pt3 c 96 3
           mknod   –m 0666 ptmx c 5 2
           mknod   –m 0666 ptyp0 c 2 0
           mknod   –m 0666 ptyp1 c 2 1
           mknod   –m 0666 ptyp2 c 2 2
           mknod   –m 0666 ptyp3 c 2 3

Craig Duffy                         Page 7 of 13                               11-Aug-11
Embedded Systems Programming                                                   Practical 4

           mknod   –m 0666    ttyp0   c   3   0
           mknod   –m 0666    ttyp1   c   3   1
           mknod   –m 0666    ttyp2   c   3   2
           mknod   –m 0666    ttyp3   c   3   3
           mkdir   pts

The mknod command makes character devices, with the mode 0666 (rw_rw_rw_),
and sets their major and minor numbers. The pts directory and the ptmx, ptyp0, and
ttyp0 entries are all to do with the pseudo-tty driver. The details of the allocation of
major numbers to devices can be found in the kernel documentation –

The /proc directory is used by the proc file system, so we need do no more than
create the empty directory. /tmp and /lost+found are likewise required by the system,
but don’t need populating. /etc is used for various system administration commands
and scripts, the sub directory init.d is required, everything else in the buildroot created
version can be deleted. Scripts that need to be placed in /etc and /etc/init.d are given
in the appendix and discussed later on (don’t forget to put your own name in the
passwd file!).

You will find that buildroot has placed all of the correct library files into lib and
/usr/lib. Likewise all of the binaries that we requested building will be in the various
bin directories - /bin /usr/bin /sbin /usr/sbin. If you notice a mismatch between what
you configured in busybox and what is in the root file system then you may have a
problem. It is worth cleaning out the file system and re-running make from the top
level buildroot directory.

Once you feel sure that your root file system has been correctly configured – be
especially careful that the file in /etc/and /dev are correct as errors in these can cause
the system not to boot up.

The final file we need to create is an init file which is in the top level directory of our
root file system and is linked to busybox. This will be the first thing that the kernel
will run and will cause a kernel panic if not there or incorrect. So type

       ln –s bin/busybox init

from the top level directory of the root file system to make a symbolic link from init
to bin/busybox. Now we have a useable root file system (we hope!).

Booting systems and file systems

The 2.4 and earlier kernels used a system called intrd for providing the kernel with a
bootable file system, the preferred 2,6 system is called initramfs, although intrd is still
heavily used and supported. Both are attempting to get over a large problem of
system booting. The problem can be formulated this way. “in order for the kernel to
boot a root file system it need to have a /dev entry for the device that it is booting, in
order to have a /dev entry it needs a root file system”. So it seems stuck – in order to
have a root file system we need /dev and in order to have /dev we need a root file

Craig Duffy                           Page 8 of 13                             11-Aug-11
Embedded Systems Programming                                                  Practical 4

The kernel get around it in a number of ways. Firstly some of the /dev entries are
hard coded into the kernel so that they can be accessed early, some devices like eth0,
the ether device are not in /dev anyway so can be booted from without a file system.
Hard coding stuff into the kernel is not an ideal solution, as it means that the kernel
then becomes device specific and changes can become tricky. In order to run a file
system the kernel has to copy it from the device – normally a hard drive of some sort,
and place it into ram so that it can access it. Once the system is up and running this is
fairly straight forward but as we have seen above during boot up this is fraught with

One solution is to create an image from the disk and place it somewhere that the
kernel can find it. This means that we have to download the file system separately
and make sure the kernel is pointing at it, this is the system used by intrd. The system
then copies the kernel into ram disks and run from it.

The initramfs system allows us to attach a file system image in the cpio format to the
end of the kernel image. The cpio format is an older UNIX format for archiving file
systems – see man cpio for details. This file system is then locked into kernel cache
buffers rather than copied into ram disk – this means that the system doesn’t have to
copy the file system internal and it is always available.

Creating a initramfs file system

In order to create the system we need to prepare our root file system in the correct
way and then configure the kernel to expect it. To create a cpio image simply type.

       find . | cpio --quiet -o -H newc > /tmp/pupfs.cpio

This will create the correct format image in the file pufs.cpio in the /tmp directory.
This should be a fairly large file.

Next we need to reconfigure the kernel to use initramfs and to tell it where the image
is. For this we need to go back to our kernel source tree and run

       make menuconfig/xconfig (whichever you prefer!)

In the general settings you give the path name of your initramfs cpio image and under
the boot menu you can add the command nonitrd to the end of the command string.

Craig Duffy                           Page 9 of 13                           11-Aug-11
Embedded Systems Programming                                                  Practical 4

You can then save the settings and rebuild the kernel. Do a make clean just before to
make sure that you get a good build!

You should notice that in the usr directory in the kernel source that the file built-in.o
is pretty large you should also notice a large size difference between the kernel image
vmlinuz and the compressed downloadable image boot/compressed/vmlinux. The
latter has the compressed file system attached the former is just a compressed kernel
image. You might get a failure during your kernel build with the following message,
the error is highlighted.

       make -f scripts/Makefile.build obj=arch/arm/boot
       MACHINE=arch/arm/mach-sa1100/ arch/arm/boot/zImage
         Kernel: arch/arm/boot/Image is ready
       make -f scripts/Makefile.build obj=arch/arm/boot/compressed
         /root/buildroot/build_arm/staging_dir/bin/arm-linux-ld -EL
       --defsym zreladdr=0xc0008000 --defsym initrd_phys=0xc0800000 --
       defsym params_phys=0xc0000100 -p --no-undefined -X
       uclibc/3.4.2/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds
       arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/head-
       sa1100.o -o arch/arm/boot/compressed/vmlinux
       /root/buildroot/build_arm/staging_dir/bin/arm-linux-ld: section
       .bss [c8100000 -> c8108437] overlaps section .text [c8000000 ->
       make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
       make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2

Craig Duffy                          Page 10 of 13                           11-Aug-11
Embedded Systems Programming                                                 Practical 4

       make: *** [zImage] Error 2

This is the part of the kernel build that builds the downloadable image which
comprises of the kernel plus file system. The kernel itself (vmliux) has been built with
no problems. The difficulty is that the image has got so large that it is now
overwriting the decompressor's variable data area. This value is specified as
ZBSSADDR in the file arch/arm/boot/compressed/Makefile. There are 2 ways
around this problem. Firstly you could just change the ZBSSADDR value, thus
giving more space for the image. Although this will work, it is likely that your file
system is too large and you have created a inefficient file system. The second option,
and cure to the previous efficiency problem, is to look at your uclibc and busybox
settings and create a slimmer file system. I would suggest trying the second option
first, and if that doesn't work then you can always change the makefile value.

Once you have managed to create a downloadable image you should elf2bin it and
then download it onto a board using eloadsvr. You will notice that both of these take
much longer as the image is so much bigger. Upon executing, if you are lucky, you
should get the following.

         Image start 0xC8000000 length 0x000EAFD4 end 0xC80EAFD4
         Image targetted at RAM
         RecAddr = C8000000h, Dest = C8000000h, RecLen = 000E2B9Ch
         RecAddr = C8400000h, Dest = C8400000h, RecLen = 00008438h
         RecAddr = 00000000h, Dest = 00000000h, LaunchAddr = C8000000h
         Got EDBG_CMD_CONFIG, flags:0x00000008
         Network Transfer Complete
         EtherDownloadImage: Setting clean-boot flag
         Uncompressing Linux............................................. done,
         booting the kernel.
         Linux version 2.6.16 (root@Richmond) (gcc version 3.4.4) #44 Mon Sep 25
         12:52:49 UTC 2006
         CPU: StrongARM-1110 [6901b118] revision 8 (ARMv4)
         Machine: Puppeteer
         Ignoring unrecognised tag 0x00000000
         Memory policy: ECC disabled, Data cache writeback
         Built 2 zonelists
         Kernel command line: root=/dev/ram0 console=ttySA0,115200n8 noinitrd
         PID hash table entries: 256 (order: 8, 4096 bytes)
         Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
         Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
         Memory: 16MB 16MB = 32MB total
         Memory: 31044KB available (728K code, 81K data, 548K init)
         Mount-cache hash table entries: 512
         CPU: Testing write buffer coherency: ok
         All systems are go!
         NetWinder Floating Point Emulator V0.97 (double precision)
         io scheduler noop registered
         io scheduler anticipatory registered (default)
         io scheduler deadline registered
         io scheduler cfq registered
         Serial: SA11x0 driver $Revision: 1.50 $
         sa11x0-uart.1: ttySA0 at MMIO 0x80010000 (irq = 15) is a SA1100
         RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
         Freeing init memory: 548K

         Please press Enter to activate this console.

         BusyBox v1.2.1 (2006.09.22-16:55+0000) Built-in shell (ash)
         Enter 'help' for a list of built-in commands.

         -ash: can't access tty; job control turned off
         / $ tty

Craig Duffy                         Page 11 of 13                           11-Aug-11
Embedded Systems Programming                                  Practical 4


Still goes into kernel panic?
Things to check.

       That the command string to the kernel is correct - if it isn't
       it can cause the wrong root file system to be tried.

       The cpio file as included in the kernel? This is harder to
       check, but the vmlinux image in arch/arm/boot/compresssed
       should be much larger than the vmliux in linux top level

       Triple check that the root file system in buildroot is correct.
       Are the /dev entries correct? (remember that the smallest error
       can result in a unbootable system)

       Do the bin and lib directories look sensible?   Compare with a
       working system.

       Are the etc files correct? This can prevent boot and cause a
       panic but can result in a system that hits lots of errors that
       it hangs up despite having mounted the file system. This
       normally is caused by the original buildroot files doing things
       that are silly/impossible on your system.

       If you get the error message….

              can't load library 'libgcc_s.so.1'
              Kernel panic - not syncing: Attempted to kill init!

       cp build_arm/stagingdir/lib/libgcc_s.so.1 build_arm/root/lib/
       and rebuild the root file system and kernel

Craig Duffy                     Page 12 of 13                 11-Aug-11
Embedded Systems Programming                                              Practical 4


Files for /loop/etc

/dev/ram                /     ext2           defaults       0         0
proc                    /proc proc           defaults       0         0 /mnt nfs             rw             0         0

::respawn:/sbin/getty -L ttySA1 115200 vt100



/bin/echo "doing rcS"
/bin/mount -t ext2 -o remount,rw /
/bin/mount /proc
#/bin/mount -n -o remount,rw > /etc/mtab
#/bin/mount -a
#/bin/echo "configuring lo and eth0"
#/sbin/ifconfig lo
#/sbin/route add -net netmask lo
#/sbin/ifconfig eth0
/bin/echo "done rcS"
      etc/init.d/rcS (includes commented out network set up)

/bin/echo “umounting file system and remounting as ro!”
/bin/umount –f –a -r
/bin/mount –n –o remount,ro

Make rcS and umountfs executable by using chmod, e.g. chmod 744 rcS

Craig Duffy                         Page 13 of 13                         11-Aug-11

To top