Allen Black

Problem with DirectFB (Multi App Core) on Coldfire

Discussion created by Allen Black on Jul 2, 2009
Latest reply on Jul 6, 2009 by Allen Black
I'm seeing an issue when I try to run any DirectFB (Multi Application Core) application (with Fusion library and the linux-fusion kernel module) on a Coldfire MCF5484. The processor is on a custom board that is based on and similar to Freescale's M5485EVB board. This is the same board (and same project) that has been mentioned in many of jkimble's posts to this forum. We are using Freescale's Coldfire M547X_8X BSP (released 7/2008 with 2.6.25 kernel) with LTIB for our development.

NOTE: You may notice that the DirectFB version in the printout below shows v1.4.0. Initially I was using v1.1.0 (the version that comes with the M547X_8X BSP's LTIB). It behaved exactly the same in all respects to version 1.4.0. It's also important to know the version of the linux-fusion kernel module that I have been using. When working with DFB v1.1.0, I was using linux-fusion v7.0.1. And currently while working with DFB v1.4.0 I'm using linux-fusion v8.1.1 (these are both the most recent version available).The linux-fusion kernel module is NOT normally included in the 2.6.25 kernel that comes with the M547X_8X BSP so it was obtained directly from the directfb.org website (and added manually to the kernal tree which was then rebuilt by LTIB).

By looking at the Fusion library source code and the debugging messages (shown below). It looks like a successful call to mmap() is being followed by a segfault when the first access is attempted on the newly mapped shared memory area.

root@freescale:/usr/local/UCP# ./UCP_GUI --dfb:debug
[  NO NAME         0.000] (  383) Direct/Main:        direct_initialize() called...
[  NO NAME         0.013] (  383) Direct/Thread:          direct_thread_set_name( 'Main Thread' )
[  NO NAME         0.022] (  383) Direct/Thread:            -> attaching unknown thread 383
[  NO NAME         0.031] (  383) Direct/Mem:                   +   110 bytes [thread.c:369 in direct_thread_set_name()]
[  NO NAME         0.043] (  383) Direct/Mem:                   +    12 bytes [thread.c:386 in direct_thread_set_name()] -> 0x80379188 "             "
[Main Thread       0.059] (  383) Direct/Main:        ...initializing now.
[Main Thread       0.067] (  383) Direct/Signals:         Initializing...

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.0 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2009  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

[Main Thread       0.077] (  383) DirectFB/Core:      dfb_core_create...
[Main Thread       0.109] (  383) Direct/Main:            direct_initialize() called...
[Main Thread       0.118] (  383) Direct/Main:            ...2 references now.
(*) DirectFB/Core: Multi Application Core. (2009-06-30 19:16) [ DEBUG ][ TRACE ]
[Main Thread       0.136] (  383) Direct/Modules:         direct_modules_explore_directory( 'systems' )
[Main Thread       0.153] (  383) Direct/Mem:                   +    44 bytes [modules.c:229 in direct_modules_explore_directory()]
[Main Thread       0.166] (  383) Direct/Mem:                   +    21 bytes [modules.c:237 in direct_modules_explore_directory()] -> 0x8037a2b0 "  "
[Main Thread       0.203] (  383) Direct/Modules:             Loading '/usr/lib/directfb-1.4-0/systems/libdirectfb_fbdev.so'...
[Main Thread       0.241] (  383) Direct/Modules:                 Registering 'fbdev' ('systems')...
[Main Thread       0.252] (  383) Direct/Mem:                           +     6 bytes [modules.c:134 in direct_modules_register()] -> 0x8037a658 "   "
[Main Thread       0.268] (  383) Direct/Modules:                 ...registered.
[Main Thread       0.276] (  383) Direct/Mem:                   +    44 bytes [modules.c:229 in direct_modules_explore_directory()]
[Main Thread       0.289] (  383) Direct/Mem:                   +    22 bytes [modules.c:237 in direct_modules_explore_directory()] -> 0x8037a698 "  "
[Main Thread       0.306] (  383) Direct/Modules:             Loading '/usr/lib/directfb-1.4-0/systems/libdirectfb_devmem.so'...
[Main Thread       0.329] (  383) Direct/Modules:                 Registering 'devmem' ('systems')...
[Main Thread       0.339] (  383) Direct/Mem:                           +     7 bytes [modules.c:134 in direct_modules_register()] -> 0x8037aa40 "   "
[Main Thread       0.356] (  383) Direct/Modules:                 ...registered.
[Main Thread       0.367] (  383) Direct/Mem:               +    42 bytes [core.c:297 in dfb_core_create()]
[Main Thread       0.379] (  383) Direct/Mem:               +    24 bytes [thread.c:113 in direct_thread_add_init_handler()]
[Main Thread       0.392] (  383) Fusion/Main:            fusion_enter( 0, 45, 0x8037a9b4 )
(*) Fusion/SHM: Using MADV_REMOVE (2.6.25.0 >= 2.6.19.2)
[Main Thread       0.410] (  383) Direct/Main:                direct_initialize() called...
[Main Thread       0.419] (  383) Direct/Main:                ...3 references now.
[Main Thread       0.432] (  383) Fusion/Main:              -> Fusion ID 0x00000001
[Main Thread       0.443] (  383) Fusion/Main:              -> shared area at 0x20000000, size 2300
[  383:    0.453] --> Caught signal 11 (at 0x20000004, invalid permissions) <--
[  383: -STACK- ]
  #0  0x800e1eec in signal_handler () from /usr/lib/libdirect-1.4.so.0 [0x800d2000]
  #1  0x80102680 in fusion_enter () from /usr/lib/libfusion-1.4.so.0 [0x800f8000]
  #2  0x8019aa8c in dfb_core_create () from /usr/lib/libdirectfb-1.4.so.0 [0x80120000]
[Main Thread       0.642] (  383) Fusion/Main:                fusion_fork_handler_prepare()
[Main Thread       0.678] (  383) Fusion/Main:                fusion_fork_handler_parent()
[Main Thread       0.701] (  384) Fusion/Main:                fusion_fork_handler_child()
sh: line 1: nm: command not found
  #3  0x800014d8 in DirectFBCreate () from ./UCP_GUI [0x80000000]

Aborted


Below is the code segment from the Fusion library (a part of the DirectFB package, not to be confused with the linux-fusion kernel module) file "fusion.c". The "mmap" call is obviously successful from looking at the debugging messages. But I believe the segfault occurs several lines below that, when the first attempt is made to access (write to) the shared memory area. I'm guessing there may be an architecture dependent virtual memory issue here. Or I may be completely off base with that guess.

     if (id == FUSION_ID_MASTER) {
          int shared_fd;
         
          snprintf( buf, sizeof(buf), "%s/fusion.%d.core",
                    fusion_config->tmpfs ? : "/dev/shm", world_index );
          
          /* Open shared memory file. */        
          shared_fd = open( buf, O_RDWR | O_CREAT | O_TRUNC, 0660 );
          if (shared_fd < 0) {
               D_PERROR( "Fusion/Init: Couldn't open shared memory file!\n" );
               ret = DR_INIT;
               goto error;
          }

          if (fusion_config->shmfile_gid != (gid_t)-1) {
               if (fchown( shared_fd, -1, fusion_config->shmfile_gid ) != 0)
                    D_INFO( "Fusion/Init: Changing owner on %s failed... continuing on.\n", buf );
          }
        
          fchmod( shared_fd, 0660 );
          ftruncate( shared_fd, sizeof(FusionWorldShared) );
         
          /* Map shared area. */
          shared = mmap( (void*) 0x20000000 + 0x2000 * world_index, sizeof(FusionWorldShared),
                         PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, shared_fd, 0 );
          if (shared == MAP_FAILED) {
               D_PERROR( "Fusion/Init: Mapping shared area failed!\n" );
               close( shared_fd );
               ret = DR_INIT;
               goto error;
          }
         
          close( shared_fd );
         
          D_DEBUG_AT( Fusion_Main, "  -> shared area at %p, size %zu\n", shared, sizeof(FusionWorldShared) );
         
          /* Initialize reference counter. */
          shared->refs = 1;
         
          /* Set ABI version. */
          shared->world_abi = abi_version;


I should mention that Single Application Core DirectFB applications (both version 1.1.0 and 1.4.0) worked perfectly fine. It's only when we "./configure --enable-multi" and build DirectFB as a Multi Application Core that we are seeing problems.

I have several questions:

1. - Has anyone ever used DirectFB in Multi Application Core mode on a Coldfire?
2. - Does anyone know the significance of address 0x20000000 in the mmap() call in "fusion.c"? And if this might collide with something architecturally significant in the Coldfire's VM implementation?
3. - And obviously, can anyone help provide some insight to what I've described above?

Thanks!
Allen

Outcomes