Re: Problem with receiving Cell Broadcast messages

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi,
|
| Am Samstag, den 19.07.2008, 08:04 +0200 schrieb Michael 'Mickey' Lauer:
|> Am Dienstag 15 Juli 2008 00:50:45 schrieb Michael 'Mickey' Lauer:
|>> Indeed. I should try walking around and see whether I receive
frequent CBM
|>> on cell change now or whether it's just my constant reregistrating that
|>> triggers it.
|>>
|>> Perhaps tomorrow if the weather is fine ;)
|> Ok, I had a chance to test this now. %CBHZ=1 fixes it for me, from
now on I
|> receive frequent home zone cell broadcasts, no matter whether I
change the
|> cell not.
|>
|> One problem less.
|
| Nice. Is that related to the problems of wake-ups-from-suspend? Or do
| cell braodcast not trigger these?

We dunno what triggers the resume crashes from GSM, except I can't
reproduce it in DM2 with gsmd up.

How can I send this %CBHZ=1 down to the modem in that environment to
test, from Ash, or patching DM2?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiBu/EACgkQOjLpvpq7dMpZqgCdEW1VNVImCUstpH6OtFzLE1Y4
+5oAn0TrWHsBkOboacxUrQVzZHu3XvIE
=gL4a
-END PGP SIGNATURE-

Re: Problem in logging in freerunner through ssh

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| pay attention that if you ssh to that other computer you'll get the same
| warning.
|
| note: 192.168.0.202 is IANA private use, so it's normal to have
| duplicates of that IP among different
| network

My local network is 192.168.0.0/24, so it makes a problem to route to
Freerunner default IP... I use this script as root on my Fedora host
laptop to take care of assigning an IP and hst route and whenever I hook
a Freerunner up

#!/bin/sh

while [ 1 ] ; do
~ sleep 5s
~ if [ ! -z "`ifconfig usb0`" ] ; then
~  if [ -z "`ifconfig usb0 | grep "inet addr"`" ] ; then
~   ifconfig usb0 192.168.0.200
~   route add 192.168.0.202 usb0
~   route del -net 192.168.0.0 netmask 255.255.255.0 usb0
~  fi
~ fi
done

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh/oxMACgkQOjLpvpq7dMqjCQCeOSkqqK3uX46zbVcrXyECJgZO
39cAnRmvEXzE+Bonil+Nb6+IwbBHt1mv
=sSqR
-END PGP SIGNATURE-

Re: [PATCH] add-ar6k-wake-interrupt.patch

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|>You can find and compile this tool in:
|
|>
http://svn.openmoko.org/trunk/src/target/AR6kSDK.build_sw.18/host/tools/wmiconfig/

|
|>Later, I will post the approach of how-to-setup-wake-up-from-wifi on
|> the wiki.
|
|>Julian, I'll send the .bb file of this utility to you please let me
|> know if you have any problems.

Sounds good, it will be nice or users if this applet comes in default
rootfs same as iwconfig, etc.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh9rrAACgkQOjLpvpq7dMqZ7ACfZYAFvKKCeaufZw0kUifBjHoo
Po0An0/8IL0dO9NdZ0Hvle6/7RZmn6UU
=PgKV
-END PGP SIGNATURE-

Re: libpcap in toolchain

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> My tackle shrivels at the pain waiting for you if you have to make a
|> new lib in OM / OE, but isn't libpcap needed for tcpdump?  Surely we
|> support tcpdump already and then libpcap too?
|>
| Kismet and all its dependencies are already in OE.
|
| In fact kismet .ipk could be stolen from angstrom feeds.

You will be relieved to know my tackle is restored to its normal
sheep-worrying self.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAkh4+1EACgkQOjLpvpq7dMqekACYrrT8SPf0vMap/LhxqFRs8/Tg
7ACgg30u+NGZ8eI8ziSOrceI9IyCa1o=
=Yahc
-END PGP SIGNATURE-

Re: libpcap in toolchain

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hello there!
|
| it would be very nice if anyone could implement the libpcap in the
| toolchain. would this be possible for anyone? unfortunately i cant do it
| :(. the lib is required for kismet, and i think kismet would be very
| nice for everyone here ;).

My tackle shrivels at the pain waiting for you if you have to make a new
lib in OM / OE, but isn't libpcap needed for tcpdump?  Surely we support
tcpdump already and then libpcap too?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh498sACgkQOjLpvpq7dMoOUwCfaaDEwM7N6tPg+V+R3BYBByhp
UKIAn2W3Ch59nfinO0RzZmdMADKLg0Rc
=fuCi
-END PGP SIGNATURE-

Re: How to switch usb mode to 500mA (enable USB charging with car charger) ?

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> This only flies on GTA01.
|>
|> ~From a quick look in the pcf50633 driver, this is disallowed on GTA02 at
|> the moment.  But, so long as the user understands what it means (and we
|> will defeat his choice anyway on USB removal so it doesn't subsequently
|> make trouble if he plugs to host PC) it sounds useful, so I will add
|> this in the kernel shortly.
|
| Cool. However, could you also add a way to use/force the fastest
| charging mode in GTA02 (i.e. 1A charging)?

I didn't suggest this could not be.  Current patch from me allows it:

http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/003761.html

- -Andy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh4ycsACgkQOjLpvpq7dMqbggCffCVva85sb7AJ9wqW9bIzUl6K
QvcAn229h4jmePG7hNWidbEkgTGjIy5k
=/TI7
-END PGP SIGNATURE-

Re: Accelerometer problem

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| if i shutdown X-Server i am able to open the /dev/input/events twice or
| more times. And it work. So it should be not the problem if the device

Huh.  Well glad as I am it works I didn't understand the real problem
here then.  Thanks for reporting this though.

| is opened by multiple processes. Just if the X-Server is up only one
| event work. lsof show that all events are opened by neod:

neod likes to have it all open and won't change AFAI was told.

In the future, we will use the threshold stuff supported by the sensor
silicon to work around that so there is not a constant 2 x 100Hz through
both the interrupt handler and the scheduler, and the battery impact.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh4x1QACgkQOjLpvpq7dMpF9ACeKWffKl1MxwEy3AsUsxTYkIhV
4iYAn3S+e5lCmDmffDrGQMd8JSSst0cx
=ey2P
-END PGP SIGNATURE-

Re: PJSIP on Freerunner

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| matt_hsu schrieb:
|> timo wrote:
|>> Hi,
|>>
|>> is anybody out there who try to compile pjsip on the opnemoko?
|>>
|>Hi Timo,
|>
|>Wow, it seems that I'm not the only one who is trying to put pjsip
|> on Neo. I've compiled pjsip with openmoko toolchain. There's no error.
|> But I've not try to run this application, since I need to configure
|> out the audio configuration/path first. Anyway, I will keep update my
|> status here. :-)
| Ok cool,
|
| i compiled pjsip on openmoko too. I am already able to make sip calls
| but also has to configure the audio system right. So i was not able to
| get the mic input.
| I read the wiki about the openmoko sound system but i do not found the
| right stat file for VoIP. Just gsm and bluetooth headset configuration
| is available.

Have a look in here:

http://git.openmoko.org/?p=system-test-suite.git;a=tree;f=gta02-dm2/data;h=7dee879fc6f4bfc88ad8e66a84b34276a6de6a90;hb=HEAD

These *.state files are the Alsa state files used for factory test.
Can't vouch for all of them but several at least are definitely good.

Right click on "raw" and Save As...

- -Andy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh3hpsACgkQOjLpvpq7dMq+RwCeLCd1lYQSDKh4tXHGEq47G8de
xD8AnAhMyEuRJ8YYLpL4ZHnYDGd+TPsZ
=EurH
-END PGP SIGNATURE-

Re: Current Bootchart / GSM power

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| My commentary is not about the small amount of power used by devices in
| the "off" state, rather it is about the fact that the GSM on the GTA01
| and GTA02 is left in a fully-operational, completely up-and-running
| state, even when you have shut down the Linux kernel and the PCF606xx
| PMU chip has otherwise shut down the power to all other components in
| the phone.
|
| The troubles this might make for the unaware user range from the trivial
| and very probable draining of the battery when the phone is supposedly
| off, to the improbable and not-so-trivial.

On GTA01 IIRC and certainly 02 there is a) what claims to be some kind
of logical on / off switch in the form of an NPN transistor that goes
into the GSM chipset, and b) the GSM logic side has switched power
itself that can be on and off.

