I am currently trying to get OpenGL ES running on the Bone, but I get some problems with the kernel modules. I already posted on the TI formus. Maybe someone can help:
See a few of the other threads in this forum for the full details on
this.. Essentially we do not have the needed bits from TI at this
What exactly is missing? I have read something about that the clock for GPU is not enabled. Can’t we fix this or can’t we get TI to fix this?
As I understand it, the DRM driver is not compatible with the old SGX frame buffer architecture. TI tells us they are not rewriting the code for 3.8. Not sure about future kernel releases. Best bet would be to ask TI on this one.
It seems to me not very fair to say we have a board with a 3d accelerator, we sell it and we won’t give you the driver nor the specs to use it…
To my understanding with 3.2 kernel it was working. Any advice on how to resume a working 3.2 distribution I may use?
You don’t have a most recent Kernel that is working correctly with the SGX drivers ?
3.2 it’s very old …
It seems that such a kernel doesn’t exist and reading last Gerald post (as always thank you for the support) it could never exist again…
In my project I’ll use two beagle : one for embedded layer (in which I’m using 3.8.13 - xenomai patched) one for the gui, in which I don’t need more than HDMI e OpenGl support…
Life is not always fair, especially when SW is involved. The new DRM architecture introduced by the Linux folks in the 3.8 Kernel broke it. I agree, that is not fair.
Gerald I didn’t want to upset you. Your support is certainly first class.
But this is the way linux works and works good. Things keep changing,
I think that one couldn’t blame linux folks for their work… and really it seems a little strange to me that for a company so big like TI is difficult to implement the needed update…
Oh, I know.I am not blaming anyone, Just sting fact. Yes TI is a big company as a whole. But when you look at the number of people that work on specific things, well let’s just say not all of TI employees are working on Linux. And those that are working on Linux are not working on 3.8 but 3.12 and later,
So, maybe … we should to move to 3.12 ?
Robert Nelson, I saw something in the mailing list about that =>
I've already personally moved to v3.12.x on everything..
But we need 'someone' to find the time too port all the "capes" *.dtbs
bits from the v3.8.x branch to the new v3.12.x branch. (the capemanger
is in place with v3.12.x)
I'm on the road next week with ARM techconn/etc going on, so i'm going
to be very hands off the next week or so.
Well, I will try to change the dtbs file for the cap LCD7 REVA3 & the cap RS485 .
Thx for this tutorial : http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
Is the 3.2 kernel SGX driver open source and simply too complex for the voluntary community to port to 3.8+ in their spare time (In which case we could start a kickstarter or something to fund someone to work full time on this bug)? Or is the driver proprietary, and the community is simply at the mercy of TI?
Driver is licensed. Circuitco has access to the driver under NDA, but they don’t have the resources any more. You might be able to ping them and see if something can be worked out. TI will have support for it, eventually. Like 2014 sometime. I am trying to accelerate that , but no promises.
Only the kernel "shim" is open source, well it also uses the in-kernel
framebuffer driver to draw directly into..
To give you an idea of what we are dealing with, take a look at this:
I try to copy the gpl bits from every sdk release, that a bunch of us
can more easily patch the bits to later kernel releases's.
In the case of the bone.. The 3.2 bits use the old frame buffer
driver, and with 3.8/3.12 we are using the brand new and shiny kms
I would like to help. I can contribute both a little bit of time, and also a little bit of money. I am a software developer and very comfortable working with C, but my knowledge of kernel development is extremely limited.
Does this repo contain a compilable binary that needs to have bugs fixed and features completed (I’m away from my development machine until Sunday)?
Nope, it's just the "shim" between the kernel and sgx closed bins..
The real trick would be for someone to reverse engineer the "sgx bits"
and just get us out of this mess all together..
But if we move to the kernel 3.12, the sgx will work?