RE: [ECOS] Linux synthetic target & JFFS2

["Koeller, T." <Thomas dot Koeller at baslerweb dot com>]

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