The RF power amp is connected directly to battery because of the high
current it wants, the enable for it should be always disabled when GSM
logic side is unpowered... I seem to recall Allen has checked this.

GSM side is a bit funny because it has pretty direct access to battery
but if logic gets both told to be "off" and then depowered on shutdown
as it presumably should then it should be OK AFAIK.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAkh3L7IACgkQOjLpvpq7dMry9wCgio32AkZvFpCQpSoD9+JLFhmC
ekYAmKLc+OoGZjZp4NH5mGIUvk3U0CI=
=3Rjr
-END PGP SIGNATURE-

Re: Current Bootchart / breaking SD boot

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| If breaking boot from SD support only gains us 6 seconds I'd vote no.

I can boot from SD into a shell in < 5 seconds from starting Linux, how
is removing it gaining us 6 seconds?  MCI probing and so on is
asynchronous to the boot action and does not stall it.

Anyway this isn't happening I am told, so no worries.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh3LcMACgkQOjLpvpq7dMqefwCaAjYN8f2MEoHbrtzU2XC7yZ4Z
MgcAn2Dt0khDqyhz1szDfumEeQU4A0IG
=kFqZ
-END PGP SIGNATURE-

Re: How to switch usb mode to 500mA (enable USB charging with car charger) ?

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> is it possible to force charging and/or switch mode to 500mA by
software (not soldering
|> resistors to the cable etc) ?   I found some rumors on the list that
this might be possible
|> but can't find any details...
|
| echo -n "fast_cccv" >
/sys/devices/platform/s3c2410-i2c/i2c-adapter/i2c-0/0-0008/chgmode

This only flies on GTA01.

~From a quick look in the pcf50633 driver, this is disallowed on GTA02 at
the moment.  But, so long as the user understands what it means (and we
will defeat his choice anyway on USB removal so it doesn't subsequently
make trouble if he plugs to host PC) it sounds useful, so I will add
this in the kernel shortly.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh3GDgACgkQOjLpvpq7dMouUACfU5Bgv4wc/NH8PMKwbOIz2T8O
33kAnRlCwi7HeHOJn8OrAUE3/EGhfUGY
=zh0A
-END PGP SIGNATURE-

Re: Accelerometer problem

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On the OM2007.2 images it is the neod which opens the accelerometers. No
| reason for doing so, even more as neod starts to eat 50% CPU, because
| the am's send both 100 events per second...
|
| If anybody is interested, I recompiled the neod without this and without
| the click-sound. Drop me a mail.
|
| No more probs with the am's and everything a lot faster.

Well I am glad to hear it can be made stable, because I did believe I
fixed the instability last patch set.

However I don't get why neod sucking on the input device too makes
trouble (other than the CPU load or whatever).  The input layer in Linux
takes care about copying the input content around consistently so
everyone with the input device open gets one copy of what's happening.
Ie, the accel driver is not aware that there are multiple apps
listening.  I guess it is a bug in the accel driver somehow still, but a
much less worrying one that the SPI sharing difficulties until now.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh13NIACgkQOjLpvpq7dMoTVACgi1QGg4kfcmbZGqADQ32MoYs5
oY8AnRoW3TxtWyXaHyyZJF2BT8GDXj6B
=57p/
-END PGP SIGNATURE-

Re: Current Bootchart / breaking SD boot

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Tue, 08 Jul 2008 18:45:33 +0100 Andy Green <[EMAIL PROTECTED]> babbled:
|
| Somebody in the thread at some point said:
|
| |> Otherwise sounds fine to make it a module.  You can't use NFS rootfs on
| |> it AFAIK due to needing association sorted out first, that was the only
| |> reason I could think to keep it in monolithic kernel for normal use.
| |
| | imho everything we can make a module - should be. sd card drivers,
all fs
| | handling other than jffs2, sysfs and procfs, wifi, etc. etc.
| |
| | yes - you can't  boot the sd kernel off sd card then with rootfs
| there, but
| | root on sd is not something our production systems need. we can
change the
| | packaging to build 2 kernels, 1 modular, 1 monolithic for kernel devs to
| | quickly test things with.
|
| That doesn't make any sense, SD card boot is really valuable and even
| appears in the U-Boot menu, what's the point of breaking it?  SD Card
| boot is very nice for customers and definitely not some weird low level
| thing.
|
|> 1. we dont ship with that uboot menu - or we shouldnt be. the uboot
env i know
|> we ship waits 3 seconds then just boots.

Wrong.

|> 2. if users really want it they can use the monolithic kernel. thats
why i said
|> we build different images. one that is streamlined for fast boot -
everything is
|> a module where we can manage it to avoid having to wait for things
like sdio
|> init, wlan init etc. before even starting to run userspace init.

Did you see the last bootchart?  Is everyone focused on the 6 seconds
possible flab in kernel and kneecapping the device therefore because of
the sheer impossibility of doing anything else about the other two
minutes bringing userspace stuff up?

|> 3. why is it nice? seriously how may customers do u expect to boot
off sd card.
|> i have in fact never booted off sd card for example. i know some
people do -
|> like you, thus provide images for them that can do it - for the rest,
move sd
|> to a module.

I guess I failed to check if you did it before I started doing it months
ago and found it was nice.  I explained a very strong reason --->

| For example, customers can choose to give community builds a test run
| like that without nuking the NAND with it.  Of course it should not be
| broken in normal builds.
|
| -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh0YIIACgkQOjLpvpq7dMrfFQCeNrdl1Q5LmmQDj2xKNm6GX6x7
bwMAmwXcjUOzEkX4AjiNA6qB4VGKcWJc
=NYWy
-END PGP SIGNATURE-

Re: Current Bootchart / breaking SD boot

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> Otherwise sounds fine to make it a module.  You can't use NFS rootfs on
|> it AFAIK due to needing association sorted out first, that was the only
|> reason I could think to keep it in monolithic kernel for normal use.
|
| imho everything we can make a module - should be. sd card drivers, all fs
| handling other than jffs2, sysfs and procfs, wifi, etc. etc.
|
| yes - you can't  boot the sd kernel off sd card then with rootfs
there, but
| root on sd is not something our production systems need. we can change the
| packaging to build 2 kernels, 1 modular, 1 monolithic for kernel devs to
| quickly test things with.

That doesn't make any sense, SD card boot is really valuable and even
appears in the U-Boot menu, what's the point of breaking it?  SD Card
boot is very nice for customers and definitely not some weird low level
thing.

For example, customers can choose to give community builds a test run
like that without nuking the NAND with it.  Of course it should not be
broken in normal builds.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzp70ACgkQOjLpvpq7dMqVDACfYlUVyEWcrRsCrbcPIIiaqNEh
yugAoJNgK5fD9ItFZPl5qO5oIcL9vZSw
=7YDc
-END PGP SIGNATURE-

Re: Current Bootchart

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Wednesday, 9. July 2008 01:05:31 Andy Green wrote:
|> What's the SD card issue?
|>
|> Otherwise sounds fine to make it a module.  You can't use NFS rootfs on
|> it AFAIK due to needing association sorted out first, that was the only
|> reason I could think to keep it in monolithic kernel for normal use.
|
| For the full details Holger should comment here but it was something
like that
| we need the kernel module to run to detect a SD card insert action.
I'm not
| 100% sure about it.

OK I don't think it makes us trouble for Glamo side where actual SD card
is sitting.  We do not detect SD insertion there anyway.

But there is some funny pnp stuff in the WLAN to do with "insertion"
event of WLAN somehow from cold, it can be something about that... maybe
the PNP bits need to be in kernel.  Definitely worth trying anyway and
see if it blows up.

- -Andy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzpv0ACgkQOjLpvpq7dMpVNACdGTUm9FlostH/fMbqFWOKKqUM
nmkAn3K35OQEmNLzCTs8l8Ge+oqk0OAD
=4g7x
-END PGP SIGNATURE-

Re: Current Bootchart

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Wednesday, 9. July 2008 00:40:25 Fred Chien wrote:
|> 3. sdio_wlan needs 1 sec or ?:
|> 4. ar6000 needs 1 sec or?
|
| Both are part of the wifi driver. Currently I'm wokring on that and I
think we
| will make it a module and not load it at boot time. Holger mentionned
a SD
| card problem we might run into. Any other objections ?

What's the SD card issue?

