| 00:00.09 | dcordes | that would probably be better to get started |
| 00:00.18 | tmzt | I don't think debian is up to date, although it has qualcomm_msm as a modem type |
| 00:00.34 | dcordes | that will work |
| 00:00.47 | dcordes | since the initial comitt, no msm changes have been done |
| 00:00.56 | tmzt | do you know how to use fso-cli |
| 00:00.59 | tmzt | cli-framework |
| 00:01.09 | dcordes | yea wait a minute |
| 00:01.45 | Dunedan | will try it parallel on a blackstone ;-) |
| 00:02.54 | dcordes | gsmcall.Initiate('+012345678','voice') |
| 00:03.23 | tmzt | how do you run frameworkd in foreground? |
| 00:05.09 | tmzt | DBusException: org.freesmartphone.Resource.NotEnabled: Resource Device is not enabled, current status is 'disabled' |
| 00:07.19 | dcordes | killall pythong |
| 00:07.24 | dcordes | frameworkd -s ogsmd |
| 00:07.27 | dcordes | python |
| 00:08.18 | dcordes | raise debuglevel in /etc/frameworkd.conf |
| 00:08.33 | dcordes | AT should be /dev/smd0 by default |
| 00:08.46 | *** join/#htc-linux konsta (n=asds@host81-151-152-241.range81-151.btcentralplus.com) |
| 00:18.55 | Dunedan | wah |
| 00:19.01 | Dunedan | works on Blackstone! |
| 00:23.00 | dcordes | Dunedan: no audio? |
| 00:23.07 | *** join/#htc-linux MethoS- (n=lem@dyndsl-085-016-162-247.ewe-ip-backbone.de) |
| 00:23.27 | Dunedan | well, alsa is unable to find audio stuff, so it might be impossible to get audio with the current setup |
| 00:30.59 | dcordes | there are no such drivers |
| 00:31.40 | Dunedan | So how should audio possible without drivers? |
| 00:32.27 | dcordes | it's all arm9 |
| 00:32.51 | dcordes | tmzt: does that work? |
| 00:33.46 | Dunedan | currently I would be satisfied with two things: a) working current kernel sources b) working X |
| 00:33.59 | dcordes | I just read your forum thread |
| 00:34.13 | cr2 | dcordes: there are some at@ for switching gsm audio. and an at@ for fm radio. |
| 00:34.30 | dcordes | did you write it down somewhere? |
| 00:34.38 | tmzt | dcordes: somewhat, I got a +COLP message back and it crashed with unexpected unsolicited message |
| 00:35.17 | tmzt | that and I am connected through ppp right now, I need to trace AT commands in ce to see how it switches between them |
| 00:35.36 | dcordes | tmzt: messages about unexpected unsolicited are normal because the support is very basic. I receive those on the kaiser but they don't crash anything |
| 00:36.14 | dcordes | probably the AT traffic crashed your arm9 in the same way as data did before? |
| 00:36.27 | tmzt | no, it didn't crash arm9 |
| 00:36.34 | dcordes | what did it do? |
| 00:36.36 | tmzt | data still is |
| 00:36.40 | dcordes | ok |
| 00:36.46 | tmzt | just the exceptions and the kept coming |
| 00:36.53 | Marajin_ | wow.. pdamill rag on HTCs being slow heh |
| 00:38.07 | tmzt | s/the/they |
| 00:38.23 | *** join/#htc-linux MethoS-- (n=lem@host-091-096-208-078.ewe-ip-backbone.de) |
| 00:38.32 | dcordes | cr2: these audio switching AT messages are not used for non A amss |
| 00:40.28 | tmzt | what's the registry entry for AT logging? |
| 00:43.02 | dcordes | HKEY_LOCAL_MACHINE\Software\HTC\ATDbgLog |
| 00:43.08 | tcccp | IEEEKS |
| 00:43.26 | tcccp | would you please mind not to use reg keys without proper warning? |
| 00:43.33 | tcccp | is sick |
| 00:43.39 | dcordes | Dunedan: what's wrong with the kernel sources? |
| 00:44.18 | tmzt | huh? |
| 00:44.25 | Dunedan | dcordes: Well, as I wrote in the forum, a kernel compiled with the current sources will hang on boot of a blackstone. |
| 00:44.34 | tmzt | black* is broken I think |
| 00:44.39 | tmzt | won't build either |
| 00:44.57 | dcordes | it builds for me |
| 00:45.32 | Dunedan | dcordes: Sure, it builds fine, but it hangs on boot. |
| 00:45.39 | dcordes | Dunedan: that sounds like the clock changes in the commit you linked to broke it |
| 00:45.42 | Dunedan | dcordes: With the message I posted to the forum. |
| 00:46.06 | Dunedan | dcordes: yes. The error message also appears in the commit. ;-) |
| 00:46.07 | dcordes | maejrep: ping |
| 00:48.22 | Dunedan | And I'm unable to start X. Is there something I need to pay attention to? |
| 00:48.36 | tmzt | error message? |
| 00:48.46 | tmzt | and what image are you using |
| 00:48.49 | Dunedan | (EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument |
| 00:48.50 | Dunedan | (EE) FBDEV(0): mode initialization failed |
| 00:48.56 | Dunedan | I'm using pure Debian. ;-) |
| 00:49.01 | tmzt | yeah, same thing |
| 00:49.05 | tmzt | xserver-xorg? |
| 00:49.08 | Dunedan | yes |
| 00:49.22 | tmzt | we should noop that and return 0 |
| 00:50.06 | tmzt | dcordes: does fso Xfbdev work now? |
| 00:51.01 | dcordes | tmzt: on the kaiser only with the refresh thread enabled |
| 00:51.39 | tmzt | wait, I still didn't disable the *4 |
| 00:51.46 | tmzt | Dunedan: are you building kernels? |
| 00:51.58 | Dunedan | yes. Directly on the blackstone. :D |
| 00:52.01 | *** join/#htc-linux MethoS-- (n=lem@host-091-096-208-078.ewe-ip-backbone.de) |
| 00:52.10 | tmzt | cool |
| 00:52.16 | Dunedan | takes around 5 hours for a full debian package. |
| 00:52.29 | tmzt | kpkg? |
| 00:52.31 | dcordes | wow |
| 00:52.36 | Dunedan | tmzt: yes |
| 00:53.03 | dcordes | any chance they will extend the debian arm architectures? |
| 00:53.12 | tmzt | you don't need that to build a kernel, you can use codesourcery.com 2008q1 and just copy the modules |
| 00:53.16 | tmzt | to armv6? |
| 00:53.20 | dcordes | yea |
| 00:53.27 | tmzt | I don't know |
| 00:53.49 | tmzt | one project just overrides arm and now ubuntu is using cortex or something |
| 00:54.09 | tmzt | armel is armv5t which works ok on msm, armv6novfp would be better |
| 00:54.25 | tmzt | Dunedan: are you using armel? |
| 00:54.28 | Dunedan | sure |
| 00:54.47 | dcordes | a benchmark on the OE images vs debian armel would be interesting |
| 00:54.57 | Dunedan | tmzt: Have you tried anything network related with a non-root user on the blackstone? I only get an error when I want to do that. |
| 00:55.01 | tmzt | debian uses full glibc also |
| 00:55.15 | tmzt | disable the android net security in .config |
| 00:55.30 | tmzt | and I have raph500 |
| 00:55.30 | dcordes | need to use that for oe |
| 00:55.35 | Dunedan | yeah |
| 00:55.37 | Dunedan | nice. |
| 00:57.54 | dcordes | # CONFIG_ANDROID_PARANOID_NETWORK is not set |
| 00:58.26 | Dunedan | I just tried it, but that failed due to the problem that the kernel wasn't booting because of the clock problem. ;-) |
| 00:59.05 | tmzt | Dunedan: can you disable vyres = yres * 4 in drivers/video/msm/msm_fb or mach-msm/msm-fb.c ? |
| 00:59.09 | tmzt | and try X |
| 01:00.05 | Dunedan | tmzt: I just need to get kernel sources without the clock bug. Maybe an older revision. |
| 01:00.08 | Dunedan | Anyone familiar with git and can tell me how to switch to an older revision? |
| 01:00.10 | tmzt | fb_info->var.yres_virtual = msmfb->yres * 2; |
| 01:00.19 | tmzt | clockbug? |
| 01:00.30 | tmzt | git checkout ~2 I think is right |
| 01:00.54 | Dunedan | tmzt: http://forum.xda-developers.com/showpost.php?p=3464045&postcount=197 |
| 01:01.15 | dcordes | Dunedan: you could also revert arch/arm/mach-msm/clock-wince.c manually |
| 01:01.21 | tmzt | that's 565, that's what we're using now right? |
| 01:01.36 | tmzt | mode "480x640" geometry 480 640 480 1280 16 timings 0 0 0 0 0 0 0 rgba 5/11,6/5,5/0,0/0 |
| 01:01.40 | tmzt | endmode |
| 01:01.56 | tmzt | oh, that's just *2 |
| 01:03.28 | tmzt | that's not the right fix, Dunedan, but we probably need maejrep |
| 01:03.52 | tmzt | I don't even see idx = 20 |
| 01:11.29 | Dunedan | ok, I think I've the needed revision. |
| 01:12.13 | Dunedan | tmzt: Should I apply the change to msm-fb? |
| 01:15.19 | tmzt | yeah, do you see the line? |
| 01:17.39 | *** join/#htc-linux MethoS- (n=lem@dyndsl-085-016-164-097.ewe-ip-backbone.de) |
| 01:18.03 | dcordes | tmzt: only frameworkd crashed when the unsolicited messages appeared? |
| 01:18.35 | tmzt | yeah, it didn't crash though it just kept repeating exceptions |
| 01:19.02 | dcordes | so cli-framework still worked? |
| 01:20.32 | tmzt | yeah, but it's just a dbus client |
| 01:20.47 | tmzt | I need to try this when not connected to the internal |
| 01:20.51 | tmzt | internet |
| 01:21.24 | dcordes | I mean did frameworkd still process the commands when it kept repeating the messages? |
| 01:24.14 | tmzt | yeah |
| 01:24.23 | tmzt | I think so, I didn't log everything |
| 01:33.50 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 01:36.48 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-99-175.web.vodafone.de) |
| 01:38.15 | dcordes | tmzt: I use the following in /etc/frameworkd.conf for logging |
| 01:38.32 | dcordes | log_level = DEBUG |
| 01:38.32 | dcordes | log_to = file |
| 01:38.33 | dcordes | log_destination = /var/log/frameworkd |
| 01:38.52 | tmzt | cool |
| 01:43.30 | Dunedan | dcordes: Before I want to publish the instructions to install debian I want to do it once more from scratch, because my first attempt had some unbeautiful tweaks. And I wanted to reinstall from scratch as far as I have a working "built-on-debian kernel package". |
| 01:47.15 | Dunedan | /s/far/soon |
| 01:49.17 | *** join/#htc-linux TheiPirate (i=user@wireless-128-62-145-198.public.utexas.edu) |
| 01:49.28 | *** part/#htc-linux TheiPirate (i=user@wireless-128-62-145-198.public.utexas.edu) |
| 01:49.53 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 02:02.17 | dcordes | Dunedan: ok just think it would be nice to provide people with that in the forum/wiki |
| 02:02.45 | dcordes | good night |
| 02:11.49 | *** join/#htc-linux woodson (n=CDP@c-68-54-66-168.hsd1.fl.comcast.net) |
| 02:52.49 | tmzt | maejrep: |
| 02:52.52 | tmzt | [ 1.716956] microp-ksc: Registering MicroP-KEY driver |
| 02:52.52 | tmzt | [ 1.723243] microp-ksc: Initializing MicroP-KEY chip driver at addr: 0x67 |
| 02:52.52 | tmzt | [ 1.742744] microp-ksc: Initialized MicroP-KEY chip revision v0682 |
| 02:52.52 | tmzt | [ 1.754615] microp-klt: Registering MicroP-LED driver |
| 02:52.52 | tmzt | [ 1.760810] microp-klt: Initializing MicroP-LED chip driver at addr: 0x66 |
| 02:52.54 | tmzt | [ 1.774940] microp-klt: This hardware is not yet supported: 8182 |
| 02:52.57 | tmzt | [ 1.786628] microp-klt: probe of 0-0066 failed with error -524 |
| 02:52.59 | tmzt | [ 2.433417] microp-keypad: Initializing MicroP keypad driver |
| 02:53.02 | tmzt | [ 2.448981] input: microp-keypad as /class/input/input3 |
| 02:53.05 | tmzt | [ 2.556281] microp_keypad_probe done |
| 03:10.14 | *** join/#htc-linux power_usr (n=chatzill@EASTGATE-TWO-EIGHTY-EIGHT.MIT.EDU) |
| 03:23.48 | *** join/#htc-linux evildarknightPDA (n=zsirc@196.192.81.34) |
| 03:36.57 | *** join/#htc-linux woodson (n=CDP@c-68-54-66-168.hsd1.fl.comcast.net) |
| 03:42.21 | woodson | ok cmon gparted in that pclinuxos from here http://linuxgator.org/download/download.html can scan and repair partitions. http://www.linuxjournal.com/article/0193 this url has much more indepth stuff about superblocks and e2fschk util. If puppy has gparted then u can do it all in there, u can also probably download it for puppy but that second url can get all your partition recovery needs done |
| 03:43.55 | woodson | the second url i mean can do in any linux distro as its common for all linux distro's |
| 03:44.16 | woodson | i have done it b4 long ago and it worked, i am sure its better now |
| 03:44.28 | woodson | damnit sorry |
| 04:04.05 | *** part/#htc-linux woodson (n=CDP@c-68-54-66-168.hsd1.fl.comcast.net) |
| 04:07.11 | *** join/#htc-linux power_usr_ (n=chatzill@EASTGATE-TWO-EIGHTY-EIGHT.MIT.EDU) |
| 04:09.41 | *** join/#htc-linux mrmoku` (n=mrmoku@ppp-93-104-34-238.dynamic.mnet-online.de) |
| 04:22.19 | *** part/#htc-linux power_usr_ (n=chatzill@EASTGATE-TWO-EIGHTY-EIGHT.MIT.EDU) |
| 04:23.19 | *** join/#htc-linux pzztgotbagz (n=nonya@unaffiliated/pzztgotbagz) |
| 05:58.00 | *** join/#htc-linux TheiPirate (i=user@wireless-128-62-145-198.public.utexas.edu) |
| 06:11.30 | *** part/#htc-linux TheiPirate (i=user@wireless-128-62-145-198.public.utexas.edu) |
| 06:43.14 | *** join/#htc-linux WizRd (n=Brett@114-30-108-54.ip.adam.com.au) |
| 06:43.23 | *** join/#htc-linux DavidFreeman (n=david@c-67-188-42-40.hsd1.ca.comcast.net) |
| 07:21.17 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 07:23.24 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbf82ba.pool.einsundeins.de) |
| 07:46.29 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 08:04.41 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfd485.pool.einsundeins.de) |
| 08:14.51 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87dcb4.pool.einsundeins.de) |
| 08:34.28 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 08:37.00 | *** join/#htc-linux Student (n=Student@62.16.118.7) |
| 08:48.04 | maejrep | tmzt: want to add 8182 support into microp-klt.c and see if it works? you can test it by writing 1/0 to /sys/class/led/* nodes |
| 08:48.21 | maejrep | if it does we can add support for it |
| 08:51.50 | *** join/#htc-linux TheiPirate (n=Timbo@cpe-67-9-132-146.austin.res.rr.com) |
| 08:55.54 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 08:59.55 | maejrep | Dunedan: what you're seeing as a bug, is not a clock bug |
| 09:00.15 | maejrep | it's the result of not having full support for all clocks yet in the clock API |
| 09:00.22 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf9256.pool.einsundeins.de) |
| 09:00.40 | maejrep | it never had support for that clock before the commit, so returning a failure status is not a bug, but the correct behavior |
| 09:01.07 | maejrep | the real fix will be to find out how to support that clock, and add it to the API |
| 09:01.20 | maejrep | keeping in mind that the current clock API is a work in progress |
| 09:18.52 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 09:37.38 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbff34c.pool.einsundeins.de) |
| 09:39.53 | *** join/#htc-linux pH5 (n=ph5@p5485FA9D.dip.t-dialin.net) |
| 09:55.14 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf9f3a.pool.einsundeins.de) |
| 10:11.05 | *** join/#htc-linux fnord_ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
| 10:15.09 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 10:19.45 | Dunedan | maejrep: http://dpaste.com/14628/ <- that's a complete dmesg of a kernel build from revision a7bbc84bc783acc349b030a4621541eab84165e0. Maybe that helps you. |
| 10:27.08 | maejrep | Dunedan: not really.. what else is printed before the clock message when it hangs? |
| 10:27.33 | maejrep | also, did you try ignoring clk 20, to see if that helps any? |
| 10:27.55 | maejrep | I'm really thinking it is not the PCLK that hangs |
| 10:28.19 | maejrep | if it were, I would guess that raphael would be hanging too, since they both use the same sdcc code |
| 10:28.37 | Dunedan | Well, whether it is the PCLK or not, it's definitely caused by a change in your commit, because with the revision before it works fine. |
| 10:29.02 | Dunedan | and if you tell me how to ignore clk 20 I could try that |
| 10:35.24 | maejrep | in: static int pc_clk_enable(uint32_t id) |
| 10:35.27 | Dunedan | maejrep: The last messages printed before the kernel hangs are exactly the same as on a working kernel. Except, that there is also a line "pc_clk_enable: enabling a clock that doesn't have an ena bit or ns-only offset: 37", which didn't cause the kernel hanging. |
| 10:35.36 | maejrep | the new code is:+ printk(KERN_WARNING "%s: enabling a clock that doesn't have an ena bit " |
| 10:35.36 | maejrep | + "or ns-only offset: %u\n", __func__, id); |
| 10:35.36 | maejrep | + return -1; |
| 10:35.47 | maejrep | if you change the return -1 to return 0, it will be the same effect |
| 10:36.08 | maejrep | that doesn't help |
| 10:36.22 | maejrep | because in the "working kernel" it did not print that message |
| 10:36.29 | Dunedan | right |
| 10:36.34 | maejrep | therefore there's nothing to base it on in your "working" dmesg :) |
| 10:37.28 | maejrep | try it with the return 0 |
| 10:38.28 | maejrep | if that still doesn't work, it may be one of the ns_only values that is different for blackstone |
| 10:38.48 | Dunedan | all right |
| 10:39.47 | maejrep | do you have the spl dumped for blackstone? |
| 10:40.11 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 10:40.41 | Dunedan | nope. I'm pretty new to this whole stuff. Give me a hint how and I can do it. |
| 10:41.25 | Dunedan | btw: with a working kernel I'll get the following message later during boot: "Cannot access the Hardware Clock via any known method." |
| 10:41.33 | maejrep | in haret: pwf spl 0 0x100000 |
| 10:42.00 | maejrep | I don't see that in your dmesg |
| 10:42.35 | Dunedan | it's printed later, after init. |
| 10:42.45 | maejrep | if it comes after the last line in your dmesg, then it's after the kernel has finished booting, and would be unrelated to the kernel |
| 10:42.58 | Dunedan | yes |
| 10:45.13 | maejrep | were you able to compile with the return 0? |
| 10:46.10 | Dunedan | I'll be able to tell you that in ~5 hours. |
| 10:46.29 | Dunedan | I do the compiling directly on the blackstone, so it takes it's time. |
| 10:47.29 | maejrep | if you've already compiled once, subsequent recompiles should be a fraction of the time |
| 10:47.45 | maejrep | why can't you compile on a different machine? |
| 10:48.20 | maejrep | you're not starting from a clean checkout for each compile, are you? |
| 10:48.42 | *** join/#htc-linux MethoS- (n=lem@host-091-097-243-148.ewe-ip-backbone.de) |
| 10:50.02 | Dunedan | I do, but mainly because I don't know how to do it better. Well, maybe I'll have the time to setup a crossbuild environment later, but currently I don't have it. |
| 10:50.04 | *** join/#htc-linux Pure4Real (n=pure4rea@89-97-140-219.ip17.fastwebnet.it) |
| 10:50.58 | maejrep | well, i mean is the source directory left as it was after your last compile, or are changes lost? |
| 10:51.43 | maejrep | cause the first compile, which takes 5 hours for you, should leave a majority of the kernel already-compiled, and only recompile the parts that changed (clock-wince.c), which should only take like a couple minutes at the most :x |
| 10:52.15 | Dunedan | I usually build a complete debian package using make-kpkg from scratch. |
| 10:52.39 | maejrep | :| |
| 10:52.56 | maejrep | but the kernel source? |
| 10:53.08 | maejrep | is it left intact from your last compile? |
| 10:53.36 | Dunedan | without cleaning it would have been ;-) |
| 10:53.41 | maejrep | D: |
| 10:54.06 | maejrep | well, that's a good tip, if you didn't already know ;) |
| 10:54.44 | maejrep | also setting up a crossbuild environment is very easy, i think |
| 10:54.57 | maejrep | you could probably get that working long before the phone finishes compiling it |
| 10:55.08 | Dunedan | Well, that's currently a very tranistional setup. It's target has been to be able to build blackstone kernels at all. So I'll change that in future. |
| 10:55.14 | maejrep | these processors aren't exactly built for compiling the linux kernel ;) |
| 10:56.30 | maejrep | http://wiki.xda-developers.com/index.php?pagename=BuildTheRaphaelKernel |
| 10:56.46 | maejrep | the toolchain is really all you need, once you have the sources |
| 10:58.06 | *** join/#htc-linux MethoS-- (n=lem@dyndsl-085-016-164-141.ewe-ip-backbone.de) |
| 10:58.08 | Dunedan | I don't want pure kernel images. I want complete debian packages. So a crossbuild setup would maybe look completely different for me. |
| 10:58.47 | maejrep | I dont know what you mean by 'complete debian packages'... if you have it booting now, all you have to do is compile the kernel, replace the zImage, and boot again |
| 10:58.54 | maejrep | nothing else has to change |
| 10:59.41 | Dunedan | dumb question but where in haret should I execute the command for getting the spl? |
| 10:59.49 | maejrep | the same zImage will be used whether you're booting with busybox, debian, android, angstrom, gentoo, or whatever else you want... |
| 11:00.22 | maejrep | have you ever connected to haret console? |
| 11:00.26 | Dunedan | nope |
| 11:00.34 | maejrep | windows or linux? |
| 11:00.39 | Dunedan | linux |
| 11:01.25 | maejrep | http://www.handhelds.org/~koconnor/haret/haretconsole-0.5.2.tar.gz |
| 11:01.43 | maejrep | do you get an IP on your linux machine when connected via usb to the phone? |
| 11:04.27 | Dunedan | with win mobile on the phone? |
| 11:04.32 | maejrep | yeah |
| 11:04.49 | maejrep | if you don't want to go through setting up haretconsole (which requires rndis or wifi), you can also put the command into a startup.txt file in the same directory as haret.exe, run it, and the file will be placed in the same directory (called "spl") |
| 11:05.10 | Dunedan | that sounds good for now |
| 11:14.01 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
| 11:16.19 | Dunedan | maejrep: http://www.phoenitydawn.de/temp/blackstone-spl |
| 11:22.52 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 11:27.08 | Dunedan | oh. the rdnis network stuff works right out of the box with dhcp from my linux box. nice. |
| 11:28.56 | maejrep | that means you have a recent kernel |
| 11:29.10 | maejrep | they've fixed the rndis support in recent kernels |
| 11:29.14 | Dunedan | 2.6.26 |
| 11:30.14 | maejrep | i'll work on analyzing that spl |
| 11:30.19 | maejrep | let me know how the return 0 goes |
| 11:30.52 | Dunedan | sure |
| 11:35.40 | *** join/#htc-linux MethoS- (n=lem@dyndsl-085-016-163-036.ewe-ip-backbone.de) |
| 11:45.05 | *** join/#htc-linux BabelO (n=BabelO@lun34-2-82-238-28-28.fbx.proxad.net) |
| 11:55.05 | *** join/#htc-linux MethoS-- (n=lem@host-091-097-242-083.ewe-ip-backbone.de) |
| 12:20.02 | maejrep | how long has RaphaelMemoryMap been broken? |
| 12:35.52 | *** join/#htc-linux Student (n=Student@62.16.118.7) |
| 12:47.00 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfef8a.pool.einsundeins.de) |
| 12:52.07 | *** join/#htc-linux nota (n=not@net-93-65-10-119.cust.dsl.vodafone.it) |
| 12:52.12 | nota | hi |
| 12:52.20 | nota | anybody with haret on h5500 ? |
| 12:55.04 | *** join/#htc-linux ClashTheBunny (i=60ed211a@gateway/web/ajax/mibbit.com/x-ad565f71bd7aad23) |
| 13:04.53 | *** join/#htc-linux hechu (n=hechu@119.131.151.211) |
| 13:18.21 | *** join/#htc-linux timebomb (n=tb@c174056.adsl.hansenet.de) |
| 13:35.02 | *** join/#htc-linux power_usr (n=chatzill@EASTGATE-TWO-EIGHTY-EIGHT.MIT.EDU) |
| 13:37.49 | nota | anybody with haret on h5500 ? |
| 13:45.36 | *** join/#htc-linux MethoS- (n=lem@host-091-097-242-083.ewe-ip-backbone.de) |
| 13:48.59 | *** join/#htc-linux NetRipper (n=netrippe@netripper.nl) |
| 13:56.53 | Marajin_ | morning people |
| 13:56.58 | Marajin_ | well, afternoon actually but ssssh :p |
| 14:10.23 | *** join/#htc-linux zycho (n=zycho@a89-183-78-209.net-htp.de) |
| 14:11.07 | nota | hi |
| 14:11.23 | nota | i have a terrible issue with haret on h5500 |
| 14:13.03 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 14:13.38 | Marajin | and what is that? |
| 14:14.57 | nota | it freezes when i tries to load a kernel |
| 14:15.12 | nota | there was a post on 2008 about that |
| 14:15.19 | nota | but no new news from then |
| 14:16.33 | Marajin | freezes where exactly though? at the end of the loading bar? |
| 14:18.36 | nota | no at the kumping |
| 14:18.40 | nota | jumping |
| 14:20.21 | nota | <PROTECTED> |
| 14:20.21 | nota | http://www.mail-archive.com/haret@handhelds.org/msg00770.html |
| 14:34.54 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-69-214.web.vodafone.de) |
| 14:38.41 | *** join/#htc-linux MethoS- (n=lem@host-091-097-242-083.ewe-ip-backbone.de) |
| 14:46.03 | *** part/#htc-linux power_usr (n=chatzill@EASTGATE-TWO-EIGHTY-EIGHT.MIT.EDU) |
| 14:50.19 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 14:53.48 | *** join/#htc-linux MethoS-- (n=lem@host-091-097-240-229.ewe-ip-backbone.de) |
| 15:00.05 | *** join/#htc-linux Balsat (n=balsat@87.72.13.34) |
| 15:07.26 | *** join/#htc-linux he_chu (n=hechu@61.140.162.153) |
| 15:09.33 | *** join/#htc-linux evildarknight (n=dsl@41.207.132.146) |
| 15:14.06 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 15:17.14 | *** join/#htc-linux power_usr (n=chatzill@BACARDI.MIT.EDU) |
| 15:31.10 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
| 15:34.51 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbfef8a.pool.einsundeins.de) |
| 15:35.11 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 15:35.31 | dcordes | BabelO: http://vimeo.com/2009612 |
| 15:35.57 | Untouchab1e | hi all |
| 15:35.57 | dcordes | it could be your t-rex |
| 15:36.00 | dcordes | hi |
| 15:36.02 | *** join/#htc-linux Balsat_ (n=balsat@87.72.13.87) |
| 15:36.27 | Untouchab1e | how's it going dcordes? |
| 15:48.07 | dcordes | Untouchab1e: all good you? |
| 15:56.57 | *** join/#htc-linux nr_irclog (n=nr_irclo@netripper.com) |
| 15:59.28 | *** join/#htc-linux nrirclog (n=nr_irclo@netripper.com) |
| 16:06.25 | *** join/#htc-linux nrirclog (n=nrirclog@netripper.com) |
| 16:07.05 | NetRipper | test |
| 16:08.11 | Untouchab1e | hi |
| 16:08.14 | Untouchab1e | NetRipper |
| 16:08.22 | Untouchab1e | how are you? :) Long time no see |
| 16:08.27 | NetRipper | hi |
| 16:08.34 | NetRipper | im alright |
| 16:08.56 | Untouchab1e | what you up to? |
| 16:09.43 | NetRipper | i just setup the replacement for clement's irc log bot |
| 16:09.49 | Untouchab1e | heh, cool |
| 16:10.01 | NetRipper | http://irclog.netripper.com/ |
| 16:10.09 | NetRipper | the old one is going offline |
| 16:10.16 | Untouchab1e | aha |
| 16:16.17 | *** join/#htc-linux sroecker (n=sroecker@BAH487c.bah.pppool.de) |
| 16:19.49 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfe6d0.pool.einsundeins.de) |
| 16:21.01 | NetRipper | :) |
| 16:23.10 | power_usr | that's great how it is real time |
| 16:29.58 | NetRipper | yea im loving it too.. it was already at http://irclog.iclem.net/ but the current owner was shutting it down.. so he helped me move it to my server |
| 16:30.50 | NetRipper | it'd be nice if the topic could be changed but been asking around for someone that can every now and then, but nobody stepped up yet ;) |
| 16:33.58 | Marajin | nobody knows who has the permissions I guess? |
| 16:34.30 | NetRipper | well, i dont |
| 16:34.30 | NetRipper | :) |
| 16:41.22 | Dunedan | maejrep: I've good and I've bad news: The bad: It doesn't work whether I use return 0 or return -1 when I compile the kernel on the blackstone itself. The good news: It work with both when I compile the kernel on my desktop pc using the crossbuild toolchain. |
| 16:47.46 | *** join/#htc-linux woodson (n=CDP@c-68-54-66-168.hsd1.fl.comcast.net) |
| 16:47.55 | *** part/#htc-linux woodson (n=CDP@c-68-54-66-168.hsd1.fl.comcast.net) |
| 16:50.24 | NetRipper | lol you compile your kernel on your phone? |
| 16:50.57 | nota | i compile everything on my ipaq :P |
| 16:55.03 | Dunedan | NetRipper: well, why not? ;-) |
| 16:56.14 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 16:59.11 | NetRipper | it's slow? :p |
| 17:00.58 | Dunedan | pure kernel compiling around 3 1/2 hours. building complete debian packages around 5 hours. And until now I haven't found a way to do the latter one on my desktop pc. crossbuilding kernel works, but crossbuilding whole debian packages not. |
| 17:06.33 | nota | gentoo on ipaq 3600, here |
| 17:06.44 | nota | a 2.6.19 kernel is compiled in 5h |
| 17:06.55 | nota | sa1100 cpu, 64Mb ram |
| 17:07.35 | nota | gentoo stage3 .... well 2 weeks |
| 17:09.21 | pH5 | wow. and I kept complaining about having to cross-build on a 2GHz P4 |
| 17:11.08 | nota | :P |
| 17:21.54 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
| 17:26.15 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf8921.pool.einsundeins.de) |
| 17:36.48 | dcordes | Dunedan: probably the gcc version your debian uses is outdated |
| 17:39.27 | dcordes | NetRipper: thanks for serving the livelog |
| 17:39.55 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 17:43.23 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbf8952.pool.einsundeins.de) |
| 17:50.47 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbfc839.pool.einsundeins.de) |
| 18:07.16 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfca7e.pool.einsundeins.de) |
| 18:21.00 | Marajin | hmm, what's with people keep saying things like 'flash OEM roms and then reflash to new custom rom' on xda-devs for the kaiser? |
| 18:26.45 | *** join/#htc-linux noodlesgc (n=noodles@97.72.68.195) |
| 18:46.12 | Dunedan | dcordes: well, it's gcc 4.3.3, so I assume that's not the reason. ;-) |
| 19:18.04 | *** join/#htc-linux Kensan_ (n=ken@gw.ptr-80-238-227-222.customer.ch.netstream.com) |
| 19:18.17 | *** join/#htc-linux MethoS- (n=lem@dyndsl-085-016-163-168.ewe-ip-backbone.de) |
| 19:20.44 | NetRipper | dcordes, nps :) |
| 19:28.07 | lupine_85 | notes a complete lack of any half-decent community for nokias |
| 19:46.21 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 19:48.24 | *** join/#htc-linux xutywx (n=pawel@195.205.38.92) |
| 19:55.19 | *** join/#htc-linux AstainHasPS3 (n=AstainHe@unaffiliated/astainhellbring) |
| 20:00.53 | power_usr | Hi AstainHasPS3 |
| 20:01.03 | power_usr | Any interesting RAPH800 news? |
| 20:02.13 | AstainHasPS3 | Nothing I seen |
| 20:02.28 | power_usr | ok |
| 20:03.14 | *** join/#htc-linux exco1 (n=exco@e181067075.adsl.alicedsl.de) |
| 20:09.09 | *** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 20:18.55 | *** join/#htc-linux MethoS-- (n=lem@host-091-096-208-020.ewe-ip-backbone.de) |
| 20:20.38 | Balsat_ | power_usr : the colors should be ok now |
| 20:20.47 | power_usr | Yup |
| 20:21.06 | power_usr | Balsat_: On Friday Astain sent me a new build with fixed colors |
| 20:21.10 | power_usr | it is working very well |
| 20:21.31 | power_usr | the SMS needed to be disabled though, as SMS on RAPH800 isn't working with Android right now. |
| 20:22.00 | Balsat_ | trouble with smd0 ? |
| 20:22.23 | *** join/#htc-linux swc|666 (n=carramro@unaffiliated/swc666/x-4934821) |
| 20:24.22 | power_usr | Balsat_: smd_7500 had to NOT be included in the kernel |
| 20:25.24 | *** join/#htc-linux ClashTheBunny (i=60ed211a@gateway/web/ajax/mibbit.com/x-5c1a803e8be7315f) |
| 20:25.27 | power_usr | Near the bottom of here is the discussion: http://apt.rikers.org/%23htc-linux/20090313.html.gz |
| 20:41.19 | *** join/#htc-linux xutywx (n=pawel@195.205.38.92) |
| 20:51.30 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 20:51.55 | *** join/#htc-linux TheiPirate (i=user@w-mob400-128-62-217-182.public.utexas.edu) |
| 20:59.59 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf863f.pool.einsundeins.de) |
| 21:08.47 | *** join/#htc-linux pzztgotbagz (n=nonya@unaffiliated/pzztgotbagz) |
| 21:11.15 | *** part/#htc-linux TheiPirate (i=user@w-mob400-128-62-217-182.public.utexas.edu) |
| 21:12.46 | *** join/#htc-linux power_usr_ (n=chatzill@18.107.7.151) |
| 21:26.04 | *** join/#htc-linux timebomb (n=tb@d040051.adsl.hansenet.de) |
| 21:26.36 | *** join/#htc-linux power_usr__ (n=chatzill@18.62.30.67) |
| 21:31.43 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-69-214.web.vodafone.de) |
| 21:48.32 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfc7e2.pool.einsundeins.de) |
| 22:03.13 | *** join/#htc-linux swc|666 (n=carramro@unaffiliated/swc666/x-4934821) |
| 22:05.49 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf8b34.pool.einsundeins.de) |
| 22:08.22 | *** join/#htc-linux noodlesgc (n=noodles@97.72.68.195) |
| 22:15.07 | *** join/#htc-linux captnoord (i=5147a47b@gateway/web/ajax/mibbit.com/x-a2e41c3463c40fec) |
| 22:20.09 | *** join/#htc-linux Pure4Real (n=pure4rea@89-97-140-219.ip17.fastwebnet.it) |
| 22:23.17 | *** join/#htc-linux captnoord (i=5147a47b@gateway/web/ajax/mibbit.com/x-41f18da49650cbff) |
| 22:37.05 | maejrep | Dunedan: the good news is greats :) the bad news is misleading for everyone else and shouldn't be called bad news :P |
| 22:37.10 | maejrep | *great |
| 22:37.31 | Dunedan | hehe |
| 22:38.10 | cr2 | hi maejrep |
| 22:38.18 | maejrep | hi! |
| 22:38.22 | maejrep | long time no see :p |
| 22:38.25 | tmzt | hello |
| 22:38.49 | maejrep | tmzt: i hear you've been making progress on ppp :o |
| 22:39.02 | tmzt | yeah some |
| 22:39.16 | cr2 | maejrep: i've looked at the blac100 dmesg and have some questions |
| 22:39.17 | maejrep | so, its smd1, and you have to disable diag, then it works? |
| 22:39.25 | tmzt | yes |
| 22:39.31 | tmzt | but unstable |
| 22:39.36 | maejrep | great |
| 22:40.08 | tmzt | I think we need diag on smd1 for android though |
| 22:40.18 | cr2 | tmzt: what is diag ? |
| 22:40.24 | tmzt | or at least it crashes after logo |
| 22:40.30 | tmzt | qualcomm diag |
| 22:40.32 | cr2 | maejrep: this one |
| 22:40.35 | cr2 | [ 0.887401] clk_set_rate 7:19200000 |
| 22:40.37 | cr2 | [ 0.887431] unknown clock! |
| 22:40.45 | cr2 | tmzt: why does androis need it ? |
| 22:40.55 | cr2 | maejrep: what does it mean ? |
| 22:41.10 | maejrep | it means we don't know how to set the rate for that clock |
| 22:41.16 | tmzt | I don't know |
| 22:41.35 | tmzt | if smd1 is not openable android works |
| 22:41.45 | maejrep | ah, no |
| 22:41.54 | tmzt | but if it is it expects dm protocol to work |
| 22:41.56 | cr2 | maejrep: which clock ? |
| 22:41.57 | tmzt | well |
| 22:41.59 | maejrep | cr2: that message is printed in pc_clk_get_rate() |
| 22:42.17 | maejrep | and that only works for sdc*_clk and sdc*_pclk (hard-coded) |
| 22:42.31 | maejrep | #define GP_CLK 7 /* General purpose clock */ |
| 22:42.35 | cr2 | maejrep: should we create some "shadow cache" for the clock settings ? |
| 22:42.57 | cr2 | ok, maybe a more verbose dmesg will be better. |
| 22:43.00 | maejrep | meaning what? |
| 22:43.17 | cr2 | how do you find out the actual clock setting ? |
| 22:43.33 | cr2 | imho, you are not supposed to read from the md/ns |
| 22:44.16 | cr2 | so i'd propose to set the values at boot, and store them in a shadow cache |
| 22:44.45 | maejrep | the values remain the same after writing them in linux |
| 22:44.46 | cr2 | "not supposed" means that it's extremely difficult to interpret these values |
| 22:44.52 | maejrep | I don't know why they change in windows |
| 22:45.01 | cr2 | don't see that in wince. |
| 22:45.21 | cr2 | [ 1.398814] sdhci: Copyright(c) Pierre Ossman |
| 22:45.31 | cr2 | this one is not needed ? |
| 22:45.38 | maejrep | never seen that |
| 22:45.48 | tmzt | for sdcc? |
| 22:46.09 | cr2 | yes, in the posted blac100 dmesg |
| 22:46.37 | maejrep | i think he compiled his own kernel .. might have included support that isnt needed? |
| 22:46.57 | cr2 | maybe |
| 22:47.04 | maejrep | or maybe that's needed for SDHC support? |
| 22:47.05 | cr2 | is it in the defconfig ? |
| 22:47.23 | maejrep | could be, I haven't looked at blac defconfig |
| 22:47.30 | cr2 | i think sdhci is some TI pci spec. or m$ |
| 22:47.45 | tmzt | I have a different klt version on raph500 |
| 22:47.45 | cr2 | i don't understand this message too: |
| 22:47.49 | cr2 | [ 1.022380] msm_serial: detected port #0 |
| 22:47.51 | cr2 | [ 1.022716] msm_serial: probe of msm_serial.0 failed with error -2 |
| 22:48.03 | cr2 | tmzt: check the i2c traces, if you use different comamnds |
| 22:48.24 | tmzt | but with supported=1 leds work |
| 22:48.43 | cr2 | maejrep: port #0 is serial debug console, but i still don't get it why the probe fails |
| 22:48.59 | cr2 | maejrep: we will need the uart2 for bt, or course |
| 22:49.26 | maejrep | I think it's because NetRipper removed the msm_serial_console device from board file |
| 22:49.45 | maejrep | because it was the reason usb-ether made it create usb0 and usb1, when only usb1 was usable |
| 22:49.53 | maejrep | tmzt: so it works if you force support for it? |
| 22:49.58 | tmzt | yes |
| 22:50.07 | maejrep | in that case, we can add v8182 support to the chip driver |
| 22:50.22 | tmzt | right |
| 22:52.59 | tmzt | I was looking at this because no2chem said it was neccesary to switch a gpio and use i2c to control keylight |
| 22:53.29 | tmzt | I have a gpio-led registered for that gpio but it doesn't work |
| 22:54.07 | tmzt | I still need to see if setting it to 0 turns off keylight when klt says it should be off |
| 22:54.34 | tmzt | 0x56 I think |
| 22:54.57 | tmzt | should be on, not off |
| 22:55.02 | captnoord | yup |
| 22:55.04 | captnoord | pull down |
| 22:55.07 | captnoord | could be |
| 22:55.07 | captnoord | :P |
| 22:55.28 | captnoord | related to sink and source stuff |
| 22:55.57 | captnoord | is beeing rude as always |
| 22:57.57 | maejrep | hmm, keypad backlight works for me .. it's done automatically by j0b0's patch I think, when you open the clamshell |
| 22:58.16 | tmzt | it works with klt |
| 22:58.18 | maejrep | and it is gpio, not i2c from what I can tell |
| 22:58.48 | tmzt | with your driver |
| 22:59.02 | maejrep | i think so |
| 22:59.12 | maejrep | (j0b0 made changes to the driver, for that) |
| 22:59.27 | tmzt | how do I find the head tail for ppp to see why its crashing |
| 22:59.31 | maejrep | klt::keypad-backlight |
| 22:59.53 | tmzt | either freezing the device so it won't respond on usb at all |
| 22:59.53 | maejrep | tmzt: :/ it doesn't get reported in the /sys smd files iirc |
| 23:00.06 | tmzt | (lsusb hangs) |
| 23:00.22 | tmzt | or panic |
| 23:00.46 | maejrep | i've had lsusb hang like that, and it's because the usb subsys goes into uninterruptible sleep (check ps | grep 'D') |
| 23:01.17 | maejrep | seems more like a host problem than the device |
| 23:01.27 | maejrep | the only way i could fix that was by rebooting the pc |
| 23:01.47 | *** join/#htc-linux noodlesgc (n=noodles@97.72.68.195) |
| 23:01.59 | tmzt | I can just unplug the device and it returns |
| 23:02.08 | tmzt | from lsusb |
| 23:02.17 | maejrep | hmm |
| 23:02.22 | tmzt | I know its ppp traffic though |
| 23:02.44 | cr2 | maejrep: serial was not the reason for usb0/usb1 confusion. adb was |
| 23:03.03 | tmzt | I can have ssh open here but if I start apt-get update at the same time it either panics or freezes |
| 23:03.11 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfd332.pool.einsundeins.de) |
| 23:03.25 | maejrep | :/ |
| 23:03.56 | tmzt | could it be related to internal ram being a different size? |
| 23:04.18 | maejrep | if you're going into an unreadable part of ram, potentially |
| 23:04.45 | maejrep | how does a 'dump mmu' compare to a raph800? |
| 23:04.49 | tmzt | how big should the buffers be now? |
| 23:05.02 | maejrep | for smd1? 0x282 and 0xd82 |
| 23:05.05 | tmzt | let's see if I can get pan |
| 23:05.44 | cr2 | tmzt: the people do some very strange allocations without understandng what's going on. |
| 23:06.42 | tmzt | the people? |
| 23:06.59 | cr2 | tmzt: other people |
| 23:08.06 | tmzt | htc? |
| 23:09.27 | cr2 | no, those who are porting to other msm devices |
| 23:09.29 | tmzt | maejrep hardcoded smd1 in the smd-7500 driver |
| 23:09.48 | cr2 | well, he does not have a better choice |
| 23:09.57 | maejrep | :/ |
| 23:09.57 | cr2 | on 7201A we can do better |
| 23:10.00 | tmzt | maejrep: is it stable on raph800? |
| 23:10.10 | maejrep | tmzt: I haven't had a chance to try it |
| 23:10.12 | tmzt | I know |
| 23:10.18 | cr2 | but i'd like to know the purpose of DIAG, and DATAn |
| 23:10.45 | maejrep | cr2: apparently our DATA1 channel is the same chosen for DIAG on 7201a |
| 23:11.04 | tmzt | do we have diag? |
| 23:11.15 | maejrep | I guess we could change cid1 to cid7, if we want it to match 7201a |
| 23:11.33 | cr2 | maejrep: ? NetRipper said he mostly got the data connection on DATA1 ? |
| 23:11.39 | maejrep | tmzt: it's looking like no, but I don't know what the diag buffer would contain, to be able to find it |
| 23:11.57 | tmzt | we need to ask viperbjk |
| 23:12.00 | cr2 | maejrep: it may be a good idea |
| 23:12.01 | maejrep | cr2: probably, but that's because 7201a has it in smd toc |
| 23:12.01 | cr2 | maejrep: so you don't have DATAn ? |
| 23:12.07 | tmzt | but it should be 0x7e |
| 23:12.11 | maejrep | I have DATA_CTLx I think |
| 23:12.15 | tmzt | encapsulated |
| 23:12.25 | maejrep | 0x7e ? |
| 23:12.32 | NetRipper | cr2, it was DATA7, we don't have a DATA1 |
| 23:12.36 | cr2 | maejrep: but not in the toc ? |
| 23:12.54 | maejrep | yes, it's in toc |
| 23:13.11 | cr2 | NetRipper: ? |
| 23:13.29 | maejrep | hmm, no |
| 23:13.43 | maejrep | [ 6.054367] smd_alloc_channel() 'SMD_RPCCALL' cid=2, shared=e0110148 |
| 23:13.43 | maejrep | [ 8.710983] smd_alloc_channel() 'SMD_CONTROL' cid=5, shared=e010c120 |
| 23:13.43 | maejrep | [ 8.872147] smd_alloc_channel() 'SMD_DATA5' cid=11, shared=e0118198 |
| 23:13.43 | maejrep | [ 8.952652] smd_alloc_channel() 'SMD_DATA6' cid=12, shared=e011c1c0 |
| 23:13.43 | maejrep | [ 9.033188] smd_alloc_channel() 'SMD_DATA7' cid=13, shared=e01201e8 |
| 23:13.44 | tmzt | data1 is cid7 on 7201a? |
| 23:13.44 | maejrep | [ 9.434830] smd_alloc_channel() 'SMD_CS_A2M' cid=33, shared=e0114170 |
| 23:13.56 | maejrep | yes tmzt |
| 23:13.58 | NetRipper | tmzt, you could say it like that |
| 23:14.07 | cr2 | CONTROL |
| 23:14.08 | cr2 | DATA1 |
| 23:14.10 | cr2 | DATA2 |
| 23:14.12 | cr2 | DATA3 |
| 23:14.13 | cr2 | DATA9 |
| 23:14.14 | cr2 | DATA11 |
| 23:14.16 | cr2 | GPSNMEA |
| 23:14.23 | cr2 | and RPCCALL at the top |
| 23:14.26 | maejrep | none of them match :p except CONTROL and RPCCALL |
| 23:14.32 | cr2 | hehe |
| 23:14.34 | NetRipper | [ 4.608972] smd_alloc_channel() 'SMD_DATA1' cid=7, shared=e0120238 |
| 23:14.38 | NetRipper | DATA1 = cid=7 |
| 23:14.43 | tmzt | what's CONTROL? |
| 23:15.05 | maejrep | dunno, it doesn't appear to be DATA_CTL, which is what android smd_qmi looks for |
| 23:16.20 | cr2 | NetRipper: yes, that's what ive put into wiki |
| 23:16.32 | maejrep | 0000c120 02 00 00 00 01 01 01 00 00 00 00 00 00 00 00 00 |................| |
| 23:16.47 | maejrep | dunno if that means anything (CONTROL buffer) |
| 23:17.46 | maejrep | all those other buffers (cid=11,12,13,33) appear to be all 0s |
| 23:19.35 | maejrep | all: did you see my comment a week or so ago about creating htc_hw.o? creates /sys nodes similar to vogue_hw, for things like exposing mtype (and gsm vs cdma) to userland |
| 23:20.05 | maejrep | also creates a vib node, which doesn't exist otherwise |
| 23:21.50 | tmzt | can we use the new support in android upstream for this or are we going to have a name collision? |
| 23:22.17 | tmzt | meaning as magic and g2 were added a lot of stuff is renamed htc* |
| 23:24.27 | tmzt | how do I setup a pan connection on this thing?? |
| 23:24.52 | maejrep | I haven't seen upstream changes |
| 23:25.56 | cr2 | tmzt: pan as in bt ? |
| 23:27.41 | tmzt | yes |
| 23:27.57 | tmzt | it doesn't show up in services |
| 23:28.06 | tmzt | maejrep: git log |
| 23:28.11 | *** join/#htc-linux power_usr (n=chatzill@EASTGATE-FOUR-TWENTY-SEVEN.MIT.EDU) |
| 23:29.56 | cr2 | tmzt: we need uart2 first |
| 23:29.59 | cr2 | and uart2dm |
| 23:32.02 | tmzt | I mean in ppc |
| 23:32.08 | tmzt | for haret |
| 23:33.36 | iratsu | how well does android run on the htc TyTN II? |
| 23:34.27 | maejrep | http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/msm_vibrator.c;h=d9a60d98331b7c32b6c99689c37742ca3e999526;hb=cf8cc2d0d566c5198d7e0b81ab985c9d07e15716 heh |
| 23:35.26 | cr2 | maejrep: yeah. we need some way to trace rpc |
| 23:35.38 | cr2 | iratsu: ask dcordes |
| 23:35.43 | maejrep | yes, though I was more referring to that they finally have a vibrator driver :p |
| 23:35.50 | maejrep | 39ea4b28a6f9c45bdc7d8666b5b37e501b029191 looks interesting too |
| 23:35.56 | maejrep | looks like it fixes an i2c bug |
| 23:43.55 | *** join/#htc-linux AstainHasPS3 (n=AstainHe@unaffiliated/astainhellbring) |
| 23:44.24 | maejrep | http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=e5846b61ba9ed3bcce1deac34112aff98a6f950e :| |
| 23:48.24 | cr2 | maejrep: how old is this driver ? i'm missed it somehow |
| 23:48.38 | maejrep | it used to be trout_h2w |
| 23:48.47 | maejrep | and exists in our branch as that |
| 23:49.11 | maejrep | this is a new "generic" version of it, written by HTC |
| 23:49.38 | maejrep | generic as in it supports the other new android devices as well |
| 23:49.56 | cr2 | hi->init_cpld(); |
| 23:50.02 | cr2 | does not look very generic |
| 23:51.46 | cr2 | <PROTECTED> |
| 23:52.21 | maejrep | <maejrep> generic as in it supports the other new android devices as well |
| 23:52.22 | maejrep | ^ |
| 23:52.40 | tmzt | what driver is this? |
| 23:52.50 | maejrep | h2w |
| 23:53.01 | cr2 | ok. |
| 23:53.07 | tmzt | what do we need that for? |
| 23:53.09 | cr2 | that's why android sucks. |
| 23:53.17 | maejrep | plugging in headset, etc |
| 23:53.27 | maejrep | h2w is designed to detect what type of device is plugged in |
| 23:53.30 | tmzt | yeah, ok |
| 23:53.34 | cr2 | what vreg is that ? hi->vreg_h2w = vreg_get(0, pdata->power_name); |
| 23:54.00 | maejrep | <PROTECTED> |
| 23:54.00 | maejrep | <PROTECTED> |
| 23:54.01 | maejrep | heh |
| 23:54.30 | cr2 | looks like a more sane approach. finallyx |
| 23:54.43 | maejrep | haha |
| 23:54.47 | maejrep | was about to say that :p |
| 23:54.51 | cr2 | :) |
| 23:54.55 | maejrep | at least they're using pdata now!! |
| 23:55.02 | cr2 | yes. |
| 23:55.06 | maejrep | now that they have more than just trout to support :p |
| 23:55.14 | cr2 | next they should fix the hardcoded gpios |
| 23:55.23 | maejrep | and renaming core drivers from trout_* to htc_* or msm_* |
| 23:55.27 | maejrep | lol |
| 23:55.36 | cr2 | and finally move to a generic gpio api for cpld |
| 23:56.00 | maejrep | gpio api ;x that sounds like a chore |
| 23:56.06 | cr2 | yeah, then the code will be much more usable |
| 23:56.16 | cr2 | htc-egpio |
| 23:56.44 | maejrep | doesn't that just expose a set_egpio_value function? |
| 23:57.13 | cr2 | yes, it makes cpld gpio use translaprent |
| 23:57.43 | maejrep | i still don't know what cpld is really |
| 23:57.54 | cr2 | gpio/irq extender |
| 23:58.06 | maejrep | more than just alt func? |
| 23:58.17 | cr2 | if you don't have enough of them on the main cpu |
| 23:58.29 | cr2 | it does not have alt func. usually |
| 23:58.30 | *** join/#htc-linux Zoolooc__ (n=fredsiba@nrbg-4dbf927d.pool.einsundeins.de) |
| 23:58.41 | cr2 | at least we don#t know any |
| 23:58.47 | cr2 | set_bit(KEY_NEXTSONG, hi->input->keybit); |
| 23:58.59 | cr2 | looks completely braindead |
| 23:59.12 | cr2 | for a unix hardliner like me :) |
| 23:59.52 | cr2 | lol |