Let's continue with our details about what's happening. This time with...
1. Wifi, Audio and the SGX --------------------------
We want as few binary blobs as possible, but there's probably no way to get a Wifi chip without a firmware blob (the driver will be open though!). While not yet fully decided, we'll most probably use the WG7351 from Jorjin: http://www.jorjin.com.tw/#!wg7351-00/c1dnh
We've got a small concern as drivers are not being developped by TI anymore for the WiLink6 chipsets but only for the WiLink8, but then again, if the WiLink6 drivers work reliable and support all features without issues, there won't be a need for more updates.
Right now, Jorjin suggests to use the WiLink6 modules as they work without issues and there still seem to be some with WiLink8 modules. Of course, if we get issues with the WG7351, we'll switch to a different one.
If you know of any other small modules with good Linux drivers we can get, feel free to suggest them here :)
This brings me to the next binary blobs: The SGX. As you know, we can't choose our own GPU, we need to live with whatever GPU we get with the SoC. The OMAP5 has Imaginations SGX, which is know to only work with a binary blob (same on the Pandora).
While it's not great, it's still acceptable - but there's one issue: There are two small binary blobs that make our life harder. One is a library linked to MESA - so to use a more recent version of MESA (the blob from TI supports the one from Ubuntu 12.04), we need to recompile that small library. Similar with a second one: It's the one that offers X.Org support. Unfortunately, TI has removed X.Org support in favour of Wayland in their latest driver versions, so we need to be able to change that one as well.
I'm already in contact with TI to find a solution and try to get these little parts opened (at least for us). The other way would be to recreate these libraries ourselves (which is possible, just takes a bit of time). notaz suggests to recreate the libraries anyways, because it would be hassle-free for us in the future.
Next, let's move to audio... audio? Binary blob? Well... we feared that at first, but it looks like we don't need one.
I know I told you that we'll re-use Pandoras awesome audio setup - however, it could be that it's not easily possible, as the OMAP5 has different outputs than the OMAP3. Also, we need more audio outputs than with the Pandora (3G/4G, etc.), which makes things even more complex.
TI offers the TWL6040, which is optimized for work with the OMAP5 and offers all the features we need. According to specs, it should have the same good quality as Pandoras Burr-Brown DAC, but I won't believe spec sheets, I will test that! As you might know, my main job is doing audio / video stuff in broadcast (TV) area. We've got plenty of professional measurement devices, and I'll use them to test both Pandoras and Pyras output and compare them. I surely don't want worse audio.
A certain part (AESS Codec) needs a binary blob. At first we thought we need that Codec for standard audio output - but it turned out we don't. We can easily use an open codec, but with the AESS Codec, we could use audio hardware effects (like an equalizer, etc.)
I hope to do some audio testings soon and let you know (and listen to) the results :)
2. The OS ---------
I didn't have much time to do anything there during the last two weeks, but aTc has been slowly working on it, created a debian package of fbturbo, and I hope I'll find the time to setup a repository and build server next week (with help from aTc and other chaps).
I can't wait for the day when the server spits out a bootable image that will run on our real first prototype :D
Discuss about that post on the webboards: http://boards.openpandora.org/topic/17080-its-the-details-that-take-longest-...