Otherwise sounds fine to make it a module.  You can't use NFS rootfs on
it AFAIK due to needing association sorted out first, that was the only
reason I could think to keep it in monolithic kernel for normal use.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhznlQACgkQOjLpvpq7dMqhTgCfdIySICWFWGUydEM1OuVGtDEi
uLcAn2zeJuqVc+dvTChAGllTf4UfEoTy
=XAgt
-END PGP SIGNATURE-

Re: Current Bootchart

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi All,
|
| The kernel issue is under study right now. I got some boot informations
| from "demsg", please check the attached file. we can see the kernel is
| doing for what at boot time.
|
| here are some interesting places for kernel at boot time:
|
| 1. Mount filesystem needs 3.6secs:
|
| [3.265000] CRCFAIL 0x1a3f
| >>  [3.265000] Current Request Command:5, ARG:0x
| flags: 0x0008
| >>  [6.805000] VFS: Mounted root (jffs2 filesystem).
| [6.805000] Freeing init memory: 124K
| [6.935000] CRCFAIL 0x1a3f

That's not completely insane for 256MB jffs2 filesystem, but if we can
improve it that'd be nice.

| 2. Framebuffer and console stuffs need 0.5 sec:
| [1.01] SMEDIA Glamo frame buffer driver (C) 2007 Openmoko, Inc.
| [1.61] Console: switching to colour frame buffer device 80x58

OK, it spins waiting for PLLs, but that isn't 500ms of spinning, I guess
it can be improved a little and we find msleeps and so on that can maybe
be reduced.

| 3. sdio_wlan needs 1 sec or ?:
| [7.01] sdio_wlan 00:01: driver attached
| [7.01] sdio_wlan 00:01: SDIO device, IDs SD_0001 (active)
| [8.09] Unsupported configuration opcode: 3
| [8.09] Unsupported configuration opcode: 5

| 4. ar6000 needs 1 sec or?
| [8.225000] ar6000_avail: name=eth0 htcTarget=0xc7f46000,
| dev=0xc74b (0), ar=0xc74b04a0

ar6000 is the WLAN too, I am not sure this all stalls the boot (bad) or
is happening async (good).  Considering it does some nice things in the
whole time it doesn't sound so awful, despite we can give it a shave.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzmpsACgkQOjLpvpq7dMrBcwCdGe4Im5ZcEh0tQXgmIK0N3lQv
SXsAnj3AV8coKHCBkRtBlreZkkP47qnX
=CbRH
-END PGP SIGNATURE-

Re: flash

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| Jffs2 is just a symptom of writing direct to raw NAND...  we don't need
| to deal with these unusual formats when our storage is SD Card.  In that
| future, we use the very well characterized ext2 or ext3.
|
|> but that doesn't help- as such we have our OS on "on-chip" flash.
that's where
|> it is. it's nastily slow (2mb/sec read rates is what i clocked on the
mtdblock
|> devices themselves, so bypassing jffs2 overhead). am i wrong i
suspecting our
|> flash SHOULD be much faster? (like 5-10x faster)? this is for freerunner.
|> future devices is... another matter :)

Well we can boot SD on GTA02.  But I really mean it's not obvious we
should make a big investment into a new raw mtd filesystem given where
we are headed.

Practically, there's likely something wrong with how we use jffs2 from
cradle to grave and we probably get a better result looking at that.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzgIcACgkQOjLpvpq7dMq+6QCfWp0Hf3NFFxt8Sf6+doDo4NuC
NvEAn2npNiSKqI1m5YnYXIr4p4i076oY
=ZQ7q
-END PGP SIGNATURE-

Re: flash

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> It's unclear where that problem comes from,
|
| The ECC might be a major factor in this. It's turned off because
| software and hardware disagree on the ECC algorithm, causing images
| DFU'ed onto the device to produce ECC errors.

Is this because U-Boot (active at DFU time) doesn't use hw ECC then?
Otherwise it would all come out in the wash?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzfaUACgkQOjLpvpq7dMoI/ACeJaXrVE8VldTU0USPiXl6FwBE
Q+MAn10ZTNW6USPqPXGWN2fSxxKGuI/A
=5BFD
-END PGP SIGNATURE-

Re: flash

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Am Dienstag 08 Juli 2008 16:03:00 schrieb Andy Green:
|> Jffs2 is just a symptom of writing direct to raw NAND...  we don't need
|> to deal with these unusual formats when our storage is SD Card.  In that
|> future, we use the very well characterized ext2 or ext3.
|
| Yes, but until then there may be a nice speedup waiting for all existing
| customers.

It's unclear where that problem comes from, I guess I would be
suspicious first about this offline generation of jjfs2 image, compare
it to unpacking tar into empty actual mtd.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzdzgACgkQOjLpvpq7dMqaFACfdfLvUIrLdKopHRhenSsa6GC5
u4kAn3JH2kDfvR1kmX3rJa39MvfbaY0m
=1+mm
-END PGP SIGNATURE-

Re: flash

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer"
| <[EMAIL PROTECTED]> babbled:
|
|> Am Dienstag 08 Juli 2008 12:45:12 schrieb Carsten Haitzler:
|>> which brings me back to... we need a way to avoid jffs2 compression for
|>> some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)
|> We should consider one of the alternatives to jffs2. The jury is
still out on
|> yaffs2 and ubifs is now in mainline.
|
| definitely. i'm no expert here... so.. what do people say? jffs2 works
.. but
| does have performance issues. it needs the ability to be able to be
taught to
| not compress some kinds of files. do we have anything of the sort out
there?

Jffs2 is just a symptom of writing direct to raw NAND...  we don't need
to deal with these unusual formats when our storage is SD Card.  In that
future, we use the very well characterized ext2 or ext3.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzc44ACgkQOjLpvpq7dMqvnQCfTS85sDbNc952KW1qvyXbF6EQ
JgQAnig0wv29uOyl4PWjhP6yDphKH9Rc
=l9bc
-END PGP SIGNATURE-

