Robert Hildinger wrote: > Greetings All, > > I have been attempting to build DirectFB 1.1.1 on an embedded ARM-based > platform similar in many respects to TI’s DaVinci platform. Everything > is up and running well in single-application mode, but the switch to > multi-app mode is giving me some fits. I can get the fusion kernel > driver compiled and installed without issue, as well as the multi-app > code within DirectFB itself. The problem comes at runtime with the > execution of the mmap() command during shared memory pool creation, > which fails everytime. The fact that the mmap() calls request a fixed > address starting at 0x20000000 appears to be the heart of the problem, > although perhaps it is the actual memory map of the platform that is at > issue. At any rate, I have tried fixed address of all types in the > format 0xX0000000 to no avail.
There are two places where this has to be changed. One is in user space in lib/fusion/fusion.c which you changed I guess. The other is in the kernel module to reserve the virtual address range for shared memory pools. In linux/drivers/char/fusion/shmpool.h: #ifdef __x86_64__ #define FUSION_SHM_BASE 0x523000010000 /* virtual base address */ #define FUSION_SHM_SIZE 0x000FFFFEF000 /* size of virtual address space */ #else #ifdef __mips__ #define FUSION_SHM_BASE 0x50010000 /* virtual base address */ #else #define FUSION_SHM_BASE 0x20010000 /* virtual base address */ #endif #define FUSION_SHM_SIZE 0x1FFEF000 /* size of virtual address space */ #endif > I’ve also tried the following test: I modified the mmap() calls to use a > NULL address and thus have the OS give back an address, ran the code, > and recorded the address given back. I then put mmap() calls back the > way they were (using a fixed address) and used the address given back by > the first run as the actual fixed address. This worked for first couple > of calls, but soon the memory pool creation requests were asking for > areas that were too large and that ultimately failed as well. Probably you just need to change the second location as well. > Please note that the platform I’m working on is an embedded system and > thus does not have a large amount of memory (128 MB to be exact). I’m > sure there are others of you that have run into this problem in getting > multi-app support up and running on your embedded platforms, and I’d > really like to know how you solved this issue. Could it be an issue with > the way virtual memory is set up on the platform? Any other possibilities? There should be an area of 256MB that could be used. Please pick one process in /proc and take a look at the addresses used already, e.g. [EMAIL PROTECTED] cat /proc/12017/maps 00400000-004be000 r-xp 00000000 08:01 375406 /bin/bash 006bd000-006c7000 rw-p 000bd000 08:01 375406 /bin/bash 006c7000-009b3000 rw-p 006c7000 00:00 0 [heap] 7f7f10a19000-7f7f10a23000 r-xp 00000000 08:01 383608 /lib/libnss_files-2.7.so 7f7f10a23000-7f7f10c23000 ---p 0000a000 08:01 383608 /lib/libnss_files-2.7.so 7f7f10c23000-7f7f10c25000 rw-p 0000a000 08:01 383608 /lib/libnss_files-2.7.so 7f7f10c25000-7f7f10c2f000 r-xp 00000000 08:01 383618 /lib/libnss_nis-2.7.so 7f7f10c2f000-7f7f10e2e000 ---p 0000a000 08:01 383618 /lib/libnss_nis-2.7.so 7f7f10e2e000-7f7f10e30000 rw-p 00009000 08:01 383618 /lib/libnss_nis-2.7.so 7f7f10e30000-7f7f10e46000 r-xp 00000000 08:01 383602 /lib/libnsl-2.7.so 7f7f10e46000-7f7f11045000 ---p 00016000 08:01 383602 /lib/libnsl-2.7.so 7f7f11045000-7f7f11047000 rw-p 00015000 08:01 383602 /lib/libnsl-2.7.so 7f7f11047000-7f7f11049000 rw-p 7f7f11047000 00:00 0 7f7f11049000-7f7f11051000 r-xp 00000000 08:01 383604 /lib/libnss_compat-2.7.so 7f7f11051000-7f7f11250000 ---p 00008000 08:01 383604 /lib/libnss_compat-2.7.so 7f7f11250000-7f7f11252000 rw-p 00007000 08:01 383604 /lib/libnss_compat-2.7.so 7f7f11252000-7f7f113aa000 r-xp 00000000 08:01 383558 /lib/libc-2.7.so 7f7f113aa000-7f7f115aa000 ---p 00158000 08:01 383558 /lib/libc-2.7.so 7f7f115aa000-7f7f115ad000 r--p 00158000 08:01 383558 /lib/libc-2.7.so 7f7f115ad000-7f7f115af000 rw-p 0015b000 08:01 383558 /lib/libc-2.7.so 7f7f115af000-7f7f115b4000 rw-p 7f7f115af000 00:00 0 7f7f115b4000-7f7f115b6000 r-xp 00000000 08:01 383575 /lib/libdl-2.7.so 7f7f115b6000-7f7f117b6000 ---p 00002000 08:01 383575 /lib/libdl-2.7.so 7f7f117b6000-7f7f117b8000 rw-p 00002000 08:01 383575 /lib/libdl-2.7.so 7f7f117b8000-7f7f117ef000 r-xp 00000000 08:01 383599 /lib/libncurses.so.5.6 7f7f117ef000-7f7f119ee000 ---p 00037000 08:01 383599 /lib/libncurses.so.5.6 7f7f119ee000-7f7f119f3000 rw-p 00036000 08:01 383599 /lib/libncurses.so.5.6 7f7f119f3000-7f7f11a10000 r-xp 00000000 08:01 383538 /lib/ld-2.7.so 7f7f11bf6000-7f7f11bf8000 rw-p 7f7f11bf6000 00:00 0 7f7f11c0d000-7f7f11c10000 rw-p 7f7f11c0d000 00:00 0 7f7f11c10000-7f7f11c12000 rw-p 0001d000 08:01 383538 /lib/ld-2.7.so 7fff19bfd000-7fff19c12000 rw-p 7ffffffea000 00:00 0 [stack] 7fff19dfe000-7fff19e00000 r-xp 7fff19dfe000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
