| 00:05.29 | tmzt_ | the matrix key layout, don't think that can be configured in userspace |
| 00:17.58 | *** join/#htc-linux nashpa (n=dliviu@dliviu.plus.com) |
| 00:35.26 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 02:28.07 | *** join/#htc-linux br1ck (n=br1ck@xdslch239.osnanet.de) |
| 02:57.41 | *** join/#htc-linux br1ck_ (n=br1ck@xdslcx202.osnanet.de) |
| 02:59.22 | *** join/#htc-linux |404NotFound| (n=seraphim@unaffiliated/httperror/bot/httperrors) |
| 03:02.46 | maejrep | lavender-t, awesome work :) |
| 03:10.01 | *** part/#htc-linux exco (n=exco@e181085066.adsl.alicedsl.de) |
| 03:12.12 | *** join/#htc-linux woodson (n=CDP@c-76-101-90-149.hsd1.fl.comcast.net) |
| 03:18.01 | *** join/#htc-linux exco (n=exco@e181085066.adsl.alicedsl.de) |
| 03:21.17 | maejrep | so, maybe a dumb question, but i thought CDMA modem doesn't work like GSM does (i.e., AT commands) |
| 03:21.40 | maejrep | yeah, dumb question... |
| 03:21.42 | maejrep | ignore me |
| 03:22.08 | maejrep | i wonder what the chances are that the mmc is different in raph800 :P |
| 03:23.46 | tmzt_ | maejrep: where is the sd on the raph800? |
| 03:23.53 | maejrep | physically? |
| 03:23.56 | tmzt_ | yes |
| 03:24.00 | maejrep | under the back cover |
| 03:24.07 | tmzt_ | but not under the battery? |
| 03:24.13 | maejrep | right, you dont have to remove the batter |
| 03:24.18 | tmzt_ | ok |
| 03:24.37 | maejrep | its right above (towards back of phone, when face down) the vol down button |
| 03:25.11 | tmzt_ | I just looked at one but couldn't take the cover off, so I was wondering where it was |
| 03:25.28 | maejrep | didn't know how, or weren't allowed? |
| 03:26.58 | maejrep | hmm, so clock-7x00.c is used in place of clock-7x00a.c? |
| 03:27.42 | tmzt_ | it was in a metal cage at the store |
| 03:27.46 | maejrep | ah |
| 03:29.16 | tmzt_ | also suprised the diam isn't much thinner than the raph |
| 03:30.25 | maejrep | the keyboard really only takes about 1/4 inch |
| 03:33.01 | tmzt_ | have you gotten used to the opera browser, zooming/panning or whatever? |
| 03:34.46 | maejrep | panning yeah |
| 03:34.59 | maejrep | but its kind of a pain that i norder to read anything at all, i always have to zoom in after each page load |
| 03:35.13 | maejrep | 192.168.0.203 for the host right? |
| 03:35.31 | tmzt_ | what is the device? just the same subnet |
| 03:35.55 | maejrep | yeah you're right .. I thought the initrd had something built into that that was expecting the host to be some ip |
| 03:36.40 | maejrep | dd: can't open '/dev/mmcblk0': No such file or directory |
| 03:36.42 | maejrep | :( |
| 03:37.02 | tmzt_ | does it detect mmc0 ? |
| 03:37.35 | maejrep | yeah |
| 03:37.43 | maejrep | [ 1.490183] mmc0: Qualcomm MSM SDCC at 0x00000000e1001000 irq 26,0 dma 8 |
| 03:37.44 | maejrep | [ 1.500427] mmc0: 4 bit data mode enabled |
| 03:37.44 | maejrep | [ 1.508026] mmc0: MMC clock 2640000 -> 18480000 Hz, PCLK 66000000 Hz |
| 03:37.44 | maejrep | [ 1.510183] mmc0: Slot eject status = 0 |
| 03:37.44 | maejrep | [ 1.520061] mmc0: Power save feature enable = 0 |
| 03:37.44 | maejrep | [ 1.527598] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x15bc9000 |
| 03:37.46 | maejrep | [ 1.530335] mmc0: DM cmd busaddr 364679168, cmdptr busaddr 364679936 |
| 03:37.48 | maejrep | [ 1.540122] mmc0: Polling status mode enabled |
| 03:38.14 | tmzt_ | and the card? |
| 03:38.17 | maejrep | should i be able to just create a block device with mknod? |
| 03:38.27 | tmzt_ | check /sys/block/ |
| 03:38.39 | maejrep | loop0->7 |
| 03:39.00 | tmzt_ | and /proc/devices shows mmcblk ? |
| 03:39.22 | maejrep | Block devices: |
| 03:39.22 | maejrep | <PROTECTED> |
| 03:39.22 | maejrep | 179 mmc |
| 03:39.55 | maejrep | so could i mknod with 179,1 ;o? |
| 03:40.03 | tmzt_ | ok, the drivers are loaded? |
| 03:40.12 | tmzt_ | <PROTECTED> |
| 03:41.08 | maejrep | all I did was apply the patch and compile, didn't change anything else |
| 03:42.12 | maejrep | dd: can't open '/dev/mmcblk0': No such device or address |
| 03:42.12 | maejrep | (after mknod) |
| 03:42.13 | tmzt_ | does the card itself appear in dmesg? |
| 03:42.24 | tmzt_ | also, /sys/bus/mmc/devices/ |
| 03:44.05 | maejrep | # ls /sys/bus/mmc/devices |
| 03:44.05 | maejrep | # ls /sys/bus/mmc/drivers |
| 03:44.05 | maejrep | mmcblk |
| 03:44.10 | maejrep | I don't see anything about the card in dmesg |
| 03:44.37 | maejrep | but also not exactly sure how it would be displayed |
| 03:44.39 | tmzt_ | the patch has debugging for the clocks? |
| 03:44.41 | maejrep | I see: |
| 03:44.44 | maejrep | [ 1.411312] clk_get sdc2_pclk |
| 03:44.45 | maejrep | [ 1.419033] clk_get_rate 22:66000000 |
| 03:44.45 | maejrep | [ 1.420061] clk_get sdc2_clk |
| 03:44.45 | maejrep | [ 1.430122] clk_set_rate 21:2640000 |
| 03:44.45 | maejrep | [ 1.440549] set_sdcc_host_clock 4000000, 2640000 |
| 03:45.31 | maejrep | # ls /sys/bus/mmc/drivers_probe -l |
| 03:45.31 | maejrep | --w------- 1 0 0 4096 Jan 1 00:11 /sys/bus/mmc/drivers_probe |
| 03:45.32 | maejrep | # ls /sys/bus/mmc/drivers_autoprobe -l |
| 03:45.32 | maejrep | -rw-r--r-- 1 0 0 4096 Jan 1 00:11 /sys/bus/mmc/drivers_autoprobe |
| 03:45.32 | maejrep | # cat /sys/bus/mmc/drivers_autoprobe |
| 03:45.32 | maejrep | 1 |
| 03:45.57 | maejrep | hmm, this patch wouldn't fix rtc0, right? |
| 03:47.56 | tmzt_ | you wouldn't know if the diam movinand is one fat32 partition, would you? |
| 03:48.05 | tmzt_ | hold on, reading the thread |
| 03:48.19 | maejrep | yes i think so |
| 03:48.32 | maejrep | # dd if=/dev/mmcblk0 count=1 | hd |
| 03:48.33 | maejrep | 00000050 20 20 46 41 54 33 32 20 20 20 00 00 00 00 00 00 | FAT32 ......| |
| 03:48.38 | maejrep | # mount /dev/mmcblk0 /mnt |
| 03:48.46 | maejrep | (from lavender-t's post) |
| 03:48.51 | tmzt_ | not even partitoned |
| 03:49.17 | tmzt_ | I don't see where that is, do you have a link (and for the patch)? |
| 03:51.54 | maejrep | http://forum.xda-developers.com/showpost.php?p=3058732&postcount=1128 |
| 03:52.05 | maejrep | http://forum.xda-developers.com/showpost.php?p=3060104&postcount=1136 |
| 04:01.51 | tmzt_ | maejrep: is the patch supposed to work for raph? |
| 04:02.05 | maejrep | haven't heard |
| 04:02.25 | maejrep | # tail -f /sys/kernel/debug/mmc0/ios |
| 04:02.25 | maejrep | clock: 0 Hz |
| 04:02.25 | maejrep | vdd: 0 (invalid) |
| 04:02.25 | maejrep | bus mode: 1 (open drain) |
| 04:02.26 | maejrep | chip select: 0 (don't care) |
| 04:02.28 | maejrep | power mode: 0 (off) |
| 04:02.30 | maejrep | bus width: 0 (1 bits) |
| 04:02.32 | maejrep | timing spec: 0 (legacy) |
| 04:03.04 | maejrep | # tail -f /sys/kernel/debug/msmsdcc/mmc0 |
| 04:03.04 | maejrep | STAT: 00000000 00000000 00000000 |
| 04:03.14 | maejrep | doesn't sound promising ;o |
| 04:04.20 | maejrep | # tail -f clk_enable/sdc1_clk |
| 04:04.20 | maejrep | 0 |
| 04:04.20 | maejrep | # tail -f clk_enable/sdc1_pclk |
| 04:04.20 | maejrep | 1 |
| 04:05.20 | tmzt_ | he might not be setting the clk through the mmc layer |
| 04:05.37 | maejrep | # cat clk_rate/sdc1_clk |
| 04:05.37 | maejrep | 4294967274 |
| 04:05.41 | maejrep | that looks like -1 :p |
| 04:05.57 | tmzt_ | are you using fmin/fmax on cmdline? |
| 04:05.59 | maejrep | # cat clk_rate/sdc2_clk |
| 04:05.59 | maejrep | 2640000 |
| 04:06.01 | maejrep | no |
| 04:06.06 | maejrep | should I? |
| 04:06.25 | tmzt_ | -static unsigned int msmsdcc_fmin = 144000; |
| 04:06.25 | tmzt_ | -static unsigned int msmsdcc_fmax = 20000000; |
| 04:06.25 | tmzt_ | +static unsigned int msmsdcc_fmin = 2640000; |
| 04:06.25 | tmzt_ | +static unsigned int msmsdcc_fmax = 18480000; |
| 04:06.28 | tmzt_ | no |
| 04:07.21 | maejrep | I did see that he's only enabling 2 in the code, probably explains the -1 for sdc1 |
| 04:07.38 | tmzt_ | your's is on sdc1 ? |
| 04:07.45 | tmzt_ | sdc2 is wifi? |
| 04:08.05 | maejrep | I have no idea |
| 04:08.09 | tmzt_ | lavender-t: are you here? |
| 04:08.12 | maejrep | how can I find out? :p |
| 04:09.31 | maejrep | for a programmer (even the occasional kernel driver or hack), I really feel dumb when I start looking at all this :) |
| 04:10.27 | tmzt_ | I don't know, but I think the clocks are different for 1 and 2 (different registers) |
| 04:11.00 | *** join/#htc-linux exco (n=exco@e181104124.adsl.alicedsl.de) |
| 04:12.01 | maejrep | so i'd probably have to trace accessing the sd in WM or something? |
| 04:13.01 | tmzt_ | how many sdcc instances are in htcraphael.c ? |
| 04:14.04 | maejrep | instances as in what? |
| 04:14.15 | maejrep | how many times its called? |
| 04:14.30 | maejrep | <PROTECTED> |
| 04:14.30 | maejrep | <PROTECTED> |
| 04:14.30 | maejrep | <PROTECTED> |
| 04:14.30 | maejrep | <PROTECTED> |
| 04:14.38 | *** part/#htc-linux exco (n=exco@e181104124.adsl.alicedsl.de) |
| 04:14.44 | maejrep | (theres a comment on the 2nd line there ..) |
| 04:14.55 | maejrep | so it only adds 2 |
| 04:15.15 | maejrep | the patch changed that from a 1 to a 2 |
| 04:17.37 | tmzt_ | the comment was from halibut source |
| 04:17.46 | maejrep | right |
| 04:17.58 | maejrep | was just pointing out that my client didn't show the "/*..." line because of hte / :) |
| 04:18.04 | tmzt_ | I thought it would try commands and timeout if the clock was not right, do you see that in dmesg |
| 04:18.08 | tmzt_ | (or, can you paste it) |
| 04:18.48 | maejrep | no, I don't see anything like that |
| 04:18.50 | maejrep | but will paste |
| 04:19.06 | maejrep | http://www.privatepaste.com/aefSuIt8wg |
| 04:21.25 | tmzt_ | slot eject status? |
| 04:21.39 | tmzt_ | the function returns 1? |
| 04:21.43 | maejrep | not sure how to interpret that .. does eject status = 0 mean it's not ejected? |
| 04:22.08 | tmzt_ | could be different for movinand |
| 04:22.17 | tmzt_ | halibut had it return 0 |
| 04:23.00 | tmzt_ | can you try that? don't think it will fix the clocks but it might at least detect it |
| 04:23.05 | maejrep | <PROTECTED> |
| 04:23.05 | maejrep | <PROTECTED> |
| 04:23.09 | maejrep | it returns 1 |
| 04:23.14 | maejrep | so eject = ! status (0) |
| 04:23.27 | tmzt_ | we need to look at mmc host code then |
| 04:23.31 | tmzt_ | mmc core |
| 04:23.44 | maejrep | that's msm_sdcc.c |
| 04:23.48 | tmzt_ | it doesn't detect a card at all |
| 04:24.05 | tmzt_ | what function? |
| 04:24.14 | maejrep | msmsdcc_check_status |
| 04:26.19 | maejrep | what would it look like if it detected a card? |
| 04:27.22 | tmzt_ | you don't get Slot status changed: ? |
| 04:27.46 | maejrep | # dmesg | grep -i slot |
| 04:27.46 | maejrep | [ 1.510183] mmc0: Slot eject status = 0 |
| 04:28.01 | tmzt_ | <PROTECTED> |
| 04:28.21 | maejrep | that's the only line with "slot" ^ |
| 04:30.13 | maejrep | is debugfs/mmc0/ios indicative of something? |
| 04:39.06 | *** join/#htc-linux PoohbaLT (n=Poohba@c-98-235-66-242.hsd1.nj.comcast.net) |
| 04:39.26 | maejrep | hmm |
| 04:39.45 | maejrep | these are new lines that I didn't see in my first dmesg: |
| 04:39.46 | maejrep | [ 8.339463] # clk_get_rate 19:-22 |
| 04:39.46 | maejrep | [ 520.799490] clk_get_rate 20:66000000 |
| 04:39.46 | maejrep | [ 527.291711] clk_get_rate 21:2640000 |
| 04:39.56 | maejrep | (didn't see because they were ~9 minutes after booting |
| 04:40.07 | maejrep | -22 seems strange |
| 04:40.42 | tmzt_ | the clk isn't used? look in the clock.h and find which clock it is |
| 04:41.34 | maejrep | which click 19 is ? |
| 04:42.10 | maejrep | clock* |
| 04:42.46 | tmzt_ | yes |
| 04:43.53 | tmzt_ | <PROTECTED> |
| 04:44.11 | tmzt_ | match those to the values from SDC2, I think |
| 04:44.22 | tmzt_ | we need to ask lavender-t |
| 04:44.55 | maejrep | could try setting his 2 back to 1 |
| 04:44.58 | maejrep | shrugs |
| 04:45.26 | tmzt_ | can you try return 0 in that detect function? |
| 04:45.59 | maejrep | halibut_sdcc_slot_status |
| 04:46.48 | tmzt_ | yes |
| 04:48.25 | tmzt_ | can you also add a printk to msm_sdcc msmsdcc_check_status at the beginning? |
| 04:51.55 | maejrep | [ 1.500427] mmc0: Slot eject status = 1 |
| 04:52.04 | maejrep | sorry, i'd already recompiled .. will do that on next run |
| 04:52.25 | maejrep | [ 1.480091] mmc0: Qualcomm MSM SDCC at 0x00000000e1000000 irq 24,0 dma -1 |
| 04:52.25 | maejrep | [ 1.490183] mmc0: 4 bit data mode enabled |
| 04:52.25 | maejrep | [ 1.497690] mmc0: MMC clock 2640000 -> 18480000 Hz, PCLK 66000000 Hz |
| 04:52.25 | maejrep | [ 1.500427] mmc0: Slot eject status = 1 |
| 04:52.25 | maejrep | [ 1.510061] mmc0: Power save feature enable = 0 |
| 04:52.27 | maejrep | [ 1.517568] mmc0: PIO transfer enabled |
| 04:52.29 | maejrep | [ 1.520183] mmc0: Polling status mode enabled |
| 04:52.31 | maejrep | looks different |
| 04:52.42 | maejrep | no status change though |
| 04:53.02 | maejrep | and no mmcblk0 |
| 04:53.35 | tmzt_ | different after that? |
| 04:55.11 | maejrep | after what? |
| 04:55.23 | maejrep | sorry, i meant the PIO transfer enabled is different |
| 04:55.33 | maejrep | before I got: |
| 04:55.38 | maejrep | # |
| 04:55.38 | maejrep | [ 1.527598] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x15bc9000 |
| 04:55.38 | maejrep | # |
| 04:55.39 | maejrep | [ 1.530335] mmc0: DM cmd busaddr 364679168, cmdptr busaddr 364679936 |
| 04:56.38 | maejrep | but i'm sure that's just the difference between sdc1 and sdc2 |
| 04:57.27 | maejrep | printk what exactly? |
| 04:57.33 | maejrep | just that I entered the function? |
| 05:00.00 | tmzt_ | yes |
| 05:00.33 | *** join/#htc-linux datachaos (n=datachao@201.22.220.166.adsl.gvt.net.br) |
| 05:04.38 | *** join/#htc-linux ALoGeNo (n=QUAKEIII@unaffiliated/alogeno) |
| 05:05.06 | maejrep | [ 9.250034] halibut_sdcc_slot_status : 293 |
| 05:05.06 | maejrep | [ 9.550034] halibut_sdcc_slot_status : 293 |
| 05:05.06 | maejrep | [ 9.840003] halibut_sdcc_slot_status : 293 |
| 05:05.09 | maejrep | (repeatedly) |
| 05:05.33 | maejrep | [ 1.550305] mmc0: Slot eject status = 1 |
| 05:05.33 | maejrep | [ 1.557873] mmc0: Power save feature enable = 0 |
| 05:05.34 | maejrep | [ 1.560030] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x15bc9000 |
| 05:05.34 | maejrep | [ 1.570183] mmc0: DM cmd busaddr 364679168, cmdptr busaddr 364679936 |
| 05:05.34 | maejrep | [ 1.580061] mmc0: Polling status mode enabled |
| 05:05.53 | maejrep | nothing about status change (since its always returning a static value, i wouldn't expect it to ever change) |
| 05:15.11 | tmzt_ | maejrep: do you see the printk? it looks like it has to report the change somewhere but I haven't found it yet |
| 05:18.03 | maejrep | it would only report a change if slot_status returns something different than it's already seen before |
| 05:18.15 | maejrep | its always returning 0 or always returning 1, so it would never report a change |
| 05:18.40 | maejrep | unless i'm understanding the "change" wrong |
| 05:18.50 | tmzt_ | ok, but how does it get the status to begin with? |
| 05:18.59 | maejrep | there is no status |
| 05:19.00 | tmzt_ | remember, that function is not supposed to be static |
| 05:19.16 | maejrep | static unsigned int halibut_sdcc_slot_status(struct device *dev) |
| 05:19.16 | maejrep | { |
| 05:19.17 | maejrep | <PROTECTED> |
| 05:19.17 | maejrep | <PROTECTED> |
| 05:19.17 | maejrep | <PROTECTED> |
| 05:19.17 | maejrep | <PROTECTED> |
| 05:20.25 | maejrep | nice, memory map is in google cache: http://74.125.45.132/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=x0X&q=cache%3Ahttp%3A%2F%2Fwiki.xda-developers.com%2Findex.php%3Fpagename%3DRaphaelMemoryMap&btnG=Search |
| 05:22.18 | maejrep | would i be able to get the clock data from haret, to see if it's different from what is being used in this patch? |
| 05:24.21 | maejrep | pdump 0xa86000a0 0x20 |
| 05:34.00 | tmzt_ | maejrep: if you have multiple sdcc's enabled, why is only mmc0 in dmesg? |
| 05:34.20 | maejrep | isn't mmc0 the controller (not the card/slot)? |
| 05:34.30 | tmzt_ | yes, that's what I mean |
| 05:35.08 | tmzt_ | that's what I'm trying to find, if the _add_sdcc's registers controllers or slots |
| 05:35.52 | maejrep | slots I would think.. but i have no idea |
| 05:40.12 | maejrep | and what do you mean by multiple sdcc's enabled? |
| 05:40.24 | tmzt_ | multiple add_sdcc's |
| 05:40.26 | maejrep | it only calls add_sdcc for "2" |
| 05:40.35 | tmzt_ | yours does? |
| 05:40.37 | maejrep | the other 3 function calls are inside of a comment |
| 05:40.58 | tmzt_ | reenable 1 |
| 05:41.01 | maejrep | -> /* TODO: Enable these once we have support for the SDC mux |
| 05:41.01 | maejrep | <PROTECTED> |
| 05:41.01 | maejrep | <PROTECTED> |
| 05:41.01 | maejrep | <PROTECTED> |
| 05:41.01 | maejrep | <PROTECTED> |
| 05:41.02 | tmzt_ | disable 2 |
| 05:41.25 | maejrep | I tried that in the last run, and that was when it said "PIO transfer enabled" instead of "DM ..." in dmesg |
| 05:41.52 | tmzt_ | I think DM is data mover and the commands are to the data mover |
| 05:41.53 | maejrep | but I also did the return 0 change at the same time .. I'll try it again with return 1 |
| 05:42.14 | tmzt_ | ok, you still don't get the printk or the changed message? |
| 05:42.16 | maejrep | or should I try enabling both 1 and 2? (comment indicates that may not work?) |
| 05:42.23 | maejrep | I get hte printk multiple times |
| 05:42.30 | maejrep | <maejrep> [ 9.250034] halibut_sdcc_slot_status : 293 |
| 05:42.30 | maejrep | <maejrep> [ 9.550034] halibut_sdcc_slot_status : 293 |
| 05:42.30 | maejrep | <maejrep> [ 9.840003] halibut_sdcc_slot_status : 293 |
| 05:42.49 | tmzt_ | that's the one you added? |
| 05:42.50 | maejrep | 293 is just the line number |
| 05:42.53 | tmzt_ | ok |
| 05:43.01 | maejrep | added what? |
| 05:43.09 | tmzt_ | printk |
| 05:43.15 | maejrep | yeah, that was it ^ |
| 05:43.30 | maejrep | and its called about 3x per second it seems |
| 05:44.35 | maejrep | so should I try it again with add_sdcc 1? |
| 05:45.03 | tmzt_ | yes |
| 05:45.04 | maejrep | and leave the status returning 1? (when i tried it with add_sdcc 1 before, I also changed the return to 0) |
| 05:45.18 | tmzt_ | it should only trigger on an irq which we don't have |
| 05:45.34 | tmzt_ | I still can't find what host->eject means |
| 05:47.10 | maejrep | I think it's just slot status (1 = empty, 0 = card in slot) |
| 05:47.30 | maejrep | <maejrep> status = host->plat->status(mmc_dev(host->mmc)); |
| 05:47.30 | maejrep | <maejrep> host->eject = !status; |
| 05:47.46 | maejrep | so because my status function always returns 1, status is always 1, and eject is always 0 |
| 05:47.52 | tmzt_ | right, but where is that checked? |
| 05:48.03 | maejrep | where is eject checked? |
| 05:48.15 | tmzt_ | can you git-grep ->status I've tried the gitweb one |
| 05:48.54 | maejrep | for status or eject? |
| 05:49.01 | tmzt_ | eject |
| 05:50.04 | maejrep | drivers/mmc/host/msm_sdcc.c: if (host->eject) { |
| 05:50.04 | maejrep | drivers/mmc/host/msm_sdcc.c: host->eject = !status; |
| 05:50.04 | maejrep | drivers/mmc/host/msm_sdcc.c: host->eject = !host->oldstat; |
| 05:50.04 | maejrep | drivers/mmc/host/msm_sdcc.c: host->eject); |
| 05:50.04 | maejrep | drivers/mmc/host/tifm_sd.c: if (host->eject) { |
| 05:50.05 | maejrep | drivers/mmc/host/tifm_sd.c: host->eject = 1; |
| 05:50.07 | maejrep | drivers/mmc/host/tifm_sd.c: host->eject = 1; |
| 05:51.44 | tmzt_ | right, but where is it in core? |
| 05:54.47 | maejrep | current dmesg: http://www.privatepaste.com/bc1DDkoBpW |
| 05:57.42 | lavender-t | hello maejrep. |
| 05:57.48 | maejrep | :D |
| 05:58.04 | lavender-t | still having problem with the mmc ? |
| 05:58.10 | maejrep | yeah, on raph800 |
| 05:58.16 | tmzt_ | <@SanMehat> tmzt_: if status == 0 then the card is ejected |
| 05:58.20 | lavender-t | i know that raph is a little different |
| 05:58.26 | maejrep | ah |
| 05:58.29 | lavender-t | netripper also found problems |
| 05:59.00 | maejrep | any way i can help debug/track it down? |
| 05:59.11 | lavender-t | could you do me a favor: set CONFIG_MMC_DEBUG=y in .config and rebuild the kernel |
| 05:59.13 | maejrep | raph800 very well may be quite different from raph100 even |
| 05:59.28 | lavender-t | that'd generate more debug spills |
| 05:59.50 | maejrep | building now |
| 05:59.57 | lavender-t | cool :) |
| 06:00.27 | tmzt_ | maejrep: you are not in #android? |
| 06:00.34 | maejrep | not currently |
| 06:00.37 | maejrep | I could be (?) |
| 06:01.07 | tmzt_ | yeah |
| 06:01.59 | lavender-t | thanks very much tmzt for supporting :) |
| 06:02.08 | maejrep | yes :) |
| 06:02.18 | maejrep | seems tmzt_ is the only one active when I am ;p |
| 06:02.22 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 06:02.32 | lavender-t | about the ejecting state, i hardcoded it to not ejected for now :) |
| 06:03.01 | tmzt_ | the logs are gone |
| 06:04.24 | maejrep | and you saw that I switched back to sdcc_add(1 ? |
| 06:04.33 | maejrep | should I leave that at 2 as in your patch? |
| 06:06.02 | lavender-t | in diamond it is sdc2. but i dont really know what's there in raph800 |
| 06:06.27 | maejrep | any quick way to find out? :p haret perhaps? |
| 06:06.47 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 06:07.27 | lavender-t | when i see the log i think there will be some clues . |
| 06:07.38 | tmzt_ | lavender-t: did you find the other clocks? |
| 06:07.56 | lavender-t | hm i dont know what registers to check in haret yet ... :( |
| 06:08.05 | lavender-t | tmzt: not yet. |
| 06:08.19 | lavender-t | i just worked other way around. |
| 06:09.07 | tmzt_ | San said there is no sd mux on trout (g1) |
| 06:09.08 | lavender-t | i assume the freq divider is the same for diamond using the clock-7x00.c file from vogue. |
| 06:09.43 | maejrep | great, my usb hub is hung in IO |
| 06:10.20 | lavender-t | possibly. i havent checked yet. i found trout had too much stuff that i was not sure whether to include or not. |
| 06:10.46 | maejrep | gotta reboot in order to copy my kernel >:( |
| 06:10.49 | maejrep | bbiaf |
| 06:11.07 | lavender-t | ah happened again :( |
| 06:13.28 | *** join/#htc-linux goxboxlive (n=goxboxli@mail2.hjellnesconsult.no) |
| 06:13.36 | *** join/#htc-linux maejrep (n=madcoder@c-71-225-238-170.hsd1.pa.comcast.net) |
| 06:14.55 | maejrep | ok booting now |
| 06:14.59 | maejrep | lots of debug info |
| 06:16.47 | lavender-t | could you post the logs somewhere ? |
| 06:17.35 | maejrep | hmm, ether isn't working now for some reason |
| 06:17.44 | maejrep | the interface comes up, but won't connect |
| 06:17.56 | lavender-t | :( |
| 06:18.35 | lavender-t | oh did you see multiple usb ethernet intfs ? |
| 06:19.00 | tmzt_ | why is that, NetRipper's code has that? |
| 06:19.22 | lavender-t | if so try the other interface. |
| 06:19.47 | maejrep | on my host yes, i have usb0 and usb1 |
| 06:20.10 | maejrep | i'm trying to use usb1, which has worked in the past ( just used bash history to bring up the interface the way I had previously..) |
| 06:20.40 | maejrep | also just tried switching from 192.168.0.206/24 to 192.168.2.206/24 and still won't do anything |
| 06:20.41 | lavender-t | yeah usb1's always working fine for me. |
| 06:20.57 | tmzt_ | maejrep: you changed the address on the fs, right? |
| 06:21.31 | maejrep | i did the first time i tried it, yes |
| 06:21.36 | maejrep | and just tried again doing the same thing |
| 06:21.44 | maejrep | but earlier tonight i've been doing: |
| 06:22.02 | maejrep | ifconfig usb1 192.168.0.202 netmask 255.255.255.0 |
| 06:22.03 | maejrep | route add -host 192.168.0.206 dev usb1 |
| 06:22.10 | maejrep | and then ping and telnet work fine |
| 06:22.17 | maejrep | not now for some reason |
| 06:22.21 | maejrep | will try rebooting i guess |
| 06:22.28 | tmzt_ | you also have auto usb0 in /etc/network/interfaces ? |
| 06:22.37 | tmzt_ | or just bring it up on the device |
| 06:22.38 | maejrep | on the phone? yes |
| 06:22.52 | maejrep | on my desktop i bring it up manually |
| 06:23.24 | lavender-t | so neither usb0 nor 1 works now ? |
| 06:23.31 | tmzt_ | lsusb -v -v |
| 06:23.42 | maejrep | lsusb showed the alcor device |
| 06:23.47 | maejrep | i've already rebooted now |
| 06:24.00 | maejrep | will check once linux boots up on the phone again |
| 06:24.02 | tmzt_ | rebooted the phone? |
| 06:24.06 | maejrep | yes |
| 06:24.13 | tmzt_ | ok |
| 06:25.24 | maejrep | # ping 192.168.0.206 |
| 06:25.24 | maejrep | PING 192.168.0.206 (192.168.0.206) 56(84) bytes of data. |
| 06:25.24 | maejrep | From 192.168.0.202 icmp_seq=2 Destination Host Unreachable |
| 06:26.01 | maejrep | and same with usb0 :/ |
| 06:26.14 | lavender-t | seems the usb transport is broken now ... :( |
| 06:26.18 | tmzt_ | ifconfig usb0 on the phone |
| 06:26.40 | tmzt_ | could be, it doesn't detect usb0 and usb1 on the pc? |
| 06:26.58 | maejrep | the pc detects both, yes |
| 06:27.10 | maejrep | and ifconfig on the phone shows usb0 is up and running |
| 06:27.42 | tmzt_ | ip address? |
| 06:27.51 | maejrep | 192.160.0.206 |
| 06:27.58 | maejrep | er, 192.168.0.206 |
| 06:28.08 | maejrep | shows RX and TX bytes = 0 |
| 06:28.19 | maejrep | on desktop also |
| 06:28.25 | tmzt_ | it should rx even if the ip is wrong, I think |
| 06:28.27 | maejrep | let me check something else |
| 06:28.42 | maejrep | dammit |
| 06:28.45 | maejrep | root 4340 0.0 0.0 17668 1100 ? D 01:12 0:00 hald-addon-storage: polling /dev/sdc (every 2 sec) |
| 06:28.45 | maejrep | root 4342 0.0 0.0 17668 1100 ? D 01:12 0:00 hald-addon-storage: polling /dev/sdd (every 2 sec) |
| 06:28.45 | maejrep | root 4344 0.0 0.0 17668 1100 ? D 01:12 0:00 hald-addon-storage: polling /dev/sde (every 2 sec) |
| 06:28.45 | maejrep | root 4346 0.0 0.0 17668 1100 ? D 01:12 0:00 hald-addon-storage: polling /dev/sdf (every 2 sec) |
| 06:28.53 | maejrep | usb in uninterruptible sleep again |
| 06:28.55 | maejrep | >:| |
| 06:29.30 | tmzt_ | oh |
| 06:29.48 | maejrep | what a pain in the ass... i have to reboot again |
| 06:31.49 | *** join/#htc-linux balsat (n=kll@87.72.13.87) |
| 06:32.21 | *** join/#htc-linux maejrep (n=madcoder@c-71-225-238-170.hsd1.pa.comcast.net) |
| 06:33.05 | maejrep | guess that external sata hdd enclosure I got in the wootoff is trash |
| 06:34.32 | maejrep | lavender-t: dmesg: http://privatepaste.com/d38YP0o2PG |
| 06:35.48 | maejrep | so all the commands are timing out |
| 06:35.56 | maejrep | thats the same thing NetRipper saw, right? |
| 06:40.30 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 06:42.12 | lavender-t | hm .. the sd might be in sdc0 looks like |
| 06:42.22 | lavender-t | could you try sd0 ? |
| 06:42.32 | lavender-t | also in mach-msm/common.c |
| 06:43.27 | lavender-t | static struct resource msm_sdc1_resources[] = { |
| 06:43.55 | lavender-t | uncomment the #if 0 ... |
| 06:44.12 | maejrep | where would I set sdc0 ? |
| 06:44.13 | lavender-t | oh here i mean sdc1 from the code ... |
| 06:44.16 | maejrep | in the sdcc_add call? |
| 06:45.05 | lavender-t | yeah in board-htcraphael.c, |
| 06:45.06 | maejrep | so sdcc_add(1 ? |
| 06:45.26 | lavender-t | msm_add_sdcc(1, |
| 06:45.28 | lavender-t | yeah |
| 06:46.13 | maejrep | ok, i have a dmesg from when i tried that earlier (though without debugging) |
| 06:46.30 | maejrep | the main difference was: |
| 06:46.31 | maejrep | <maejrep> [ 1.560030] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x15bc9000 |
| 06:46.31 | maejrep | <maejrep> [ 1.570183] mmc0: DM cmd busaddr 364679168, cmdptr busaddr 364679936 |
| 06:46.44 | maejrep | (with add_sdcc 2) |
| 06:46.53 | maejrep | and: <maejrep> [ 1.517568] mmc0: PIO transfer enabled |
| 06:46.58 | maejrep | for add 1 |
| 06:47.10 | maejrep | i'll try it with debugging as well though |
| 06:50.52 | lavender-t | that's b/c the DMA resources were turned off for sdc1 |
| 06:51.15 | lavender-t | by uncommenting common.c the DMA is enabled |
| 06:51.27 | maejrep | so you expect that? |
| 06:51.35 | maejrep | still getting timeouts btw |
| 06:52.10 | maejrep | http://privatepaste.com/4c88xDi4wD |
| 06:52.22 | lavender-t | cool. i'll take a look. |
| 06:54.06 | lavender-t | hm ... looks the same :( |
| 06:55.22 | lavender-t | let me see if there is a way to find out the sdc# ... |
| 06:57.00 | dcordes | hi all |
| 06:57.01 | lavender-t | if raph800 uses sdc3 or 4, then the clock code needs some changes too ... :( |
| 06:57.27 | tmzt_ | hi, dcordes |
| 06:57.49 | lavender-t | hi dcordes |
| 07:00.00 | maejrep | :x |
| 07:00.32 | lavender-t | what's happening to the memory map pages in the wiki ? |
| 07:00.58 | lavender-t | raphael and kaiser are all blank now :( |
| 07:01.23 | maejrep | http://74.125.45.132/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=daZ&q=cache%3Ahttp%3A%2F%2Fwiki.xda-developers.com%2Findex.php%3Fpagename%3DRaphaelMemoryMap&btnG=Search |
| 07:02.31 | lavender-t | oh that's nice |
| 07:09.54 | *** join/#htc-linux Tinyboom (n=nahh@178.80-202-153.nextgentel.com) |
| 07:14.56 | lavender-t | hm sorry maejrep, i've got no clues now. |
| 07:15.12 | maejrep | k |
| 07:16.38 | tmzt_ | lavender-t: how did you find the clocks for sdc2? I see what you said about vogue clocks (dividers) |
| 07:17.41 | lavender-t | oh yeah. so i assumed they have the same divider. then diamond's main freq is 528MHz which is 1.32 time that of the vogue |
| 07:18.17 | tmzt_ | you are still setting the clocks with proc_comm? |
| 07:18.51 | lavender-t | so i changed the f_min/f_max in the msm_sdcc.c to have it take the different frequencies |
| 07:18.59 | lavender-t | no. i'm using the CLK_CTL registers directly |
| 07:19.21 | lavender-t | that the reason i need the A0/A4 stuff. |
| 07:19.36 | tmzt_ | a0/a4 are for sdc2 only? |
| 07:19.49 | lavender-t | a0/a4 are for sd1 |
| 07:20.02 | lavender-t | sdc2 is a8/ac |
| 07:20.10 | lavender-t | and so forth |
| 07:21.45 | lavender-t | so the whole sd clock stuff here is for now just a guessing game. |
| 07:22.03 | lavender-t | no datasheet :( |
| 07:23.49 | maejrep | so by changing it to add_sdcc 1, would i need to use something else? |
| 07:24.41 | lavender-t | no nothing special. the clock-7x00.c covers sdc1 and sdc2 |
| 07:24.58 | lavender-t | but for sdc3/4 there will be more code. |
| 07:25.04 | maejrep | ah |
| 07:26.10 | lavender-t | this one i mostly directly used the code from vogue |
| 07:26.30 | lavender-t | just added sd2. (it was sd1 only) |
| 07:27.04 | lavender-t | agree the code was not very well written ;) |
| 07:27.32 | lavender-t | just wish to try out first if it really works. |
| 07:27.57 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 07:30.05 | *** join/#htc-linux kiozen (n=oeichler@p5492A189.dip0.t-ipconnect.de) |
| 07:47.41 | tmzt_ | lavender-t: do you know of anyway to set those values through proc_comm? swetland from google is saying that's the prefferred way |
| 07:52.12 | *** join/#htc-linux ionstorm (n=ion@ip68-228-225-247.ph.ph.cox.net) |
| 07:54.34 | lavender-t | yeah i agree |
| 07:54.52 | lavender-t | if we can get the proc_comm working that'd be all natural |
| 07:55.12 | tmzt_ | does the proc_comm api involve setting those dividers too, or is it just the frequency? |
| 07:55.31 | lavender-t | but the thing is proc_comm stucks at waiting for commands forever |
| 07:55.36 | tmzt_ | (assuming trout amss 6525? is similar enough) |
| 07:59.43 | lavender-t | possibly. haret from wince could have negative impact. |
| 08:00.03 | tmzt_ | what happens with proc_comm commands? |
| 08:00.59 | lavender-t | every msm_proc_comm() call stuck at proc_comm_wait_for() |
| 08:01.11 | lavender-t | waiting for the command completion |
| 08:01.24 | *** join/#htc-linux kkaze_wor (n=kaze@ABordeaux-152-1-35-247.w83-193.abo.wanadoo.fr) |
| 08:01.37 | lavender-t | if you have the code, the first wait (PCOM_READY) always passed. |
| 08:01.40 | tmzt_ | no proc_comm commands work? is this a smd issue? |
| 08:02.04 | lavender-t | but then command is written to the smem, the 2nd wait PCMD_CMD_DONE |
| 08:02.13 | lavender-t | always stuck there forever. |
| 08:02.31 | lavender-t | hm .. not sure. |
| 08:02.46 | lavender-t | i'm not really familiar with the proc_comm mechanism |
| 08:02.56 | tmzt_ | I'm not either |
| 08:02.58 | lavender-t | so i gave up on that. |
| 08:03.15 | tmzt_ | dzo and cr2_ worked on that, someone else finished making it linux-like or whatever |
| 08:03.52 | tmzt_ | you can check the logs here though as I'm not sure of that |
| 08:04.05 | lavender-t | i remember was told that cr2 suggested abandon proc_comm for diam raph :) |
| 08:04.38 | tmzt_ | yeah, we could probably find the clock register values then |
| 08:04.55 | tmzt_ | I think NetRipper tried tracing with haret (or maejrep) |
| 08:04.55 | lavender-t | also dzo's vogue doesnt have proc_comm |
| 08:05.23 | tmzt_ | I thought he just implemented it differently |
| 08:05.29 | lavender-t | the clock-7x00.c was copied from the vogue branch |
| 08:06.00 | lavender-t | in the makefile proc_comm.c isnt even compiled. |
| 08:07.20 | tmzt_ | did you see anything relevant in maejrep dmesg's? |
| 08:07.42 | lavender-t | no. |
| 08:07.55 | lavender-t | the clock was probably still not correct for raph800 |
| 08:08.12 | tmzt_ | what does that mean? |
| 08:08.28 | tmzt_ | what could be different or you mean a difference in msm7500? |
| 08:09.00 | lavender-t | i mean the sd clock settings in CLK_CTL registers |
| 08:10.39 | tmzt_ | right, are you saying there is a differnce in msm7500 in those registers? |
| 08:10.56 | tmzt_ | or that different ones are used |
| 08:11.10 | tmzt_ | different clocks are used for the sd card slot |
| 08:12.05 | tmzt_ | lavender-t: should we get netriper to try this first? |
| 08:12.14 | lavender-t | i assumed they are the same for 7201a and 7500 |
| 08:12.46 | lavender-t | but diamond uses a different main freq to drive the clock |
| 08:12.56 | lavender-t | i think. :) |
| 08:13.10 | tmzt_ | so you mean you need to calculate the dividers differently? |
| 08:13.20 | lavender-t | diam is 528MHz, vogue/kaiser is 400MHz |
| 08:13.21 | tmzt_ | swetland referred to pll0 |
| 08:13.41 | lavender-t | ?? |
| 08:14.41 | tmzt_ | hold on |
| 08:15.11 | lavender-t | i can switch to #android if you guys are there. |
| 08:15.21 | swetland | is in various places |
| 08:16.07 | lavender-t | hm .. i'm still getting use to irc ... ;) |
| 08:16.15 | swetland | my suspicion is they'd use pll0 since you don't always want to use the high speed plls if you don't have to and pll0 will always have to be on if the arm9 is on |
| 08:16.35 | swetland | tcxo is 19.2MHz so it's too slow for the high end on sd |
| 08:17.14 | lavender-t | oh ok ... |
| 08:17.30 | swetland | the cpu clock can be divided down from several different plls |
| 08:17.52 | swetland | but most peripherals tend to use tcxo or pll0 (since they're always on and if you *only* use them you're saving power) |
| 08:19.09 | lavender-t | so the CLK_CTL registers controls the divider of the freq fed in which is provided by pll0 ? |
| 08:20.37 | swetland | I believe pll0 is 245760 (based on: http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/acpuclock.c;h=6ea137be23e8dbb5086f4fec42267b32d557b6f9;hb=android-msm-2.6.27) |
| 08:20.44 | lavender-t | from the memory map it says to be sdc1 clock 0xa0/0xa4, etc. |
| 08:21.06 | lavender-t | ok let me check that. |
| 08:21.18 | swetland | or maybe that was the wrong divisor |
| 08:22.30 | swetland | no that's right |
| 08:23.06 | swetland | pll1 768MHz, pll2 1056MHz |
| 08:24.48 | lavender-t | ok i'll look into these plls. |
| 08:25.31 | lavender-t | btw, i wonder if you know how these CLK_CTL + 0xa0/0xa4 registers are supposed to be set ? |
| 08:25.52 | swetland | I'm not sure I'm actually allowed to talk about the clock control block |
| 08:26.10 | tmzt_ | do the proc_comm's also use the dividers? |
| 08:26.11 | maejrep | all hail nda |
| 08:26.24 | swetland | (and would have to dig through the databooks in any case -- don't know the details off the top of my head either way) |
| 08:26.25 | tmzt_ | or do they set the frequency and let amss figure it out |
| 08:26.34 | swetland | the proc comm api just takes frequencies |
| 08:27.14 | lavender-t | i had quite some headache about proc_comm too |
| 08:27.26 | swetland | proc comm is going to be a pain if you're hacking on winmo devices |
| 08:27.38 | swetland | as a bunch of the calls we use for linux were added specifically for linux |
| 08:27.51 | tmzt_ | it seems they have ONRPC.dll interestinly, I thought that was something google did |
| 08:27.51 | swetland | and I have no idea if/when they'll find their way into the builds of amss used for winmo |
| 08:27.54 | lavender-t | oh :( |
| 08:28.14 | *** join/#htc-linux dsr_ro (i=dsr@89.39.110.83) |
| 08:28.35 | swetland | I *think* qualcomm intends for their to eventually be a single codebase and for it all to be unified, but I really don't discuss non-linux support with them ever |
| 08:28.41 | lavender-t | so the proc_comm docs are confidential, i guess ... :( |
| 08:29.24 | tmzt_ | (trying to ask questions that the source can answer but familiarity with the source can make clearer) |
| 08:29.31 | lavender-t | if haret can be made to undo the WM stuff it would be great |
| 08:29.34 | swetland | I'm not aware of any non-marketing docs from qualcomm that are available without an nda |
| 08:31.00 | swetland | our agreement allows us to write GPL drivers for a goodly number of peripherals and distribute that code, so we do that |
| 08:31.11 | lavender-t | ic. the problem for me is that i still cant venture my phone the flash a new boot loader for android |
| 08:31.54 | lavender-t | so i have to rely on haret until the build is in a reasonable good condition. |
| 08:32.00 | swetland | nods |
| 08:33.48 | lavender-t | ok i'll look into the plls first and see. thanks very much for your help swetland |
| 08:33.53 | lavender-t | and tmzt :) |
| 08:34.09 | swetland | good luck |
| 08:34.22 | lavender-t | thanks ! |
| 08:34.42 | swetland | it's fun watching you guys pick apart this stuff. I kinda have to watch at a distance, since I work for a company with relationships with both Qualcomm and HTC ^^ |
| 08:35.37 | *** join/#htc-linux kilian_ (n=kilian@92.66.94.81) |
| 08:35.44 | maejrep | must suck when you have the answers and can't give them ;) |
| 08:36.01 | lavender-t | yeah i understand. :) |
| 08:36.34 | swetland | often I don't even have the answers. the bootloader and radio firmware are mostly black boxes to us. I just complain to HTC or QCT if I need them to work differently |
| 08:38.20 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 08:42.11 | dcordes | swetland, hi |
| 08:43.31 | *** join/#htc-linux ionstorm (n=ion@ip68-228-225-247.ph.ph.cox.net) |
| 08:44.02 | dcordes | swetland, on the trout, how do you set the audio in/out devices (speaker or handset) for phone calls? |
| 08:44.13 | dcordes | proc_comm? |
| 08:45.52 | swetland | rpc |
| 08:47.42 | dcordes | swetland, ok. on the kaiser when you dial without setting anything, you get the speaker |
| 08:49.41 | dcordes | swetland, are the actual commands in the trout kernel or is that in the ril? |
| 08:52.51 | swetland | http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/qdsp5/snd.c;h=8d8b3dbef8306b59a5ff903e14e26f3cd97120b8;hb=android-msm-htc-2.6.25 |
| 08:53.05 | swetland | is the kernel driver that handles passing routing commands to the modem via rpc |
| 08:53.43 | swetland | in android, audio routing is requested through the platform audio apis / audioflinger |
| 08:53.55 | swetland | I don't believe the RIL has any direct involvement |
| 08:54.13 | dcordes | ok so I might look it up |
| 08:54.35 | dcordes | thanks |
| 08:54.36 | dcordes | bbl |
| 08:54.44 | swetland | calls it a night |
| 08:54.47 | swetland | happy hacking, folks |
| 08:55.08 | lavender-t | good night swetland. |
| 09:40.05 | NetRipper | lavender-t, cr2 put the formulas for A0 and A4 on irc last night |
| 09:41.24 | NetRipper | lavender-t, 22:32 at http://irclog.iclem.net/?chan=htc-linux&day=18 |
| 09:42.01 | NetRipper | lavender-t, do you know how to calculate "actual_freq"? |
| 09:43.31 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 09:47.08 | lavender-t | oh cool. i'll look for that ... |
| 09:50.46 | lavender-t | oh man, looks fabulous !! |
| 09:59.45 | tmzt_ | dcordes: I think dzo just did it that way to make it simpler |
| 10:09.48 | jeanseb | hello i got a oops with htc blue angel (self build gpe image) |
| 10:09.52 | jeanseb | anywhere to send them ? |
| 10:13.28 | tmzt_ | OOPS is a kernel thing, so it would help to know what zImage you are using? |
| 10:14.48 | tmzt_ | jeanseb: |
| 10:16.03 | jeanseb | tmzt_, i use a self compile one (bitbake gpe-image) from oe source for angstrom distrib |
| 10:16.32 | tmzt_ | hh.org kernel then |
| 10:16.41 | jeanseb | kernel is 2.6.21-hh20-r23-htcblueangel |
| 10:18.30 | tmzt_ | I don't know where to send them or who is even working on hh20 or blueangel with that kernel |
| 10:18.55 | tmzt_ | there where some lists on handhelds.org and now maybe on linuxtogo.org |
| 10:20.13 | jeanseb | ok thks looking at linuxtogo.org |
| 10:21.58 | tmzt_ | sure, if you have specific questions someone here can try to answer them |
| 10:22.37 | tmzt_ | you might also ask on #oe or #openembedded if the question is about OE/Angstrom |
| 10:22.53 | tmzt_ | (don't know which channel it is) |
| 10:23.05 | jeanseb | join #oe |
| 10:23.20 | jeanseb | ok |
| 10:54.43 | *** join/#htc-linux jeanseb (n=jeanseb@gazypan.dyndns.org) |
| 11:28.51 | *** join/#htc-linux Pit- (n=shark@bidou.eu) |
| 11:31.18 | *** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net) |
| 11:34.35 | *** part/#htc-linux Pit- (n=shark@bidou.eu) |
| 11:53.05 | *** join/#htc-linux Tinyboom (n=nahh@178.80-202-153.nextgentel.com) |
| 12:05.39 | *** join/#htc-linux kiozen (n=oeichler@p5492A189.dip0.t-ipconnect.de) |
| 12:08.39 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 12:40.33 | *** join/#htc-linux Uncle_CM (i=Uncle@gateway/tor/x-b480c0726ba5cabc) |
| 12:47.47 | *** join/#htc-linux LunohoD_ (n=alex@e180076132.adsl.alicedsl.de) |
| 13:34.05 | *** join/#htc-linux rl2000 (n=rl2000@0x573b8b62.hhnqu1.dynamic.dsl.tele.dk) |
| 13:39.00 | *** join/#htc-linux ionstorm (n=ion@ip68-228-225-247.ph.ph.cox.net) |
| 14:44.41 | *** join/#htc-linux EA2 (n=chipper@cpe-024-074-138-191.carolina.res.rr.com) |
| 15:05.17 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87ef2a.pool.einsundeins.de) |
| 15:14.18 | *** join/#htc-linux Xime (n=xime@dag94-3-82-233-170-230.fbx.proxad.net) |
| 15:19.03 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 15:23.08 | *** join/#htc-linux exco (n=exco@e181104124.adsl.alicedsl.de) |
| 15:51.08 | *** part/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 15:51.20 | *** join/#htc-linux pishuri (n=pishuri@users3.ilo.org) |
| 16:15.14 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 16:16.04 | *** join/#htc-linux kiozen_ (n=oeichler@rgnb-5d87cb10.pool.einsundeins.de) |
| 16:17.50 | *** join/#htc-linux toer_ (i=tore@179.81-166-86.customer.lyse.net) |
| 16:27.05 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 17:07.54 | *** join/#htc-linux LunohoD_ (n=alex@e180073177.adsl.alicedsl.de) |
| 17:12.56 | *** join/#htc-linux DusHmaniac (n=not@cp1055556-a.landg1.lb.home.nl) |
| 17:12.57 | *** join/#htc-linux kiozen_ (n=oeichler@rgnb-5d87cfbb.pool.einsundeins.de) |
| 17:14.29 | *** join/#htc-linux kiozen__ (n=oeichler@rgnb-5d87ecb4.pool.einsundeins.de) |
| 17:21.40 | *** join/#htc-linux bertramt (n=chatzill@63.246.89.17) |
| 17:26.02 | *** join/#htc-linux fnord__ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
| 17:29.20 | *** join/#htc-linux Tinyboom (n=nahh@178.80-202-153.nextgentel.com) |
| 17:39.09 | *** join/#htc-linux Uncle_CM (i=Uncle@gateway/tor/x-61fe54c3eb597bc3) |
| 17:50.44 | *** join/#htc-linux fn0rd (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
| 17:56.51 | *** part/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 18:00.04 | *** join/#htc-linux Othello (i=Othello@gateway/tor/x-d5d715e57ab2fac4) |
| 18:01.57 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 18:24.16 | *** join/#htc-linux orux (n=jose@89.130.46.3) |
| 18:27.33 | *** join/#htc-linux Xime (n=xime@dag94-3-82-233-170-230.fbx.proxad.net) |
| 18:28.31 | *** join/#htc-linux [D3-2]Xime (n=xime@dag94-3-82-233-170-230.fbx.proxad.net) |
| 18:49.33 | *** join/#htc-linux hollo (n=hollo@3e6b025d.rev.stofanet.dk) |
| 18:51.31 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
| 19:09.16 | *** join/#htc-linux zsircusr1 (n=dcordes@ip-90-186-24-143.web.vodafone.de) |
| 19:09.53 | zsircusr1 | any raph mmc news? |
| 19:21.11 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
| 19:23.01 | *** join/#htc-linux jeanseb (n=jeanseb@gazypan.dyndns.org) |
| 19:25.33 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 19:59.19 | *** join/#htc-linux Kuma (n=John@f048004117.adsl.alicedsl.de) |
| 20:00.15 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c64a.pool.einsundeins.de) |
| 21:12.26 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 21:29.18 | *** join/#htc-linux nebi (n=nebi@c-d0ed70d5.02-145-7570701.cust.bredbandsbolaget.se) |
| 21:35.22 | dcordes | drops a pin |
| 21:36.36 | *** join/#htc-linux thejigsaw (n=4d1d4d12@67.159.35.76) |
| 21:36.42 | Kensan | hears it touch the floor |
| 21:44.06 | *** join/#htc-linux dante__ (n=dante@151.80.81.80) |
| 22:00.18 | NetRipper | waits until someone steps onto it |
| 22:02.44 | dcordes | NetRipper, raph800 at works? |
| 22:04.57 | NetRipper | i haven't posted instructions on the forum yet |
| 22:05.15 | NetRipper | i'll do that somewhere tonight |
| 22:06.47 | *** join/#htc-linux kiozen_ (n=oeichler@rgnb-5d87c931.pool.einsundeins.de) |
| 22:06.58 | NetRipper | i heard you dont even have a sim card on cmda |
| 22:07.39 | dcordes | yea |
| 22:07.46 | *** join/#htc-linux Uncle_CM (i=Uncle@gateway/tor/x-f07ea6964d24d993) |
| 22:08.43 | tmzt_ | cdma uses an ESN which is registered with the carrier |
| 22:10.12 | NetRipper | like a network IMEI? |
| 22:12.18 | tmzt_ | yes, ESN is like IMEI, the ESN is given to the network and put in their database, then the phone can register using that ESN and MIN (phone number) |
| 22:12.36 | NetRipper | ah |
| 22:12.51 | NetRipper | so no easily switching to a new phone |
| 22:13.04 | tmzt_ | no |
| 22:13.32 | tmzt_ | you have to call and give another esn for another phone and it has to be one the support (usually one they sold) |
| 22:33.01 | toer | lo |
| 22:46.33 | tmzt_ | wasabi: which phone did you get? |
| 22:46.44 | wasabi | android dev phone |
| 22:46.56 | tmzt_ | I thought that came with root access |
| 22:47.12 | tmzt_ | have you looked into openchange.org ? |
| 22:49.04 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 22:49.27 | wasabi | dunno what that's aout |
| 22:49.45 | tmzt_ | exchange client with samba 4 |
| 22:49.51 | wasabi | or how it relates to a phone |
| 22:50.22 | tmzt_ | it runs on linux can be compiled for arm (probably, maybe needs a little work) |
| 22:51.15 | wasabi | not really related to activesync at all. |
| 22:51.18 | tmzt_ | I think one of the features is an imap proxy so that might be all that's needed for android, but it really needs an evolution or evolution-data-server compatible mail program |
| 22:51.21 | wasabi | this is a mapi implementation |
| 22:51.22 | tmzt_ | activesync? |
| 22:51.32 | tmzt_ | what are you trying to do? |
| 22:51.37 | wasabi | yeah. exchange phone stuff is 'activesync'. it's http-based |
| 22:51.46 | wasabi | Just get email/calendar/contacts on phone. |
| 22:51.54 | tmzt_ | look at synce.sf.net sync-engine |
| 22:52.01 | tmzt_ | from outlook? |
| 22:52.05 | wasabi | that's desktop stuff. |
| 22:52.07 | wasabi | no server stuff. |
| 22:52.16 | wasabi | like iphones, and windows mobile devices. push mail. |
| 22:52.22 | wasabi | and blackberries. |
| 22:52.25 | wasabi | and all the others. |
| 22:52.34 | tmzt_ | it's an airsync implementation/state machine |
| 22:53.11 | wasabi | yeah, so not really what i'm looking for. i don't know anybody who uses desktop active sync from work anymore. |
| 22:53.19 | wasabi | everybody uses over the air push stuff |
| 22:53.47 | tmzt_ | I'm saying it implements the airsync http protocol, whether it can be used as a server or not I don't know |
| 22:53.55 | wasabi | what is airsync? |
| 22:54.24 | tmzt_ | I don't know of any way to use a self-signed certificate with a wm5 phone so I never tried it with anything other than an rndis connection (and bluetooth pan) |
| 22:54.48 | tmzt_ | airsync is the microsoft protocol for activesync over HTTP |
| 22:55.39 | tmzt_ | does aku3 push use a sms message? |
| 22:55.47 | wasabi | alu3? |
| 22:55.48 | wasabi | aku |
| 22:55.56 | tmzt_ | wm5 update that added push-mail |
| 22:55.59 | wasabi | no. |
| 22:56.04 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 22:56.14 | wasabi | over the air active sync has been supported much longer than 5. |
| 22:56.19 | wasabi | it's just HTTP. phone keeps a socket open for a poll. |
| 22:56.35 | wasabi | Basically issuse a blocking HTTP request that waits forever. |
| 22:56.53 | wasabi | I think back in vs 4 or something they did a txt message to initiate push. |
| 22:56.57 | tmzt_ | ok, sync-engine implements the server side of the protocol in python and basically describes the protocol |
| 22:57.04 | wasabi | hmm. well that's interesting. |
| 22:57.35 | wasabi | so i guess that's what needs to be written then. a calendar and contact client that uses it. |
| 22:58.18 | tmzt_ | I guess so, I don't know how android stores the data or if it can be accessed from an authorized (privledged) application |
| 22:58.25 | tmzt_ | but it seems funmobil? does |
| 22:58.29 | wasabi | what data? |
| 22:58.37 | tmzt_ | contacts/calendar |
| 22:58.46 | wasabi | oh. got me. i think it's all service-based. |
| 22:58.58 | wasabi | as in, there are calendar and contact services... of which you can have more than one. |
| 22:59.17 | wasabi | so you don't access teh data. you just write a new app that exposes more. |
| 22:59.47 | tmzt_ | ok, so it would be an airsync client that serves as a provider (a bit like a MAPI provider)? |
| 23:00.08 | wasabi | I'd leave mapi out of the discussion. it just confuses things. |
| 23:00.18 | wasabi | I think it exposes an interface with something similar to getContacts() |
| 23:00.41 | wasabi | Where IContact or whatever defines common info |
| 23:00.53 | wasabi | So you'd write an app that syncs in the background. |
| 23:01.03 | wasabi | it's own data store. it's own contact list. |
| 23:01.07 | wasabi | but other apps would have access to them |
| 23:02.02 | tmzt_ | using sqlite? |
| 23:02.03 | wasabi | me->bar =) |
| 23:02.07 | wasabi | yeah. probably. |
| 23:02.12 | wasabi | it's all javay |
| 23:02.18 | wasabi | so it's all wrapped. you don't write native apps. |
| 23:02.21 | wasabi | you're not even allowed to |
| 23:02.32 | wasabi | without rooting the phone and stuff. |
| 23:02.48 | wasabi | but the onlyway to integrate with any of the important services is with the proper java-like API |
| 23:03.20 | tmzt_ | right, with the storage apis android provides, what I meant by sqlite |
| 23:04.26 | wasabi | i found a real great imap client. k9. it's a fixup of the built in one. |
| 23:04.37 | wasabi | runs really quick |
| 23:04.52 | tmzt_ | but still no contacts/calendars |
| 23:05.11 | tmzt_ | does push (idle) work with exchange? |
| 23:05.32 | wasabi | Yes. |
| 23:05.37 | wasabi | Oh you mean IMAP |
| 23:05.41 | wasabi | no the imap client doesn't do IDLE |
| 23:05.47 | tmzt_ | k9 doesn't? |
| 23:05.49 | wasabi | I sent a message to the dev telling him to add it |
| 23:05.52 | wasabi | nope |
| 23:06.20 | wasabi | the ui works really nice. pops up quick, requests the top 25 messages at a time. |
| 23:06.29 | wasabi | so it doesn't freeze up |
| 23:06.42 | wasabi | it's faster than evolution. =9 |
| 23:12.09 | *** join/#htc-linux Moku (n=John@f048004117.adsl.alicedsl.de) |
| 23:53.51 | *** join/#htc-linux miknix (n=miknix@81.193.80.227) |