This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]