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.

[Nabendu]

I am facing sameproblem here..Seems that mmap for 2.6.25 kernel sm712 frame buffer is not working.

Yes I also found nanox like program cant access the mmaped address.Whenever It tries to access the address got from mmap it gives segmentation fault.

I am also going through sm712fb code no success yet..

Was it working on 2.6.10 kernel?
Any solution found??


Regards,
Nabendu




Message Edited by Nabendu on 2008-11-19 02:04 AM

[jkimble]

OK. That confirms it then. I wasn't 100% sure but it seemed like the only thing going wrong (mmap).

There was no frame buffer driver for the chip I was using in the 2.6.10 kernel. Epson had (again) an example driver for other chips in the same family for the 2.6.8 kernel. I ported it to my chip and the 2.6.10 kernel. It's worked very well for 2.6.10. I've got a fairly sophisticated GUI running on Nano-X and with a touchscreen. Very nice.

Now I want to go to 2.6.25 but, though I'm 98% sure of my driver, no user space programs can use it. The mmap call definately sends back and invalid address. I'm in the process now of looking into what it's doing. Never been in this part of the kernel before. Really don't want to hack it up and make things worse. I'm not getting any other suggestions though.

I'll post here if I can work it out in a reasonable way.

[Nabendu]

btw which version of gdb you are using? The default gdb given within ltib iso image?

[jkimble]

Yes, the gdb that came with the 2.6.25 kernel. I just compiled in the package and it seems to work well.

I'm a little suprised that some Freescaler hasn't spoken up here. As an embedded OS being able to write drivers is a crucial thing. This will have to be fixed if this kernel is going to be used for anything beyond messing around. I'm at  point where I must make a decision this week whether to continue a product release with the 2.6.10 kernel (which is missing some things I'd really like to have) or find a solution to the mmap issue. It's really NOT a production kernel if mmap fails and it gives me grave concerns for the rest of the memory management in this release. I feel like I can't trust it..

Any Freescaler familiar with this kernel, I'd REALLY apprciate some feed back.

[Nabendu]

Yes ,it is unfortunate they don't reply.I also raised a service request but they dont answer.


I think i found some solution..

I found that I can read mmaped area but fail in write only.

There is a write protection bit in MMU for page handling in m5475,it should be on for write permission.
Enabled by CF_PAGE_WRITABLE mask.

So added folowing over vma,
pgprot_val(vma->vm_page_prot) = CF_PAGE_NOCACHE | (pgprot_val(vma->vm_page_prot) & ~CF_PAGE_COPYBACK);
   if(vma->vm_flags & VM_WRITE)
        pgprot_val(vma->vm_page_prot) |= CF_PAGE_WRITABLE;

in fb_pgprotect macro..

It should work now.Tomorrow I will check on my board.

If it doesn't work, there must be some serious problem on paging or elsewhere.


--------------------------------------
For my case gdb with 2.6.25 giving compilation error...I can't include gdb using ltib. Can you send me your working gdb spec file?

[JimDon]

---

Nabendu wrote:
Yes ,it is unfortunate they don't reply.I also raised a service request but they dont answer.

---

My experience had been that they will reply when the have an answer (i.e. fix). Chances are they were able to reproduce, or the would have asked for more info right away.

[jkimble]

Oh sure. I'm not whacking on them. They've done a great job of support in the past. If it were a trivial thing I'm sure they'd have had an answer right away.

It's just a frustrating problem...

[kmahan]

I've got the service ticket.  I've just got a number of other projects going on currently.  Not enough time in the day!

I did reply on a different thread, and it appears that Nabendu figured out what I was talking about.

[jkimble]

Yes the mod Nabendu listed earlier seemed to correct the problem I was having with my frame buffer. Not sure if that fixes the root of the problem but at first glance I think it might be all that's required.

Happy days!

Thanks!

[aeg]

Hi guys,

glad you found a fix for the frame buffer issue. I found the same thing a while back and have a service request with Freescale. I'll test Nabendu's mod tomorrow.

The weird thing is that mmaping via uio seems to work fine. That's how I wrote my nano-x driver.

Best,
Andreas

[Nabendu]

The fix is not working.

pgprot_val(vma->vm_page_prot)= 1c10
after MMU write protection off.
pgprot_val(vma->vm_page_prot)= 1c98 .

checking further ..

Any one let me know about 2.6.10 kernel     vma->vm_page_prot valus....                                           

[jkimble]

I confirm seeing the same vma->vm_page_prot values of 0x1c10 before the call tofb_pgprotect () and 0x1c98 after on the 2.6.25 kernel. Oddly this seems to fix my issue for nano-X. Another frame buffer application, however, continues to have a seg fault problem.

I have this all working on the 2.6.10 kernel. The values before and after for that kernel were:

Before fb_pgprotect (Equivalent section in fbmem() ) - 0x1c19
After   fb_pgprotect  (Equivalent section in fbmem() ) -  0x1c99

Please let me know if you find anything new on this. I will do the same.

[Nabendu]

if your printks are like below....
print .. pgprot_val(vma->vm_page_prot)     
 pgprot_val(vma->vm_page_prot) = CF_PAGE_NOCACHE | (pgprot_val(vma->vm_page_prot) & ~CF_PAGE_COPYBACK);
        if(vma->vm_flags & VM_WRITE)
            pgprot_val(vma->vm_page_prot) |= CF_PAGE_WRITABLE;
            vma->vm_flags &= ~0x00004000;        // to be checked
    print pgprot_val(vma->vm_page_prot)
 

