This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Linux synthetic target & JFFS2
- From: Andrew Lunn <andrew at lunn dot ch>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 19 Aug 2003 13:29:55 +0200
- Subject: Re: [ECOS] Linux synthetic target & JFFS2
- References: <850597605E79D21182830008C7A4B9CF1EB4263B@COMM1>
On Tue, Aug 12, 2003 at 06:35:22PM +0200, Koeller, T. wrote:
> Hi,
>
> playing with the JFFS2 flash file system on the Linux
> synthetic target I noticed that the option
> CYGSEM_FLASH_SYNTH_FILE_WRITEBACK is not honored -
> the file is written to even with this option turned
> off. I also tried to remove write permission from the
> file, but then the mmap() fails and the program does not
> even start.
Its all a bit weird.
cdl_option CYGSEM_FLASH_SYNTH_FILE_WRITEBACK {
display "FLASH changes modify the underlying file"
flavor booldata
default_value 0
description "
If enabled, changes made to the contents of the emulated
FLASH are reflected in the underlying file. Otherwise,
the file will be left unaffected by any changes the program
makes to FLASH contents."
}
This actually controls flags passed to mmap():
#ifdef CYGSEM_FLASH_SYNTH_FILE_WRITEBACK
CYG_HAL_SYS_MAP_SHARED
#else
CYG_HAL_SYS_MAP_PRIVATE
#endif
MAP_SHARED Share this mapping with all other processes
that map this object. Storing to the region is
equivalent to writing to the file. The file
may not actually be updated until msync(2) or
munmap(2) are called.
MAP_PRIVATE
Create a private copy-on-write mapping. Stores
to the region do not affect the original file.
If WRITEBACK is enabled, two synth processes would see the same FLASH
contents and changes you write directly to the mmap'ed memory are
written back to the file.
If WRITEBACK is disabled, the two synth processes have there own copy
of the file and changes directly to the memory should not be written
back.
This does not make sense because:
1) you don't directly write to flash memory. You write using the flash
API. The flash_progam_buf() function then does an lseek followed by
a write so modifying the file.
2) The mmap only passes PROT_READ. So any write to the mmap'ed memory
is going to cause a segfault! I did this deliberately so to catch
any dangling pointers etc, trying to scribble over the flash which
is always a bug.
This option was not part of my original contribution. I guess Jifl
added it. My contribution always was read/write since thats what a
FLASH does. Im not sure a read only flash makes sense. If a write
fails on a real system it means the component is damaged!
Why do you want read only flash?
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss