- Table of contents
- Linux Root File System
Linux Root File System¶
A sample linux root file system for the MityDSP-L138 and MityARM-1808 products are included in the Board Support Package downloads and are provided in tarball (for the purposes of NFS mounting) or jffs2 (for the purposes of flashing NAND based flash) formats. The linux root file system has been built using the Open Embedded build system under a linux development environment. A short description of what was done to create the filesystem is included in the Installing Open Embedded page. Note that this is generally not required for most deployments.
You can also use other root filesystems, including the one provided on the TI Digital Video SDK for the OMAP-L138. See the Dv_sdk_notes page for details.
Using the root filesystem¶
Flashing Image to NAND¶
(Note: parts of these instructions were derived from a TI DM816x U-Boot documentation)
Once you have a suitable image of a root filesystem you would like to deploy, you may wish to install it onto the MityDSP-L138 NAND Flash in order boot independently of a network connection and an external server. The MityDSP-L138 family of SOMs include 256 MBytes of NAND FLASH memory for local OS storage. NAND Flash technology provides a high amount of non-volatile storage at an inexpensive cost. This is achieved by allowing devices to contain bad blocks of storage in a production run. Therefore, software techniques must be employed to manage and track the bad blocks on the device. Fortunately, both the u-Boot NAND drivers and the linux NAND drivers deal with detecting and tracking bad blocks on a NAND chip and will skip using them during runtime. Software developers, however, must be aware of the fact that bad blocks do exists when programming devices.
There are several filesystem types that are designed to work with NAND or other non-volatile storage devices that linux supports. The filesystem used in this example is the JFFS2 filesytem. The JFFS2 filesystem is capable of handling scenarios where bad blocks are encountered on the target media (NAND). Please see http://sourceware.org/jffs2/ for more information.
The following command example shows the necessary options for appropriately creating a JFFS2 format file system from a directory on your virtual machine (or whatever *nix host machine you are on):
sudo mkfs.jffs2 -x lzo --root=<your_mityomap_rootfs>/ --faketime --output=<rootfs_image_file>.jffs2 --little-endian --eraseblock=0x20000 -n
where <your_mityomap_rootfs> is the directory that is the top of the root filesystem (i.e contains directories etc, usr, boot, and such)
and <rootfs_image_file> can be whatever name you want, but is typically the same as <your_mityomap_rootfs>
i.e. You created a filesystem hierarchy on your build machine under /home/mitydsp/build/my_filesystem/ then <your_mityomap_rootfs> would be /home/mitydsp/build/my_filesystem
If the mkfs.jffs2 command returns with:
sudo: mkfs.jffs2: command not found
Then you need to install "mtd-utils" by runnign the following from a terminal on your development kit virtual machine "sudo apt-get install mtd-utils"
Given a root filesystem in JFFS2 format, you need to transfer the image to the sector/partition of NAND that you want to load. From U-boot, given the MityDSP-L138 stock partitioning (these can be examined by the "mtdparts" command from u-Boot), this can be accomplished by the following commands. These commands assume:
- A NAND root filesystem partition size of 128 MBytes (the default configuration in a CL supplied kernel)
- A root filesystem image size less than 96MiB (100663296bytes).
u-Boot> mw.b 0xC2000000 0xFF 0x06000000 u-Boot> tftp 0xC2000000 myserver:/path/to/root_filesystem.jffs2 u-Boot> nand erase 0 0x8000000 u-Boot> nand write.jffs2 0xC2000000 0 0x<rounded_filesize>
Please NOTE that the "<rounded_filesize>" must be a hex number of the filesize rounded up to the next page size of the NAND device. In the case of MityDSP, this is 0x800. This is critical as overwriting additional data/pages to NAND will result in the kernel JFFS2 subsystem to inject ECC errors as it begins to write data/files to the partition. For example, if your jffs2 image size is 0x45cde74, then the argument passed to the nand write.jffs2 command must be 0x45ce000. Example using wolframalpha, equation: ceiling(0x45cde74, 0x800)
Please NOTE the ".jffs2" extension on the "nand write" command. This is critical. The extension (also ".e" and ".i" can be used) causes the u-Boot program to skip over bad blocks while writing the filesystem image to the NAND device. This is how the JFFS2 drivers in linux (or any other OS) expect the data to be stored in NAND. Not using the extension causes a straight write, and the u-Boot program will attempt to use bad blocks in the device.
Once the NAND flash has been stored, for linux you will need to configure the kernel command line to instruct it to boot using the NAND partition as the root filesystem. The default kernel for the MityDSP-L138 is configured to mount the first 128 MBytes of NAND as /dev/mtd0 and provides a JFFS2 compatible block driver at /dev/mtdblock0 to interface to the partition. The corresponding device line, then should include the following arguments (the mtdparts= line is optional if using a default CL kernel):
U-Boot> setenv bootargs mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mtdblock0 rw noatime rootfstype=jffs2 ip=none
Please keep in mind that, when mounted, this filesystem is read/write. In order to prevent loss of data, YOU SHOULD ALLOW IT TO BOOT UP CLEANLY, and YOU SHOULD SHUT IT DOWN cleanly with a "shutdown", "reboot", "halt" or "poweroff" command. During application writing of data, using the sync() system call will force a flush to the filesystem. Otherwise, any ongoing write operations may not complete and loss of posted write data could result. JFFS2 should be able to recover in the event of sudden power offs (avoiding filesystem corruptions), but it may not capture all of the posted writes if this situation occurs. If you need to support uncontrolled shutdowns while running a writable filesystem, consider Booting a Read-Only Linux Filesystem.
If you would like to flash this image while running linux (e.g., from an NFS mounted root drive), you can issue the following commands.
root@mitydsp# > flash_eraseall /dev/mtd0 root@mitydsp# > nandwrite -p /dev/mtd0 /path/to/your_mityomap_rootfs.jffs2
OR
root@mitydsp# > flash_eraseall /dev/mtd0 root@mitydsp# > mkdir -p /mnt/nand root@mitydsp# > mount -t jffs2 /dev/mtdblock0 /mnt/nand root@mitydsp# > cd /mnt/nand && tar xvzf your_mityomap_roofs.tar.gz
Once the root file system is set up, you will need to make sure that you have set uboot to load the kernel out of SPI flash (NOR flash). Instructions to do this are found on the following page under the title "Installing the Kernel on SPI - FLASH".
http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Kernel
Exporting as NFS mountable drive¶
These instructions are for a linux host (Ubuntu 10.04, e.g. the Critical Link provided VM).
The first thing you need to do is ensure that the NFS server is installed on the host. If you are using an Ubuntu based machine (e.g., the Critical Link provided VM), use the following command:
mityomapl138@vm:~$ sudo apt-get install nfs-kernel-server
Create a directory that will serve as the root filesystem and install the root filesystem tarball.
mityomapl138@vm:~$ mkdir mityomap_rootfs mityomapl138@vm:~$ cd mityomap_rootfs mityomapl138@vm:~$ sudo tar xzvf ../mityomap-base-mityomapl138_20100509.tar.gz
Next, you will need to configure the linux NFS server to share this directory. This can be done by editing the /etc/exports file and adding an entry similar to the following:
/home/mityomapl138/mityomap_rootfs *(rw,sync,no_root_squash)
This will allow any machine that can see your vm to mount this directory as root, rw. So be careful. If you are on an open network, you will need to add some security to this (see man 5 exports for details).
If there are problems mounting the disk from your target, check the /var/log/daemon.log file to see what the NFS server is saying.
Boot from an NFS server¶
There are 2 separate parts to using an NFS server for the L138.- Loading the kernel from an NFS server. (Assuming you have an ip address...)
- Using an NFS server for the root filesystem.
You can get an ip address from dhcp or statically. For dhcp, add ipaddr=dhcp to your environment.
U-Boot > setenv ipaddr dhcp U-Boot > saveenv
For a static ip, set ipaddr=10.0.x.x (or whatever you want the OMAP's ip address to be). Remember to save the environment if you want to boot this way in the future.
For simplification, the NFS server ip and NFS boot image can be saved as environment variables and changed as needed.
U-Boot > setenv serverip 10.0.0.87 U-Boot > setenv serverimage /home/mityomapl138/mityomap_rootfs/boot/uImage U-Boot > saveenv
[This example assumes the NFS server has the ip address 10.0.0.87 and has the boot image stored at /home/mityomapl138/mityomap_rootfs/boot/uImage]
To load the kernel via NFS into memory, you will use the uboot nfs command.
U-Boot > help nfs
nfs - boot image via network using NFS protocol
Usage:
nfs [loadAddress] [[hostIPaddr:]bootfilename]
U-Boot > nfs 0xc0700000 ${serverip}:${serverimage}
U-Boot > bootm
[If you decide not to use environment variables, replace ${serverip} and ${serverimage} with their corresponding ip and path]
To make this boot setting automatic and persist across power cycles, do the following:
U-Boot > setenv bootcmd "nfs 0xc0700000 ${serverip}:${serverimage}; bootm"
U-Boot > saveenv
In some cases, you may find that the ARM is unable to consistently copy the kernal over NFS, or that once it begins to boot, it can't NFS mount the root file system (see below). This is particularly true when directly connecting between a PC and an L138 system. If you have this problem, it may be helpful to add "ping ${serverip};" to the beginning of the boot command to ensure that the connection is established:
U-Boot > setenv bootcmd "ping ${serverip}; nfs 0xc0700000 ${serverip}:${serverimage}; bootm"
U-Boot > saveenv
When the server attempts a host lookup, it will most likely fail. To avoid this issue and speed the boot process, you can set the ip address of the L138 board in the NFS server's /etc/hosts file. Add an entry with the IP address, followed by a host name in the /etc/hosts file similar to the following:
10.0.X.X OMAPL138
Replace 10.0.X.X. with your L138 boards's ip address and select an appropriate host name (You may make one up).
To use an NFS server for the root filesystem, the nfs root assignment must be added to the bootargs evironment variable.
U-Boot > setenv bootargs ${bootargsbase} root=/dev/nfs nfsroot=${serverip}:/home/mityomapl138/mityomap_rootfs ip=dhcp
NOTE: While U-Boot allows you to nest and dereference environment variables, as seen above, this cannot be done within the parameters of the bootargs environment variable. This is due to the implicit usage of the bootargs variable by the bootm command. If ${serverip} were used instead of "10.0.0.87" as above, the boot sequence would use "${serverip}" as the ip address of the server and would not be able to load the NFS filesystem. Additional valid command line boot arguments for the linux kernel can be added to the bootargs variable.
Booting off MMC / SD Card¶
If you have an MMC interface on your I/O card hooked to the MityDSP-L138 or MityARM-1808 MMC peripheral, you can prepare an MMC / SD card to host both your root filesystem and the kernel for boot up. These instructions are valid for using a ext2 based filesystem on the SD card.
First, you need a root filesystem tarball. Here is an example for creating one from an NFS mounted file system:- On the system where the NFS mounted file system is located, change directory to the root of your NFS mounted drive.
- Create the tarball using the following command:
mitydspl@mitydsp:~/mityomap_rootfs$ sudo tar -czvf /path/to/write/my_rootfs.tar.gz ./
Alternatively you can use one of the tarballs located in the MDK. (/home/mitydsp/MDK_2014-01-13/fs/mityomap-full.tgz or /home/mitydsp/MDK_2014-01-13/fs/mityomap-full.tgz)
Second, you need to prepare the SD card. This can be done on the target by inserting the MMC card and running the commands:- Find sd card using
fdisk -l. You can be pretty confident that the disk is the sd card by looking at its total size (3965 MB), this closely matches the 4GB sd card.mitydsp@mitydsp $ sudo fdisk -l [...] Disk /dev/sdd: 3965 MB, 3965190144 bytes 3 heads, 32 sectors/track, 80672 cylinders, total 7744512 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000d934d Device Boot Start End Blocks Id System /dev/sdd1 2048 7743487 3870720 83 Linux
Please make sure you have at least one partition listed (for example/dev/sdd1/).
- Format sd card and extract tarball. Remember to unmount the sd card before removing it.
mitydsp@mitydsp $ sudo -s root@mitydsp # umount /dev/sdd1 root@mitydsp # mkfs.ext3 -L "rootfs" /dev/sdd1 root@mitydsp # mount /dev/sdd1 /mnt root@mitydsp # cd /mnt/ root@mitydsp # tar xzvf /home/mitydsp/MDK_2014-01-13/fs/mityomap-full.tgz root@mitydsp # cd / root@mitydsp # umount /dev/sdd1
This will create an ext3 partition on the MMC card and install a provided root filesystem. Root filesystems provided by Critical Link will also include a working kernel image located in /boot in the tarball. You may want to add your image if it requires tailoring. Keep in mind that you may need install kernel modules, etc., if kernel modificaiton is required.
Once you have the MMC card setup, reboot and enter u-Boot.
Note: By default, u-boot will not talk to the MMC card, since this could cause problems if those pins are used for something else on a given project. For this reason, you must enable the MMC pins by configuring u-boot. Follow the directions on the u-Boot MMC Configuration Page.
Once the MMC is enabled, here are the commands to load both the kernel image as well as mount the root filesystem from an MMC/SD partition. If you only want to mount the root filesystem and load the kernel elsewhere, you'll need to remove the ext2load line and replace it with the load command for your given media (e.g., SPI NOR flash).
U-Boot > mmcinfo U-Boot > setenv bootargs mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mmcblk0p1 rw rootwait ip=none U-Boot > ext2load mmc 0:1 c0700000 /boot/uImage U-Boot > bootm
To autoboot on powerup, you'll need to update your bootcmd environment variable to issue the proper commands to read the kernel from the MMC at startup. This can be done using:
U-Boot > setenv bootcmd "mmcinfo;setenv bootargs mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mmcblk0p1 rw rootwait ip=none;ext2load mmc 0:1 c0700000 /boot/uImage; bootm" U-Boot > saveenv
Note that depending on your specific application, you may need to modify the bootargs (e.g. the ip=dhcp option).
Once this bootcmd is saved, the module will autoboot from the SD card after a power cycle.
Capturing a modified root filesystem stored on NAND¶
Oftentimes the file system is modified while running from NAND. If this occurs the changes need to be captured so they can be deployed to other production units. There are several ways to accomplish this. One is to NFS boot to another filesystem, then mount the NAND, and tar up the contents.
To NFS boot, follow the instructions above.
Then, create a new directory to mount the NAND block to:
mkdir /fs_root mount -t jffs2 /dev/mtdblock0 /fs_root
Finally, Tar up the contents of the filesystem
cd /fs_root tar cvzf /fs_root.tar.gz ./
You can either untar this file over the top of existing units filesystems, or you can create a jffs2 image from the files and use that to write the NAND blocks directly, as shown here. The commands shown below should be run on the servers that hosts the NFS mount. The sudo in the commands below ARE REQUIRED. You MUST run these commands as root or the owner will be incorrect and strange problems will occur when using the images.
mkdir ./fs_root cd fs_root mv ../fs_root.tar.gz ./ sudo tar xvzf ./fs_root.tar.gz
At this point you will want to remove anything cached on the filesystem. If udev is installed, delete /etc/dev.tar so that the udev device cache is regenerated on the first boot. Also, if you have multiple network interfaces you may want to remove the /etc/udev/rules.d/70-persistent-net.rules file so that the system doesn't tie interface names to non-existent HW addresses on a new board.
cd .. sudo mkfs.jffs2 -x lzo --root=fs_root/ --faketime --output=fs_root.jffs2 --little-endian --eraseblock=0x20000 -n
Then follow the instructions at the top of this page to flash this image into NAND on the other units.
If you need to examine a previously created jffs2 filesystem on a linux development machine, follow the directions given here..
http://wiki.openmoko.org/wiki/Userspace_root_image
Go to top
