gta02a5 prototype #30 brief review
andy at openmoko.com
Wed Feb 27 16:02:10 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
> On Wednesday 27 February 2008 06:12:58 Andy Green wrote:
>>> * BT and GPS power nodes are only in a very deeply embedded i2c subdir,
>>> whereas the other device nodes are in /sys/devices/.
>> We can symlink them if you think it is good.
> Yes, that makes it a bit more consistent, so please do that.
>>> * after enabling the BT power node, no bluetooth model is found on USB.
>> You must additionally echo "0" > bah-de-blah/reset for detection
> Excellent. That does it. I can scan and inquire fine here.
>>> * Wifi module works ok, but has some quirks. First, reception was not
>>> that good, second, there are some driver problems with the wireless
>>> extensions not being fully supported. you can't set the channel in ad-hoc
>>> mode, link quality has bogus values (x/y, x >= y), when you scan and
>>> there is nothing found, iwlist eth0 scan hangs with:
>>> eth0 Failed to read scan data : Resource temporarily unavailable
>>> kernel says:
>>> AR6000 scan complete: 0
>>> ar6000_ioctl_giwscan(): data length 0
>>> [repeated 20 times]
>> You must have the "89" firmware on your module for good operation.
> Which I have.
Hum I was earlier today doing a scan OK, I saw Willie do a scan OK, I
don't think it is epidemic whatever it is. On the previous firmware I
was able to associate well to my WPA network at home, although after
some 10MB of transfer it blew chunks.
>>> * NOT tested yet:
>>> * accellerometer
>>> * suspend/resume from various sources
>>> * RTC
>> Testing RTC will be valuable because I never looked at it and the time
>> is often inconsistent.
> Ok, I will do some tests today/tomorrow. Is suspend/resume expected to work
It's progressing the last two days, there are several nasty things that
can be triggered or not depending on what drivers are coming in. The
last patch I sent allows multiple resumes from the power button, for the
stock buildhost case (really, it is for the result of the config that
happens to be in there and the consequent ordering of suspend operations
and races triggered or not), the main thing left is the LCM all-white
>>> Further questions:
>>> * What's the plan regarding support for non-coloumb-counter batteries?
>>> apm did not show any sane values. Interestingly after some time, I got a
>>> BATTFULL message from PCF -- is this correct?
>> They should work for charging but we don't ship with them so no
>> telemetry. The telemetry from the smart batteries is pretty good.
> I see. However we should support at least the same level of telemetry with the
> dumb batteries that we had in GTA01.
If there's no date attached to it, fine, because it isn't exactly a
blocker: we don't ship with those batteries.
>> BATTFULL is fine it is an event from the standalone charger state
>> machine that it sees it should stop charging because the battery is
>> acting done. It keeps topping the thing up at (long) intervals and will
>> repeat it ongoing, but it is accurate.
> Excellent, we could not sense that in GTA01.
It's just we used the pcf50633, it deals with all that.
>>> * battemp and friends do not contain information yet.
>> Raster was in here yesterday asking about that, he is on it.
> Ok, cool. Going standard power class is definitely a good way. I want to see
> the embedded apm emulation dying a rapid death.
I dunno how that fits in with the (broken) reboot functionality,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-devel