It's the details that take longest (Part 3)


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
47
Location
Ingolstadt
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.

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
 
 
A post about blobs :)

The_Blob_poster.jpg
 
Last edited by a moderator:
...

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.


...
The Pandora's audio quality alone is worthed the Iphone 6 price itself. This means my Pandoras are still get used even after Pyra release and this is awsome.  So I don't worry too much if Pyra's audio won't be as good as Pandora's ;)
 
Last edited by a moderator:
Is a binary "blob" such a bad thing? I mean, even if not open source, as long as it does it's job fine I'm OK with every solution. And if a closed source driver is faster than an open source driver, use the closed one! :)
 
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.
Won"t Wayland be kind of stable when the Pyra comes out? Just wondering...
Wasn't  power consumption a concern with Wayland? 
I have seriously no idea. Never used it so far.

Is a binary "blob" such a bad thing? I mean, even if not open source, as long as it does it's job fine I'm OK with every solution. And if a closed source driver is faster than an open source driver, use the closed one! :)
wait until _wb_ sees your message and burns you at the stake! :D
 
Good post.

SGX driver is always a large discution subject.

Anyway, Wayland is probably nice, full of Eye-candy, but we probably don't want that on a portable device where we want to control when 3D is ON or OFF (for both power consuption avoiding overhead)
 
What I understand is that with Wayland the 3D acceleration is enabled full time, so it would be a bit more power hungry. 
 
Hi

Have not posted anything for a long time and still will not have much time. It is a joy to follow the news and development of the Pyra and i am looking forward to owning one.

The reason why i post is to contribute a smaller bit of information about a possible WLan alternaive:

http://www.hd-wireless.se/index.php/products

This company sells some chips as well modules based on those chips. If not buying the module, they offered (i had not time to verify that again, checked some months ago) a "sure to work" reference layout/design guide.


To the best of my understanding, the linux driver is open source:

http://linux.hd-wireless.se/bin/view/Linux/GettingStarted

I do not know if the firmware is available open source.


Also, last time i checked (again, several months ago) some of their ICs were on stock at digikey. Sourceing for testing should therefore be no problem.

All the best!!
 
Last edited by a moderator:
What I understand is that with Wayland the 3D acceleration is enabled full time, so it would be a bit more power hungry.
Don't they consider anything for tablets with Wayland though ?
shut off the display or run the battery out in 4 hours if active I guess?
 
Last edited by a moderator:
Currently the driver is crashing occasionally, I'd rather not have it attached to the desktop..

shut off the display or run the battery out in 4 hours if active I guess?
Doesn't Android have full time 3D acceleration as well anyway ?
Doesn't mean we have to follow bad examples. There is 2D chip accelerator much better suited for desktop composition stuff.
 
Last edited by a moderator:
Currently the driver is crashing occasionally, I'd rather not have it attached to the desktop..

shut off the display or run the battery out in 4 hours if active I guess?
Doesn't Android have full time 3D acceleration as well anyway ?
Doesn't mean we have to follow bad examples. There is 2D chip accelerator much better suited for desktop composition stuff.
Does it mean that Android support could be buggy because of the driver? (not that I care much anyway, just asking).
 
What are the requirements for the near field radio?  I understand it to be a n-standard WiFi /combo bluetooth chip connected via USB. Is that correct?

Edit: Realtek RTL8723  is such a chip, and it has drivers here https://github.com/lwfinger/rtl8723au  see  http://marc.info/?l=linux-wireless&m=136483360212000

Hardware: http://www.ccandc.com.tw/products_2.php?prod=217  or http://dl.radxa.com/rock/docs/hw/ds/BL-8723RB1_product_specification.pdf

Edit2: I saw now that its SDIO

http://wireless.kernel.org/en/users/Drivers/brcm80211

Completely open source host drivers, no binary object files.
BCM4329

BCM4330

BCM4334

BCM43241

BCM4335

BCM43362

BCM4354

BCM43143

Then again, it says "yes" for non-free firmware required for brcmfmac  here: https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

www.mediatek.com/en/products/connectivity/wifi/consumer-electronics/usb/rt3180  i dont know about this, but it doesnt even look like its supported in http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
 
Last edited by a moderator:
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.
 Won"t Wayland be kind of stable when the Pyra comes out? Just wondering...
Wayland already reached maturity, but the apps didn't fully migrated yet. There is SDL2, EFL and GTK, but without the XDG-shell extension, which isn't stable yet, the support is pretty incomplete. We still need Qt and the Desktop Environments.

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.
 Won"t Wayland be kind of stable when the Pyra comes out? Just wondering...
Wasn't  power consumption a concern with Wayland?
Last research I saw was pretty positive (i.e. better than Xorg): http://community.arm.com/groups/arm-mali-graphics/blog/2014/08/14/mali-x11-vs-wayland-at-siggraph-2014

But this assumes no XWayland (native Wayland).
 
Back
Top