Re: [PATCH]: uClinux (MMU-less) patches against 2.5.28

David Woodhouse
2002-07-26T08:16:06Z

gerg@snapgear.com said:
> You may have noticed some MAGIC_ROM_PTR patches in the mtd driver
> code in this patch. This is to allow XIP for applications. We have
> been support XIP for quite some time on uClinux, it works really well.

> A problem we have experienced with MTD is that the nature of
> asynchronous writing to FLASH does not play nice with apps runing XIP.
> Any thoughts on how to deal with this?

Other than burying my head in the sand and hoping that someone starts
making dual-port flash? Sort of...

XIP of the kernel makes it harder, of course -- writing to the chip you're
running the _kernel_ from turns your entire text segment into status words,
so really I can't see any alternative but to copy the flash manipulation
routines into RAM, disable all interrupts, and get on with it.

If we're talking about XIP of just userspace pages, I have a vague plan for
that which may be slightly more feasible. If it holds up to the cold light
of day, perhaps you can help adjust it to work with uClinux.

The plan is to hand out pages to be mapped into userspace (or indeed kernel
space -- JFFS2 can speed up mounts this way too), but which get marked
absent when the flash driver talks to the chip. If your applications then
take a page fault, you can either suspend the operation or just make them
wait till it's complete.

The actual implementation of this should be relatively simple. We can
provide a generic_mtd_vm_ops and the chip drivers just need to know about
an extra state for 'mapped' and have a method to enter that state, and a
callback for when they want to _leave_ that state. Oh, and a way to get the
raw physical address for a given range of flash.

It occurs to me that this doesn't work too well without an MMU though. Got
any better ideas? Could we disable entire processes when one of their pages
is inaccessible?

--
dwmw2