Re: Accelerometer problem

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| That's exactly what happens to me.
|
| Andy, I had to go when I received the email and didn't have time to
| write back; but, Timo explained it well - same problem.
|
| Paul
|
| On Sun, Jul 6, 2008 at 7:32 PM, Timo Drick <[EMAIL PROTECTED]
| <mailto:[EMAIL PROTECTED]>> wrote:
|
| Andy Green schrieb:
|
|
| Somebody in the thread at some point said:
| | I've tried with today's kernel and nothing - the problem is
| still there.
|
| Can you describe how to reproduce what you're seeing then,
| preferably
| with stuff from Ash (like hexdump) if possible.
|
| - -Andy
|
| I use the kernel: uname -a
| Linux om-gta02 2.6.24 #1 PREEMPT Sat Jul 5 01:18:58 CEST 2008
| armv4tl unknown
|
| hexdump /dev/input/event2
| 000 f11d 4870 8a7e 0006 0002 0002 0396 
| 010 f11d 4870 8a9d 0006    
| 020 f11d 4870 b04a 0006 0002 0002 0396 
| 
|
| hexdump /dev/input/event3
| wait until death :-(

Huh.  OK.  I will examine this tonight.  Kernel from Jul 5 should have
all that stuff in alright.

Thanks for writing up the description.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhxu88ACgkQOjLpvpq7dMoFHwCfQqpgblVuHgTgeOCmaQUlB1GX
k4IAn2GJqY7fFRHQhftxfKLL5CpfGWy7
=/hWq
-END PGP SIGNATURE-

Re: WLAN in ad-hoc or master mode

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| Switch the wlan interface of Freerunner into master mode failed:
| iwconfig eth0 mode master
| Error for wireless request "Set Mode" (8B06) :
|SET failed on device eth0 ; Invalid argument.

I don't think the firmware in the WLAN device has Master mode supported.

| "iwconfig eth0 mode ad-hoc" do not throw any error message but do not
work:
| iwconfig eth0 channel 1
| iwconfig eth0
| eth0  AR6000 802.11g  ESSID:"moko"  Mode:Ad-Hoc  Bit Rate:11
| Mb/s   Tx-Power=15 dBm   Sensitivity=0/3  Retry:on
| Encryption key:off
|  Power Management:off
|  Link Quality:0/94  Signal level:-95 dBm  Noise level:-96 dBm
|  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
|  Tx excessive retries:25  Invalid misc:0   Missed beacon:8
|
|
| there are no frequency set. And the openmoke is not able to connect to
| the other ad-hoc station. I have another wlan station in promiscuous
| mode with airodump output. And this station do not report any packet
| from the phone. Just the other station is detected.

Doesn't sound great... maybe try fiddling with ordering of setting
channel, also ifconfig up on it.  IIRC someone else reported luck with
Ad-Hoc.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhxuz4ACgkQOjLpvpq7dMrcjgCfV3DxV0UbEheKs5xxuoM6lkXg
FkYAniUMgyTTrdHSFhNqERTR3MTu7DoW
=r4nQ
-END PGP SIGNATURE-

Re: bad touch screen calibration for landscape orientation

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi,
|
| using a new gta02 (how can I figure out the exact version, like
gta02v4 or similar?) the
| touch screen calibration is off on the long (X) axis when I switch
orientation to landscape.
| using "mtpaint" it's quite easy to check what's going on.
|
| why?  how can I fix this wrong x-offset in landscape mode ?

I guess this is userspace issue: the ts driver itself does not know or
care about orientation, only the downstream apps like X I guess care.
It used to work OK FWIW.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhxunEACgkQOjLpvpq7dMrH6wCeNmKlHWz5iLhKHw7Q/yhr+xrC
1isAn2SzSdKJUZ3nqlou9WPYChHqVNV2
=YTLH
-END PGP SIGNATURE-

Re: TangoGPS and GPSD

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> this explains that there is a problem with the internal antenna.
|> the gps receiver detects a shortage and disables the antenna :-(
|>
|> same problem with my new gta02 :-(
|
| I don't understand Andy's findings that way.
| Seems more like GPS-receiver can't even switch off antenna at all. The
whole
| story about Vcont is just switching between internal and ext. ant.,
and is
| done by a separate chip (UPG2012TB).
| No way to switch ant. off for ublox-receiver

According to Shawn Lin examining it, the effect of that problem is IIRC
2dB drop in signal level, it doesn't kill anything.  And I don't believe
it makes trouble itself, despite it's not right, because when I shorted
the antenna path to the internal one bypassing that antenna mux, it
didn't change anything.

I did see though that external antenna was always a good way, why I
never got to the bottom of.  Some days I would get great response from
internal antenna and other days not, with same test situation.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhxugQACgkQOjLpvpq7dMr67ACfRdBiu1L2PLhp8bwnh2eeME27
lnIAn07iA27PPuZ5m3Y7Dv6uMYsN+xt0
=L1tv
-END PGP SIGNATURE-

Re: Accelerometer problem

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| I've tried with today's kernel and nothing - the problem is still there.

Can you describe how to reproduce what you're seeing then, preferably
with stuff from Ash (like hexdump) if possible.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhw23sACgkQOjLpvpq7dMrNUgCaAvlgicaDxtPoIvgmFX17cmcb
hyAAnjvkl4D/BcE1rY5wlwvz9ZfReq88
=DfkS
-END PGP SIGNATURE-

Re: Accelerometer problem

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi all,
|
| i play with the new Freerunner GTA02 and mentioned the problems with
| reading both accelerometers. With the /dev/input/event2/3.
| I search the mailing list and found reports of that problem but no
| solution. Do i have to activate the second accelerometer or is there a
| way to read both accelerometers.
| I plan to control a rc-car with the Freerunner. For the first tries one
| accelerometer is enough. But sometimes the event2 works and sometimes
| event3 (I observed the same behaviour discussed earlier the both
| accelerometer switch after each reboot). The second accelerometer is
| twisted 45° so it does matter which accelerometer is used.

Make sure you have really current kernel, there is a fix in the stable
branch for erratic operation the last days.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhw1AMACgkQOjLpvpq7dMranACdERGrd6M4DQVNroZucO8vDYw6
xasAoIsBuuoClgUYpckEO6ngcsb+iocr
=trMJ
-END PGP SIGNATURE-

Re: SHR First steps

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| If I remember correctly, Mickey said (and tests proved) that the FSO
| stack is more stable for purposes like pure telephony, and has a
| stable suspend/resume functionnality, which is a huge step ahead for
| the battery time. The problem is, as you pointed out, related to UI.
|
| Please correct me if I'm wrong :-).

Suspend / resume was only handicapped by kernel side troubles, all
images with latest stable should get "almost great" suspend / resume on
GTA02 anyway, hopefully same for GTA01.  The last big problem flying
around is resume from GSM wake seems to sometimes make trouble, but I
couldn't reproduce it and the two reporters didn't complain for a while,
status of it is unclear.

Of course there's more we can do on resume, it's not finished, but it
should work pretty OK now.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhwsjwACgkQOjLpvpq7dMqD2gCeOw52zfk+oEBl9TqFxsmlUX1G
MQkAnjKeKtLTcdijgBeLVFFo9Gd3Zx67
=U2rt
-END PGP SIGNATURE-

Re: SHR First steps

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| I would love it if this could eventually just turn into a part of the
| ASU, with people replacing the old 2007.2 apps (without breaking
| them!) with alternatives that work better or look nicer as a part of
| the ASU.  Our goal is *not* to create another competing release
| (although I know that's essentially what we're doing right now).  Our
| goal is to take the goodness of the future and the goodness of the
| past and patch together something that gives us both until the future
| can catch up on all counts with the past :-)

Personally, I think no matter how that pans out will be great for end
users to have more than one "way" available to them, and it being a GPL
world this does not at all have to mean balkanization.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhwk/cACgkQOjLpvpq7dMrmHQCfUojEhjq0B1ZrL8f6ZAkevJAU
wCMAn1sgnKynsWVUXQO+LI7RXaqC2G9p
=LaHE
-END PGP SIGNATURE-

Re: Current Bootchart

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| after collect informations, we can sum up the most important issues for
| boot time:

Hey bootchart is really good step to understand and measure the real
issues, nice work.

| 1. initializing kernel(9 secs)

What actually does that, JFFS2 mount?  I use ext2 on SD card, there is
no 9 second delay there.

| 2. initializing boot splash (exquisite/exquisite-write)  (8 secs)
| 3. udev (udev/udevd) (29 secs)

mdev on busybox is possible replacement.

| 4. updating dynamic library cache will waste a lot of time (ldconfig)
| (18secs)

I already mentioned this some weeks ago, I took it out on the DM2 boot
here and it makes a big difference.  And most of the time, it is doing
nothing at all.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhwkHAACgkQOjLpvpq7dMo6dwCeIV/lmzHaXavthGsQpXMBsdSK
wd0AnjLL1AKtOHiAebdrbJ2psC5cXtO1
=4+Ya
-END PGP SIGNATURE-

Re: Help with creating a high-functionality, high-stability FSO/ASU based release

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> That's nothing, they also have some core channel going on for "real
|> insiders".
|
| It has an excellent S/N ratio too - zero signal, only "FOO has
| joined", "FOO has left" noise ;-)

Funny quirk of psychology that anyone joins it then: maybe it should
just die.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhuWVwACgkQOjLpvpq7dMq+IwCfcJUnO4fPlFN5sbjPZSYKXx5n
1ykAn0c91KC/j0HEqqK5xocdoEf1Ye0x
=fJPK
-END PGP SIGNATURE-

Re: Help with creating a high-functionality, high-stability FSO/ASU based release

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| Woohoo, fork city!
|
|> As Mickey noted in his earlier email on this topic, why fork OE?  This
|> is not a fork, its continuing development of a project that originated
|> in OE, and was forked to a separate git repo later on.

Well, OK, but taken with needing a separate kernel, it's a fork.  Forks
are about control.  But, in GPL world, forks are not always bad news,
everyone can have everything and choose the mix they like.  And for
customers, having multiple living images that can mix from each other is
just a flat out win.

|> So fundamentally, OM (the repo) currently exists as a fork from OE to
|> facilitate the business goals and needs of OM (the company), and not for
|> the convenience of OM (the community).  The conclusion is clear; OE is
|> the best choice for the community.

Personally I have always been uncertain about OE being "best choice*",
that, but never mind.

| Mike, I think you'd make a great choice as handling a community kernel.
|
|> Given our recent discussions, I'm not sure if you're being sarcastic,
|> but whatever.  There will be no changes in the short term; the stock
|> kernel will continue to be the one marked "stable" in the OM git repo
|> (that's how OE works).  For those interested, there will be experimental
|> kernels, just as there are now, with various changes and patches.

No no, it's an occupational hazard of being English that it's hard to
tell if we're being sarcastic.  I mean it, your code has been very deep
into the guts of the kernel and you can obviously handle it.

Problems debugging something like resume handshake management are the
extreme stinky end of the stick anyway, any code to penetrate the
mysteries of it is not going to be loved by anyone that didn't
understand the extremity.  It's just unfortunate current situation.

| That's nothing, they also have some core channel going on for "real
| insiders".
|
|> Non-Disclosure Agreements are nasty things.  I've worked on a project
|> where the lawyers' interpretation would have prohibited discussions on
|> even a closed IRC channel.

That's the excuse for the devel channel.  There isn't an excuse for the
other one.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhuUJwACgkQOjLpvpq7dMpLXACfQ4EuiZst+33mK9FSGVE7ify0
W8wAn1zTpwb1un82yshknNhpys5FvwrR
=zQeG
-END PGP SIGNATURE-

Re: Help with creating a high-functionality, high-stability FSO/ASU based release

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| I'll volunteer to assist on kernel and the base image maintenance.
|
| This is a community project, not an Openmoko (the company) project -- as
| such I suggest that for the infrastructure we consider using the
| development environment (and repository) that the OM git repository
| originally derived from, and remains loosely in sync with.  That would
| be the OE (OpenEmbedded) stuff.

Woohoo, fork city!

Mike, I think you'd make a great choice as handling a community kernel.

| I'll also suggest that we begin using a community development IRC
| channel for those interested in development (of any sort), I propose
| #openmoko-cdevel on freenode (since #openmoko-devel is already taken,
| and is closed).

That's nothing, they also have some core channel going on for "real
insiders".

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhuPUoACgkQOjLpvpq7dMqSwACfQWTk0ktCoLPrgR2s9L4QNG5S
3l4AnRqweWNSB1JGzPaoX3eOFx9dzA1+
=BN8d
-END PGP SIGNATURE-

Re: Real Time kernel any experience?

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| A quick and awesome response ;)
|
| I will keep in mind that, 1us is a really quick reaction time (like
| your replies  ;)) but the goal is for running a plc software  so I
| need to assure a regular latency time more than  the quickest time
| possible( but it helps to know than this react time is even
| possible).

