Flash Management and JFFS2 File System |
Linux provides management of the on-module NOR Flash, including the ability to partition the physical Flash onto separate logical partitions and mount a JFFS2 flash filesystem on a Flash partition. The Flash management and JFFS2 filesystem require enabling appropriate kernel options in the kernel configuration and adding certain device nodes and Linux tools to the target file system. The rootfs project included in the Emcraft distribution at projects/rootfs provides a sample Linux configuration that has the Flash management and JFFS2 functionality fully enabled. The examples in the text below make use of the rootfs project. Linux splits the external Flash onto several partitions. Even though the partitioning is purely logical in the software, the user view is that each Flash partition can be accessed as a separate "Flash disk" device, independent of the other Flash partitions. Each Flash partitioned can be accessed as a "raw" disk or, alternatively, a Flash file system can be mounted on a partition. The Flash partitioning is defined in project/rootfs/rootfs.dts.STM32F7: nor_flash { The flash layout included in the distribution provides a reasonable Flash partitioning for the on-module Flash device, however, depending on your application needs, you might want to change the number and size of configured Flash partitions. When Linux boots on the target, there will be the following messages in the kernel print-out indicating that the Flash driver is enabled and then describing the specific partitions created by the kernel: physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 In the above example, the first partition is used to hold the U-Boot environment variables. The second partition is allocated to the bootable Linux image (uImage). Finally, the third partition is dedicated to the JFFS2 file system. Let's start with creating a JFFS2 file system on the third partition. The following command erases the Flash partition and marks it up as a JFFS2 file system. JFFS2 provides transparent management of bad blocks and Flash wearing capabilities ensuring the robustness and longevity of the file system in Flash. Notice use of the -j flag as the indication to flash_eraseall that the partition must not only be erased but also marked up for JFFS2: / # flash_eraseall -j /dev/mtd2 Now everything is ready to mount a JFFS2 file system on that partition. As expected, the initial file system is empty: / # mkdir /m Let's add some files to the JFFS2 file system and validate that they are correct. In the example below, we copy the busybox binary from the initramfs root file system to Flash and then run it from Flash: / # cp /bin/busybox /m Now, let's reboot the system and make sure that any updates we make in the JFFS2 are indeed persistent: / # reboot -f As a next step, let's update the Linux uImage in the second partition from a host directory mounted over NFS. This provides a simple demonstration of a possible software upgrade sequence using a Linux image pulled from the network. First step is to prepare the partition for a new uImage by erasing the Flash: / # flash_eraseall /dev/mtd1 Let's mount the host directory over NFS and copy a prebuilt uImage to Flash. In this example, we install the Linux image for the rebuilt rootfs project: / # mount -o nolock 192.168.1.102:/mnt/work/emcraft/bsp/nfs /mnt Now, we are ready to reboot and validate the target is indeed running the newly installed Linux project: / # reboot -f
|