| 00:03.10 | richp3 | woooo: http://forum.xda-developers.com/showpost.php?p=3139539&postcount=1893 |
| 00:05.42 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 00:06.01 | addman3333 | Should android 1.0 with this kernel: http://forum.xda-developers.com/showthread.php?p=3138954 work with a raph800? |
| 00:07.09 | j0b0 | yes, but colors are off |
| 00:10.19 | j0b0 | and of course 'work' means: no audio, no keyboard, no sensors other than touchscreen and navpad |
| 00:10.20 | addman3333 | yes, of course. Mine is getting stuck trying to mount mmc |
| 00:10.30 | *** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 00:10.54 | j0b0 | the id is a kernel boot option. try 1, 2 and 3 |
| 00:12.59 | j0b0 | and make sure the images are in /tmp |
| 00:13.16 | addman3333 | k. Thanks I'll give that a try |
| 00:13.28 | j0b0 | (but thats after it mounts the sd card of course) |
| 00:14.57 | lupine_85 | yays that the kernel he built boots |
| 00:15.13 | lupine_85 | nothing new in it, mind ;) |
| 00:15.13 | *** join/#htc-linux Magorium (i=Othello@gateway/tor/x-54a7e4eae8ca0f17) |
| 00:15.31 | *** join/#htc-linux dcordes__ (n=dcordes@unaffiliated/dcordes) |
| 00:17.41 | lupine_85 | I think the virtual keyboard interferes with X |
| 00:18.34 | maejrep[w] | addman3333: raph800 is msm_sdccid=3 |
| 00:18.57 | addman3333 | Sweet. Thanks. |
| 00:19.36 | maejrep[w] | (sprint) |
| 00:19.47 | addman3333 | Is there anything that a programmer (not kernel programer :-/ ) could help with at this point? |
| 00:20.00 | maejrep[w] | research and testing basically |
| 00:20.18 | maejrep[w] | but really research is mostly done |
| 00:20.41 | *** join/#htc-linux dcordes_1 (n=dcordes@f054161231.adsl.alicedsl.de) |
| 00:20.58 | maejrep[w] | oh, "a programmer" thought you said not a programmer |
| 00:21.10 | maejrep[w] | kernel programming is not too different from normal C programming |
| 00:22.05 | lupine_85 | tries with the new msmvkeyb_toggle option set to off |
| 00:22.18 | lupine_85 | maejrep[w]: well, it certainly helps to have a good grasp of kernel internals |
| 00:22.34 | lupine_85 | (I do not has :p) |
| 00:22.49 | maejrep[w] | true, but I've been learning as I go ;) |
| 00:22.50 | lupine_85 | where did you post that snippet, btw? |
| 00:22.55 | maejrep[w] | privatepaste.com |
| 00:23.01 | maejrep[w] | if you search your backlog |
| 00:23.05 | maejrep[w] | I don't have it on hand |
| 00:23.35 | maejrep[w] | I think "toggle" is a bad kernel option name :P |
| 00:23.50 | maejrep[w] | toggle implies an alternating functionality |
| 00:25.33 | maejrep[w] | Jan 08 01:23:18 <maejrep> http://privatepaste.com/d701PUME04 |
| 00:25.43 | lupine_85 | tre, but I'd rather have it than not :D |
| 00:25.44 | lupine_85 | thanks |
| 00:26.16 | maejrep[w] | very rudimentary, but helps illustrate code that duplicates what you see in haret |
| 00:26.34 | maejrep[w] | you don't have to write any of the id bits beyond 0xff |
| 00:26.59 | maejrep[w] | and in fact, when you send it an addr, it has to be shifted right 1 bit, because i2c_transfer shifts the addr left 1 bit |
| 00:27.09 | lupine_85 | heh. that's good of it |
| 00:27.17 | lupine_85 | don't you lose data? |
| 00:27.18 | maejrep[w] | which is why I do 0xc4>>1 (so you can visually see the 0xc4 which matches haret) |
| 00:27.59 | lupine_85 | (and isn't diff an awesome tool? ;) ) |
| 00:28.03 | maejrep[w] | only the 0 bit |
| 00:29.27 | lupine_85 | right, vkeyb gone, let's see if X works |
| 00:29.55 | lupine_85 | (the splash screen worked before the draggabl vkeyb incidentally) |
| 00:30.00 | lupine_85 | and stopped working afterwards |
| 00:31.57 | lupine_85 | ho hum, lots of [ 24.860667] Alignment trap: Xfbdev (580) PC=0x40179930 Instr=0xe4942004 Address=0x0015c52e FSR 0x011 |
| 00:35.22 | *** join/#htc-linux balsat1 (n=kll@87.72.13.87) |
| 00:37.37 | maejrep[w] | would be nice if you could ibit certain i2c commands ;p |
| 00:38.42 | lupine_85 | maejrep[w]: if you use haretconsole, have a tail | grep on the .log ? |
| 00:38.53 | lupine_85 | (tail -) |
| 00:38.57 | lupine_85 | tail -f rather |
| 00:39.54 | maejrep[w] | speaking of which, have you had a chance to try to find out any new i2c ioctls from the source? There are plenty of strings that look like constants (why they are compiled in the dll, i'm not sure .. must be for debug logging), and knowing one name-to-address mapping could help considerably, if you assume that the strings are in a sequential order :P |
| 00:40.20 | *** join/#htc-linux infernixx (n=nix@unaffiliated/infernix) |
| 00:43.48 | *** join/#htc-linux ddfire (n=ddfire@94-240-16-190.fibertel.com.ar) |
| 00:44.22 | ddfire | hi all |
| 00:44.29 | lupine_85 | not had much time for that recently |
| 00:44.34 | ddfire | i read at xda-developers there is a new zImage |
| 00:44.39 | lupine_85 | MicroP.dll is all fun though |
| 00:44.53 | lupine_85 | (along with OEM_Misc.dll) |
| 00:44.53 | ddfire | but the others file from where i get them? and what is the radio???? |
| 00:46.11 | lupine_85 | mostly looks like KSC_IOControl is the target |
| 00:46.27 | *** join/#htc-linux camden (n=camden@ancnat2.apto.aptalaska.net) |
| 00:46.31 | *** join/#htc-linux ddfire (n=ddfire@94-240-16-190.fibertel.com.ar) |
| 00:46.32 | camden | hello |
| 00:46.52 | ddfire | hi camden |
| 00:47.07 | maejrep[w] | target for what? reading keyboard keys? |
| 00:48.41 | ddfire | please any one..... |
| 00:50.39 | maejrep[w] | ddfire: "a new zImage" isn't very descriptive ;) |
| 00:52.10 | ddfire | maejrep[w]: i found it in a post on wiki.xda.developers.com |
| 00:52.58 | ddfire | one sec |
| 00:53.21 | maejrep[w] | ddfire: what I meant was, you didn't tell what device you have, and what you are looking for |
| 00:54.04 | ddfire | maejrep[w]: i have an htc tilt i am looking boot android on it |
| 00:54.30 | ddfire | this is the link http://forum.xda-developers.com/showthread.php?p=3138622#post3138622 |
| 00:55.02 | maejrep[w] | i see, now we're getting somewhere :) |
| 00:55.12 | maejrep[w] | I don't have a tilt or know anything about a new zImage, sorry |
| 00:59.54 | ddfire | maejrep[w]: and the other files you know where i can find them? |
| 01:00.01 | maejrep[w] | what other files? |
| 01:00.11 | maejrep[w] | (that's a probable "no") |
| 01:00.13 | ddfire | haret android.bin |
| 01:00.21 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 01:00.23 | ddfire | default.txt |
| 01:00.30 | maejrep[w] | well, android.bin is usually tweaked for certain devices |
| 01:01.06 | maejrep[w] | so you'd probably want to find one that is known to work with Tilt. haret you can get from handhelds.org - or google for haret and handhelds |
| 01:01.32 | maejrep[w] | default.txt is always device specific as well, so you'd need one specifically for the Tilt |
| 01:02.31 | ddfire | maejrep[w]: thanks |
| 01:02.48 | lupine_85 | maejrep[w]: pretty much |
| 01:02.51 | lupine_85 | (the strings are very fun) |
| 01:02.59 | maejrep[w] | ddfire: that post ( http://forum.xda-developers.com/showpost.php?p=3138622&postcount=1888 ) has a zImage.zip attachment |
| 01:03.02 | maejrep[w] | did you try downloading that? :) |
| 01:03.08 | lupine_85 | I was decompiling OEM_Misc as that provides the I2C1: device |
| 01:03.31 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 01:03.32 | maejrep[w] | the strings aren't that bad.. they're just unicode |
| 01:03.37 | maejrep[w] | and reverse byte order |
| 01:03.51 | maejrep[w] | but if you run the compiled dll through strings, you can clearly see what the text is |
| 01:04.01 | maejrep[w] | or maybe not through strings, but through hexdump you can |
| 01:05.26 | maejrep[w] | ddfire: also check http://wiki.xda-developers.com/index.php?pagename=BuildTheKaiserKernel |
| 01:05.34 | maejrep[w] | if you'd like to compile it yourself |
| 01:05.46 | maejrep[w] | that also links to haret.exe and android.bin 0.8 |
| 01:07.49 | ddfire | and what about the new image? |
| 01:07.58 | maejrep[w] | [20:02:58] <maejrep[w]> ddfire: that post ( http://forum.xda-developers.com/showpost.php?p=3138622&postcount=1888 ) has a zImage.zip attachment |
| 01:07.58 | maejrep[w] | [20:03:02] <maejrep[w]> did you try downloading that? :) |
| 01:08.05 | maejrep[w] | :| |
| 01:08.20 | ddfire | yes, i try to boot it |
| 01:08.32 | ddfire | (it just hangup) |
| 01:08.52 | maejrep[w] | well, that's the zImage from that post :s |
| 01:09.00 | lupine_85 | maejrep[w]: strings --encoding=l MicroP.dll |less |grep KSC |grep Read |
| 01:09.07 | ddfire | i repleced the old zImage whit this one |
| 01:09.21 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 01:09.29 | maejrep[w] | lupine_85: I never did get that dump mounted :( |
| 01:10.04 | maejrep[w] | ddfire: that's usually the correct way to do it, but again I don't know much about the kaiser kernel |
| 01:10.08 | maejrep[w] | do you get any output at all? |
| 01:10.19 | lupine_85 | strings -a -t x --encoding=l MicroP.dll |less |grep KSC |grep Read |
| 01:10.23 | lupine_85 | (more useful) |
| 01:10.25 | ddfire | me? no |
| 01:10.40 | ddfire | maejrep[w]: thanks you very much |
| 01:10.42 | maejrep[w] | does it blank the screen, or hang at the haret "loading" screen? |
| 01:10.52 | ddfire | both |
| 01:11.06 | ddfire | one time each one |
| 01:11.08 | maejrep[w] | haret loading screen would still be in windows mobile |
| 01:11.10 | maejrep[w] | oh |
| 01:11.17 | maejrep[w] | hmm |
| 01:11.24 | maejrep[w] | and once it blanks the screen, you get no text output? |
| 01:12.16 | ddfire | nop |
| 01:12.38 | ddfire | i will try to boot the last sucsefull combination and go from there |
| 01:12.54 | maejrep[w] | yeah, sorry I don't know much about it |
| 01:13.01 | maejrep[w] | I'm sure others here do though, if you stick around |
| 01:13.03 | ddfire | no thanks you for your time |
| 01:13.23 | dcordes | ddfire: what's your aim? |
| 01:13.38 | ddfire | aim??? |
| 01:13.48 | dcordes | what do you want to do? |
| 01:14.00 | maejrep[w] | aol instant messenger :p |
| 01:14.05 | ddfire | dcordes: i want to boot android in my htc tilt |
| 01:14.31 | maejrep[w] | ddfire: you're aware that support is still very limited for most devices (kaiser included), right? |
| 01:14.42 | dcordes | with the newer (based on htc-vogue branch) kernels you can't make calls |
| 01:15.05 | *** join/#htc-linux Guimli (n=guimli@ecu69-1-82-231-127-213.fbx.proxad.net) |
| 01:15.09 | dcordes | maejrep[w]: what do you want to do today (tm) ? |
| 01:15.10 | ddfire | maejrep[w]: yes i just want to play whit it, i am a linux fan i use it to work to program |
| 01:15.26 | ddfire | i am using linux now |
| 01:15.41 | lupine_85 | maejrep[w]: maejrep[w] http://www.lupine.me.uk/MicroP.dll http://www.lupine.me.uk/MicroP.lst http://www.lupine.me.uk/MicroP.strings.txt |
| 01:16.04 | ddfire | ok i will wait until someone in the post answer my questions |
| 01:16.22 | ddfire | there is other linux to put on htc whit better hardware support? |
| 01:16.44 | lupine_85 | I shall do some more decompilation tomorrow, potentially |
| 01:16.46 | ddfire | where i can find something better than windows mobile ? |
| 01:16.47 | maejrep[w] | no, all the hardware support is being actively developed |
| 01:16.51 | dcordes | ddfire: you can see the radio version in the bottom right corner on the bootsplash |
| 01:16.57 | lupine_85 | overall, I'm bloody busy though :/ |
| 01:17.51 | ddfire | maybe it is: R 1.70.19.09? |
| 01:18.04 | dcordes | yea that |
| 01:18.34 | dcordes | ddfire: mullins posted a link to the proper radio in here yesterday |
| 01:18.47 | ddfire | where is here? |
| 01:18.51 | ddfire | the chat? |
| 01:18.58 | dcordes | yes |
| 01:18.58 | maejrep[w] | <PROTECTED> |
| 01:18.59 | maejrep[w] | :D |
| 01:19.18 | maejrep[w] | <PROTECTED> |
| 01:19.26 | maejrep[w] | that looks useful.. do you know yet how to enable those logs? |
| 01:19.59 | maejrep[w] | heading home |
| 01:20.00 | ddfire | dcordes: and how i get that link? |
| 01:20.55 | dcordes | use /topic command |
| 01:21.20 | lupine_85 | maejrep[w]: they're conditional on another function, but I don't know how one enables it |
| 01:21.45 | ddfire | and then? |
| 01:22.03 | lupine_85 | it's a common feature in the source code - once decompiled it looks like : if(sub_10012534(0x40, 0x40000000) != 0) NKDbgPrintfW(""); |
| 01:22.13 | ddfire | i dont know how to get it please give me the link or the full info on how to get it |
| 01:22.17 | lupine_85 | (the two constants change a bit) |
| 01:22.23 | lupine_85 | dunno what sub_10012534 does |
| 01:22.48 | dcordes | ddfire: go to the rikers log and look at yesterday's logs |
| 01:23.31 | dcordes | it was a rapidshare link |
| 01:23.37 | dcordes | brb |
| 01:23.37 | lupine_85 | humm, it's sub_1000C198 in the microP code |
| 01:23.38 | ddfire | ok |
| 01:23.40 | ddfire | thanks! |
| 01:25.05 | lupine_85 | my bedtime now, anyways. I have optician's in the morning |
| 01:26.23 | *** join/#htc-linux zule (i=foglem@shadowmite.com) |
| 01:26.24 | *** join/#htc-linux zycho_ (n=zycho@a89-182-17-156.net-htp.de) |
| 01:26.35 | lupine_85 | dcordes: did you have trouble with alignment traps and Xfbdev ? |
| 01:28.29 | dcordes | sorry what's an alignment trap? |
| 01:29.47 | dcordes | on kaiser/polaris there is the refresh problem in some kernels with Xfbdev |
| 01:32.53 | lupine_85 | looks like [ 24.868754] Alignment trap: Xfbdev (580) PC=0x40179930 Instr=0xe4942004 Address=0x0015c3c7 FSR 0x011 |
| 01:33.01 | lupine_85 | might not actually be causing the problem |
| 01:33.39 | lupine_85 | dcordes: on my raph100, starting X (gpe-dm) causes the screen to blank except for a mall white - in the top-left |
| 01:33.42 | lupine_85 | small* |
| 01:34.11 | dcordes | is that an area or only a line? |
| 01:34.16 | lupine_85 | just a line |
| 01:34.17 | dcordes | maybe it fails to refresh too |
| 01:34.30 | lupine_85 | dunno if it's actually a hyphen |
| 01:34.39 | dcordes | you must call the refresh function in msm_fb |
| 01:34.57 | lupine_85 | this is the most recent kernel on linuxtogo |
| 01:35.00 | dcordes | probably |
| 01:35.08 | dcordes | wait a minute |
| 01:35.33 | lupine_85 | mm, I noticed with the vkeyb on, the little section below the green square sometimes showed what looked like the gpe-de screen |
| 01:36.03 | lupine_85 | (when dragging it around, so causing updates to certain areas, I guess) |
| 01:36.10 | dcordes | maybe because the keyboard calls the refresh |
| 01:37.20 | lupine_85 | yeah, I suspect so |
| 01:37.40 | lupine_85 | framebuffer devices... another area I have no expertise in :D |
| 01:37.45 | lupine_85 | (there's a lot of them) |
| 01:38.32 | dcordes | http://privatepaste.com/721TCQ6djr |
| 01:38.41 | dcordes | this fixes the problem for kaiser in ths htc-msm branch |
| 01:39.12 | *** part/#htc-linux exco (n=exco@e181105118.adsl.alicedsl.de) |
| 01:39.14 | dcordes | but I'm not sure if it's the refresh problem on raph because j0b0 had X working |
| 01:41.07 | dcordes | searching the posts |
| 01:45.33 | dcordes | lupine_85: http://forum.xda-developers.com/showthread.php?p=3042196&highlight=xfbdev#post3042196 |
| 01:48.57 | lupine_85 | thanks. I shall play more tomorrow |
| 01:53.54 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 02:07.52 | maejrep | anyone know what the navi controller is in diam/raph? |
| 02:07.54 | maejrep | hardware wise |
| 02:10.36 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 02:10.53 | dcordes | maejrep: do we have no hi res pcb photographs? |
| 02:10.58 | dcordes | gnite |
| 02:11.07 | maejrep | ah probably |
| 02:14.59 | *** join/#htc-linux mdrobnak (n=mdrobnak@pool-96-232-187-37.nycmny.fios.verizon.net) |
| 02:16.04 | *** part/#htc-linux balsat1 (n=kll@87.72.13.87) |
| 02:16.50 | mdrobnak | Hey everyone |
| 02:22.42 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 02:23.49 | *** join/#htc-linux _schurig (n=schurig@pD95FB4E1.dip0.t-ipconnect.de) |
| 02:37.04 | *** join/#htc-linux br1ck (n=br1ck@xdslcg016.osnanet.de) |
| 02:39.44 | maejrep | hmm, the block diagram and teardown photos available currently don't mention the navi at all |
| 02:40.02 | maejrep | there's some mention of it in the service manual, but obviously nothing identifying about the chip |
| 02:40.23 | mdrobnak | That sucks. So we're still at the same point with it as we were a few days ago then, right? |
| 02:40.40 | maejrep | no, I can read data from the navi touch area now |
| 02:40.47 | maejrep | I'm just trying to find out what I should call the driver :P |
| 02:40.50 | mdrobnak | lol |
| 02:40.58 | mdrobnak | raphael_navi_reader |
| 02:40.59 | mdrobnak | lol |
| 02:41.03 | maejrep | if I can't find a part number, I'll just call it msm_navi_driver_lol |
| 02:41.20 | maejrep | CONFIG_MSM_NAVI_LOL=y |
| 02:41.31 | mdrobnak | hahaha |
| 02:41.49 | mdrobnak | I take no credit for that |
| 02:41.59 | mdrobnak | s/take/want/ |
| 02:42.17 | mdrobnak | :-) |
| 02:43.21 | maejrep | hmm, looks like there's already talk of a linux driver for kxsd9 (the accelerometer) |
| 02:44.04 | mdrobnak | I would think the PPP & Audio routing stuff is fairly important, vs the accelerometer.. |
| 02:44.15 | mdrobnak | and...the RTC |
| 02:44.57 | maejrep | lol |
| 02:45.06 | maejrep | RTC is over pcom i believe |
| 02:45.23 | maejrep | so that should be reasonably painless now that proc_comm is roughly functional |
| 02:45.44 | mdrobnak | Hats off to everyone involved, really. |
| 02:45.56 | mdrobnak | The amount accomplished in only a few weeks is amazing. |
| 02:46.23 | maejrep | that's all it takes ;) |
| 02:46.40 | maejrep | that is, time |
| 02:46.40 | maejrep | heh |
| 02:47.13 | mdrobnak | btw, I think we need to turn the touch sensitivity DOWN on the touch screen |
| 02:47.24 | mdrobnak | with the onscreen keyboard I hit multiple keys |
| 02:47.30 | maejrep | damn, already quarter to 10... I've been up past 3am for the past several days working on this :x |
| 02:47.49 | maejrep | as in, you fat finger the keys? or it repeats the key? |
| 02:47.55 | mdrobnak | one sec |
| 02:48.08 | maejrep | if the former, that's probably because of calibration |
| 02:48.20 | AstainHellbring | maejrep what you working on? |
| 02:48.38 | maejrep | navi cap sensor |
| 02:48.43 | mdrobnak | Nevermind, it's just the input on the google search is weird |
| 02:48.57 | AstainHellbring | nice get some gps from our TP's eh? |
| 02:49.01 | mdrobnak | Or it could be that the soft keyboard isn't that great at this point. |
| 02:49.12 | maejrep | by "this" i meant the phone itself not the driver |
| 02:49.18 | mdrobnak | AstainHellbring: No, navigation circle, not GPS hehe |
| 02:49.29 | maejrep | and by "navi" i meant the bottom capacitive touch navigational panel |
| 02:49.30 | maejrep | :p |
| 02:49.33 | AstainHellbring | ahhh that thing |
| 02:50.00 | mdrobnak | Yeah, I take back what I said. The touchscreen is fine :-) |
| 02:50.03 | maejrep | we need that to work in order to distinguish home from send :p |
| 02:50.22 | maejrep | and left |
| 02:50.26 | AstainHellbring | yah that would be nice |
| 02:51.01 | mdrobnak | Anyone see the stuff on the Palm pre? |
| 02:51.09 | maejrep | i've heard about it |
| 02:51.10 | AstainHellbring | memememe |
| 02:51.13 | maejrep | haven't seen it |
| 02:51.14 | AstainHellbring | pre looks hot |
| 02:51.24 | mdrobnak | I must admit, it looks pretty damn cool |
| 02:51.25 | maejrep | my boss was telling me it's going to be a rival to android heh |
| 02:51.39 | mdrobnak | and it *seemed* very fast |
| 02:52.02 | mdrobnak | I dunno. At this point, HTML & JS is what makes everything run they said |
| 02:52.08 | *** join/#htc-linux swc|666 (n=coooter@unaffiliated/swc666/x-4934821) |
| 02:52.23 | mdrobnak | I suppose, like with everything else, time will tell. |
| 02:54.49 | AstainHellbring | if its as fast as they claimed it will kick ass |
| 02:57.09 | mdrobnak | Honestly, at this point I'm looking to Linux to bring some speed to all the phones.. |
| 02:57.18 | mdrobnak | I know the RAPH should be fast... |
| 02:57.24 | mdrobnak | Sometimes it is, even in WinMo |
| 02:57.33 | mdrobnak | others though, it Lags so badly it's not funny. |
| 02:58.17 | mdrobnak | maejrep: Are you on the east coast in the US? And damn, that's late. And you've been to work in the last few days too? :-) |
| 02:59.36 | AstainHellbring | linux brought crazy speed to the titan |
| 03:01.15 | mdrobnak | then there's hope :-) |
| 03:02.13 | mdrobnak | Aside from the scroll speed of the app list, Android seems plenty fast really. |
| 03:02.20 | mdrobnak | (it seems slightly slow sometimes) |
| 03:02.29 | mdrobnak | Going down is fast, coming up isn't always |
| 03:06.59 | maejrep | yeah |
| 03:07.01 | maejrep | and yeah |
| 03:08.57 | mdrobnak | What kind of work / background do you have, if I may ask? |
| 03:09.13 | mdrobnak | I do Linux / Windows sys admin stuff for a living |
| 03:09.36 | mdrobnak | did c++ and some asm stuff in college, but couldn't get into coding too much |
| 03:15.19 | maejrep | I used to be a network administrator. now i'm a web developer for a website |
| 03:16.26 | mdrobnak | Cool. Where'd you pick up the embedded dev stuff? |
| 03:18.00 | maejrep | #htc-linux :p |
| 03:18.30 | *** join/#htc-linux Shinto (n=John@f048230110.adsl.alicedsl.de) |
| 03:25.19 | mdrobnak | LOL |
| 03:25.56 | maejrep | hmm, irq 97 isn't firing |
| 03:26.27 | mdrobnak | what's touchpad, 94 or 97? |
| 03:26.50 | maejrep | oh, that would be why i'm sure |
| 03:26.59 | maejrep | 94 is the gpio |
| 03:27.09 | maejrep | but i think i set it to use INT_GPIO_GROUP2 |
| 03:27.21 | maejrep | which is probably the keyboard among other things |
| 03:29.07 | mdrobnak | well, I'm going to make it a early night tonight...Good luck with that, and I look forward to seeing your work in the git tree :-) |
| 03:36.38 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 03:43.27 | *** join/#htc-linux Laeed (n=laeed@87-231-160-234.rev.numericable.fr) |
| 03:44.39 | Laeed | Hiiiiiiiiii!!!!! New here I am glad to join you all |
| 03:46.07 | maejrep | welcome |
| 03:46.15 | Laeed | thx |
| 03:46.48 | Laeed | i would like to help |
| 03:47.00 | Laeed | how could i do? |
| 03:49.15 | tmzt | didn't cr2 say that was the atmel adc? is there another chip it could be? |
| 03:49.38 | maejrep | atmel is what? the navi controller? |
| 03:51.18 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 03:51.19 | tmzt | OpenSys: still here? that was some information from a linux header so we would know what address to dump |
| 03:51.51 | tmzt | maejrep: it's a microcontroller, it can be anything but it has a few features built in, cr2 said there was a datasheet for it also |
| 03:52.33 | maejrep | ah ok |
| 03:52.33 | tmzt | maejrep: that won't tell us what commands it accepts, but the SREC data in the spl apparently will if disasm'd |
| 03:52.34 | maejrep | right |
| 03:52.34 | tmzt | maejrep: the SREC is basically the firmware downloaded to the chip |
| 03:52.47 | maejrep | I was asking more for the purpose of naming the driver file :P |
| 03:53.13 | tmzt | it would be htcmsmatmel or something? |
| 03:53.25 | tmzt | or even specific to the device |
| 03:53.47 | tmzt | it would be nice if we can find a common name for raph/diam since they share so much |
| 03:54.56 | maejrep | yeah |
| 03:55.19 | maejrep | instead of msm7x0xx, which 1) isn't very specific :p, and 2) covers other devices no so similar |
| 03:56.28 | maejrep | though, maybe just using MSM 7x00/1(A) to identify it isn't so bad.. they do share a lot of meaningful information (although some also differs) |
| 03:56.51 | maejrep | probably the most different device of them all is the trout, but that would be expected I think |
| 03:56.54 | tmzt | there is nothing msm specific about this chip and it shouldn't be dependent on msm at all |
| 03:57.03 | maejrep | the atmel you mean? |
| 03:57.04 | tmzt | it's just a i2c chip |
| 03:57.06 | tmzt | yes |
| 03:57.46 | tmzt | it's a i2c chip driver that registers one or more input devices |
| 03:57.48 | maejrep | hmm, just noticed there's a very different behavior between touching the key cap and touching the action button... not sure why that is, i thought they shared an irq |
| 03:58.08 | maejrep | so the one driver would handle everything that goes through that chip? :x |
| 03:58.17 | maejrep | (there's a lot of stuff it could be doing) |
| 03:58.25 | tmzt | no, one is the capacitative ts the other is a momentary switch |
| 03:58.45 | tmzt | maybe or it should be a mfd driver |
| 03:59.07 | tmzt | it would be enough for now to be an input device that is also a led driver |
| 03:59.31 | tmzt | though mfd is probably right |
| 04:00.06 | maejrep | er? |
| 04:00.15 | tmzt | multifunction device drivers/mfd |
| 04:00.17 | maejrep | when i said action button, i didn't mean pressing it - i mean the capacitive sensor of it |
| 04:00.30 | maejrep | must be the way windows handles it |
| 04:00.30 | tmzt | ah, that might be different adc then |
| 04:00.45 | maejrep | cause the GPIO is the same whether touching the main button keycap, or touching the action keycap |
| 04:01.02 | tmzt | I assume the irq's are soft irq's on the atmel implemented as gpio's, though it could be all through i2c?? |
| 04:01.14 | maejrep | was just noticing the the dimmed backlight didn't get bright when touching the main buttons, but touching the center button did |
| 04:01.23 | tmzt | or you mean a register on it has a bit set that you have to clear? |
| 04:01.30 | tmzt | in wm? |
| 04:01.38 | maejrep | i don't know what you're asking :X |
| 04:01.46 | tmzt | it doesn't do anything in linux though, does it? |
| 04:01.53 | maejrep | not yet |
| 04:01.58 | maejrep | until I make it do something ;p |
| 04:02.04 | tmzt | well, what do you mean by irq? |
| 04:02.37 | maejrep | did i say irq? i meant gpio (which is handled as an irq for our purposes) |
| 04:02.42 | tmzt | "different behavior" and "I thought they shared an irq" ? |
| 04:03.04 | tmzt | so it actually uses different gpios on the msm chip? |
| 04:03.07 | maejrep | and, they do share that gpio (just checked again in haret) |
| 04:03.09 | maejrep | no |
| 04:03.22 | maejrep | its just windows that behaves differently based on where you touch |
| 04:03.35 | maejrep | touching the action button wakes up a dimmed display, but the rest of the navi does not |
| 04:03.41 | maejrep | (touching, not pressing) |
| 04:03.50 | tmzt | right, mfd is probably what you want because it implements the ISRs on the atmel firmware (i2c registers) as different gpios/irqs |
| 04:04.02 | maejrep | :O |
| 04:04.34 | tmzt | I guess you implement that at the low-level, then write higher level drivers for the input, led, etc. functions |
| 04:04.35 | maejrep | so the driver would go there, instead of under i2c, or mach-msm? |
| 04:04.42 | tmzt | I think |
| 04:05.06 | tmzt | based on reading some discussions on the linux-arm-kernel and openezx-devel lists |
| 04:05.27 | tmzt | I guess it's not a i2c chip because it's not fixed-function |
| 04:06.36 | maejrep | k i'll have to read up about that in a bit heh |
| 04:07.18 | maejrep | for now i'm just trying to learn i2c and see if I can reverse the API for the data that comes out |
| 04:10.29 | maejrep | hmm |
| 04:13.56 | maejrep | tmzt, any ideas why my module can't request the irq after being removed and reinserted? :x |
| 04:14.07 | maejrep | I'm calling free_irq in my remove function |
| 04:16.09 | tmzt | cat /proc/interrupts |
| 04:16.43 | maejrep | 158: 1 msmgpio itializing addr: %02x |
| 04:16.43 | maejrep | :X |
| 04:16.54 | maejrep | (that is not the string I passed to request_irq...) |
| 04:17.53 | maejrep | I get: [ 114.350183] testi2c_probe: failed to get irq 158 |
| 04:18.04 | maejrep | but the first time I insert it, it works |
| 04:18.22 | maejrep | and when I rmmod, I get: [ 103.657677] Trying to free already-free IRQ 158 |
| 04:28.55 | *** part/#htc-linux Laeed (n=laeed@87-231-160-234.rev.numericable.fr) |
| 04:31.09 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 04:42.03 | maejrep | tmzt, there's an atmel spi driver already in git, do you think it's related and/or would work? |
| 04:42.04 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 04:42.23 | tmzt | it might, but I think this is firmware dependent |
| 04:44.37 | maejrep | looking at the code, it seems reasonable, and implements dma |
| 04:44.48 | maejrep | but I don't know how that works really ;x |
| 04:53.25 | maejrep | well that was a kernel panic :) |
| 05:03.27 | *** join/#htc-linux [OpenSys] (n=vasco@bl7-171-90.dsl.telepac.pt) |
| 05:22.45 | *** join/#htc-linux Kevin2 (n=Kevin2@207-237-194-161.c3-0.avec-ubr2.nyr-avec.ny.cable.rcn.com) |
| 05:24.53 | maejrep | :| |
| 05:27.36 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 05:36.48 | *** join/#htc-linux goxboxlive (n=goxboxli@mail2.hjellnesconsult.no) |
| 05:37.43 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 05:48.58 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 05:56.07 | maejrep | i hate when i screw with something and eventually make it stop working :( |
| 05:56.23 | jerry507_mac | Negative progress stinks |
| 05:57.37 | maejrep | hmm, I do see one difference ... wonder if that broke it ;x |
| 05:58.26 | maejrep | ah that would definitely break it :( |
| 05:59.03 | maejrep | uninitialized character buffer, writing one byte of it to i2c == D: |
| 05:59.18 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 05:59.46 | tmzt | ah, were you using s*nprintf to fill the request_irq string? |
| 06:00.02 | tmzt | why did it use "addr: %02x" ? |
| 06:01.16 | maejrep | nope |
| 06:01.29 | maejrep | the addr:%02x was from a printk about 2 lines later |
| 06:01.34 | maejrep | had to be memory corruption of some sort |
| 06:01.47 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 06:01.54 | maejrep | request_irq string was a string literal "testi2c" |
| 06:03.54 | maejrep | argh |
| 06:05.20 | maejrep | if its not one thing its another (this is what i was talking about when I said I screw with things so much trying to fix one problem, that I end up not realizing that one "fix" broke something else and then the original problem was later fixed without me realizing it, except the other fix that broke it is still broken |
| 06:06.29 | *** join/#htc-linux tekkdrone (i=tekkdron@72.183.115.231) |
| 06:13.26 | *** join/#htc-linux pichurri (n=pichurri@194.230.146.132) |
| 06:20.08 | *** join/#htc-linux br1ck (n=br1ck@xdslcg016.osnanet.de) |
| 06:21.12 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 06:24.41 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 06:31.27 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 06:33.11 | *** join/#htc-linux TheJoker (i=Othello@gateway/tor/x-b3ae603979771dbc) |
| 06:38.22 | *** join/#htc-linux msbullock (n=msbbull@173-105-126-8.pools.spcsdns.net) |
| 06:38.56 | msbullock | hello |
| 06:39.15 | tmzt | hi |
| 06:41.09 | zycho_ | hi |
| 06:41.50 | msbullock | which htc phones do you have? |
| 06:42.14 | tmzt | none |
| 06:42.31 | zycho_ | diamond |
| 06:42.50 | *** join/#htc-linux TheJoker (i=Othello@gateway/tor/x-3b33595869c08c03) |
| 06:43.38 | jerry507_mac | tmzt, you don't have a single one? |
| 06:43.45 | msbullock | I have the Titan and I hate it. I want a different phone but I'd like to have one with android. |
| 06:43.51 | tmzt | no, I have a moto q but that's not htc |
| 06:44.07 | tmzt | why do you hate Titan? |
| 06:44.14 | jerry507_mac | It's a little ironic :) |
| 06:44.45 | tmzt | it's a few kernel drivers |
| 06:44.51 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 06:45.26 | msbullock | the keyboard messes up with the missing letters or the double letters |
| 06:46.28 | msbullock | The memory isnt enough to have a functioning windows 6.1 and still run applications with the memory left over. |
| 06:47.05 | *** join/#htc-linux kiozen (n=oeichler@p5492A476.dip0.t-ipconnect.de) |
| 06:47.50 | *** join/#htc-linux balsat1 (n=kll@87.72.13.87) |
| 06:47.59 | msbullock | running NueRom pre 3 after a fresh restart Im lucky to have 24 mb free at startup, 20 after some occasional usage. |
| 06:48.39 | tmzt | what are you looking to do with it? |
| 06:48.52 | msbullock | I hate that more than half the ram on the phone is required for just the operating system |
| 06:50.57 | msbullock | I want something that runs smooth, Something I can easily customize. Ssomething thats functional first, media second |
| 06:52.37 | msbullock | I'd love if they made a Touch Pro android phone. something with free memory so I can have google maps open when Im flipping through my contacts and not crash. |
| 06:52.59 | *** join/#htc-linux tekkdrone (n=tekkdron@72.183.115.231) |
| 06:54.35 | msbullock | I like the concept of an open source phone. The platform is a great staring point for many small electronic devices and requires very littlle memory |
| 06:55.57 | tmzt | ok, you should probably try dzo's vogue images though there may now be a compiled titan image somewhere |
| 06:58.28 | msbullock | Last titan image I tried from Jan 5 the touchscreen was so bugged out I couldnt use it. The image before that to get anything you had to press so hard on the screen it was un-useable. will the vogue rom keys be the same as the titan? |
| 06:59.06 | tmzt | we should see if it's possible to build a non-vkeyb titan image assuming the hard keys work now |
| 06:59.22 | tmzt | then the touchscreen becomes a userspace issue as it normally is |
| 06:59.34 | maejrep | :( |
| 06:59.52 | tmzt | maejrep: any idea or is that about raph |
| 07:00.05 | maejrep | yeah that's me getting frustrated :P |
| 07:00.19 | maejrep | don't understand how it could be working perfectly yesterday, and totally fail now |
| 07:01.25 | *** join/#htc-linux TheJoker (i=Othello@gateway/tor/x-7850df823c9d51c1) |
| 07:01.30 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 07:01.32 | msbullock | tmzt, I'll have to look for that vogue image. I'm off to bed for the night, thanks for the Idea |
| 07:03.17 | tmzt | maejrep: have you uppgraded or pulled the kernel? |
| 07:03.29 | maejrep | no |
| 07:08.21 | *** join/#htc-linux daspsycho (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
| 07:09.15 | tmzt | maejrep: I was wondering if the memory corruption was a result of that, but I guess it's just your driver |
| 07:09.25 | maejrep | yeah :P |
| 07:09.48 | tmzt | can you paste it (msg if you prefer) |
| 07:17.11 | maejrep | ugh |
| 07:17.15 | maejrep | the driver? |
| 07:17.28 | maejrep | can't really call it that right now :P |
| 07:17.39 | maejrep | more like a passenger, straight to hell |
| 07:18.06 | maejrep | it's horribly mangled but i'll paste it for you if you'd like |
| 07:18.26 | maejrep | hmm |
| 07:18.43 | *** join/#htc-linux pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be) |
| 07:19.07 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 07:32.34 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 07:36.55 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 07:37.04 | tmzt | maejrep: have you dumped the atmel with i2cdump ? |
| 07:37.30 | maejrep | is that a linux app? |
| 07:37.35 | maejrep | and is it in angstrom? |
| 07:37.54 | tmzt | yes, it's part of i2ctools from lmsensors |
| 07:38.10 | tmzt | you also need i2cdev enabled in the kernel |
| 07:38.22 | maejrep | chardev? |
| 07:38.39 | tmzt | /dev/i2c-1 /dev/i2c-2 etc. |
| 07:38.54 | tmzt | yeah |
| 07:39.53 | tmzt | do you get any spamed irq messages now? |
| 07:39.54 | maejrep | and did you say its in angstrom? or i should get lmsensors? |
| 07:39.57 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 07:40.10 | tmzt | or nobody cared? |
| 07:40.24 | tmzt | I think it's in angstrom |
| 07:40.26 | maejrep | no, if I comment out the i2c_transfer function, I do get the printk's |
| 07:40.36 | maejrep | but not overly spammed |
| 07:40.43 | maejrep | I get what I should expect |
| 07:40.49 | tmzt | I mean from the kernel core itself |
| 07:40.58 | maejrep | oh no, but I did just enable i2c debugging |
| 07:41.30 | tmzt | the reason for writing an i2c chip driver if I understand it is to acknowledge an irq |
| 07:42.06 | tmzt | meaning, if the chip causes an irq you have to mask that in the chip or you continue to get the irqs |
| 07:42.12 | maejrep | i think i2c-msm handles that part of it |
| 07:42.32 | maejrep | then i'm not understanding |
| 07:43.07 | maejrep | the chip has to do that, or the bus does? |
| 07:43.37 | tmzt | well, I mean disable_irq prevents your handler from being called but the chip continues to cause irqs (unless the gpio is rising-edge only) |
| 07:44.00 | tmzt | this is common in i2c gpio expanders that need to cause irqs for each of the additonal gpio pins |
| 07:44.43 | tmzt | there is a register that is written to mask a particular gpio once handled so that the cpu is not interrupted by the chip again |
| 07:45.10 | tmzt | this register is specific to the chip, not something i2c can handle itself |
| 07:45.31 | maejrep | would it be in the i2c memory area? |
| 07:45.39 | tmzt | it's possible your chip stops interrupting the msm once it's talked to over i2c or some other handshake |
| 07:46.09 | tmzt | yeah, that's why I am saying to i2cdump and see if such a register exists |
| 07:46.30 | maejrep | yeah, no i2cdump on angstrom |
| 07:46.37 | tmzt | but it could be a specific command particularly with a programmable chip like this |
| 07:46.42 | maejrep | would I be able to compile it using my cross compiler? |
| 07:46.47 | tmzt | i2c-tools i2c-utils something like that |
| 07:46.49 | tmzt | yes |
| 07:48.06 | tmzt | wait, I compiled mine on the device but OE should provide an environment in it's interactive mode |
| 07:50.24 | maejrep | $ file tools/i2cdump |
| 07:50.25 | maejrep | tools/i2cdump: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped |
| 07:50.30 | *** join/#htc-linux Mullins (n=bw@89.204.241.105) |
| 07:50.33 | maejrep | OE? |
| 07:50.51 | maejrep | I don't know how I should compile this :( |
| 07:51.41 | tmzt | open embedded, the system angstrom uses |
| 07:52.19 | tmzt | what is the development mode, bbuild something |
| 07:52.35 | maejrep | what? |
| 07:53.13 | tmzt | do you have angstrom sources already built? |
| 07:54.01 | maejrep | i'm using the angstrom initrd that NetRipper made a long time ago |
| 07:54.06 | maejrep | but i just got it compiled |
| 07:54.06 | tmzt | bitbake, dcordes told me the command and I can't ever remember it, but it allows you to get a shell in the cross environment |
| 07:54.10 | tmzt | ok |
| 07:54.12 | tmzt | how? |
| 07:54.32 | maejrep | CC := arm-none-linux-gnueabi-gcc |
| 07:54.34 | maejrep | in make file |
| 07:54.53 | maejrep | # ./i2cdetect -l |
| 07:54.53 | maejrep | i2c-0i2c MSM I2C adapter I2C adapter |
| 07:55.07 | tmzt | ok, I guess that works if it only needs libc |
| 07:55.13 | tmzt | cool |
| 07:55.38 | tmzt | i2cdetect (help) |
| 07:55.42 | maejrep | so what specifically should I look for with i2cdump? |
| 07:55.58 | tmzt | dump the whole chip by address if you can |
| 07:56.23 | tmzt | something that changes when you touch the sensor |
| 07:56.56 | *** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com) |
| 07:57.25 | tmzt | i2cdump 1 <addr> b |
| 07:57.25 | maejrep | I'm getting X's |
| 07:57.40 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 07:57.41 | tmzt | all X's? |
| 07:57.48 | maejrep | <PROTECTED> |
| 07:57.48 | maejrep | 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX |
| 07:57.48 | maejrep | 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX |
| 07:57.50 | maejrep | yes |
| 07:57.55 | maejrep | (all the way to ff) |
| 07:58.14 | maejrep | that was i2cdump 0 3 |
| 07:58.15 | tmzt | try w instead of b |
| 07:58.22 | tmzt | 3? |
| 07:58.26 | maejrep | ah nm |
| 07:58.28 | tmzt | what was the i2c id from earlier? |
| 07:58.36 | maejrep | used x62 and that worked |
| 07:58.41 | maejrep | didn't realize all that data was for a single id |
| 07:58.50 | maejrep | <PROTECTED> |
| 07:58.50 | maejrep | 00: 00 55 aa 55 aa 00 00 00 00 00 00 00 00 00 00 82 .U?U?..........? |
| 07:58.50 | maejrep | 10: 00 20 a2 XX XX XX XX XX XX XX XX XX XX XX XX XX . ?XXXXXXXXXXXXX |
| 07:58.50 | tmzt | collect as many as you can |
| 07:59.02 | maejrep | so that's what I expect |
| 07:59.17 | tmzt | and you know the length now I guess |
| 07:59.59 | maejrep | heh yeah |
| 08:00.27 | maejrep | kind of an odd number, and haret only shows 18 bytes |
| 08:00.33 | tmzt | is it always like that? |
| 08:00.49 | maejrep | like what? 19 bytes? |
| 08:00.55 | tmzt | i2cdump -r 00 18 0/1 0x62 b |
| 08:01.24 | tmzt | all 00 in the middle |
| 08:01.39 | maejrep | not if i'm touching it heh |
| 08:01.54 | tmzt | the leds are all off? |
| 08:02.12 | maejrep | behind the keycap? yes (charging light is pulsing though) |
| 08:02.40 | lupine_85 | ooooooooooooooooooooooooh |
| 08:02.47 | tmzt | so the last few bytes change? |
| 08:02.56 | tmzt | 82 00 20 a2 |
| 08:03.51 | tmzt | you probably need to keep your finger on the sensor when dumping |
| 08:03.57 | maejrep | right |
| 08:03.58 | maejrep | <PROTECTED> |
| 08:03.59 | maejrep | 00: 00 11 ff ff ff 00 ff ff 1b 00 00 01 ff ff ff 82 .?......?..?...? |
| 08:03.59 | maejrep | 10: 00 20 d6 . ? |
| 08:04.05 | maejrep | that's on the action button |
| 08:04.27 | tmzt | oh, the aa 55 aa 55 changed too |
| 08:05.57 | maejrep | yeah, and it seems to settle back down to some other values, but then they don't reset back to 0 |
| 08:06.12 | maejrep | <PROTECTED> |
| 08:06.12 | maejrep | 00: 00 55 aa 55 aa 82 ff ff 00 00 00 06 ff ff ff 82 .U?U??.....?...? |
| 08:06.12 | maejrep | 10: 00 20 2b . + |
| 08:06.19 | maejrep | haven't touched it in a couple minutes |
| 08:06.48 | tmzt | it's possible you are supposed to reset it somehow |
| 08:07.02 | tmzt | have you traced writes in wm with cr2's instructions? |
| 08:07.10 | maejrep | yes |
| 08:07.17 | maejrep | addlist mmutrace, anyway |
| 08:07.23 | maejrep | not sure if his instructions include more than that :p |
| 08:07.48 | *** join/#htc-linux kiozen (n=oeichler@p5492A476.dip0.t-ipconnect.de) |
| 08:08.47 | tmzt | any other banks? |
| 08:09.32 | tmzt | how quickly does /proc/interrupts for the i2c irq increase? |
| 08:09.38 | tmzt | (if it's enabled) |
| 08:11.28 | maejrep | http://www.privatepaste.com/acc28qx41q |
| 08:11.45 | maejrep | it's not enabled (didn't insert the module yet) |
| 08:14.13 | tmzt | 0xd 0xf look interesting |
| 08:14.16 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) [NETSPLIT VICTIM] |
| 08:14.16 | *** join/#htc-linux Descention (n=munsco95@acm.pct.edu) [NETSPLIT VICTIM] |
| 08:14.16 | *** join/#htc-linux tcccp (n=hey@223.66.238.89.arpa-addr.in) [NETSPLIT VICTIM] |
| 08:14.16 | *** join/#htc-linux Dinde (n=kayser@81-65-176-209.rev.numericable.fr) [NETSPLIT VICTIM] |
| 08:14.16 | *** join/#htc-linux Funklord (n=cow@c-ecd572d5.014-46-73746f28.cust.bredbandsbolaget.se) [NETSPLIT VICTIM] |
| 08:14.17 | *** join/#htc-linux swetland (n=swetland@nat/google/x-ac2328226c12fbc1) |
| 08:14.20 | tmzt | two buttons on the same hardbutton have the same value? |
| 08:15.02 | maejrep | they have the same keypad (gpio matrix) value |
| 08:15.14 | maejrep | but no, the navi sensor should detect the difference between them |
| 08:15.23 | tmzt | I don't mean press I mean touch |
| 08:15.37 | jerry507_mac | Didn't someone else run into the same problem |
| 08:15.40 | maejrep | yeah they should not be the same (maybe some values the same, but not all) |
| 08:16.21 | tmzt | look at down and up |
| 08:16.47 | tmzt | "3b 3b 3b" "1d 1d 1d" |
| 08:17.13 | maejrep | left is 0f 0e[f?] 0f |
| 08:17.18 | maejrep | right 2c 2c 2c |
| 08:17.39 | tmzt | touch left but a little differently |
| 08:17.51 | maejrep | 0, 1, 2, 3 heh |
| 08:17.54 | maejrep | for the quadrant |
| 08:18.08 | tmzt | and pressure? |
| 08:18.17 | *** join/#htc-linux pichurri (n=pichurri@users3.ilo.org) |
| 08:18.28 | maejrep | 0=left, 1=up, 2=right, 3=down |
| 08:18.32 | maejrep | let me see, sec |
| 08:19.06 | maejrep | looks like pressure is not considered? |
| 08:19.07 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0-18 0 98 b |
| 08:19.07 | maejrep | <PROTECTED> |
| 08:19.08 | maejrep | 00: 00 44 ff ff 3b 00 ff ff 00 00 40 00 3b 3b 3b 82 .D..;.....@.;;;? |
| 08:19.08 | maejrep | 10: 00 20 14 . ? |
| 08:19.08 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0-18 0 98 b |
| 08:19.10 | maejrep | <PROTECTED> |
| 08:19.12 | maejrep | 00: 00 44 ff ff 3b 00 ff ff 00 00 40 00 3b 3b 3b 82 .D..;.....@.;;;? |
| 08:19.14 | maejrep | 10: 00 20 14 . ? |
| 08:19.18 | maejrep | first one is barely touching, 2nd is pressing the hard button |
| 08:19.34 | tmzt | the atmel firmware is doing more work here |
| 08:19.50 | maejrep | http://www.privatepaste.com/3dik8mYHj9 -- this is the same one as earlier but grouped according to hard button |
| 08:19.55 | tmzt | I mean pressure as in more area covered or pressed harder but not pressing the button |
| 08:20.00 | tmzt | same as on a touchpad |
| 08:20.06 | maejrep | k |
| 08:20.30 | *** join/#htc-linux k1ll (n=spam@218.63.252.219) |
| 08:21.24 | dcordes | hi |
| 08:22.12 | tmzt | so 1, 2, 3, 4 are some kind of status with aa 55 being clear? |
| 08:22.43 | maejrep | hmm |
| 08:23.38 | maejrep | looks like [1] is "area" of the entire keypad |
| 08:24.31 | maejrep | 11 = action, 22 = home/send, 44 = up, 55 = down, 66 = left, cc = right, 88 = back/end |
| 08:24.52 | maejrep | no, maybe not... hmm |
| 08:25.15 | maejrep | I don't think 55aa55aa is clear though |
| 08:25.28 | dcordes | what does the i2cdump output represent? is like every bank representing a pin? |
| 08:25.57 | tmzt | like a memory area on the chip |
| 08:26.06 | ali1234 | it doesn't really represent anything logic, especially if you're dealing with a microcontroller |
| 08:26.14 | tmzt | think of an i2c eeprom, which is a very simple chip with just read/write commands |
| 08:26.37 | tmzt | ali1234: hey, you know what's going on here? |
| 08:26.46 | ali1234 | i know a bit about i2c |
| 08:26.50 | tmzt | like the first 5 bytes? |
| 08:27.01 | ali1234 | the first 5 bytes usually arn't used at all |
| 08:27.17 | dcordes | ok |
| 08:27.19 | tmzt | the first dump had 00 55 aa 55 aa |
| 08:27.43 | ali1234 | but you are dealing with a microcontroller right? |
| 08:27.47 | maejrep | the values for byte 1 do seem to be significant |
| 08:27.53 | tmzt | yes, atmel avr? |
| 08:27.58 | ali1234 | so... |
| 08:28.18 | tmzt | cr2 also said it's programmed by spl so must be over i2c also |
| 08:28.28 | ali1234 | reading one byte from each address might not even tell you anything useful |
| 08:28.37 | dcordes | so the spl uploads a firmware each boot? |
| 08:28.41 | tmzt | i2cdump w ? |
| 08:28.51 | maejrep | so 1=0x44 is both up and down |
| 08:29.15 | ali1234 | get the firmware and analyse it? |
| 08:29.42 | tmzt | it's in SRECs in the spl |
| 08:29.56 | dcordes | if cr2 found that it uploads the firmware he might as well dump it? |
| 08:30.38 | ali1234 | i2c isn't like a memory space... it's more like 127 serial ports :) |
| 08:31.25 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 08:31.26 | tmzt | ali1234: I mean the commands make it appear that way although the microcontroller can certainly behave differently |
| 08:31.27 | ali1234 | do you know what kind of avr it is? |
| 08:32.13 | ali1234 | the linux i2cdump command works that way, but lower level stuff doesn't... you may need to read more than one byte from an address to get anything meaningful |
| 08:32.17 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 08:32.56 | ali1234 | if it was just a gpio expander or cpld then no... but as it is a uC then you really can't tell without traces or disassembled firmware |
| 08:33.26 | cr2 | hi |
| 08:33.43 | cr2 | ali1234: you know the atmel asm ? |
| 08:33.48 | maejrep | hmm, i just made it unhappy |
| 08:33.52 | dcordes | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=commit;h=4aaf31b55b8b87c7afcce8684deb6fb56719abb1 |
| 08:34.10 | cr2 | tmzt: there is no i2c controller in atmel, according to the datasheet |
| 08:34.13 | ali1234 | cr2: i know how to program them in C, i can work my way through the asm given enough time :) |
| 08:34.28 | cr2 | so it must be some bitbang driver implemented in firmware |
| 08:34.40 | ali1234 | cr2: does it say "TWI" |
| 08:34.50 | cr2 | so it supports multiple i2c ids |
| 08:34.51 | ali1234 | cr2: "i2c" is copyright, everyone but phillips calls it "TWI" |
| 08:35.20 | cr2 | i don't give a fckw |
| 08:36.04 | cr2 | ali1234: the asm does not look very difficult to decode |
| 08:36.46 | ali1234 | cr2: i'm just saying... you wont ever see "i2c" in an avr datasheet, even though most support it in hardware |
| 08:36.49 | cr2 | but i doubt that we really need it. there are not that much commnds sent, so we can attribute them relatively easy |
| 08:37.21 | cr2 | hm. ok, i'll check |
| 08:37.27 | cr2 | yes, i2c is patented by philips |
| 08:38.12 | cr2 | so i don't know why one will use i2c if it's not implemented in hardware |
| 08:38.13 | cr2 | instead of spi |
| 08:38.53 | cr2 | btw, is there any linux i2c keyboard driver ? |
| 08:39.11 | ali1234 | sort of |
| 08:39.18 | cr2 | Kevin2 has written the spi keyboard driver for hermes/athena |
| 08:39.25 | ali1234 | look in the dvb usb stuff, they all use i2c for the remote controls |
| 08:39.44 | cr2 | so it'd not be very difficult to change the transport protocol |
| 08:39.48 | ali1234 | but of course the actual protocol is completely arbitrary |
| 08:40.16 | cr2 | because it's just spi bus vs. i2c bus here |
| 08:41.20 | ali1234 | i think you'll find that spl is uploading the firmware over spi |
| 08:41.22 | cr2 | maejrep: http://wiki.xda-developers.com/index.php?pagename=RaphaelPSOC |
| 08:41.32 | dcordes | http://ozlabs.org/pipermail/linuxppc-embedded/2002-September/008295.html |
| 08:41.33 | ali1234 | to do it over i2c would require a custom bootloader on the avr |
| 08:41.37 | *** join/#htc-linux daspsycho (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
| 08:41.44 | maejrep | I'm using it :) |
| 08:42.42 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 08:42.44 | cr2 | ali1234: there are many firmwares for different devices ;) i need to document the fw/chip id sequence |
| 08:42.47 | tmzt | 18:50 < cr2> bstone spl has SREC decoder |
| 08:42.47 | tmzt | 18:51 < cr2> hm. the same atmegap48 |
| 08:42.47 | tmzt | 18:51 < cr2> Reset Micro_P48(KEY) |
| 08:42.49 | tmzt | 18:51 < cr2> Reset Micro_P48(LED) |
| 08:43.26 | cr2 | cc,30,02,x - get version |
| 08:43.47 | tmzt | found it and cr2 shows up, cool |
| 08:43.51 | cr2 | tmzt: i think it's just a binary blob on others |
| 08:43.56 | ali1234 | cr2: maybe you could port avrdude :) |
| 08:44.36 | tmzt | cr2: the i2cdump looks interesting but only 18 bytes, ali1234 said to try words |
| 08:44.42 | tmzt | maejrep: can you change that b to a w? |
| 08:44.52 | ali1234 | should be easy if it's just bitbanging spi on a gpio... assuming you have linux up and networking or something |
| 08:44.54 | cr2 | ali1234: the fw update is included in the driver, it just takes time to document it. with checksumming et al. |
| 08:45.38 | cr2 | tmzt: mmutracing the i2c traffic is more helpful |
| 08:45.51 | cr2 | ali1234: i fear it all goes over i2c |
| 08:46.04 | tmzt | is there a decoder for commands and addresses? |
| 08:46.27 | tmzt | for haret traces |
| 08:46.48 | BabelO_ | hi |
| 08:46.58 | BabelO_ | cr2 i ve the si47x driver :) |
| 08:47.32 | cr2 | hi BabelO_ |
| 08:48.18 | cr2 | tmzt: harald welte did something in this direction, but for 'traces' instead of 'mmutrace' |
| 08:48.21 | cr2 | so he had a lot of trouble |
| 08:48.36 | cr2 | BabelO_: does it work ? :) |
| 08:49.14 | maejrep | tmzt: |
| 08:49.15 | maejrep | # ./i2cdump -y -r 0-12 0 98 w |
| 08:49.16 | maejrep | <PROTECTED> |
| 08:49.16 | maejrep | 00: 5500 aa55 55aa aa55 00aa 0000 0000 0000 |
| 08:49.16 | maejrep | 08: 0000 0000 0000 0000 0000 |
| 08:49.41 | cr2 | tmzt: i used some hacked awk script to parse the i2c log |
| 08:49.54 | cr2 | tmzt: but only for ak4641 |
| 08:50.21 | cr2 | tmzt: a .py i2c protocol analyzer will be very nice to have .... |
| 08:50.23 | tmzt | are there likely to be commands other than read/write here? |
| 08:50.39 | maejrep | I think this data is meaningful, we just need to be able to turn the bytes into sections of the key cap |
| 08:51.02 | maejrep | which appears to be possible |
| 08:51.13 | tmzt | could the first 5 be words and the rest bytes? |
| 08:51.34 | cr2 | maejrep: i think it's just an ADC readout. for the x an y axes, like on the touchscreen |
| 08:51.59 | cr2 | maejrep: so you'd reuse the ts infrastructure |
| 08:52.11 | maejrep | I don't know what you mean by ADC ;x |
| 08:52.29 | cr2 | Analog-DigitalConverter |
| 08:52.36 | maejrep | ah |
| 08:52.43 | maejrep | right I did know that :P |
| 08:53.09 | tmzt | which would be really cool because you could do real gestures then? |
| 08:53.09 | maejrep | the data I'm getting here is the same data I was seeing in haret mmutrace |
| 08:53.30 | cr2 | maejrep: so it's an i2c touchscreen. like tsc2003 on vogue/titan/kaise |
| 08:54.03 | cr2 | tmzt: i doubt that it's 3D |
| 08:54.13 | tmzt | 3d? |
| 08:54.52 | cr2 | it records the capacity changes in 2D (/y) |
| 08:55.12 | cr2 | like most touchscreens do for the resistance. |
| 08:55.19 | tmzt | yeah, I didn't mean 3d, I mean swiping across the face or whatever |
| 08:55.20 | maejrep | yeah doesn't seem to be affected by pressure |
| 08:55.24 | tmzt | oh |
| 08:55.30 | cr2 | do you know 3D touchscreens ? :) |
| 08:55.57 | maejrep | synaptics touchpads measure pressure ;) |
| 08:56.06 | tmzt | the synaptics demos for windows could measure pressure |
| 08:56.14 | tmzt | it shows it as different colors |
| 08:56.32 | cr2 | tslib does nt use pressure |
| 08:56.47 | cr2 | but it's usually reported by many ts drivers |
| 08:57.10 | tmzt | kernel can report it though, tslib only cares if the driver flag is there (ABS_PRESSURE) and accepts 0/1 or any range during calibration |
| 08:57.19 | tmzt | but translates it into a 0/1 value |
| 08:57.32 | tmzt | based on a threashold |
| 08:57.35 | cr2 | ok |
| 08:57.52 | maejrep | So it seems like certain bytes are "section", and other bytes are showing position within that section |
| 08:58.11 | tmzt | and there are 3 or 4 completely seperate sections? |
| 08:58.35 | cr2 | maejrep: the driver talks about 'table' |
| 08:58.41 | tmzt | we can aggregate and convert to a single x,y though maybe |
| 08:59.18 | maejrep | right |
| 08:59.55 | tmzt | I wonder if that stuff is not exposed though based on the data here |
| 09:00.01 | maejrep | there's left section, left nav, right section, right nav, action, up nav, and potentially down nav but I'm having a hard time replicating down |
| 09:00.19 | tmzt | if there are 8 adc inputs and the fw is converting all this stuff |
| 09:00.40 | maejrep | and by that ^ I mean the i2cdump is reporting unique values for byte 1 based on section |
| 09:00.45 | cr2 | tmzt: 1 adc is used for the luminosity sensor |
| 09:02.10 | cr2 | dcordes: The requested URL /re/bin/view/linux.html was not found on this server. |
| 09:02.21 | tmzt | well how many are there in hw? I based 8 on you saying there would be a x/y per area (or x/y are needed for a capacitative sensor) and there are 3 or 4 sensors here |
| 09:02.29 | *** join/#htc-linux daspsycho1 (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
| 09:02.57 | maejrep | you mean physical hw buttons? |
| 09:03.07 | maejrep | there's left, right, down, up, action |
| 09:04.02 | tmzt | the circular scrolling works on part of left/right doesn't it, as well as on the central part? |
| 09:04.09 | maejrep | the 4 directional areas from i2c cap sensor let you 1) detect rotating in a circle around the action button, and 2) determine left and right directional intention when pressing the left or right hard buttons |
| 09:04.18 | cr2 | maejrep: i think some of them are on the gpio matrix ? |
| 09:04.26 | maejrep | all the hard buttons are |
| 09:04.55 | cr2 | btw, why is the matrix driver using polling ? |
| 09:05.00 | BabelO_ | cr2: it should work :) i just need to keep out gpio thing , i have a power problem on artemis |
| 09:05.05 | tmzt | cr2: google's? |
| 09:05.15 | cr2 | in wince the rows are using the gpio irqs |
| 09:05.32 | maejrep | my keypad driver uses irq |
| 09:05.41 | cr2 | ok |
| 09:05.42 | maejrep | but doesn't have any meaningful key assignments currently |
| 09:05.47 | tmzt | it's using the generic gpio_matrix isn't it? |
| 09:05.50 | maejrep | yes |
| 09:06.09 | tmzt | there's no hw scanning like on pxa is there? |
| 09:06.13 | maejrep | but it needs to combine the i2c cap sensor data with left and right, to determine which of the left and right buttons are being pressed |
| 09:06.24 | cr2 | BabelO_: do you have working gsm on arte ? |
| 09:06.27 | maejrep | it uses gpio_event_matrix (or w/e) |
| 09:06.39 | maejrep | it doesn't manually scan any of it |
| 09:06.42 | tmzt | w/e ? |
| 09:06.48 | cr2 | maejrep: it's not a kernel issue |
| 09:07.04 | tmzt | it has to scan the outputs doesn't it? |
| 09:07.13 | tmzt | (by scan I mean cycle through) |
| 09:07.26 | maejrep | cr2, what's "it" |
| 09:07.31 | cr2 | tmzt: it's impleneted in hw on pxa |
| 09:07.52 | maejrep | tmzt, whatever it's doing, is being done by gpio_event_matrix: |
| 09:07.54 | maejrep | static struct gpio_event_matrix_info halibut_matrix_info = { |
| 09:07.54 | maejrep | <PROTECTED> |
| 09:07.54 | maejrep | <PROTECTED> |
| 09:07.54 | maejrep | <PROTECTED> |
| 09:07.54 | maejrep | <PROTECTED> |
| 09:08.16 | cr2 | maejrep: combining the 2 input devices, and doing some correlation analysis |
| 09:08.26 | maejrep | correlation for what? |
| 09:08.40 | cr2 | [10:06] <maejrep> but it needs to combine the i2c cap sensor data with left and right |
| 09:08.45 | maejrep | right |
| 09:08.56 | maejrep | I can already tell if I'm on home/send/back/end by looking at the i2c data |
| 09:09.21 | cr2 | ok, but it's not the kernel driver business |
| 09:09.31 | cr2 | imvho :) |
| 09:10.02 | BabelO_ | cr2: i m on it :) Motorola opensource website has published source code from TI for syren spi battery / sound / gsm |
| 09:10.39 | cr2 | BabelO_: that sounds very good |
| 09:11.05 | maejrep | cr2, you mean the kernel driver shouldn't take the data from each and trigger a key event based on upper/lower portion of the key cap? |
| 09:11.12 | Mullins | dcordes: If I want to see the printk in tsc2003.c using angstrom.cpio, what must I do? |
| 09:12.15 | *** join/#htc-linux rmoravcik1 (n=rmoravci@gtsgw.ttc.cz) |
| 09:12.27 | cr2 | maejrep: it's a policy decision for me, and the kernel should not do policy decision |
| 09:12.50 | dcordes | Mullins: you just boot to the console and login |
| 09:12.58 | maejrep | so it should just expose the two devices independently, and have an X driver correlate the data into key events? |
| 09:13.01 | Mullins | dcordes: yes, have done |
| 09:13.29 | Mullins | dcordes: touch the screen and I should see the messages? |
| 09:13.51 | dcordes | if the touch events has printks, yes |
| 09:14.03 | cr2 | maejrep: i think yes, because it's a rather arbitrary decision |
| 09:14.21 | maejrep | yeah, I see your point |
| 09:14.52 | maejrep | makes it more complex ;p but a good point |
| 09:14.57 | Mullins | dcordes: KERN_INFO or KERN_ALERT should not matter? |
| 09:14.57 | dcordes | Mullins: have you seen the commit? |
| 09:15.06 | BabelO_ | cr2: it is the big missing csmi driver with the tipbd bus exchange to speak between the too arm processor |
| 09:15.52 | dcordes | Mullins: maybe only alert and error show on the fbcon? |
| 09:16.14 | cr2 | dcordes: should haret support tracing the arm9 gpios on msm ? |
| 09:17.29 | dcordes | cr2: why not |
| 09:17.37 | cr2 | dcordes: looking at the raph500 spl yesterday, i think that the wiki gpio function list is more of less complete |
| 09:17.57 | cr2 | because then you need to check the owner bits |
| 09:18.42 | cr2 | and have 2 gpio register locations per gpio, which are only masked by the owner mask |
| 09:19.03 | cr2 | which adds complexity. |
| 09:19.35 | cr2 | maybe we can ignore the arm11 gpio tracing |
| 09:19.42 | dcordes | let's look at the owner bits first |
| 09:20.05 | cr2 | as swetland said, the arm9 gpio register locations are the "real" locations |
| 09:20.30 | cr2 | it's all documented |
| 09:21.04 | cr2 | the arm9 gpios are 'empty' in the raphaelGPIO list |
| 09:21.05 | cr2 | we don't know their purpose |
| 09:21.31 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 09:21.36 | cr2 | maybe one if them is controlling the vibra ;) |
| 09:22.51 | dcordes | NetRipper: mentioned raphael vibra the other day |
| 09:23.16 | cr2 | via proc_comm |
| 09:23.47 | cr2 | btw, can we grep the vogue tree for all proc_comm usage ? |
| 09:24.01 | cr2 | and put it into wiki ? |
| 09:24.41 | cr2 | bbl |
| 09:24.48 | maejrep | yeah, msm_proc_comm_wince() can control the vibra now cr2 :) |
| 09:26.58 | tmzt | should we be able to talk to the atmel with spi as well or only when loading firmware? |
| 09:28.57 | jerry507_mac | It's possible |
| 09:29.37 | jerry507_mac | Does the firmware get loaded every time? |
| 09:36.56 | *** join/#htc-linux dream_kill (n=nospam@92.56.48.66) |
| 09:39.22 | *** join/#htc-linux Guest92758 (n=nospam@92.56.48.66) |
| 09:59.26 | lupine_85 | sight test fini :) |
| 09:59.43 | dream_kill | hi |
| 10:00.08 | lupine_85 | heya |
| 10:03.38 | dream_kill | any new progress on raph100 yet? |
| 10:06.17 | lupine_85 | work on i2c... |
| 10:06.24 | lupine_85 | which is nice :) |
| 10:09.25 | dream_kill | any tests i can do here :P ? |
| 10:19.16 | XD | woo |
| 10:19.31 | XD | so I'm trying to get andriod on my touch pro |
| 10:20.28 | XD | I got it running, sort of gimped, colors are off. anyone know how to do this correctly? |
| 10:23.06 | lupine_85 | XD: known problem with some models (diam/raph800?) |
| 10:24.30 | XD | I see |
| 10:24.42 | XD | ya, cause a see a few people saying they got it going |
| 10:24.53 | XD | I've got a raph |
| 10:28.03 | maejrep | XD, sprint? |
| 10:28.30 | maejrep | cr2/tmzt/lupine_85: http://wiki.xda-developers.com/index.php?pagename=Raphael_I2C_Navi |
| 10:28.35 | maejrep | kinda rough still |
| 10:28.42 | maejrep | can't quite make out what everything should be |
| 10:30.31 | *** join/#htc-linux myxor (n=myxor@pdbn-4d089055.pool.mediaWays.net) |
| 10:30.54 | maejrep | i can get it to detect 3 individual sections of the key cap simultaneously :p |
| 10:31.12 | lupine_85 | cool |
| 10:31.23 | maejrep | it might be able to detect all 4 sections simultaneously, but can't quite trigger that so far |
| 10:31.32 | lupine_85 | so one could do all manner of complicated multipress stuff? :) |
| 10:31.53 | maejrep | yeah :D |
| 10:32.58 | XD | majrep verizon |
| 10:33.00 | maejrep | yes :D it can pick up all 4 |
| 10:33.11 | maejrep | XD, that's raph500 then, but also known to have some color issues |
| 10:33.21 | maejrep | <PROTECTED> |
| 10:33.21 | maejrep | 00: 00 ff 43 43 00 00 31 32 1c d8 06 01 00 00 00 82 ..CC..12????...? |
| 10:33.21 | maejrep | 10: 00 20 8b . ? |
| 10:33.34 | maejrep | shows byte 1 having ff (all 4 sections active) |
| 10:33.41 | XD | ah |
| 10:34.06 | lupine_85 | so so awesomely cool |
| 10:34.14 | lupine_85 | has no spare time this weekend |
| 10:34.26 | lupine_85 | (but not :( since I'm spending it avec people :) ) |
| 10:36.18 | maejrep | what are you trying to say?? |
| 10:36.20 | maejrep | ;p |
| 10:37.13 | XD | heh |
| 10:37.18 | lupine_85 | that I2C bit-banging isn't as fun as real banging? :p |
| 10:37.27 | lupine_85 | hides |
| 10:39.53 | maejrep | hmm, still some inconsistencies with some of these values |
| 11:01.09 | *** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net) |
| 11:07.15 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
| 11:13.53 | NetRipper | maejrep, why'd you remove the wiki page again? |
| 11:14.02 | maejrep | sorry, I moved it: http://wiki.xda-developers.com/index.php?pagename=Raphael_Navi |
| 11:14.11 | NetRipper | ah |
| 11:54.12 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 12:24.01 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 12:25.14 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 12:42.14 | *** join/#htc-linux exco (n=exco@e181079020.adsl.alicedsl.de) |
| 12:43.29 | *** join/#htc-linux daspsycho (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
| 12:47.00 | *** join/#htc-linux gmarzioz (n=gmarzioz@host60-41-dynamic.61-82-r.retail.telecomitalia.it) |
| 12:49.43 | *** join/#htc-linux Heema (n=Heema@217.139.57.79) |
| 13:07.18 | gmarzioz | hi |
| 13:07.35 | gmarzioz | i have a blueangel |
| 13:08.12 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B0340AC.dip.t-dialin.net) |
| 13:08.25 | gmarzioz | what kernel ??? |
| 13:09.53 | gmarzioz | for qtopia ?? |
| 13:13.25 | *** join/#htc-linux kiozen (n=oeichler@p5492A476.dip0.t-ipconnect.de) |
| 13:16.50 | *** join/#htc-linux imfloflo (i=5bcfd11d@gateway/web/ajax/mibbit.com/x-3c1e32bbf4a9d963) |
| 13:25.00 | *** join/#htc-linux kiozen (n=oeichler@p5492A476.dip0.t-ipconnect.de) |
| 13:32.39 | *** join/#htc-linux Relaed (n=knarfytr@FLH1Aat058.oit.mesh.ad.jp) |
| 13:36.30 | *** part/#htc-linux Relaed (n=knarfytr@FLH1Aat058.oit.mesh.ad.jp) |
| 13:41.13 | *** join/#htc-linux piusvelte (n=chatzill@nat.philau.edu) |
| 13:43.24 | *** join/#htc-linux kiozen (n=oeichler@p5492A476.dip0.t-ipconnect.de) |
| 13:55.01 | gmarzioz | hi |
| 13:55.34 | gmarzioz | there are some one that use a blueangel?? |
| 13:58.13 | DJWillis | gmarzioz: tried the old images from http://www.linuxtogo.org/~htcpxa/htcblueangel/? Been a while since I built for a BlueAngel |
| 14:01.00 | gmarzioz | yes |
| 14:01.05 | gmarzioz | i tried that |
| 14:01.32 | gmarzioz | i'm looking for an image whit wireless |
| 14:01.45 | gmarzioz | it don't work in that |
| 14:02.23 | tsdogs | afair there was wifi support in hh.org kernel done by BabelO, and thoose images should have it included (at least Qtopia) |
| 14:03.07 | gmarzioz | where i can find the last images |
| 14:03.08 | gmarzioz | ?? |
| 14:04.16 | DJWillis | gmarzioz: I have to say I assumed http://www.linuxtogo.org/~htcpxa/htcblueangel/Qtopia/SDInstall/ had WiFi in it. |
| 14:05.00 | *** join/#htc-linux Kensan_ (n=ken@gw.ptr-80-238-170-4.customer.ch.netstream.com) |
| 14:05.58 | gmarzioz | but not work |
| 14:06.27 | gmarzioz | the battery don't charge and the keyboard don't work |
| 14:06.36 | gmarzioz | bien |
| 14:06.38 | gmarzioz | !! |
| 14:07.14 | DJWillis | gmarzioz: is building your own kernel an option? |
| 14:08.00 | gmarzioz | i'm download the kernel and untar in sd |
| 14:08.24 | gmarzioz | and the qtopia linux.exe don't work |
| 14:09.02 | gmarzioz | i'm tried with haret.exe |
| 14:09.18 | gmarzioz | and work |
| 14:13.48 | *** join/#htc-linux addman3333 (n=skool@cpe-67-9-134-92.austin.res.rr.com) |
| 14:14.31 | *** join/#htc-linux kim0 (n=kim@s559116c1.adsl.wanadoo.nl) |
| 14:43.44 | dcordes | lupine_85: did you see the j0b0 X post? |
| 14:56.45 | lupine_85 | dcordes: last night? yes |
| 14:57.27 | lupine_85 | turning off the vkeyb doesn't fix the android loading issues, so I suspect the refresh bug (or some variant thereof) has been introduced between two kernels that I have |
| 14:57.42 | lupine_85 | erm, X |
| 14:57.44 | lupine_85 | not android |
| 14:58.18 | *** join/#htc-linux lifegrasp (n=ckonkel@63.254.171.226) |
| 15:04.52 | *** join/#htc-linux metter (n=metter@237-74.0-85.cust.bluewin.ch) |
| 15:08.47 | *** join/#htc-linux _4nakin (n=Tuan@115.76.134.252) |
| 15:17.06 | *** join/#htc-linux zule (n=zule@shadowmite.com) |
| 15:25.09 | *** join/#htc-linux MethoS- (n=clemens@host-091-097-245-045.ewe-ip-backbone.de) |
| 15:27.59 | *** join/#htc-linux Heema (n=Heema@217.139.57.79) |
| 15:30.36 | *** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com) |
| 15:41.42 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 15:43.33 | *** join/#htc-linux timebomb (n=tb@p5B3E6939.dip.t-dialin.net) |
| 15:46.16 | *** join/#htc-linux aljosa (n=aljosa@cheguevara.fsb.hr) |
| 15:46.43 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
| 15:47.53 | aljosa | i have htc tytn, where can i find more info on GSM/3G status - is there any chance that i will be able to call other people from linux 8-) |
| 15:48.22 | lupine_85 | yay, I have the server |
| 15:48.30 | lupine_85 | requires new discs installing, but is otherwise good |
| 15:48.55 | lupine_85 | will just be careful to backup in the meantime :) |
| 15:54.04 | *** part/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 16:04.03 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87d0b4.pool.einsundeins.de) |
| 16:07.19 | *** join/#htc-linux infernixx (i=nix@unaffiliated/infernix) |
| 16:33.58 | *** join/#htc-linux MethoS (n=clemens@host-091-097-245-045.ewe-ip-backbone.de) |
| 16:40.30 | dcordes | j0b0: are you here? |
| 16:40.42 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 16:42.53 | AstainHellbring | morning |
| 16:45.44 | zycho | hi |
| 16:46.01 | AstainHellbring | hi |
| 16:49.10 | dcordes | morning AstainHellbring |
| 16:49.17 | AstainHellbring | hi dcordes whats new? |
| 16:49.29 | zycho | #include <hate.h> |
| 16:51.01 | dcordes | AstainHellbring: nothing new here. did you see the latest dzo commit? |
| 16:51.11 | AstainHellbring | no I didnt what did it include? |
| 16:51.46 | *** join/#htc-linux br1ck (n=br1ck@xdslcg016.osnanet.de) |
| 16:54.03 | dcordes | AstainHellbring: keyboard touchscreen etc. I'm building it right now. hope smd works |
| 16:54.16 | AstainHellbring | nice |
| 16:54.57 | dcordes | oops I think he removed arch/arm/mach-msm/AudioPara.c by accident |
| 16:55.05 | AstainHellbring | oh oh |
| 17:06.55 | AstainHellbring | dcordes how up to date is the wiki on functionality of the latest efforts? |
| 17:09.37 | *** part/#htc-linux yoyey (n=yoann@bro69-3-82-237-160-83.fbx.proxad.net) |
| 17:09.40 | dcordes | kaiser one? |
| 17:11.41 | dcordes | ok smd doesn't work yet |
| 17:12.52 | dcordes | I think receive does but not send |
| 17:13.43 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
| 17:15.18 | dcordes | oh cool. kaiser powers down after shutdown with the dzo kernel |
| 17:18.18 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 17:25.54 | AstainHellbring | no I was referring to raph stuffs |
| 17:25.56 | AstainHellbring | whats smd do? |
| 17:27.21 | AstainHellbring | but kaiser does still interest me as I have one of those sitting around too |
| 17:29.53 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 17:30.09 | AstainHellbring | morning cr2 |
| 17:30.11 | *** join/#htc-linux Miek (n=mike@unaffiliated/mikechml) |
| 17:30.21 | cr2 | hi AstainHellbring |
| 17:30.55 | AstainHellbring | how goes it cr2? |
| 17:31.04 | cr2 | dcordes: i have documented a lot of things (hardcopy), but can't edit wiki ;) |
| 17:31.26 | dcordes | I can sure do that. |
| 17:31.39 | cr2 | dcordes: the A0/A4 calculation is the same for all msm7x0xX cpus |
| 17:31.44 | cr2 | but |
| 17:31.52 | dcordes | the power management code from vogue seems to work on kaiser since it can power off with the vogue kernel |
| 17:32.05 | cr2 | some frequences are missing on less advanced phones |
| 17:32.27 | cr2 | like titan,kaiser |
| 17:32.29 | dcordes | lass advanced means lacking components or you mean the non-A ? |
| 17:32.40 | dcordes | so the non-As |
| 17:32.52 | cr2 | raph100 and bstone are most advanced |
| 17:33.06 | cr2 | raph800 uses SD >2 |
| 17:33.10 | dcordes | and x1 |
| 17:33.21 | cr2 | diam100 does not have 48MHz mode |
| 17:33.33 | dcordes | what's 48MHz ? |
| 17:33.43 | cr2 | titan does not have 12 and 24MHz mode, only 19MHz |
| 17:33.51 | cr2 | SD bus speed |
| 17:34.22 | cr2 | dcordes: that means that vogue will have the same formula too |
| 17:34.57 | dcordes | AstainHellbring: raph wiki is pretty uptodate afaik |
| 17:35.18 | cr2 | dcordes: can you recursively grep the vogue git for all proc_comm instances ? |
| 17:35.41 | cr2 | btw, the accelerometer uses 2 undocumented i2c registers |
| 17:36.10 | cr2 | i don't know if it's critical, probably not |
| 17:36.28 | cr2 | still, htc has different datasheet from those in the inet ;) |
| 17:36.45 | dcordes | inet seems to have many datasheets now |
| 17:37.22 | dcordes | greping |
| 17:37.38 | lupine_85 | sometimes, I hate ruby |
| 17:37.46 | cr2 | i have documented a lot of atmel microcontroller functions, maejrep will be happy |
| 17:38.49 | cr2 | lupine_85: 19 more register locations for atmel 0xcc aka KLT1 |
| 17:39.22 | cr2 | lupine_85: 3 more locatrions for 0xce aka KSC1 |
| 17:40.03 | cr2 | there are some good hints what they are doing, but it's still a lof of testing behind. |
| 17:41.16 | lupine_85 | good stuff. if only I had time :D |
| 17:41.27 | lupine_85 | well, I've negotiated some geek time this weekend |
| 17:41.30 | lupine_85 | so we'll see |
| 17:41.41 | dcordes | cr2: http://privatepaste.com/770dmA3hOG |
| 17:41.45 | dcordes | pc usage |
| 17:41.48 | lupine_85 | 19 for the light seems a bit insane though |
| 17:41.52 | lupine_85 | *shrug* |
| 17:44.31 | kiozen | hi cr2 |
| 17:44.41 | kiozen | do you have a nice wms server for me? |
| 17:44.50 | *** join/#htc-linux Sparky_ (n=maik@77.20.236.81) |
| 17:45.39 | cr2 | kiozen: the _really_ nice one is behind the firewall ;) |
| 17:46.36 | kiozen | yes I know |
| 17:46.42 | kiozen | the free ones I find are cheesy |
| 17:46.57 | cr2 | ./arch/arm/mach-msm/pm.c: msm_proc_comm(0x14, 0, 0); |
| 17:46.57 | cr2 | this one is missing in my list |
| 17:47.05 | cr2 | kiozen: what are you doing on the weekend ? |
| 17:47.17 | kiozen | getting cold feet |
| 17:47.29 | cr2 | lol |
| 17:48.08 | kiozen | you need a beer? |
| 17:48.36 | cr2 | why not :) |
| 17:48.42 | dcordes | bbl |
| 17:48.50 | cr2 | msm_proc_comm(0x5,0,0xb22); |
| 17:48.50 | cr2 | 0xb22 is some weird arefact |
| 17:48.57 | kiozen | I think I have free from family saturday noon to sunday noon |
| 17:50.09 | BabelO | kiozen: , cr2: grrrrhh i want beer too |
| 17:50.09 | cr2 | ./arch/arm/mach-msm/vogue-hw.c: printk("proc_comm(%x,%x)",v1,v2); |
| 17:50.18 | cr2 | this one matches wince btter |
| 17:50.22 | kiozen | BabelO: you are welcome to join ;) |
| 17:51.01 | cr2 | BabelO: i can pick you in the munich airport on the way to kiozen :) |
| 17:51.46 | BabelO | cr2: i ve one hour to travell to marseille to took a plane :) maybe it is too late |
| 17:52.04 | cr2 | lol |
| 17:52.08 | cr2 | ./arch/arm/mach-msm/vogue-ts.c: msm_proc_comm(0x11f,1,0); // set charger status=1 |
| 17:52.20 | kiozen | BabelO: tomorrow evening, not today |
| 17:52.25 | cr2 | i have |
| 17:52.27 | cr2 | 5c 2=0x1f unregister vocoder pcm |
| 17:53.38 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 17:54.20 | cr2 | ./arch/arm/mach-msm/board-htcvogue.c: msm_proc_comm(0x116,0x200,0); |
| 17:54.31 | cr2 | this one looks like vreg |
| 17:54.50 | kiozen | cr2: you still got my number? |
| 17:55.03 | cr2 | 0x200 is 2.85V in my list |
| 17:55.49 | cr2 | kiozen: hmm. i need to look for my phone. i've lost the paper slip with the PUK, so i have some problems now |
| 17:56.27 | cr2 | because raph100 "auto" entered my pin, and locked out the sim card |
| 17:56.32 | BabelO | kiozen: svn up or not ? |
| 17:56.37 | cr2 | fucking wince 6.1 |
| 17:56.43 | cr2 | that's all what i can say ;) |
| 17:56.48 | kiozen | no, just the xml |
| 17:57.01 | kiozen | 20cm sat data from johannisburg |
| 17:57.19 | kiozen | cr2: old email still working? |
| 17:57.41 | cr2 | yes, but i don't have the working phone. |
| 17:58.01 | kiozen | lol, you are pretty offline these days |
| 17:58.29 | cr2 | yeah |
| 17:59.07 | cr2 | and i need to buy an umts flatrate tmob sim card |
| 17:59.44 | BabelO | kiozen: 447 eur to come for next week end :) |
| 18:00.10 | kiozen | wow, think how many copter yu can buy :) |
| 18:00.43 | cr2 | BabelO: then it's cheaper to drive |
| 18:01.02 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 18:01.56 | BabelO | cr2: no some are around 200 eur , it cost more with only the highway :) |
| 18:05.22 | cr2 | kiozen: ok, so what do you suggest ? |
| 18:05.48 | kiozen | depends if you want to stay overnight or not :) |
| 18:06.21 | kiozen | and if you just want to drink a beer or have a look at the loox too |
| 18:06.53 | cr2 | i can do everything :) |
| 18:06.59 | kiozen | anyway I would recommend some light hacking on the loox in the afternoon |
| 18:07.12 | kiozen | a nice dinner in the evening |
| 18:07.21 | cr2 | ok, so when should i come ? |
| 18:07.34 | kiozen | 14:00 |
| 18:07.40 | kiozen | that's ok? |
| 18:07.57 | cr2 | on sunday ? |
| 18:08.08 | kiozen | saturday |
| 18:09.10 | kiozen | om sunday afternoon my wife will escape for her lectures |
| 18:09.26 | kiozen | she has exams in a few weeks |
| 18:09.29 | cr2 | maybe a bit later ? |
| 18:09.32 | kiozen | ok |
| 18:09.39 | kiozen | what best for you? |
| 18:09.46 | cr2 | i'd like to make a short stop in münchen too |
| 18:10.12 | cr2 | 15:00-16:00 |
| 18:10.38 | kiozen | ok |
| 18:10.50 | cr2 | good. |
| 18:10.59 | kiozen | at my home |
| 18:11.09 | cr2 | ok |
| 18:11.13 | kiozen | we can go to office from there |
| 18:11.51 | cr2 | ok. |
| 18:12.04 | cr2 | the key issue for me is to dump the n560 spl from mdoc |
| 18:12.28 | kiozen | ok |
| 18:12.39 | cr2 | or get it from the net, but i've not seenit anywhere. |
| 18:12.50 | kiozen | let's see |
| 18:13.31 | kiozen | spl first, then beer :D |
| 18:13.41 | cr2 | lol |
| 18:14.32 | kiozen | ok dinner, bbl |
| 18:23.25 | *** join/#htc-linux Rogro82 (n=rogro82@s5591104d.adsl.wanadoo.nl) |
| 18:31.25 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfc95a.pool.einsundeins.de) |
| 18:34.29 | *** join/#htc-linux DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) |
| 18:45.51 | *** join/#htc-linux metter_ (n=metter@24-81.1-85.cust.bluewin.ch) |
| 18:57.22 | *** join/#htc-linux Zinbolic (n=Zy@84.238.80.215) |
| 19:03.30 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 19:08.03 | *** join/#htc-linux dcordes_ (n=dcordes_@unaffiliated/dcordes) |
| 19:08.21 | dcordes_ | cr2 where's the data to be added to the wiki? |
| 19:12.45 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 19:15.33 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 19:19.22 | cr2 | dcordes_: hardcopy now |
| 19:21.25 | cr2 | dcordes_: let's fix the gpio area page |
| 19:27.15 | maejrep[w] | what needs fixing? |
| 19:29.41 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 19:30.18 | cr2 | http://wiki.xda-developers.com/index.php?pagename=RaphaelMemoryMapPg2 |
| 19:30.35 | cr2 | gpio_conf2 and gpio_conf1 |
| 19:30.39 | dream_kill | hi |
| 19:31.58 | cr2 | maejrep[w]: all bracketed addresses are arm9, and are real. the brackets ans ? for gpio_conf2 can be removed |
| 19:36.41 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 19:41.46 | *** join/#htc-linux skool (n=azachars@nat/sun/x-a7e2de5b14e3ec08) |
| 19:58.17 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 20:00.15 | cr2 | maejrep[w]: still here ? |
| 20:00.35 | maejrep[w] | vaguely |
| 20:00.40 | maejrep[w] | (at [w] :p) |
| 20:01.09 | cr2 | :) |
| 20:01.55 | tmzt | is the keyboard through the atmel chip or is that a different i2c addr? |
| 20:06.37 | cr2 | tmzt: atmel. 0xce |
| 20:06.39 | maejrep[w] | it is |
| 20:07.16 | dcordes_ | the non hsusb seems like complicated thing |
| 20:07.34 | cr2 | ce,10,2,x |
| 20:07.46 | cr2 | ce,11,2,x |
| 20:07.54 | cr2 | ce,12,2,x |
| 20:08.01 | cr2 | ce,13,2,x |
| 20:08.05 | *** join/#htc-linux puregenius (n=dsa@brln-4d0ccbe7.pool.mediaWays.net) |
| 20:08.14 | cr2 | these for read |
| 20:08.34 | tmzt | same for all raph's? |
| 20:08.39 | cr2 | ce,13,... keymiscval for write |
| 20:09.02 | tmzt | and that's a matrix with 1,0 1,1 1,2 etc? |
| 20:09.05 | cr2 | yes, i guess it's inside the firmware |
| 20:09.47 | cr2 | maejrep[w]: can you i2cdump the 0xce ? |
| 20:10.20 | cr2 | tmzt: it's not a matrix |
| 20:10.50 | cr2 | id,reg,size,*val |
| 20:10.55 | cr2 | i think |
| 20:13.39 | *** join/#htc-linux puregenius (n=chatzill@brln-4d0ccbe7.pool.mediaWays.net) |
| 20:13.49 | maejrep[w] | cr2: I get weird results.. either all XX's or all "06" |
| 20:13.58 | maejrep[w] | im' sure it needs to be initialized |
| 20:14.06 | maejrep[w] | or requested differently |
| 20:14.15 | dcordes_ | BabelO ping |
| 20:14.43 | tmzt | 0xce is the i2c address but it's also implemented by the same atmel chip? |
| 20:14.54 | cr2 | maejrep[w]: can you add mmutrace on the i2c r/w and press a keyboard key ? |
| 20:15.11 | cr2 | tmzt: it's all implemented in firmware (my guess) |
| 20:15.52 | tmzt | maejrep[w]: have you run a full i2cdetect on the bus? |
| 20:17.21 | maejrep[w] | tmzt: still through the i2c-msm bus |
| 20:17.29 | maejrep[w] | whether that's the same chip or not I couldn't tell you |
| 20:17.39 | maejrep[w] | I don't think I did ? |
| 20:18.34 | maejrep[w] | yeah, based on the results of the navi tests, its very clearly not just a raw input with coordinates, so the chip is definitely aggregating the data to the interface |
| 20:18.38 | tmzt | i2cdetect -a 0/1 |
| 20:18.59 | tmzt | take awhile and you need to redirect it to a file (it's long) |
| 20:19.28 | maejrep[w] | I'm at work, but I'll see if usbnet is setup on this pc |
| 20:20.32 | cr2 | tmzt: there are 3 "chips" 0xc4 (tpd), 0xcc(klt1) and 0xce(ksc1) |
| 20:20.46 | tmzt | ok |
| 20:21.08 | tmzt | what are those? tpd, kltl, ksc1 |
| 20:21.18 | tmzt | let me look at navi wiki |
| 20:21.39 | cr2 | http://wiki.xda-developers.com/index.php?pagename=RaphaelPSOC |
| 20:21.56 | cr2 | but i need to make big changes to this page |
| 20:22.14 | tmzt | so your naming them after the ce devices? |
| 20:23.02 | tmzt | diams don't have this chip at all do they? |
| 20:23.07 | cr2 | dcordes: i guess working wifi is a better option |
| 20:24.18 | cr2 | tmzt: tpd is capacitive navi sensor, klt1 is led and backlight and adc (luminosity) , and ksc1 is keyboard |
| 20:24.53 | cr2 | dcordes: and for wifi we need the SD clock set properly, and the vreg powered up. |
| 20:25.14 | tmzt | cr2, where do we get the eeprom data to send to wifi? |
| 20:25.42 | cr2 | dcordes: we may invert the SD formula, to get the "haret" 7 params |
| 20:25.51 | cr2 | tmzt: on the nand |
| 20:26.21 | cr2 | tmzt: diam does not have 0xce, but must have 0xcc and 0xc4 |
| 20:26.23 | tmzt | so we should add the capability to haret to do that and pass as atag like on g1 or access it from linux? |
| 20:27.00 | cr2 | tmzt: dd it from nand to /lib/firmware/* |
| 20:27.07 | tmzt | I mean does diam have the physical atmel chip? |
| 20:27.24 | cr2 | tmzt: i think that the fw1251.bin is in \windows too |
| 20:27.28 | tmzt | can we safely implement ro mtd? |
| 20:27.43 | tmzt | I don't mean firmware I mean calibration data |
| 20:27.46 | dcordes_ | there are 3 modesf or msmsdcc |
| 20:27.52 | cr2 | ro mtd should be possible |
| 20:27.59 | dcordes_ | bt, wifi, undefined |
| 20:28.14 | dcordes_ | for the sdc2 |
| 20:28.16 | tmzt | also sdio is using the 24mhz clock with 8bit bus? |
| 20:28.23 | cr2 | dcordes_: hehe. sd and mmc ? |
| 20:28.46 | cr2 | tmzt: it depends on the clock divisors. i don't remember now. |
| 20:29.14 | cr2 | tmzt: usually you start at 144kHz and ask the device anout the type, voltage and speed. |
| 20:29.41 | tmzt | ok, it's just you said titan/vogue don't have 48mhz which I assumed was for sdio |
| 20:30.02 | tmzt | are we any closer on dma for sdcc |
| 20:30.05 | cr2 | 48MHz is for SD2.0 |
| 20:30.37 | cr2 | titan/vogue have 144kHz and 19MHz only |
| 20:30.45 | cr2 | at least in wince |
| 20:31.02 | cr2 | i don't know where/how dzo has picked his values |
| 20:31.35 | dcordes_ | cr2 I don't know what that mode does but I thinkf or wifi one should setwifi mode |
| 20:31.41 | cr2 | i have compared all spls and sdhc drivers, and they all have the same divisor algorithm. |
| 20:32.13 | cr2 | dcordes_: i think something like that is documented in wiki |
| 20:32.22 | cr2 | dcordes_: at least for sd mode. |
| 20:32.30 | dcordes_ | tmzt did you see the youngest commits in htc-vogue? I tried it on the kaiser. sds eems to work well |
| 20:33.08 | dcordes_ | and it powered off |
| 20:33.09 | tmzt | dcordes_: vogue/titan/kaiser/polaris are all in htc-vogue now? |
| 20:33.18 | cr2 | +0x218 =0 sd |
| 20:33.18 | dcordes_ | yes |
| 20:33.27 | maejrep[w] | brb, gotta reboot |
| 20:33.46 | cr2 | dcordes_: b3100000 a9000000 1 GPIO_CONF1, DEX'd |
| 20:34.08 | dcordes_ | we only need to add the non hsusb and wifi, bt |
| 20:34.57 | tmzt | is it possible only the ulpi part of the usb is different, that would explain the different IP wouldn't it? |
| 20:35.03 | cr2 | dcordes_: bt is not using sdio. imho |
| 20:35.14 | maejrep[w] | I don't think it does |
| 20:35.35 | tmzt | bt mode might be wifi interoperation |
| 20:35.49 | tmzt | where are these modes? |
| 20:36.16 | dcordes_ | somebody said it. can't remember |
| 20:36.40 | *** join/#htc-linux sensorama (n=apan@c-9f06e155.910-1-64736c14.cust.bredbandsbolaget.se) |
| 20:36.53 | tmzt | dcordes_: do you mean the cpld commit? this enables poweroff on kaiser? |
| 20:37.03 | cr2 | dcordes_: i'll try to add the clock divisor to wiki |
| 20:38.05 | tmzt | writel(0, A11S_PWRDOWN); does this really write to 0? |
| 20:38.10 | dcordes_ | tmzt uhm I think it's the vogue-pm code |
| 20:38.17 | *** join/#htc-linux timebomb (n=tb@e182092241.adsl.alicedsl.de) |
| 20:39.35 | cr2 | dcordes_: from your grep i don't see any real vreg management. only the 0x200 bit |
| 20:39.36 | tmzt | dcordes_: if kaiser fully supports qwerty keyboard can we disable vkeyb on there now? |
| 20:40.56 | tmzt | someone was saying yesterday that the touchscreen wasn't working and I can't see how that was a kernel issue unless they meant the confusing calibration procedure for vkeyb |
| 20:41.04 | tmzt | (but that was titan though) |
| 20:43.31 | *** join/#htc-linux mdrobnak (n=mdrobnak@ip67-152-2-193.z2-152-67.customer.algx.net) |
| 20:43.56 | camden | hi guys. great work so far! thanks for all your efforts! |
| 20:45.21 | dcordes_ | tmzt dzo added ts2003.c for kais now |
| 20:45.43 | mdrobnak | Hey dcordes_ - any new kernels for the Raph? |
| 20:45.56 | tmzt | why is the battery reading in the ts driver? it's on tsc2003 but is it registered as a battery device? |
| 20:46.39 | dcordes_ | idk |
| 20:48.33 | tmzt | added tsc2003.c from where? |
| 20:49.46 | tmzt | that's the cooked driver |
| 20:50.14 | cr2 | tmzt: it's android ;) |
| 20:50.39 | tmzt | android still needs it's data like that? |
| 20:51.30 | tmzt | kcalloc? |
| 20:52.16 | dcordes_ | tmzt your ts2003.c patch that allows tslib is in no git |
| 20:52.23 | dcordes_ | I'll bbl |
| 20:52.58 | tmzt | there is no generic tsc2003 driver that would work for raw/tslib, why do we need one in arch-msm ? |
| 20:54.35 | radem205 | Is it right that Haret completely disable windows mobile when running? |
| 20:54.42 | cr2 | tmzt: this whole msm code is a hck |
| 20:54.55 | tmzt | radem205: yes, when used to boot linux |
| 20:55.14 | tmzt | radem205: but haret also disables ce interrupts at times |
| 20:55.26 | cr2 | radem205: there is nothing to disable after haret |
| 20:56.05 | tmzt | cr2: ok, but can we at least get a CONFIG options for VKEYB and ANDROID_TOUCHSCREEN or something like that |
| 20:58.58 | cr2 | tmzt: http://wiki.xda-developers.com/index.php?pagename=RaphaelPSOC |
| 20:59.03 | cr2 | tmzt: editing at 9600 is not fun ;) |
| 20:59.15 | zule | any apache guys able to tell me how to get apache to treat index.php as php and not text? if I don't specify the file, it finds it and runs it as php... |
| 21:04.49 | mdrobnak | zule: Is this a hosted solution, or your own server? |
| 21:05.09 | zule | my own dedicated server |
| 21:06.24 | mdrobnak | <PROTECTED> |
| 21:06.45 | mdrobnak | and my DirectoryIndex contains index.php |
| 21:06.57 | mdrobnak | But this really isn't the right channel for this..... |
| 21:07.28 | zule | I know, just you guys are linux literate and not swamped with newb's asking questions |
| 21:07.30 | zule | hehe |
| 21:07.48 | zule | umm, the addtype in what file? httpd.conf? |
| 21:07.53 | mdrobnak | yah |
| 21:07.57 | *** join/#htc-linux Magister7 (n=Magister@93.180.223.96) |
| 21:08.00 | zule | the directoryindex is already there |
| 21:08.11 | mdrobnak | Thats how it is on my debian-based box. |
| 21:08.22 | tmzt | did you have #! line on the php? |
| 21:08.31 | mdrobnak | (well, not really, they've got some funky thing set up) |
| 21:08.32 | mdrobnak | no |
| 21:08.38 | tmzt | wondering how it already worked as a directory index |
| 21:08.43 | mdrobnak | yeah thats odd |
| 21:08.55 | mdrobnak | *oops at last response |
| 21:09.00 | zule | I added it to the modules.d php directoryindex line |
| 21:09.01 | mdrobnak | thought it was zule asking about.. |
| 21:09.18 | tmzt | oh sorry |
| 21:09.24 | mdrobnak | (No my fault) |
| 21:09.42 | mdrobnak | zule:What distribution? |
| 21:09.47 | zule | it looks like I'm missing a mime interpretter |
| 21:09.57 | zule | this is all because I finally am upgrading from apache 2.0 to 2.2 |
| 21:09.58 | mdrobnak | Ah. That's possible. |
| 21:10.09 | mdrobnak | Or is it source built? |
| 21:12.09 | zule | a-ha! gentoo's default mime.types does not have php listed |
| 21:12.20 | zule | and apache 2.2 changed to using that by default |
| 21:12.52 | mdrobnak | (Also, I bet you the main page, without the .php, is cached...) |
| 21:14.36 | zule | hrm... still not working |
| 21:15.04 | zule | http://shadowmite.com/blog/index.php |
| 21:15.06 | zule | vs |
| 21:15.10 | zule | http://shadowmite.com/blog/ |
| 21:15.17 | zule | it's backwards from what I would expect |
| 21:17.06 | mdrobnak | Ok, that works. |
| 21:17.08 | mdrobnak | (second link) |
| 21:17.16 | mdrobnak | and so does index.php |
| 21:17.16 | mdrobnak | :-) |
| 21:17.28 | zule | index.php worked for you? |
| 21:17.34 | zule | I hit reload and still can't get it |
| 21:17.50 | mdrobnak | Clear your cache |
| 21:17.52 | mdrobnak | close the browser |
| 21:17.55 | mdrobnak | and try it again. |
| 21:18.07 | *** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl) |
| 21:20.06 | zule | i just tried it on someone elses computer, it doesn't work with index.php at the end |
| 21:20.14 | zule | are you sure you didnt have it cached? |
| 21:20.15 | zule | lol |
| 21:20.27 | mdrobnak | Anyway, as you said, we're working on the CDMA version of the Diamond / Raphael phones too, but not sure of how the framebuffer is coming.. |
| 21:21.04 | tmzt | j0b0 said it's possible the lcd is just inited wrong |
| 21:21.20 | mdrobnak | mdrobnak@mdrobnak-desktop:~$ wget -S http://shadowmite.com/blog/index.php |
| 21:21.20 | mdrobnak | --2009-01-09 16:20:43-- http://shadowmite.com/blog/index.php |
| 21:21.20 | mdrobnak | Resolving shadowmite.com... 69.60.117.188 |
| 21:21.20 | mdrobnak | Connecting to shadowmite.com|69.60.117.188|:80... connected. |
| 21:21.20 | mdrobnak | HTTP request sent, awaiting response... |
| 21:21.21 | mdrobnak | <PROTECTED> |
| 21:21.33 | mdrobnak | <PROTECTED> |
| 21:21.41 | mdrobnak | ~29KB |
| 21:21.44 | cr2 | http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
| 21:22.52 | mdrobnak | Well, a lot of progress is happening on all of the phones, so I'm sure someone will figure it out soon enough |
| 21:24.51 | *** join/#htc-linux madCoder- (n=madCoder@smtp-n.myyearbook.com) |
| 21:24.59 | madCoder- | so i2cdetect is running now |
| 21:25.32 | madCoder- | its timing out on many of the lower ids, so it really is going to take a while |
| 21:25.55 | madCoder- | but I would have expected it to respond with "FAIL" instead |
| 21:26.24 | madCoder- | ie, on id 0x09, it responded with status "MST ACT", which means it didn't reject the command, but after that it started to time out |
| 21:26.29 | tmzt | not sure i2c is really that smart |
| 21:26.56 | tmzt | like those XX you get when reads fail |
| 21:32.00 | madCoder- | yeah i think it's already stopped responded completely |
| 21:33.19 | madCoder- | no, i think i broke i2c-msm :) |
| 21:33.50 | madCoder- | do you suspect that it has more than those 3 ids? |
| 21:34.33 | cr2 | no. |
| 21:34.43 | cr2 | the accelerometer is 0x30 |
| 21:34.50 | cr2 | then 2 cams |
| 21:35.00 | cr2 | don't remmebr the ids |
| 21:35.04 | tmzt | they have to be powered with vreg though? |
| 21:35.09 | tmzt | cameras |
| 21:35.11 | *** join/#htc-linux puregenius (n=chatzill@brln-4d0ccbe7.pool.mediaWays.net) |
| 21:35.28 | cr2 | cams ? i think yes |
| 21:38.29 | cr2 | http://wiki.xda-developers.com/index.php?pagename=RaphaelDEX |
| 21:38.42 | cr2 | knows dex vregs are at the bottom |
| 21:39.00 | cr2 | it's possible to access more through the radio bootloader |
| 21:39.12 | cr2 | and then there is some rpc black magic |
| 21:39.57 | cr2 | i'd like to see where the is the support code located in the radio bootlooader |
| 21:40.06 | cr2 | and how it correlates with the obfuscated g1 code. |
| 21:40.16 | tmzt | cr2 have you looked at the atmel code? |
| 21:40.28 | cr2 | no |
| 21:40.49 | cr2 | tmzt: check the raphaelpsoc page for my new data |
| 21:41.52 | cr2 | ok, it seems that it'd be easy to deriver the 7 params from the A0/A4 contents |
| 21:46.59 | *** join/#htc-linux Heema (n=Heema@217.139.57.79) |
| 21:47.33 | tmzt | what are the 7 params, you said haret params so I assume you mean dumped from ce somewhere |
| 21:50.45 | cr2 | sd clock params |
| 21:50.55 | cr2 | check msm_sdio wiki page |
| 21:53.23 | cr2 | NetRipper: can you dump these ? |
| 21:53.33 | cr2 | <PROTECTED> |
| 21:53.33 | cr2 | <PROTECTED> |
| 21:53.33 | cr2 | <PROTECTED> |
| 21:53.34 | cr2 | <PROTECTED> |
| 21:53.51 | NetRipper | in haret? |
| 21:53.53 | cr2 | #define VIC_REG(off) (MSM_VIC_BASE + (off)) |
| 21:53.58 | cr2 | yes |
| 21:54.51 | cr2 | hm. maybe writing 'dump gpio' in C is not a bad idea after all |
| 21:56.17 | NetRipper | cr2, http://netripper.pastebin.com/m76c137ff |
| 21:56.43 | tmzt | cr2: would devmem2 or similar work? |
| 21:56.51 | tmzt | what do you mean by c? |
| 21:58.17 | cr2 | tmzt: for haret |
| 21:58.28 | cr2 | instead of .py wizardry |
| 21:58.49 | tmzt | dump gpiomfp would be nice for pxa |
| 21:59.06 | cr2 | write it :) |
| 21:59.30 | tmzt | I was looking into what would be neccessary to decode all the alt functions and figure out which parts of the soc are actually used |
| 21:59.41 | NetRipper | what is the mfp part? |
| 21:59.52 | tmzt | the new way of doing pinmux |
| 22:00.22 | NetRipper | ah in regard with the 2 muxed gpios? |
| 22:01.16 | cr2 | NetRipper: the ts irqs are all RE ? |
| 22:01.29 | NetRipper | re? |
| 22:01.57 | cr2 | rising edge |
| 22:02.24 | tmzt | cr2, is it neccessary to clear the gpio from the atmel some how? |
| 22:02.43 | cr2 | tmzt: which one ? |
| 22:02.54 | cr2 | tmzt: i see only 1 reset gpio, that's all |
| 22:03.00 | tmzt | I mean irq |
| 22:03.05 | tmzt | to msm |
| 22:03.11 | NetRipper | cr2, i dont know.. how can i see in haret? |
| 22:03.15 | NetRipper | how they are configured |
| 22:03.33 | cr2 | NetRipper: it's from your data |
| 22:03.58 | mdrobnak | Hey I just saw on the Wiki there's a kernel with "Up" on the keypad mapped as Menu? If so, which one is that? |
| 22:04.00 | NetRipper | its irq 30 |
| 22:04.06 | NetRipper | im unsure how to read the data |
| 22:04.13 | NetRipper | i'll try |
| 22:05.32 | cr2 | NetRipper: we should do the init |
| 22:05.52 | cr2 | NetRipper: and there are 2 possible init options |
| 22:06.04 | NetRipper | cr2, yes, im looking into that.. i also think we need to signal the touchscreen when there's no more data.. |
| 22:06.18 | *** join/#htc-linux balsat3 (n=kll@87.72.13.87) |
| 22:06.25 | NetRipper | cr2, what are the options? |
| 22:07.06 | cr2 | not yet documented |
| 22:07.58 | *** join/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:09.57 | NetRipper | cr2, i mean, which two init options do you see, or do you mean spl vs wince driver? |
| 22:10.13 | *** join/#htc-linux skool (n=azachars@nat/sun/x-98c6936c6cd81677) |
| 22:11.37 | *** join/#htc-linux Moku (n=John@f048230110.adsl.alicedsl.de) |
| 22:11.56 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 22:12.01 | madCoder- | the one in spl that loops on 0x800 then does something else |
| 22:12.15 | madCoder- | and the one in wince that does some other stuff but not that stuff ^ |
| 22:12.16 | madCoder- | :) |
| 22:13.07 | NetRipper | edge = 1 (irq 30) |
| 22:14.13 | NetRipper | i mean |
| 22:14.15 | NetRipper | edge and pos |
| 22:14.17 | NetRipper | for irq3 |
| 22:14.19 | NetRipper | so, rising |
| 22:15.27 | NetRipper | type0 = 1 for irq30 and polarity0 = 0 for irq30 |
| 22:16.07 | mdrobnak | Time to go home. Could someone please put in the wiki "Experimental Kernels" with the latest builds please? |
| 22:16.24 | *** join/#htc-linux Bally3 (n=chatzill@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 22:17.18 | madCoder- | wasn't someone going to setup a box to mirror git and do automatic builds? |
| 22:17.22 | NetRipper | any "public" experiental kernels will be posted in the thread i guess |
| 22:17.38 | mdrobnak | NetRipper: Have you tried following it lately? ;-) |
| 22:17.57 | NetRipper | git will always be behind the experimental kernels ;) |
| 22:17.58 | madCoder- | yeah I lost track about 30 pages ago :| |
| 22:18.01 | mdrobnak | LOL |
| 22:18.03 | NetRipper | tried what mdrobnak ? |
| 22:18.13 | mdrobnak | NetRipper: following the thread |
| 22:18.16 | mdrobnak | hehe |
| 22:18.18 | NetRipper | mdrobnak, yes ;) |
| 22:18.24 | NetRipper | i get mail when it's updated |
| 22:18.25 | NetRipper | ;) |
| 22:19.16 | mdrobnak | Me too. |
| 22:19.18 | mdrobnak | Anyway |
| 22:19.21 | mdrobnak | I'm out the door.. |
| 22:19.22 | mdrobnak | ttyl guys |
| 22:24.36 | *** part/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:25.28 | NetRipper | when tracing with haret.. there's no way to tell the difference between when a wince driver changes a memory address, or when the hardware does, is there? |
| 22:26.12 | tmzt | NetRipper: only one of those would show up as a write wouldn't it? |
| 22:26.38 | NetRipper | how so, haret doesn't detect when a hardware device changes a memory address? |
| 22:27.23 | tmzt | I think it detects accesses to them |
| 22:27.50 | NetRipper | then what do you mean by 'only one of those'? |
| 22:27.51 | tmzt | mayve that's just mmutrace though |
| 22:28.15 | tmzt | driver changing it would be an access, hardware changing it would not |
| 22:28.25 | NetRipper | hm |
| 22:28.29 | tmzt | only of the two possibilities you mentioned |
| 22:29.02 | NetRipper | im tracing the touchscreen but i do think i see changes that the touchscreen hardware makes |
| 22:29.07 | tmzt | since traces traces memory addresses it should detect hardware changes as well, but mmutrace does not |
| 22:29.14 | tmzt | what command are you using? |
| 22:29.21 | NetRipper | watch var sec |
| 22:30.05 | tmzt | so the same as traces and gpios, it would detect the hardware changes as well |
| 22:30.12 | NetRipper | ok |
| 22:31.15 | NetRipper | any way on how i can differentiate to what the driver does, adn what the hardware does? im currently using timing as a hint.. where i believe the hardware responds almost immediately (within same millisecond) and driver will respond a few ms later |
| 22:31.32 | tmzt | mmutrace |
| 22:31.41 | tmzt | does that work on msm? |
| 22:31.48 | NetRipper | i dont know |
| 22:32.11 | NetRipper | how does mmutrace work? |
| 22:32.15 | NetRipper | command? |
| 22:32.47 | tmzt | addlist mmutraces <addr> |
| 22:32.50 | tmzt | wirq N |
| 22:32.57 | tmzt | or mmutrace not traces |
| 22:33.02 | NetRipper | ah, wirq |
| 22:33.11 | NetRipper | ok |
| 22:33.14 | NetRipper | let's try that |
| 22:33.33 | tmzt | also, dump 2 mmu <phys> to get all the mappings |
| 22:34.03 | NetRipper | does the mmutrace list want physical or virtual addresses? |
| 22:34.21 | NetRipper | probably virt |
| 22:34.28 | tmzt | yeah |
| 22:35.05 | NetRipper | tmzt, and when i see things with mmutrace, it'll be wince? |
| 22:35.21 | tmzt | it will be arm code, probably wince |
| 22:35.26 | NetRipper | ok, thanks |
| 22:36.00 | NetRipper | hm |
| 22:36.01 | NetRipper | nothing happens |
| 22:36.12 | tmzt | you have all the mappings? |
| 22:36.16 | tmzt | help vars |
| 22:36.32 | tmzt | and use the newest haret for msm |
| 22:36.39 | NetRipper | yes |
| 22:36.45 | NetRipper | i'm using the cvs version |
| 22:36.49 | NetRipper | updated few days ago |
| 22:37.19 | tmzt | are changes going into cvs or git (or both)? |
| 22:37.25 | NetRipper | cvs |
| 22:37.29 | NetRipper | git is updated later, afaik |
| 22:38.24 | NetRipper | hm i've updated the mmutrace, and it indeed says it's watchable via wirq |
| 22:41.48 | NetRipper | hm |
| 22:41.51 | NetRipper | maybe i should add size |
| 22:42.10 | NetRipper | it defaults to 1, while they are words of 4 bytes |
| 22:42.20 | tmzt | unaligned accesses? |
| 22:43.36 | NetRipper | ermm i dont know much about data alignment |
| 22:44.00 | NetRipper | shouldnt haret take care of that? |
| 22:44.01 | tmzt | I mean I think you're right, maybe it's data abrting or something |
| 22:44.13 | tmzt | is the size in bytes? |
| 22:44.37 | NetRipper | yes |
| 22:44.48 | NetRipper | what is the proper size to use? |
| 22:45.07 | tmzt | multiples of 4 starting at addresses that are divisible by 4 |
| 22:45.29 | NetRipper | that should be the case |
| 22:46.05 | NetRipper | yep divisible by 4 |
| 22:46.19 | NetRipper | and 0x00, 0x04, 0x08, 0x0c, 0x10 etc |
| 22:47.06 | NetRipper | there are aborts when the wirq finishes, but there's almost the same amount of aborts when i dont do anything to trigger any changes |
| 22:49.10 | NetRipper | hm |
| 22:49.14 | *** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl) |
| 22:49.15 | NetRipper | there are more aborts when i touch the screen |
| 22:49.17 | NetRipper | so |
| 22:49.20 | NetRipper | may still be a problem ;) |
| 22:55.37 | NetRipper | what does & ~0xc00 do? it sets the flag, right? |
| 22:56.00 | NetRipper | or does it toggle it? |
| 22:58.57 | *** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl) |
| 23:00.57 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B037C9B.dip.t-dialin.net) |
| 23:02.14 | tmzt | NetRipper: clears it, and the inverse 1111 & 1011 = 1011, ~0100 = 1011 |
| 23:03.07 | lupine_85 | madCoder-: that be me, when I have time |
| 23:03.12 | lupine_85 | I have the box now |
| 23:04.24 | lupine_85 | so I just need to set the hardware up |
| 23:04.37 | lupine_85 | erm, software |
| 23:04.57 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 23:09.45 | *** part/#htc-linux sensorama (n=apan@c-9f06e155.910-1-64736c14.cust.bredbandsbolaget.se) |
| 23:11.57 | stefan_schmidt | (Not sure if you got this as I got disconnected) dcordes: Is the G1 near enough to the Kaiser that the msm modem support from FSO might work there? I have one that would like to try it on the G1 Dev Phone. |
| 23:13.58 | lupine_85 | does some setup |
| 23:21.29 | dream_kill | try what? |
| 23:21.40 | dream_kill | flash g1 with kasier radio :P ? |
| 23:22.06 | dream_kill | they started the g1 FROM kaiser :P |
| 23:22.32 | dream_kill | first radio on "dream" project was the kaiser radio :D |
| 23:25.28 | stefan_schmidt | dream_kill: So the radio part is identical I take from your words? |
| 23:39.36 | tmzt | stefan_schmidt: the driver should be the same, don't know about the amss itself but g1 has different rf components for different frequencies |
| 23:40.44 | stefan_schmidt | tmzt: ok, let's see when the guy has some time and I got an image build |
| 23:41.07 | tmzt | dcordes has a fso build for armv6novfp, should work on the g1 as a rootfs |
| 23:41.38 | tmzt | the kernel doesn't support ext2, maybe jf has one that does |
| 23:42.34 | stefan_schmidt | tmzt: No rush needed. He will have time only after LCA so some time left. |
| 23:42.50 | stefan_schmidt | And I need a buildsetup for it when we like to do more testing |
| 23:43.26 | tmzt | when is that? |
| 23:43.39 | tmzt | forgot it's january already |
| 23:50.40 | tmzt | stefan_schmidt: sorry ext2 won't work not because of the filesystem but lack of a block device, but dcordes rootfs can be extracted to yaffs2 at least |