Reply
Thread Tools
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#511
Originally Posted by nowave7 View Post
Right. So if you want to have 3d, please remove your SD card(s).
It is temporary workaround until memory is allocated early in boot sequence. I wonder whether it needs the memory at all. omapfb already has three 800x480 framebuffer planes allocated maybe they can be reused for MBX framebuffer as is. Anyway, if we really need two more 800x480 framebuffers/flipbuffers it can be allocated in omapfb driver directly at kernel boot time(wasting another 1.5MB). Or does the mbx driver need more later? (for textures etc)
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 02-22-2010 at 07:39 PM.
 

The Following User Says Thank You to fanoush For This Useful Post:
nowave7's Avatar
Posts: 241 | Thanked: 56 times | Joined on Jan 2009 @ Novi Sad, Serbia
#512
Originally Posted by fanoush View Post
It is temporary workaround until memory is allocated early in boot sequence.
I know. Just being a bit sarcastic and frustrated that, no matter what I do, I just cant get it to work.
__________________
Save the whales, feed the hungry, free the mallocs!
 
javispedro's Avatar
Posts: 2,057 | Thanked: 3,901 times | Joined on Jan 2009 @ Barcelona
#513
Originally Posted by fanoush View Post
pure magic indeed :-)
There is in fact way too magic here :P, as you'll see if you get any sample to run.

Originally Posted by fanoush View Post
xegltest cannot find libXau.so (even if it IS in /usr/lib!)
I personally just create a libXau.so.0 symlink pointing to libXau.so.6.


