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
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:24 EST