OK FIQ doesn't help :-)  "Real time" means a few different things.

| kernel is able to connect with the high precision clocks of the arm
| processor?

I don't know about any really high precision clocks (I looked in vain
for a CPU cycle counter register) a while back, but Andrzej Zaborowski
has a patch in the andy branch that allows "dynamic tick" scheduling to
much higher resolution than normal

http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=c27edf64d78abb0bb8d3004a231b6a2fb4c9931e

he's planning to use it to get low jitter mplayer action.  I guess this
won't do any harm for realtime.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhrgicACgkQOjLpvpq7dMpW2QCeP1ZAj01NILlZHljyiiI4lRwJ
BiMAnimMUHx5Oa/dkm+CTYsp1ujlZFOM
=nxq6
-END PGP SIGNATURE-

Re: Real Time kernel any experience?

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi there,
|
| In order to make some test  I'm interested in make a rt patched
| kernel to the neo any one has tried this before? any incompatibility
| with 0M already detected?

I didn't try it, but we do have FIQ support in the OM kernel, you can
write the service code in C as well.

If you are after hard real time response FIQ can deliver it much more
aggressively than any other solution (you are running the service code
in ~1us from the stimulus for sure no matter what anything else is doing).

If the need is to do with scheduling behaviours then it doesn't directly
help.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhrezMACgkQOjLpvpq7dMoCtACZAWvKeDjqpgP0EMofWD6MxfnD
UzgAn1Ov35FbwtG5E17tqBt6MDSe6w/c
=2Kh0
-END PGP SIGNATURE-

Re: Neo FreeRunner GTA02 for helicopter control

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Here's my implementation on how to read the accelerometers (be aware
| that the accelerometers sometimes don't work...):
|
http://projects.openmoko.org/plugins/scmsvn/viewcvs.php/accelneo/src/accelneo.c?rev=56&root=gestures&view=markup

|


There's a bunch of fixes queued up for the stable kernel that solve that
and make other improvements, like touchscreen jitter removal and suspend
/ resume speedup and reliability improvements.  I'll update the stable
branch in the next days.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhrWd4ACgkQOjLpvpq7dMolLwCfT58DSSnx51vlAmUKWwMDVrHM
jX8An3QzbFvHHNzTAMOwZDksFNt8CU/M
=eVJv
-END PGP SIGNATURE-

Re: Neo FreeRunner GTA02 for helicopter control

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| If you pop the top facia, I2C is available from two testpoints near the
| debug connector.  I'll post a pic in a minute.

Here we are, GND is not on a testpoint there but the mounting holes at
the bottom and you can grab it from a capacitor under the battery on the
right of the picture too.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhrOBAACgkQOjLpvpq7dMqgEgCZARl32xL8D80yGozW3r5Gi3gt
VgYAn07xJmuc1KjS+WWswgJkSbPfitiN
=Pg9J
-END PGP SIGNATURE-
<>

Re: Neo FreeRunner GTA02 for helicopter control

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| We have planed a nice project with openmoko.
| Our goal is to make a helicopter like vehicle with 4 engines to fly and
| the controller of that should be the Neo FreeRunner GTA02.
| To control the engines we think that we use PWM-moduls with I²C.
| I know, that sounds a bit crazy and a lot of work, but we have enough
time.
|
| The first thing is, how we can get the best access to the accelerometers
| and to I²C.

Accelerometers come out on /dev/input/event2 and 3 using normal X Y Z
events.

If you pop the top facia, I2C is available from two testpoints near the
debug connector.  I'll post a pic in a minute.

There is not really any spare PWM, but you can steal the one used for
FIQ (Timer 3) I guess.

| Can we use the toolchain for this application?

Yes it should be fine.

I'm not sure a usermode app is the way to go with this though, and I2C
may not be fast enough either, but you can get started that way.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhrNJ4ACgkQOjLpvpq7dMoIwgCggtPFNSiSET6oeqVqbn/V5XNf
+KUAn3ruSvmtyv38zF/G9T7WWrbIKUqZ
=FFH3
-END PGP SIGNATURE-

Re: OE on fedora9

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Thursday 19 June 2008 12:48:45 Michael 'Mickey' Lauer wrote:
|> Am Donnerstag 19 Juni 2008 09:54:09 schrieb Andy Green:
|>> Besides, I can't use
|>> our wonderful flawless Openmoko build+packaging system to work on tslib
|>> because it can't cope with exotic hosts like Fedora 9.
|> Still? What's the problem now, gmp-native's problem with gcc 4.3 was
fixed
|> as far as I can recall.
|
| Okay,
| four days, three kernel oopses of the fedora 9 kernel in virtualbox
and two
| patches to OE later I can say that the asu image is building on fedora 9.

F9 kernel (actually, I pick bits out of development / rawhide so it's a
later kernel here right now) has been very solid here but of course if
one doesn't use the bit that's broken that would always seem to be the case.

Nice work anyway, it's quite a herd of cats to get to build.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhelm8ACgkQOjLpvpq7dMoavwCgiZ74AEz68aSIvRJrWfmZ0aMA
Z9MAnRSYi190pGm9THJ61ab4Oe8TJYQ9
=O67C
-END PGP SIGNATURE-

Re: RFC: GSM flowcontrol handling, GTA01 and GTA02

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| in neo1973_pm_gsm.c.  All we really want is to leave the UART in
| auto-flowcontrol mode, but override the RTS line by switching it to GPIO
| mode.  A dozen lines of code in neo-specific source, versus some unknown
| amount of code with sweeping impact to all users of s3cx24xx devices? --
| I've switched from my original position to support the more practical
| solution :-)

Sounds good to me :-)

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhM5jkACgkQOjLpvpq7dMoOKwCdG4u5IJfdq1mS6cZI9+0rs3Gp
4aQAn0iJMhzfBV9yxa+j0QPsNAx/W3pD
=21Jj
-END PGP SIGNATURE-

Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Hi yourself... I guess you must have started using Openmoko build system
|> then because last time we spoke about it you were avoiding it same as me
|> - -- for the same reasons.
|
| I think you misunderstood me there - I wasn't referring to myself when
| I mentioned the angelic patience :-)  (*)

