Caanoo / WIZ Non-Proprietary / Open Source Opengl (Es) Driver For Wiz ?

[hiben]

I'm currently experimenting with getting a completely open Linux running on the Wiz.
So far most things are supported: I have a custom bootloader, a custom kernel that recognizes the hardware and the needed resources to unbrick the device...

The only thing that is really problematic is having support for OpenGL (ES, lite, whatever). The driver from the firmware is closed source and I don't want to use
the precompiled library (because I do not know how long it will play well with other libs). The hardware is recognized by the kernel but the module only exposes the registers of the card. Having anything like OpenGL would be really nice because even the LF1000 can do some graphic work while the CPU can do other things...

The Wiz Wiki mentions that somebody is working on reverse engineering the driver but I could not find anything on this (are you there ? making progress ? ).
I spent the last half hour reading the LF1000 databook and it seems that the hardware is quite well documented (if the information is correct...). I'm thinking of trying myself to code something but I estimate that this will take at least a year before the first results are there.

So: does anyone know if there is some open source support for the chipset ? Maybe a patch against Mesa or something ?

I'm not an expert on how OpenGL libraries are found by the various abstractions (GLUT, SDL, DirectFB, ...) so maybe I'm not looking in the right direction. If someone feels I'm on the wrong track please let me know...

 

[Pickle]

your chances of having an opensource driver are basically none.

 

[skeezix]

Also, see Open2x .. Not sure if theres a wiz version but I always used it on gp2x f100/f200 .. You can roll your own but they've done it before so likely helpful for ya

Jeff

 

[hardyx]

I studied for months the 3D hardware in Pollux and is very complex to create an OGL driver for this. I recommend you use the closed source driver or create a simple driver (lot of work). I think the GPU can be programmed with a little library for make floating point operations too, I'm investigating in this direction. Reverse engineering the driver? Don't waste your precious time in this, is very difficult.

 

[Orkie]

JustBurn wrote some code to draw/texture polygons and I think do rotations directly with the hardware, and he was looking lighting if I recall correctly.

 

[hiben]

Thanks for all the replies!

From what I've read, doing 'simple' raster transformations (rotating the whole screen) is a lot simpler than involving matrix calculations in the process.
I am also tempted to use the chip first as a floating point co-processor as suggested in the databook. This could be a solid foundation for a driver.

In the meantime I did some research on how DirectFBGL is working and I think this would be a nice starting point. In the end, having an EGL compliant driver is the way to go. I will try to develop in this direction but don't hold your breath. Currently I am motivated just to see how far I can get but maybe I'll give this up when I get my next poorly documented gadget... ;-)

I will share any results - if there are any - so maybe some younger, more idealistic person with a lot of free time can pick this up

 

[hiben]

Just to keep this alive:

A fellow nerd told me how he hacked into Adobes flashplayer plugin once to 'fix some features' and this made me realize a new way of approaching the GL driver issue. Instead of trying to code drivers from scratch I'll have a look at the disassembly of the binary drivers and try to draw some conclusions.

First investigations show that the GL driver is compiled from/uses C++ code so it gets a bit messy in the disassembled code. On the other hand ARM is relatively simple...

 

[crow_riot]

just to let you know, there was a package around called "wiz_data.exe", which leaked/included the pollux manual and IIRC a sample driver implementation for the LF1000 for WindowsCE.
Let me know if you're interested, i think i may still have it lying around somewhere on my old pc.

 

[hiben]

just to let you know, there was a package around called "wiz_data.exe", which leaked/included the pollux manual and IIRC a sample driver implementation for the LF1000 for WindowsCE.
Let me know if you're interested, i think i may still have it lying around somewhere on my old pc.

Thanks for the offer but I already have that file.
While there is a Windows CE driver in this file it is only shipped as a DLL.
There is however an interesting source/implementation (for linux) of the OAL layer (used by EGL) that shows the correct memory mapping. I did not see it before and just discovered it along the samples.
The sample GLES application(s) using that implementation however only lookup my Wiz (but there is some moving garbage on the screen so there is hope... ).

 

[StarG]

Hiben: maybe contacting FSF is helpful. They announced the necessity for having a FLOSS PowerVR driver. Check here:

http://libreplanet.org/wiki/GroupowerVR_drivers

Drawback is that they mainly target the SGX series and there is little to announce yet. My best bet would be to use a hacked up Mesa driver with specific patches to spit out hw polys instead of sw rasterisation (thereby skipping hw TnL stage and sacrificing performance) in the sake of simplicity.

As Orkie said JustBurn explored the register space too and i think he said something alike "i can draw polys".

 

[hiben]

I really appreciate any effort the FSF is doing to get open source or even free software drivers but I don't really think there will be success before the hardware is really obsolete in the consumer market (~5-10 years IMHO)...

Contacting them will neither help them nor me since what they need is somebody with influence on the market and not someone who just wants to use weird hardware.

It is good to know that some people can draw accelerated polys with the hardware. Having real transformations on the other hand would just open up so much more possibilities...

 

[StarG]

I agree with the latter. The transformations themselves could be refitted for other uses even.

As with the FSF issue i think thats pretty clever of them. If this works out and they can assemble a working driver this probably starts a shift in driver-openness in mobile sector too. As the majority of todays SoC still use mostly Imagination-based GPU's and they consist of 2 main lines now: the old MBX line and the new SGX one. According to their PR:

The architecture will be upward-compatible with the current, widely used Series5, "ensuring a smooth migration path for developers upgrading applications optimized for Series5 to the new architecture,"

Source: http://www.linuxfordevices.com/c/a/News/Imagination-Technologies-Powervr-Series6/

Creating a driver for the latter class probably means that you could interface GPUs still to ship. Hereby creating a bit of selection pressure for the upcoming contenders in the segment.

Back to topic of course. Yes its no real help as of now. Your guess is a bit harsh but not out of scope generally. With a small dedicated team i guess 2-3 years would be enough to get some real work done. As of now i'd go the least effort, most effect route. Have you thought about using a Ginge-like wrapper around the commercial blob and start dumping the data it receives from applications and maybe combining it with a memory dumper? e.g. have the application do some gl_init() and enter jtag single step mode. Do a step and do a full memory dump. (repeat) Then look what memory cells the app did changes too. Should be possible to correlate the registers needed to do a proper setup.

 

[hiben]

...

Back to topic of course. Yes its no real help as of now. Your guess is a bit harsh but not out of scope generally. With a small dedicated team i guess 2-3 years would be enough to get some real work done. As of now i'd go the least effort, most effect route. Have you thought about using a Ginge-like wrapper around the commercial blob and start dumping the data it receives from applications and maybe combining it with a memory dumper? e.g. have the application do some gl_init() and enter jtag single step mode. Do a step and do a full memory dump. (repeat) Then look what memory cells the app did changes too. Should be possible to correlate the registers needed to do a proper setup.

The problem with the graphics adapter here is that it is controlled by memory mapped IO (and an interrupt). I would need to catch every write in the register range with known GL commands. This could work but even if I get the CPU in single step mode - (is JTAG working ? I've seen the pinout but no one seems to have used it...) (I could borrow an adapter from work on a rainy weekend and see how far I get...) - I'm not sure if the GPU will also single step...
I'm no expert on ARM or JTAG... sounds like painful, unrewarding work... ;-) ...uploading textures will be real fun in single step...

I think I'll first proceed with my disassembling approach - I was a bit sidetracked with debian on the wiz and did not start yet.

Wrapping things could only help in minor situations because the API is already known (EGL / GL ES).