[uClinux-dev] XIP broken in 2.4.31-uc0 ? (fwd)

David McCullough davidm at snapgear.com
Sat Oct 8 01:28:42 EDT 2005

Jivin David Howells lays it down ...
> David McCullough <davidm at snapgear.com> wrote:
> > Not currently,  this is still working with the old romptr code in
> > conjunction with the new mmap stuff.
> It should be possible to dispense with the romptr op, at least in the 2.6
> kernel.

I fully intend to get rid of it in 2.4 as well,  but we are in the last
stages of a release and a lot of people rely on XIP working,  so a
complete re-implementation at this stage didn't seem the ideal time :-)

> You should be able to do it by:
>  (1) Return the address at which the data lives through the
>      file->f_op->get_unmapped_area() operation.
>  (2) Set:
> 		- Can't write back to ROM.
> 		- Copying the data is permitted for MAP_PRIVATE/PROT_WRITE.
> 		- Mapping the data in place is permitted for
>                   MAP_SHARED/PROT_READ.
> 		- PROT_READ is permissible directly.
> 		- PROT_EXEC is permissible directly.
>      In the capabilities field of the backing_dev_info structure pointed to by
>      the address_space (i_host) - you should only need one of these for an
>      entire mount, and should be able to share them.
> > A question for you though, romfs could be on a disk, ram, flash or any
> > number of things.  It could only report membacked if the device it is
> > running on is membacked.  Does this point towards membacked being a function
> > rather than a boolean ?
> No. I think it's invariant for a file, and so can be set when the inode and
> the address_space is created.

Yep,  I sort of figured that below.

> > romfs may be able to determine membacked at mount/init time I guess by
> > checking the underlying device.  I haven't looked at it in detail yet, but
> > it might save me some time if you know the answer off the top of your head
> > :-)
> Yes. You should be able to find out by looking in the address_space attached
> to the inode attached to the blockdev - if you have a blockdev. I assumed
> ROMFS would be like JFFS2 or NFS, but I suppose that isn't required.

romfs runs on top of a block device of some kind,  so this sounds like
the way to go.  When I get some cycles I'll look at cleaning up 2.4 and
getting XIP into 2.6 using this mechanism,


David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com

More information about the uClinux-dev mailing list