OK then :-)  just people might have gotten the wrong idea :-)

| For me, bitbake is a great tool for distribution makers. I say that it's
| a great tool for them because they seem to be happy with it. When they're
| happy and make happy little pre-compiled packages for me, I'm happy as
| well. And I'm even happier if I never ever have to touch bitbake ;-)
|
| (*) If you must know, I was thinking of Raster. Although the deprecations
| he uttered on IRC while struggling to use bitbake as a twisted
| substitute for make seemed somewhat less angelic (-:C

Yeah I saw him myself fidgiting and complaining through endless rebuilds
to pointlessly regenerate for himself what was already sitting in a
package in the OM repo.

|> What you should have said is: ''Also, having a toolchain that makes it
|> easy to cross-build from PACKAGES will help a lot towards people not
|> even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.''
...
| Yes, if the package has already been properly openembeddified and is
| part of someone's build process, sure, you can just grab the binary.
| But often enough, you'll find that this hasn't happened yet, and you
| probably want to try it out before lobbying its addition to the
| daily build.

Even if you build something weird it would just mean you should package
your dependent stuff in OE package first, and then install it into the
package-based toolchain the same using your local packages so you can
link against it.  It's no different with any packaging system like RPM:
if you planned on passing this new package around, you had to package
the dependencies anyway.

Packaged-based toolchain is then a complete stand alone solution for
normal devs.  For the people who build the packages in the main repo
from scratch and do have to have a complete set of build dependencies on
their build box, this bitbake or mokomakefile stuff that wants to build
an entire subdistro on their host is actually useful.  But how many
people need to drink that bleach?  Three?  Everyone else can have a
happy life building package-based.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhGUOEACgkQOjLpvpq7dMqzYwCeOND0JKcaLwEpWTa/V/4lVfbM
o3EAniqRSTvEJfw7UQPC+nCsBa3q1XpY
=fZ76
-END PGP SIGNATURE-

Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| in a main repository?  In Fedora, the multitude of repositories for
| downloading packages has caused nightmares of "dependency hell" when
| users install from two or more repos that carry some of the same package.
|
| The most user-friendly solution is one location that holds all the apps
| a user could want, one place for them to look, one place to maintain.
| Branching repositories should be avoided as much as possible.
|
| Submitting packages to OE is like contributing upstream.  It makes the
| most out of your contribution.

Yeah I know what you are talking about exactly.

In fact it is OK if apps are in multiple repos so long as they are
linked entirely against canonical dependent packages from central
distribution.  The damage came when you had say mplayer from freshrpms
and livna that each required and imported say faad from their respective
repositories.

Then if you wanted xine from a different place you got mplayer, the Hell
appeared because faad dependency in xine could either be satisfied by
the foreign package of different patchlevel than the one from the same
place as the Xine, or worse could not be satisfied due to use of =
version dependency when the two repos' faad were at different versions.

Of course it becomes political then what gets into the central
distribution with what config options, as happened with Fedora rafts of
dependent packages were landgrabbed into Extras as the de-facto
canonical source of them and the independent guys felt treated badly
about having that taken away from them rather brusquely.  In addition
people were and still are grumpy about the pretty intense packaging
rules and "bureaucracy" surrounding "submission" of packages and
"approval", although since as a Fedora user I benefit from the high
level of engineering and consistency I find it hard to argue against it.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhGOuwACgkQOjLpvpq7dMq2GQCeI9+3ZV3kn5nrmwDaHKJi4gG0
cM8Anj0U1lFpaM32+W4UuJLcM30kONzI
=1GZi
-END PGP SIGNATURE-

Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Rod Whitby wrote:
|> And therein starts the decline of Openmoko application availability
into
|> the poor practices of the windows world ...
|
| ;-) It's really two different usage scenarios: one is the "nice and tidy
| distribution", the other is getting something to build and, sometimes,
| to disseminate it quickly.
|
| While there are people who indeed have the angelic patience to work in
| distribution mode all the time, for most of us, this is just too much
| pain and overhead. (Hi Andy ;-)

Hi yourself... I guess you must have started using Openmoko build system
then because last time we spoke about it you were avoiding it same as me
- -- for the same reasons.

| Also, having a toolchain that makes it easy to cross-build from sources
| will help a lot towards people not even wanting to download pre-built
| binaries.

This is completely backwards.  I know you run Gentoo so maybe the
insanity is normal for you, but if someone painstakingly equipped their
box to build death-foo-libs package that has crazy build dependencies on
automake 0.1 and emacs 0.01, and kindly packaged and made available the
binary, why on earth should you ignore that and go through agonies
setting up your box to regenerate exactly the same bits?  They even give
you a -dev package, after YOU compiled the thing there is NOTHING
additional over just using the packages.  Except what, a chunk of your
life evaporated while you stared at things scrolling.

What you should have said is: ''Also, having a toolchain that makes it
easy to cross-build from PACKAGES will help a lot towards people not
even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.''

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhGOH8ACgkQOjLpvpq7dMpdEwCglPhYYa6ZK7zIR7GdKtXp3qpc
zzwAn3JcIXJJj/SU8hcO/8U8cVfIzAhR
=TJSV
-END PGP SIGNATURE-

Re: Meta Toolchain Release (2008 May)

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> Why not allow installation of target packages into the toolchain and
|> these "difficult philosophical questions" of what to stuff into
|> toolchain are GONE.  End users can decide and enforce what they wanted
|> in there purely from normal distribution packages.
|
| that's exactly what I was talking about in my previous mails.  :)

SUPER DUPER!

- -Andy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg/zqIACgkQOjLpvpq7dMoQlQCfZTsx/o4Z9PGprAkDB8tNPUC/
MiQAnjeOIi2b3FceY3rDV/MZnMjId7QC
=dPth
-END PGP SIGNATURE-

Re: Meta Toolchain Release (2008 May)

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> That is exactly the problem.  You see, if we put april software update
|> into consideration (these are standard openmoko apps as well), the
|> prerequisite will not be small for a toolchain.  I'm still thinking
|
| Not sure what you mean, is it that the dependencies for the April
| software are different and hence the toolchains needs both April and
| May libs ?
|
| I have just looked at one app (dialer), so you guys know the
| dependencies a lot better than I do and maybe they do make the
| toolchain too big, but just for the dialer the toolchain was pretty
| reasonable size.
|
|> about this out of my personal interest.

Why not allow installation of target packages into the toolchain and
these "difficult philosophical questions" of what to stuff into
toolchain are GONE.  End users can decide and enforce what they wanted
in there purely from normal distribution packages.

If they want ASU stuff in there, give 'em a list of package names that
form ASU, they can wget them and install them into their toolchain, even
keep up to date with ASU daily like that.

No other solution is gonna fix the root issue, is it!

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg/yuQACgkQOjLpvpq7dMpdwwCgimbF0+sOU1BqkoX9IcZqD/yy
LeIAnjGi7+Nnoh7Q7TlP8BUQfZz+B4a9
=aRbz
-END PGP SIGNATURE-

Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Pranav Desai wrote:
|> On Wed, May 28, 2008 at 5:49 PM, Rod Whitby <[EMAIL PROTECTED]
|> > wrote:
|> The usual way is to add the package to OpenEmbedded, and then add
|> it's name to the task-openmoko-feed.bb
|>  recipe so that it automatically gets
|> built, packaged and deployed to the official download site.
|>
|> But wouldn't that mean writing a recipe for all packages that we want
|> to add?
|
| That is correct.
|
|> Many third party apps already have a makefile setup, why do you want
|> to change that ?
|
| Writing a recipe does not involve changing the existing Makefile. If the
| existing Makefile is written properly, then the recipe should be about 5
| lines long.
|
| But the major reason to do this is the one I gave below, which you
| didn't comment on.  Security and trust of third-party apps should be a
| very significant consideration for the Openmoko community.

Hey allow me to comment on it.  Openmoko doesn't break new ground in
having a distro, most of the issues furrowing brows here were solved
long ago in "proper distros" (and, if we directly used a proper distro
in the future, these issues would just magically work, but that's a
flamewar for another time).

Looking at Fedora, the solution is not to have a single point of fai- I
mean distribution and claim that this is especially "secure", the
solution is to crypto-sign the packages and have the public key on the
clients.  This is a very strong assertion you can trust -- no matter how
you came by the package -- that the holder of the private key authorized
the package build.  And indeed with that, Fedora gets to use a system of
mirror repos that are completely out of their control to distribute
their packages, but it is perefctly safe due to enforcement of sig
checking at the client.

