On Thursday, October 12, 2017, Nicolas Pitre wrote: > Small embedded systems typically execute the kernel code in place (XIP) > directly from flash to save on precious RAM usage. This adds the ability > to consume filesystem data directly from flash to the cramfs filesystem > as well. Cramfs is particularly well suited to this feature as it is > very simple and its RAM usage is already very low, and with this feature > it is possible to use it with no block device support and even lower RAM > usage. > > This patch was inspired by a similar patch from Shane Nay dated 17 years > ago that used to be very popular in embedded circles but never made it > into mainline. This is a cleaned-up implementation that uses far fewer > ifdef's and gets the actual memory location for the filesystem image > via MTD at run time. In the context of small IoT deployments, this > functionality has become relevant and useful again. > > Signed-off-by: Nicolas Pitre <n...@linaro.org> > --- > fs/cramfs/Kconfig | 30 +++++++- > fs/cramfs/inode.c | 215 +++++++++++++++++++++++++++++++++++++++++++------ > -----
Works! I first applied the MTD patch series from here: http://patchwork.ozlabs.org/project/linux-mtd/list/?series=7504 Then this v6 patch series on top of it. I created a mtd-rom/direct-mapped partition and was able to both mount after boot, and also boot as the rootfs. Log from booting as rootfs: [ 1.586625] cramfs: checking physical address 0x1b000000 for linear cramfs image [ 1.594512] cramfs: linear cramfs image on mtd:rootfs_xipcramfs appears to be 15744 KB in size [ 1.603619] VFS: Mounted root (cramfs filesystem) readonly on device 31:1. $ cat /proc/self/maps 00008000-000a1000 r-xp 1b005000 1f:01 18192 /bin/busybox 000a9000-000aa000 rw-p 00099000 1f:01 18192 /bin/busybox 000aa000-000ac000 rw-p 00000000 00:00 0 [heap] b6e07000-b6ee0000 r-xp 00000000 1f:01 766540 /lib/libc-2.18-2013.10.so b6ee0000-b6ee8000 ---p 000d9000 1f:01 766540 /lib/libc-2.18-2013.10.so b6ee8000-b6eea000 r--p 000d9000 1f:01 766540 /lib/libc-2.18-2013.10.so b6eea000-b6eeb000 rw-p 000db000 1f:01 766540 /lib/libc-2.18-2013.10.so b6eeb000-b6eee000 rw-p 00000000 00:00 0 b6eee000-b6f05000 r-xp 00000000 1f:01 670372 /lib/ld-2.18-2013.10.so b6f08000-b6f09000 rw-p 00000000 00:00 0 b6f0a000-b6f0c000 rw-p 00000000 00:00 0 b6f0c000-b6f0d000 r--p 00016000 1f:01 670372 /lib/ld-2.18-2013.10.so b6f0d000-b6f0e000 rw-p 00017000 1f:01 670372 /lib/ld-2.18-2013.10.so bedb0000-bedd1000 rw-p 00000000 00:00 0 [stack] bedf4000-bedf5000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] So far, so good. Thank you! Tested-by: Chris Brandt <chris.bra...@renesas.com>
