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