Nor does it limit us to only having safe packages from "Mr Openmoko", if
we decide we want Pranav's packages we install his public key too and we
can safely eat packages from Pranav even if we found them on Usenet or
lying around on the street.  Anyone faking or meddling with Openmoko or
Pranav packages is SOL when we try to install them it is rejected with
"package payload differs from signature" or "missing signature", etc.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg/yesACgkQOjLpvpq7dMpbEwCfbQdRVlXz5rvg4ByJx2/lxb3S
rKgAn1Vw6kFbEGhdBAqJ4+FlLTlZ2vMA
=4RrR
-END PGP SIGNATURE-

Re: Meta Toolchain Release (2008 May)

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| | What we need is to enable to install these into the toolchain somehow,
| | rather than make that a special "do it at the factory" operation
| to get
| | things into toolchain.
| |
| |> Agreed, but till that time if anyone is interested in the toolchain I
| |> can put it up somewhere.
|
| Hey good job Pranav.
|
| After 7 months of proposing this methodology I finally get a taker --
| from outside OM.  Maybe in another 7 months we can get a host-side opkg
|
|> Hmm, so within OM you guys don't prefer/advise using pre-built
|> toolchains? Any particular reason?

Open Embedded is the basis for current OM build system, it has a
Gentoo-type build-it-all-from-scratch approach.  It wanted to build over
1,100 packages when I tried to use it to compile ONE package, many of
these packages were built for host.  It was unable to build its thousand
packages of fun on Fedora 9 so I was unable to use it -- at all.

In fact all of the target packages it wanted to compile were sitting
there already compiled in the distribution packages, it did not need to
do any of it.  All it needed was to use the prebuilt toolchain like you
did, and unpack existing target packages and their -dev into the host
like you did, and I would have been away.

|> For me, it seems too tedious to setup the OM dev env to build single app
|> like the dialer or some other app like squid-cache. I think the
|> toolchain is very useful, especially for small apps, test programs or
|> even OM apps, which just needs a small personalized modification.
|> Anyway, thats just my thought.

Totally agree.  But more so: it should be the basis of our offering to
devs.  Vast bulk of potential devs only want to recompile THEIR package
and just link against distro packages, or cherrypick one distro app to
modify.  Package-based toolchain is the perfect, lean basis for this.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg9ykcACgkQOjLpvpq7dMq5CwCdElyVA8nl1EzU5PWAh6mBv0LL
k0wAnRCqVcySdczXSdhvN9avDtOe3LYq
=76MD
-END PGP SIGNATURE-

Re: Meta Toolchain Release (2008 May)

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On 5/26/08, Andy Green <[EMAIL PROTECTED]> wrote:
| Somebody in the thread at some point said:
|
| | No package 'libjana' found
| | No package 'libjana-ecal' found
| | No package 'libjana-gtk' found
| |
| | Any ideas, suggestions or can anyone provide with the required
libraries ?
|
| Presumably the actual target libs you want are sitting there in the OM
| distribution packages, and the includes and other bits and bobs are
| likewise just sitting there in the -dev OM distribution packages.
|
|
|> I was able to package a working toolchain (atleast it builds
|> openmoko-dialer2) which includes the missing libs mentioned above and
|> few others. As you said most of the libs were included the OM dist.
|
| What we need is to enable to install these into the toolchain somehow,
| rather than make that a special "do it at the factory" operation to get
| things into toolchain.
|
|
|> Agreed, but till that time if anyone is interested in the toolchain I
|> can put it up somewhere.

Hey good job Pranav.

After 7 months of proposing this methodology I finally get a taker --
from outside OM.  Maybe in another 7 months we can get a host-side opkg
or even unpack helper scripts as part of the toolchain so people can use
it for building against their own packaged libs in a coherent way.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg9EQ4ACgkQOjLpvpq7dMrX4wCfZ4XorL+QSzSO6yiXFmRqA9oX
PfMAnAw2AsWMOHJogII3VFRFtfRw99bx
=KutW
-END PGP SIGNATURE-

Re: RFC: GSM flowcontrol handling, GTA01 and GTA02

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

|> didn't (yet) have the patches in the form they should have been.  To be
|> honest, I was expecting a few go-rounds of discussions and changes
|> before they would be committed!

Well beauty and functionality are two different things... if we got
feedback about functionality of the patches that is very valuable and
independent of how we might have to rearrange the code for "beauty"
reasons.  Since it all remains patches just in "andy" branch we can swap
them out for updated versions real easy.

|> And there is an organization issue I'd like comments on -- I think if we
|> pull the GSM IRQ handler out of mach-gta0x.c and into neo1973_pm_gsm.c,
|> it'll clean up some things.  Also, perhaps some of this stuff will be
|> more palatable if it were enabled via Kconfig.
|
|> I agree with the general principle on keeping GTA-specific things out of
|> the serial driver... but the problem is that issues of one sort or
|> another keep dragging me back into that code.  Dealing with some of the
|> GSM issues and requirements from code outside the serial driver is
|> rather like repairing one's roof -- from across the street :-)  If there
|> are generic ways we can solve problems instead, we should definitely
|> explore those ways.

The same thing happened in the pcf50xxx drivers, it does not live in its
own little world and blobs out all over the place.  But the serial
driver is already upstream, I just imagine Ben Dooks' head exploding
seeing we propose to turn his nice generic s3c24xx serial driver into a
GTAxx serial driver.  The most we can expect him to accept in there is
some function pointer hooks in the platform stuff, maybe any true
s3c-specific handshake management functions.  (That way if as we suspect
it is a 2410 errata issue we can sell that to Ben).

It doesn't mean changing the functionality of the patches much, just
pouring ALL GTAxx code out from the serial driver into mach-gtaxx.c and
having a tunnel into that from upstream stuff via callbacks or variables
in platform data.

Also the Neospy stuff seems to invade a few places and would be best
conditional on a Kconfig option too as you suggested.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkg9BfYACgkQOjLpvpq7dMoJXwCfZ7LDFAh4zJoOjOrDqVjIWgk4
2AEAniDt1gfphMYCyU59j1P700sT3kwq
=2h9g
-END PGP SIGNATURE-

Re: accellerometer test

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| On Tue, 2008-04-01 at 21:37 +0200, Michael 'Mickey' Lauer wrote:
|> Hi guys,
|>
|> just got around to testing one (the 2nd one seems broken or unaccessible
|> on my prototypes) of the Neo FreeRunner accellerometers.
|
| Both seem to work on my prototype (GTA02v5), as long as X isn't running.
| If I start my X session, event3 is no longer accessible, so I imagine
| something else is reading it already? Does neod open either of them?

neod has them both open, but the input subsystem should be okay with
that and you having them too.  I think you need to make sure you have a
real recent kernel with the patch to improve locking for the service
routine.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf1DMIACgkQOjLpvpq7dMpm3wCfaESLPI5HZ11hI2lKcOad+RSY
KFEAn0Xu4JhMRm46gWGjWSznXPWBjOdT
=9JUy
-END PGP SIGNATURE-

Re: accellerometer test

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| I notice you mention only one chip is currently working as isr source.
| But isn't there two independently configurable pins connected to irqs
| from that one chip?  I didn't dig into the schematic, not sure.

We have two physical chips on there, one at the "top" near the earpiece
and one at the "bottom" near the mic.  The top one is at 45 degrees to
the bottom one.  Having two is something to do with being able to sense
the attitude of the phone in space and not just the position.

Both of the chips interrupt the CPU independently at 100Hz when they are
being read from, but only one of the CPU interrupts has the magic power
to wake from suspend -- the other one is just a regular interrupt that
can't do it.  But I don't think it will make much difference to the wake
threshold scenario since both sensors see a gross action if you pick the
phone up or whatever.

Separately, there are two INT pins on each chip, but on A6 we only
connected one of them to eliminate the pullup.  You can select any
interrupt function on to either interrupt, it didn't seem that we need
more than one at a time.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf07nAACgkQOjLpvpq7dMrunACeK8MzVSkrsdGHEQQXiwhrZjjJ
HQsAn2jyRigiFGp4ShIav4U2RSoMHlgX
=7mjn
-END PGP SIGNATURE-

