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

[gerg <gerg@snapgear.com>]

David Woodhouse wrote:
> 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. 

Not at all unresonable. I don't think there is any other real
alternative if you want your kernel running from flash, and
you want to write to flash.


> 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.

The MAGIC_ROM_PTR support in the uClinux patch adds a field to
the block_device_operations and file_operations structures that
allows getting at the physical address in 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?

Disabling processes that are known to be running direct from flash
sounds workable. (There is no real notion of separating pages under
uClinux - it is an all or nothing mapping. The text, data, bss, etc
are always a single contiguous region in the address space).

More generous lock that really required for general VM linux, but at
least the whole process model works for both VM and non-VM linux.
I would expect this avoids any potential loop/deadlock with pages
(going on the discussion in follow up emails anyway).

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com