MCF5485EVB, Linux 2.6.25 kernel: MMap broken...

[jkimble]

I've been working with a frame buffer driver for this board for several weeks now and, after a lot of checking and rechecking, I find that calls to mmap with my pointer to /dev/fb0 returns an invalid (gdb reports "out of bounds") address. Direct ioctl calls work and calls from within the frame buffer driver work too. Only user space programs that use mmap (like nano-X...) fail and they always fail with a seg fault upon trying to write to the address returned by mmap.

I'm looking over /drivers/video/fbmem.c now and comparing it to the 2.6.10 version. Somethings obviously not right though...

Anyone have any experience with this? I'd be happy to show my examples.

[jkimble]

I'm not enough of a kernel expert to say either.  We were reduced to empiracal results and, since going to DirectFB, we've had 0 pixel corruption or seg fault behavior that couldn't be attributed to our application and fixed. We (5 of us) literally spent weeks looking at this. The group included a PhD that has extensive kernel experence and four VERY experienced Linux developers (driver and application level) and could never identify the issue.

I totally agree that the problem appears to be a memory protection issue (mmap). However having now had a stable application with a complex GUI (50+ GUI pages with fast changing data and animations) running for over a year on this kernel, with the only change being Microwindows Vs DirectFB, I feel pretty comfortable with this kernel (after our fix anyway!!).

I would be VERY interested if you find a kernel issue. Please post if you do.

[nbm]

Hi jkimble.It's good to hear that DirectFB is working very well with large no of applications.Is the PCI DMA working properly? I mean function like BitBlt is extensively using DMA for pixel writting?Also did you try USB mouse rapid movement along the DirectFB?

Now I am not working on that board.As far as I remember when I was working that BSP I found kernel memory allocations were not DMA allocation.I am not sure whether this is the reson of the problem when data transfer huge,and DMA needs to be used.

Segmentetion Fault was due to the memory protection bug in MMAP as I mentioned in my previous post. (BTW my profile name is changed from nabendu to nbm ).

[ChrisJohns]

I will forward your comments on to the Microwindows maintainer.

I see the DirectFB license is LGPL. This may be an issue given LGPL requires you provide to the end user all the Linux code you use plus your application object files so it can be relinked.

[nbm]

I also agree.micro window is slower one and development is stopped.It's better to use DFb.It also support HW acceleration.

[jkimble]

That's fantastic! Thanks for finding that!

Did you need to retain the change to fb_pgprotect() ? I'm assuming you do since we're really just going back to the 2.6.10 settings.

Thanks again!

[Nabendu]

you are welcome..

i need to know in old configuration(2.6.10) what mouse you were using? is it usb mouse/touchscreen ?
In my case usb mouse  (is it psaux?) is not working.

and what keyboard you were using.

I had not tested after removing the changes in fb_protect but i think without the change it should also work..





Message Edited by Nabendu on 2008-11-25 07:46 PM

[jkimble]

On the 2.6.10 kernel I was using a touchscreen driven by an ADS7846 encoder that interfaces to the SPI bus. No keyboard at all (we have a popup on the touchscreen).

I've not yet got that working on the new kernel. I've got SPI working but I've got to get the ads7846 talking to it. I was disappointed it didn't just work from kernel configuration menu but it doesn't. Always takes some tweaking eh?

Having trouble with CAN too. Seems to lock up the whole OS (unusual) when sending a certain size message. More work to do....

At least the frame buffer works now!

[Nabendu]

Cool up guys...no blame game.The type of work they doing are great.& I understand they may be busy...

We need the solution..

If we try and make a solution that will be good( may be for gpp package)

Cheers..

[jkimble]

Ha! That's funny. I was just looking at that macro and wondering if I should change it. I'll give your fix a try. I agree with your analysis. Let's hope that's all it is....

I'll let you know what I find.