Re: accellerometer test

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
|> It seems to me there is basically one number you can set, and then you
|> can decide if X, Y and/or Z go above or below that number makes an
|> interrupt.  It looks like this number is absolute, ie, if you set it to
|> 5 then going above or below 5 x 18mG "in + or -" will trigger it.
|>
|> So you can almost get what you are looking for, just that there is only
|> one number allowed.
|
| Excellent! When do you have time to give that a go? :)

Right now... to be clear we talk about wake CPU from suspend with this?

Also is

http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1277

okay now?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf05sIACgkQOjLpvpq7dMpIHwCffQdZeu/qeEERIUc/GkkujivF
TzoAnRcjBz1gTGLYzEm7hlJMfOp8P6mg
=zBcJ
-END PGP SIGNATURE-

Re: accellerometer test

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Am Donnerstag, den 03.04.2008, 09:57 +0100 schrieb Andy Green:
|> We can wake up from one of the accelerometers and not the other -- which
|> is likely okay for real use -- but there is no driver support or API to
|> enable or disable it yet.  I guess it can just expose something in /sys.
|
| Agreed. Can we program the threshold for the three axis individually? If
| so, I'd like to have something like
|
| echo "600 -1 -1"
|> /sys/class/accellerometer/gta02-lis302dl/wakeup_threshold
|
| before falling asleep.
|
| The -1 would mean "ignore this axis", the 600 would refer a change of
| 0.6G irrespectively of sign.

For reference the datasheet is freely available here:

http://www.st.com/stonline/products/literature/ds/12726.pdf

It seems to me there is basically one number you can set, and then you
can decide if X, Y and/or Z go above or below that number makes an
interrupt.  It looks like this number is absolute, ie, if you set it to
5 then going above or below 5 x 18mG "in + or -" will trigger it.

So you can almost get what you are looking for, just that there is only
one number allowed.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf04AAACgkQOjLpvpq7dMoCywCeOAvQiWYOZ8xuEHQbQ6o4X4Mr
vA0AnRJxuAmCnLcpItcfYp6Nx6R8hDg1
=5W3y
-END PGP SIGNATURE-

Re: accellerometer test

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi guys,
|
| just got around to testing one (the 2nd one seems broken or unaccessible
| on my prototypes) of the Neo FreeRunner accellerometers.
|
| Apart from a bit of jitter, I think its pretty accurate -- I'm very
| satisfied with the performance. We can detect lots of different
| orientations, including (the boring) landscape and portrait, but also
| up-side-down (which comes in handy for autosleeping). I'd love to have
| wake-up as well eventually (Andy, Werner?).

We can wake up from one of the accelerometers and not the other -- which
is likely okay for real use -- but there is no driver support or API to
enable or disable it yet.  I guess it can just expose something in /sys.

| The attached python program displays the three axis on the console and
| calls xrandr to mimick the usual (yes, boring) autoswitch from landscape
| to portrait and back.
|
| I'm looking forward to when we start doing gesture recognition (GSoC
| 2008). In the meantime, I'll come up with a simple graphical testing
| program.

Sounds good.  I am curious about what happens if you take that app for a
ride in your car.  What does it show after you accelerated to cruising
speed and just go constantly along with it sat on the passenger seat?
Same as if it was at rest?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf0m/sACgkQOjLpvpq7dMpXXgCfaNfCpndOnR21/ireBskGu5tg
8gsAn1V6otjnx66XypsUYCkNCv+K9hOw
=uG4J
-END PGP SIGNATURE-

Re: [gta02] U-Boot Testing on 04022008

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| I think there is something wrong in our root filesystem. I had this
| situation before. If I use the root filesystem on 04/01/2008, everything
| passes. For the root filesystem on 4/2/2008, I cannot boot into X.

What actually does happen?

It gets stuck on a framebuffer graphical page with the progress bar?
X tries to start and dies and you look at text again?
It freezes?
...

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfzhqoACgkQOjLpvpq7dMqiNwCfSsh4FH+Ou5yVpazTBqYQ2koo
RuIAoI9XcY6P2WaC+fJi6KNG/HLhzZDg
=nlGE
-END PGP SIGNATURE-

Fedora-based cross compilation environment available....

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks -

Just saw this on Fedora devel a few mins ago:

''Several months ago I mentioned that Red Hat had a cross build
environment which generates embedded root filesystems using Fedora
source rpms.  Today we are making it available.  It is rough around the
edges, but functional.  If people express an interest in it we will see
about putting it on Fedora hosted and have future development take place
there.  All the bits are on the GES FTP server:

ftp://ftp.ges.redhat.com/private/releng/arm-linux-beta

The cross build environment is called 'rpmbuildroot'.  This is the
package you are looking for.  Jump into the docs directory for
information on how to get started (skip the top level README).

For the last while the focus has been on the Nokia N770, <==
so you will find that is what the environment is configured for.  There
are also some mips and am33 patches in there (rpmbuildroot is target
arch independent), but they are unlikely to be valid for any modern
Fedora version.

...''

https://www.redhat.com/archives/fedora-devel-list/2008-March/msg00780.html

''...
I took your binutils-cross patch a while ago and added gcc/gdb
cross patches to come up with a way of building cross-toolchains
from Fedora sources:

http://ftp.linux.org.uk/pub/linux/arm/fedora/cross/latest/


Wiki page detailing how to use this on ARM:

http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain

...''

https://www.redhat.com/archives/fedora-devel-list/2008-March/msg00785.html

Just a little straw in the wind...

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1XDLOjLpvpq7dMoRAhmdAJoDuGrEiaDshEj4V0hT5ogDH+8EtwCfdNMJ
mrboFlLDgaNqb7cCqYakY4Y=
=4k69
-END PGP SIGNATURE-

Re: gta02a5 prototype #30 brief review

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

> 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:

>> 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.

> Well, please read again, apart from the bogus link quality and channel 
> setting 

Yep, sorry.  Just not used to things working enough to fail only under
some condition, I'll get used to it.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHxX7nOjLpvpq7dMoRApkLAKCN/2nROQJaC71s4FrxGgP0LqrloACfU4pD
gE/eYWbIb5BLJH98YCEif84=
=wFXX
-END PGP SIGNATURE-

Re: gta02a5 prototype #30 brief review

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

OK.

>>> * 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.

Alright!

>>> * 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 
> now?

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
resume issue.

>>> 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,
otherwise sure.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHxXtyOjLpvpq7dMoRAp5bAJwOQjKU/tPCUxGwB5zCucSvU5y7nQCePyBP
J/C2dnCxRwra+MPsLprugtM=
=0a9q
-END PGP SIGNATURE-

Re: gta02a5 prototype #30 brief review

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

> * on bootup, the device started to crackle and was _very_ slow. Further 
> debugging lead us to the J6 GPIO which was not initialized. Setting it to 1 
> made the system usable and stopped the audio crackles.

This is killed.

> * vibrator is very weak, i guess this is a hardware problem, right?

Still investigating this, it seems it should be hardware one way or the
other.

> * audio is a bit on the soft side, did the amp change or is it a software 
> problem?

No idea.

> * 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.

> * after enabling the BT power node, no bluetooth model is found on USB.

You must additionally echo "0" > bah-de-blah/reset for detection

> * GPS module works ok, very impressive actually, we even got a fix inside the 
> ICE (which has very thick windows).

Ooooh good!

> * 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.

> * the LEDs do not turn off (echo 0 keeps them slightly on)

AAAH

Well they're off here

> * the blue LED can not be turned on

AAAH

It works here

There are problems with PWM that Willie made a workaround patch for by
making them GPIO on/off for now, maybe it will help until the PWM issue
is understood.

> * xrandr -o 2 just crashes the X server, --output default --rotate left does 
> not work

Dunno.

> * There's an interesting xglamo xrender performance problem vs. software 
> rendering. I'll post more details after running a benchmark.
> 
> * I got a LEDPWRFAIL in dmesg:
>   PCF50633_INT4_LEDPWRFAIL

Yeah I have it on my whiteboard.  It is to do with the problem of
backlight not coming back on easily that has always been there.

> * 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.

> 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.

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.

> * battemp and friends do not contain information yet.

Raster was in here yesterday asking about that, he is on it.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHxPFaOjLpvpq7dMoRAt0IAJ9boV42JTD0TphnYwY8On3GhCiMYQCdFYYT
QoR26vBsNqK8SfL1xvjoRHU=
=XwaC
-END PGP SIGNATURE-