[Gta04-owner] Hardware validation status

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Jun 4 18:26:13 CEST 2011


Dear all,
we have used the time we wait for SMD production to start (it is now
scheduled for end of next week for the first two A3 boards). During
this delay, we have made some more experiments with the A2 board.

Everything is quite tricky because there is a hardware layout issue
in the A2 board which has crossed over the I2C lines for the
communication with the PMU and Codec (TPS65950). This
is already fixed in the PCB layout for the A3 boards. So you all won't
have to worry about it - just we have to find tricky ways to work
with this board.

But we managed to test some more functions on the GTA04A2 board:
* vibracall motor works (rotates left/right in controllable speed)
* some sound signals can be seen with an oscilloscope
* USB client mode works
* CDC Ethernet gadget (IP-over-USB) networking
   but shows 50% ping packet loss due to I2C
   communication delays introduced by our I2C fix

With the help of Denis 'gnutoo', we also were able to better
understand the ALSA driver for the sound chip and it appears
that there are no major problems. A minor problem may be
routing sound from the UMTS modem to the speakers. But
there is a comparable solution for FSO running on a N900.

So the plan is to have a U-Boot with a "systest" command
available and a 2.6.32 kernel that has been patched to
control all hardware functions. We will call this a "hardware
validation kernel".

It is not intended to be final or for real systems (SHR, QtMoko etc.).
The idea is to provide the board with a working kernel (although
not the latest things) and then start together with volunteers from
the community to work towards a 3.0 kernel... We can then
always compare with the 2.6.32 kernel if something does not
work immediately.

Why did we use a 2.6.32? Well, because we have a working
beagleboard kernel source. And after 2.6.32 the beagleboard
team heavily worked on pushing things to upstream. And this
did break some parts. E.g. on a 2.6.34, the LCD driver is
broken and was only fixed in 2.6.35 or 36. And tracking these
bugs and versions is additional load if we just want to bring up
the hardware.

Therefore we decided to stick with a known working reference
kernel and postpone upstreaming and cutting edge functionality
until the hardware is stable.

Finally, we fortunately have some other projects where we
can look for drivers and inspiration how to build our own:

* Palm Pre
* N900
* IGEP2
* Gumstix
* OpenPandora

just to mention some projects.

Nikolaus



More information about the Gta04-owner mailing list