**** BEGIN LOGGING AT Sun Jan 08 02:59:57 2012
Jan 08 10:56:46 <mrmoku> GNUtoo|laptop: ping
Jan 08 12:42:04 <angelox|laptop> good morning
Jan 08 13:57:03 <rah> who is Lars-Peter Clausen?
Jan 08 14:11:25 <PaulFertser> rah: here it's the one who puts lots of effort into maintaining the OM kernel
Jan 08 14:11:33 <misc> rah: the one called larsc
Jan 08 14:13:43 <rah> misc: thanks
Jan 08 14:13:49 <rah> larsc: ping :-)
Jan 08 14:16:30 <larsc> rah: pong
Jan 08 14:17:27 <rah> larsc: I'm looking at the gta01-machine-2.6.37 branch of git.openmoko.org/git/kernel.git
Jan 08 14:17:46 <rah> larsc: you committed a number of patches for gta01 support
Jan 08 14:18:10 <rah> larsc: does this branch contain the latest gta01 code?
Jan 08 14:18:39 <rah> larsc: I want to build a kernel for a gta01 for shr-core but the latest bootable kernel I can find is 2.6.29
Jan 08 14:19:09 <rah> (that is, the latest kernel I can find elsewhere)
Jan 08 14:21:24 <larsc> rah: it should be to hard to forward port it to a new kernel version if you want a to use a more recent version
Jan 08 14:22:19 <rah> larsc: yes, that's what I'm looking at doing but it makes sense to forward-port from the latest gta01-supporting tree that I can find
Jan 08 14:22:53 <rah> larsc: there seem to be even more recent gta01 patches in the andy-tracking tree
Jan 08 14:23:08 <rah> larsc: so I guess I want to know: which tree would you suggest forward-porting from? :-)
Jan 08 14:23:18 <pabs3> does 3.2 mainline run on gta02 ?
Jan 08 14:23:52 <larsc> rah: gta01-2.6.37
Jan 08 14:24:06 <larsc> rah: you'll also need pcf50606-2.6.37
Jan 08 14:24:54 <rah> larsc: you mean gta01-machine-2.6.37?  or are you referring to a different tree?
Jan 08 14:25:23 <larsc> rah: sorry yes
Jan 08 14:25:37 <rah> larsc: ok, thanks
Jan 08 18:50:53 <GNUtoo> hi DocScrutinizer 
Jan 08 18:51:19 <GNUtoo> I have one headphone-for-cellphone that fit into the gta02 and the gta04
Jan 08 18:51:35 <GNUtoo> but on gta02 only the right part can be eared
Jan 08 18:51:52 <GNUtoo> on the gta04 the sound is ok when I press the pickup/hangup button
Jan 08 18:52:03 <GNUtoo> else it seem mono but for both ears
Jan 08 18:52:08 <GNUtoo> the question is:
Jan 08 18:52:23 <GNUtoo> is it possible to make it compatible with gta02 and gta04
Jan 08 18:54:49 <GNUtoo> like for instance I swap some pins resoldering some wire in the mic part
Jan 08 18:54:59 <GNUtoo> and I mess with alsamixer
Jan 08 18:55:06 <GNUtoo> and have it working on both phones
Jan 08 19:16:17 <mrmoku> hehe
Jan 08 19:16:35 <mrmoku> GNUtoo: I was looking through my headphones-for-cellphones today too
Jan 08 19:16:41 <mrmoku> found none
Jan 08 19:17:07 <mrmoku> and I looked at the pin layout of gta04 compared with gta02
Jan 08 19:17:16 <mrmoku> don't think it is possible
Jan 08 19:18:31 <GNUtoo> ok
Jan 08 19:18:41 <GNUtoo> then I guess I'll go for gta04
Jan 08 19:18:50 <GNUtoo> as the gta02 has the capacitor problem
Jan 08 19:19:52 * mrmoku will order some cheepo iphone compatible one
Jan 08 19:20:34 <GNUtoo> ok but iphone has the same 2.5" thing?
Jan 08 19:20:38 <GNUtoo> the pinout may be the same
Jan 08 19:20:41 <GNUtoo> but not the size
Jan 08 19:20:51 * GNUtoo will simply resolder the one he got
Jan 08 19:33:47 <DocScrutinizer> gta04 pinout is a mess
Jan 08 19:36:42 <DocScrutinizer> it's basically incompatible to everything you would expect to be able to buy in an electronics store. Obviously Nikolaus copied some pinout that got invented by Apple to make their iPhones incompatible to all 2nd source headsets not specially fsckdup for use with iPhone, while their apple headsets (maybe) would usually work with arbitrary other mp3-players etc
Jan 08 19:38:16 <GNUtoo> ok
Jan 08 19:38:32 <mrmoku> GNUtoo: gta04 manual states explicitely that iphone headphones are compatible
Jan 08 19:38:59 <DocScrutinizer> the big fsckup with gta04 pinout is the mic-input (the sensitive line of audio input, the one that mustn't be touched or you get hum and plops on any amp) on GTA04 is connected to *SLEEVE* and thus to cable shield braid, when using any "normal" plug
Jan 08 19:39:30 <GNUtoo> yes but what kind of iphones?
Jan 08 19:39:49 <mrmoku> iphone 2g / ipad / ipod
Jan 08 19:39:53 <mrmoku> is written there I think
Jan 08 19:39:58 * mrmoku checks
Jan 08 19:40:04 <GNUtoo> ok
Jan 08 19:40:09 <GNUtoo> because I've read that:
Jan 08 19:40:18 <DocScrutinizer> so if you consider buying a plug and a cable at your electronics store and DIY a cable... forget it, the plug you could buy won't allow you to connect the cable in a sane way so it could work with GTA04 pinout
Jan 08 19:40:53 <GNUtoo> The pin assignment (not necessarily the diameter) we have choosen is compatible to e.g.:
Jan 08 19:41:02 <GNUtoo> note the not necessarlily the diameter
Jan 08 19:41:14 <mrmoku> ipod + iphone 2g + sharp zarus sl860
Jan 08 19:41:31 <GNUtoo> yes but what about the diameter?
Jan 08 19:43:49 <mrmoku> hmm
Jan 08 19:44:03 <mrmoku> searching in amazon ... 3.5mm :-/
Jan 08 19:44:50 <mrmoku> DocScrutinizer: so no way to rework the gta02 cable?
Jan 08 19:44:56 <mrmoku> damn
Jan 08 19:45:37 <mrmoku> GNUtoo: btw. I start to get interested in bluetooth audio too :)
Jan 08 19:45:59 <mrmoku> probably we will get a new car hifi with bt
Jan 08 19:46:27 <DocScrutinizer> mrmoku: all plugs you could get are built in a way so base (the 'hot wire' mic input, on GTA04) is connected to the mechanical latch that holds the cable and thus contacts to the shielding braid
Jan 08 19:47:22 <DocScrutinizer> mrmoku: plugs with metal housing/hood will even directly expose that line to touch it with your fingers etc
Jan 08 19:47:39 <mrmoku> :/
Jan 08 19:48:10 <DocScrutinizer> it's definitely the most kinky weirdo idea I ever heard of to connect mic hot input to a 2.5mm base contact
Jan 08 19:48:21 <mrmoku> DocScrutinizer: so the only option would be an apple compatible thing with adapter?
Jan 08 19:48:25 <mrmoku> or not even that?
Jan 08 19:48:33 <DocScrutinizer> yep
Jan 08 19:48:33 <GNUtoo> mrmoku, ok
Jan 08 19:49:23 <GNUtoo> ok I'll re-use the cable for gta02 then
Jan 08 19:49:28 <DocScrutinizer> I guess apple built their own fsckdup plugs that isolate base contact from shielding and hood (well hood most likely plastic anyway)
Jan 08 19:52:44 <DocScrutinizer> gta02 pinout been completely different to gta04. from tip to base we got: mic, left, right, GND. Note the GND on base as every EE would expect, even in his wildest nightmares
Jan 08 19:52:57 <DocScrutinizer> gta04 has hot mic in there
Jan 08 19:54:45 <GNUtoo> ahhh iphone 2g not ipod 2g
Jan 08 19:54:58 <DocScrutinizer> to be absolutely unambiguous: gta04 has (tip to base) left, right, GND, mic-in. While it *should* be: left, right, mic-in, GND
Jan 08 19:56:25 <DocScrutinizer> pushing the hold-button will short base and 3rd ring and thus rectify things for left/right audio-out
Jan 08 19:56:44 <GNUtoo> I don't understand
Jan 08 19:56:49 <DocScrutinizer> on usual headsets which have what gta04 *should* have
Jan 08 19:56:58 <GNUtoo> doesn't the iphone has a 3.5"
Jan 08 19:57:08 <GNUtoo> the gta02/gta04 has 2.5"
Jan 08 19:57:12 <GNUtoo> right?
Jan 08 19:57:34 <DocScrutinizer> yes, gta02/04 has 2.5mm
Jan 08 19:57:48 <GNUtoo> so buying an iphone headphones won't work
Jan 08 19:57:58 <DocScrutinizer> I don't really care what apple got on their crappy devices
Jan 08 19:58:07 <GNUtoo> because the plug will be too big....
Jan 08 19:58:54 <GNUtoo> mrmoku, ^^^
Jan 08 19:59:06 <GNUtoo> I mean the plug of the hedphones
Jan 08 20:00:03 <mrmoku> GNUtoo: apple headphones + nokia adapter :-P
Jan 08 20:00:22 <GNUtoo> ah ok
Jan 08 20:00:26 <GNUtoo> nokia adapter?
Jan 08 20:00:31 <GNUtoo> where did you find that?
Jan 08 20:00:40 <GNUtoo> I've just bought nokia headphones
Jan 08 20:00:42 <mrmoku> GNUtoo: in the manual
Jan 08 20:00:43 <GNUtoo> ok
Jan 08 20:00:55 <mrmoku> There are easy to get 2.5mm to 3.5mm adapters. E.g. Nokia AD-52.
Jan 08 20:01:13 <GNUtoo> ah the AD52
Jan 08 20:01:21 <GNUtoo> ok
Jan 08 20:01:34 <GNUtoo> I've one I think
Jan 08 20:01:43 <GNUtoo> but mine is very bad
Jan 08 20:01:48 <GNUtoo> it doesn't fit well
Jan 08 20:03:15 <pespin> zub, hi, vI just saw your mail regarding eflvala but I'm quite ill and I'mnot able to look into it. Idon't know when will I have time to look into it as next week I start exams, thanks for the contributions. Please if I don't say anything during next days ping me again
Jan 08 20:10:07 <zub> pespin: no problem. que se mejore!
Jan 08 20:17:20 <DocScrutinizer> mrmoku: (adapters) yes, and it seems every one of them invents another re-wiring scheme to adapt carp-A to crap-B
Jan 08 20:18:50 <mrmoku> yeah, not funny :/
Jan 08 20:18:51 <DocScrutinizer> you'd probably need a 1:1 2.5->3.5 converter, plus a 3.5->3.5 apple to "normal" headsets adapter
Jan 08 20:19:11 <mrmoku> hmm
Jan 08 20:19:18 <DocScrutinizer> I really don't get it what's been Nikolaus' rationale to do that weird thing
Jan 08 20:19:22 <mrmoku> GNUtoo: you have a jabra bt headset IIRC?
Jan 08 20:45:56 <DocScrutinizer> well, looking at only the schematics I have access to (http://projects.goldelico.com/upload/gta04-main/files/GTA04A3-1-complete.pdf p80) the whole hs-jack thing is completely confusing. a) is the shown symbol for headset receptacle actually showing what the component does, and what's the meaning of the note "pin 1 & 5 swapped!"?  b) what means the color coding as noted there? usually on *every* adapter/cable/multiplug-receptacle-
Jan 08 20:45:57 <DocScrutinizer> component/TV etc you *always* got white=left, RED=right, yellow=Video/Mic/whatever c) what's R703 for?? best to make it NC d) usually those normally-closed contacts like on pin2 and pin3 of receptacle are the left/right return to feed internal speakers just when there's no headset plugged in, the way this component symbol suggests they work is rather weird
Jan 08 20:48:03 <lindi-> DocScrutinizer: is there a commit message that might explain it?
Jan 08 20:48:14 <DocScrutinizer> nfc
Jan 08 20:50:26 <mrmoku> JaMa: gnutls-native is failing upon me
Jan 08 20:50:29 <mrmoku> JaMa: any idea?
Jan 08 20:50:46 <mrmoku> | *** Libgcrypt v1.4.0 or later was not found. You may want to get it from
Jan 08 20:55:31 <DocScrutinizer> lindi-: only thing I know is Nikolaus explaining to me they checked some weird adapter to decide how to wire up the headset connector, and GTA04 now matches that adapter \o/
Jan 08 20:56:54 <DocScrutinizer> my suggestion to follow a more generally accepted *standard* like http://www.omtp.org/OMTP_Local_Connectivity_Wired_Analogue_Audio_v1_0.pdf got basically rejected
Jan 08 20:59:22 <rah> how can I cross-compile a kernel without using bitbake?
Jan 08 21:02:06 <DocScrutinizer> btw above standard is what Nokia is using for all their devices since years now, and I think a lot of other manufacturers adopted it as well as it's really the most sane concept
Jan 08 21:02:35 <PaulFertser> rah: basically, you can simply use an emdebian toolchain (or whatever you've got in your distro) and compile the kernel as usual specifying ``make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- ''
Jan 08 21:03:30 <rah> PaulFertser: can I not use the oe cross-compiler?
Jan 08 21:04:18 <rah> PaulFertser: or rather, how can I use the oe cross-compiler?
Jan 08 21:05:56 <PaulFertser> rah: of course you can, just specify it with full path in your CROSS_COMPILE=
Jan 08 21:08:37 <rah> PaulFertser: what would the path be?  I can't seem to find it under tmp-eglibc/
Jan 08 21:09:12 <rah> PaulFertser: and should CROSS_COMPILE be set to just the prefix?
Jan 08 21:09:44 <PaulFertser> rah: no, to the full path. I've forgotten OE enough to not be able to tell you the whole path, but it's somewhere in tmp/ in there.
Jan 08 21:10:34 <rah> PaulFertser: in that case, full path of which executable, cc?
Jan 08 21:11:03 <PaulFertser> rah: full path with prefix but without the ``gcc'' part.
Jan 08 21:11:57 <rah> right, I see
Jan 08 21:16:33 <DocScrutinizer> I guess path as in $PATH
Jan 08 21:25:26 <PaulFertser> DocScrutinizer: hey hey :)
Jan 08 21:25:37 <DocScrutinizer> heyhey :-)
Jan 08 21:42:38 <DocScrutinizer> PaulFertser: could socat open a netlink socket and wait for kevents?
Jan 08 21:42:54 <DocScrutinizer> or is there any other cmdline tool to do that?
Jan 08 21:44:36 <DocScrutinizer> (except python, obviously ;-D)
Jan 08 21:46:19 <PaulFertser> DocScrutinizer: not sure but "udevadm monitor" should work great for kevents.
Jan 08 21:46:40 <DocScrutinizer> seems it only listens to UEVENT not KEVENT
Jan 08 21:47:53 <DocScrutinizer> or wait... I hope a kevent would get sent to *all* recipients who got a netlink socket opened? or would it only get sent to one of them?
Jan 08 21:49:13 <DocScrutinizer> [2012-01-08 22:29:22] <DocScrutinizer> probably udev-adm monitor would be a better choice for getting some ideas about it
Jan 08 21:49:15 <DocScrutinizer> [2012-01-08 22:31:05] <DocScrutinizer> alas iirc we need to listen to KEVENT, not UEVENT, when we want some useful functions for h-e-n
Jan 08 21:49:27 <PaulFertser> DocScrutinizer: udevadm monitor --kernel
Jan 08 21:49:33 <DocScrutinizer> ooooh
Jan 08 21:49:42 <PaulFertser> DocScrutinizer: kernel uevents
Jan 08 21:49:49 <DocScrutinizer> :-D
Jan 08 21:50:26 <DocScrutinizer> IroN900:~# udevadm monitor --kernel
Jan 08 21:50:28 <DocScrutinizer> udevmonitor will print the received events for:
Jan 08 21:50:29 <DocScrutinizer> UEVENT the kernel uevent
Jan 08 21:50:55 <PaulFertser> lindi-: btw, knowing you're into low-level stuff: OpenOCD 5.0 now supports threads for FreeRTOS and Linux, i.e. you can stop your target with gdb and see all the running processes (kernel and userspace threads all alike) and switch between them, see the individual stack frames, local variables etc etc.
Jan 08 21:51:03 <DocScrutinizer> I seem to recall I played with it and I didn't see any of the non-fs kernel events, e.g for VBUS etc
Jan 08 21:51:10 <rah> PaulFertser: works, thanks
Jan 08 21:51:21 <PaulFertser> rah: :)
Jan 08 21:52:53 <DocScrutinizer> PaulFertser: anyway, no event gets reported on above cmdline, when I un/plug charger to N900
Jan 08 21:54:47 <PaulFertser> DocScrutinizer: i'm not sure it should given the crappiness of the drivers.
Jan 08 21:55:59 <DocScrutinizer> hmm, vbus is detected via twl4030 and evidently *something* in system notices plug events instantly (or is polling faster than 4/s which I doubt)
Jan 08 21:56:57 <DocScrutinizer> :-/
Jan 08 21:56:59 <DocScrutinizer> bme_RX-51  739       root    7r   REG        0,0     4096        951 /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
Jan 08 21:57:06 <DocScrutinizer> though
Jan 08 21:57:18 <DocScrutinizer> bme_RX-51  739       root   14u  unix 0xce6a4a80                4322 socket
Jan 08 21:57:29 <DocScrutinizer> not sure if that's a netlink socket
Jan 08 22:04:01 <lindi-> PaulFertser: interesting
Jan 08 22:04:28 <lindi-> PaulFertser: however I analyze my memory dumps normally with the "crash" tool
Jan 08 22:04:35 <lindi-> PaulFertser: that has similar features
Jan 08 22:05:08 <PaulFertser> lindi-: and this new feature works for a running system.
Jan 08 22:06:37 <lindi-> PaulFertser: so does crash when you take a memory dump of the running system :)
Jan 08 22:06:49 <lindi-> PaulFertser: there's also --volatile
Jan 08 22:07:09 <PaulFertser> lindi-: thanks for the pointer.
Jan 08 22:08:25 <lindi-> PaulFertser:  it's somewhat difficult to google
Jan 08 22:10:59 <rah> WIN
Jan 08 22:11:23 <rah> 2.6.37 openmoko tree successfully compiles for my gta01
Jan 08 22:11:29 * rah builds SHR image
Jan 08 22:12:01 <PaulFertser> lindi-: ah, it's called openocd rtos support.
Jan 08 22:12:18 <rah> WIN
Jan 08 22:12:25 <rah> shr image built :-)
Jan 08 22:12:29 <lindi-> rah: I'm already at 2.6.39 :)
Jan 08 22:13:06 <rah> eh?
Jan 08 22:13:09 <rah> lindi-: with a gta01?
Jan 08 22:19:19 <lindi-> rah: no, gta02
Jan 08 22:20:29 <rah> oh I see
Jan 08 22:20:39 <rah> you're just saying "mine's bigger than yours" ;-)
Jan 08 22:23:56 <DocScrutinizer> PaulFertser: maybe the kernel actually doesn't emit a KEVENT for VBUS change
Jan 08 22:24:04 <DocScrutinizer> :-/
Jan 08 22:24:19 <DocScrutinizer> seems bme is polling like ever 1 .. 2 seconds
Jan 08 22:24:53 <DocScrutinizer> strace -p `pidof /usr/sbin/bme_RX-51`
Jan 08 22:28:42 <rah> WIN
Jan 08 22:28:45 <rah> kernel boots :-)
Jan 08 22:30:25 <PaulFertser> DocScrutinizer: quite possibly so...
Jan 08 22:41:13 <DocScrutinizer> :nod:
Jan 08 22:50:45 <DocScrutinizer> PaulFertser: hmm, Jan  8 23:48:59 IroN900 ke_recv[1840]: prop_modified:1889: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus
Jan 08 22:53:12 <PaulFertser> DocScrutinizer: bme polling <-> some shit hal plugin <-> hal ?
Jan 08 22:54:18 <DocScrutinizer> possibly
Jan 08 22:54:21 <DocScrutinizer> http://paste.debian.net/151479/
Jan 08 22:54:32 <DocScrutinizer> unplug, sleep5, plug
Jan 08 22:54:43 <DocScrutinizer> first thing seems read from dbus
Jan 08 22:55:45 <DocScrutinizer> fd3 = syslog
Jan 08 23:00:15 <PaulFertser> DocScrutinizer: sorry, going to sleep atm, had a long day. And tbh you know my opinion about 2.6.28 maemo forks and the maemo os that's using it.
Jan 08 23:00:29 <DocScrutinizer> PaulFertser: where would I read to check if they implemented proper kevent sending for sys/*/vbus ?
Jan 08 23:00:41 <DocScrutinizer> :-D
Jan 08 23:00:43 <DocScrutinizer> yeah
Jan 08 23:01:06 <PaulFertser> DocScrutinizer: the kernel sources, but i can't tell right atm what should be looked at there.
Jan 08 23:01:18 <DocScrutinizer> ok, np
Jan 08 23:01:24 <DocScrutinizer> have a nice rest :-)
Jan 08 23:01:31 <PaulFertser> DocScrutinizer: thanks, you too :)
Jan 08 23:02:06 <DocScrutinizer> indeed I should - immediately. in 5.5h the night is over
Jan 08 23:02:17 <DocScrutinizer> :-(
Jan 08 23:04:13 <PaulFertser> Luckily we still have "holidays" here, 31 Dec till 9 Jan inclusive.
Jan 08 23:04:38 <PaulFertser> Some say it's not luckily though, assuming too many people drink too much during these days.
Jan 08 23:05:24 <PaulFertser> I do not, i have some job to do, and unfortunately it's not related to any community efforts (though it involves stm32+freertos+openocd+gcc+newlib).
Jan 08 23:05:34 <PaulFertser> Anyway, good night to everybody.
Jan 08 23:05:47 <PaulFertser> DocScrutinizer: sleep well
Jan 08 23:06:02 <DocScrutinizer> thanks, hope I will, sooooon
Jan 08 23:08:20 * DocScrutinizer would've thought kernel sending of kevents for sysnode state changes was an implicit thing dealt with by some macro for sysnode handling
Jan 09 01:20:28 <angelox|laptop> good night all
**** ENDING LOGGING AT Mon Jan 09 02:59:57 2012