Basically, things to be worked on:
- Most visible: it's rendering to the Xomap buffer, but not sending changes to omapfb. (that's why I also ask showing/hiding the applications menu since it refreshes a large part of the screen). Manually refreshing entire screen after every frame works (and doesn't crash, even when running for long periods), but it's far from an ideal solution.
- Also very visible: periodic freezes.
- The driver leaks like if there was no tomorrow. Just restart a GLES app a few times until everything crashes/hangs. I can load a single 800x480 texture; next one causes everything to freeze.
- After the screen turns off everything goes crazy or black.
- Performance ( :P ).

Last edited by javispedro; 02-22-2010 at 07:44 PM.
 

The Following 4 Users Say Thank You to javispedro For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#514
Originally Posted by javispedro View Post
I personally just create a libXau.so.0 symlink pointing to libXau.so.6.
Thanks, missed the '.0' part.

Originally Posted by javispedro View Post
Basically, things to be worked on:
- Most visible: it's rendering to the Xomap buffer, but not sending changes to omapfb.
Right, that needs work. Maybe when buffers are flipped omapfb update can be called. If I understand it correcly omaplcd.ko implements device independent framebuffer for the rest of powervr code and now implements two 800x480 'flipbuffers'. So in theory omaplcd.ko is the only device specific part we need to change, correct?

Originally Posted by javispedro View Post
- Also very visible: periodic freezes.
- The driver leaks like if there was no tomorrow. Just restart a GLES app a few times until everything crashes/hangs. I can load a single 800x480 texture; next one causes everything to freeze.
Is it known what part leaks, kernel side or userspace (mbxdaemon or whatever)?
Originally Posted by javispedro View Post
- After the screen turns off everything goes crazy or black.
well when screen is off, the hardware (lcd panel, epson controller, omap display controller) is off and maybe powervr driver (omaplcd.ko part) is not aware of that and blindly writes some dispc registers? Hmm, I need to check whole omapfb/rfbi/blizzard code again, I guess powervr's omaplcd.ko assumes too much and expects omap display controller to actually drive the display and messes with lot of its registers, this seems wrong to me but how comes it even works as is?
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 02-22-2010 at 08:41 PM.
 

The Following 3 Users Say Thank You to fanoush For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#515
Here is initial version of wiki page documenting current status http://wiki.maemo.org/MBX_drivers_status Feel free to expand it.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 

The Following 8 Users Say Thank You to fanoush For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#516
Originally Posted by Stskeeps View Post
Well, I'm up for anything - I guess a wiki page would be useful
started
Originally Posted by Stskeeps View Post
and a mailing list, maybe a garage project would be in order?
Heh, last time I created garage project it was epic failure. But we need some coordination and this thread is already long and messy.

Personally I know next to nothing about 3D/opengles. I also expect to be the slowest person of you all. I also expect there are a lot of bright people already involved. I have moderate and rusty knowledge of omapfb/rfbi/dispc/blizzard drivers but maybe you already know more than me so there is no point in explaining that? With a mailing list or some other non-volatile place (no irc) I could check what are the issues and see if I can help. Trying stuff others already tried is not ideal. Just trying to save my time as much as possible, shame on me :-P
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 

The Following 2 Users Say Thank You to fanoush For This Useful Post:
Stskeeps's Avatar
Posts: 1,586 | Thanked: 10,165 times | Joined on Jun 2008 @ Warsaw, Poland
#517
Originally Posted by fanoush View Post
started

Heh, last time I created garage project it was epic failure. But we need some coordination and this thread is already long and messy.

Personally I know next to nothing about 3D/opengles. I also expect to be the slowest person of you all. I also expect there are a lot of bright people already involved. I have moderate and rusty knowledge of omapfb/rfbi/dispc/blizzard drivers but maybe you already know more than me so there is no point in explaining that? With a mailing list or some other non-volatile place (no irc) I could check what are the issues and see if I can help. Trying stuff others already tried is not ideal. Just trying to save my time as much as possible, shame on me :-P
Well, the GLES expert here is javispedro, I know next to none about omapfb or kernel issues, just did a couple of good guesses

A mailing list would be in order under a garage project I think
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 
Posts: 207 | Thanked: 27 times | Joined on Apr 2008
#518
I use rootfs on SD.
Ok. I flash provided kernel, boot from internal flash, umount all SD, load provided modules, create device and start mbxdaemon.
glinfo
dmesg
[ 867.476562] No flipbuffers
[ 867.476562] mbxdaemon: page allocation failure. order:8, mode:0xd0
[ 867.476562] [<c002c178>] (dump_stack+0x0/0x14) from [<c0082084>] (__alloc_pages+0x2c0/0x2d4)
[ 867.476562] [<c0081dc4>] (__alloc_pages+0x0/0x2d4) from [<c002dd40>] (__dma_alloc+0x184/0x3e4)
[ 867.476562] [<c002dbbc>] (__dma_alloc+0x0/0x3e4) from [<c002dfc4>] (dma_alloc_coherent+0x24/0x30)
[ 867.476562] [<c002dfa0>] (dma_alloc_coherent+0x0/0x30) from [<bf069c2c>] (AllocContiguousMemory+0x30/0x6c [omaplcd])
[ 867.476562] [<bf069bfc>] (AllocContiguousMemory+0x0/0x6c [omaplcd]) from [<bf069d3c>] (GetBackBuffer+0xa8/0xc0 [omaplcd])
[ 867.476562] r6 = 00000001 r5 = 00000000 r4 = 00000000
[ 867.476562] [<bf069c94>] (GetBackBuffer+0x0/0xc0 [omaplcd]) from [<bf06943c>] (InitMain+0x19c/0x250 [omaplcd])
[ 867.476562] r6 = C88FD00C r5 = C88FD000 r4 = 00000000
[ 867.476562] [<bf0692a0>] (InitMain+0x0/0x250 [omaplcd]) from [<bf06a580>] (OMAPLCDBridgeDispatch+0x408/0x460 [omaplcd])
[ 867.476562] [<bf06a178>] (OMAPLCDBridgeDispatch+0x0/0x460 [omaplcd]) from [<c00a9c6c>] (do_ioctl+0x74/0x84)
[ 867.476562] r6 = BEE581AC r5 = FFFFFFE7 r4 = C1B10A80
[ 867.476562] [<c00a9bf8>] (do_ioctl+0x0/0x84) from [<c00a9f14>] (vfs_ioctl+0x298/0x2b8)
[ 867.476562] r6 = 00000000 r5 = BEE581AC r4 = C1B10A80
[ 867.476562] [<c00a9c7c>] (vfs_ioctl+0x0/0x2b8) from [<c00a9fa0>] (sys_ioctl+0x6c/0x94)
[ 867.476562] r7 = 00000008 r6 = BEE581AC r5 = 00000000 r4 = C1B10A80
[ 867.476562] [<c00a9f34>] (sys_ioctl+0x0/0x94) from [<c0027be0>] (ret_fast_syscall+0x0/0x2c)
[ 867.476562] r8 = C0027D88 r7 = 00000036 r6 = 00009190 r5 = 0000B478
[ 867.476562] r4 = 41022DB8
[ 867.476562] Mem-info:
[ 867.476562] DMA per-cpu:
[ 867.476562] CPU 0: Hot: hi: 42, btch: 7 usd: 5 Cold: hi: 14, btch: 3 usd: 11
[ 867.476562] Active:13679 inactive:10272 dirty:0 writeback:0 unstable:0
[ 867.476562] free:2226 slab:2415 mapped:5925 pagetables:572 bounce:0
[ 867.476562] DMA free:8904kB min:1440kB low:1800kB high:2160kB active:54716kB inactive:41088kB present:130048kB pages_scanned:0 all_unreclaimable? no
[ 867.476562] lowmem_reserve[]: 0 0
[ 867.476562] DMA: 86*4kB 102*8kB 82*16kB 65*32kB 42*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 8904kB
[ 867.476562] Swap cache: add 0, delete 0, find 0/0, race 0+0
[ 867.476562] Free swap = 0kB
[ 867.476562] Total swap = 0kB
[ 867.476562] Free swap: 0kB
[ 867.500000] 32768 pages of RAM
[ 867.500000] 2578 free pages
[ 867.500000] 2730 reserved pages
[ 867.500000] 2415 slab pages
[ 867.500000] 27476 pages shared
[ 867.500000] 0 pages swap cached
[ 867.500000] AllocContiguousMemory: unable to allocate contiguous memory of bb800
[ 867.500000] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<6>PVR_KERNLError): Failed to find offset struct (KVAddress=c8abd000)
[ 868.773437] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.773437] PVR_KERNLError): Failed to find offset struct (KVAddress=c891c000)
[ 868.773437] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.781250] PVR_KERNLError): Failed to find offset struct (KVAddress=c8916000)
[ 868.781250] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.781250] PVR_KERNLError): Failed to find offset struct (KVAddress=c8914000)
[ 868.781250] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1793.078125] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<6>PVR_KERNLError): Failed to find offset struct (KVAddress=c8abd000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c891c000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c8916000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c8914000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
 
nowave7's Avatar
Posts: 241 | Thanked: 56 times | Joined on Jan 2009 @ Novi Sad, Serbia
#519
A question for fanoush, stskeeps, and javispedro,. If there is no source code for the TI 3D driver, how are we to hack it any further? Does this mean that the current omapfb driver will change, and in what way? Excuse my ignorance.
__________________
Save the whales, feed the hungry, free the mallocs!
 

The Following User Says Thank You to nowave7 For This Useful Post:
Stskeeps's Avatar
Posts: 1,586 | Thanked: 10,165 times | Joined on Jun 2008 @ Warsaw, Poland
#520
Originally Posted by nowave7 View Post
A question for fanoush, stskeeps, and javispedro,. If there is no source code for the TI 3D driver, how are we to hack it any further? Does this mean that the current omapfb driver will change, and in what way? Excuse my ignorance.
The parts that are most problematic is in the kernel and open source. Rest, we have a line to TI to ask about things.
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 2 Users Say Thank You to Stskeeps For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT -4. The time now is 07:23 AM.