> brad@ltc.com said:
> > have maintained, on and off, a patch to crafms that supports
> > traditional cramfs decompress-and-read/run-from-RAM, plus direct
> > mmaping with no decompression and read/run straight out of ROM:
>
> > http://www.ltc.com/~brad/mips/cramfs-linear-root-xip-linux-2.4.9-2.diff
>
> + if (remap_page_range(vma->vm_start, KSEG0ADDR(address), length,
> + vma->vm_page_prot))
>
>
> Cute, but not very generic.
Yes, sorry, I should have mentioned that MIPSism in there. I haven't tried,
but I imagine it wouldn't be that hard to adjust for other platforms.
(In case anyone isn't familiar with KSEG0ADDR on MIPS, it takes a physical
address as it's only paramter and returns a cacheable virtual address in
"kernel address segment 0" (0x80000000 - 0xafffffff) which is hardwire 1:1
mapped with physical address space).
> The approach I was contemplating was to
> allocate a set of 'struct page's for the pages containing XIP data, then
> add those pages to the page cache manually on read_inode().
>
> It's a shame that ->readpage() doesn't get to say 'actually I used my own
> page for that, I didn't want one allocated for me'.
That sounds nice, but I cannot imagine how much trouble it would be to
implement.
> Extending the MTD API to return a set of pages representing a particular
> device, and handling the locking so that we don't try to write to the
chips
> while pages are mapped, will also be necessary if we want to do it with
> flash chips that are used for anything else.
Actually, I've used that patch on a system that had a cramfs/xip and a jffs
partition on the same flash chip where the kernel was running xip out of
flash. :-)
Regards,
Brad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/