![]() |
|||
![]() |
IntroductionIn earlier releases, all non-transient Itsy applications were stored in flash memory inside compressed ramdisk images. Adding or removing files from an Itsy was an inconvenient multi-step process involving the ldrd and mkrd scripts. The granularity of working with entire ramdisk images also made changes very time-consuming, since large ramdisk images had to be "burned" into flash via the relatively slow serial port.This documentation describes our current improved model for managing Itsy ramdisks, persistent flash-based filesystems, packages, and startup scripts. Hopefully it will make your Itsy experience a bit more pleasant.
DefinitionsAs used in this document, the term ramdisk refers to a compressed disk image, as created by the mkrd script. This is essentially a block-level filesystem copy made using dd and then compressed using gzip. An ftl filesystem is a persistent flash-based filesystem constructed using our port of the Linux Flash Translation Layer driver. Please refer to the separate FTL documentation for detailed instructions on creating a flash filesystem; the procedure basically involves ftl_insmod, ftl_format, and mke2fs.
A package is a collection of related files and an associated startup script that is automatically run at boot time to perform any necessary installation and initialization. Packages are currently stored as simple compressed tar files (e.g., package-name.tar.gz). In future releases, we may migrate to a more sophisticated package manager such as rpm. Flash Bank ConfigurationOn the Itsy v1 prototypes, the motherboard had 4MB of flash, which was always dedicated to storing the monitor, kernel, initial ramdisk, etc., and memory-extension daughtercards were used for additional flash. The extra flash is usually accessed through the FTL flash filesystem. On the v2 prototypes, the motherboard has 32MB of flash, which is software-partitioned into a 4MB region (for the monitor, kernel, initial ramdisk, etc.) and a 28 MB region containing a FTL flash filesystem (in the current release). This partitioning can be changed using the flash_region command; extensive documentation on this is available in the apps subtree under ftl_utils (the command is called flash_region). Memory-extension daughtercards are also available for the v2, and can also be partitioned if you like, although there is no need. The preferred configuration is to use ftl on all regions except for the first 4MB one. For backwards compatibility, any region may instead contain a compressed ramdisk.The naming convention for filesystems is as follows. /dev/flash1 refers to the entire motherboard flash (4MB for v1 Itsy, 32MB for v2). /dev/flash1a refers to the first region (default of 4MB for Itsy v2), /dev/flash1b refers to the second region (default of 28MB for Itsy v2), and /dev/flash1c the third (empty for Itsy v2).
System Startup ScriptAt boot time, the system startup script /etc/rc.d/init.d/local is executed, performing the following steps:Load common kernel modules. Determine which flash regions (e.g. flash1b, flash2, etc.), auto-detect their sizes and type of data they contain (gzip-compressed ramdisk or ftl filesystem). For a compressed ramdisk, extract from flash, decompress into in-memory ramdisk, and mount. For an ftl filesystem, load the ftl kernel module, run e2fsck on the block device, and mount. For each newly mounted filesystem, execute each package startup scripts in the top-level directory rc.itsy, if any, using the same conventions used for the rc files under /etc/rc.d. NOTE: Some packages make use of on-the-fly created ramdisks. The ram device (/dev/ram4 or whatever) is hardcoded in the respective rc.itsy/script that creates and populates the disk. See /wrl/proj/itsy/packages/RamDeviceAllocation for more information. Package Startup ScriptsPackages provide quite a bit of flexibility for installing and initializing sets of related files. Each package includes an rc.itsy containing one or more startup scripts named with the prefix SNN, where NN is a two digit number (e.g., S10developer, S18doom, etc.) These startup scripts are run sequentially in ascending numeric order (i.e., 10 then 18) soon after boot time when /etc/rc.d/init.d/local is executed, as described above.A typical startup script for package foo generally does something like the following: Make a symbolic link from /pkg/foo, providing a useful convention for finding packages without using absolute pathnames containing mount points. For example:
Make symlinks for packages executables from /usr/local/bin. For example:
Update ldconfig information for any shared libraries. For example:
Perform any other necessary initialization. For example, the doom startup script creates a separate in-memory ramdisk, decompresses its wad file there, and then makes an appropriate symlink. This saves space when using an ftl filesystem, but doesn't make a lot of sense if the package is put onto a compressed ramdisk. Installing PackagesOnce you have found or created a package, you need to put it on your Itsy. For the preferred setup where the package will live on an ftl filesystem, you can simply run the sendpkg command as follows:sendpkg -h host -d dir foo.tar.gz The sendpkg script is very simple, using rsh and tar to install the specified foo package on the specified host. If left unspecified, the -h host option defaults to the Itsy hostname itsy-$USER, and the -d dir installation directory defaults to /disk1b, which is typically a symbolic link to /mnt/ftl1b (on an Itsy v2; this region is unlikely to exist on an Itsy v1). Once sendpkg completes, you can run the startup script the first time manually, or simply reboot and it will run automatically. If you instead want to put a package into a compressed ramdisk, simply create a new ramdisk using the newrd script, and then uncompress and untar the package file into it at top-level (e.g., tar zxvf foo.tar.gz). Then use mkrd and burn it into the flash via the monitor as usual. |
![]() |
|
The Itsy Project
is a joint effort of the Western Research Lab and the Systems Research Center