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

[David Woodhouse <dwmw2@infradead.org>]

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