This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Linux synthetic target & JFFS2
- From: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- To: 'Andrew Lunn' <andrew at lunn dot ch>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 19 Aug 2003 14:06:15 +0200
- Subject: RE: [ECOS] Linux synthetic target & JFFS2
This seems to be a misunderstanding. I understand that the
option in question controls whether writing to the memory region
(the simulated flash) modifies the underlying file as well, just
like the description says. I am not talking about the effects of
running two synth processes in parallel, nor do I want the simulated
flash to be read-only. I also do not quite understand why someone
would use lseek() or other File-I/O functions if the file is
memory mapped.
tk
-----------------------------------------------
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:Thomas.Koeller@baslerweb.com
http://www.baslerweb.com
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Tuesday, August 19, 2003 1:30 PM
> To: Koeller, T.
> Cc: ecos-discuss (E-Mail)
> Subject: Re: [ECOS] Linux synthetic target & JFFS2
>
>
> 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