View Full Version : The N800 has a 3D accelerator, right?
gerbick, thanks for trying to give business lessons to Nokia, TI and other partners involved in the hardware and software discussed in this thread. Still, there are a couple of details you should consider.
Thanks for hiding behind a vapid, nebulous term as "business decisions" when honestly you've answered absolutely nothing other than announce a non-announcement. Simply put, make something happen or otherwise this is yet another non-announcement and indicative of that nothing productive in terms of prior iterations of so-called future-proof hardware and OS sold under the guise of fully-opensource will yet be another notch in the belt of marketing promise and lacking delivery.
I'm quite sure that the quotes of "fully open" are quite remembered by those that found out it wasn't. Please start with considering that first. Sell a fake promise, deliver something years later.
Way to go.
- The hardware for graphics acceleration is there as part of a pack. It's not that Nokia puts it on purpose only to decide that will not be used. It doesn't make business sense to to remove that piece of hardware from the configuration.
I quite understand this. I remember that we had to support SGI 320 and 540's back in the day. They had a firewire connection that was essentially useless due to licensing and SGI just simply was not going to pay Apple their fee per machine for licensing. It was just part of the chipset that came on those motherboards.
Guess what? You didn't find Firewire support advertised. Can't say the same for Nokia's claims (see above).
- Nokia would need to pay for those drivers if they would be shipped as part of the product. It doesn't make business sense to do so when such drivers are not used by the OS and when assuring their commercial quality would add more cost.
And now they can be used by a dead OS that you've all but killed?
Even unsupported would have encouraged 2 years of tinkering in advance to when Nokia decided to pull support.
- Nokia doesn't own the drivers. It's not Nokia the company that is doing the nice move to provide in a way or another those drivers now to the community. It's TI and the partners involved that have the IPR and the resources to do the move.
This I understand. But where was this information when the machines were released?
If you want to complain about Fremantle not being compatible with OMAP2 devices that's fine, but this is not related to this thread and there are already others where this topic has been discussed.
I wish to complain about how you didn't announce any of this the day these machines came out and addressed it years later. Silence in this form for so long is misleading in quite a few ways.
When the next machine comes out; I'm quite sure you will have a few people wait and ask more educated questions that upon delivery of non-answers will result in a backlash of "Remember how they treated their prior customers..." due to prior claims made that were not followed through by Nokia.
Simply put, I hope that even you can understand that fully-opensource means just that. The N800/N810 were sold under that guise and it was a lie. My complaint is real, actual, and now louder due to revelations like this.
And my complaint is well inline with the rest of this thread. You just don't want to address it. And that's ok too... I understand that it doesn't quite fit into your connotation of "business sense".
And I know it never will.
I don't think I ever saw Nokia advertising the 3D chip in the N8x0 or their 3D capable graphics driver ...
... to allow your established base to languish and have the community become bigger heroes than the originator of the software...
...is an unprecedented Open Software win for Nokia.
So many companies let their software languish but also never let the community step up and become heroes because they won't share the old code, even though it is old and the company has moved on. Has Microsoft released the source code for Windows 3.1?
But Nokia is opening it up! Win!
...is an unprecedented Open Software win for Nokia.
So many companies let their software languish but also never let the community step up and become heroes because they won't share the old code, even though it is old and the company has moved on. Has Microsoft released the source code for Windows 3.1?
But Nokia is opening it up! Win!
absolutely spot on.
I've been grinning from ear to ear after hearing about this and really hope it comes through.
even though a driver may not be fully utilized and may be buggy and all of the possible problems that may come with it, it will be there to work on and expand and improve.
i personally think the n8x0 line are outstanding devices and can hold their own against many other machines, in just the same way the 770 has outlasted its sellby date, so will this generation.
This is really good news, many thanks Quim. I look forward to some hacking :)
@Gerbick: You're after continued support. It's not going to come from Nokia for whatever reasons (the fact that my phone has never had any updates and still does what I bought it for 2 years ago comes to mind).
Where you will get support is Mer, this is a project which is designed to keep the software running on our (now out-of-date) hardware up-to-date and running nicely and to experiment with new and cool software (3D comes to mind).
Depending on the design of the drivers, you may be able to hack them into working on Chinook/Diablo, but that's up to you, I'll be using Mer and looking forward.
javispedro
2009-06-25, 18:06
I am worried about the technical issues (framebuffer size and all that). How are we going to get Clutter if it requires whole screen 3D acceleration, but the framebuffer cannot contain 800x480?
I guess it's still too early to worry about this. Let's celebrate!
...is an unprecedented Open Software win for Nokia.
I'm not doubting that. I just hope this community doesn't fracture like the Zaurus community had done before it.
So many companies let their software languish but also never let the community step up and become heroes because they won't share the old code, even though it is old and the company has moved on. Has Microsoft released the source code for Windows 3.1?
But Nokia is opening it up! Win!
It's a "win"... but at what level? Enthusiast level will benefit, no doubt. But it means nothing to an average consumer that has yet to install the ability to obtain root or the other hacks on this board.
In the meantime, I have to bone up and learn a ton more from you guys in the community.
However, I feel as if I can still voice my opinion in regards to Nokia treatment of this position - it just doesn't make sense to me.
I don't think I ever saw Nokia advertising the 3D chip in the N8x0 or their 3D capable graphics driver ...
The Nokia N810 features a highly customizable user interface and contains various novelties such as a Mozilla based browser with Ajax and Adobe flash 9, Bluetooth headset support as well as enhanced video and audio features.
Upon research, it was discovered that the 3D chipset was also present and speculation was that it was going to be utilized as well.
That speculation was community level; however words like "enhanced video" right after a chipset term like bluetooth added with the speculation... you're 100% right though.
Not advertised. But definitely speculated. I can take that blame though fully on myself for falling for the speculation. But it does exist, the chipset that is...
Frank Banul
2009-06-25, 18:43
When I looked at this, the limitation on frame buffer was for the internal LCD controller, not the 3D accelerator which if I recall correctly can use internal memory. Now the problem is still how do you get the internal frame buffer out to the external LCD controller in a timely manner. This seems like it would limit total frame rate.
I am worried about the technical issues (framebuffer size and all that). How are we going to get Clutter if it requires whole screen 3D acceleration, but the framebuffer cannot contain 800x480?
I guess it's still too early to worry about this. Let's celebrate!
Frank
danramos
2009-06-25, 19:15
I don't understand all this complaining now...
It made sense some time ago, when n8x0s were something new and not everybody knew about the omap2 resolution limit...
Nokia wanted a piece of hardware that was enough small to be almost pocketable and yet with a resolution and a screen size that could make the web experience as good as possible for the user... and I think Nokia hit just right with the NITs.
The Omap2 was pretty much bleeding edge for the time being, unfortunately its limits regarding the 640x480 max resolution pushed Nokia to use a serial LCD (a quite good one too) that gave users 160 more columns but deprived them of native 3D HW acceleration...
Now, after two years, we see the possibility of a new feature being pushed into our beloved devices thanks to Nokia commitment and the efforts of the community... I can't be anything else than grateful.
The problem is the hobbling and crippling for two years. Why did I buy something I was told was based on open-source (and I remember the tagline being marched out repeatedly by Nokia was "future proof because it's based on open-source") but then the gotchas are that just about every driver was closed and even some of the included applications. You only find out that it's PORTIONS of the system are open-source after you've already purchased and you read the ABOUT dialog or the paper documentation inside the box... but the promises of EVENTUALLY getting open-sourced drivers hangs some of us in there.. two years later we're only JUST being told that maybe we'll get the crippled video driver opened up.
I appreciate the opening up. I can not appreciate the distant amount of time it took to do so. Basically, the argument that this was the "right time" reads to me as "now that nobody wants that hardware anymore because we have these NEW chipsets that we're also going to close-source the drivers for..."
I also don't understand how it's a good business move either. I'm MORE likely to keep my old hardware now--and VERY VERY unlikely to want to buy the newer hardware... which I would LIKE to get, but the security and value and understanding of a fully open architecure is a much higher value to somebody like me, that has to configure solutions for people that are using the hardware, than the increased resources of the new hardware. The moment someone else DOES come out with a NEW piece of more open hardware, you KNOW I will pounce on it and so will the people I support and talk to.
Really, this is great news. It's just bittersweet news. I can't get TOO excited. It's like being told to be thankful you're getting table scraps. If you're hungry enough, there's no reason not to be thankful but... really? Is that the way to treat people who're ready to open their wallet to you?
javispedro
2009-06-25, 19:23
While I agree with the fact that I too though the device would be way more open (In fact, I got once bitten by icd & friends being closed), you should remember that in this case...
there was no closed driver. there was _no_ driver at all.
Nothing is being opened up, but developed. This is why we can still hope it will be open source from the beginning.
JustNick
2009-06-25, 19:36
I am worried about the technical issues (framebuffer size and all that). How are we going to get Clutter if it requires whole screen 3D acceleration, but the framebuffer cannot contain 800x480?
There is a 5Mbit fast memory dedicated to graphics, I guess that in a well documented fully OSS driver scenario somebody (I wish I had the knowledge, the ability and the talent to help...) could use the 800x480 resolution in 12bit (means 4096 colours if i did right the math) for the "plain" interface and for tasks that don't require hi-color count, while a faster 400x240@16bit could be used for games (given the Epson pixel doubling and the serial controller buffer are enough) or (in case with the PowerVR drivers comes something to make the IVA funcional) accelerate video reproduction leaving the CPU core less stressed...
Oh boy, oh boy, can't wait :D
danramos
2009-06-25, 19:37
While I agree with the fact that I too though the device would be way more open (In fact, I got once bitten by icd & friends being closed), you should remember that in this case...
there was no closed driver. there was _no_ driver at all.
Nothing is being opened up, but developed. This is why we can still hope it will be open source from the beginning.
You're arguing the semantics of speech when the point is the amount of time it's taken to open (or release, in your words) the drivers for hardware we've already had in our possession all this time.
I see that it's also cold-comfort for the developers of the Playstation 3 that got angry after they learned that Sony intentionally withheld API's and documentation for their platform for the reason that it would make the system appear to get better with time.
Good point on thinking it was an open platform when you bought it. It's difficult enough to deal with finding replacement styluses or parts. At least we finally can look forward to another trickle of opened drivers.
Like I said--I appreciate it. Greatly. I just have a hard time jumping for joy after waiting for what can be measured in years. Maybe a frosted cupcake with a couple of candles will do. heh
danramos
2009-06-25, 19:39
There is a 5Mbit fast memory dedicated to graphics, I guess that in a well documented fully OSS driver scenario somebody (I wish I had the knowledge, the ability and the talent to help...) could use the 800x480 resolution in 12bit (means 4096 colours if i did right the math) for the "plain" interface and for tasks that don't require hi-color count, while a faster 400x240@16bit could be used for games (given the Epson pixel doubling and the serial controller buffer are enough) or (in case with the PowerVR drivers comes something to make the IVA funcional) accelerate video reproduction leaving the CPU core less stressed...
Oh boy, oh boy, can't wait :D
If that's doable--I'd say that would be fantastic and more than enough for a good user experience. The resolution is already so high for portable gaming that I don't think anyone would care or notice... and the UI really needs more resolution than color to be useful and still look brilliant.
speculatrix
2009-06-25, 20:44
I'm not doubting that. I just hope this community doesn't fracture like the Zaurus community had done before it.
the great thing about OSS is that anyone can improve on it, and if they have ideas beyond those envisaged by the original authors, then they can go where they want. KDE as an example probably takes QT to a whole new level far beyond the capabilities of the Trolltech people.
the bad about about OSS is that anyone can try and improve on it, and if they have ideas conflicting with the original authors, then they can go where they want and fragment the community. Take for example the number of different linux desktops - lxde, maemo, fluxbox, xfce...
The forking/fragmentation isn't a big problem provided that there's still a critical mass behind each project to make it work, and if there's only one key person behind each fork and they get bored then it will die.
I know you're trying to wind everyone up and annoy them, but for the sake of the record: The fragmentation of the zaurus community of which you refer took place many years ago, and actually led to three quite active communities (sharp/cacko, pdaXrom, OpenZaurus) which helped each other, for example the OpenZ/Angstrom group helped create a really good Arm kernel which has been a great step up for Debian, Unbuntu and Android. Sharp/Cacko has withered as Sharp* had no interested. pdaXrom has withered because it relied too much on too few people to advance. OpenZ/Angstrom members alienated their users and then each other.
* The Zaurus was never sold to be a general purpose machine, it was an electronic dictionary with simple media player, and its use of linux was almost an accident, thus the community knew they'd have to do almost everything, e.g. SDHC support and accelerated video. This is perhaps why the Sharp/Cacko distro has died.
Things aren't perfect in the world of Nokia tablets but they're a damn site better than many other places.
There is a 5Mbit fast memory dedicated to graphics, I guess that in a well documented fully OSS driver scenario somebody (I wish I had the knowledge, the ability and the talent to help...) could use the 800x480 resolution in 12bit (means 4096 colours if i did right the math) for the "plain" interface and for tasks that don't require hi-color count, while a faster 400x240@16bit could be used for games (given the Epson pixel doubling and the serial controller buffer are enough) or (in case with the PowerVR drivers comes something to make the IVA funcional) accelerate video reproduction leaving the CPU core less stressed...
The 5MBit (which would be the framebuffer if we had a smaller LCD) won't make any odds except if used as intermediate memory (and I'm not sure the PowerVR needs this) as the data must still head out to the LCD controller (and this is the bit of the pipeline which is slow).
The framerate will certainly be limited, but it will still be useful and usable imho.
IVA has, unfortunately, nothing to do with the PowerVR, perhaps we can campaign for the firmware and tasks to use this next ;) :)
danramos
2009-06-25, 22:48
the bad about about OSS is that anyone can try and improve on it, and if they have ideas conflicting with the original authors, then they can go where they want and fragment the community. Take for example the number of different linux desktops - lxde, maemo, fluxbox, xfce...
No, the BAD thing about OSS is all the closed-source we keep ending up with. :) The forking isn't even a real problem. The popular stuff will keep going off on their own and evolving (I don't think anybody really misses xfree86 anymore, for example).
IVA has, unfortunately, nothing to do with the PowerVR, perhaps we can campaign for the firmware and tasks to use this next ;) :)
Cripes.
JustNick
2009-06-26, 07:20
The 5MBit (which would be the framebuffer if we had a smaller LCD) won't make any odds except if used as intermediate memory (and I'm not sure the PowerVR needs this) as the data must still head out to the LCD controller (and this is the bit of the pipeline which is slow).
The framerate will certainly be limited, but it will still be useful and usable imho.
IVA has, unfortunately, nothing to do with the PowerVR, perhaps we can campaign for the firmware and tasks to use this next ;) :)
I imagined IVA wasn't something PowerVR related, but dreaming doesn't cost a thing :D
About the 5Mbit that's exactly the idea I had about it: a quite fast intermediate memory :)
Of course once we have the driver we will probably have a better understanding of how the 3d accelerator works (hopefully) and the community's big brains will know for sure if that memory can be of any kind of benefit our NITs or not...
I'm quite sure that the quotes of "fully open" are quite remembered by those that found out it wasn't. Please start with considering that first. Sell a fake promise, deliver something years later.I don't recall any claims of "fully open-source" -- about the strongest statements I really heard were "runs Linux." Are you sure you heard this from Nokia, and not from some fanboy going hyperbolic? Anyway, that's all pretty irrelevant to this driver.
I quite understand this. I remember that we had to support SGI 320 and 540's back in the day. They had a firewire connection that was essentially useless due to licensing and SGI just simply was not going to pay Apple their fee per machine for licensing. It was just part of the chipset that came on those motherboards.
Guess what? You didn't find Firewire support advertised. Can't say the same for Nokia's claims (see above).Guess what? You didn't find 3D acceleration advertised. Precisely analogous.
If Nokia ever made a "fully open-source" claim (which I'm highly skeptical of), that's invalidated by all the closed source software shipped on the device. But there was no closed PowerVR driver on the device! So this open-source/closed-source complaint, valid or not, is completely off-topic -- seems it belongs in some thread about something that actually was closed-source.
This I understand. But where was this information when the machines were released?What information? That Nokia didn't have drivers for an internal graphics accelerator it wasn't using, wasn't advertising, and a normal enduser wouldn't even know was there?
I'm as down on shady deceptive marketing as the next guy, but I don't think any company has an obligation to issue a press release every time some bit of wild speculation about their product appears, and I hardly see that they did anything to promote the notion that the PowerVR would be usable.
bleh. Let it rest.
they want to release the damn drivers, so be it. the next iteration of whatever Nokia comes out will invariably be as badly supported as the prior three steps in order to get to a mainstream product that will be, by the time of its release be nothing more than a shiny "me-too" product.
the community - which I've stated over and over - shines whereas Nokia (the company) just doesn't. Not in regard to their ability to support, keep updates flowing, or anything else.
this... actually helps that situation because Mer, and the community, will lengthen the amount of time I will use my N810. to me, that's a win.
want to go deeper into semantics, go for it. I've already posted what I felt and above all what I think will happen. too bad I'm not as adept as the most of you in regards to the dev side. so as a consumer, I'm exercising a right.
and yeah...
"The Nokia N810 packs the power of a traditional computer into a pocket-sized format. Its open standard technology accelerates the convergence of multiple functionalities and services into a single device", said Ari Virtanen, Vice President, Convergence Products, Multimedia, Nokia. "Our new Nokia N810 offers users a true Web 2.0 experience in a compact, stylish, yet affordable package - it connects people to what matters to them."
Open standard, open source community, put it together wrong like I did... and there you have it. I never said anything about deceptive.
And it's fully on topic - they're going to release drivers for something, hide behind "business" all while dropping support for something else that's only been supported by a born-dead upgrade to Diablo.
call it nitpicking, but it's fully on-topic in a thread about a 3D accelerator that could have been used, and the life of this product extended from within and the community able to expand upon early on and not when the product is dying.
meh.
ishida336
2009-06-28, 05:24
I suppose I picked a great time to get an N810--right when support for the device is pretty much nill.
Well, it's not like I would be able to afford the next generation, since it's supposed to be a PHONE and likely cost $600+.
Nokia, I don't want a smart phone. I want a mobile linux device. Making another smartphone will just be a "HEY LOOK! We have one too!" in the market of the Iphone and HTC Hero. Instead of sticking to the market they actually have a fairly large stake in, the ultramobile internet tablet, of which there are few pickings now.
It makes me wonder if I should have gotten an Eee.
I suppose I picked a great time to get an N810--right when support for the device is pretty much nill.
Well, it's not like I would be able to afford the next generation, since it's supposed to be a PHONE and likely cost $600+.
Actually, now is a pretty decent time. The OS is the most stable at the moment and the community is maturing - just having to convince some to continue at Diablo matters if they keep machines at that level. With Mer, and this driver forthcoming and other advances - Tear for instance - it'll all get much better via the community.
ishida336
2009-06-28, 05:34
Hopefully it will. I chose the N810 because I didn't want to touch the evil Ipod Touch (and I don't even know why I particularly hate Apple. I just do.) I'll need continued support SOMEWHERE on the device, even if I have to install another -hopefully similar or intercompatible- OS.
amirtycoon
2009-06-28, 06:26
Nokia need to change their strategy.
i paid 460$ for NOKIA N82 and they say it has 3D accelerator but then there is no software to use it.
same happen for N810 , they said it was powerful multimedia device but what.....
i'm not going to pay 600$+ for N900 , i guess.
just waste of money and u get nothing only OMPA 3430 which now adays many device have it with less price.
i'm not going to pay 600$+ for N900 , i guess.
just waste of money and u get nothing only OMPA 3430 which now adays many device have it with less price.
Many, eh? In that case it should be no trouble to list a few.
You see, I'm aware of exactly 2 OMAP3430 devices available now:
Samsung Omnia HD -- sub-VGA candybar, seems to go for $600+
Palm Pre -- HVGA QWERTY slider, $549
(presumed) Nokia N900 -- WVGA QWERTY slider, est. $600+
Not "many" in my book, nor for substantially less price (especially since the N900 price is still a wild guess). And you'll notice both those devices have substantially less screen (specifically 60% and 40% the pixels); a look at the other specs makes it obvious the N900 is better hardware than the Pre, though the OmniaHD is more mixed.
I'm not saying I haven't missed a few -- I'm not a complete gadgethound -- but there's a huge difference from "2 devices, 1 at the same price, one ~$100 cheaper" to "many devices with less price", and until someone can list some more, I can't consider the latter anything but BS.
Add:
Sony Satio - plays Playstation games
Pandora
Sony Aino and Yari are also rumored to go the OMAP3 route too. Not confirmed.
I think HTC has something forthcoming too, but I never know what's in those things until they're released.
The Satio does look cool, but seems to be scheduled for an October release.
The Pandora isn't OMAP3430; it's a 3530, which is (IIRC) similar in feature set, but is not as power-efficient. (And besides, it's not available yet, either. :()
JustNick
2009-07-24, 21:54
Hi, I will use this thread to send updates on one my committed tasks in the maemo.org June sprint (http://wiki.maemo.org/Maemo.org_Sprints/June_09):
9.06-14 Plan for the OMAP2 acceleration drivers
There have been some discussions between the Maemo team and TI in the past months, and we seem to be moving to actions now.
This hasn't moved faster for many reasons, one of them being that this is not the most important item in the priority list shared by both companies. Still, I must say I'm impressed about the willingness to come up with a solution for the community shown by both sides. Really remarkable for a project based on 'legacy hardware' (from the platform development point of view of these companies) with zero revenue and actually some additional costs.
The current idea is that TI or an associated partner will provide either an OSS implementation of the driver known to contain some bugs or a closed implementation with probably better performance (although still not 100% commercial quality) or both. It would a one time delivery with no commitment for additional support.
My take in these discussions has been that an OSS driver is always preferrable since it would give to the community the chances to improve it, as opposed to a closed binary. Ther current idea is to try to implement in the OSS driver the fixes that were implemented in the closed one, tidy up the code a bit and make sure all the licensing is correct.
The scenario of community developers signing NDAs has been discarded. Note that both drivers were developed by two different companies that now they need to share their code. It is much easier to deal with this situation by a developer in one of these companies sharing already an NDA.
Everybody is quite busy but they are trying to arrange the time needed to complete the task. No deadlines and not even a commitment, but the optimist in me thinks that we could have some drivers available during the Summer... or perhaps before the Maemo Summit if unknown problems appear.
Any good news? :D After a month we (meaning me&my tablet at least) are here, waiting for updates, our hearts full of hope (ok, I can't sleep... sorry to bother :D)
Wait until August, until the the entire country of Finland returns from their collective vacation... :)
The Pandora isn't OMAP3430; it's a 3530, which is (IIRC) similar in feature set, but is not as power-efficient.
I thought, and I may just have imagined it, that the two were equivalent but with the 3530 being the off the shelf component to be used for everything, except for smartphone handsets for which the 3430 was designed. I seem to remember thinking that that meant the two had slightly different features, but I thought the power efficiency, etc., was the same.
Does anyone have a definitive answer to this out of interest?
JustNick
2009-07-25, 11:52
i can't even find an omap35xx on the main OMAP page on TI website...
This is the 3530 (http://focus.ti.com/docs/prod/folders/print/omap3530.html)
This one is the 3430 (http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=14649&navigationId=12643&templateId=6123)
I personally would like an Omap4 :D
anders_gud
2009-09-16, 05:47
Bump... Any news on this? :-)
Hi, I will use this thread to send updates on one my committed tasks in the maemo.org June sprint (http://wiki.maemo.org/Maemo.org_Sprints/June_09):
9.06-14 Plan for the OMAP2 acceleration drivers
There have been some discussions between the Maemo team and TI in the past months, and we seem to be moving to actions now.
This hasn't moved faster for many reasons, one of them being that this is not the most important item in the priority list shared by both companies. Still, I must say I'm impressed about the willingness to come up with a solution for the community shown by both sides. Really remarkable for a project based on 'legacy hardware' (from the platform development point of view of these companies) with zero revenue and actually some additional costs.
The current idea is that TI or an associated partner will provide either an OSS implementation of the driver known to contain some bugs or a closed implementation with probably better performance (although still not 100% commercial quality) or both. It would a one time delivery with no commitment for additional support.
My take in these discussions has been that an OSS driver is always preferrable since it would give to the community the chances to improve it, as opposed to a closed binary. Ther current idea is to try to implement in the OSS driver the fixes that were implemented in the closed one, tidy up the code a bit and make sure all the licensing is correct.
The scenario of community developers signing NDAs has been discarded. Note that both drivers were developed by two different companies that now they need to share their code. It is much easier to deal with this situation by a developer in one of these companies sharing already an NDA.
Everybody is quite busy but they are trying to arrange the time needed to complete the task. No deadlines and not even a commitment, but the optimist in me thinks that we could have some drivers available during the Summer... or perhaps before the Maemo Summit if unknown problems appear.
JustNick
2009-09-16, 07:44
http://wiki.maemo.org/Maemo.org_Sprints/September_09
"TI contact has resources ready. They are getting access to the source code from TI and maemo in order to start the work. "
I've been keeping my fingers crossed since the day qgil made that announcement :D
overfloat
2009-09-16, 20:11
Wait did I miss something? We are getting 3d acceleration for the n800/n810? I thought that the display is currently handled by a 3rd party Epson chip due to the inability of the OMAP's acceleration hardware to display 800x480 resolution or something.
Too many rumors around!
They are still slowly starting. I'm the messenger here. Sorry for not bringing better news sooner.
But it is happening, even if slow. 3 emails exchanged this week, to give you a specific example.
attila77
2009-09-16, 20:14
I'm not sure if that PowerVR there cares that much about resolution - it just renders stuff to a buffer, what you do with it later on is a different issue.
Sorry if this is a somewhat stupid question, but how much difference will 3D acceleration make? Will it make everyday use faster, open up a wider range of programs or something else entirely? I still think that its awesome that a company is willing to do this.
Thanks in advance
attila77
2009-09-16, 20:52
Wider range of programs, mostly (and potentially easier backporting of things that use (OpenGL ES 1.x) 3D from Fremantle).
That's great, I cant wait for it to get into our hands.
Аny news :)
I heard that in the next two weeks some bits will be available :D
I heard that in the next two weeks some bits will be available :D
It reminds me of today dilbert strip (http://dilbert.com/fast/2009-10-12/)
;)
I heard that in the next two weeks some bits will be available :D
Hope :rolleyes:
JustNick
2009-10-14, 12:27
http://mobiletablets.blogspot.com/2009/10/maemo-summit-news-n8x0-omap2-graphics.html
Hurray! :D
Me can't wait :)
Now this will make for a great surprise. It would be nice to get them as a launch party gift when the n900 comercially launches :) You know, as a gift to the community that helped Nokia develop this wonderful line of devices.
Actually these days I was wondering whether my long time committed task was complete. TI has promised publicly the release of the drivers and you have a direct contact in TI to ask further questions if needed.
There is little else to be done on my side since (you figured out) I'm not coding the drivers myself. :)
works are in full swing....
http://marc.info/?l=linux-omap&w=2&r=1&s=rx-51&q=b
Stout, what do you see there? I don't see anything.
absolutely nothing
just a lot of activity
but mainly audio related
and the hope that someone can read something else in it
http://mobiletablets.blogspot.com/2009/10/maemo-summit-news-n8x0-omap2-graphics.html
Hurray! :D
Me can't wait :)
Excellent news.
What are the characteristics of this graphics accelerator?
PS: This driver is in a Free (as freedom) Software license?
WOW, after soooo long! I thought it was a sarcastic joke.
Than you very much, qgil and everyone else involved.
I'm dancing in the streets :D
Bump up :)
Any progress about this? I understand that it will be slow, however.
Maybe we need to start a new thread, "Have your N8x0 3D Acceleration Drivers Shipped Yet?"
attila77
2009-10-23, 22:32
Or a "What do we realistically expect in the PowerVR MGX drivers?" thread ;)
Or a "What do we realistically expect in the PowerVR MGX drivers?" thread ;)
Hmm, let's see (http://talk.maemo.org/forumdisplay.php?f=12):
we expect to be able to play
- quake3 (and all of it's incarnations)
- second life
- BZFlag
- World of Goo
- Homeworld
- Bounce
- Sims 3
They all use OpenGL, no*?
Maybe we need to start a new thread, "Have your N8x0 3D Acceleration Drivers Shipped Yet?"
Or "Who will ship first? Pandora or the N8x0 3D Acceleration Drivers?" :D
Or "Who will ship first? Pandora or the N8x0 3D Acceleration Drivers?" :D
Pandora :rolleyes:
attila77
2009-10-24, 10:19
Well, the supposed two weeks are up... Or is "two weeks" the TI lingo for Pandora's "two months" ? :D
Well, the supposed two weeks are up... Or is "two weeks" the TI lingo for Pandora's "two months" ? :D
Or maybe Wally now works for ti (goto 292 (http://talk.maemo.org/showthread.php?p=344877#post344877))
Any movement :confused::rolleyes:
JustNick
2009-10-27, 13:30
The announcement was on the 13th, two weeks in working days could mean 15 working days, 5 days a week so 3 common mortal weeks, aka 21 days: there are 31 days in october, so I guess the 3rd of november could be a better day to ask for movements :D
Hmm, I know what you're saying - when a business says, for example, 3 to 5 days, they mean working days. But once you get into weeks it normally means actual weeks.
javispedro
2009-10-27, 15:02
Apply Westheimer's rule: To estimate the time it takes to do a task: Estimate the time you think it should take, multiply by two and change the unit of measure to the next highest unit.
Thus, we'll get 3D drivers in 4 months.
Or apply the openpandora.org rule: We'll get them in 2 months (from whatever day you read this).
attila77
2009-10-29, 13:03
TI has promised publicly the release of the drivers and you have a direct contact in TI to ask further questions if needed.
Sooo.... Time to poke the 'direct contact' for info ?
javispedro
2009-10-29, 13:12
And he is? :D
attila77
2009-10-29, 13:26
Ameet Suri (http://www.linkedin.com/pub/ameet-suri/3/935/8b0) was the guy at the TI presentation on the Summit, if that's who qgil is referring to... I was on another session at the time so have no detailed info on what exactly has been said on this topic.
qwerty12
2009-10-29, 13:38
Dear Maemo Community,
We would like to apologise for the delay of these drivers. In recompense, we would like to give you $100,000 and the IVA drivers as our way of saying sorry. All we will need from you is a bank account number in which to deposit the funds and $5,000 as a deposit (the IVA drivers are not cheap) on which we will return when we pay you your $100,000.
Yours,
TI
Stskeeps
2009-10-29, 13:40
Ameet Suri (http://www.linkedin.com/pub/ameet-suri/3/935/8b0) was the guy at the TI presentation on the Summit, if that's who qgil is referring to... I was on another session at the time so have no detailed info on what exactly has been said on this topic.
I have mailed him a couple of days ago, will see what he answers. Was also about topics such as where we should be looking for it, how people gain access, any quirks, etc.
Agent 770
2009-10-29, 14:38
According to people working on those drivers, it'll be done next week.
http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/70000/0000/600/70675/70675.strip.print.gif
http://dilbert.com/fast/2009-10-12/
javispedro
2009-11-05, 09:31
And another week has gone by!
Maybe a blocker issue was found :(
attila77
2009-11-05, 09:44
Then it would be more correct to say 'hey guys, we know what we said but ran into a blocker that will delay us for two more weeks, sorry' than face corporate silence like we do now.
Well, didn't you get used to the silence? :D
Is there any visible "progress" or blockers? Like driver bugs blocking the release, IP/licensing issues, lack of fund, whatever.
anders_gud
2009-11-09, 11:32
WOW, after soooo long! I thought it was a sarcastic joke.
Any news on this great joke?
:mad:
linuxeventually
2009-11-09, 12:19
TI releasing these drivers, VMware releasing that demo, Adobe releasing Flash 10 for ARM, OpenPandora launching, Nokia implementing true rotate support...
All things that are going the way of Duke Nukem Forever or the Phantom game console. >.>
Amarantus
2009-11-09, 12:42
TI releasing these drivers, VMware releasing that demo, Adobe releasing Flash 10 for ARM, OpenPandora launching, Nokia implementing true rotate support...
All things that are going the way of Duke Nukem Forever or the Phantom game console. >.>
You forgot noBounds Project one more joke
There was a quiet demo of the current NoBounds implementation (they've changed the name) at the 2009 Summit. I got to see more of the actual technology being used to do the NoBounds "trick". It failed to impress me.
attila77
2009-11-10, 10:41
@qole: How about some council action in the next sprint on poking TI/qgil about this issue (if no TI info surfaces till then) ? If nothing else, at least a communique of what's going on/wrong.
There was a quiet demo of the current NoBounds implementation (they've changed the name) at the 2009 Summit. I got to see more of the actual technology being used to do the NoBounds "trick". It failed to impress me.
This is interesting, can you tell us more? Summarize the technology behind the "trick"?
iamNarada
2009-11-11, 15:55
There was a quiet demo of the current NoBounds implementation (they've changed the name) at the 2009 Summit. I got to see more of the actual technology being used to do the NoBounds "trick". It failed to impress me.
Changed the name to? And failed why? Slow, non-functional?
I wish I could remember the new name for the technology.
I guess that I wasn't impressed because the demo hardware was big, bulky, and expensive and I wondered why you'd buy a big box to stream output from another device when you can buy a micro ATX, atom-based PC that's about the same size for nearly the same price. I had a hard time envisioning use cases for the system.
attila77
2009-11-11, 17:39
I wish I could remember the new name for the technology.
Are you referring to the liquidHDsomething streamer thingy ?
iamNarada
2009-11-11, 17:52
I wish I could remember the new name for the technology.
I guess that I wasn't impressed because the demo hardware was big, bulky, and expensive and I wondered why you'd buy a big box to stream output from another device when you can buy a micro ATX, atom-based PC that's about the same size for nearly the same price. I had a hard time envisioning use cases for the system.
Ugh. I was thinking they were working on implementing what I recalled (which may have been erroneous) the original noBounds embodied, i.e. all the connections, to external displays, external keyboard, etc, were done via WiFi and/or Bluetooth. What happened to that?
sjgadsby
2009-11-11, 18:52
I was thinking they were working on implementing what I recalled (which may have been erroneous) the original noBounds embodied, i.e. all the connections, to external displays, external keyboard, etc, were done via WiFi and/or Bluetooth.
Oh, noBounds was always wireless, but it has also always required a fairly hefty decoding/processing unit on the receiving side (http://talk.maemo.org/showthread.php?p=155278#post155278). The initial demo video simply glossed over that fact.
I believe qole is simply questioning at what receiver size and price point does trying to offload processing from an underpowered handheld device using clever tricks stop making sense. There's some line that once crossed, makes it more logical to just buy an inexpensive, ultra small PC and run a VNC client on the handheld.
iamNarada
2009-11-11, 19:00
Ah, the receiver...Clear. Riddle me this...where does DLNA fall in the context of this discussion. If I had (which I don't, but I can dream) one of the fancy new Samsung ridiculously thin televisions which support DLNA over wi-fi out of the box, would that meet the decoding/processing requirements? Can the n900 act as a DLNA server, or only as a client?
sjgadsby
2009-11-11, 19:05
Can the n900 act as a DLNA server, or only as a client?
The media player in Maemo 5 is a DLNA client. There have been DLNA/UPnP servers ported to previous Maemo releases, and given the increased developer and user interest in Maemo 5, there will almost certainly be a server or two available at some point.
I got some details from another forum member in a PM:
guy behind noBounds is called: Bernd Steinke
his maemo.org account is: http://maemo.org/profile/view/steinke/
he lists 2 projects on his profile, noBounds and LiquidHD
nobounds you know about, liquidhd might be what you are thinking of..
LiquidHD
liquidpixel remote user interface
video overview:
http://www.youtube.com/watch?v=UThEGzhIxRk
description:
http://www.siliconimage.com/technologies/index.aspx?Page=13&Section=1
javispedro
2009-11-12, 12:11
(Back to topic...)
It seems that the TI guy is MiA, or at least, doesn't answer to emails.
So now you know that trying to make 3D drivers for the N810 CAN and WILL kill you! Kids, don't try this at home!
mattiviljanen
2009-11-12, 17:35
The original (?) post on Maemo.org front page claimed that the display driver will be released in two weeks. If I count the days right, the two weeks have come and gone. Any news of the driver yet?
Ever since I found out about the 3d inside the n8x0 I belived it will never get drivers (as newer platforms will be far more interesting than hacking the old one). This thread almost woke some hope inside me. Well it's about to fall asleep again :)
Anyways since the TI guy is MiA I suggest a search party to raid pow camps. I can spare 300 gold and 100 iron :)
JustNick
2009-11-13, 12:04
Let say there's just one guy working on this in his "spare time" between regular working tasks @TI.
Let say the original driver wasn't the best driver that ever appeared in the embedded word, so it needs to be "fixed" in order to be usable.
Let say that once fixed it needs to be tested, integrated with maemo and pushed to the masses in the most painless and successfull way.
And let remember all this is done for a EOLed device...
Maybe we can wait a little longer without complaining, I'm sure our NITs will have a wonderful christmas present ;)
attila77
2009-11-13, 12:18
Let say there's just one guy working on this in his "spare time" between regular working tasks @TI.
Let say the original driver wasn't the best driver that ever appeared in the embedded word, so it needs to be "fixed" in order to be usable.
Let say that once fixed it needs to be tested, integrated with maemo and pushed to the masses in the most painless and successfull way.
And let remember all this is done for a EOLed device...
Maybe we can wait a little longer without complaining, I'm sure our NITs will have a wonderful christmas present ;)
It's more a question of communication than anything else. First of all, he didn't HAVE to say two weeks, it was (for all we know) a self-imposed (or intra-TI) limit or estimate. Also, not replying is just plain bad PR. I understand the person in question probably cannot say anything without management level approval, but then again, that is comms issue again - only within TI. If we waited 3 years, we can certainly wait a month more, but please, just a little bit/better communication could do wonders.
Just a quick note to let everyone know that TI has confirmed today that the drivers are being opened. Please be patient as we work through the issues. In the meantime, I encourage everyone to go to
http://wiki.maemo.org/Diablo_Community_Project
and indicate if you have any specific plans or intentions for the drivers. And if you can help, please volunteer.
Just a quick note to let everyone know that TI has confirmed today that the drivers are being opened. Please be patient as we work through the issues. In the meantime, I encourage everyone to go to
http://wiki.maemo.org/Diablo_Community_Project
and indicate if you have any specific plans or intentions for the drivers. And if you can help, please volunteer.
Has TI reconfirmed that they will be releasing the drivers, or are they confirming they will be released today?
JustNick
2009-11-14, 09:53
Just a quick note to let everyone know that TI has confirmed today that the drivers are being opened. Please be patient as we work through the issues. In the meantime, I encourage everyone to go to
http://wiki.maemo.org/Diablo_Community_Project
and indicate if you have any specific plans or intentions for the drivers. And if you can help, please volunteer.
This is great news! :)
I assume the drivers are already finished, but opening former closed source software to the public is a process that can take a long time. It's not about technical issues, but about politics and lawyers.
The frustrating thing for me is the way TI says things about the OMAP2 drivers so unofficially. We get told that "TI says that.." but there's no official word from them. Where's a press release? Who is in charge of this project? What's the timeline? Most importantly to me, what are the hold ups?
Just a quick note to let everyone know that TI has confirmed today that the drivers are being opened.
Can you link to this confirmation, or was this a private message?
I got some details from another forum member in a PM:
guy behind noBounds is called: Bernd Steinke
his maemo.org account is: http://maemo.org/profile/view/steinke/
he lists 2 projects on his profile, noBounds and LiquidHD
nobounds you know about, liquidhd might be what you are thinking of..
LiquidHD
liquidpixel remote user interface
video overview:
http://www.youtube.com/watch?v=UThEGzhIxRk
description:
http://www.siliconimage.com/technolo...e=13&Section=1
OK, we've recenly achieved enough to have time to answer! :D I'm sorry for the long quiet period! Please find much more in the related thread:
http://talk.maemo.org/showthread.php?p=389559#post389559
Time is hard, please stay patient although that's even harder :cool: ...
t_moyashi
2009-11-29, 12:08
I tried compiling Mr.Philipp Zabel's PowerVR MBX test driver (http://de.pastebin.ca/946765).
Look at dmesg and dream someday ti releases the real driver.
qwerty12
2009-11-29, 12:13
dream someday ti releases the real driver.
I've seen the real driver and let me tell you, there are some smart people trying to make it work (including pH5, Philipp Zabel).
JustNick
2009-11-29, 15:07
I've seen the real driver and let me tell you, there are some smart people trying to make it work (including pH5, Philipp Zabel).
me worshipping smart people!
I've seen the real driver and let me tell you, there are some smart people trying to make it work (including pH5, Philipp Zabel).
Excuse me for the (probably) stupid question but: once this shiny GL driver will be released, will it work for the applications running under the qole's chroot envirinment?
javispedro
2009-12-02, 21:48
Excuse me for the (probably) stupid question but: once this shiny GL driver will be released, will it work for the applications running under the qole's chroot envirinment?
It's not GL but GL ES 1.1.
It's not GL but GL ES 1.1.
Fine.
So... Aren't we talking about 3D gfx acceleration?
Why pointing out the difference?
javispedro
2009-12-03, 08:42
Why pointing out the difference?
Because there are no GL ES 1.1 applications in the entire Debian, so basically there's no reason for the GL ES 1.1 libraries/acceleration to be there.
Thanks for the lesson.
There are cool guys around here!
What about applications that require 3D acceleration that run on N900? Would it be possible to port those on N800/N810 once we get the GL ES 1.1 support, even though those apps are written for GL ES 2.0?
How different are 1.1 and 2.0?
javispedro
2009-12-03, 10:53
There's a lot of differences. You could even potentially emulate 1.1 using 2.0, but doing the opposite would be very difficult.
There's a lot of differences. You could even potentially emulate 1.1 using 2.0, but doing the opposite would be very difficult.
Yeah, found that the 2.0 is not backward compatible with 1.1, so no luck there :(
Maybe we can wait a little longer without complaining, I'm sure our NITs will have a wonderful christmas present ;)
I'm not complaining but... I wish my NIT had it's christmas present!
Stskeeps
2009-12-27, 13:35
A teaser from a tool called 'glinfo':
**********************************
OpenGL vendor string: Imagination Technologies
OpenGL renderer string: PowerVR MBXLite with VGPLite
OpenGL version string: OpenGL ES-CM 1.1
OpenGL extensions:
GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_fixed_point GL_OES_point_size_array GL_OES_point_sprite GL_OES_matrix_get GL_OES_read_format GL_OES_single_precision GL_IMG_texture_compression_pvrtc GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_OES_query_matrix GL_IMG_vertex_program GL_IMG_texture_stream GL_OES_matrix_palette GL_OES_draw_texture GL_IMG_read_format GL_IMG_texture_format_BGRA8888 GL_EXT_multi_draw_arrays
**********************************
PVR_SRVUM:
PVR_SRVUM: Texture allocation HWM = 85 bytes
**********************************
Config num 8
EGL vendor string: Imagination Technologies
EGL version string: 1.2 build 3.5.35.630
EGL extensions:
EGL_IMG_power_management
EGL config Attributes:
EGL_CONFIG_ID = 0x8
EGL_BUFFER_SIZE = 0x10
EGL_ALPHA_SIZE = 0x0
EGL_BLUE_SIZE = 0x5
EGL_GREEN_SIZE = 0x6
EGL_RED_SIZE = 0x5
EGL_DEPTH_SIZE = 0x18
EGL_STENCIL_SIZE = 0x0
EGL_CONFIG_CAVEAT = 0x3038
EGL_LEVEL = 0x0
EGL_MAX_PBUFFER_HEIGHT = 0x400
EGL_MAX_PBUFFER_PIXELS = 0x1fc000
EGL_MAX_PBUFFER_WIDTH = 0x7f0
EGL_NATIVE_RENDERABLE = 0x0
EGL_NATIVE_VISUAL_ID = 0x0
EGL_NATIVE_VISUAL_TYPE = 0x3038
EGL_SAMPLES = 0x0
EGL_SAMPLE_BUFFERS = 0x0
EGL_SURFACE_TYPE = 0x1
EGL_TRANSPARENT_TYPE = 0x3038
EGL_TRANSPARENT_BLUE_VALUE = 0x0
EGL_TRANSPARENT_GREEN_VALUE = 0x0
EGL_TRANSPARENT_RED_VALUE = 0x0
Problems reading from a client. Disconnecting
Disconnecting client 133
karatchov
2009-12-27, 17:18
great news.
Any idea if we are gonna see opengl in maemo4 or this is just for mer ?
Stskeeps
2009-12-27, 17:35
The idea is to have them both in Diablo and Mer (and whoever else wants them)
To clarify what I posted: We got over a bad bug that caused the drivers not to work at all on Nokia N8x0s.
Now they initialize, but there is still work to be done to fit better with the N8x0 framebuffer setup. I had a demo application rendering something to the framebuffer in full resolution and showing it on the screen (as far as I can tell) and the tests of the different MBX driver services were fine. PVR2D worked as well.
We are also currently waiting for a proper distribution of the libs in order to have people able to use them without worrying about legal issues. I don't expect too much movement on this matter before new years.
The important thing is that today was a big breakthrough in terms of getting GLES to N8x0. Please be patient while we get things better. If you have deep knowledge of OMAP2 / N8x0 kernel specifics, come and prod me on IRC and you can help out.
> Please be patient while we get things better.
As if we'd have a choice;) It is clear that nothing is going to happen before NY. But even approximately - would it be matter of couple of months? Or rather summer 2010? Or next Xmas?
javispedro
2009-12-27, 20:46
More jaw dropping teasers!
All credit goes to Stskeeps, who did what I considered a month's worth of work!
How it should look (screenshot taken from a N810 running a ES 1.1 sample):
http://depot.javispedro.com/nit/mbx/test.png
How it looks (picture taken with a N900 of the same N810):
http://depot.javispedro.com/nit/mbx/real.jpg
(^^ say hello to a OpenGL ES 1.1 capable N810 ;) )
As you can see, there's still some work to do, but the results are promising... and full screen!.
Thanks again everybody who is making this possible.
triple_a
2009-12-28, 10:53
Just a stupid question: what would be the practical applications for the 3d acceleration? The N8x0 tablets are so marginal products that there aren't a lot of new applications or games coming to take advantage of this.
I guess also the included Wayfinder app won't be able to use the 3d acceleration as it was written to use software rendering?
So correct me if I'm wrong, the biggest benefit would be for future releases of Mer, if they want to implement some fancy UI stuff?
I don't know about if omap 3D acceleration can be used for games but I image it could be possible.
And a fancy gui for mer is a good reason for me. I played around with mers new gui using sw rendering. It's slow right now but I'm really excited about an accelerated version.
BTW, would hardware acceleration benefit things like playing movies? I know it is 2D, but if media player could do it using HW-accelerated GL... At least on PC VLC can use GL for output
speculatrix
2009-12-28, 20:29
BTW, would hardware acceleration benefit things like playing movies? I know it is 2D, but if media player could do it using HW-accelerated GL... At least on PC VLC can use GL for output
I would hope it could lead to
* fast scrolling of big web pages
* fast task/page switching
* game acceleration
* offloading some video decoder processing, in particular scaling
* offloading 2D overlays for alpha blending
I would hope it could lead to
* fast scrolling of big web pages
* fast task/page switching
* game acceleration
* offloading some video decoder processing, in particular scaling
* offloading 2D overlays for alpha blending
Bingo!!!
You're forgetting nothing!
does this mean that meamo5 will run on N8x0?
how cool it would be to have Gallium 3D on N8x0 with OpenCL state tracker :)
Bingo!!!
You're forgetting nothing!Maybe we can add fast zooming too!
does this mean that meamo5 will run on N8x0?
how cool it would be to have Gallium 3D on N8x0 with OpenCL state tracker :)
N900 has different from n810 processor.
To run maemo 5 on n810 needs to recompile all from sources.
Because of some part of maemo 5 is closed only Nokia developers can do this. Also needs to port n810 hardware drivers to new maemo 5 kernel.
If you have deep knowledge of OMAP2 / N8x0 kernel specifics, come and prod me on IRC and you can help out.
Is current progress and pending issues documented somewhere (wiki page etc)? What kernel version you use with those drivers, diablo 2.6.21?
I wonder how it is hooked into display updates, N8x0 lcd controller uses partial and manual display updates to minimize memory traffic, does MBX driver know which part of its framebuffer changed or is fullscreen update the only sane way?
If there are any issues with mbx and omapfb/rfbi/blizzard driver integration I would definitely want to have a look at it and help as much as I can (which may be not much as I am quite slow nowadays). If you feel I would not slow you down let me know (pm, e-mail, link to current status).
If it is possible to make the kernel work-in-progress part public then please do. Quietly sitting on the sources is not ideal.
N900 has different from n810 processor.
To run maemo 5 on n810 needs to recompile all from sources.
Because of some part of maemo 5 is closed only Nokia developers can do this. Also needs to port n810 hardware drivers to new maemo 5 kernel.
How important the closed parts are?
If I understand it right, the n8x0 drivers will be ported to the latest mainline kernel thanks to the fine work of the MER developers.
How important the closed parts are?
If I understand it right, the n8x0 drivers will be ported to the latest mainline kernel thanks to the fine work of the MER developers.
I haven't n900. On maemo 4 most packages from
catalogue.tableteer.nokia.com aren't open software.
Stskeeps
2009-12-29, 20:30
How important the closed parts are?
If I understand it right, the n8x0 drivers will be ported to the latest mainline kernel thanks to the fine work of the MER developers.
Doubt that'll happen until rest of N8x0 kernel is mainlined, which may be never.
Doubt that'll happen until rest of N8x0 kernel is mainlined, which may be never.
ok, but if the drivers are ported to the maemo 5 kernel, there must be at least one nokia employee who will be king enough to recompile the whole maemo 5 for the n8x0. :)
ok. I can see now that hoping in such a thing is stupid.
There was someone (if I remember correctly) who was trying to port the n8x0 drivers to the mainline kernel, in his spare time last summer.
I'll never stop hoping that one day I'll be able to compile and use a vanilla kernel n800.
Thanks, and keep up the good work! I'm so excited to see the 3d support! :D
If it is possible to make the kernel work-in-progress part public then please do. Quietly sitting on the sources is not ideal. I don't know what it is going on at the moment, but it should be possible. In my correspondence with TI more than a month ago, they confirmed that they would open the drivers under GPL.
We need a crack team to keep pushing where bri3d was going (http://talk.maemo.org/showthread.php?t=35112). Yes, it is supposedly for Android, but the work is very relevant for this kind of thing...
So far everyone trying to do work to get the N8x0 stuff to work in a mainline kernel gets only so far, and then they run out of steam...
So far everyone trying to do work to get the N8x0 stuff to work in a mainline kernel gets only so far, and then they run out of steam...
As soon as I get my N810, that's probably going to be one of the first things I do. :) I almost finished porting the HP iPAQ H2200 kernel board code, which was stuck at Linux 2.6.21 on the handhelds.org CVS tree, to 2.6.33. I was planning on submitting it to mainline once I finished the framebuffer/LCD code, but that might not happen since I'm getting an N810 now. I'm still searching for one; I haven't purchased anything yet... Hopefully the source for the OpenGL driver will be out by the time I get it - I have a lot of things planned!
gTan64:
Just make sure you make your HP iPAQ H2200 kernel board code patches publicly available! I don't have one of those, nor do I plan to get one, but I hate seeing that kind of work lost on any platform! :)
I have to sell my iPAQ before I get my N810. Since it might be a matter of weeks before I get my N810, I'm probably going to finish the kernel for my iPAQ so its next owner (one of you? hey, it runs Linux!) can have more fun with it than I did - heck, I even got a N64 emulator* on it! As much as I want mainline, the Handhelds 2.6.21 kernel isn't that bad. I "only" want ramzswap, the gpio sysfs interface, overclocking, signalfd() so I can update udev and HAL on my Debian install, and 2D graphics acceleration. Doable I guess. :D
*running at ~2 FPS, but still somewhat playable. (Yes, I know "playable" is a stretch... :p)
Stskeeps:
The MBX drivers are running on plain Diablo, right? I'm assuming they haven't been tested on Mer & friends yet... How much cleanup have you had to do, and how much is left? Just wondering - I'm trying to figure out how much updating it would need for a "port" to the mainline kernel or linux-omap... I'm hoping it's not too much. :)
What about TV out?
n810 has the same 3,5 mm Nokia A/V connector that n95 and n900 has.
Stskeeps
2010-01-01, 23:12
Stskeeps:
The MBX drivers are running on plain Diablo, right? I'm assuming they haven't been tested on Mer & friends yet... How much cleanup have you had to do, and how much is left? Just wondering - I'm trying to figure out how much updating it would need for a "port" to the mainline kernel or linux-omap... I'm hoping it's not too much. :)
MBX drivers aren't N8x0 specific. They're for OMAP2.
Stskeeps
2010-01-01, 23:13
What about TV out?
n810 has the same 3,5 mm Nokia A/V connector that n95 and n900 has.
A bit off-topic. But I think verdict was that it is simply not wired up.
MBX drivers aren't N8x0 specific. They're for OMAP2.
I knew that. Should I have said "the OMAP2 graphics drivers you got from TI"? I know of several other devices the MBX was used in, but I don't know of any that had OpenGL ES libraries available for them, so I guess that's where I got MBX from. I was probably referring more or less to OpenGL ES libraries for the N8x0 when I said "MBX drivers"... Oh well.
Stskeeps
2010-01-02, 10:15
I knew that. Should I have said "the OMAP2 graphics drivers you got from TI"? I know of several other devices the MBX was used in, but I don't know of any that had OpenGL ES libraries available for them, so I guess that's where I got MBX from. I was probably referring more or less to OpenGL ES libraries for the N8x0 when I said "MBX drivers"... Oh well.
Sorry, answered a little too quickly :) The libs are OMAP2-specific as well. The parts that deal with N8x0 mostly exists in kernel.
To have the drivers being acceptable in mainline, it would be worth following how the SGX drivers are faring as the style is similar.
fabceolin
2010-01-04, 01:09
A teaser from a tool called 'glinfo':
**********************************
OpenGL vendor string: Imagination Technologies
OpenGL renderer string: PowerVR MBXLite with VGPLite
OpenGL version string: OpenGL ES-CM 1.1
OpenGL extensions:
GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_fixed_point GL_OES_point_size_array GL_OES_point_sprite GL_OES_matrix_get GL_OES_read_format GL_OES_single_precision GL_IMG_texture_compression_pvrtc GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_OES_query_matrix GL_IMG_vertex_program GL_IMG_texture_stream GL_OES_matrix_palette GL_OES_draw_texture GL_IMG_read_format GL_IMG_texture_format_BGRA8888 GL_EXT_multi_draw_arrays
**********************************
PVR_SRVUM:
PVR_SRVUM: Texture allocation HWM = 85 bytes
**********************************
Config num 8
EGL vendor string: Imagination Technologies
EGL version string: 1.2 build 3.5.35.630
EGL extensions:
EGL_IMG_power_management
EGL config Attributes:
EGL_CONFIG_ID = 0x8
EGL_BUFFER_SIZE = 0x10
EGL_ALPHA_SIZE = 0x0
EGL_BLUE_SIZE = 0x5
EGL_GREEN_SIZE = 0x6
EGL_RED_SIZE = 0x5
EGL_DEPTH_SIZE = 0x18
EGL_STENCIL_SIZE = 0x0
EGL_CONFIG_CAVEAT = 0x3038
EGL_LEVEL = 0x0
EGL_MAX_PBUFFER_HEIGHT = 0x400
EGL_MAX_PBUFFER_PIXELS = 0x1fc000
EGL_MAX_PBUFFER_WIDTH = 0x7f0
EGL_NATIVE_RENDERABLE = 0x0
EGL_NATIVE_VISUAL_ID = 0x0
EGL_NATIVE_VISUAL_TYPE = 0x3038
EGL_SAMPLES = 0x0
EGL_SAMPLE_BUFFERS = 0x0
EGL_SURFACE_TYPE = 0x1
EGL_TRANSPARENT_TYPE = 0x3038
EGL_TRANSPARENT_BLUE_VALUE = 0x0
EGL_TRANSPARENT_GREEN_VALUE = 0x0
EGL_TRANSPARENT_RED_VALUE = 0x0
Problems reading from a client. Disconnecting
Disconnecting client 133
Great!!!!
I'm waiting for good news!
After the "launch" of the N900, we're pretty good at waiting for months with nothing but screenshots, hints and teasers. We don't need public repositories or open code!
Good to see that the community devs are taking a page out of Nokia's book here. We all want to be like our parents when we grow up.
;)
There are still licensing issues to be resolved, but afaiu it's not too far off now.
Yesterday I install on my n800 Xephyr 7.6 with libgl-mesa-dri package. After launch Xephyr, next I launch glxgears for testing GLX but it show me only 8-10fps, next I expand glxgears window on fullscreen and gears speed slow down about 1fps. I think it a problem with driver swrast_dri.so. Maybe we add to swrast_dri.so suppport of framebuffer, sdl, XSP or Xvideo (with YUV12 hardware output) for better performance?
Here glxinfo output
name of display: :1.0
display: :1 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.4
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow,
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,
GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
GL_EXT_copy_texture, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements,
GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord,
GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays,
GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels,
GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object,
GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array,
GL_3DFX_texture_compression_FXT1, GL_APPLE_packed_pixels,
GL_APPLE_vertex_array_object, GL_ATI_blend_equation_separate,
GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once,
GL_ATI_fragment_shader, GL_ATI_separate_stencil,
GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_program_debug, GL_MESA_resize_buffers,
GL_MESA_texture_array, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
GL_NV_blend_square, GL_NV_fragment_program, GL_NV_light_max_exponent,
GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection,
GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format,
GL_SGI_color_matrix, GL_SGI_color_table, GL_SGI_texture_color_table,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays
33 GLX Visuals
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x21 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0xbe 16 tc 0 16 0 r . . 5 6 5 0 0 0 0 0 0 0 0 0 0 None
0xbf 16 tc 0 16 0 r . . 5 6 5 0 0 0 0 16 16 16 0 0 0 Slow
0xc0 16 tc 0 16 0 r y . 5 6 5 0 0 0 0 0 0 0 0 0 0 None
0xc1 16 tc 0 16 0 r y . 5 6 5 0 0 0 0 16 16 16 0 0 0 Slow
0xc2 16 tc 0 16 0 r . . 5 6 5 0 0 0 8 0 0 0 0 0 0 None
0xc3 16 tc 0 16 0 r . . 5 6 5 0 0 0 8 16 16 16 0 0 0 Slow
0xc4 16 tc 0 16 0 r y . 5 6 5 0 0 0 8 0 0 0 0 0 0 None
0xc5 16 tc 0 16 0 r y . 5 6 5 0 0 0 8 16 16 16 0 0 0 Slow
0xc6 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0xc7 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0xc8 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0xc9 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0xca 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0xcb 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0xcc 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0xcd 16 dc 0 16 0 r . . 5 6 5 0 0 0 0 0 0 0 0 0 0 None
0xce 16 dc 0 16 0 r . . 5 6 5 0 0 0 0 16 16 16 0 0 0 Slow
0xcf 16 dc 0 16 0 r y . 5 6 5 0 0 0 0 0 0 0 0 0 0 None
0xd0 16 dc 0 16 0 r y . 5 6 5 0 0 0 0 16 16 16 0 0 0 Slow
0xd1 16 dc 0 16 0 r . . 5 6 5 0 0 0 8 0 0 0 0 0 0 None
0xd2 16 dc 0 16 0 r . . 5 6 5 0 0 0 8 16 16 16 0 0 0 Slow
0xd3 16 dc 0 16 0 r y . 5 6 5 0 0 0 8 0 0 0 0 0 0 None
0xd4 16 dc 0 16 0 r y . 5 6 5 0 0 0 8 16 16 16 0 0 0 Slow
0xd5 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0xd6 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0xd7 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0xd8 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0xd9 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0xda 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0xdb 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0xdc 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x3d 32 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
wsuetholz
2010-01-20, 23:54
The glxinfo output is great news.. Thanks to everyone involved. Both TI, and anybody at Nokia that facilitated making available the information necessary for the developers to be able to ... develop? As well as the developers that managed to work with the information provided and produce something workable.
However, I'm always wanting it all... :D
So, how about the rest of the OMAP2 processor capabilities that we don't know how to take advantage of? Spoken of at this page TI OMAP2 Gaming Brochure (http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?contentId=4573&navigationId=12591&templateId=6123).
Things like the IVA which would be helpful for mplayer and vlc I assume. More information about the DSP interface, I realize that Simon Pickering has done a wonderful job with this already, but he and others could do better with complete documentation. Especially in the best way to transfer/share data being transformed by the DSP.
I understand that the IVA is another ARM based processor running in parallel to the ARM11 main processor. I could see that being used to off load gstreamer processes, and maybe even some of the A2DP processing that is still problematic. Can you say full H.264 decoding? Probably not...
There are enough co-processors as part of the OMAP2 package, it would be nice if they were all available to interested parties.
There is even functionality in the ARM11 processor to assist interpreted bytecode processing like Java VM and Python. This is another function that somebody has been able to figure out, but again it would be better if documentation was available on how best to use the extra features.
The OMAP2 product is old enough now that maybe TI could be persuaded to continue their wonderful trend of helping the open source developers have the tools to utilize their hardware to the limits of it's capabilities.
To read a better and more reasoned dissertation on this subject look here Drivers Justification (http://wiki.maemo.org/Drivers_justification)
wsuetholz
2010-01-21, 00:04
Fine.
So... Aren't we talking about 3D gfx acceleration?
Why pointing out the difference?
Here are some pages at the maemo wiki, mainly geared towards maemo 5, but they are relevant to this discussion as well.
OpenGL-ES (http://wiki.maemo.org/OpenGL-ES) and OpenGL_ES_Libraries (http://wiki.maemo.org/OpenGL_ES_Libraries).
Judging by those pages, how much maemo 5 will work, will depend on if clutter, and QT has an OpenGL ES 1.1 mode, it looks like SDL already does. If it's just a matter of the libraries, maybe they would automatically use the highest level of OpenGL available. Not really likely though. For the most part, I don't believe that there is much direct OpenGL code in the applications, most of it is in the Libraries used, be they QT or SDL.
danramos
2010-01-21, 00:07
After all this time.. all the waiting, I feel disappointed with TI. Profoundly. They should feel shameful for hurting development.
Stskeeps
2010-01-21, 08:53
danramos: TI wants as much as everyone to be giving out quality drivers. Current issues is not due to OMAP2 or their drivers, but due to the way the N8x0s are set up regarding external LCD controller as I've explained
We are still working with them to get the sufficient details to provide something that's not 'just' a hacker curiousity on N8x0 - currently it works but it isn't that interesting for actual usage. The remaining item is a shrink-wrap package so people can use these libraries legally and I'll poke them about it today.
TI has been cooperative in the port of these drivers to N8x0, so I think it's a bit unjustified to think they should 'feel shameful' as they have been forthcoming in delivering sources and libraries from their side.
We are still working with them to get the sufficient details to provide something that's not 'just' a hacker curiousity on N8x0 - currently it works but it isn't that interesting for actual usage. The remaining item is a shrink-wrap package so people can use these libraries legally and I'll poke them about it today.
I'm confused by this paragraph.
The drivers work, but they need a "shrink-wrap package"?
They aren't interesting for actual usage, but all you need is a way to use them legally?
So what's going on? Do they work or not? If we could get them legally in a "shrink wrapped package," would they be "interesting for actual usage"?
danramos
2010-01-22, 00:08
danramos: TI wants as much as everyone to be giving out quality drivers. Current issues is not due to OMAP2 or their drivers, but due to the way the N8x0s are set up regarding external LCD controller as I've explained
We are still working with them to get the sufficient details to provide something that's not 'just' a hacker curiousity on N8x0 - currently it works but it isn't that interesting for actual usage. The remaining item is a shrink-wrap package so people can use these libraries legally and I'll poke them about it today.
TI has been cooperative in the port of these drivers to N8x0, so I think it's a bit unjustified to think they should 'feel shameful' as they have been forthcoming in delivering sources and libraries from their side.
I'm still not sure what you mean. On the one hand, you're telling me that they want to provide more than 'just' a hacker curiosity? What's the difference between that and an actual open architecture with usefulness? Last time I checked, the way to make a library legal to use.. is to document it and give permission for it to be used. What's the hold-up after all this time? I stand by my admonishment of TI until I see a tangible difference.
TI has been cooperative in the port of these drivers to N8x0 Maybe they are being cooperative, but are the drivers open or not? Sounds like they are not.
danramos
2010-01-22, 01:12
Maybe they are being cooperative, but are the drivers open or not? Sounds like they are not.
Is that the difference between '"just" hack curiosity' and 'shrink-wrap?' I mean--is that just another way to rephrase 'open' and 'closed' code, respectively? If so, that seems insulting.
Stskeeps
2010-01-22, 08:34
Right, let me explain the timeline:
* I got GPL drivers and libraries from TI quite early. The kernel drivers are GPL, libraries came with no license. The GPL drivers and libraries are -for OMAP2-, which means that we would have to adjust them for N8x0 setup, which proved to be the difficult part.
* Since they (libraries) came with no license it was impossible to make them downloadable publically of the sole reason that I don't want to risk maemo.org or myself a C&D - I hope that you respect that.
* We had a few community members (who has been involved in the request to get drivers in the past) who knew what they were doing test out the build systems of the drivers and try to get the drivers initializing and rendering.
* Initially, everything failed. By chance, we figured out there were some bad assumptions in the drivers (regarding number of framebuffers and some kernel structures) which got the drivers initialized.
* Then, javispedro managed to get the drivers rendering under X (one of the former posts).
Currently, the drivers render straight into the OMAP framebuffer. Which some know, isn't enough to make it actually appear on screen (contents have to be manually synchronized to the external framebuffer). With a framebuffer synchronization call after each render request, it did update synchronously and this was not rendering very fast. That's the hack curiousity.
Current situation re licensing is that TI is making a shrink wrap package of the libraries that we can actually pass around. We have also requested information in order to get WSEGL (windowing system) headers so we can integrate the MBX rendering better with Xomap and may possibly push frame rate higher.
Right now the path we are pursuing is similar to kate's comment on https://wiki.maemo.org/Talk:Drivers_justification (The 'We are having discussions with TI if we could find reasonable terms to get driver released to developers etc' part).
To get further development on this driver, we have to have it out in the open properly and that is what happening right now (TI responded positively this morning). Since the drivers are for OMAP2 they need further adjustment for the N8x0 setup, where community members have already given a hand in getting them to work for N8x0 and hopefully more will happen in this regard.
read all 41 pages
thanks all people for pushing this forward to improve the good device in our hands.
http://mobiletablets.blogspot.com/2009/10/maemo-summit-news-n8x0-omap2-graphics.html
I really hope i'm missing something here
Dear Texas Instruments
Where are our drivers?
fanks
Morgs
The drivers are there. Just not ready for general use yet. Mer will have them once all issues are fixed.
GeneralAntilles
2010-02-04, 13:29
The drivers are there. Just not ready for general use yet. Mer will have them once all issues are fixed.
Community developers are working on making the drivers behave with the N8x0's weird framebuffer setup. See the end of this thread (http://talk.maemo.org/showpost.php?p=488227&postcount=406) for details.
absence of evidence is not evidence of absence. ;)
sjgadsby
2010-02-04, 15:08
The thread "Hey! Who remembers OMAP2 graphics drivers were promised 'in 2 weeks' at the Summit?" with five posts has been merged into this thread.
The drivers are there. Just not ready for general use yet. Mer will have them once all issues are fixed.
Great news!
I will Waiting here for Forever!:D:cool:
absence of evidence is not evidence of absence. ;)presence of the source code where any person who wants it can download it (not "community developers") is evidence (important part of the definition) of openness.
Stskeeps
2010-02-09, 09:37
Got the shrink-wrap today for quick testing it if works. Approved that the drivers worked in the manner we had reached before and gave feedback to TI guy. Minor changes to be made.
They'll hopefully end up on TI extranet very soon now (TM)
Delivery form seems to be a x86 binary which has the following contents (summary):
Linux and Windows Vertex Program Compiler
Windows PVRUniSco
L&W PVRTexToolGUI
L&W PVRTC
A training course (examples)
PVRShell(?)
Demos
OpenVG + SDK
debug version of GLES libraries (some of you might find this interesting)
PVR2D and of course, that it's GLES 1.1.
It comes with a console or X mode installer with a license.
For the people interested in licensing, I've attached the license terms for the libraries/demos/SDK (kernel driver is GPL)
Don't assume drivers that will work out of box and render happily to the screen - there's still work to be done on this as explained earlier in this thread, but this is the first step to make this possible. You will need to flash a new kernel (with extra DMA memory) and some other things as well.
Good news! Please make sure the "GL Kernel" also has rotation enabled, and all the other goodies that the community has been adding (faster SD card IO, etc) :)
Stskeeps
2010-02-09, 17:36
Good news! Please make sure the "GL Kernel" also has rotation enabled, and all the other goodies that the community has been adding (faster SD card IO, etc) :)
The hope is to push the kernel + module out through community SSU.
Good news! Please make sure the "GL Kernel" also has rotation enabled, and all the other goodies that the community has been adding (faster SD card IO, etc) :)
And not to forget the Japanese FM radio frequency band support. :)
Someone have a idea of the real speedup ( % ) of the 3d drivers ? It will change the performance in video ? i
hugs
Tecla
javispedro
2010-02-10, 00:17
It will change the performance in video ?
Video playing? Not really...
The Maemo Diablo alredy have a 2d acceleration ?
The video playing is good enough, but ....
shadowjk
2010-02-10, 01:10
I'm pretty certain it wont change the performance of Diablo. Hopefully though they'd make it possible for skilled people to make the fremantle desktop run at tolerable speed on N8x0... Volunteers needed on both the drivers and the userspace stuff, I believe..
Maybe stop spending time on Mer for the N900 and work on getting Mer running for the N8x0 when the drivers come....?
Stskeeps
2010-02-16, 06:46
In other news, the drivers should be uploaded to TI extranet today.
And you need to create a TI account for this. For those who want to have access the SDK need to send the mail to gamingonomap@list.ti.com and we will follow the above procedure.
You need to then click "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
While I kinda assume this will be drowned out in Meego announcements and discussion, well, I got the mail last night :)
Please read the remainder of this thread for the various issues there are with this driver.
speculatrix
2010-02-16, 10:15
And you need to create a TI account for this. For those who want to have access the SDK need to send the mail to gamingonomap@list.ti.com
I'm signing up too, I don't know how useful I can be but I figure that the more people who register an interest with TI then the more seriously TI will take community development and open-sourcing drivers
Blank page here 2.
Recompiling the kernel ? It remember me my old times of slackware, pretty cool.
mikemorrison
2010-02-17, 00:09
i was emailed instructions on how to set up a TI-pass ID after sending off a request to gamingonomap@list.ti.com. after setting up the TI-pass ID i was able to log onto that page and download the drivers:
OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.1 SDK based on Linux kernel 2.6.21
(OMAP24xx_MBX_K2621_N8xx_v3535630.zip)
Stskeeps
2010-02-17, 07:22
i was emailed instructions on how to set up a TI-pass ID after sending off a request to gamingonomap@list.ti.com. after setting up the TI-pass ID i was able to log onto that page and download the drivers:
OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.1 SDK based on Linux kernel 2.6.21
(OMAP24xx_MBX_K2621_N8xx_v3535630.zip)
Yes, I was able to as well after selecting "Extranets" on my TI.com and WTBU-OMAP Gaming SDK .
Well, consider the drivers released :) I'm sure we'll fill in the details regarding how to get them up soon.
JustNick
2010-02-17, 15:05
Uhm, I was already registered @TI, but I cannot find "Extranets", man I feel dumb :(
Angelochelotti
2010-02-17, 15:16
I also do not :(
I got the .bin file... and now? O.o
Stskeeps
2010-02-17, 20:54
I got the .bin file... and now? O.o
chmod +x and ./filename --help it has a console and a X mode.
Angelochelotti
2010-02-17, 22:51
here is very slow to download the zip.... around 5kb/s :mad:
i need a key to download ?
i dont see the link :p
[]´s
tecla
Angelochelotti
2010-02-17, 23:23
you need to send one email to gamingonomap@list.ti.com requesting the driver OMAP2 for n8X0... when you recive the feed back, you will see one link that take you to create your TI-pass ID.
And when you complet your TI-pass ID go back to http://my.ti.com/
and click: " "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
"
Angelochelotti
2010-02-17, 23:33
someone managed to install successfully?
I got the SDK yesterday evening. It requires a specifically built kernel, I think you need to set a flag, something with buffers, don't know what exactly, there is a Readme file with precise instructions. Since it was late, I left that for today.
Angelochelotti
2010-02-18, 12:44
And where can I find this readme file?
If i install these, will I lost my archives?
When you unzip the archive you've downloaded from TI site, you need to install it first, like Stskeeps said. You will be guided through the install process, pretty much like windows install shield procedure. After this you will find the source code, pre-built drivers, examples, and some test applications in the directory you specified during install. Oh, an you have to do this under Linux, on your desktop machine. :)
I compiled kernel and modules.
lsmod
Module Size Used by
omaplcd 10832 0 - Live 0xbf076000
mbxaccess 25464 1 omaplcd, Live 0xbf06e000
I guess need start mbxdaemon
./mbxdaemon
daemon creating semaphore
Semaphore 12345678 initialized.
daemon succeeded creating semaphore
PVR_DMSRV:(Error): MBXAPI_Open: Failed to open device errno=2
[64, ../mbxservicesdaemon/mbxaccessapi/mbxaccessapi.c]
PVR_DMSRV:(Error): Error : MBXDRIVERMANAGER_Failed_SysInit [68, ../mbxservicesdaemon/mbxserviceapi/mbxserviceapi.c]
Error in loading mbxdaemon
Do I need create device manualy using mknod?
May be I miss something?
PS
Msg loading mbxaccess:
OMAPLCD: Copy from user failed.
OMAPLCD: Copy from user failed.
I don't think that should be the case. Could you put dmesg here, after modules load?
Stskeeps
2010-02-18, 14:01
I compiled kernel and modules.
lsmod
Module Size Used by
omaplcd 10832 0 - Live 0xbf076000
mbxaccess 25464 1 omaplcd, Live 0xbf06e000
I guess need start mbxdaemon
./mbxdaemon
daemon creating semaphore
Semaphore 12345678 initialized.
daemon succeeded creating semaphore
PVR_DMSRV:(Error): MBXAPI_Open: Failed to open device errno=2
[64, ../mbxservicesdaemon/mbxaccessapi/mbxaccessapi.c]
PVR_DMSRV:(Error): Error : MBXDRIVERMANAGER_Failed_SysInit [68, ../mbxservicesdaemon/mbxserviceapi/mbxserviceapi.c]
Error in loading mbxdaemon
Do I need create device manualy using mknod?
May be I miss something?
PS
Msg loading mbxaccess:
OMAPLCD: Copy from user failed.
OMAPLCD: Copy from user failed.
Read rc.pvr for steps, too. This stuff needs shaping, but the drivers are out now. You need to mknod and some other funny things.
mbxaccess
OMAPLCD: Copy from user failed. (3 times)
omaplcd
OMAPLCD_Init: major device 250
So the drivers will not create device node upon successful load? That is very ugly...
Thank you.
Now I'll try various tests.
Thank you.
Now I'll try various tests.
After tests plz came and tell us.
I send the email but i havent any answer yet.
Im very excited with this driver.
Cool! I like to see threads full of incomprehensible techno-talk! This feels like progress!
Compile the kernel! Make the device nodes! Vent the plasma from the nacels while using the main deflector dish to reroute the sensor array!
Stskeeps
2010-02-18, 20:06
Cool! I like to see threads full of incomprehensible techno-talk! This feels like progress!
Compile the kernel! Make the device nodes! Vent the plasma from the nacels while using the main deflector dish to reroute the sensor array!
As I said in my original post:
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
When I say "weak at heart" in a very technical thread, it has to be bad ;)
They will also not easily render to the screen in a continous manner as you would hope they would.
That said, I'll be writing up a guide either tomorrow or on monday and post it on blog, on how to get them working so people can start hacking on them.
mbxdaemon start successful,
Then I try start glinfo
./glinfo
**********************************
Config num 1
EGL vendor string: Imagination Technologies
EGL version string: 1.2 build 3.5.35.630
EGL extensions:
EGL_IMG_power_management
EGL config Attributes:
EGL_CONFIG_ID = 0x1
EGL_BUFFER_SIZE = 0x10
EGL_ALPHA_SIZE = 0x0
EGL_BLUE_SIZE = 0x5
EGL_GREEN_SIZE = 0x6
EGL_RED_SIZE = 0x5
EGL_DEPTH_SIZE = 0x18
EGL_STENCIL_SIZE = 0x0
EGL_CONFIG_CAVEAT = 0x3038
EGL_LEVEL = 0x0
EGL_MAX_PBUFFER_HEIGHT = 0x400
EGL_MAX_PBUFFER_PIXELS = 0x1fc000
EGL_MAX_PBUFFER_WIDTH = 0x7f0
EGL_NATIVE_RENDERABLE = 0x0
EGL_NATIVE_VISUAL_ID = 0x21
EGL_NATIVE_VISUAL_TYPE = 0x15208
EGL_SAMPLES = 0x0
EGL_SAMPLE_BUFFERS = 0x0
EGL_SURFACE_TYPE = 0x5
EGL_TRANSPARENT_TYPE = 0x3038
EGL_TRANSPARENT_BLUE_VALUE = 0x0
EGL_TRANSPARENT_GREEN_VALUE = 0x0
EGL_TRANSPARENT_RED_VALUE = 0x0
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 7
Current serial number in output stream: 8
Then system become very slow and after few minutes reboot.
[ 1003.375000] No flipbuffers
[ 1003.382812] mbxdaemon: page allocation failure. order:8, mode:0xd0
[ 1003.382812] [<c002c178>] (dump_stack+0x0/0x14) from [<c0082084>] (__alloc_pages+0x2c0/0x2d4)
[ 1003.382812] [<c0081dc4>] (__alloc_pages+0x0/0x2d4) from [<c002dd40>] (__dma_alloc+0x184/0x3e4)
[ 1003.382812] [<c002dbbc>] (__dma_alloc+0x0/0x3e4) from [<c002dfc4>] (dma_alloc_coherent+0x24/0x30)
[ 1003.382812] [<c002dfa0>] (dma_alloc_coherent+0x0/0x30) from [<bf076c2c>] (AllocContiguousMemory+0x30/0x6c [omaplcd])
[ 1003.382812] [<bf076bfc>] (AllocContiguousMemory+0x0/0x6c [omaplcd]) from [<bf076d3c>] (GetBackBuffer+0xa8/0xc0 [omaplcd])
[ 1003.382812] r6 = 00000001 r5 = 00000000 r4 = 00000000
[ 1003.382812] [<bf076c94>] (GetBackBuffer+0x0/0xc0 [omaplcd]) from [<bf07643c>] (InitMain+0x19c/0x250 [omaplcd])
[ 1003.382812] r6 = C890C00C r5 = C890C000 r4 = 00000000
[ 1003.382812] [<bf0762a0>] (InitMain+0x0/0x250 [omaplcd]) from [<bf077544>] (OMAPLCDBridgeDispatch+0x408/0x460 [omaplcd])
[ 1003.382812] [<bf07713c>] (OMAPLCDBridgeDispatch+0x0/0x460 [omaplcd]) from [<c00a9c6c>] (do_ioctl+0x74/0x84)
[ 1003.382812] r6 = BE960210 r5 = FFFFFFE7 r4 = C41C0F20
[ 1003.382812] [<c00a9bf8>] (do_ioctl+0x0/0x84) from [<c00a9f14>] (vfs_ioctl+0x298/0x2b8)
[ 1003.382812] r6 = 00000000 r5 = BE960210 r4 = C41C0F20
[ 1003.382812] [<c00a9c7c>] (vfs_ioctl+0x0/0x2b8) from [<c00a9fa0>] (sys_ioctl+0x6c/0x94)
[ 1003.382812] r7 = 00000008 r6 = BE960210 r5 = 00000000 r4 = C41C0F20
[ 1003.382812] [<c00a9f34>] (sys_ioctl+0x0/0x94) from [<c0027be0>] (ret_fast_syscall+0x0/0x2c)
[ 1003.382812] r8 = C0027D88 r7 = 00000036 r6 = 00000000 r5 = 401B2510
[ 1003.382812] r4 = 00000008
[ 1003.382812] Mem-info:
[ 1003.382812] DMA per-cpu:
[ 1003.382812] CPU 0: Hot: hi: 42, btch: 7 usd: 11 Cold: hi: 14, btch: 3 usd: 13
[ 1003.382812] Active:17742 inactive:5152 dirty:6 writeback:0 unstable:0
[ 1003.382812] free:4103 slab:1610 mapped:5796 pagetables:564 bounce:0
[ 1003.382812] DMA free:16412kB min:1440kB low:1800kB high:2160kB active:70968kB inactive:20608kB present:130048kB pages_scanned:6 all_unreclaimable? no
[ 1003.382812] lowmem_reserve[]: 0 0
[ 1003.382812] DMA: 1191*4kB 798*8kB 181*16kB 26*32kB 4*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 16412kB
[ 1003.382812] Swap cache: add 1745, delete 1711, find 112/118, race 0+0
[ 1003.382812] Free swap = 243928kB
[ 1003.382812] Total swap = 250712kB
[ 1003.382812] Free swap: 243928kB
[ 1003.406250] 32768 pages of RAM
[ 1003.406250] 4441 free pages
[ 1003.406250] 2730 reserved pages
[ 1003.406250] 1610 slab pages
[ 1003.406250] 31941 pages shared
[ 1003.406250] 34 pages swap cached
[ 1003.406250] AllocContiguousMemory: unable to allocate contiguous memory of bb800
[ 1003.406250] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed
Stskeeps
2010-02-18, 21:24
[ 1003.375000] No flipbuffers
[ 1003.382812] mbxdaemon: page allocation failure. order:8, mode:0xd0
Yeah, this is where the zImage comes into play. Basically, we need to help make packaging for Maemo4 for this stuff, so it initializes early enough.
I changed CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=8
compiled kernel and flash it.
What's wrong?
I flash kernel from Ti package.
Result is the same:
[ 191.546875] No flipbuffers
[ 191.562500] mbxdaemon: page allocation failure. order:8, mode:0xd0
I've also flashed the Ti release kernel image, created the device node, exported the library path and finally ran the glinfo, but it just hangs. No output whatsoever.
Did you start mbxdaemon?
Show mbxdaemon output.
Yes, started the mbxdaemon. This is the output:
daemon creating semaphore
Semaphore 12345678 initialized.
daemon succeeded creating semaphore
I assume it is all ok?
Done a strace on glinfo process. It appears that it hangs on file open:
Nokia-N810-43-7:~# strace -p 1609
Process 1609 attached - interrupt to quit
open("/tmp/mbx/txfifo", O_WRONLY
Running strace on glinfo, reveals that exporting the LD_LIBRARY_PATH was not such a good idea. I am missing the GL ES libraries, even though I exported the path to them. I should have installed libraries through the install.sh script.
Are you sure that install.sh will install libraries?
This is the first part of the strace output, apologize for being a bit too long:
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# strace ./glinfo
execve("./glinfo", ["./glinfo"], [/* 62 vars */]) = 0
brk(0) = 0x12000
uname({sys="Linux", node="Nokia-N810-43-7", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/lib/tls/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/tls/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/lib/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/usr/lib/tls/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/v6l/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/v6l/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/v6l/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/v6l/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/v6l/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/v6l/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/v6l/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/v6l", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/fast-mult/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/fast-mult/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/fast-mult/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/fast-mult", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/half/libGLES_CM.so", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/half", 0xbe8e7a60) = -1 ENOENT (No such file or directory)
open("/usr/lib/libGLES_CM.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0dG\0 \0004\0\0\0L"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=355408, ...}) = 0
mmap2(NULL, 342500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40004000
mprotect(0x4004f000, 32768, PROT_NONE) = 0
mmap2(0x40057000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4b) = 0x40057000
close(3) = 0
open("/usr/X11R6/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0l\21 2.A4\0\0\0\30"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=11208, ...}) = 0
mmap2(0x412e8000, 41120, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x412e8000
mprotect(0x412ea000, 28672, PROT_NONE) = 0
mmap2(0x412f1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x412f1000
mprotect(0xbe8e8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3) = 0
open("/usr/X11R6/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324 \302\3A4\0\0\0004"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1086428, ...}) = 0
mmap2(0x41028000, 1118708, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41028000
mprotect(0x4112c000, 32768, PROT_NONE) = 0
mmap2(0x41134000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x104) = 0x41134000
mmap2(0x41137000, 8692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x41137000
close(3) = 0
open("/lib/libIMGegl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libIMGegl.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324 \17\0\0004\0\0\0\230"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=42966, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000
mmap2(NULL, 66640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40058000
mprotect(0x40061000, 28672, PROT_NONE) = 0
mmap2(0x40068000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0x40068000
close(3) = 0
open("/lib/libsrv_um_1.1.35.630.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libsrv_um_1.1.35.630.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0l(\0 \0004\0\0\0000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=165007, ...}) = 0
mmap2(NULL, 64880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4006c000
mprotect(0x40074000, 28672, PROT_NONE) = 0
mmap2(0x4007b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7) = 0x4007b000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200 \261\"A4\0\0\0P"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=445776, ...}) = 0
mmap2(0x41228000, 475316, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41228000
mprotect(0x41294000, 28672, PROT_NONE) = 0
mmap2(0x4129b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6b) = 0x4129b000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40002000
set_tls(0x40002120, 0x40002120, 0x41023048, 0x400027f8, 0x40) = 0
mprotect(0x4129b000, 4096, PROT_READ) = 0
mprotect(0x41134000, 4096, PROT_READ) = 0
mprotect(0x412f1000, 4096, PROT_READ) = 0
mprotect(0x40004000, 307200, PROT_READ|PROT_WRITE) = 0
mprotect(0x40004000, 307200, PROT_READ|PROT_EXEC) = 0
brk(0) = 0x12000
brk(0x33000) = 0x33000
open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libpvrX11WSEGL.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libpvrX11WSEGL.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0`\r\ 0\0004\0\0\0x"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=16264, ...}) = 0
mmap2(NULL, 44124, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4007c000
mprotect(0x4007f000, 28672, PROT_NONE) = 0
mmap2(0x40086000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x40086000
close(3) = 0
open("/lib/libpvr2d.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libpvr2d.so", O_RDONLY) = 3
This is the second part:
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\214 \20\0\0004\0\0\0("..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=17959, ...}) = 0
mmap2(NULL, 45600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40088000
mprotect(0x4008c000, 28672, PROT_NONE) = 0
mmap2(0x40093000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x40093000
close(3) = 0
open("/lib/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libX11.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20B VA4\0\0\0\244"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=779012, ...}) = 0
mmap2(0x41550000, 810576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41550000
mprotect(0x4160a000, 32768, PROT_NONE) = 0
mmap2(0x41612000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xba) = 0x41612000
close(3) = 0
open("/lib/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXau.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\334 \tSA4\0\0\0 "..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=8536, ...}) = 0
mmap2(0x41530000, 38816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41530000
mprotect(0x41532000, 28672, PROT_NONE) = 0
mmap2(0x41539000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x41539000
close(3) = 0
open("/lib/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\1 7TA4\0\0\0@"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=17016, ...}) = 0
mmap2(0x41540000, 47284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41540000
mprotect(0x41544000, 28672, PROT_NONE) = 0
mmap2(0x4154b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x4154b000
close(3) = 0
uname({sys="Linux", node="Nokia-N810-43-7", ...}) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
uname({sys="Linux", node="Nokia-N810-43-7", ...}) = 0
uname({sys="Linux", node="Nokia-N810-43-7", ...}) = 0
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"...}, 19) = 0
uname({sys="Linux", node="Nokia-N810-43-7", ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
access("/root/.Xauthority", R_OK) = -1 ENOENT (No such file or directory)
writev(3, [{"l\0\v\0\0\0\0\0\0\0\0\0"..., 12}], 1) = 12
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
read(3, "\1\0\v\0\0\0?\0"..., 8) = 8
read(3, "\332&/\4\0\0`\1\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\ 0 \10\377\300'\t\0T"..., 252) = 252
write(3, "7\0\5\0\0\0`\1>\0\0\0\10\0\0\0\377\377\0\0b\0\5\0\f\0\0\0BIG-R"..., 64) = 64
read(3, "\1\210\2\0\0\0\0\0\1\205\0\0\1\0\0\0`C\25\0(\210,\ 0b\0\0\0HP\25\0"..., 32) = 32
read(3, "\1\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0`C \25\0(\210,\0"..., 32) = 32
write(3, "\205\0\1\0"..., 4) = 4
read(3, "\1\0\4\0\0\0\0\0\377\377?\0(\210,\0\205\0\0\0HP\25 \0\254\344\0\0D\265\26\0"..., 32) = 32
writev(3, [{"b\0\5\0\t\0`\1"..., 8}, {"XKEYBOARD"..., 9}, {"\0\0\0"..., 3}], 3) = 20
read(3, "\1\210\5\0\0\0\0\0\1\212W\213\1\0\0\0\0\0\0\0(\210 ,\0b\0\0\0HP\25\0"..., 32) = 32
write(3, "\212\0\2\0\1\0\0\0"..., 8) = 8
read(3, "\1\1\6\0\0\0\0\0\1\0\0\0(\210,\0\212\0\0\0HP\25\0\ 300\344\0\0D\265\26\0"..., 32) = 32
write(3, "<\0\2\0\0\0`\1+\0\1\0"..., 12) = 12
read(3, "\1\1\10\0\0\0\0\0\213\1\300\0HP\25\0\300\344\0\0D\ 265\26\0\3141\25\0\234*\v\0"..., 32) = 32
shutdown(3, 2 /* send and receive */) = 0
close(3) = 0
open("/dev/mbx", O_RDWR) = 3
open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
getpid() = 1663
SYS_299(0xbc614e, 0x1, 0x1b6, 0x1, 0x152c0) = 0
open("/tmp/mbx/txfifo", O_WRONLY <unfinished ...>
Are you sure that install.sh will install libraries?
Didn't go into much detail through the install.sh, but according to Readme.txt it should.
From my experience glinfo hang when mbxdaemon crash kernel.
Do anybody have working kernel .config?
This is the exact procedure I did after flashing the kernel, along with dmesg output, though nothing interesting there, other than registering a character device:
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# insmod mbxaccess.ko
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# insmod omaplcd.ko
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# grep ""mbx"$" /proc/devices | cut -b1,2,3
251
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# mknod /dev/mbx c 251 0
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# ./mbxdaemon
./mbxdaemon: error while loading shared libraries: libmbxservicesdaemon_1.1.35.630.so: cannot open shared object file: No such file or directory
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# export LD_LIBRARY_PATH=/home/user/binary_omap2420_linux_release
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# ./mbxdaemon
daemon creating semaphore
Semaphore 12345678 initialized.
daemon succeeded creating semaphore
Nokia-N810-43-7:/home/user/binary_omap2420_linux_release# dmesg |tail
[ 72.132812] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8)
[ 88.226562] cx3110x: PSM dynamic with 100 ms CAM timeout.
[ 98.125000] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8)
[ 106.132812] JFFS2 warning: (1373) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -122
[ 106.781250] JFFS2 warning: (1373) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -174
[ 107.101562] JFFS2 warning: (1373) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -408
[ 107.390625] JFFS2 warning: (1373) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -192
[ 121.562500] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8)
[ 133.257812] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8)
[ 157.531250] OMAPLCD_Init: major device 250
Stskeeps
2010-02-19, 12:10
This is the exact procedure I did after flashing the kernel, along with dmesg output, though nothing interesting there, other than registering a character device:
Copy libs into /usr/lib and run ldconfig
Copy libs into /usr/lib and run ldconfig
Ok, will try that. Thanks!
Nope, nothing. Sill the same. Oh, and I seem to be missing powervr.ini in/etc?
Where you get powervr.ini? I can't find this file...
When running glinfo through strace, there is the following line:
open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
Not sure if it is necessary, just thought I asked. :)
javispedro
2010-02-19, 14:39
No, it's not needed*.
I'm still waiting TI email...
EDIT: * AFAIU, for now. It might be needed in the future.
Thanks javispedro, good to know.
No ideas what we are doing wrong...
Strange to me that some tests running normally.
So you at least got some test running? I haven't even gotten that far.
BoxOfSnoo
2010-02-19, 18:15
Apologies if I missed the obvious here, but does this driver enable Jazelle, or just 3D acceleration?
./services_test
----------------------- Start -----------------------
Try calling PVRSRVConnect an invalid argument:
OK
Call PVRSRVConnect a valid argument:
OK
Try calling PVRSRVEnumerateDevices with invalid puiNumDevices:
OK
Get number of devices from PVRSRVEnumerateDevices:
OK
.... Reported 1 devices
.... Device Number | id
0001 | 0x0002
Attempt to acquire device 1:
OK
OK
eDeviceType = PVRSRV_DEVICE_ID_MBX1
byVersionMajor = 1
byVersionMinor = 3
Display Class API: enumerate devices
OK
OK
Display Class API: open device
Display Class API: enumerate display formats
OK
OK
Display Class API: enumerate display dimensions
OK
OK
Display Class API: get the system (primary) buffer
OK
Display Class API: get the sysphys addr from system buffer handle
OK
Display Class API: map sysphys addr to MBX
OK
Display Class API: get sync object for system surface
OK
Attempt to create command queue size 4096:
OK
Attempt to look inside command queue:
psQueueInfo->ui32ReadOffset = 0
psQueueInfo->ui32WriteOffset = 0
psQueueInfo->pvUserLinQueue = 0x4002c040
psQueueInfo->pvUserLinQueue[50] = 0
Attempt to create 2MB parameter buffer:
OK
-----Begin direct single blit: clear screen-----
Attempt to acquire SlavePort:
-----Completed direct single blit: clear screen-----
-----Begin multiple overlapping direct blits-----
-----Completed multiple overlapping direct blits-----
-----Begin multiple overlapping direct batch blits-----
-----Completed multiple overlapping direct batch blits-----
-----Begin multiple scheduled overlapping blits-----
-----Completed multiple scheduled overlapping blits-----
-----Begin slaveport write test (10485760 bytes) -----
-----Single write: Batch size = 220 bytes , 0.170000s , 60234.60kb/sec
-----Single write: Batch size = 100 bytes , 0.180000s , 56888.02kb/sec
-----Single write: Batch size = 40 bytes , 0.270000s , 37925.35kb/sec
-----Single write: Batch size = 20 bytes , 0.430000s , 23813.59kb/sec
-----Batch write: Batch size = 220 bytes , 0.170000s , 60233.34kb/sec
-----Batch write: Batch size = 100 bytes , 0.200000s , 51198.24kb/sec
-----Batch write: Batch size = 40 bytes , 0.280000s , 36570.17kb/sec
-----Batch write: Batch size = 20 bytes , 0.390000s , 26255.51kb/sec
----- slaveport write test finished-----
-----Begin memory bandwidth/alloc test (max size = 20971520 bytes, copy multiple = 10X)
-----Mem = 41 x 524288 bytes, (Alloc/Free/Copy) 0.02000s,0.04000s,2.71000s, 0.00049s/alloc, 0.00098s/free, 77461.25kb/sec
-----Mem = 81 x 262144 bytes, (Alloc/Free/Copy) 0.02000s,0.02000s,1.67000s, 0.00025s/alloc, 0.00025s/free, 124167.66kb/sec
-----Mem = 161 x 131072 bytes, (Alloc/Free/Copy) 0.06000s,0.05000s,1.63000s, 0.00037s/alloc, 0.00031s/free, 126429.45kb/sec
-----Mem = 321 x 65536 bytes, (Alloc/Free/Copy) 0.08000s,0.09000s,1.61000s, 0.00025s/alloc, 0.00028s/free, 127602.48kb/sec
-----Mem = 641 x 32768 bytes, (Alloc/Free/Copy) 0.12000s,0.19000s,1.60000s, 0.00019s/alloc, 0.00030s/free, 128200.00kb/sec
-----Mem = 1281 x 16384 bytes, (Alloc/Free/Copy) 0.40000s,0.58000s,1.61000s, 0.00031s/alloc, 0.00045s/free, 127304.35kb/sec
-----Mem = 2033 x 8192 bytes, (Alloc/Free/Copy) 0.62000s,1.17000s,1.28000s, 0.00030s/alloc, 0.00058s/free, 127062.50kb/sec
-----Mem = 2032 x 4096 bytes, (Alloc/Free/Copy) 0.69000s,1.17000s,0.65000s, 0.00034s/alloc, 0.00058s/free, 125046.15kb/sec
-----Mem = 4063 x 2048 bytes, (Alloc/Free/Copy) 0.94000s,1.40000s,0.65000s, 0.00023s/alloc, 0.00034s/free, 125015.38kb/sec
-----Mem = 8123 x 1024 bytes, (Alloc/Free/Copy) 1.60000s,1.60000s,0.65000s, 0.00020s/alloc, 0.00020s/free, 124969.23kb/sec
----- Memory bandwidth test finished (max mem = 21495808 bytes, address range = 008C0300 to 01CC1000) -----
Attempt to destroy parameter buffer:
OK
Attempt to destroy command queue:
OK
Display Class API: unmap system surface from MBX
Display Class API: close the device
PVRSRVReleaseMBXInfo:
OK
PVRSRVDisconnect:
Disconnecting client 242
OK
---------------------End loop 1---------------------
IMHO
The problem is warning while compiling omaplcd_linux.c and mmap.c about incompatible pointer type.
rlinfati
2010-02-20, 15:49
nokia800:/usr/local/bin# ./egl_test
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 7
Current serial number in output stream: 8
services_test run OK, module load, mbxdaemon running, device chmod'ed 666
omaplcd_linux.c:
irqreturn_t vsync_isr(int irq, void *dev_id, struct pt_regs *regs)
should be
static irqreturn_t vsync_isr(int irq, void *dev_id)
Also in mmap.c
function define as PKV_OFFSET_STRUCT *PVRMMapRegisterArea
but return PKV_OFFSET_STRUCT
javispedro
2010-02-20, 17:14
Apologies if I missed the obvious here, but does this driver enable Jazelle, or just 3D acceleration?
Why, 3D, of course (as the title says).
Angelochelotti
2010-02-20, 18:45
there's any tutorial to install the driver? it's safe?
someone install it succesfuly?
there's any tutorial to install the driver? it's safe?
someone install it succesfuly?
No.
No.
No.
No.
No.
No.
:D
Padding to lengthen the message...
BoxOfSnoo
2010-02-21, 02:21
Why, 3D, of course (as the title says).
NO WAY! Are you referring to the same thread where someone says on the very first page...
The processor used in the tablets is an OMAP2 ARM(EL) processor manufactured by Texas Instruments. This chip is used in a wide variety of mobile devices and is a "packaged" chip meaning it's not just a CPU. It's a CPU with onboard ram, included video chip, 3d accelerator, hardware mpeg processing, java bytecode interpreter etc. However, not all these features are used on every device.
On our tablets, the 3d and the video chip are not utilized because they don't support a screen of the resolution the tablets have. The LCD is handled by a third party (Epson) chip.
Also missing is drivers for the hardware Java interpreter (Jazelle) but this is due to a licensing issue if I remember correctly.
How could I be so stupid an insensitive as to ask if this was part of the package released by TI???
I send two messages to gamingonomap@list.ti.com regarding OpenGL ES SDK, however, they didn't respond yet.
What should I tell to them in order to get the SDK?
I send two messages to gamingonomap@list.ti.com regarding OpenGL ES SDK, however, they didn't respond yet.
What should I tell to them in order to get the SDK?Did you write the name of SDK you want to download?
See post #425 (http://talk.maemo.org/showthread.php?p=528791#post528791) or #436 (http://talk.maemo.org/showthread.php?p=533273#post533273) or similar guide for SGX http://code.google.com/p/beagleboard/wiki/HowtoUseSGXunderAngstrom "Step I: Obtain the Graphics SDK from TI". This did the trick for me:
Hello,
I'd like to download "OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21"
I already have my.TI account with e-mail ...@...
Thanks.
Did you write the name of SDK you want to download?
See post #425 (http://talk.maemo.org/showthread.php?p=528791#post528791) or #436 (http://talk.maemo.org/showthread.php?p=533273#post533273) or similar guide for SGX http://code.google.com/p/beagleboard/wiki/HowtoUseSGXunderAngstrom "Step I: Obtain the Graphics SDK from TI". This did the trick for me:
Thanks. What I was curious about is that I wrote what I want but there was no reply. Creating my-TI account made the trick.
That said, I'll be writing up a guide either tomorrow or on monday and post it on blog, on how to get them working so people can start hacking on them.
That would be great :-) Maybe a Wiki page would do too.
Also what are ideas about further cooperation and code sharing wrt fixing the GPL-ed kernel part? Wiki page with progress/developer comments, IRC, some mailing list?
Stskeeps
2010-02-22, 11:15
Was looking around to see where the 3D accelerator drivers can actually help things without having to render straight to screen:
* Cairo backend targetting OpenVG (GTK+ would benefit from this?)
* Qt4.6 accelerated QGraphicsView targetting OpenVG. UIEmo could take benefit from this?
Other things on N8x0 that can take benefit from OpenVG?
Anyone had any luck? I wasn't even able to get to the point where svs57 is now.
Stskeeps
2010-02-22, 11:55
Right, small tutorial:
You need to flash the zImage that is there, it is basically Diablo kernel + higher DMA memory available.
Copy lib*.so lib*.a to /usr/lib, run ldconfig
Copy glinfo, egl_test, mbxdaemon, ovg_demos, ovg_test, power_test, pvr2d_test, services_test, xegl_test, xovg_test, xtest to /usr/bin
You have two .ko's, mbxaccess and omaplcd.ko. You need to insmod mbxaccess.ko first, then omaplcd.ko
You need to then set up some device nodes (after mbxaccess and omaplcd is loaded);
mbxaccess_maj=`grep ""mbx"$" /proc/devices | cut -b1,2,3`
/bin/rm -f /dev/mbx
/bin/mknod /dev/mbx c $mbxaccess_maj 0
disp_maj=`grep "omaplcd$" /proc/devices | cut -b1,2,3`
/bin/rm -f /dev/omaplcd
/bin/mknod /dev/omaplcd c $disp_maj 0
chmod a+rw /dev/mbx /dev/omaplcd
You can now start mbxdaemon
Verify with ./glinfo. Perhaps ./services_test. Perhaps test ./xegltest as 'user' in X-terminal. Nothing fancy will show, but at least the drivers seem to work. Keep in mind that this is first step, it's now up to you to see if you can get something sane out of it. I stated some potential things above (cairo accelerated?)
This is exactly what I was doing, but it doesn't seem to be working on my device, for some reason. Tried strace, and gdb on glinfo, but came up with nothing. :(
Stskeeps
2010-02-22, 12:09
That would be great :-) Maybe a Wiki page would do too.
Also what are ideas about further cooperation and code sharing wrt fixing the GPL-ed kernel part? Wiki page with progress/developer comments, IRC, some mailing list?
Well, I'm up for anything - I guess a wiki page would be useful and a mailing list, maybe a garage project would be in order?
Stskeeps
2010-02-22, 12:13
This is exactly what I was doing, but it doesn't seem to be working on my device, for some reason. Tried strace, and gdb on glinfo, but came up with nothing. :(
Posted it a little too early, try again?
Would have helped had I known the test programs require regular user account, and not root :confused: Anyway, still hitting some problems:
----------------------- Start -----------------------
Try calling PVRSRVConnect an invalid argument:
PVR_SRVUM:(Error): PVRSRVConnect: Invalid parameter [119, /home/girish/Graphics/Nokia/embedded/services_um/env/linux/pvr_glue.c]
OK
Call PVRSRVConnect a valid argument:
PVR_SRVUM:(Error): Cannot open device driver /dev/pvrsrv.
[79, /home/girish/Graphics/Nokia/embedded/services_um/env/linux/pvr_bridge_u.c]
FAIL - PVRSRV_ERROR_INIT_FAILURE
PVR_SRVUM:
PVR_SRVUM:Memory Stats
PVR_SRVUM:------------
PVR_SRVUM:
PVR_SRVUM:High Water Mark = 0 bytes
Can not open device /dev/pvrsrv . Where did this come from?
EDIT:
My bad. The device in question appears to be /dev/mbx for which I did not set proper permissions. After doing so, glinfo just hangs again...
It appears root/user has no effect after all... :(
Stskeeps
2010-02-22, 13:14
Would have helped had I known the test programs require regular user account, and not root :confused: Anyway, still hitting some problems:
Can not open device /dev/pvrsrv . Where did this come from?
Which test app does this come from?
Which test app does this come from?
It was from services_test.
An interesting point. When running glinfo and services_test, through strace, they both seem to hang at the very same spot:
open("/tmp/mbx/txfifo", O_WRONLY
This time I double checked the file in question has permissions set to read/write for all users/groups.
Stskeeps
I did what you wrote.
I compiled kernel with
CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=8
and flashed it.
I compiled and installed kernel modules (debug version),
created and set perms for devices.
When I start glinfo kernel crashed
[ 999.296875] No flipbuffers
[ 999.304687] mbxdaemon: page allocation failure. order:8, mode:0xd0
[ 999.304687] [<c002c168>] (dump_stack+0x0/0x14) from [<c008204c>] (__alloc_pages+0x2c0/0x2d4)
[ 999.304687] [<c0081d8c>] (__alloc_pages+0x0/0x2d4) from [<c002dd20>] (__dma_alloc+0x184/0x3e4)
[ 999.304687] [<c002db9c>] (__dma_alloc+0x0/0x3e4) from [<c002dfa4>] (dma_alloc_coherent+0x24/0x30)
[ 999.304687] [<c002df80>] (dma_alloc_coherent+0x0/0x30) from [<bf072c2c>] (AllocContiguousMemory+0x30/0x6c [omaplcd])
[ 999.304687] [<bf072bfc>] (AllocContiguousMemory+0x0/0x6c [omaplcd]) from [<bf072d3c>] (GetBackBuffer+0xa8/0xc0 [omaplcd])
[ 999.304687] r6 = 00000001 r5 = 00000000 r4 = 00000000
[ 999.304687] [<bf072c94>] (GetBackBuffer+0x0/0xc0 [omaplcd]) from [<bf07243c>] (InitMain+0x19c/0x250 [omaplcd])
[ 999.304687] r6 = C890C00C r5 = C890C000 r4 = 00000000
[ 999.304687] [<bf0722a0>] (InitMain+0x0/0x250 [omaplcd]) from [<bf073544>] (OMAPLCDBridgeDispatch+0x408/0x460 [omaplcd])
[ 999.304687] [<bf07313c>] (OMAPLCDBridgeDispatch+0x0/0x460 [omaplcd]) from [<c00a9bf4>] (do_ioctl+0x74/0x84)
[ 999.304687] r6 = BEF400CC r5 = FFFFFFE7 r4 = C3FD50C0
[ 999.304687] [<c00a9b80>] (do_ioctl+0x0/0x84) from [<c00a9e9c>] (vfs_ioctl+0x298/0x2b8)
[ 999.304687] r6 = 00000000 r5 = BEF400CC r4 = C3FD50C0
[ 999.304687] [<c00a9c04>] (vfs_ioctl+0x0/0x2b8) from [<c00a9f28>] (sys_ioctl+0x6c/0x94)
[ 999.304687] r7 = 00000008 r6 = BEF400CC r5 = 00000000 r4 = C3FD50C0
[ 999.304687] [<c00a9ebc>] (sys_ioctl+0x0/0x94) from [<c0027be0>] (ret_fast_syscall+0x0/0x2c)
[ 999.304687] r8 = C0027D88 r7 = 00000036 r6 = 00009190 r5 = 0000B478
[ 999.304687] r4 = 40022DB8
[ 999.304687] Mem-info:
[ 999.304687] DMA per-cpu:
[ 999.304687] CPU 0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 13
[ 999.304687] Active:20332 inactive:6234 dirty:1 writeback:0 unstable:0
[ 999.304687] free:471 slab:1598 mapped:7451 pagetables:551 bounce:0
[ 999.304687] DMA free:1884kB min:1440kB low:1800kB high:2160kB active:81328kB inactive:24936kB present:130048kB pages_scanned:16 all_unreclaimable? no
[ 999.304687] lowmem_reserve[]: 0 0
[ 999.304687] DMA: 21*4kB 11*8kB 7*16kB 6*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1884kB
[ 999.304687] Swap cache: add 0, delete 0, find 0/0, race 0+0
[ 999.304687] Free swap = 250712kB
[ 999.304687] Total swap = 250712kB
[ 999.304687] Free swap: 250712kB
[ 999.328125] 32768 pages of RAM
[ 999.328125] 794 free pages
[ 999.328125] 2728 reserved pages
[ 999.328125] 1598 slab pages
[ 999.328125] 28692 pages shared
[ 999.328125] 0 pages swap cached
[ 999.328125] AllocContiguousMemory: unable to allocate contiguous memory of bb800
[ 999.328125] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<6>PVR_KERNL:(Error): Failed to find offset struct (KVAddress=c8abd000)
[ 1000.671875] [567, /opt/3d/MBX_Linux_KM/embedded//services/env/linux/mmap.c]
[ 1000.671875] PVR_KERNL:(Error): Failed to find offset struct (KVAddress=c891a000)
[ 1000.671875] [567, /opt/3d/MBX_Linux_KM/embedded//services/env/linux/mmap.c]
[ 1000.671875] PVR_KERNL:(Error): Failed to find offset struct (KVAddress=c8914000)
[ 1000.671875] [567, /opt/3d/MBX_Linux_KM/embedded//services/env/linux/mmap.c]
[ 1000.679687] PVR_KERNL:(Error): Failed to find offset struct (KVAddress=c8912000)
[ 1000.679687] [567, /opt/3d/MBX_Linux_KM/embedded//services/env/linux/mmap.c]
glinfo output:
glinfo
PVR_SRVUM:(Warning): Hint: Setting WindowSystem to libpvrX11WSEGL.so [192, /home/girish/Graphics/Nokia/embedded/services_um/env/linux/pvr_apphint.c]
PVR_DMSRV:HostMapPhysToLin: Mapped 0x48050000, 0x1000 bytes to 0xc8910000
PVR_DMSRV:HostMapPhysToLin: Mapped 0x80600000, 0xbc000 bytes to 0xc8a00000
**********************************
Config num 1
EGL vendor string: Imagination Technologies
EGL version string: 1.2 build 3.5.35.630
EGL extensions:
EGL_IMG_power_management
EGL config Attributes:
EGL_CONFIG_ID = 0x1
EGL_BUFFER_SIZE = 0x10
EGL_ALPHA_SIZE = 0x0
EGL_BLUE_SIZE = 0x5
EGL_GREEN_SIZE = 0x6
EGL_RED_SIZE = 0x5
EGL_DEPTH_SIZE = 0x18
EGL_STENCIL_SIZE = 0x0
EGL_CONFIG_CAVEAT = 0x3038
EGL_LEVEL = 0x0
EGL_MAX_PBUFFER_HEIGHT = 0x400
EGL_MAX_PBUFFER_PIXELS = 0x1fc000
EGL_MAX_PBUFFER_WIDTH = 0x7f0
EGL_NATIVE_RENDERABLE = 0x0
EGL_NATIVE_VISUAL_ID = 0x21
EGL_NATIVE_VISUAL_TYPE = 0x151a8
EGL_SAMPLES = 0x0
EGL_SAMPLE_BUFFERS = 0x0
EGL_SURFACE_TYPE = 0x5
EGL_TRANSPARENT_TYPE = 0x3038
EGL_TRANSPARENT_BLUE_VALUE = 0x0
EGL_TRANSPARENT_GREEN_VALUE = 0x0
EGL_TRANSPARENT_RED_VALUE = 0x0
PVR_SRVUM:(Error): GLESTimeNow: not implemented [81, linux_os.c]
PVR_DMSRV:ui32PageTableBase = 8c2000
PVR_DMSRV:ui32StartPage = 1
PVR_DMSRV:ui32EndPage = 200
PVR_DMSRV:ui32ParamBase = 0
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 7
Current serial number in output stream: 8
PVR_SRVUM:
PVR_SRVUM:Memory Stats
PVR_SRVUM:------------
PVR_SRVUM:
PVR_SRVUM:High Water Mark = 25304 bytes
PVR_SRVUM:
PVR_SRVUM:18088 bytes still allocated in 35 allocations
PVR_SRVUM:
PVR_SRVUM:1 - 40 bytes at 0x1F128 - services_calls.c:39
PVR_SRVUM:2 - 32 bytes at 0x1EF88 - cfg_core.c:267
PVR_SRVUM:3 - 24 bytes at 0x1EFB0 - cfg_core.c:54
PVR_SRVUM:4 - 128 bytes at 0x1F0A0 - cfg_core.c:267
PVR_SRVUM:5 - 24 bytes at 0x1EF48 - cfg_core.c:54
PVR_SRVUM:6 - 24 bytes at 0x1EF08 - cfg_core.c:54
PVR_SRVUM:7 - 104 bytes at 0x1EE78 - khronos_egl.c:2220
PVR_SRVUM:8 - 40 bytes at 0x1EE28 - ./common/heapman.c:56
PVR_SRVUM:9 - 1288 bytes at 0x1E8F8 - ./common/dvcgen.c:1016
PVR_SRVUM:10 - 12 bytes at 0x15380 - names.c:631
PVR_SRVUM:11 - 508 bytes at 0x1E6B8 - names.c:585
PVR_SRVUM:12 - 28 bytes at 0x1E678 - names.c:578
PVR_SRVUM:13 - 648 bytes at 0x1E3C8 - vprogram.c:1424
PVR_SRVUM:14 - 12 bytes at 0x14E30 - names.c:631
PVR_SRVUM:15 - 508 bytes at 0x1E188 - names.c:585
PVR_SRVUM:16 - 28 bytes at 0x1E148 - names.c:578
PVR_SRVUM:17 - 524 bytes at 0x1DF18 - tex.c:7172
PVR_SRVUM:18 - 524 bytes at 0x1DCE8 - tex.c:7172
PVR_SRVUM:19 - 12 bytes at 0x1AAC0 - names.c:631
PVR_SRVUM:20 - 508 bytes at 0x1DAA8 - names.c:585
PVR_SRVUM:21 - 28 bytes at 0x1DA68 - names.c:578
PVR_SRVUM:22 - 48 bytes at 0x1AA88 - /home/girish/Graphics/Nokia/embedded/services_um/env/linux/pvr_glue.c:686
PVR_SRVUM:23 - 524 bytes at 0x1D838 - tex.c:7368
PVR_SRVUM:24 - 32 bytes at 0x14DC8 - tex.c:7354
PVR_SRVUM:25 - 11480 bytes at 0x1AB58 - eglglue.c:60
PVR_SRVUM:26 - 32 bytes at 0x14DA0 - cfg_core.c:267
PVR_SRVUM:27 - 24 bytes at 0x1A938 - cfg_core.c:54
PVR_SRVUM:28 - 128 bytes at 0x1AAD0 - cfg_core.c:267
PVR_SRVUM:29 - 24 bytes at 0x14D80 - cfg_core.c:54
PVR_SRVUM:30 - 24 bytes at 0x1A978 - cfg_core.c:54
PVR_SRVUM:31 - 140 bytes at 0x1A9D8 - khronos_egl.c:3743
PVR_SRVUM:32 - 40 bytes at 0x15330 - ./common/pvr2dinit.c:485
PVR_SRVUM:33 - 48 bytes at 0x14E70 - /home/girish/Graphics/Nokia/embedded/services_um/env/linux/mbx/mbx_glue.c:679
PVR_SRVUM:34 - 356 bytes at 0x1A500 - ./common/pvr2dinit.c:356
PVR_SRVUM:35 - 144 bytes at 0x12018 - tls.c:47
PVR_SRVUM:
Problems reading from a client. Disconnecting
Disconnecting client 133
PVR_DMSRV:(Warning): Free stale HW Context ID [1224, /home/girish/Graphics/Nokia/embedded/services/devices/devclass_3d/mbx/mbxinit.c]
PVR_DMSRV:(Warning): Free stale HW Context ID [1224, /home/girish/Graphics/Nokia/embedded/services/devices/devclass_3d/mbx/mbxinit.c]
Messages while compiling modules:
make BUILD=debug KBUILD=1 all
! ======================= MBX GPL BUILD ==============================:
! DATE: пн фев 22 2010 16:46:19 MSK
! PWD: /opt/3d/MBX_Linux_KM/embedded/build/omap2420_linux
!
! SETTINGS:
!
! PVRVERSION: 3.5.35.630
! KERNELVERSION: 2.6.21
! BUILD=debug
! PVR_BUILD_DIR=omap2420_linux
! SYSTEM=omap24xx
! CROSS_COMPILE=arm-none-linux-gnueabi-
! TOOLCHAIN=/DATA/toolchain/arm-2007q3
! KERNELDIR=/usr/src/kernel-source-diablo
!
! ALL_CFLAGS=-DLINUX -DPVR_BUILD_DIR="omap2420_linux" -DPVR_BUILD_DATE="пн фев 22 2010 16:46:18 MSK" -DPVR_BUILD_TYPE="debug" -DDEBUG -g -O0 -DBLIT -DMONTAVISTA_PM -DOMAP2420 -DVIPT_MMAP_COLOUR -DREENTRANCY_PROTECTION -DUSE_TERMINATE_WORD -DSUPPORT_XWS -UUSE_TERMINATE_WORD -DOPENGLES1_1 -DSUPPORT_POWER_MANAGEMENT -DEXTENDED_COLOR_MATERIAL -DPVRTC -DSINGLE_PRECISION -DUSER_CLIPPLANES -DTEXENVCOMBINE -DTEXENVDOT3 -DQUERY_MATRIX -DVERTEX_PROGRAM -DTEXTURE_STREAM -DMATRIX_PALETTE -DRENDER_TO_TEXTURE -DDRAW_TEXTURE -DSUPPORT_DYNAMIC_PBRESIZE -DUSE_FBDEV -DFBDEV_NAME="/dev/fb/0" -DREAD_FORMAT -DSUPPORT_MBX_1_5_FEATURES -DTEXTURE_FORMAT_8888 -DSCHEDULER_CONTROL_SUPPORT -DUSE_IMG_POWER_DOMAIN_FUNCTION -DMULTI_DRAW_ARRAYS -DDYNAMIC_VERTEX_CODE_GEN -DEGL1_2 -DFAST_TWIDDLE_16BPP -DFAST_TWIDDLE_32BPP -DSUPPORT_OPENGL -DSUPPORT_OPENVG -DSUPPORT_HW_RECOVERY -DKBUILD -DMBX_GPL -DUPCONVERT_SINGLE_CHANNEL_TEXTURES -DPRN_ENABLE=defined -Wall -fno-strict-aliasing
!
! ALL_INCLUDES=
!
! SYSBIN is
! /opt/3d/MBX_Linux_KM/embedded/binary_omap2420_linux_debug
!
! TARGET=all
!
+gpl/driver
Compiling mbxaccess.c
mbxaccess.c:172: warning: 'powervr_device' defined but not used
Compiling malloc_debug.c
Compiling /opt/3d/MBX_Linux_KM/embedded/services/env/linux/mmap.c
/opt/3d/MBX_Linux_KM/embedded/services/env/linux/mmap.c: In function `PVRMMapRegisterArea':
/opt/3d/MBX_Linux_KM/embedded/services/env/linux/mmap.c:455: warning: return from incompatible pointer type
/opt/3d/MBX_Linux_KM/embedded/services/env/linux/mmap.c:479: warning: return from incompatible pointer type
Compiling mbxaccess_iowrapper.c
Compiling mbxaccess_mbxmem.c
Compiling mbxaccess_memwrapper.c
Compiling mbxaccess_mmapwrapper.c
Compiling mbxaccess_procwrapper.c
Compiling mbxaccess_pvrclassjtable.c
Compiling mbxaccess_timerwrapper.c
Compiling mbxaccess_virtmemwrapper.c
Compiling /opt/3d/MBX_Linux_KM/embedded/services/env/linux/mm.c
Compiling /opt/3d/MBX_Linux_KM/embedded/services/env/linux/mutex.c
Compiling /opt/3d/MBX_Linux_KM/embedded/services/env/linux/pvr_debug.c
Linking pre-processed kernel module tmp_omap2420_linux_debug_mbxaccess.ko/mbxaccess.core.o
Performing module post processing
Compiling mbxaccess.core.mod.c
Linking post-processed kernel module bin_omap2420_linux_debug_mbxaccess.ko/mbxaccess.ko
Copying bin_omap2420_linux_debug_mbxaccess.ko/mbxaccess.ko to /opt/3d/MBX_Linux_KM/embedded/binary_omap2420_linux_debug
-gpl/driver
+3rdparty/omap24xx_lcd/kernel
Compiling omaplcd_displayclass.c
Compiling omaplcd_linux.c
omaplcd_linux.c: In function `AllocContiguousMemory':
omaplcd_linux.c:261: warning: unsigned int format, IMG_UINT32 arg (arg 2)
omaplcd_linux.c: In function `InstallVsyncISR':
omaplcd_linux.c:498: warning: passing arg 2 of `request_irq' from incompatible pointer type
Linking pre-processed kernel module tmp_omap2420_linux_debug_omaplcd.ko/omaplcd.core.o
Performing module post processing
Compiling omaplcd.core.mod.c
Linking post-processed kernel module bin_omap2420_linux_debug_omaplcd.ko/omaplcd.ko
Copying bin_omap2420_linux_debug_omaplcd.ko/omaplcd.ko to /opt/3d/MBX_Linux_KM/embedded/binary_omap2420_linux_debug
-3rdparty/omap24xx_lcd/kernel
Creating /opt/3d/MBX_Linux_KM/embedded/binary_omap2420_linux_debug/install.sh
Creating /opt/3d/MBX_Linux_KM/embedded/binary_omap2420_linux_debug/rc.pvr
I did use a custom built kernel, but with it, the device could not even boot. This is the config I used for it http://inz.fi/nokia_2420_defconfig. Of course I set the CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE to 8.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.