| 01:43.19 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 02:03.23 | *** join/#gpe hvontres|home (n=hvontres@adsl-75-30-201-148.dsl.sndg02.sbcglobal.net) |
| 02:10.58 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 02:41.05 | *** join/#gpe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 03:29.59 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 03:33.32 | *** join/#gpe jg (n=jg@169.222.11.60) |
| 04:31.21 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 04:58.52 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 05:44.10 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 05:45.21 | *** join/#gpe jg (n=jg@169.222.11.60) |
| 05:55.34 | *** join/#gpe jg_ (n=jg@169.222.11.60) |
| 06:25.03 | *** join/#gpe _law_ (n=law@80.122.23.18) |
| 06:29.24 | *** join/#gpe rob_w (n=bob@p85.212.184.235.tisdip.tiscali.de) |
| 07:16.31 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 07:20.07 | *** join/#gpe jg (n=jg@169.222.11.60) |
| 07:29.24 | *** join/#gpe _law_ (n=law@mx2.stiftadmont.at) |
| 07:45.01 | *** join/#gpe theturtle (n=theturtl@guiness.lifl.fr) |
| 08:54.42 | *** join/#gpe celsion (n=unknown@p5487BD9D.dip0.t-ipconnect.de) |
| 09:01.35 | *** join/#gpe obergix[work] (n=olivier@inf-berger.int-evry.fr) |
| 09:10.40 | *** join/#gpe bedboi (n=bedboi@c3lab.poliba.it) |
| 09:36.17 | *** join/#gpe cel (n=unknown@p5487AFCB.dip0.t-ipconnect.de) |
| 10:19.55 | *** join/#gpe polyonymous_ (n=hacker@pD95390E7.dip0.t-ipconnect.de) |
| 10:35.50 | *** join/#gpe jg (n=jg@202.142.40.162) |
| 10:41.31 | *** join/#gpe pH5 (n=ph5@e178232167.adsl.alicedsl.de) |
| 10:57.18 | florian_kc | good monring |
| 11:11.43 | bedboi | florian_kc: do you know if gpe-expenses has been ported to maemo? |
| 11:14.21 | _law_ | hi florian_kc |
| 11:19.44 | neal | florian: http://linuxtogo.org:8008/timeline still wants me to login. |
| 11:21.23 | florian_kc | neal: yes, for some reason it broke the database :-( |
| 11:21.40 | neal | what's it? |
| 11:21.42 | neal | timeline? |
| 11:21.57 | florian_kc | neal: svntrac |
| 11:22.29 | neal | oh. |
| 11:31.48 | *** join/#gpe shiyee (n=Shiyee@homer.cs.aau.dk) |
| 11:38.04 | pb__ | florian_kc: good morning |
| 12:04.40 | *** join/#gpe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 12:26.39 | *** join/#gpe florian_kc (n=fuchs@dns.kernelconcepts.de) |
| 12:31.26 | _law_ | pH5, my bluetooth now works fine (inkl. gprs / umts) :-) gnome-bluez works as passkey-agent, gpe-bluetooth needs some work i think |
| 12:32.31 | florian_kc | re |
| 12:33.24 | florian_kc | _law_: could you check the error log if anything is in there when gpe-bluetooth should have displayed the pin dialog. |
| 12:34.52 | pb__ | florian_kc: it sounds like the dbus protocol used by hcid has changed. |
| 12:35.05 | pb__ | I guess gpe-bluetooth needs updating to work with the new style. |
| 12:35.06 | _law_ | florian_kc, have you already tried blue >= 3.x |
| 12:35.35 | pb__ | that's slightly annoying. I wonder why Marcel did this. |
| 12:37.21 | florian_kc | pb__: something like this, i remember i have seen an error that indicated something like this a while ago in an OZ image but i'm not sure anymore |
| 12:38.33 | florian_kc | _law_: hmmm maybe, i guess OZ from last autumn was a little bit more up to date than familiar. |
| 12:39.33 | florian_kc | i can take a look as soon as i manage to test a new image on a device with bluetooth |
| 12:43.45 | _law_ | florian_kc, i have switch to angstrom |
| 12:44.27 | _law_ | but there is an expamle passkey-agent in the new bluez-utils sources... |
| 12:51.42 | florian_kc | Currently my job is to make a stupid FM receiver work... |
| 12:52.42 | florian_kc | _law_: ok that's good - i guess we can look up the new api there easily |
| 13:07.38 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 13:12.25 | pb__ | florian_kc: heh, I also have a stupid fm receiver that I need to make work |
| 13:13.50 | florian_kc | :-) |
| 13:15.07 | florian_kc | pb__: this one is a Si4701... i can talk to it and set registers but it refuses to activate itself |
| 13:15.21 | pb__ | florian_kc: ah, that's the same chipset that we have |
| 13:16.01 | pb__ | well, actually our newer boards are using si4703, but the two parts are virtually identical |
| 13:16.45 | pb__ | I could probably send you a copy of my driver code if you wanted. |
| 13:17.46 | pb__ | iirc, the early problems we had with the si4701 were mostly caused by (a) an endianness mismatch between the chip and the host cpu, and (b) our early sample devices not having any firmware in their mask rom. If your parts are from full production then the latter ought not to be a problem for you though. |
| 13:20.14 | florian_kc | pb__: I need to activate and test it in the bootloader which is really easy because i have a working implementation for a different bootloader. But with my u-boot it never sets the firmware revision and enable bits... but it does with the other one. |
| 13:20.56 | florian_kc | pb__: Unluckily it worked on the same board with the other bootloader. |
| 13:21.08 | pb__ | ah right |
| 13:21.26 | pb__ | it doesn't set those bits until the firmware is booted, which in turn doesn't happen until you have gone through the power-up procedure. |
| 13:21.56 | pb__ | it'd be worth checking you have the bit ordering in the registers right. I think the si47xx is big endian and you need to reverse the byte order if you are on a little endian cpu. |
| 13:22.40 | florian_kc | hmm... let me check the code i copied :-) |
| 13:23.52 | pb__ | fwiw,my init code writes 0x4801, 0x0000, 0xc804, 0x131f (in host ordering) to registers 2-5. |
| 13:24.58 | pb__ | so, on the i2c bus, that'd translate to <start> <addr> 0x48, 0x01, 0x00, 0x00, 0xc8, 0x04, 0x13, 0x1f <stop> |
| 13:25.07 | neal | endianness sucks. |
| 13:25.19 | neal | Why didn't we just stay with VAX endianness? |
| 13:25.36 | pb__ | We should just have stayed with 8-bit cpus. |
| 13:25.56 | neal | would eliminate a lot of the security problems |
| 13:26.34 | florian_kc | heh indeed :-) |
| 13:27.05 | florian_kc | pb__: ok, let me take a look what it sends here... it looks like someone made it really complicated |
| 13:27.22 | pb__ | righto |
| 13:27.28 | pb__ | I'm pretty sure it doesn't need to be complicated. |
| 13:28.10 | florian_kc | i have a nice struct of structs describing the registers... for a bootloader. |
| 13:29.41 | pb__ | by the way, did you ever hear any more about XIos and their bankrupcy proceedings? |
| 13:30.20 | florian_kc | pb__: hmm... i just noticed it reports a chip revision not mentioned by the datasheet. |
| 13:30.35 | florian_kc | pb__: i'll ask, one sec |
| 13:30.50 | pb__ | florian_kc: what's the value that you see in that status register? |
| 13:48.41 | florian_kc | pb__: you mean the "powercfg" register? |
| 13:50.05 | pb__ | florian_kc: I was actually thinking of the chipid one, but powercfg would be interesting too |
| 13:50.38 | florian_kc | pb__: no news about xios... the last information we got was that our priority was extremely low and it it would be unlikely to get anything. |
| 13:51.00 | pb__ | :-( |
| 13:51.05 | pb__ | yeah, I think we're in the same situation |
| 13:51.05 | pb__ | oh well |
| 13:51.49 | florian_kc | ~lart XIos |
| 13:52.35 | florian_kc | pb__: i'll check the registers as soon as i'm back from lunch |
| 13:52.41 | pb__ | righto |
| 13:52.43 | pb__ | bon appetit |
| 13:52.47 | florian_kc | thanks |
| 13:52.50 | florian_kc | bbl |
| 14:10.56 | *** join/#gpe kb7sqi (n=kb7sqi@cpe-075-177-056-201.triad.res.rr.com) |
| 14:26.19 | *** join/#gpe pH5_ (n=ph5@e178232112.adsl.alicedsl.de) |
| 14:40.05 | *** join/#gpe petterhj (i=petterhj@217-122-156.112220.adsl.tele2.no) |
| 14:41.57 | florian_kc | re |
| 14:47.21 | pb__ | wb |
| 14:50.56 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 14:53.30 | *** join/#gpe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 14:58.06 | *** join/#gpe rob_w|mis (n=rob_w@p85.212.184.235.tisdip.tiscali.de) |
| 15:01.33 | *** join/#gpe tnb (n=tnb@sdgsystems.net) |
| 15:42.46 | *** join/#gpe bedboi (n=bedboi@c3lab.poliba.it) |
| 15:55.16 | *** join/#gpe shiyee (n=Shiyee@0x50a16802.abnxx4.adsl-dhcp.tele.dk) |
| 16:24.14 | florian_kc | bedboi: no idea about gpe-expenses, but it would be a good idea to ask |
| 16:27.26 | florian_kc | pb_: 0x42 0x12 0x00 0x08 is what i have in the deviceid and chipid register... |
| 16:29.21 | *** join/#gpe satadru (n=satadru@cpe-66-65-85-121.nyc.res.rr.com) |
| 16:30.49 | florian_kc | pb__: the data from the struct seems to be correct... mostly. |
| 16:31.17 | pb__ | is that data in chip byte order, or host byte order? |
| 16:31.23 | pb__ | 0x1242 would be correct for the device id register |
| 16:32.33 | satadru | Hi all, I just wanted to mention that with BobofDoom from hackndevs help I got gpe loading on the Palm Treo 680 last night... It runs very very well |
| 16:32.34 | satadru | ;-) |
| 16:32.42 | pb__ | 0x800 in chipid means rev b silicon, which is probably right as well |
| 16:33.05 | pb__ | (and no firmware loaded, which means it doesn't think you've set ENABLE yet) |
| 16:33.16 | pb__ | what's in your powercfg register? |
| 16:33.35 | pb__ | satadru: very good |
| 16:34.13 | florian_kc | pb__: that's the chip byte order... unless i missed something important. |
| 16:34.49 | florian_kc | pb__: right - even if my data sheet dooesn't mention this revision the mfgid is correct too. |
| 16:35.56 | pb__ | what datasheet are you looking at? |
| 16:36.38 | pb__ | the latest si4700/01 data that I have is v0.87, dated feb 06 |
| 16:37.46 | florian_kc | ok, my one i have is 0.6 :-} |
| 16:38.45 | pb__ | ah, that's the datasheet for rev a |
| 16:38.45 | pb__ | your silicon is almost certainly rev b: I don't think the -a parts shipped in any volume, and they have been obsolete for ages. |
| 16:38.45 | florian_kc | it says "Confidential" on every page |
| 16:42.55 | florian_kc | hrm, the public ones are a little bit limited :-/ |
| 16:44.50 | *** join/#gpe mccarthy (n=mccarthy@granular.che.pitt.edu) |
| 16:45.25 | florian_kc | 0x01 0x40 is the powercfg register |
| 16:45.28 | mccarthy | hi florian_kc |
| 16:45.33 | mccarthy | hi pb_ |
| 16:45.36 | florian_kc | hi mccarthy |
| 16:48.06 | florian_kc | pb__: that means i set the power_enable bit there and the mute_disable one are set which is what the code does. |
| 16:49.22 | *** join/#gpe pH5 (n=ph5@e178232112.adsl.alicedsl.de) |
| 16:49.55 | pb__ | yeah, that looks right |
| 16:50.35 | pb__ | are you sure the chip isn't being held in reset or something? |
| 16:50.52 | pb__ | (by external logic controlling its RESET signal and/or clock, I mean) |
| 16:51.56 | florian_kc | pb__: no, the reset is connected to a gpio pf the cpu and i it stays high unless the code performs the actual reset |
| 16:54.33 | pb__ | okay |
| 16:55.15 | pb__ | do you have the right delay between setting ENABLE and reading the chipid field? it takes a couple of hundred milliseconds for the firmware to load. |
| 16:56.22 | florian_kc | hrm... i'm pretty sure i don't have... like the other bootloader |
| 17:06.10 | florian_kc | the reset sequence in the other bootloader is wrong anyway, i wonder how this crap is expected to wirk |
| 17:06.15 | florian_kc | eh work |
| 17:07.19 | pb__ | doh |
| 17:08.40 | florian_kc | it should hold the chip in reset until power and clock signal are there... but it pulls it down for a short while after that happened. |
| 17:09.07 | florian_kc | in this case its maybe just a matter of a slightly different timing... |
| 17:20.13 | florian_kc | looks good... but my device_enable stays 0 |
| 17:34.52 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 17:51.56 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 17:52.10 | *** join/#gpe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 17:57.25 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 18:02.39 | *** join/#gpe goxboxlive (n=goxboxli@9.80-202-160.nextgentel.com) |
| 18:25.33 | florian_kc | pb__: It works... finally. The fix was to turn on the USB clock of the CPU... |
| 18:36.00 | pb_ | florian_kc: ah, how odd |
| 18:37.14 | florian_kc | I wasn't able to find the relationship... and the clock signal to the tuner or the reset didn't change (of course). |
| 19:19.30 | florian_kc | bbl |
| 19:24.24 | *** join/#gpe bart_ (n=bart@d515206AF.access.telenet.be) |
| 19:31.44 | *** join/#gpe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 19:51.56 | *** join/#gpe _law_ (n=_law_@213.173.86.202) |
| 19:57.06 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 20:08.11 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 20:30.54 | *** join/#gpe goxboxlive (n=goxboxli@9.80-202-160.nextgentel.com) |
| 20:34.17 | *** join/#gpe BBrox (n=ulmer@bbrox.org) |
| 20:39.10 | *** join/#gpe florian (n=fuchs@84-245-178-31.bpool.celox.de) |
| 21:30.34 | *** join/#gpe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 21:50.41 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:02.03 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:10.26 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:19.15 | *** join/#gpe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 22:20.29 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:25.59 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:37.55 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 22:47.02 | *** join/#gpe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 23:15.23 | *** join/#gpe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
| 23:20.06 | *** join/#gpe jg (n=jg@169.222.11.60) |
| 23:31.17 | *** part/#gpe _law_ (n=_law_@213.173.86.202) |
| 23:40.32 | *** join/#gpe polyonymous_ (n=hacker@pD953BAEC.dip0.t-ipconnect.de) |
| 23:40.58 | *** join/#gpe bronson_ (n=bronson@c-24-5-71-119.hsd1.ca.comcast.net) |
| 23:59.36 | *** join/#gpe bronson_ (n=bronson@adsl-75-36-145-166.dsl.pltn13.sbcglobal.net) |