Then vma->prot = 0x1c19= (CF_PAGE_ACCESSED|CF_PAGE_VALID|CF_PAGE_SHARED|CF_PAGE_READABLE|CF_PAGE_WRITABLE|CF_PAGE_DIRTY)

Then vma->prot = 0x1c99= (CF_PAGE_ACCESSED| CF_PAGE_VALID | CF_PAGE_SHARED | CF_PAGE_READABLE | CF_PAGE_NOCACHE | CF_PAGE_WRITABLE | CF_PAGE_DIRTY)

As far I know the first value provided vma created by mmap...

But for 2.6.25,    0x1c10 =
(CF_PAGE_ACCESSED | CF_PAGE_VALID | CF_PAGE_SHARED | CF_PAGE_READABLE)

dirty page bit may be ok, but dont know whether WRITE permission should be on or not.

I am not sure wheather io_remap_pfn_range routine work on MMU on the rWR permissins bits/ it is already used in between user level mmap and  fb_mmap calls  ( i mean the vma operation)


Any freescaler / experienced freescale mmap system call probly can answer.

I am planning to chechk it by writting a simple mmap device driver and check wheter i can write it or not.I think it will also fail.(worst part is to look mm system codes) .


jkimble  can you provide me the "vma->vm_page_prot"  valueafter remap_pfn_range?




Message Edited by Nabendu on 2008-11-22 04:25 AM

[Nabendu]

I am just wondering only few peoples tried microwindow on 5475evb on 2.6.25 and got this problem ?

[Nabendu · Accepted solution]

Hi alll,

The problem is solved..

just change your cf_pgtable.h file in asm-m68k dir as following.

 #define __S101    __pgprot(CF_PAGE_VALID \
             | CF_PAGE_ACCESSED \
             | CF_PAGE_SHARED \
             | CF_PAGE_READABLE \
             | CF_PAGE_EXEC)
#define __S011    __pgprot(CF_PAGE_VALID \
             | CF_PAGE_ACCESSED \
             | CF_PAGE_SHARED \
             | CF_PAGE_DIRTY \
                         | CF_PAGE_WRITABLE \
             | CF_PAGE_READABLE)


& compile ........


Message Edited by Nabendu on 2008-11-25 04:12 PM

[kmahan]

Hi Nabendu,

Thanks for tracking this down.  I definitely fat fingered that one.

I see you added CF_PAGE_DIRTY (in addition to the CF_PAGE_WRITABLE).  Was there a reason for that?  It isn't in the other writeable cases (and I didn't have it in my earlier code).

--Kurt

[aeg]

Hi,

has anyone tried the proposed code change with the virtual frame buffer driver?
It doesn't seem to work on my end..... Same good old segmentation fault.

Best,
Andreas

[schiller]

Hi everybody,

I'm facing a quite similar problem.

I'm using Linux 2.6.25 kernel with microwindows on a MCF5474. Launching my application is not problem. No segmentation fault are generated. My application runs well and I get what I want on the screen.

Now if I start some others application requiring more memory, dead pixels appear on the screen.

I wrote a little application which allocates a big table (at least 1Mb) with the same fixed value for each elements. Sometimes when I start this application, I get a big "line" on the screen. The color of the line is exactly the one I put in the my table.

Coarsely, it seems that the memory allocated for the table from my test program is a part of the framebuffer.

Does somebody here has already got this kind of problem ?

Any idea to fix it (I made all the modification described in this topic) ?

Best,

Guillaume

[jkimble]

 This is from my personal experience but I found Microwindows to work well only to a point. As our application grew we had more and more anomalous problems (random seg faults, screen corruption) that we were unable to explain. Our assumption was that the problem was with our application or the frame buffer driver (both of which we wrote in house). We focused on what we had done ourselves and, though we found stuff, nothing fixed our problems.

Finally, we went to something called DirectFB (which is supported in the Freescale package for the Coldfire with 2.6.25) and, after a week of porting things over, our problems all went away. I know that's not a definitive mark against Microwindows but my group spent a lot of time on this and, in the end, most of the seg faults appeared to be occurring within Microwindows.

Microwindows is also a dead project whereas DirectFB is on-going (The new Palm phones use it, I think the Droid is DFB based too). There's even a web browser (not a good one) that is supported.

I know it's a big change but if I were in your shoes I'd look into it (and was and I did).

[schiller]

Well, I agree that Microwindows is a dead project but I can't understand why my problems could come from it.

In my opinion there is something wrong with the memory allocation (the mmap) :

- First step, Microwindows requests for a mapping of the framebuffer via mmap.

At this point, Microwindows is able to draw pixels on the screen by writing data into this memory mapping (let's call that application1). Until now, no big deal.

- Then comes an other application (application2) which requests quite a lot of memory (a big table for example). Linux allocates the memory for this process but I think a part of this allocated memory belongs to memory reserved by the framebuffer's mmap.

- Starting from this point of view, if application2 starts to write into its memory it will also write into the framebuffer. This leads to get dead or wrong pixels to the screen (I get this results with my test application).

- Last step, application1 is writing to the framebuffer (to display new pixels for example) and thus also write into the application2 memory leading obviously to crash application2 (I get this results with my test application).

For me the framebuffer's mmap call  is not working that well (memory protection issue?)...

Maybe I miss something (I'm not really an advanced Linux kernel user) but for me it is a good explanation.

Is somebody here agrees my theory ? If yes, what could I do?

Best,

Guillaume