RE: [PATCH v6 1/4] cramfs: direct memory access support

[Chris Brandt <Chris.Brandt@renesas.com>]

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 <nico@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.brandt@renesas.com>


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>