| 00:39.50 | *** join/#htc-linux imfloflo (n=moi@83.25.71-86.rev.gaoland.net) |
| 00:48.04 | *** join/#htc-linux imfloflo_ (n=moi@83.25.71-86.rev.gaoland.net) |
| 00:52.01 | *** join/#htc-linux sabrod (n=sabrod@mic92-8-82-234-143-184.fbx.proxad.net) |
| 01:48.16 | *** join/#htc-linux MrPippy (n=pip@adsl-75-37-163-177.dsl.sndg02.sbcglobal.net) |
| 01:53.37 | *** join/#htc-linux jyoshm (n=jmissao@unaffiliated/sundial) |
| 02:18.36 | *** join/#htc-linux SOG (n=SOG@n219079053207.netvigator.com) |
| 02:44.52 | *** join/#htc-linux ellisway (n=ellis@78.86.162.166) |
| 02:51.45 | *** join/#htc-linux opensaurus (n=ogr3@adsl-99-41-57-24.dsl.lsan03.sbcglobal.net) |
| 03:05.52 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 03:14.50 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 04:08.15 | *** join/#htc-linux Moku (n=John@f048230103.adsl.alicedsl.de) |
| 04:25.41 | *** join/#htc-linux droid0011 (n=g1@p4FDCF095.dip.t-dialin.net) |
| 04:35.30 | *** join/#htc-linux Daemon_ (n=DaemonES@195.238.92.163) |
| 04:56.43 | *** join/#htc-linux rafyvitto (n=rafyvitt@24.54.253.34) |
| 06:24.55 | *** join/#htc-linux ArteK (n=Artur@81.15.241.96) |
| 06:30.55 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) |
| 06:36.11 | *** join/#htc-linux stickboy (n=anonymou@128.153.210.35) |
| 06:46.11 | *** join/#htc-linux Daemon_ (n=DaemonES@195.238.92.163) |
| 07:01.25 | *** join/#htc-linux stickboy (n=anonymou@128.153.211.117) |
| 07:14.32 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 07:23.51 | *** join/#htc-linux kiozen (n=kiozen@93.135.76.56) |
| 07:51.45 | *** join/#htc-linux pH5 (n=ph5@e178218122.adsl.alicedsl.de) |
| 08:01.51 | *** join/#htc-linux Amaranth_ (n=travis@ubuntu/member/Amaranth) |
| 08:13.38 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 08:46.19 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-76-254.web.vodafone.de) |
| 08:46.28 | cr2 | hi |
| 08:48.11 | cr2 | the 3000fffe rpc seems to have some special role in managing the rpc calls. |
| 08:48.25 | cr2 | like fffffffe aka router |
| 08:50.18 | cr2 | and we need to deal gracefully with its *ept |
| 08:50.48 | cr2 | initialized exactly after the router init. |
| 08:55.15 | *** join/#htc-linux xperia (n=chatzill@80-218-229-51.dclient.hispeed.ch) |
| 08:55.22 | xperia | hello cr2 |
| 08:55.29 | cr2 | hi xperia |
| 08:55.59 | xperia | cr2 i have some new hot stuff for you about audio and drivers. interessted ? |
| 08:56.06 | cr2 | sure |
| 08:56.30 | xperia | give me just a moment please so i can send you the info. |
| 08:57.17 | cr2 | rpc_clnt_lookup2... |
| 08:58.38 | cr2 | ok. L1 is fore registering the client. |
| 08:59.00 | cr2 | L2 is lookup2 |
| 09:00.18 | cr2 | lookup is lookup2(3000fffe,0,-1) |
| 09:00.54 | cr2 | it's something new. not like g1 code. |
| 09:04.12 | tmzt | hey |
| 09:04.19 | tmzt | saw your pastes |
| 09:05.09 | cr2 | tmzt: hi. i'm inside the wince rpc implementation |
| 09:06.09 | tmzt | found a resolver? |
| 09:09.04 | cr2 | tmzt: yes. now i need to decide how to deal with it. |
| 09:11.58 | cr2 | Line: 1299. rpc_router_os_wm: Calling RPC_Init()! |
| 09:12.18 | cr2 | Line: 1422. rpc_router_core rpc_router_open'ing: Processor:0x00000001, Process:0xfffffff |
| 09:12.38 | cr2 | Line: 1440. rpc_router_core rpc_router_open'ed: Processor:0x00000001, Process:0xfffffffe |
| 09:12.52 | cr2 | Line: 1062. rpc_router_os_wm: IOCTL code = 30010014 |
| 09:13.18 | cr2 | ONCRPC.dll attached |
| 09:13.20 | cr2 | [RPC] n 0 af7fbfb2 6206 |
| 09:13.41 | cr2 | Line: 1062. rpc_router_os_wm: IOCTL code = 30010008 |
| 09:13.42 | cr2 | Line: 188. rpc_router_database: dup server registration. Prog: 3000ffff, Ver: 0. |
| 09:14.17 | cr2 | [RPC] n 1 af4fbede 6335 |
| 09:14.19 | cr2 | [RPC]L1 50e48370 af4fbede |
| 09:14.20 | cr2 | ONCRPC task running. |
| 09:15.26 | tmzt | but server registration on amss side is automatic |
| 09:16.30 | cr2 | this is for client *ept |
| 09:17.12 | cr2 | [RPC]L2 50e48f70 af7fbfb2 |
| 09:17.13 | cr2 | Line: 1062. rpc_router_os_wm: IOCTL code = 30010010 |
| 09:17.15 | cr2 | [RPC] s 50e48f70 50e48e30 |
| 09:17.16 | cr2 | [RPC] i 50e48f70 50e48e30 |
| 09:17.34 | cr2 | hmm. they could have created a more user-friendly dmesg :) |
| 09:17.46 | x29a | lol |
| 09:19.02 | cr2 | x29a: yeah. by dereferencing the pointers |
| 09:27.34 | tmzt | what is this? just kitl output? |
| 09:28.07 | cr2 | yes |
| 09:29.06 | cr2 | [D:GPS] GPS: [NMEAThread] +++ Wait for PosReqSentEvent |
| 09:30.18 | tmzt | how are you able to dump the structures? |
| 09:30.34 | cr2 | tmzt: how do we talk to the resolver ? |
| 09:30.41 | cr2 | Line: 1062. rpc_router_os_wm: IOCTL code = 30010008 |
| 09:30.42 | cr2 | Line: 188. rpc_router_database: dup server registration. Prog: 3000ffff, Ver: 0. |
| 09:30.47 | cr2 | which structures ? |
| 09:32.27 | tmzt | the pointers you referred to |
| 09:32.51 | cr2 | not easy |
| 09:33.17 | tmzt | we don't have headers |
| 09:33.27 | tmzt | vdump works? |
| 09:33.50 | cr2 | it's a temporary buffer |
| 09:34.03 | cr2 | you need some debugger infrastructure around |
| 09:34.04 | tmzt | oh |
| 09:34.18 | cr2 | msm may be difficult |
| 09:34.37 | cr2 | i think on pxa something like that is already doable |
| 09:35.22 | cr2 | tmzt: how does the rpc resolver work on g1 ? |
| 09:36.01 | tmzt | is there one? |
| 09:36.03 | cr2 | hm. we just send us the hello router msg ? |
| 09:36.23 | cr2 | and pick the full amss server list |
| 09:36.33 | cr2 | looks like a wild hack to me ;) |
| 09:36.52 | tmzt | yes |
| 09:37.00 | tmzt | 07:38 < cr2> hm. we just send us the hello router msg ? |
| 09:37.03 | tmzt | yeah |
| 09:37.09 | tmzt | we fake it |
| 09:37.35 | xperia | sorry for this question but does keyboard backlight or leds works on raphael ? if yes is the gpio 86 the power gpio for microp or does raph dont need power gpio for backlight or leds. |
| 09:37.43 | xperia | i am reffering to this here |
| 09:37.52 | xperia | if (machine_is_htcraphael()) { |
| 09:37.53 | xperia | raphael_keypad_resources[0].start = MSM_GPIO_TO_INT(27); |
| 09:37.55 | xperia | raphael_keypad_resources[0].end = MSM_GPIO_TO_INT(27); |
| 09:37.57 | xperia | raphael_keypad_data.clamshell.gpio = 38; |
| 09:37.59 | xperia | raphael_keypad_data.clamshell.irq = MSM_GPIO_TO_INT(38); |
| 09:38.00 | xperia | raphael_keypad_data.backlight_gpio = 86; |
| 09:38.02 | xperia | msm_hsusb_pdata.phy_init_seq = halibut_phy_init_seq_raph100; |
| 09:38.03 | xperia | } |
| 09:38.34 | cr2 | xperia: kbd backlight works |
| 09:39.52 | cr2 | tmzt: now, if it would have been possible to capture the rpccall smem fifo at bootup ... |
| 09:40.33 | tmzt | we need early haret for that |
| 09:41.39 | xperia | a possibility would be also modifying the driver by adding some new stuff that copy stuff to a memmory space that is not changed. |
| 09:42.13 | xperia | correction (that copy the data to a memory space) |
| 09:42.17 | cr2 | xperia: add the power gpio to the pdev struct |
| 09:42.35 | cr2 | xperia: so it'll be not used on raph. at least right now. |
| 09:43.21 | tmzt | jpower gpio? |
| 09:45.03 | cr2 | power or reset for microp |
| 09:46.31 | xperia | how about the struct microp_keypad_platform_data that holds nearly all needed variables like gpio for the keys, irqs and so on |
| 09:46.32 | cr2 | tmzt: so, the wince rpc implementation is different from g1 |
| 09:47.41 | cr2 | xperia: clamshell ? does it belong to microp ?? |
| 09:48.14 | tmzt | cr2: looks like it |
| 09:49.10 | cr2 | tmzt: they do a lookup2 for PROG first |
| 09:49.34 | cr2 | tmzt: get the *ept from it and then send a message |
| 09:50.05 | cr2 | hmm. msm_rpc_connect() ? |
| 09:50.58 | xperia | cr2: i have two microp's |
| 09:51.00 | xperia | [K] MicroP1Version=0x787 / Keybaord with Keyboard Led backlight |
| 09:51.01 | xperia | [K] MicroP2Version=0x707 / Leds and LCD |
| 09:51.24 | cr2 | xperia: microp48 and microp88 ? |
| 09:52.14 | xperia | never heared about microp48 and microp88 but this are the microp-ksc 787 driver and microp-klt driver 707 |
| 09:52.33 | xperia | does microp48 and microp88 exist somewhere |
| 09:52.37 | tmzt | those are atmel models |
| 09:52.38 | cr2 | ksc and klt are wince names |
| 09:53.15 | xperia | the starnge things is that the drivers are heavy overloaded with stuff from other devices like htc-shift |
| 09:53.27 | cr2 | ? |
| 09:53.35 | xperia | especially for the keypad driver |
| 09:54.08 | xperia | if you analyze the keypad driver you will find a lot of stuff for the htc-shift |
| 09:54.31 | xperia | like sound on slider the is not implemented in the htc kovsky device |
| 09:54.31 | tmzt | everything is reused |
| 09:55.09 | xperia | other things are function that are not used but stay in the driver |
| 09:55.17 | cr2 | htc does not care about the clean code |
| 09:55.33 | cr2 | they care about just some working code |
| 09:55.48 | xperia | about 40% of the code is useless |
| 09:56.17 | cr2 | *cough* msvc *cough* |
| 09:56.37 | *** join/#htc-linux tsdogs (n=tsdogs@tsdogs.metalit.net) |
| 09:56.42 | cr2 | +cut and paste |
| 09:58.02 | xperia | i think for your problem the best is modifying the driver with about two or tree lines that pipe the data to a memory space. that is the most easy solution to trace everything |
| 09:58.21 | xperia | for the driver related |
| 09:59.02 | cr2 | binary patching the dll ? |
| 10:00.25 | xperia | yeah. i am not a ida pro expert but it should provide this possibility at least there are some debug and runtime test possibility for the 0x86 platform |
| 10:00.28 | tmzt | yeah |
| 10:00.33 | tmzt | not that easy |
| 10:01.04 | cr2 | you can't use userspace debugger for kernel drivers |
| 10:01.15 | tmzt | well |
| 10:01.25 | tmzt | they aren't kernel drivers |
| 10:01.32 | tmzt | are they? |
| 10:04.48 | xperia | cant say about microp1 and microp2 and the rpc stuff. i know that big stuff is handled in userspace for the htc-kovsky device |
| 10:05.20 | xperia | especially the led notification. Backlight is also userspace |
| 10:05.29 | xperia | on event |
| 10:07.29 | xperia | me studying at the moment power gpio for backlight |
| 10:20.16 | cr2 | ok, it seems that we need to connect some dummy client for 3000ffff |
| 10:20.40 | cr2 | which will get some messages from amss |
| 10:22.26 | cr2 | lookup is 3000fffe, but i don't see it being used by drivers. |
| 10:26.10 | *** join/#htc-linux varza (n=kvirc@188.26.161.255) |
| 10:32.58 | *** join/#htc-linux Bally3 (n=Bally3@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 10:33.23 | xperia | ln which dll can this here be handled? SetMicroPPower+. bOn:1, bStateOn:0 |
| 10:34.12 | xperia | keypad, backlight and led dont have "SetMicroPPower" |
| 10:35.00 | cr2 | xperia: oem_misc ioctl ? |
| 10:35.27 | xperia | thanks for the hint have to try it ! |
| 10:52.26 | cr2 | clk_regime_msm_sel_camclk(24MHz) |
| 11:09.07 | *** join/#htc-linux x29a_ (n=x29a@unaffiliated/x29a) |
| 11:09.45 | xperia | have to make a litle break. will come back in ca. 45 minutes. bye |
| 11:20.07 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 11:23.07 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 11:23.47 | *** join/#htc-linux idkfa (n=sergey@87.228.4.172) |
| 11:24.02 | *** join/#htc-linux timebomb (n=tb@e179198227.adsl.alicedsl.de) |
| 11:38.30 | *** join/#htc-linux Amaranth_ (n=travis@ubuntu/member/Amaranth) |
| 11:54.27 | *** join/#htc-linux federasta (n=fede@host-84-222-83-99.cust-adsl.tiscali.it) |
| 11:54.53 | federasta | hello! |
| 11:56.26 | federasta | any one that get one version of linux on the trinity with success? |
| 11:58.22 | federasta | thanks |
| 11:58.28 | *** part/#htc-linux federasta (n=fede@host-84-222-83-99.cust-adsl.tiscali.it) |
| 12:10.05 | *** join/#htc-linux yaz (n=yaz@93.2.146.224) |
| 12:44.26 | cr2 | point sequence=time+brightness |
| 12:53.47 | *** join/#htc-linux luc__ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 13:05.00 | *** join/#htc-linux SOG (n=SOG@n058152151113.netvigator.com) |
| 13:05.56 | *** join/#htc-linux luc__ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 13:06.40 | *** join/#htc-linux xiroxz (n=xiroxz@c-a7b5e355.025-52-6f72653.cust.bredbandsbolaget.se) |
| 13:06.46 | xiroxz | Hello |
| 13:09.33 | *** join/#htc-linux XorA|gone (n=nnXorA@www.xora.org.uk) |
| 13:10.07 | *** join/#htc-linux otwieracz (n=otwierac@host86-162-234-54.range86-162.btcentralplus.com) |
| 13:10.10 | otwieracz | Hello. |
| 13:10.51 | otwieracz | Can anybody tell me what is status of porting linux to HTC Tornado? |
| 13:16.12 | cr2 | otwieracz: ask in #linwizard |
| 13:34.21 | *** join/#htc-linux luc__ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 13:38.30 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
| 13:41.44 | Echo31 | cr2: Hi |
| 13:44.11 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) |
| 13:44.49 | *** join/#htc-linux Amaranth_ (n=travis@ubuntu/member/Amaranth) |
| 13:46.05 | *** join/#htc-linux Moku (n=John@g227172214.adsl.alicedsl.de) |
| 13:54.31 | *** join/#htc-linux Shinto (n=John@g228193211.adsl.alicedsl.de) |
| 14:09.37 | *** join/#htc-linux ogr3_ (n=ogr3@adsl-99-41-57-24.dsl.lsan03.sbcglobal.net) |
| 14:18.20 | *** join/#htc-linux druidu (n=druidu@78.97.155.94) |
| 14:18.43 | druidu | hello there |
| 14:22.26 | druidu | cr2 online? |
| 14:25.50 | *** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
| 14:26.20 | Captnoord | major commits on the repo.... |
| 14:26.23 | Captnoord | because of merge? |
| 14:26.28 | Captnoord | google commits? |
| 14:27.52 | Captnoord | hey cr2 your online? |
| 14:31.55 | otwieracz | Hmm. There is nobody on #linwizard :) |
| 14:32.33 | Captnoord | hehe |
| 14:32.38 | druidu | what repo? |
| 14:32.41 | Captnoord | maybe I should read the irc logs |
| 14:32.42 | Captnoord | nvm |
| 14:32.51 | Captnoord | instead of asking right away |
| 14:32.52 | Captnoord | nah |
| 14:33.06 | Captnoord | new linux kernel branch |
| 14:33.19 | Captnoord | .29 i guess it was |
| 14:34.12 | druidu | ah, branch htc-msm-2.6.29 |
| 14:34.23 | Captnoord | yup |
| 14:34.24 | Captnoord | nah |
| 14:34.31 | Captnoord | it was long ago I updated... |
| 14:34.32 | Captnoord | so |
| 14:34.46 | Captnoord | spend a very long time working........ :( |
| 14:35.28 | druidu | actually, it has none of our patches |
| 14:35.37 | Captnoord | I see |
| 14:35.39 | druidu | just board-halibut board-trout and board-sapphire |
| 14:35.47 | druidu | sapphire was released on developer.htc.com too |
| 14:35.47 | *** join/#htc-linux shafty (n=kvirc@66-90-130-225.grandecom.com) |
| 14:36.18 | shafty | hey anyone have a hero rom loaded on their phone? Need a file from it as I'm trying to backport htc chirp |
| 14:37.11 | Captnoord | hmmm k... as long as there is a bit more info..... the way I see it is like the Periodic table of elements.... even that they didn't had 1 they could predict how it behavus and its spec's because of they knew the one's that where close.... |
| 14:37.13 | Captnoord | so the more info we got |
| 14:37.20 | Captnoord | the more we know the variants |
| 14:37.26 | Captnoord | still time consuming |
| 14:37.27 | Captnoord | but |
| 14:37.36 | Captnoord | now need to finish my work |
| 14:37.38 | Captnoord | so |
| 14:37.44 | Captnoord | will hang around for a bit |
| 14:38.16 | Captnoord | shafty: this is linux dev..... nothing related to rom's |
| 14:38.24 | Captnoord | maybe try |
| 14:38.30 | Captnoord | woeps |
| 14:38.31 | Captnoord | sorry |
| 14:38.43 | Captnoord | isn't the hero stuff public? |
| 14:38.54 | Captnoord | or can't you just parse the hero rom to get the file? |
| 14:39.16 | shafty | ah ok |
| 14:39.22 | Captnoord | because isn't it a remote file system |
| 14:39.27 | Captnoord | so you would be able to load that |
| 14:39.30 | Captnoord | and pick the file |
| 14:39.32 | shafty | no the file is only available from an actual hero installation |
| 14:39.42 | Captnoord | isn't there a dump somewhere? |
| 14:39.59 | shafty | it's not on the ROM itself, it's in /data/data after an actual installation |
| 14:40.15 | shafty | it's htcchirp.db |
| 14:40.35 | shafty | looks like no one has backported it and I figured out how |
| 14:40.38 | shafty | just need the file |
| 14:40.45 | Captnoord | but doesn't the dump contain it? |
| 14:40.46 | druidu | weee, I see we have sharp panel startup code in new branch |
| 14:40.47 | Captnoord | hmmm..... |
| 14:40.56 | druidu | *powerup code |
| 14:40.58 | shafty | there aren't any "dumps" avail |
| 14:41.04 | shafty | just ROM's |
| 14:41.09 | Captnoord | druidu: thats nice..... :D energy saving stuff |
| 14:41.19 | Captnoord | and the rom's doesn't contain the info you need? |
| 14:41.23 | shafty | dumps would be like a tar of / |
| 14:41.39 | *** join/#htc-linux Moku (n=John@g228133232.adsl.alicedsl.de) |
| 14:41.42 | druidu | not only that, but maybe we can start it up from scratch (preparing for a stand-alone kernel image) |
| 14:41.50 | shafty | nope, /data/data is created after booting up the phone and the package installer has installed all the apks in /data/app |
| 14:42.17 | shafty | hence, this could only come from a phone running hero |
| 14:43.38 | Captnoord | druidu: where? |
| 14:43.45 | Captnoord | shafty: maybe I can help ya |
| 14:43.48 | Captnoord | lol |
| 14:43.49 | Captnoord | nah |
| 14:43.50 | Captnoord | sorry |
| 14:43.52 | Captnoord | he has a g1 |
| 14:44.02 | shafty | a g1 running hero is what I need |
| 14:44.14 | Captnoord | hmmmm |
| 14:44.17 | shafty | I had mine on a hero rom yesterday and decided to go back to a cupcake build |
| 14:44.21 | Captnoord | lemme e-mail someone |
| 14:44.26 | shafty | k thanks |
| 14:44.27 | druidu | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/board-sapphire-panel.c;h=b2030c091337653bdb74afcd87a012c8a8511291;hb=htc-msm-2.6.29 |
| 14:44.30 | shafty | the file is.... |
| 14:44.52 | Captnoord | thanks |
| 14:44.56 | Captnoord | I will check in a moment |
| 14:45.01 | Captnoord | need to finish this |
| 14:45.01 | Captnoord | :P |
| 14:45.08 | shafty | k |
| 14:45.32 | druidu | /* Initial sequence of sharp panel with Novatek NT35399 MDDI client */ |
| 14:45.54 | druidu | diamond had a sharp panel right? |
| 14:47.25 | Captnoord | that I don't know / can't remember |
| 14:47.52 | otwieracz | Anybody can help me build Angstrom for Tornado? |
| 14:48.59 | *** part/#htc-linux ArteK (n=Artur@81.15.241.96) |
| 14:49.30 | Captnoord | Hitachi (5), Sharp(0xa) or Toppoly(2,0x11). |
| 14:49.59 | Captnoord | for the raph |
| 14:50.10 | Captnoord | and diamond and raph is same base |
| 14:51.28 | Captnoord | but those have'nt got the sharp I guess |
| 14:51.31 | Captnoord | nah |
| 14:51.40 | Captnoord | there are some people around who know that better |
| 14:52.12 | Captnoord | but the sharps can be improved with the code hell yea |
| 14:52.13 | Captnoord | :P |
| 14:53.14 | *** join/#htc-linux Shinto (n=John@f049159140.adsl.alicedsl.de) |
| 15:06.59 | Captnoord | cr2 gj on the ati stuff |
| 15:11.49 | *** join/#htc-linux root (n=root@cBEA15AC1.dhcp.bluecom.no) |
| 15:13.52 | *** join/#htc-linux rashire2 (n=ed1112wa@pool-98-114-226-103.phlapa.fios.verizon.net) |
| 15:40.35 | cr2 | hi druidu |
| 15:40.39 | Squarc | hey there |
| 15:40.57 | Squarc | is there any new stuff to test on the diam ? |
| 15:41.11 | cr2 | Captnoord: i've looked at all dlls once again |
| 15:41.31 | cr2 | Squarc: nothng new yet |
| 15:41.39 | Squarc | cr2: ok thx |
| 15:41.58 | cr2 | we need to fix the known code bugs first |
| 15:42.10 | cr2 | druidu: you have diam100 ? |
| 15:48.17 | Echo31 | cr2: Hi |
| 15:54.49 | cr2 | hi Echo31 |
| 15:55.23 | druidu | hehe, welcome back cr2 |
| 15:55.23 | druidu | yep, diam100 |
| 15:56.33 | druidu | with a partially fucked up touchscreen (occasionally all hits are registered on the leftmost column whatever I do, probably a hardware problem) |
| 15:57.34 | *** join/#htc-linux marex (n=marex@thor.hackndev.com) |
| 15:57.44 | Echo31 | cr2: have you received the bundle updated ? |
| 15:58.50 | *** join/#htc-linux MethoS- (n=clemens@host-091-096-213-004.ewe-ip-backbone.de) |
| 16:00.20 | druidu | anyway, who's up for a quick review of the current situation, what needs to be done to get various features working, a little roadmap |
| 16:04.04 | *** join/#htc-linux pH5 (n=ph5@g229140222.adsl.alicedsl.de) |
| 16:04.10 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-76-254.web.vodafone.de) |
| 16:04.28 | *** join/#htc-linux mrb__ (n=mrb@160.89-10-30.nextgentel.com) |
| 16:04.38 | druidu | cr2 you got the last thing I said? |
| 16:07.40 | *** join/#htc-linux ogr3__ (n=ogr3@adsl-99-41-58-215.dsl.lsan03.sbcglobal.net) |
| 16:08.35 | cr2 | druidu: yes. looks strange though. |
| 16:09.05 | druidu | what looks strange? |
| 16:09.14 | cr2 | Echo31: what bundle ? |
| 16:09.17 | druidu | the touscreen thing? |
| 16:09.26 | druidu | *touchscreen |
| 16:09.41 | cr2 | druidu: that it still works, but in such a strange way |
| 16:09.45 | cr2 | yes |
| 16:09.59 | Captnoord | cr2: and did the dll's gave away new stuff? |
| 16:10.11 | Echo31 | PH5: cr2: I sent a athena patch bundle |
| 16:10.38 | cr2 | Echo31: ok, i'll look at it |
| 16:11.07 | druidu | the weird thing is that sometimes it works perfectly... and sometimes the X component is always 0 or smth like that, and if I try calibration in WM it won't even work because of that |
| 16:11.09 | cr2 | Captnoord: nothing groundbreaking, but we may fix many things here and there |
| 16:11.13 | druidu | anyway, I was saying |
| 16:11.20 | druidu | who's up for a quick review of the current situation, what needs to be done to get various features working, a little roadmap... |
| 16:11.38 | Captnoord | cr2: its usualy the details that causes big bugs..... |
| 16:11.46 | druidu | should we port to 2.6.29? |
| 16:11.55 | cr2 | druidu: the lcd powerup/down |
| 16:12.05 | cr2 | druidu: why not. |
| 16:12.12 | druidu | there is new lcd powerup/down code in the new branch |
| 16:12.19 | druidu | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/board-sapphire-panel.c;h=b2030c091337653bdb74afcd87a012c8a8511291;hb=htc-msm-2.6.29 |
| 16:12.25 | druidu | for hitachi & sharp |
| 16:12.38 | pH5 | Echo31: cool. I'll have a look, but I won't be able to apply it until next week. |
| 16:12.39 | druidu | don't remember which panel diamond and raphael used |
| 16:12.46 | cr2 | yes, but it still needs many fixes on out side |
| 16:12.57 | pH5 | n810 is too memory starved for kernel git |
| 16:13.10 | cr2 | druidu: do a reset and dump the wince dmesg. i think it was hitachi |
| 16:13.31 | Captnoord | I think I can get myself a diamond... as a friend of mine is getting a new phone |
| 16:13.32 | Captnoord | :P |
| 16:14.41 | druidu | wince dmesg? how do I do that? |
| 16:14.43 | cr2 | druidu: the clock-wince.c needs some major rewrite because it misses a whole class of clocks. |
| 16:15.00 | druidu | do we have specs for them? |
| 16:15.12 | cr2 | druidu: it's 1M sdram @0x17600000 (i think) |
| 16:15.32 | cr2 | no specs, but solid research. |
| 16:15.50 | cr2 | i'll try to update the wiki with newer information |
| 16:16.32 | cr2 | the keyboard leds on raph100 are different from raph800, but it's a minor thing |
| 16:17.07 | cr2 | i've just updated the KSC/KLT wiki. we may check what is missing in the current driver |
| 16:17.37 | cr2 | there are some DEX calls that needs to be tested |
| 16:18.10 | cr2 | and some code bugfixes, that are just waiting for dcordes, or whoever has git write access |
| 16:18.32 | druidu | I have git write access too |
| 16:18.41 | druidu | don't you have an account? |
| 16:19.00 | cr2 | great. then i'll try to merge the fixes |
| 16:19.11 | druidu | actually, commit access, not sure what you need |
| 16:19.13 | cr2 | will you be here in the evening ? |
| 16:19.36 | cr2 | yes, ill write a patch, you'd commit it. |
| 16:19.54 | druidu | I'll be here |
| 16:20.08 | druidu | so, what do we need to make calls work properly? (including audio) |
| 16:20.14 | cr2 | audiomgr params, arm11 halt, bt clocks just come into my mind |
| 16:20.33 | cr2 | ok. |
| 16:20.34 | cr2 | bbl |
| 16:20.40 | druidu | ok, bye |
| 16:25.45 | druidu | anybody know why page http://wiki.xda-developers.com/index.php?pagename=RaphaelMemoryMap doesn't work anymore? |
| 16:26.56 | otwieracz | I have problem with linux under tornado, when booting up i have white screen. Whats wrong? |
| 16:27.49 | *** join/#htc-linux phh (n=quassel@lns-bzn-50f-81-56-224-142.adsl.proxad.net) |
| 16:33.20 | *** join/#htc-linux martling (n=martin@the.earth.li) |
| 16:34.29 | *** join/#htc-linux Moku (n=John@f048020177.adsl.alicedsl.de) |
| 16:34.47 | *** join/#htc-linux niccoswe (n=niccoswe@78-70-202-58-no156.tbcn.telia.com) |
| 16:36.08 | *** join/#htc-linux rafyvitto (n=rafyvitt@24.54.253.34) |
| 16:41.08 | *** join/#htc-linux Gnutoo (n=gnutoo@ABordeaux-152-1-40-189.w83-193.abo.wanadoo.fr) |
| 16:47.30 | otwieracz | 17:26:56 < otwieracz> I have problem with linux under tornado, when booting up i have white screen. Whats wrong? |
| 16:47.54 | *** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey) |
| 16:51.39 | rafyvitto | hey cr2,tmzt,dzo and the other devs, did you ever heard about this dual boot of linux and windows mobile on the htc typhoon? heres a link for the thread on xda devs, http://forum.xda-developers.com/showthread.php?t=388273&highlight=linux |
| 16:52.17 | rafyvitto | maybe some good info can be gathered from the devs of this project |
| 16:58.01 | *** join/#htc-linux rafyvitto (n=rafyvitt@24.54.253.34) |
| 17:25.25 | *** join/#htc-linux rafyvitto (n=rafyvitt@24.54.253.34) |
| 17:26.56 | *** join/#htc-linux Bally3 (n=Bally3@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 17:27.44 | rafyvitto | http://forum.xda-developers.com/showthread.php?t=388231 here are some screenshot of the project i mention erlyer |
| 17:54.57 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
| 17:59.26 | *** join/#htc-linux idkfa (n=sergey@87.228.4.172) |
| 18:06.55 | *** part/#htc-linux otwieracz (n=otwierac@host86-162-234-54.range86-162.btcentralplus.com) |
| 18:07.56 | *** join/#htc-linux MrPippy (n=pip@adsl-75-37-163-177.dsl.sndg02.sbcglobal.net) |
| 18:11.56 | *** join/#htc-linux ArteK (n=Artur@81.15.241.96) |
| 18:28.38 | Bally3 | does anyone know how to extract irq information using haretconsole in windows? |
| 18:37.57 | *** join/#htc-linux pH5|N810 (n=ph5@g229140159.adsl.alicedsl.de) |
| 18:39.21 | *** join/#htc-linux idkfa (n=sergey@87.228.4.172) |
| 18:53.55 | *** join/#htc-linux pH5 (n=ph5@g229186096.adsl.alicedsl.de) |
| 19:21.26 | *** join/#htc-linux Ekips (i=spike@d51A460C9.access.telenet.be) |
| 19:33.47 | *** join/#htc-linux rafyvitto (n=rafyvitt@24.54.253.34) |
| 19:41.01 | *** join/#htc-linux toi (n=toi@d54C2AAB7.access.telenet.be) |
| 19:45.12 | *** join/#htc-linux idkfa (n=sergey@87.228.4.172) |
| 19:45.31 | *** join/#htc-linux Bally3 (n=Bally3@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 19:56.46 | zapp | sdfg |
| 20:07.57 | zapp | hello |
| 20:09.49 | opensaurus | hrm sometimes channel listing brings some cool results. |
| 20:10.25 | opensaurus | ive got a kaiser. thats nice that theyre porting android |
| 20:10.32 | opensaurus | thanks devs |
| 20:19.43 | swc|666 | cant wait for the n900 |
| 20:19.47 | phh | opensaurus: you looked at the channel list ? you're mad |
| 20:20.24 | glyph | swc|666: you and me both |
| 20:20.30 | swc|666 | ;) |
| 20:20.47 | glyph | in the meanwhile I'm pretty psyched about getting a new lease on life for my kaiser though |
| 20:20.49 | glyph | winmo blows |
| 20:20.58 | opensaurus | hah some fruitful results. |
| 20:21.00 | swc|666 | nods |
| 20:21.10 | opensaurus | yeah im a linux user alredy |
| 20:21.11 | glyph | speaking of which |
| 20:21.30 | swc|666 | i'm using a blackberry now... htc's have been a disappointment for me in recent times |
| 20:21.43 | glyph | Lots of discussions seem to say that compcache is the way to fix reliability issues with android builds, but I am experiencing pretty much the opposite |
| 20:21.51 | glyph | which makes sense, compressed swap is like russian roulette for allocation |
| 20:21.56 | opensaurus | swc|666, ive been getting the edfc error on my kaiser |
| 20:22.13 | opensaurus | i had a hermes less than a month ago get wsod |
| 20:22.19 | swc|666 | ouch |
| 20:22.42 | glyph | I'm just wondering if anyone else has some experience with compcache/ramzswap on these devices and could tell me what the deal is with them |
| 20:22.52 | opensaurus | yeah i took it apart and tried to fix ribbon on it for wsod and it didnt work |
| 20:23.07 | phh | glyph: the announced size (in /proc/swaps), isn't dynamically resized ? |
| 20:23.15 | glyph | phh: dynamically resized? |
| 20:23.28 | glyph | phh: I'm not sure what you mean |
| 20:23.42 | opensaurus | so yeah im gonna try android out mos def i just downloaded latest build |
| 20:23.51 | phh | glyph: according to the really available memory, thange the swap's size in /proc/swaps |
| 20:23.56 | glyph | aah |
| 20:23.59 | glyph | phh: I'm sure it does |
| 20:24.04 | phh | I used that mod on my laptop lately, and it works greatly |
| 20:24.07 | glyph | I'm talking about emergent effects, though :) |
| 20:24.16 | opensaurus | thanks everybody working on it. im out |
| 20:24.18 | phh | but x86 isn't the same thing as arm. |
| 20:24.29 | glyph | like, android is doing something funky, deciding how much java heap to keep around based on available RAM, I don't think it's coping terribly well with ramzswap |
| 20:24.37 | phh | ouch |
| 20:25.05 | phh | well compcache won't make less available RAM (or you're REALLY unlucky.) |
| 20:25.15 | phh | since it announces itself as a swap |
| 20:25.36 | glyph | phh: I am not entirely sure what android is doing, I think it is looking at total available memory |
| 20:25.52 | glyph | I'm working on a hypothesis though, just trying to narrow down the causes of unreliability :) |
| 20:26.06 | phh | that'd seem totally stupid to me (yeah i have a 40GB swap here.) |
| 20:26.12 | glyph | swapfile on my SD card seems rock solid so far, which is surprising to me, because everyone tells me that it should be worse than compcache |
| 20:26.14 | phh | (with 2GB of RAM.) |
| 20:27.03 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-125-116.web.vodafone.de) |
| 20:27.15 | phh | glyph: maybe because linux manages that swap correctly |
| 20:27.24 | phh | & android sucks (meaning some memory is almost never read back) |
| 20:28.09 | cr2 | druidu: i'm back |
| 20:38.01 | *** join/#htc-linux niccoswe (n=niccoswe@78-70-202-58-no156.tbcn.telia.com) |
| 20:38.32 | ali1234 | i just got me "free" mobile broadband dongle |
| 20:38.42 | ali1234 | it's MSM6246 based :O |
| 20:42.35 | cr2 | ali1234: does g3doc.c driver work for you ? |
| 20:43.04 | cr2 | ali1234: amss hacking for msm62xx is not fun, i guess. |
| 20:43.07 | ali1234 | cr2: that driver you pointed me to does work with a few tiny mods (like change hardcoded chip size and number of chips) |
| 20:44.10 | cr2 | ali1234: patch it, and let's commit the changes |
| 20:44.11 | ali1234 | it should be on linwizard tree, just finding it |
| 20:44.43 | cr2 | ali1234: actually i'd like to port it to g4. it should be doable with some minor effort and patience |
| 20:46.24 | ali1234 | commit fbb319d209785ab77d014116a3a38d950b1882fb |
| 20:46.38 | cr2 | full link ? |
| 20:46.47 | ali1234 | hang on a sec |
| 20:46.52 | ali1234 | might be ssome more patches oyu need |
| 20:48.49 | ali1234 | http://git.lurian.net/?p=linwizard-kernel.git;a=commit;h=fbb319d209785ab77d014116a3a38d950b1882fb |
| 20:48.55 | ali1234 | http://git.lurian.net/?p=linwizard-kernel.git;a=commit;h=c0c9d2e7f8d727973761e2c7f558512f2fb30283 |
| 20:49.02 | ali1234 | that's all i got :) |
| 20:49.21 | ali1234 | it's only read only, still a char dev, but it does seem to output the flash memory ok |
| 20:49.46 | ali1234 | i was worried because it was outputing everything twice, turns out the bootloader is on the start of both flash chips, presumably for backup |
| 20:51.19 | cr2 | spl is stored twice in 512byte blocks. raid1-style ;) |
| 20:53.00 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 20:56.27 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 20:58.37 | ali1234 | cr2: yeah i can't remember how it was laid out, but later bits of the dump clearly showed windows FS and stuff |
| 20:58.43 | ali1234 | so it was really working :) |
| 20:59.53 | *** join/#htc-linux [1]Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
| 21:02.34 | cr2 | ~ping druidu |
| 21:02.35 | apt | pong druidu |
| 21:07.05 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
| 21:07.15 | opensaurus | bah, do you absolutely HAVE to have a data plan for android to work? telling me sim is locked and its not accepting my pin for some reason |
| 21:08.06 | cr2 | opensaurus: disable the pin |
| 21:09.02 | opensaurus | yeah, i suppose that'd do it |
| 21:10.31 | cr2 | ali1234: g4 support ? |
| 21:10.34 | cr2 | 58 // G4 Wizard has one die - 1 * 128mb |
| 21:10.36 | cr2 | 59 //#define DIES 1 |
| 21:10.37 | cr2 | 60 //#define DOCG4 |
| 21:11.00 | ali1234 | cr2: well i read the source code and the G3 and G4 datasheets, and to me it looked like it should work |
| 21:11.13 | druidu | here |
| 21:11.14 | ali1234 | but it's not tested |
| 21:11.56 | ali1234 | cr2: do you happen to know about samsung K5D parts? they seem to be combination nand and sdram but on samsung website they are conspicuously absent |
| 21:12.12 | cr2 | ali1234: there are some minor differences. just remembering the disassembly we have done with lkcl |
| 21:12.55 | cr2 | ali1234: i think msm7x0x uses it |
| 21:12.59 | *** join/#htc-linux dcordes (n=luke@unaffiliated/dcordes) |
| 21:13.02 | druidu | I'm trying to make a patch to update to latest 2.6.27 branch from android.git.kernel.org |
| 21:13.10 | dcordes | hi all |
| 21:13.11 | ali1234 | cr2: yes i found it inside this dongle |
| 21:13.16 | druidu | maybe some of their updates are useful |
| 21:13.18 | dcordes | hey druidu good to see ya :) |
| 21:13.20 | cr2 | druidu: why is it a problem ? |
| 21:13.22 | druidu | hey there :) |
| 21:13.35 | cr2 | druidu: btw, we are using wiki.htc-linux.org |
| 21:13.53 | cr2 | druidu: the raphaelmemorymap page is much better there. and is available |
| 21:13.55 | druidu | hmm, there are a few conflicts especially in config files |
| 21:14.04 | druidu | that's good, didn't know that |
| 21:14.17 | dcordes | druidu, you upstreamed htc-msm-2.6.27 back to google? |
| 21:14.29 | cr2 | druidu: i'll try to do some minor patches too |
| 21:14.54 | druidu | well, I'm not sure if our setup permits to do a straight upstream fetch (or I just don't know how) |
| 21:16.42 | druidu | I branched the newest upstream version, copied all the files that were modified since the last 2.6.27 upstream sync into this branch, then tried to merge this new branch with the original upstream branch |
| 21:18.03 | druidu | actually, forget all I said, that was something else... just did a `git pull --no-commit git://android.git.kernel.org/kernel/msm.git android-msm-2.6.27` |
| 21:18.50 | druidu | maybe we should also change the config files to allow switching between our smd/clock and their smd/clock code |
| 21:20.26 | cr2 | druidu: expect a major revamp for our clock |
| 21:20.39 | cr2 | are there any smd differenrces ? |
| 21:20.53 | cr2 | (for 7201A ?) |
| 21:21.05 | cr2 | only on 7501A afair. |
| 21:21.55 | druidu | well, we're using smd_7500.c |
| 21:21.57 | cr2 | but 7501A has a different amss too (6150 vs 52xx), so it requires a different ADSP setup = has no chance of working right now. |
| 21:21.59 | druidu | they use smd.c |
| 21:22.29 | cr2 | druidu: not we. only cdma people. (*500,800) |
| 21:22.48 | cr2 | they have other problems too |
| 21:22.50 | druidu | I was thinking of a `choice` in Kconfig so that you could switch among the files |
| 21:23.00 | cr2 | the battery code is different between us too |
| 21:23.27 | cr2 | and the keyboard leds. |
| 21:23.28 | opensaurus | hrm there a wiki on disabling a sim pin for kaiser/tmo? google is letting me down |
| 21:23.29 | druidu | ah |
| 21:23.31 | druidu | obj-$(CONFIG_MSM_SMD) += smd.o smd_tty.o |
| 21:23.31 | druidu | # smd_qmi.o |
| 21:23.31 | druidu | obj-$(CONFIG_MSM_SMD_7500) += smd_7500.o |
| 21:23.48 | druidu | so raphael/diamong non cdma use MSM_SMD ? |
| 21:24.13 | tmzt | yeah |
| 21:24.22 | tmzt | actually cdma does too |
| 21:24.48 | tmzt | msm smd cdma just registers channels that aren't in the table |
| 21:25.30 | druidu | ah, you're right, looking at the code now |
| 21:25.39 | tmzt | opensaurus: probably modem settings |
| 21:25.43 | tmzt | phone settings |
| 21:25.52 | tmzt | ask in #xda-devs |
| 21:26.39 | tmzt | cr2: just get gsm working :) we'll worry about cdma after that |
| 21:26.47 | druidu | +1 :) |
| 21:28.18 | tmzt | druidu: git can do a three way merge |
| 21:30.11 | druidu | yeah, but it won't be able to solve the twisted conflicts we have :) |
| 21:30.42 | cr2 | tmzt: we have a big problem with adsp/audiomgr already. |
| 21:31.16 | cr2 | druidu: so we need a 6150 / 52xx AMSS Kconfig option too |
| 21:31.34 | cr2 | depending on the 7501A/7201A choice. |
| 21:34.23 | druidu | so what's with 6210 6220 6225 and WINCE, which one is for which? |
| 21:35.02 | cr2 | WINCE = 52xx or 6150 |
| 21:35.18 | cr2 | 52xx is GSM/UMTS and 6150 is CDMA |
| 21:35.40 | cr2 | the value can be actually parsed from the smem G23 location |
| 21:35.45 | tmzt | cr2: we need to fix or revert the microp patches for kovs |
| 21:35.55 | cr2 | so you don't boot a wrong kernel at runtime |
| 21:36.32 | cr2 | tmzt: the driver should check for the fw version |
| 21:36.39 | druidu | cr2 one more time, how can I read the lcd panel id? (it was a really long time and I forgot @ which address to find it) |
| 21:36.56 | cr2 | tmzt: and i don't think clamshell is a good addition anyway |
| 21:37.45 | cr2 | druidu: yes, you can. but the problem is to separate the toshiba mddi client from epson. |
| 21:38.14 | cr2 | druidu: 2.6.29 kernel has toshiba and novatec mddi client code. |
| 21:38.55 | cr2 | druidu: epson lcd panel detection code is different from toshina |
| 21:39.34 | druidu | /* Initial sequence of TPO panel with Novatek NT35399 MDDI client */ |
| 21:39.37 | cr2 | to make it even more difficult, there is a code aurora lcd driver which supports tvout. |
| 21:39.46 | druidu | /* Initial sequence of sharp panel with Novatek NT35399 MDDI client */ |
| 21:39.59 | cr2 | yes. so there are 3 known MDDI clients |
| 21:40.40 | druidu | ok, so novatek is surely the one used in g1 |
| 21:40.53 | druidu | which one do diam/raphael use? |
| 21:40.55 | cr2 | or toshiba |
| 21:41.14 | cr2 | the GSM uses toshiba, and CDMA epson |
| 21:41.38 | cr2 | blackstone (GSM) uses epson |
| 21:42.10 | druidu | we have toshiba init code in 2.6.29 |
| 21:43.10 | cr2 | 1 toshiba init is different from raph/diam |
| 21:43.23 | cr2 | but raph/diam still work with g1 init |
| 21:43.26 | ali1234 | looks like this dongle has gps but disabled in firmware |
| 21:43.51 | cr2 | we may fix it too. the sequence is 99% documented in the wiki. |
| 21:44.23 | druidu | ok, so how can I see which panel I have from haret? |
| 21:44.36 | cr2 | ali1234: for gps you need an appropriate preamplifier + filter. |
| 21:44.51 | cr2 | druidu: you can't |
| 21:45.07 | druidu | wasn't there an address which had the id? |
| 21:45.09 | druidu | 0x2a or smth |
| 21:45.10 | ali1234 | it has two unused antenna connections on the board, one for internal and one of those tiny external connectors |
| 21:45.16 | cr2 | druidu: the easiest way is to dump the wince dmesg after reset. or to check the smem location |
| 21:45.37 | ali1234 | so two internal, one external in total, and only one internal is used |
| 21:46.01 | tmzt | ali1234: I never understood why they did that |
| 21:46.05 | druidu | tried 0x17600000 and it's invalid... |
| 21:46.17 | tmzt | I would think that's the killer app, maps in the car |
| 21:46.19 | cr2 | druidu: ? check wiki |
| 21:46.21 | ali1234 | tmzt: so they can sell the gps version for more money, but still save on only making one board |
| 21:47.06 | tmzt | cr2: we never disable lcd panel, right? |
| 21:47.08 | druidu | HaRET(21)# pd 0x17600000 4 |
| 21:47.08 | druidu | 17600000 |EXCEPTION while reading from address 01990000 |
| 21:47.35 | cr2 | tmzt: my understanding is that they use the same mDSP and preamp as for UMTS |
| 21:48.03 | cr2 | tmzt: setlcd 4 ; setlcd 1 |
| 21:48.36 | tmzt | cr2: I know, I told him that |
| 21:48.51 | cr2 | druidu: look at the 'dump mmu' output for the top of SDRAM |
| 21:48.53 | tmzt | cr2: he committed broken mach checks anyway |
| 21:49.37 | tmzt | what's the problem? |
| 21:50.15 | cr2 | druidu: your output looks like you are trying to dump the AMSS ram, which is protected by MPU |
| 21:50.52 | tmzt | mDSP for what? |
| 21:51.19 | cr2 | http://www.htc-linux.org/wiki/index.php?title=RaphaelMemoryMap |
| 21:52.07 | cr2 | tmzt: mDSP for phone and gps. i think they use the same hardware for both. |
| 21:52.20 | tmzt | ah |
| 21:52.40 | cr2 | that's why they are so insane about patents & such. |
| 21:52.49 | tmzt | maybe the same convol |
| 21:53.04 | *** join/#htc-linux shafty (n=kvirc@cpe-70-113-42-154.austin.res.rr.com) |
| 21:53.08 | druidu | lol |
| 21:53.08 | druidu | HaRET(28)# pd 0x081034 4 |
| 21:53.09 | druidu | 00081034 | 0000000a | .... |
| 21:53.25 | druidu | so it's sharp |
| 21:53.39 | *** join/#htc-linux leaigor (n=laigor@188.134.36.14) |
| 21:53.49 | tmzt | what is? |
| 21:53.55 | cr2 | <PROTECTED> |
| 21:54.18 | tmzt | what do we need gps for? |
| 21:54.19 | druidu | the lcd panel |
| 21:54.23 | cr2 | druidu: check +0xfc048 4b model id (XC) |
| 21:54.42 | tmzt | yeah, which device? |
| 21:55.04 | cr2 | druidu: sorry. 17200000 1 wince dmesg |
| 21:55.10 | cr2 | 172, not 176 |
| 21:55.24 | cr2 | 176 will the the AMSS ram, and you'll get an expection |
| 21:55.35 | cr2 | tmzt: diam100 |
| 21:55.36 | druidu | 1601061c @ 0xfc048 |
| 21:55.44 | ali1234 | presumably a gps antenna never transmits so i could just connect it to a scope and see what is coming out of it |
| 21:55.58 | cr2 | druidu: pd 0x01ffc048 4 |
| 21:56.02 | druidu | amss id is zero 0xfc030 |
| 21:56.23 | cr2 | ali1234: should not come anything useful |
| 21:56.45 | druidu | ah... |
| 21:56.45 | druidu | pd 0x01ffc048 4 |
| 21:56.45 | druidu | 01ffc048 | 00000001 | .... |
| 21:56.56 | cr2 | druidu: pd 0x01ffc048 0x10 |
| 21:57.08 | druidu | oops, forget the 1f part |
| 21:57.10 | cr2 | err |
| 21:57.20 | cr2 | pd 0x01ffc030 0x10 |
| 21:57.29 | druidu | 01ffc030 | 322e3235 35322e39 4832312e 00000000 | 52.29.25.12H.... |
| 21:57.42 | cr2 | your AMSS is 5229 |
| 21:57.49 | cr2 | that's what is call 52xx |
| 21:58.04 | druidu | ah, cool, I remember I was that when I reflashed the firmware... duh |
| 21:58.10 | *** part/#htc-linux ArteK (n=Artur@81.15.241.96) |
| 21:58.10 | cr2 | they are all 52xx, and xx varies wildly. i think mine is 17 |
| 21:59.03 | druidu | +0xfc048 4b model id (XC) |
| 21:59.05 | druidu | so what's this? |
| 21:59.09 | cr2 | "protocol" column pd 0x01ffc048 0x10 |
| 21:59.20 | cr2 | <PROTECTED> |
| 21:59.27 | cr2 | <PROTECTED> |
| 21:59.29 | tmzt | cr2: I don |
| 21:59.31 | druidu | it's 1 |
| 21:59.36 | cr2 | it's the motherboard variation |
| 21:59.41 | druidu | 00000001 |
| 21:59.49 | cr2 | the LCD power gpios depend on this value |
| 21:59.57 | tmzt | cr2: I don't understand how mDSP affects audio and why it's a problem |
| 22:00.00 | cr2 | i think 0x52 vs. 0x62 gpio |
| 22:00.08 | cr2 | tmzt: it does not |
| 22:00.26 | druidu | can hart dump strings, like in gdb? |
| 22:00.30 | cr2 | tmzt: but 6150 AMSS needs an own adsp_6150.c |
| 22:00.36 | tmzt | sapp does the same thing, but it uses atags for oardid I think |
| 22:00.43 | tmzt | right, ok |
| 22:00.44 | cr2 | because it's different from adsp_5200.c |
| 22:01.06 | druidu | *haret |
| 22:01.11 | cr2 | druidu: i doubt it |
| 22:01.18 | tmzt | druidu: there was a suggestion to add gdb protocol support to haret |
| 22:01.54 | cr2 | tmzt: may uploading and executing the script by haretconsole first. |
| 22:02.03 | druidu | it would have been easier to read dmesg... |
| 22:02.30 | cr2 | because 'runscript' needs the script to be already on the target device. which is a PITA in many cases |
| 22:02.55 | tmzt | synce-pcp |
| 22:03.18 | druidu | yeah, synce works |
| 22:03.26 | cr2 | tmzt: i think it's just a minor change to haretconsole. |
| 22:03.28 | tmzt | haret is just a big select loop |
| 22:03.42 | cr2 | tmzt: to support _runscript or somethng like that. |
| 22:04.03 | druidu | I'm actually using only activesync now from linux, it's much easier to upload new kernel image then run it without restarting haret (and with activesync enabled when I run haret I get usbnet) |
| 22:04.21 | cr2 | druidu: i use linload.exe |
| 22:04.37 | cr2 | and usb_storage mode |
| 22:04.43 | cr2 | to put it on the raph |
| 22:04.58 | tmzt | of course adding ymodem might be easier |
| 22:05.05 | druidu | yeah, but with usb_storage mode you won't have usbnet once it restarts right? |
| 22:05.24 | cr2 | i think you should |
| 22:05.35 | tmzt | yes |
| 22:05.39 | cr2 | but i use the SD card, so i need to switch manually |
| 22:05.48 | cr2 | anyway |
| 22:05.52 | druidu | didn't work for me... diamond has internal sd card anyway |
| 22:05.53 | tmzt | but you can't read from sd |
| 22:06.01 | cr2 | otherwise i don't see the SD card |
| 22:06.24 | druidu | I know, that's why I use activesync and a tool called "Fur" with uses FUSE to mount filesystem via synce |
| 22:06.35 | cr2 | ok |
| 22:06.44 | tmzt | where do you get that? |
| 22:06.50 | druidu | Fur? |
| 22:06.50 | cr2 | druidu: i had enabled the nand driver actually |
| 22:06.53 | druidu | standard ubuntu package |
| 22:07.02 | tmzt | it wouldn't compile for me |
| 22:07.19 | cr2 | druidu: but then we had some problems on the fs level, because of the 0x2000 blocksize |
| 22:07.32 | druidu | apt-cache show fur: Description: FUSE module to mount Windows Mobile devices FUR (Fuse Uses Rapi) is a filesystem client for fuse to mount the filesystem of a Windows Mobile device attached via SynCE. |
| 22:07.33 | tmzt | it survives device reboot? |
| 22:08.08 | tmzt | yeah, but I didn't think it worked with latest synce |
| 22:08.11 | druidu | well, all I remember is that last time I messed with nand I bricked my device :P |
| 22:08.24 | cr2 | hehe |
| 22:08.31 | druidu | fuse mount no |
| 22:08.34 | cr2 | druidu: actually it is strange |
| 22:08.38 | cr2 | http://wiki.xda-developers.com/index.php?pagename=Raphael_ExtractedRadioRoms |
| 22:08.48 | tmzt | what is this lcd init for? |
| 22:08.54 | tmzt | fixing htcfb? |
| 22:08.55 | cr2 | GSM should check for '52' only |
| 22:09.02 | cr2 | tmzt: suspend/resume |
| 22:09.05 | druidu | but as I said, usbnet was working for me only when running haret with activesync enabled |
| 22:09.06 | tmzt | ah |
| 22:09.26 | tmzt | right, that's a diam problem |
| 22:09.28 | druidu | and also, standalone kernel, cold boot it :) |
| 22:09.42 | cr2 | druidu: frm nand :) |
| 22:10.10 | tmzt | did w figure out exactly what mdp does? |
| 22:10.21 | tmzt | how flipping really works? |
| 22:10.24 | cr2 | druidu: http://www.htc-linux.org/wiki/index.php?title=RaphaelNAND |
| 22:10.41 | tmzt | raster said we have the buffers backward |
| 22:10.49 | cr2 | druidu: the really critical things are below 0x24 MB anyway |
| 22:10.49 | tmzt | it's back then front |
| 22:11.01 | druidu | http://wiki.xda-developers.com/index.php?pagename=Diamond_Upgrades |
| 22:11.07 | cr2 | tmzt: backward ? |
| 22:11.08 | druidu | all are 52.* for diamond too |
| 22:11.24 | cr2 | druidu: yes. only GSM. |
| 22:11.30 | cr2 | druidu: CDMA is different. |
| 22:11.32 | tmzt | cr2: yeah, so it's back then front |
| 22:11.45 | cr2 | tmzt: what do you mean ? |
| 22:11.47 | tmzt | cr2: X expected the opposite |
| 22:11.58 | tmzt | back buffer |
| 22:12.02 | tmzt | front buffer |
| 22:12.07 | tmzt | in that order |
| 22:12.10 | cr2 | ah, ok |
| 22:12.20 | druidu | btw |
| 22:12.30 | cr2 | i thought yu talked about nand |
| 22:12.30 | druidu | I was thinking of making it use like 3 buffers |
| 22:12.40 | tmzt | sorry |
| 22:12.41 | druidu | for implementing a proper onscreen keyboard with not artifacts behind |
| 22:13.03 | tmzt | druidu: osk i a userspace thing |
| 22:13.12 | druidu | yeah, true |
| 22:13.15 | druidu | android 1.5 has it anyway |
| 22:13.47 | tmzt | we need to remove that and update thread |
| 22:13.49 | cr2 | druidu: can you compile the git head for .27 ? |
| 22:13.56 | tmzt | I'm working on that for X |
| 22:14.10 | cr2 | tmzt: hehe. and the dma3+tvout |
| 22:14.38 | tmzt | we can do the darkstar thing for ts cal |
| 22:14.58 | tmzt | keep it in kernel but use ts_calibrate from userspace |
| 22:15.02 | druidu | what I really don't get it is how can android, with the current diamong touchscreen driver, know the size of the pressed area |
| 22:15.11 | tmzt | write the settings to sysfs |
| 22:15.31 | druidu | and write a simple android app for calibration |
| 22:15.33 | cr2 | druidu: it's hardcoded into the driver |
| 22:15.40 | druidu | no it's not :)) |
| 22:15.47 | druidu | i tried the sample app |
| 22:15.58 | cr2 | android is dumb as a rock if it does not support on-boot calibration |
| 22:16.00 | tmzt | we uses msmts from google now |
| 22:16.12 | cr2 | tmzt: no, afaik |
| 22:16.22 | druidu | and if I press with my finger or with my stylus I get different sizes |
| 22:16.39 | tmzt | cr2: it only supports capac. screens, so no calib. |
| 22:16.49 | tmzt | oh, we don't? |
| 22:17.03 | druidu | nope, it's my ts driver |
| 22:17.05 | cr2 | j0b0 has written some nice hack for ts pressure. |
| 22:17.18 | druidu | nameley input_report_abs(msm_ts_dev, ABS_PRESSURE, touched ? MSM_TS_ABS_PRESSURE_MAX : MSM_TS_ABS_PRESSURE_MIN) :) |
| 22:17.19 | tmzt | we should use fingers |
| 22:17.27 | cr2 | druidu: patched by NetRipper to support half-broken irqs |
| 22:17.34 | tmzt | but android doesn't support that yet |
| 22:18.18 | druidu | when tracing irqs from haret, does the release interrupt fire consistently? |
| 22:18.35 | cr2 | android sucks ;) but it's another story, and we must support it. |
| 22:19.16 | cr2 | druidu: no, it's some hw bug i think. there is a goggle msm_ts driver, but it does more or less the same. said NetRipper |
| 22:20.14 | druidu | <PROTECTED> |
| 22:20.14 | druidu | <PROTECTED> |
| 22:20.18 | druidu | cound this be the race? |
| 22:20.26 | druidu | we enable the irq before clearing the flag |
| 22:21.20 | cr2 | druidu: look at the goggle msm_ts driver. it has bit names inside |
| 22:21.35 | cr2 | afair 2.6.29 only |
| 22:25.09 | cr2 | druidu: can you apply this patch to .27 git ? https://privatepaste.com/51cFQBwgUR |
| 22:25.54 | ali1234 | this thing seems to have two internal antennas. and looking at pictures on google, one of them looks like a GPS antenna |
| 22:27.07 | cr2 | ali1234: even if the hardware is there, where can you get the right amss firmware ? |
| 22:27.26 | ali1234 | i dunno, it must exist though |
| 22:27.36 | ali1234 | they wouldn't make hardware and not ever use it anywhere :) |
| 22:28.00 | ali1234 | part of the unlock procedure involves flashing a dodgy firmware to it, so i have that too |
| 22:28.11 | cr2 | lol |
| 22:28.17 | ali1234 | next thing i do will be try to disassemble that |
| 22:28.51 | cr2 | ali1234: you'd document the difference between dodgy & non-dodgy fw :) |
| 22:29.04 | cr2 | a lot of thumb code = pita |
| 22:29.15 | ali1234 | none dodgy = what comes in the unit, dodgy = anything else :) |
| 22:29.41 | cr2 | ali1234: i mean on the asm level :) |
| 22:30.16 | ali1234 | i think the unlocked firmware is just something a particular phone company gives out when customers ask for unlocking |
| 22:30.21 | ali1234 | i dont have anything to compare it with |
| 22:30.53 | tmzt | unlocking? |
| 22:31.00 | tmzt | ke sim unlocking? |
| 22:31.10 | tmzt | thought you meant gps |
| 22:31.32 | cr2 | 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,Athlon64, Sempron] HyperTransport Configuration |
| 22:31.34 | cr2 | ... |
| 22:31.51 | cr2 | 00:1b.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,Athlon64, Sempron] Link Control |
| 22:32.08 | cr2 | omg. 16cpus :) |
| 22:32.26 | cr2 | 82:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI |
| 22:32.28 | cr2 | Express HBA (rev 03) |
| 22:32.37 | ali1234 | managed to find pinout of RTR6285 in some phone service manual :) |
| 22:32.58 | cr2 | gps chip ? |
| 22:33.11 | tmzt | ali1234: have you talked to chavonbravo? |
| 22:33.22 | tmzt | in #xda-devs? |
| 22:33.27 | ali1234 | no, who's that? |
| 22:33.36 | tmzt | he |
| 22:33.42 | ali1234 | 6285 seems to be the UMTS+GPS chip yeah |
| 22:33.54 | tmzt | as saying something about that chip yesterday |
| 22:33.57 | marex | cr2: hi, long time no see ;-) |
| 22:33.59 | tmzt | tg01 has it |
| 22:34.15 | cr2 | datasheet ? |
| 22:34.32 | cr2 | marex: got n560 to resume already ? |
| 22:34.46 | tmzt | cr2: it's only accessible to amss anyway |
| 22:34.58 | ali1234 | tmzt: i think it's used in G1 too |
| 22:34.59 | marex | cr2: nope, havent looked at it ever since ... how's the audio part going on your side ? ;-) |
| 22:35.12 | cr2 | marex: g4 driver -> http://git.lurian.net/?p=linwizard-kernel.git;a=commit;h=fbb319d209785ab77d014116a3a38d950b1882fb |
| 22:35.24 | tmzt | yeah, all current umts qualcomm's should have it |
| 22:35.31 | cr2 | marex: once the resume will work, i'll look at audio |
| 22:36.08 | cr2 | tmzt: arm11 can talk to SBI too |
| 22:36.35 | marex | cr2: that site doesnt seem to load ... |
| 22:36.45 | marex | cr2: btw. damn you ... :-E~ ;-) |
| 22:36.51 | tmzt | I'm sure, mpu shared bus |
| 22:37.03 | cr2 | tmzt: but there may be a lot of trouble |
| 22:37.26 | cr2 | tmzt: we can disable the SBI clock, that'll be fun if arm9 will be able to recover :) |
| 22:37.28 | tmzt | yeah, amss is hard realtime |
| 22:37.35 | tmzt | and we have no stack |
| 22:37.49 | tmzt | gsm |
| 22:37.59 | cr2 | marex: hehe. worked 30min ago for me |
| 22:38.13 | tmzt | I wonder if the tested amss on the arm11 |
| 22:38.31 | tmzt | they did brew demos on the chips |
| 22:38.47 | tmzt | but I don't know about amss phone functions |
| 22:39.28 | tmzt | but I would say keep to AP anyway |
| 22:39.37 | tmzt | let BP do what it does |
| 22:40.28 | tmzt | I wonder about the closed components on ce though, they seem to be combining functions |
| 22:40.45 | tmzt | like you were saying with gps |
| 22:40.53 | ali1234 | the gps pins are connected to a bunch of circuitry |
| 22:41.14 | ali1234 | i had to cut off some of the shielding to find that |
| 22:41.22 | cr2 | tmzt: the gps is done via SMD and rpc |
| 22:41.27 | *** join/#htc-linux xperia (n=chatzill@80-218-229-51.dclient.hispeed.ch) |
| 22:41.33 | xperia | hello to all. |
| 22:41.35 | cr2 | tmzt: so it's arm9 only. |
| 22:42.07 | cr2 | tmzt: the same big brother design like a780 |
| 22:43.20 | xperia | just short, cr2 or tmzt is it possible to send me the raphs dll named oem_misc, keypad, n5ledmgr, backlight over mail for compare |
| 22:43.44 | cr2 | xperia: get a rom, and dissect it |
| 22:44.50 | cr2 | xperia: i have updated the wiki today. need to compare with the mcrop driver thouh. |
| 22:45.22 | xperia | ohh thats is heavy and a lot of time consuming as the tools need to be installed and first i have to know how to extract them. it is more easy to send them over mail and the wifi connection dirctly from the phone. it cost not more than 1 minute. |
| 22:45.51 | tmzt | ali1234: what msm? |
| 22:46.03 | ali1234 | 6246 |
| 22:46.55 | *** join/#htc-linux Bally3 (n=Bally3@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 22:47.40 | marex | cr2: well -- how complete is that driver? is it any better than the G3 one for uni ? |
| 22:47.47 | cr2 | xperia: i need to use webmail |
| 22:47.48 | druidu | git mergetool + kdiff3 rulez :D |
| 22:47.55 | cr2 | marex: it's the same |
| 22:48.13 | cr2 | druidu: will you apply the patch ? then i'll do 1 more |
| 22:48.30 | druidu | in a few minutes |
| 22:48.39 | druidu | I'm finishing with the patch for the upstream changes |
| 22:48.52 | druidu | I'll commit that and then yours |
| 22:49.27 | cr2 | druidu: and i need to write a detailed comment for clock-wince, why are the settings as they are. and what needs to be changed there |
| 22:49.29 | cr2 | ok |
| 22:49.56 | cr2 | Bally3: booted a kernel on hermes already ? |
| 22:51.12 | marex | cr2: so what's so revolutionary ? |
| 22:52.13 | xperia | cr2: realy nice changes in the wiki for the microp driver. are they based on the files that i have send you or did you used other sources ? |
| 22:54.50 | cr2 | xperia: i have used all avalable sources |
| 22:55.17 | cr2 | marex: if n560 will resume ,i t will be revoltionary |
| 22:55.35 | cr2 | marex: have you seen the LED driver for n560 already ? |
| 22:56.47 | xperia | i would like them to test it tomorow. if you are from 10 o clock here it would be for me a pleasure to test it. i have some heavy i2c traces and a extended crosscompiled i2ctools with data block write possibility for debuging. |
| 22:56.57 | cr2 | druidu: we also need to revise the #idefs made by NetRipper, if they are really needed. |
| 22:57.37 | cr2 | xperia: i can add the hardcoded raph tables to wiki too |
| 22:58.14 | cr2 | 0x3c blocksize 3*16+12=48+12=60 |
| 22:58.23 | marex | cr2: no, why ? |
| 22:58.37 | marex | cr2: I got myself a nice toy -- Zipit Z2 |
| 22:58.47 | marex | Zipit Wireless really rocks as a linux corp. |
| 22:58.50 | cr2 | wtf is thAt ? |
| 22:59.15 | marex | cr2: EeePC with ARM after being shot at with a shrink ray |
| 22:59.27 | marex | (and both size and price involved were shrunk) |
| 22:59.33 | xperia | cr2: well for the raph users and for me as a backup it could be helpfull but only if you have time. with the new changes in the wiki i have for sure something tomorow to do. |
| 22:59.59 | xperia | i hope you will be tomorow around here :-) |
| 23:04.46 | xperia | have to go for sleep. wish you all a good night. bye |
| 23:06.06 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-125-116.web.vodafone.de) |
| 23:12.20 | cr2 | /TODO: Find out what channel 0x11 is for |
| 23:12.29 | cr2 | ce,11,02,x get pin status rd |
| 23:13.28 | cr2 | static void micropksc_led_work_func(struct work_struct *work) |
| 23:13.36 | cr2 | hehe |
| 23:13.39 | cr2 | <PROTECTED> |
| 23:14.41 | cr2 | needs to be fixed. |
| 23:24.23 | cr2 | ok, now i see it. this clamshell code broke non-x1 |
| 23:26.00 | cr2 | druidu: one more patch https://privatepaste.com/e4YsjLrz24 |
| 23:26.05 | druidu | ok |
| 23:26.28 | cr2 | druidu: it could look better if we will modify the DEX api to override the proc_comm more transparently |
| 23:27.14 | druidu | btw, do we have code for real power off or reset? |
| 23:27.24 | cr2 | PCOM_POWER_OFF |
| 23:27.36 | cr2 | yes, it shuts down the PMIC |
| 23:27.45 | druidu | cool |
| 23:28.02 | cr2 | i don't know what is the difference between PCOM_POWER_OFF and PCOM_POWER_DOWN |
| 23:28.28 | cr2 | reset needs to be refined later |
| 23:28.41 | cr2 | but the 'halt' will work as expected |
| 23:29.31 | cr2 | don't know about 'reboot' |
| 23:31.09 | cr2 | and i'm thinking about adding a lot of printks to dump the wince state values. |
| 23:31.19 | tmzt | cr2: yeah, on my suggestion he made the code conditional |
| 23:31.45 | tmzt | but only with machine is |
| 23:31.51 | cr2 | tmzt: buffer[1] = 0x16 - (data->led_state << 1); |
| 23:31.59 | cr2 | tmzt: this works only on raph800 |
| 23:33.26 | cr2 | tmzt: the most tough problem is the stuck DMA for BT now. |
| 23:33.57 | cr2 | and the ADSP. but it may be sorted out with a lot of printks aka pr_info() |
| 23:34.32 | tmzt | it should also be wrapped with with ifdef |
| 23:34.46 | tmzt | or, properly using fw version |
| 23:36.06 | druidu | power_down is standby? |
| 23:36.31 | cr2 | druidu: no, full shutdown |
| 23:36.48 | cr2 | sorry. POWER_OFF |
| 23:37.01 | druidu | I was speculating that _DOWN might be a standby |
| 23:37.28 | druidu | anyway, I have this dilemma: should I port our changes to the latest upstream branch or the other way around? |
| 23:38.03 | tmzt | we need abstraction |
| 23:38.13 | druidu | I did a git-pull and solved the conflicts, not exactly sure what happened there |
| 23:38.19 | tmzt | and the code should still build for trout/dream |
| 23:38.44 | tmzt | we have a few g1 testers now |
| 23:38.46 | cr2 | .29 may be better |
| 23:38.59 | druidu | .29 is a bit harder to merge |
| 23:39.06 | cr2 | because of the more sane LCD code |
| 23:39.09 | druidu | and they have alternate versions too, .27 is the current default |
| 23:39.12 | cr2 | ok, i agree |
| 23:39.30 | druidu | I think .27 and .29 upstream are pretty much the same in lcd code? |
| 23:39.45 | cr2 | but then we need some hack for lcd up/down. |
| 23:40.06 | cr2 | PCOM_RESET_APPS is arm11 reboot. don't know how to do it. |
| 23:40.14 | cr2 | PCOM_RESET_CHIP wtf f? |
| 23:40.39 | cr2 | PCOM_CONFIG_NAND_MPU . ok. thanks to itsutils we know how to do it. |
| 23:40.41 | druidu | if youboard-sapphire-panel.c |
| 23:40.52 | druidu | if you're talking about board-sapphire-panel.c, it's in 2.6.27 too |
| 23:40.59 | cr2 | PCOM_CONFIG_USB_CLKS don't know if it's useful |
| 23:41.28 | cr2 | PCOM_POWER_DOWN is g1 contstant |
| 23:41.38 | cr2 | =10 |
| 23:42.02 | cr2 | our POWER_OFF=0x14 = 20 |
| 23:42.29 | druidu | it's in a big enum in proc_comm.h |
| 23:42.51 | cr2 | yes, and our numbers are different |
| 23:44.04 | druidu | quick git question, how can I cleanup merge leftover files? |
| 23:44.11 | cr2 | PCOM_RESET_MODEM is our PCOM_RESET_ARM9 |
| 23:44.21 | druidu | *.BACKUP.*, *.BASE.*, *.LOCAL.* |
| 23:44.40 | cr2 | PCOM_PM_VID_EN is rpc for us |
| 23:46.10 | druidu | git clean -f |
| 23:48.25 | tmzt | CHIP might be arm9? |
| 23:48.46 | cr2 | PCOM_RESET_MODEM is our PCOM_RESET_ARM9 |
| 23:50.12 | druidu | cr2: there's some stuff in the clock code that break the build after upstream sync |
| 23:50.20 | druidu | CLKFLAG_USE_MIN_MAX_TO_SET is no longer used |
| 23:50.35 | cr2 | which line ? |
| 23:50.46 | cr2 | i don't think we use it |
| 23:50.53 | cr2 | <PROTECTED> |
| 23:50.56 | druidu | this is new clock.h |
| 23:50.56 | druidu | http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/clock.h;h=f49376629bd68787014de28d06520257c6ebbf72;hb=android-msm-2.6.29 |
| 23:51.04 | cr2 | hmm. we set PMDH to 0xa00 ?? |
| 23:51.14 | druidu | 474 |
| 23:51.22 | druidu | <PROTECTED> |
| 23:51.24 | druidu | in clk_set_rate |
| 23:51.51 | cr2 | wrong link |
| 23:51.56 | druidu | hmmm |
| 23:52.06 | druidu | that's the link to new clock.h |
| 23:52.17 | druidu | hmmm, I think I'll just rip the clk_set_rate function from clock.c |
| 23:52.50 | druidu | you probably didn't change anything in that part anyway |
| 23:52.55 | cr2 | clk_set_rate is not yet implemented i think |
| 23:53.28 | druidu | ok, I'll just take the new version from clock.c so the build doesn't break |
| 23:53.44 | cr2 | i know how to derive a lot of clocks from the base PLLs and how the base PLLs are setup, but there are many options to set the divisors. so it's not going to be easy. |
| 23:53.51 | cr2 | ok |
| 23:54.35 | cr2 | anf the most ugly thing is that g1 uses different clock setup from wince. |
| 23:55.18 | cr2 | the androids have really done many things to make our life difficult |
| 23:57.46 | druidu | yeah, but there's still a lot of duplicate code between clock.c clock-wince.c |
| 23:57.50 | druidu | unfortunately |
| 23:59.23 | Bally3 | cr2: you asking me or you done it? |
| 23:59.55 | cr2 | Bally3: asking you |