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…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Let's continue with our details about what's happening.
This time with...
1. The LCD Cable and Display PCB
--------------------------------
Askarus and me have taken the time to design the layout (physical, not
electrical) of the LCD Cable, using paper and thin foil cuts to measure
that everything fits and can be assembled.
The flex cable will be a lot more simple than for the Pandora:
* No edges which rub against each other and could cut traces * Only
half of the traces needed, so traces on one side of the cable are
enough, no double-side (like on the Pandora) needed.
* The cable will be twice as wide in the area where it rolls and we're
keeping distance from the edge to prevent any damages there.
* The cable will only connect two PCBs, it won't have it's own PCB
included at the top.
We've not yet decided whether we make the lines redundant, so if one
breaks, there's still a second one, but we'll see how well that all
fits.
Nikolaus and me are also currently discussing about how the display PCB
will be layouted so that it is easy to assemble, needs as little space
as possible in the lid and works without any issues. There are multiple
solutions possible, and we need to find out the best one, so we'll do
some mechanical tests as well.
2. The LCD
----------
I received some BOE LCD samples which have the touchscreen applied.
Unfortunately, they're not properly assembled (there are air bubbles
between the touchscreen and LCD), but we'll get them replaced for free.
We can already use them for mechanical tests though.
I'm currently in favour of using the BOE display, as we got it to work
already and it had a fantastic picture. I'm also getting a demo board
of the Success display though, so I can test and see if it's worth
finishing our driver for it or not. And Sharp is interested in getting
their display into the Pyra - they even tried to code an OMAP5 display
driver for us, so we'll test their LCD as well. It's 5,2" instead of
5", so we need to check whether we can fit the LCD into the lid without
changing the size, but I think it might JUST work.
We haven't continued to work on the Rotator chip driver (not enough
manpower), as we know it's software and we know it works with the BOE
displays in other setups, so that has a bit lower priority.
That's it for today - more stuff will be posted tomorrow :)
That's it for today.
More stuff will follow tomorrow :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17066-its-the-details-that-take-longest…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Things seem to slow down (with less blog posts I do), and that's true
in a way, but untrue in another. Yes, progress has slowed down - which
is normal for a product. The first 90% of development are fastest, from
then on, it's only the details that remain... and those take longest.
We're now in that stage.
But while visible progress slows down, the actual background work is
more than before, and hasn't slowed down a bit.
It's quite a lot of things to tell you about, and surely a lot to
discuss about as well. So I'll do one post per day now for the next few
days with small snippets :)
Let's start with...
1. The Case
-----------
The case company is currently tweaking all the issues I found (stylus
didn't hold, speaker area needs to be finished, shoulder buttons need
improvement (and an alternate design should be created for testing),
battery compartment needs to be changed to fit the new battery, some
areas need to be modified so that the LCD cable can fit, etc.)
I've created quite a list (including pictures and explanations what
they need to be aware of when designing those areas)... and whew, that
really took quite a while. You need to think ahead of all issues that
could occur and explain upfront what needs to be done to prevent that.
I can't wait to receive the next case update - it should be pretty
close now to the final version!
2. The Keymat
-------------
The keymat sample we got was working fine (and felt fine), but the
material was not diffuse enough so you could see the LEDs clearly
below. I'm getting more keymat samples with more diffuse material soon.
No layout discussion from my side until everything is mechanically
ready :)
3. The Stylus
-------------
I've got an offer from Elton to create Pandora / Pyra-versions of the
XStylus - but I'm not sure yet whether we should use it or not. I
personally am fine with the stylus we got for the Pandora and have used
the XStylus for the Nintendo DS, but it's not more comfortable for me,
only a bit flakier.
The Pyra XStylus would use a new nylon material which doesn't break as
easy, so it should be better than the NDS XStylus.
What do you think? Would you prefer an XStylus as default stylus or a
solid one like in the Pandora?
That's it for today.
More stuff will follow tomorrow :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17064-its-the-details-that-take-longest…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
The road from a first PCB version to a fully working prototype is a
long one.
Moving to Kernel 3.17
---------------------
Nikolaus is working at two things at the same time: Getting kernel 3.17
to work with all hardware AND testing the hardware itself.
There are two reasons to switch to 3.17:
1. It's the latest one (which we also want to use on the final unit)
2. He's also working with 3.17 on the GTA04, and quite a bit of
hardware is similar, so it saves some work.
Mostly, Kernel 3.17 is now working fine without major issues.
What's nice is that the CPU temperature is even lower than with the 3.8
kernel (about 10 degrees less on idle state).
The mainboard tests
-------------------
Now, onto testing the features of the mainboard.
First, let's start with what has already been tested and is working
fine:
* Keyboard-Backlight LEDs
* Shoulder Buttons
* Nub buttons
* Nubs (Position etc.)
* Keyboard
* Sensor: BMP180 (digital barometric pressure sensor)
* DC/DC-Converter for the USB-Hosts ports
Not yet tested:
* RGB-LEDs
* Stresstest VBUS
* Mikrofon-Detect-Switch
* CPU-Reset-Logic (LSH-BOTTOM + Poweron)
* Charger-Bypass
* FTDI232 (Linux console)
* Charger
* Vibration motor, Microfone, Speakers
* Modem-USB, Modem-Ignite, GPS
* INA231 (for checking modem status)
* Fuel Gauge(s)
* Other sensors
Can't be tested yet (as we need the CPU-Board or the next revision of
the motherboard:
* HDMI
* eSATA
* USB-OTG 2/3
* Audio
* WLAN/BT
* Display connected to the mainboard
Quite a lot of things to test, but we're moving forward.
Case design
-----------
FormAction (the case design company) is back from summer holidays, so
we resumed the work there as well. I'm working on giving detailed
explanations how the shoulder buttons should work internally and
externally, and we also want to try out Fusion_Powers design as well as
optimized the one I suggested.
The OS
------
Things are moving along, slow, but sure.
We've setup various gits (http://dev.pyra-handheld.com/) and will soon
populate them. The basic creation of a rootfs using debootstrap is
already working, now we need work out how to do automatic package
creation from sourcecodes and scripts and maybe move to multistrap (so
we can create the image directly on the server, not using the EVM).
Other stuff
-----------
Two batteries from two different companies have been sent to
FormAction. One is thicker, one is wider than Pandoras one, both have
6000mAh. They will let me know which one would fit better into our case.
We'll most probably use the BOE display, as the quality is great and we
already got it to work. We still want to test the success and maybe a
Sharp one.
Oh, and as someone requested it:
The Blog now has an RSS feed as well:
http://boards.openpandora.org/index.php?app=core&module=global§ion=rss&…
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/16973-the-long-road-to-a-final-unit/
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
