Message-ID: <SG2PR06MB1165E8DC60659449C24DD6B68A820@SG2PR06MB1165.apcprd06.prod.outlook.com>
Date:   Wed, 16 Aug 2017 11:08:30 +0000
From:   Chris Brandt <Chris.Brandt@...esas.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
CC:     Alexander Viro <viro@...iv.linux.org.uk>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/5] cramfs refresh for embedded usage

On Wednesday, August 16, 2017, Nicolas Pitre wrote:
> > Yes, now I can boot with my rootfs being a XIP cramfs.
> >
> > However, like you said, libc is not XIP.
> 
> I think I have it working now. Probably learned more about the memory
> management internals than I ever wanted to know. Please try the patch
> below on top of all the previous ones. If it works for you as well then
> I'll rebase and repost the whole thing.
> 
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 4c7f01fcd2..0b651f985c 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c


Yes, that worked. Very nice!

$ cat /proc/self/maps
00008000-000a1000 r-xp 1b005000 00:0c 18192      /bin/busybox
000a9000-000aa000 rw-p 00099000 00:0c 18192      /bin/busybox
000aa000-000ac000 rw-p 00000000 00:00 0          [heap]
b6e23000-b6efc000 r-xp 1b0bc000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6efc000-b6f04000 ---p 1b195000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6f04000-b6f06000 r--p 000d9000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6f06000-b6f07000 rw-p 000db000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6f07000-b6f0a000 rw-p 00000000 00:00 0
b6f0a000-b6f21000 r-xp 1b0a4000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6f24000-b6f25000 rw-p 00000000 00:00 0
b6f26000-b6f28000 rw-p 00000000 00:00 0
b6f28000-b6f29000 r--p 00016000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6f29000-b6f2a000 rw-p 00017000 00:0c 670372     /lib/ld-2.18-2013.10.so
be877000-be898000 rw-p 00000000 00:00 0          [stack]
beba9000-bebaa000 r-xp 00000000 00:00 0          [sigpage]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]


Just FYI,
I'm running an xipImage with all the RZ/A1 upstream drivers enabled and 
only using about 4.5MB of total system RAM.
That's pretty good. Of course for a real application, you would trim off
the drivers and subsystems you don't plan on using, thus lowering your
RAM usage.


> +/*
> + * It is possible for cramfs_physmem_mmap() to partially populate the
> mapping
> + * causing page faults in the unmapped area. When that happens, we need
> to
> + * split the vma so that the unmapped area gets its own vma that can be
> backed
> + * with actual memory pages and loaded normally. This is necessary
> because
> + * remap_pfn_range() overwrites vma->vm_pgoff with the pfn and
> filemap_fault()
> + * no longer works with it. Furthermore this makes /proc/x/maps right.
> + * Q: is there a way to do split vma at mmap() time?
> + */


So if I understand correctly, the issue is that sometimes you only have 
a partial PAGE worth that you need to map. Correct?

For the AXFS file system, XIP page mapping was done on a per page 
decision, not per file. So the mkfs.axfs tool would only mark a page as XIP if
the entire section would fit in a complete PAGE. If for example you had
a partial page at the end of a multi page code segment, it would put 
that partial page in a separate portion of the AXFS image and be marked as
'copy to RAM' instead of being marked as 'map as XIP'.
So in the AXFS case, it was a combination of the creation tool and file 
system driver features to fix the partial page issue.
Not sure if any of this info is relevant, but I thought I would mention 
anyway.


Thank you for your efforts on adding XIP to cramfs!


Chris

Powered by blists - more mailing lists