https://elinux.org/api.php?action=feedcontributions&user=Andreme&feedformat=atomeLinux.org - User contributions [en]2024-03-28T13:09:55ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=File_Systems&diff=7657File Systems2008-11-11T09:09:41Z<p>Andreme: Layout change</p>
<hr />
<div>This page has information about file systems which are of interest for embedded projects.<br />
<br />
== Introduction ==<br />
Most embedded devices use [http://en.wikipedia.org/wiki/Flash_memory flash memory] as storage media.<br />
Also, size and bootup time are very important in many consumer electronics products. Therefore, <br />
special file systems are often used with differrent features, such as enhanced compression, or<br />
the ability to execute files directly from flash.<br />
<br />
=== MTD ===<br />
Note that flash memory may be managed by the Memory Technology Devices (MTD) system of Linux. See the [http://www.linux-mtd.infradead.org/faq/general.html MTD/Flash FAQ] for more information. Most of the <br />
filesystems mentioned here are built on top of the MTD system.<br />
<br />
=== UBI ===<br />
The [http://www.linux-mtd.infradead.org/doc/ubi.html Unsorted Block Images] (UBI) system in the Linux kernel<br />
manages multiple logical volumes on a single flash device.<br />
It provides a mapping from logical blocks to physical erase blocks, via the MTD layer.<br />
UBI provides a flexible partitioning concept which allows for wear-leveling across the whole flash device.<br />
<br />
See the [http://www.linux-mtd.infradead.org/doc/ubi.html UBI] page or<br />
[http://www.linux-mtd.infradead.org/faq/ubi.html UBI FAX and Howto] for more information.<br />
<br />
=== Partitioning ===<br />
The kernel requires at least one "root" file system, onto which<br />
other file systems can be mounted. In non-embedded systems, often only a single <br />
file system is used. However, in order to optimize limited resources (flash, RAM,<br />
processor speed, boot up time), many embedded systems<br />
break the file system into separate parts, and put each part on it's own partition (often in<br />
different kinds of storage.<br />
<br />
For example, a developer may wish to take all the read-only files of the system, and put<br />
them into a compressed, read-only file system in flash. This will consume the least amount<br />
of space on flash, at the cost of some read-time performance (for decompression).<br />
<br />
Another configuration might have executable files stored uncompressed on flash, so that<br />
they can be executed-in-place, which saves RAM and boot-up time (with a potential small<br />
loss of performance).<br />
<br />
For writable data, if the data does not need to be persistent, sometimes a ramdisk<br />
is used. Depending on the performance needs and the RAM limits, the file data may be<br />
compressed or not.<br />
<br />
There is no single standard for interleaving the read-only and read-write portions of the<br />
file system. This depends heavily on the set of embedded applications used for the<br />
project.<br />
<br />
== Embedded Filesystems ==<br />
Here are some filesystems designed for and/or commonly used in embedded devices, sorted in alphabetical order:<br />
<br />
=== AXFS ===<br />
*[[AXFS]] - Advanced XIP File System<br />
** Website: http://axfs.sourceforge.net/<br />
** This file system is designed specifically to support Execute-in-place operations. It uses a bi-phased approach. The first phase is to have the filesystem in flash and run it to collect profile data, stating what pages are used. In the second phase you build a filesystem using these profile data. This filesystem makes all pages metioned in the profile file as XIP data, which can then will be loaded to RAM upon mounting (and executed as XIP). It is also possible to put the XIP pages in NOR flash and run them from there.<br />
<br />
=== CramFS === <br />
*[http://en.wikipedia.org/wiki/Cramfs CRAMFS] - A compressed read-only file system for Linux. The maximum size of CRAMFS is 256MB.<br />
** "Linear Cramfs" is the name of a special feature to use uncompressed file, in a linear block layout with the Cramfs file system. This is useful for storing files which can be executed in-place. For more information on Linear Cramfs, see [[Application XIP]]<br />
<br />
=== JFFS2 ===<br />
* [http://sourceware.org/jffs2/ JFFS2] - The Journalling Flash File System, version 2. This is the most commonly used flash filesystem.<br />
** The maximum size of JFFS2 is 128MB.<br />
** http://sourceforge.net/projects/mtd-mods has some patches by Alexey Korolev for improvements to JFFS2 <br />
*** See the presentation on Alexey's patches at:<br />
** To improve mount time substantially verify that the erase block summary patch is in your image. This patch is part of the jffs2 driver since 2005-09-07. A patch for an earlier version can be found at: http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch (or try your luck at http://web.archive.org/web/*/http://www.inf.u-szeged.hu/jffs2/mount.php).<br />
<br />
=== LogFS ===<br />
*[http://logfs.org/logfs/ logfs] - LogFS is a scalable flash filesystem. It is aimed to replace<br />
JFFS2 for most uses, but focuses more on the large devices.<br />
<br />
Matt Mackall writes (in July of 2007):<br />
<br />
LogFS is a filesystem designed to support large volumes on FLASH. It<br />
uses a simple copy-on-write update process to ensure consistency (the<br />
"log" in the name is a historical artifact). It's easily the most<br />
modern and scalable open-source FLASH filesystem available for Linux<br />
and it's well on its way to being accepted in the mainline tree.<br />
<br />
Scott Preece writes:<br />
<br />
The big win for LogFS (in my limited knowledge of it) is that it stores<br />
its tree structure in the media, rather than building it in memory at<br />
mount time. This significantly reduces both startup time and memory<br />
consumption. This becomes more important as the size of the flash device<br />
increases. Read more in LWN (http://lwn.net/Articles/234441) and<br />
linux.com (http://www.linux.com/articles/114295).<br />
<br />
Some newer flash memory, like MLC (multi-level cell), are not well supported.<br />
<br />
LogFS now has it's own mailing list: see http://logfs.org/cgi-bin/mailman/listinfo/logfs<br />
<br />
=== NFS ===<br />
Due to space constraints on embedded devices, it is common during development to use<br />
a network file system for the root filesystem for the target. This allows the target to<br />
have a very large area where full-size binaries and lots of development tools can be placed<br />
during development. One drawback to this approach is that the system will need to<br />
be re-configured with local file systems (and most likely re-tested) for final<br />
product shipment, at some time during the development cycle.<br />
<br />
An NFS client can be built into the Linux kernel, and the kernel<br />
can be configured to use NFS as the root filesystem. This requires support for networking,<br />
and mechanisms for specifying the IP address for the target, and the path to the filesystem<br />
on the NFS host. Also, the host must be configured to run an NFS server. Often, the host<br />
also provides the required address and path information to the target board by running<br />
a DHCP server.<br />
<br />
See the the file Documentation/nfsroot.txt in the Linux kernel source for more information<br />
about mounting an NFS root filesystem with the kernel.<br />
<br />
=== PRAMFS ===<br />
*[http://pramfs.sourceforge.net/ PRAMFS] - Persistent and protected RAM File System<br />
The Persistent/Protected RAM Special Filesystem (PRAMFS) is a full-featured read/write filesystem that has been designed to work with fast I/O memory, and if the memory is non-volatile, the filesystem will be persistent. In addition, it has Execute-in-place support.<br />
<br />
=== Romfs ===<br />
* [http://romfs.sourceforge.net RomFs] - A small space-efficient read-only filesystem. A description can be found in Documentation/filesystems/romfs.txt or http://lxr.linux.no/linux/Documentation/filesystems/romfs.txt<br />
<br />
=== SquashFS ===<br />
*[[Squash Fs]] - A (more) compressed read-only file system for Linux. This file system has better compression than JFFS2 or CRAMFS.<br />
<br />
It is possible to tune the amount of compression when running mksquashfs. The -b option allows you to specify the block size. A smaller block size generally gives less compression and a larger -b option gives more compression. However there is a downside to this. Data is read from the flash using blocks. So if you use a block size of 128k, and you need a page of 4k, still the compressed equivalent of 128k data will be read from flash. As 128k comprises 32 pages, it will result in 32 pages being read into the buffer cache, even though at the moment of reading you only need one. Often the other 31 pages will be needed as well, but if not you wasted some tiem to read and decompress the unused data. Also you got some unneeded data in the buffer cache (possibly the system even had to kick used pages from the cache in order to make room for these 31 pages).<br />
<br />
If you care for the smallest filesystem you probably want to go with the largest block size. However, if your primary concern is performance you might want to experiment a little bit to see what works out best for you (and that could even be applying no compression at all! Mksquashfs has options: -noInodeCompression, -noDataCompression and –noFragmentCompression to control this). If you also applied function reordering (see [[Boot Time#User-space and application speedups]] a large block size will probably work out well for you.<br />
<br />
The table below gives an idea of the amount of compression that is achieved by the various block sizes. Input was a root filesystem of an embedded device. <br />
<br />
{|border="1" cellpadding="5" cellspacing="0"<br />
|-bgcolor="#0090ff"<br />
! !! size || compression<br />
|-<br />
| Initial || 53128K || 100 %<br />
|-<br />
| 4K || 17643K || 33.2 %<br />
|-<br />
| 8K || 16572K || 31.2 %<br />
|-<br />
| 16K || 15780K || 29.7 %<br />
|-<br />
| 32K || 15204K || 28.6 %<br />
|-<br />
| 64K || 14812K || 27.9 %<br />
|-<br />
|}<br />
<br />
=== YAFFS2 ===<br />
*[http://www.yaffs.net/yaffs-overview YAFFS] - Yet Another Flash File System - a file system designed specifically for NAND flash.<br />
<br />
YAFFS2 is simple, portable, reliable and self-contained. It is widely used in embedded OSes other than Linux, and can also be used stand-alone without an OS, e.g. in bootloaders. When used with Linux it can use MTD or its own flash driver. Similarly it can use the VFS or its own posix layer. It is log-structured, and single-threaded. It does not do compression itself - either compress the data itself or use squashfs on top of YAFFS2. <br />
<br />
YAFFS2 is designed to boot quickly (insofar as a log-structured FS that has to scan the flash can). It uses checkpointing so that if a partition was unmounted cleanly then there is no need to rescan the flash on power-up. All the features of the FS are configuable so you can trade off things like maximum file/partition size, flash block size, file granulaity etc. Data is written straight through to the flash except for caching to ensure efficienct use of blocks. YAFFS2 normally uses the OOB are of the flash for its metadata, allowing faster booting as only the OOB needs to be read for flash scan. It can keep its metadata inside the main page area at the expense of some speed.<br />
<br />
Despite having been in use on Linux in real products since 2004 it has not yet made it to the mainline. <br />
<br />
** Presentation on YAFFS2 by Wookey at ELC Europe 2007: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=get&target=yaffs.pdf yaffs.pdf]<br />
** Presentation from CELF Jamboree 17 comparing YAFFS and JFFS2 on 2.6.10: [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17?action=AttachFile&do=view&target=celf_flashfs.pdf celf_flash.pdf]<br />
<br />
YAFFS2 is GPLed, but is also available under dual-licensing terms for use in non-free contexts from Aleph One Ltd.<br />
<br />
==== YAFFS vs. JFFS2 mount time comparisons for 2.6.10 ====<br />
Here are some core results for mount times. (See the Toshiba Jamboree17 presentation for details.)<br />
<br />
* hardware: MIPS, 333 MHZ CPU, with 64 MB NAND Flash.<br />
* kernel: 2.6.10 +EBS patch +YAFFS (20061128 version).<br />
** JFFS2 compression option is disabled.<br />
* Key:<br />
** “Initial”: Time for mounting when the mount is just after launching “flash_eraseall”.<br />
** "1000 files”: Time for mounting after creating 1000 files (one file size is 33554 bytes.)<br />
** “JFFS2+EBS” needs to check EBS, and then it does start to scan the blocks normally. Therefore, “Initial” mount time is a little bit slow.<br />
<br />
{|border="1" cellpadding="5" cellspacing="0"<br />
|-bgcolor="#0090ff"<br />
! !! JFFS2 !! JFFS2+EBS !! YAFFS<br />
|-<br />
| Initial || 0.93 sec || 1.12 sec || 0.27 sec<br />
|-<br />
| 1000 files|| 7.34 sec || 1.06 sec || 2.52 sec<br />
|-<br />
|}<br />
<br />
It is unclear whether or not these data are made with a jffs2 driver that has the erase block summary patch applied. This patch is part of the jffs2 driver since 2005-09-07. A patch for an earlier version can be found at: http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch (or try your luck at http://web.archive.org/web/*/http://www.inf.u-szeged.hu/jffs2/mount.php).<br />
<br />
== Mounting the root filesystem ==<br />
The root filesystem is mounted by the kernel, using a kernel command line option.<br />
Other file systems are mounted from user space, usually by init scripts or an <br />
init program, using the 'mount' command.<br />
<br />
The following are examples of command lines used for mounting a root filesystem<br />
with Linux:<br />
<br />
* Use the first partition on the first IDE hard drive:<br />
** root=/dev/hda1<br />
* or in later kernels:<br />
** root=/dev/sda1<br />
<br />
* Use NFS root filesystem (kernel config must support this)<br />
**root=/dev/nfs<br />
<br />
(Usually you need to add some other arguments to make sure<br />
the kernel IP address gets configured, or to specify the<br />
host NFS path.)<br />
<br />
* Use flash device partition 2:<br />
** root=/dev/mtdblock2<br />
<br />
[FIXTHIS - should probably mention initrd's here somewhere]<br />
<br />
=== Mounting JFFS2 image on PC using mtdram ===<br />
Since it is not possible to use the loopback device to mount JFFS2 images, mtdram needs to be used instead. Usually three modules are needed to get it working:<br />
<br />
* mtdram: Provides an MTD partition in RAM. The size can be defined with the total_size parameter.<br />
<br />
* mtdblock: This will create a block device for access to the partition.<br />
<br />
* jffs2: Since JFFS2 is usually not used as a filesystem on a PC, support needs to be loaded manually.<br />
<br />
modprobe mtdram total_size=16384 <br />
modprobe mtdblock <br />
modprobe jffs2 <br />
<br />
Depending on the target's endianess the image file might need conversion to PC endianess. jffs2dump from the MTD tools can be used to archive this. <br />
<br />
jffs2dump -b -c -e <output-filename> <input-filename><br />
<br />
The final image can be copied to the block device using dd.<br />
<br />
dd if=<image-file> of=/dev/mtdblock0<br />
<br />
Mounting is done in the usuall way.<br />
<br />
mount /dev/mtdblock0 /tmp/jffs2 -t jffs2<br />
<br />
== Special-purpose Filesystems ==<br />
=== ABISS ===<br />
The Active Block I/O Scheduling System is a file system designed to be able to provide real-time <br />
features for file system I/O activities.<br />
<br />
See [http://abiss.sourceforge.net/ ABISS]<br />
<br />
=== Layered Filesystems ===<br />
Layered filesystems enable you to mount read-only media and still have the possibility to write to it. At least, the writing part will end up somewhere else, which is transparantly handled by the layered filesystem. It has been around for quite some time and below are some examples of filesystems already usable on (embedded) Linux systems out-of-the-box.<br />
<br />
==== UnionFS ====<br />
Sometimes it is handy to be able to overlay file systems on top of each other.<br />
For example, it can be useful in embedded products to use a compressed read-only<br />
file system, mounted "underneath" a read/write file system. This give the<br />
appearance of a full read-write file system, while still retaining the<br />
space savings of the compressed file system, for those files that won't<br />
change during the life of the product.<br />
<br />
UnionFS is a project to provide such a system (providing a "union" of multiple<br />
file systems).<br />
<br />
See http://www.filesystems.org/project-unionfs.html<br />
<br />
See also union mounts, which are described at http://lkml.org/lkml/2007/6/20/18<br />
(and also in Documentation/union-mounts.txt in the kernel source tree - or will be, when this feature<br />
is merged.)<br />
<br />
==== aufs ====<br />
Another UnionFS. Go to http://aufs.sourceforge.net for more details.<br />
<br />
==== mini_fo ====<br />
Go to http://www.denx.de/wiki/Know.MiniFOHome for more details<br />
<br />
== Other projects ==<br />
=== Multi-media file systems ===<br />
* XPRESS file system - [See OLS 2006 proceedings, presentation by Joo-Young Hwang]<br />
** I found out at ELC 2007 that this FS project was recently suspended internally at Samsung<br />
<br />
<br />
[[Category:File Systems| ]]</div>Andremehttps://elinux.org/index.php?title=Toolbox&diff=7656Toolbox2008-11-11T09:03:16Z<p>Andreme: Fixed typo</p>
<hr />
<div>This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.<br />
<br />
== Development Tools ==<br />
=== Toolchains ===<br />
* see [[Toolchains]]<br />
=== Debuggers ===<br />
* [http://openocd.berlios.de/web/ Open On-Chip Debugger]<br />
* FIXTHIS - need link for debuggers (DDD, gdb, kgdb, etc.)eclipse<br />
<br />
=== Integrated Development Environments === <br />
* [http://www.eclipse.org Eclipse] - Powerfull IDE written in JAVA.<br />
* [http://www.jedit.org jEdit] - Editor written in JAVA which can be expanded to a full IDE with plug-ins.<br />
* [http://www.kdevelop.org KDevelop] - Standard IDE for KDE.<br />
<br />
* FIXTHIS - need more links for IDEs<br />
<br />
=== Tracers and Profilers ===<br />
* see [[Kernel Trace Systems]]<br />
<br />
=== Benchmarks ===<br />
* see [[Benchmark Programs]]<br />
<br />
=== Source Management Tools ===<br />
There are a number of tools for managing patches, which are useful for different tasks.<br />
There's now a whole page devoted to this. See [[Source Management Tools]]<br />
<br />
For some simple tools for managing patches, see [[Diff And Patch Tricks]]<br />
<br />
=== Test Systems ===<br />
* See [[Test Systems]]<br />
<br />
== Developer Resources ==<br />
=== Kernel mailing lists, web sites, etc. ===<br />
* See [[Linux Kernel Resources]]<br />
<br />
=== Documentation ===<br />
==== Online ====<br />
* Linux Device Drivers, 3rd edition - http://lwn.net/Kernel/LDD3/<br />
* Papers from the Ottawa Linux Symposium - broken out - see http://kernel.org/doc/ols/<br />
* Embedded Linux kernel and driver development - http://free-electrons.com/training/drivers<br />
* Free Software tools for embedded systems - http://free-electrons.com/training/devtools<br />
* Real time in embedded Linux systems - http://free-electrons.com/articles/realtime/<br />
* Embedded Linux optimizations - http://free-electrons.com/articles/optimizations<br />
* Audio in embedded Linux systems - http://free-electrons.com/training/audio<br />
* Multimedia in embedded Linux systems - http://free-electrons.com/training/multimedia<br />
* Embedded Linux From Scratch... in 40 minutes! - http://free-electrons.com/articles/elfs/<br />
<br />
==== Books ====<br />
* Embedded Linux System Design and Development - by P. Raghavan, Amol Lad, and Sriram Neelakandan (Hardcover - Dec 21, 2005)<br />
** This one looks quite good.<br />
* Embedded Linux Primer: A Practical Real-World Approach - by Christopher Hallinan<br />
** So does this one.<br />
* Building Embedded Linux Systems - by Karim Yaghmour<br />
** This book is a bit dated (the edition I have is from 2003, but it is still a great resource.<br />
<br />
=== Code Style Tips ===<br />
* This section is for good [[Code Styling Tips]]<br />
<br />
=== Debugging Tips ===<br />
* See the [[Kernel Debugging Tips]] page<br />
* See also [[Debugging Makefiles]]<br />
<br />
=== GCC Tips and Tricks ===<br />
* This section of [[GCC Tips]] is a collection of tips and tricks helpful for embedded developers<br />
<br />
== Embedded Linux Distributions ==<br />
* see [[Embedded Linux Distributions]]<br />
[[Category:Development Tools]]</div>Andremehttps://elinux.org/index.php?title=Toolbox&diff=7655Toolbox2008-11-11T09:00:49Z<p>Andreme: Added Eclipse, jEdit and KDevelop</p>
<hr />
<div>This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.<br />
<br />
== Development Tools ==<br />
=== Toolchains ===<br />
* see [[Toolchains]]<br />
=== Debuggers ===<br />
* [http://openocd.berlios.de/web/ Open On-Chip Debugger]<br />
* FIXTHIS - need link for debuggers (DDD, gdb, kgdb, etc.)eclipse<br />
<br />
=== Integrated Development Environments === <br />
* [http://www.eclipse.org Eclipse] - Powerfull IDE written in JAVA.<br />
* [http://www.jedit.org jEdit] - Editor written in JAVE which can be expanded to a full IDE with plug-ins.<br />
* [http://www.kdevelop.org KDevelop] - Standard IDE for KDE.<br />
<br />
* FIXTHIS - need more links for IDEs<br />
<br />
=== Tracers and Profilers ===<br />
* see [[Kernel Trace Systems]]<br />
<br />
=== Benchmarks ===<br />
* see [[Benchmark Programs]]<br />
<br />
=== Source Management Tools ===<br />
There are a number of tools for managing patches, which are useful for different tasks.<br />
There's now a whole page devoted to this. See [[Source Management Tools]]<br />
<br />
For some simple tools for managing patches, see [[Diff And Patch Tricks]]<br />
<br />
=== Test Systems ===<br />
* See [[Test Systems]]<br />
<br />
== Developer Resources ==<br />
=== Kernel mailing lists, web sites, etc. ===<br />
* See [[Linux Kernel Resources]]<br />
<br />
=== Documentation ===<br />
==== Online ====<br />
* Linux Device Drivers, 3rd edition - http://lwn.net/Kernel/LDD3/<br />
* Papers from the Ottawa Linux Symposium - broken out - see http://kernel.org/doc/ols/<br />
* Embedded Linux kernel and driver development - http://free-electrons.com/training/drivers<br />
* Free Software tools for embedded systems - http://free-electrons.com/training/devtools<br />
* Real time in embedded Linux systems - http://free-electrons.com/articles/realtime/<br />
* Embedded Linux optimizations - http://free-electrons.com/articles/optimizations<br />
* Audio in embedded Linux systems - http://free-electrons.com/training/audio<br />
* Multimedia in embedded Linux systems - http://free-electrons.com/training/multimedia<br />
* Embedded Linux From Scratch... in 40 minutes! - http://free-electrons.com/articles/elfs/<br />
<br />
==== Books ====<br />
* Embedded Linux System Design and Development - by P. Raghavan, Amol Lad, and Sriram Neelakandan (Hardcover - Dec 21, 2005)<br />
** This one looks quite good.<br />
* Embedded Linux Primer: A Practical Real-World Approach - by Christopher Hallinan<br />
** So does this one.<br />
* Building Embedded Linux Systems - by Karim Yaghmour<br />
** This book is a bit dated (the edition I have is from 2003, but it is still a great resource.<br />
<br />
=== Code Style Tips ===<br />
* This section is for good [[Code Styling Tips]]<br />
<br />
=== Debugging Tips ===<br />
* See the [[Kernel Debugging Tips]] page<br />
* See also [[Debugging Makefiles]]<br />
<br />
=== GCC Tips and Tricks ===<br />
* This section of [[GCC Tips]] is a collection of tips and tricks helpful for embedded developers<br />
<br />
== Embedded Linux Distributions ==<br />
* see [[Embedded Linux Distributions]]<br />
[[Category:Development Tools]]</div>Andremehttps://elinux.org/index.php?title=Processors&diff=7641Processors2008-11-10T13:14:28Z<p>Andreme: Added link to linux-mips.org</p>
<hr />
<div>Here is a list of different processor families, with miscellaneous notes for development information:<br />
<br />
See also [[Hardware Hacking]] for a list of systems that include these processors.<br />
<br />
== ARM ==<br />
See [http://www.arm.com ARM website] and the [http://en.wikipedia.org/wiki/ARM_architecture Wikipedia ARM article] for information about the ARM architecture and processor family.<br />
<br />
From the Linux perspective, there are 2 very different kinds of ARM chips:<br />
* ARM processors that include a memory management unit (MMU), and can run standard Linux<br />
* ARM processors without MMU. These can run a modified version of Linux called uClinux ( http://uclinux.org/ ), enabling Linux to run on MMUless platforms or embedded processors with memory protection unit (MPU). These include ARM processors such as ARM7TDMI, ARM1156T2(F)-S or ARM Cortex-R4(F) for instance. <br />
<br />
Please note that because of security considerations for MMU-less processors, it is unwise to <br />
use them when 3rd-party or untrusted code will be running on the device. For locked-down, single<br />
function devices, MMU-less processors may be appropriate. They are usually less expensive than processors<br />
with MMU.<br />
<br />
Some major ARM platforms/SOCs are:<br />
* [[DaVinci]] from [http://www.ti.com/corp/docs/landing/davinci/firstproducts.html Texas Instruments]<br />
* OMAP - by TI<br />
* i.MX - by FreeScale<br />
** Freescale's GIT repository for i.MX Linux support is at: http://opensource.freescale.com<br />
*** Info about this repository, as of April 2007 is at: http://www.spinics.net/lists/arm-kernel/msg39771.html<br />
* [http://www.arm.com/products/DevTools/Hardware_Platforms.html ARM RealView] platforms - by ARM Ltd. <br />
** Linux BSP and resources available at http://www.arm.com/linux with associated [http://www.linux-arm.org/git GIT tree]<br />
* XScale/PXA - by Marvell (formerly Intel) -- has MMU<br />
** PXA255/PXA26x - Cotulla/Dalhart<br />
** PXA27x - Bulverde<br />
** PXA3xx - Monahans family<br />
*** Linux PXA255/PXA26x/PXA27x BSPs are available in mainline kernel. You can find PXA3xx BSP from [http://www.marvell.com/ Marvell]. Marvell team is working hard to get PXA3xx patches accepted by the mainline.<br />
* Orion - by Marvell<br />
** Linux BSP for Orion-2 SoC available on [http://marc.info/?l=linux-arm-kernel&m=117869744222933&w=2 ARM Linux Mailing List].<br />
* Philips LPC21xx series of ARM processors are currently the lowest-cost ARM processors available. But they have no MMU.<br />
* [[JuiceBox]] uses a ARM S3C44B0X. It runs uClinux.<br />
* AT91 - by Atmel<br />
** [http://www.atmel.com/dyn/products/devices.asp?family_id=605#1393 AT91RM9200] - ARM920T based -- has MMU<br />
** [http://www.atmel.com/dyn/products/devices.asp?family_id=605#1739 AT91SAM9 Series] - ARM926EJ-S based -- has MMU<br />
** Linux gateway : [http://www.linux4sam.org www.linux4sam.org]<br />
* Cirrus Logic ([http://arm.cirrus.com/ Linux forum and download site])<br />
** EP73xx - ARM720T based<br />
** EP93xx - ARM920T based<br />
* Samsung System-on-Chip (SystemLSI gtoup)<br />
** S3C2410 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410], S3C2440 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2440], S3C2443 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2443] - ARM920T<br />
** S3C2416 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2416] - S3C2450 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2450], S3C2412 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2412], S3C2413 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2413] - ARM926EJS<br />
** S3C6400 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C6400], S3C6410 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C6410] - ARM1176EJS<br />
<br />
== MIPS ==<br />
Information about MIPS processor architecture can be found [http://www.mips.com here]. For the Linux port information can be found [http://www.linux-mips.org here].<br />
<br />
Processors based on MIPS architecture include<br />
# [http://www.toshiba.com/taec/Catalog/Family.do?familyid=5 TX System RISC] from Toshiba.<br />
# [http://www.pmc-sierra.com/mips-processors MSP series] of processor from PMC Sierra.<br />
<br />
== SuperH ==<br />
<br />
[[Image:Superh_logo.gif]]<br />
<br />
Built by [http://www.renesas.com/homepage.jsp Renesas Technology] the webpage of record for the SuperH family of microprocessors can be found here: [http://www.renesas.com/fmwk.jsp?cnt=superh_family_landing.jsp&fp=/products/mpumcu/superh_family/ SuperH RISC Engine Family].<br />
<br />
Wikipedia Page: [http://en.wikipedia.org/wiki/SuperH SuperH]<br />
<br />
Linux on SuperH: [http://linux-sh.org/shwiki/FrontPage linux-sh]<br />
<br />
=== Renesas SuperH Overview ===<br />
<br />
SuperH is an embedded RISC developed for high cost-performance, miniaturization, and performance per unit of power consumption (MIPS/W). We are developing CPU cores for a wide range of applications and functions and have many products available. Our product lines include a series with the SH-2 as the CPU core and on-chip large-capacity flash memory and peripheral functions such as timer, serial I/O, and AD converter, and a series with the SH-3 or SH-4 as the CPU core, which achieves high-speed data processing and is equipped with cache and MMU. Additionally, there is lineup of series with the SH2-DSP or SH3-DSP as the CPU core, which have full DSP functions and an emphasis on multimedia and communications processing. Currently available products also have lots of features, such as low power modes, low power consumption, and small size. Various versatile operating systems and development tools have been improved, allowing for more efficient development.<br />
<br />
=== Devices ===<br />
* Sega<br />
** [http://linux-sh.org/shwiki/Dreamcast Dreamcast] - Limited to the machine models that can start by MIL-CD and usage of a Broad Band Adapter is recommended.<br />
* Hitachi ULSI Systems<br />
** [http://linux-sh.org/shwiki/MS7206SE01 MS7206SE01] - SH72060 Solution Engine<br />
** MS7750SE01 - SH7750(sh4) Solution Engine<br />
** MS7709SE01 - SH7709(sh3) Solution Engine<br />
* SuperH, Inc.<br />
** ["MicroDev"]<br />
* HP Jornada<br />
** 525 (SH7709 (sh3))<br />
** 548 (SH7709A (sh3))<br />
** 620LX (SH7709 (sh3))<br />
** 660LX (SH7709 (sh3))<br />
** 680 (SH7709A (sh3))<br />
** 690 (SH7709A (sh3))<br />
* Renesas Technology Corp.<br />
** RTS7751R2D - CE Linux Forum(CELF)Compliant Evaluation Board<br />
* [http://www.shlinux.com Renesas Europe/MPC Data Limited]<br />
** EDOSK7705 - SH7705 sh3<br />
* EDOSK7760 - SH7760 sh4<br />
** EDOSK7751R - SH7751R sh4<br />
** SH7751R SystemH - SH7751R sh<br />
* [http://www.cqpub.co.jp/eda/CqREEK/SH4PCI.HTM CQ Publishing Co.,Ltd.]<br />
** CQ RISC Evaluation Kit(CqREEK)/SH4-PCI with Linux<br />
** [http://www.kmckk.co.jp/eng/ Kyoto Microcomputer Co., Ltd. (KMC or KμC)<br />
** Solution Platform KZP-01 KZP-01[Mainboard] + KZ-SH4RPCI-01[SH4 CPU Board]<br />
* [http://www.si-linux.com/index.html Silicon Linux Co,. Ltd.]<br />
** CAT760 - SH7760<br />
** CAT709 - SH7709S<br />
** CAT68701 - SH7708R For A-one CATBUS[Designed for 68000 board] compliant<br />
* [http://dsn-net.net/product/list_shlinux.html Daisen Electronic Industrial Co., Ltd.]<br />
** SH2000 - SH7709A 118MHz<br />
** SH2002 - SH7709S 200MHz<br />
** SH-500 - SH7709S 118MHz<br />
** SH-1000 - SH7709S 133MHz<br />
** SH-2004 - SH7750R 240MHz<br />
* [http://www.iodata.jp/prod/storage/hdd/index_lanhdd.htm IO-DATA DEVICE, Inc.(Network Attached Storage [NAS] Series)]<br />
** LAN-iCN - NAS Adapter for IODATA HDD with "i-connect" Interface<br />
** LAN-iCN2"] - NAS Adapter for IODATA HDD with "i-connect" Interface<br />
** LANDISK"] - SH4-266MHz[FSB133MHz] RAM64MB UDMA133 USB x2 10/100Base-T<br />
*** HDL-xxxU - LANDISK Series NAS Standard Model<br />
*** HDL-xxxUR - LANDISK with RICOH IPSiO G series print monitor for Windows support <br />
*** HDL-WxxxU - LANDISK with wide body & twin drive support for Heavy storage or RAID1<br />
*** HDL-AV250 - LANDISK with Home Network DLNA guideline support<br />
*** LANTank - LANDISK kit SuperTank(CHALLENGER) Series<br />
**** HDL-WxxxU based twin drive bulk NAS kit. LANTank have a special feature that supported network media server(cf. iTunes etc..).<br />
* [http://www.e-linux.jp/tmm_index.html TOWA MECCS CORPORATION]<br />
** TMM1000 - SH7709<br />
** TMM1100 - (SH7727<br />
** TMM1200 - SH7727<br />
* [http://www.sophia-systems.co.jp/ice/eval_board/index.html Sophia Systems]<br />
** Sophia SH7709A Evaluation Board<br />
** Sophia SH7750 Evaluation Board<br />
** Sophia SH7751 Evaluation Board<br />
* [http://www.movingeye.co.jp/mi6/sh4board.html MovingEye Inc.]<br />
** A3pci7003 - Using SH7750/ART-Linux [Linux with Realtime Extension]<br />
* [http://www.apnet.co.jp/product/ms104/ms104-sh4.html AlphaProject Co., Ltd.]<br />
** MS104-SH4 - SH7750R/PC104(Embedded ISA Bus) with apLinux<br />
* [http://www.interface.co.jp/cpu/ Interface Corporation.]<br />
** MPC-SH02 - SH7750S: ATX Motherboard Style<br />
** PCI-SH02xx"] - SH7750S: PCI-CARD Style<br />
* [http://www.tacinc.jp/ TAC Inc.]<br />
** [http://web.kyoto-inet.or.jp/people/takagaki/T-SH7706/T-SH7706.htm T-SH7706LAN] another name "Mitsuiwa SH3 board" SH-MIN - SH7706A/128MHz Flash512KB SDRAM 8MB 10BASE-T<br />
* [http://www.securecomputing.com/ SecureComputing]/[http://www.snapgear.org/ SnapGear] (older products, check ebay etc, all can netboot and have a debug header)<br />
** [http://www.snapgear.org/ SG530] - SH7751@166MHz RAM16MB FLASH4MB 2x10/100 1xSerial<br />
** [http://www.snapgear.org/ SG550] - SH7751@166MHz RAM16MB FLASH8MB 2x10/100 1xSerial<br />
** [http://www.snapgear.org/ SG570] - SH7751R@240MHz RAM16MB FLASH8MB 3x10/100 1xSerial<br />
** [http://www.snapgear.org/ SG575] - SH7751R@240MHz RAM64MB FLASH16MB 3x10/100 1xSerial<br />
** [http://www.snapgear.org/ SG630] - SH7751@166MHz PCI NIC card RAM16MB FLASH4MB 1x10/100 1xSerial-header<br />
** [http://www.snapgear.org/ SG635] - SH7751R@240MHz PCI NIC card RAM16MB FLASH16MB 1x10/100 1xSerial-header<br />
<br />
== PowerPC ==<br />
For Linux embedded applications requiring Floating Point in a SOC the MPC5200 is hard to beat.<br />
<br />
Freescale's highly integrated, cost-effective [http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200&fpsp=1&tab=Documentation_Tab MPC5200] is well suited for networking, media, industrial control, and automotive applications. It delivers 760 MIPS with a Floating Point Unit (FPU), hardware Memory Management Unit (MMU) for fast task switching, is packed with I/O, and operates at only one watt. The MPC5200 serves the processing-intensive network media gateway, network access storage, set-top box, audio jukebox automotive, Internet access, industrial automation, image detection/analysis, and electronic/medical instrumentation markets. With its successful foundation in the automotive/telematics market via the mobileGT™ alliance and platforms, all markets can now enjoy extended temperature, automotive qualification, and life cycles typically demanded in that industry. A solid choice of Real Time Operating Systems (RTOS) and development boards with Board Support Packages (BSPs) provides users with a complete and flexible set of solutions.<br />
<br />
Product Highlights<br />
<br />
The MPC5200 is based on a 400 MHz MPC603e PowerPC core with an integrated double precision Floating Point Unit (FPU) that is qualified at -40oC to +85oC. It incorporates a hardware-based memory management unit (MMU) for advanced memory protection schemes, fast task switching and broad RTOS support. The MPC5200 was designed for fast data throughput and processing. The integrated BestComm DMA controller offloads the main MPC603e core from I/O intensive data transfers. An integrated Double Data Rate (DDR) memory controller accelerates data access with an effective memory bus speed of 266 MHz. A high-speed PCI interface backed by the BestComm DMA controller and DDR memory support enables high-speed data transfers in and out of the MPC5200.<br />
<br />
* MPC603e series PowerPC™ processor core<br />
* 0-400 MHz operation at -40oC to +85oC temperature range<br />
* Double Precision Floating Point Unit (FPU)<br />
* Instruction and Data Memory Management Unit (MMU)<br />
* 16K Instruction and 16K Data Caches<br />
* BestComm Intelligent DMA I/O Controller<br />
* SDR and 133 MHz Double Data Rate (DDR) memory interface (266 MHz effective)<br />
* Local Plus interface for flash memory, etc.<br />
* 10/100 Ethernet MAC<br />
* Peripheral Control Interface (PCI) Version 2.2<br />
* ATA/IDE Interface<br />
* USB 1.1 Host (two each. USB 2.0 compatible)<br />
* Programmable Serial Controllers (six)<br />
* Serial Peripheral Interface (SPI)<br />
* I2C (two)<br />
* I2S (up to three)<br />
* CAN 2.0 A/B (two)<br />
* J1850 BDLC-D<br />
* GPIO (up to 56)<br />
* 8 Timers<br />
* 1.5V core, 3.3V external (and 2.5V for DDR memory)<br />
* 272 Pin Plastic Pin Ball Grid Array (PBGA) Package<br />
* AEC-Q100, QS9000/TS-16949 automotive grade available<br />
* Lead (Pb) and lead-free packages<br />
<br />
The DENX Embedded Linux Development Kit (ELDK) provides a complete and powerful software development environment for embedded and real-time systems. It is available for ARM, PowerPC and MIPS processors and consists of:<br />
<br />
* Cross Development Tools (Compiler, Assembler, Linker etc.) to develop software for the target system.<br />
* Native Tools (Shell, commands and libraries) which provide a standard Linux development environment that runs on the target system.<br />
* Firmware that can be easily ported to new boards and processors.<br />
* Linux kernel including the complete source-code with all device drivers, board-support functions etc.<br />
* RTAI (Real Time Application Interface) Extension for systems requiring hard real-time responses.<br />
* SELF (Simple Embedded Linux Framework) as fundament to build your embedded systems on.<br />
<br />
All components of the ELDK are available for free with complete source code under GPL and other Free Software Licenses. Also, detailed instructions to rebuild all the tools and packages from scratch are included.<br />
<br />
The ELDK can be downloaded for free from several mirror sites or ordered on CD-ROM for a nominal charge (99 Euro). To order the CD please contact office@denx.de<br />
<br />
Detailed information about the ELDK is available [http://www.denx.de/wiki/DULG/ELDK here]. <br />
<br />
== XScale ==<br />
CE2110 Media Processor<br />
* [http://www.intel.com/design/celect/2110/ CE2110 Media Processor]<br />
The highly integrated Intel CE 2110 Media Processor helps to simplify the design of consumer electronics products with reduced BOM cost. The integrated Intel XScale® processor core at 1GHz provides processing performance and headroom to deploy new revenue-generating applications. Hardware-based decode of widely used video codecs (MPEG-2, H.264) maximizes system-level performance by enabling the processor core to be used exclusively for applications.<br />
<br />
The Intel CE 2110 Media Processor also includes an Intel® Micro Signal Architecture (Intel® MSA) DSP core for audio codecs, a PowerVR* 2D/3D graphics accelerator, hardware accelerators for encryption and decryption, comprehensive peripheral interfaces, analog and digital input/outputs, and a transport interface for ATSC/DVB input.<br />
<br />
* The Intel CE 2110 Media Processor Development Platform is designed to reduce time-to-market for new applications.<br />
* The Intel CE 2110 Media Processor reference platform provides the foundation for rapid development of new customer designs and product demonstrations.<br />
<br />
== x86 ==<br />
<br />
* Geode from [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330,00.html AMD]<br />
:* AMD Geode GX / CS5535<br />
:* AMD Geode LX / CS5536<br />
<br />
[[Category:NeedsEditing]]<br />
[[Category:Processors| ]]</div>Andremehttps://elinux.org/index.php?title=File_Systems&diff=7638File Systems2008-11-10T12:58:19Z<p>Andreme: Added instructions to mount JFFS2 image on PC</p>
<hr />
<div>This page has information about file systems which are of interest for embedded projects.<br />
<br />
== Introduction ==<br />
Most embedded devices use [http://en.wikipedia.org/wiki/Flash_memory flash memory] as storage media.<br />
Also, size and bootup time are very important in many consumer electronics products. Therefore, <br />
special file systems are often used with differrent features, such as enhanced compression, or<br />
the ability to execute files directly from flash.<br />
<br />
=== MTD ===<br />
Note that flash memory may be managed by the Memory Technology Devices (MTD) system of Linux. See the [http://www.linux-mtd.infradead.org/faq/general.html MTD/Flash FAQ] for more information. Most of the <br />
filesystems mentioned here are built on top of the MTD system.<br />
<br />
=== UBI ===<br />
The [http://www.linux-mtd.infradead.org/doc/ubi.html Unsorted Block Images] (UBI) system in the Linux kernel<br />
manages multiple logical volumes on a single flash device.<br />
It provides a mapping from logical blocks to physical erase blocks, via the MTD layer.<br />
UBI provides a flexible partitioning concept which allows for wear-leveling across the whole flash device.<br />
<br />
See the [http://www.linux-mtd.infradead.org/doc/ubi.html UBI] page or<br />
[http://www.linux-mtd.infradead.org/faq/ubi.html UBI FAX and Howto] for more information.<br />
<br />
=== Partitioning ===<br />
The kernel requires at least one "root" file system, onto which<br />
other file systems can be mounted. In non-embedded systems, often only a single <br />
file system is used. However, in order to optimize limited resources (flash, RAM,<br />
processor speed, boot up time), many embedded systems<br />
break the file system into separate parts, and put each part on it's own partition (often in<br />
different kinds of storage.<br />
<br />
For example, a developer may wish to take all the read-only files of the system, and put<br />
them into a compressed, read-only file system in flash. This will consume the least amount<br />
of space on flash, at the cost of some read-time performance (for decompression).<br />
<br />
Another configuration might have executable files stored uncompressed on flash, so that<br />
they can be executed-in-place, which saves RAM and boot-up time (with a potential small<br />
loss of performance).<br />
<br />
For writable data, if the data does not need to be persistent, sometimes a ramdisk<br />
is used. Depending on the performance needs and the RAM limits, the file data may be<br />
compressed or not.<br />
<br />
There is no single standard for interleaving the read-only and read-write portions of the<br />
file system. This depends heavily on the set of embedded applications used for the<br />
project.<br />
<br />
== Embedded Filesystems ==<br />
Here are some filesystems designed for and/or commonly used in embedded devices:<br />
=== JFFS2 ===<br />
* [http://sourceware.org/jffs2/ JFFS2] - The Journalling Flash File System, version 2. This is the most commonly used flash filesystem.<br />
** The maximum size of JFFS2 is 128MB.<br />
** http://sourceforge.net/projects/mtd-mods has some patches by Alexey Korolev for improvements to JFFS2 <br />
*** See the presentation on Alexey's patches at:<br />
** To improve mount time substantially verify that the erase block summary patch is in your image. This patch is part of the jffs2 driver since 2005-09-07. A patch for an earlier version can be found at: http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch (or try your luck at http://web.archive.org/web/*/http://www.inf.u-szeged.hu/jffs2/mount.php).<br />
<br />
=== CramFS === <br />
*[http://en.wikipedia.org/wiki/Cramfs CRAMFS] - A compressed read-only file system for Linux. The maximum size of CRAMFS is 256MB.<br />
** "Linear Cramfs" is the name of a special feature to use uncompressed file, in a linear block layout with the Cramfs file system. This is useful for storing files which can be executed in-place. For more information on Linear Cramfs, see [[Application XIP]]<br />
<br />
=== romfs ===<br />
* [http://romfs.sourceforge.net RomFs] - A small space-efficient read-only filesystem. A description can be found in Documentation/filesystems/romfs.txt or http://lxr.linux.no/linux/Documentation/filesystems/romfs.txt<br />
<br />
=== SquashFS ===<br />
*[[Squash Fs]] - A (more) compressed read-only file system for Linux. This file system has better compression than JFFS2 or CRAMFS.<br />
<br />
It is possible to tune the amount of compression when running mksquashfs. The -b option allows you to specify the block size. A smaller block size generally gives less compression and a larger -b option gives more compression. However there is a downside to this. Data is read from the flash using blocks. So if you use a block size of 128k, and you need a page of 4k, still the compressed equivalent of 128k data will be read from flash. As 128k comprises 32 pages, it will result in 32 pages being read into the buffer cache, even though at the moment of reading you only need one. Often the other 31 pages will be needed as well, but if not you wasted some tiem to read and decompress the unused data. Also you got some unneeded data in the buffer cache (possibly the system even had to kick used pages from the cache in order to make room for these 31 pages).<br />
<br />
If you care for the smallest filesystem you probably want to go with the largest block size. However, if your primary concern is performance you might want to experiment a little bit to see what works out best for you (and that could even be applying no compression at all! Mksquashfs has options: -noInodeCompression, -noDataCompression and –noFragmentCompression to control this). If you also applied function reordering (see [[Boot Time#User-space and application speedups]] a large block size will probably work out well for you.<br />
<br />
The table below gives an idea of the amount of compression that is achieved by the various block sizes. Input was a root filesystem of an embedded device. <br />
<br />
{|border="1" cellpadding="5" cellspacing="0"<br />
|-bgcolor="#0090ff"<br />
! !! size || compression<br />
|-<br />
| Initial || 53128K || 100 %<br />
|-<br />
| 4K || 17643K || 33.2 %<br />
|-<br />
| 8K || 16572K || 31.2 %<br />
|-<br />
| 16K || 15780K || 29.7 %<br />
|-<br />
| 32K || 15204K || 28.6 %<br />
|-<br />
| 64K || 14812K || 27.9 %<br />
|-<br />
|}<br />
<br />
=== YAFFS2 ===<br />
*[http://www.yaffs.net/yaffs-overview YAFFS] - Yet Another Flash File System - a file system designed specifically for NAND flash.<br />
<br />
YAFFS2 is simple, portable, reliable and self-contained. It is widely used in embedded OSes other than Linux, and can also be used stand-alone without an OS, e.g. in bootloaders. When used with Linux it can use MTD or its own flash driver. Similarly it can use the VFS or its own posix layer. It is log-structured, and single-threaded. It does not do compression itself - either compress the data itself or use squashfs on top of YAFFS2. <br />
<br />
YAFFS2 is designed to boot quickly (insofar as a log-structured FS that has to scan the flash can). It uses checkpointing so that if a partition was unmounted cleanly then there is no need to rescan the flash on power-up. All the features of the FS are configuable so you can trade off things like maximum file/partition size, flash block size, file granulaity etc. Data is written straight through to the flash except for caching to ensure efficienct use of blocks. YAFFS2 normally uses the OOB are of the flash for its metadata, allowing faster booting as only the OOB needs to be read for flash scan. It can keep its metadata inside the main page area at the expense of some speed.<br />
<br />
Despite having been in use on Linux in real products since 2004 it has not yet made it to the mainline. <br />
<br />
** Presentation on YAFFS2 by Wookey at ELC Europe 2007: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=get&target=yaffs.pdf yaffs.pdf]<br />
** Presentation from CELF Jamboree 17 comparing YAFFS and JFFS2 on 2.6.10: [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17?action=AttachFile&do=view&target=celf_flashfs.pdf celf_flash.pdf]<br />
<br />
YAFFS2 is GPLed, but is also available under dual-licensing terms for use in non-free contexts from Aleph One Ltd.<br />
<br />
==== YAFFS vs. JFFS2 mount time comparisons for 2.6.10 ====<br />
Here are some core results for mount times. (See the Toshiba Jamboree17 presentation for details.)<br />
<br />
* hardware: MIPS, 333 MHZ CPU, with 64 MB NAND Flash.<br />
* kernel: 2.6.10 +EBS patch +YAFFS (20061128 version).<br />
** JFFS2 compression option is disabled.<br />
* Key:<br />
** “Initial”: Time for mounting when the mount is just after launching “flash_eraseall”.<br />
** "1000 files”: Time for mounting after creating 1000 files (one file size is 33554 bytes.)<br />
** “JFFS2+EBS” needs to check EBS, and then it does start to scan the blocks normally. Therefore, “Initial” mount time is a little bit slow.<br />
<br />
{|border="1" cellpadding="5" cellspacing="0"<br />
|-bgcolor="#0090ff"<br />
! !! JFFS2 !! JFFS2+EBS !! YAFFS<br />
|-<br />
| Initial || 0.93 sec || 1.12 sec || 0.27 sec<br />
|-<br />
| 1000 files|| 7.34 sec || 1.06 sec || 2.52 sec<br />
|-<br />
|}<br />
<br />
It is unclear whether or not these data are made with a jffs2 driver that has the erase block summary patch applied. This patch is part of the jffs2 driver since 2005-09-07. A patch for an earlier version can be found at: http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch (or try your luck at http://web.archive.org/web/*/http://www.inf.u-szeged.hu/jffs2/mount.php).<br />
<br />
=== LogFS ===<br />
*[http://logfs.org/logfs/ logfs] - LogFS is a scalable flash filesystem. It is aimed to replace<br />
JFFS2 for most uses, but focuses more on the large devices.<br />
<br />
Matt Mackall writes (in July of 2007):<br />
<br />
LogFS is a filesystem designed to support large volumes on FLASH. It<br />
uses a simple copy-on-write update process to ensure consistency (the<br />
"log" in the name is a historical artifact). It's easily the most<br />
modern and scalable open-source FLASH filesystem available for Linux<br />
and it's well on its way to being accepted in the mainline tree.<br />
<br />
Scott Preece writes:<br />
<br />
The big win for LogFS (in my limited knowledge of it) is that it stores<br />
its tree structure in the media, rather than building it in memory at<br />
mount time. This significantly reduces both startup time and memory<br />
consumption. This becomes more important as the size of the flash device<br />
increases. Read more in LWN (http://lwn.net/Articles/234441) and<br />
linux.com (http://www.linux.com/articles/114295).<br />
<br />
Some newer flash memory, like MLC (multi-level cell), are not well supported.<br />
<br />
LogFS now has it's own mailing list: see http://logfs.org/cgi-bin/mailman/listinfo/logfs<br />
<br />
=== AXFS ===<br />
*[[AXFS]] - Advanced XIP File System<br />
** Website: http://axfs.sourceforge.net/<br />
** This file system is designed specifically to support Execute-in-place operations. It uses a bi-phased approach. The first phase is to have the filesystem in flash and run it to collect profile data, stating what pages are used. In the second phase you build a filesystem using these profile data. This filesystem makes all pages metioned in the profile file as XIP data, which can then will be loaded to RAM upon mounting (and executed as XIP). It is also possible to put the XIP pages in NOR flash and run them from there.<br />
<br />
=== PRAMFS ===<br />
*[http://pramfs.sourceforge.net/ PRAMFS] - Persistent and protected RAM File System<br />
The Persistent/Protected RAM Special Filesystem (PRAMFS) is a full-featured read/write filesystem that has been designed to work with fast I/O memory, and if the memory is non-volatile, the filesystem will be persistent. In addition, it has Execute-in-place support.<br />
<br />
=== NFS ===<br />
Due to space constraints on embedded devices, it is common during development to use<br />
a network file system for the root filesystem for the target. This allows the target to<br />
have a very large area where full-size binaries and lots of development tools can be placed<br />
during development. One drawback to this approach is that the system will need to<br />
be re-configured with local file systems (and most likely re-tested) for final<br />
product shipment, at some time during the development cycle.<br />
<br />
An NFS client can be built into the Linux kernel, and the kernel<br />
can be configured to use NFS as the root filesystem. This requires support for networking,<br />
and mechanisms for specifying the IP address for the target, and the path to the filesystem<br />
on the NFS host. Also, the host must be configured to run an NFS server. Often, the host<br />
also provides the required address and path information to the target board by running<br />
a DHCP server.<br />
<br />
See the the file Documentation/nfsroot.txt in the Linux kernel source for more information<br />
about mounting an NFS root filesystem with the kernel.<br />
<br />
== Mounting the root filesystem ==<br />
The root filesystem is mounted by the kernel, using a kernel command line option.<br />
Other file systems are mounted from user space, usually by init scripts or an <br />
init program, using the 'mount' command.<br />
<br />
The following are examples of command lines used for mounting a root filesystem<br />
with Linux:<br />
<br />
* Use the first partition on the first IDE hard drive:<br />
** root=/dev/hda1<br />
* or in later kernels:<br />
** root=/dev/sda1<br />
<br />
* Use NFS root filesystem (kernel config must support this)<br />
**root=/dev/nfs<br />
<br />
(Usually you need to add some other arguments to make sure<br />
the kernel IP address gets configured, or to specify the<br />
host NFS path.)<br />
<br />
* Use flash device partition 2:<br />
** root=/dev/mtdblock2<br />
<br />
[FIXTHIS - should probably mention initrd's here somewhere]<br />
<br />
=== Mounting JFFS2 image on PC using mtdram ===<br />
Since it is not possible to use the loopback device to mount JFFS2 images, mtdram needs to be used instead. Usually three modules are needed to get it working:<br />
<br />
* mtdram: Provides an MTD partition in RAM. The size can be defined with the total_size parameter.<br />
<br />
* mtdblock: This will create a block device for access to the partition.<br />
<br />
* jffs2: Since JFFS2 is usually not used as a filesystem on a PC, support needs to be loaded manually.<br />
<br />
> modprobe mtdram total_size=16384 <br />
<br />
> modprobe mtdblock <br />
<br />
> modprobe jffs2 <br />
<br />
Depending on the target's endianess the image file might need conversion to PC endianess. jffs2dump from the MTD tools can be used to archive this. <br />
<br />
> jffs2dump -b -c -e <output-filename> <input-filename><br />
<br />
The final image can be copied to the block device using dd.<br />
<br />
> dd if=<image-file> of=/dev/mtdblock0<br />
<br />
Mounting is done in the usuall way.<br />
<br />
> mount /dev/mtdblock0 /tmp/jffs2 -t jffs2<br />
<br />
== Special-purpose Filesystems ==<br />
=== ABISS ===<br />
The Active Block I/O Scheduling System is a file system designed to be able to provide real-time <br />
features for file system I/O activities.<br />
<br />
See [http://abiss.sourceforge.net/ ABISS]<br />
<br />
=== Layered Filesystems ===<br />
Layered filesystems enable you to mount read-only media and still have the possibility to write to it. At least, the writing part will end up somewhere else, which is transparantly handled by the layered filesystem. It has been around for quite some time and below are some examples of filesystems already usable on (embedded) Linux systems out-of-the-box.<br />
<br />
==== UnionFS ====<br />
Sometimes it is handy to be able to overlay file systems on top of each other.<br />
For example, it can be useful in embedded products to use a compressed read-only<br />
file system, mounted "underneath" a read/write file system. This give the<br />
appearance of a full read-write file system, while still retaining the<br />
space savings of the compressed file system, for those files that won't<br />
change during the life of the product.<br />
<br />
UnionFS is a project to provide such a system (providing a "union" of multiple<br />
file systems).<br />
<br />
See http://www.filesystems.org/project-unionfs.html<br />
<br />
See also union mounts, which are described at http://lkml.org/lkml/2007/6/20/18<br />
(and also in Documentation/union-mounts.txt in the kernel source tree - or will be, when this feature<br />
is merged.)<br />
<br />
==== aufs ====<br />
Another UnionFS. Go to http://aufs.sourceforge.net for more details.<br />
<br />
==== mini_fo ====<br />
Go to http://www.denx.de/wiki/Know.MiniFOHome for more details<br />
<br />
== Other projects ==<br />
=== Multi-media file systems ===<br />
* XPRESS file system - [See OLS 2006 proceedings, presentation by Joo-Young Hwang]<br />
** I found out at ELC 2007 that this FS project was recently suspended internally at Samsung<br />
<br />
<br />
[[Category:File Systems| ]]</div>Andreme