| 00:00.26 | makkonen | this would be a lot more helpful if I could get my corresponding logs, and see where the difference between working and non-working are. |
| 00:01.11 | makkonen | you have adb working and not shutting down? |
| 00:02.12 | MrPippy | that new sms message doesn't make it through to the interface, but it seems to show up consistently after atdt#777 |
| 00:02.48 | MrPippy | and yeah i'm using an old kernel (linuxtogo from ~middle october), and usbnet stays connected |
| 00:03.45 | MrPippy | none of the kernel changes in the last 2 months have been useful for me, this runs pretty well |
| 00:03.53 | ToAsTcfh | it shouldnt use data to send text |
| 00:04.45 | makkonen | so it's this: AT< 0000021003080800031000100B0100 |
| 00:04.58 | makkonen | that's either coming out corrupt, or being parsed incorrectly, no? |
| 00:05.35 | MrPippy | it says below that is a voice mail indicator clear--maybe the network just sends those when a call is placed? |
| 00:05.46 | MrPippy | i haven't gotten voice mail in a while (and my indicator is clear) |
| 00:06.42 | makkonen | oh, yeah. the voicemail status does get sent through the sms channels. I remember getting SMSes from 000000 on the vogue way back when. |
| 00:07.30 | MrPippy | hmm this is in /smodem/ppp.log: |
| 00:07.31 | MrPippy | Turning on data |
| 00:07.31 | MrPippy | Done! |
| 00:07.51 | makkonen | why is it erroring out on the third or fourth get_neighboring_cell_ids |
| 00:18.37 | MrPippy | also this is with amss 6150, i'll probably try it with 5200 next |
| 00:21.16 | *** part/#htc-linux kam187 (n=kam187@81-179-8-102.dsl.pipex.com) |
| 00:21.38 | *** join/#htc-linux kam187 (n=kam187@81-179-8-102.dsl.pipex.com) |
| 00:23.37 | MrPippy | in-call switching between speakerphone and earpiece works |
| 00:54.31 | ToAsTcfh | MrPippy: u there |
| 00:54.39 | MrPippy | yeah |
| 00:55.35 | ToAsTcfh | ok im not getting data but im not getting the ATDT#777 call either. |
| 00:56.14 | ToAsTcfh | when doing echo -e 'ATDT#777\r' > /dev/smd0 it results in nothing |
| 00:56.39 | ToAsTcfh | is it the ril callin for this or what |
| 00:58.16 | ToAsTcfh | is there something i can add or change to insure ATDT#777 is called? |
| 00:58.27 | MrPippy | yeah the ril should dial that |
| 00:58.34 | MrPippy | do you have a logcat -b radio? |
| 00:59.05 | ToAsTcfh | yeah hold up. mine db radio though |
| 01:00.13 | ToAsTcfh | MrPippy: http://pastebin.com/d20fdea43 |
| 01:00.39 | ToAsTcfh | calls work text is fine too just no data |
| 01:02.20 | MrPippy | hmm i don't think we're using the same RIL, yours has cdma stuff and mine has gsm |
| 01:02.39 | ToAsTcfh | yeah... mines a hero |
| 01:03.18 | ToAsTcfh | using a aosp 2.0 build with cdma settings and stuff |
| 01:03.43 | ToAsTcfh | cdma built 2.0 build |
| 01:04.43 | MrPippy | and your ril came from a droid? |
| 01:04.53 | ToAsTcfh | no |
| 01:05.01 | ToAsTcfh | a gsm hero |
| 01:06.16 | MrPippy | it looks like this is where the error is "qmi_send_recv_procedure():QMI timeout (up: 3) 1 time(s)" |
| 01:06.24 | ToAsTcfh | the cdma ril from my original 1.5 build is hacked to add cdma support. thus why it doesnt do anything but crash everything in 2.0 |
| 01:06.27 | MrPippy | but i don't know what that is |
| 01:08.32 | MrPippy | yeah short of disassembling the ril, i'm not sure what you could try |
| 01:09.52 | ToAsTcfh | i can disassembling the ril? |
| 01:11.42 | MrPippy | yeah you could go at it with ida pro or something, but its probably too complicated to really learn anything |
| 01:12.07 | ToAsTcfh | yeah |
| 01:12.31 | MrPippy | being able to watch everything in and out of smd0 or smd1 would be more useful but i'm not sure how you could |
| 01:13.01 | *** join/#htc-linux praxidike (n=praxidik@c-174-56-11-95.hsd1.nm.comcast.net) |
| 01:15.34 | MrPippy | has htc said anything about releasing the cdma hero kernel code? |
| 01:15.55 | ToAsTcfh | hell no. they suck |
| 01:17.10 | ToAsTcfh | i dont think they have to tell me how to build it. |
| 01:17.47 | ToAsTcfh | a board_heroc would be nice though |
| 01:47.55 | *** join/#htc-linux praxidike (n=praxidik@c-174-56-11-95.hsd1.nm.comcast.net) |
| 01:51.42 | tmzt | strace the rild process |
| 01:51.47 | tmzt | not easy with android stuff though |
| 01:53.23 | *** join/#htc-linux jeremychang (n=jeremych@61-30-10-70.static.tfn.net.tw) |
| 01:56.55 | *** join/#htc-linux quietcblongs (n=Administ@c-76-115-181-74.hsd1.wa.comcast.net) |
| 01:57.15 | quietcblongs | Toast, you here? |
| 02:05.13 | *** join/#htc-linux jenericc (i=ebcain@cpe-24-210-123-84.insight.res.rr.com) |
| 02:09.28 | ToAsTcfh | yeah man |
| 02:10.52 | ToAsTcfh | tmzt: i have no clue how to strace. i went and got one to use and looked into it and had no clue as to what it was talkin bout |
| 02:11.23 | ToAsTcfh | quietcblongs: im here |
| 02:11.25 | tmzt | attach to the process |
| 02:11.25 | quietcblongs | Hey Toast, I read more source today, and I think there are a few things to look/poke at |
| 02:12.04 | ToAsTcfh | quietcblongs: like? |
| 02:12.15 | quietcblongs | However, I can't do much when the I run a 1.5 ROM, anytime I echo something to /dev/smd0 locks up my phone |
| 02:12.34 | quietcblongs | do you know if there is a way to somehow catch the AT commands when running 1.5? |
| 02:12.51 | ToAsTcfh | no |
| 02:13.00 | quietcblongs | 1. I think we need to make sure the phone is set to the right Mobile IP profile |
| 02:13.55 | quietcblongs | 2. I found that "netcfg rmnet0 dhcp" should be called AFTER sending the "up:..." to /dev/qmi0, if dmesg doesn't say "network start failed" |
| 02:14.42 | quietcblongs | I've pretty much verified #1 with the commands found here; |
| 02:14.43 | quietcblongs | http://www.softwareconceptsinc.net/members/csp5850-manual/ap-at.html |
| 02:15.04 | quietcblongs | however, after settting the MIP and everything else, the up command sent to qmi0 still fails |
| 02:15.40 | tmzt | dhcp? not likely |
| 02:16.01 | quietcblongs | no? should I just do a rmnet up? |
| 02:16.08 | tmzt | can you tcp dump while bringing it up on the working rom? |
| 02:16.15 | tmzt | tcpdump -i rmnet0 |
| 02:16.28 | tmzt | not sure what the ppp is being used for |
| 02:16.35 | tmzt | have you straced that? |
| 02:16.38 | quietcblongs | I doubt stock is doing ppp |
| 02:16.45 | tmzt | actually, try attaching linux ppp to it |
| 02:16.55 | tmzt | I think it's might be using LCP/IPCP for ip address |
| 02:17.11 | quietcblongs | you mean tether? |
| 02:17.21 | quietcblongs | via usb? and then do a dialup connection? |
| 02:17.41 | tmzt | no |
| 02:17.52 | tmzt | try attaching it to whatever rild-ppp attaches to |
| 02:17.57 | tmzt | use lsof to find it |
| 02:18.05 | tmzt | you will need a chroot and bind mount proc and sysfs for this |
| 02:18.48 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 02:19.21 | quietcblongs | hmm, I'll need to compile those... lucky for me, I do have a working build environment. Is there a reference that talks about doing what you said in more detail? |
| 02:19.40 | tmzt | get debian |
| 02:19.43 | tmzt | much easier |
| 02:19.47 | tmzt | as a chroot |
| 02:19.53 | tmzt | saurik has instructions |
| 02:19.56 | tmzt | forget the X/vnc stuff |
| 02:20.26 | tmzt | high-rez: can you join #ofono sometime? |
| 02:20.33 | quietcblongs | I took a look and is rild-htc what we're trying to attach to? |
| 02:20.44 | tmzt | yes |
| 02:20.54 | tmzt | lsof that with lsof -p `pidof rild-htc` |
| 02:21.03 | tmzt | give me the device nodes it has open |
| 02:21.04 | quietcblongs | in adb shell right? |
| 02:21.15 | tmzt | if you must, debian chroot is preferred |
| 02:21.35 | quietcblongs | ok, I'm not familiar with chroot, I'll need to do some reading... |
| 02:22.25 | tmzt | saurik |
| 02:22.28 | tmzt | search for that |
| 02:22.35 | tmzt | follow the instructions until the vnc stuff |
| 02:39.19 | *** join/#htc-linux jeremychang_ (n=jeremych@61-30-10-70.static.tfn.net.tw) |
| 02:47.43 | MrPippy | nice wifi is working on diam500 |
| 02:49.25 | AstainHellbring | nice MrPippy |
| 02:49.57 | tmzt | yeah |
| 02:50.29 | MrPippy | a lot easier than the first time i did it a few months back with tiwlan |
| 02:51.20 | MrPippy | although i had to start and stop wifi twice, first time it scanned but wouldn't join a network, second time it joined the "remembered" network |
| 02:59.36 | *** join/#htc-linux toumei (n=tmclane@c-98-197-210-171.hsd1.tx.comcast.net) |
| 03:18.37 | *** join/#htc-linux CVirus (n=Satan@196.205.192.81) |
| 03:18.43 | *** part/#htc-linux CVirus (n=Satan@196.205.192.81) |
| 03:19.19 | *** join/#htc-linux KonvIRC_ (n=blindaue@ibis.u-strasbg.fr) |
| 03:20.49 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) [NETSPLIT VICTIM] |
| 03:20.49 | *** join/#htc-linux kam187 (n=kam187@81-179-8-102.dsl.pipex.com) |
| 03:20.49 | *** join/#htc-linux MrPippy (n=pip@adsl-75-36-53-28.dsl.sndg02.sbcglobal.net) [NETSPLIT VICTIM] |
| 03:20.49 | *** join/#htc-linux Brenton (n=chatzill@c122-107-100-34.blktn5.nsw.optusnet.com.au) [NETSPLIT VICTIM] |
| 03:20.49 | *** join/#htc-linux Kevin21 (n=Kevin2@207-172-165-101.s101.tnt1.nywnj.ny.dialup.rcn.com) [NETSPLIT VICTIM] |
| 03:29.33 | ToAsTcfh | tmzt: ive been trying to stace with no luck.isthis stace gonna work for what were doing?http://benno.id.au/blog/2007/11/18/android-runtime-strace |
| 03:33.42 | *** join/#htc-linux MatBeez (n=MatBee@d24-150-35-2.home.cgocable.net) |
| 03:36.31 | ToAsTcfh | quietcblongs: whats ur status? got debian up yet? |
| 03:38.53 | quietcblongs | no |
| 03:39.37 | quietcblongs | I'm trying to do lsof first, but while that is going, I've poked around /prod/<pid for rild> with Fresh's ROM, and found the rild and rild-debug sockets fd's |
| 03:40.08 | quietcblongs | running debian on my phone is going to be later if I can't get anywhere with tcpdump/lsof |
| 03:40.25 | *** join/#htc-linux toumei (n=tmclane@c-98-197-210-171.hsd1.tx.comcast.net) |
| 03:41.06 | ToAsTcfh | yeah iim trying to strace some things but for the life of me cant get it to work |
| 03:50.51 | MrPippy | strace -p (pid of rild) doesn't work? |
| 03:51.54 | ToAsTcfh | strace -c -p rild -o /sdcard/strace.txt |
| 03:52.08 | quietcblongs | tcpdump -i rmnet0 just shows ARP request as the first packet |
| 03:52.31 | quietcblongs | basically means, tell me the gateway MAC address (I think..) |
| 03:53.05 | MrPippy | rmnet0 is the interface for the data connection? |
| 03:53.13 | quietcblongs | yes |
| 03:54.04 | quietcblongs | I'm trying to reverse engineer whats going on in a working Hero CDMA ROM, and bring that to an AOSP 2 build I have that runs already, but data doesn't work, while voice/sms does. |
| 03:54.09 | ToAsTcfh | even if u setprop the ips to it and the gw it results in nothing |
| 03:55.03 | ToAsTcfh | i left the old 2.1 build. this build has more hope i think |
| 03:55.23 | ToAsTcfh | its cleaner for sure |
| 03:55.28 | quietcblongs | the setprop is done by the code AFTER the ips are set via the black box, from reading the code. |
| 03:56.04 | ToAsTcfh | im talkin bout in 2.0 |
| 03:56.14 | ToAsTcfh | there not set at all |
| 03:56.54 | quietcblongs | right, because the network didn't come up. the code checks if qmi0 somehow sent back the ip and gw, and if it doesn't get anything/errors out, it won't set those props |
| 03:58.50 | ToAsTcfh | thats what i was thinking. but even forcing them and putting rmnet0 up still does nothing. for some reason were not getting the whole #777 action to start everything in motion |
| 03:59.19 | ToAsTcfh | but u say the comand is in the ril so wtf |
| 04:01.10 | ToAsTcfh | the ril in ur build. is it one u built while making the build? |
| 04:01.21 | quietcblongs | yes |
| 04:01.28 | quietcblongs | you're talking about rild? |
| 04:01.32 | ToAsTcfh | so its universal |
| 04:01.37 | quietcblongs | yes |
| 04:02.10 | quietcblongs | I read a lot of code in the last few days... |
| 04:02.28 | ToAsTcfh | what was it lib-ril used from 2.1? |
| 04:02.44 | quietcblongs | yes, the libril_htc from the leaked 2.1 rom |
| 04:03.05 | quietcblongs | bascially, here is how the setup goes in the 2.0 build |
| 04:03.09 | ToAsTcfh | the one from tur build didnt weork? |
| 04:03.48 | ToAsTcfh | its prolly our kernel |
| 04:04.14 | quietcblongs | I need to test a 1.5 ril on my 2.0 more |
| 04:04.41 | ToAsTcfh | didnt u do that last night |
| 04:04.51 | quietcblongs | I think everything is fairly the same from the rild and down |
| 04:04.56 | ToAsTcfh | u said it kept crashin |
| 04:05.32 | quietcblongs | it was, but I think its because I didn't set it to not retry as often |
| 04:05.47 | quietcblongs | so my AT commands was probably clashing with what the OS was trying to do itself |
| 04:05.48 | ToAsTcfh | ok |
| 04:06.55 | ToAsTcfh | i know the props for the rmnet ip have changed since 1.5 |
| 04:07.42 | ToAsTcfh | net.rmnet0.dns1 now its net.dns1 |
| 04:07.58 | MrPippy | makkonen: the ril we've been using, was it built straight from gitorious, or does it have patches? |
| 04:08.01 | quietcblongs | I don't know if the props are that important as long as getting rmnet0 up |
| 04:10.02 | ToAsTcfh | i can get rmnet up but even then it still wont conect |
| 04:10.43 | ToAsTcfh | even with the ips. maybe if the ril does it instead itll work |
| 04:10.47 | ToAsTcfh | idk |
| 04:11.40 | ToAsTcfh | MrPippy: which strace do u use? |
| 04:11.42 | quietcblongs | well, bringing up rmnet0 manually doesn't do a who lot. its when you can get it to come up through /dev/qmi0. somehow, the phone gets data back and sets up the network with it |
| 04:11.47 | ToAsTcfh | any strace? |
| 04:11.53 | MrPippy | i haven't used strace yet |
| 04:12.01 | MrPippy | our ril is open source, so that is very helpful |
| 04:12.44 | ToAsTcfh | i see... qmi is errored in the logcat also |
| 04:15.02 | ToAsTcfh | MrPippy: lucky bastards!!! lol i never thought id say that about a diam500 user trying to get android running. i was there for the frustration lol |
| 04:16.49 | ToAsTcfh | MrPippy: is Tenny still trying to get things working too.? i havent heard from him in a while |
| 04:17.08 | quietcblongs | is the diam500 msm76xx based? |
| 04:17.16 | MrPippy | tenny? |
| 04:17.21 | MrPippy | and diam500 is msm7501a |
| 04:17.40 | ToAsTcfh | tenny from xda |
| 04:18.38 | ToAsTcfh | its been like 3 months since ive heard from him. i guess he dipped on the project |
| 04:20.11 | MrPippy | yeah looks like he's still active on xda, just nothing linux |
| 04:20.35 | ToAsTcfh | hmm |
| 04:20.49 | MrPippy | theres a new thread on xda of diam500 people looking for android, gonna go introduce myself |
| 04:21.23 | ToAsTcfh | i seen that a week or so ago |
| 04:22.33 | ToAsTcfh | i think they got booted from the old thread. when i left they were trying to organize the thread better |
| 04:23.37 | MrPippy | that thread is just a monster...it hurts inside every time i see the entire collective knowledge on some subject is a 600-page xda thread |
| 04:24.00 | ToAsTcfh | but no matter what as long as something gets fix on another device the diam500 get broken because of it. lol |
| 04:24.58 | ToAsTcfh | the diam500 needs its own board and everything |
| 04:25.05 | MrPippy | yeah the diam500 hasn't worked without patches since the msmsdccid kernel parameter got banished |
| 04:25.21 | MrPippy | but even a 2 month old kernel works much better than what i have right now from the gitorious tree |
| 04:26.03 | ToAsTcfh | i never could get it to boot with sqfs |
| 04:26.19 | ToAsTcfh | even with ur config |
| 04:30.54 | ToAsTcfh | quietcblongs: im out man, i gotta get to bed. i got some ideas for 2morrow. talk to u then |
| 04:32.12 | ToAsTcfh | MrPippy: take it easy and good luck. |
| 04:32.14 | quietcblongs | l8t |
| 04:40.20 | makkonen | MrPippy: I believe that ril is what's up on gitorious. I didn't build it myself, phh just sent me a link to it on his server. |
| 04:59.34 | *** join/#htc-linux rashire (n=ed1112wa@pool-98-114-89-30.phlapa.fios.verizon.net) |
| 04:59.56 | *** join/#htc-linux goxboxlive (n=jrs@mail2.hjellnesconsult.no) |
| 05:22.01 | *** join/#htc-linux makkonen (n=makkonen@cpe-66-69-229-9.austin.res.rr.com) |
| 05:33.06 | *** join/#htc-linux droid001 (n=g1@p4FDC98B1.dip.t-dialin.net) |
| 05:33.13 | *** join/#htc-linux jeremychang (n=jeremych@61-30-10-70.static.tfn.net.tw) |
| 06:01.20 | MrPippy | makkinen: looking at that source is really useful, after the #777 it waits 20 seconds before running pppd, and then checks the error code (incorrectly i think), and declares success |
| 06:14.37 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 06:20.22 | *** join/#htc-linux praxidike (n=praxidik@c-174-56-11-95.hsd1.nm.comcast.net) |
| 06:59.59 | MrPippy | hmm the ril runs "/bin/pppd /dev/smd1", but for me "cat: can't open '/dev/smd1': No such device" |
| 07:02.21 | quietcblongs | MrPippy: do a "ls /dev/s*", you might not have that device |
| 07:03.11 | MrPippy | i have all the devices (0, 1, 7, 27) but the only working one is 0 |
| 07:04.32 | quietcblongs | try /bin/pppd /dev/smd1 noauth local |
| 07:05.36 | MrPippy | it just exits with return value 7, from the man page "The serial port could not be opened." |
| 07:06.53 | *** join/#htc-linux kvaster (n=kvaster@live.bn.by) |
| 07:09.10 | quietcblongs | hmm, not sure what to do about that error then |
| 07:11.10 | MrPippy | yeah i might have to put printks all over the smd code |
| 07:12.40 | quietcblongs | I just straced the stock hero cdma's rild and got some leads, but I'm looking for that one command that is sent to HTC's ril that does all the stuff I can now see in making the data connection. I'd rather not do a hatchet job and just hack all that onto my aosp 2.0 build |
| 07:27.56 | *** join/#htc-linux mattias (n=mattias@84-119-75-240.dynamic.xdsl-line.inode.at) |
| 07:38.45 | MrPippy | very weird, before starting android the smd devices have major number 253, but after android starts they have major 254 |
| 07:39.41 | *** join/#htc-linux kiozen (n=oeichler@p54920CDB.dip0.t-ipconnect.de) |
| 07:54.21 | *** part/#htc-linux quietcblongs (n=Administ@c-76-115-181-74.hsd1.wa.comcast.net) |
| 08:04.07 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 08:04.42 | *** join/#htc-linux kvaster (n=kvaster@live.bn.by) |
| 08:14.03 | *** join/#htc-linux jenericc` (i=ebcain@cpe-24-210-123-84.insight.res.rr.com) |
| 08:43.16 | *** join/#htc-linux jenericc (i=ebcain@cpe-24-210-123-84.insight.res.rr.com) |
| 09:01.49 | *** join/#htc-linux jenericc` (i=ebcain@cpe-24-210-123-84.insight.res.rr.com) |
| 09:29.41 | *** join/#htc-linux luminoso_ (n=lumos@av-217-129-139-239.netvisao.pt) |
| 09:30.40 | *** join/#htc-linux Captnoord (n=Captnoor@145.74.216.254) |
| 09:43.31 | *** join/#htc-linux pjottrr (n=phuisken@dhcp-077-249-139-228.chello.nl) |
| 09:47.56 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 09:52.54 | *** join/#htc-linux marex (n=marex@78.128.198.52) |
| 09:56.16 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 10:00.10 | *** join/#htc-linux kvaster (n=kvaster@93.84.112.80) |
| 10:25.21 | *** join/#htc-linux leobaillard (n=leobaill@leobaillard.org) |
| 10:57.02 | *** join/#htc-linux Squarc (n=Squarc@82.217.32.29) |
| 11:06.28 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 11:18.32 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 11:31.00 | *** join/#htc-linux leobaillard (n=leobaill@leobaillard.org) |
| 11:39.32 | *** join/#htc-linux MethoS- (n=clemens@134.102.106.250) |
| 11:42.40 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 11:47.01 | *** join/#htc-linux balans (n=Gebruike@212-123-149-239.ip.telfort.nl) |
| 12:05.32 | *** join/#htc-linux itchy8me (n=itchy8me@ip80-116-211-87.adsl2.static.versatel.nl) |
| 12:06.14 | *** join/#htc-linux GNUtoo (n=GNUtoo@host30-159-dynamic.44-79-r.retail.telecomitalia.it) |
| 12:31.29 | *** join/#htc-linux phh_ (n=quassel@4be54-3-82-228-187-43.fbx.proxad.net) |
| 12:41.18 | *** join/#htc-linux GeekLad (n=GeekLad@adsl-82-3-110.jax.bellsouth.net) |
| 12:44.53 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 13:02.48 | *** join/#htc-linux jenericc (i=ebcain@24.210.123.84) |
| 13:10.34 | *** join/#htc-linux Lodroid (n=not@217.202.70.101) |
| 13:59.53 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 14:02.30 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 14:08.00 | makkonen | MrPippy: Disable USB_FUNCTION_DIAG in the defconfig. When it initializes, it takes up /dev/smd1 and keeps it from being initialized by smd_7500 for radio function, I think. Or you could do it in the code at drivers/usb/function/diag.c |
| 14:36.26 | *** join/#htc-linux davep (n=dp@CPE-124-188-210-63.sfcz1.cht.bigpond.net.au) |
| 14:38.00 | *** join/#htc-linux davep (n=dp@CPE-124-188-210-63.sfcz1.cht.bigpond.net.au) |
| 14:47.44 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 14:47.44 | *** join/#htc-linux balans (n=Gebruike@212-123-149-239.ip.telfort.nl) |
| 15:02.26 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 15:07.59 | *** join/#htc-linux GoogleWaveGuy (n=GoogleWa@adsl-82-3-110.jax.bellsouth.net) |
| 15:15.18 | *** join/#htc-linux GoogleWaveGuy (n=GoogleWa@adsl-82-3-110.jax.bellsouth.net) |
| 15:15.23 | *** join/#htc-linux GoogleWaveGuy (n=GoogleWa@adsl-82-3-110.jax.bellsouth.net) |
| 15:15.57 | *** join/#htc-linux GoogleWaveGuy (n=GoogleWa@cpe-66-69-229-9.austin.res.rr.com) |
| 15:16.23 | GeekLadfromGoogl | for lack of a better nick, I defaulted it to GoogleWaveGuy |
| 15:16.40 | GeekLadfromGoogl | the applet requires a nick to load |
| 15:18.42 | *** join/#htc-linux AnotherGoogleWav (n=GoogleWa@c-24-18-252-54.hsd1.wa.comcast.net) |
| 15:19.30 | *** join/#htc-linux AnotherGoogleWav (n=GoogleWa@adsl-82-3-110.jax.bellsouth.net) |
| 15:19.42 | *** join/#htc-linux GoogleWaveGuy (n=GoogleWa@adsl-82-3-110.jax.bellsouth.net) |
| 15:20.47 | *** join/#htc-linux NexVision (n=a@c-76-109-33-88.hsd1.fl.comcast.net) |
| 15:55.41 | *** join/#htc-linux kvaster_ (n=kvaster@93.84.112.80) |
| 16:09.58 | *** join/#htc-linux catfishk (n=catfishk@c-76-105-138-218.hsd1.or.comcast.net) |
| 16:12.51 | catfishk | is anyone else having issues with the "u" key not working on RAPH800 with the latest Android images? |
| 16:14.28 | makkonen | all android images. all non-android images, too. |
| 16:14.59 | makkonen | it's a kernel issue. keyboard driver's just a little busted. |
| 16:16.04 | catfishk | oh ok |
| 16:16.29 | makkonen | it teaches you just how important the U key is in modern computer usage. |
| 16:17.46 | catfishk | it certainly does. is there another way to get root without 'sudo' or 'sudo gainroot'? |
| 16:18.40 | *** join/#htc-linux kiozen (n=oeichler@p54920CDB.dip0.t-ipconnect.de) |
| 16:19.27 | makkonen | my method was to make a file with the text 'su' and put it on my sd card. then I named it 's', and just would go to /sdcard and hit ./s |
| 16:20.00 | makkonen | other people have remapped their key layout so that they'd have a function key remapped to u. I haven't looked into how to do that yet. |
| 16:20.22 | *** join/#htc-linux leobaillard (n=leobaill@leobaillard.org) |
| 16:24.35 | catfishk | ah, a little script for it. i will try that |
| 16:25.36 | makkonen | yeah. in android, as far as I can tell, shell scripts seem to complain a bit when you format them correctly. so just put the command in a text file. |
| 16:26.01 | makkonen | (I might've just been formatting my shell scripts incorrectly. But just simple text works.) |
| 16:26.03 | catfishk | ok sure |
| 16:46.00 | *** join/#htc-linux ali1234 (n=al@robotfuzz.co.uk) |
| 16:54.36 | catfishk | makkonen: i ran ifconfig as root- no ppp0 with cricket though the little 3G icon is there |
| 16:56.49 | makkonen | huh |
| 16:57.06 | makkonen | have you tried disabling data in winmo before booting into android? |
| 16:58.09 | catfishk | i have. i don't imagine it's the proxy not bringing it up. probably something in my startup.txt. should i create a new APN? i have been modifying the default Android APN since my custom APNs aren't sticking |
| 17:00.24 | makkonen | this is out of my wheelhouse. I don't know what, if any, effect changing the APN has in cdma. |
| 17:02.15 | catfishk | in your kernel the default Android APN is there, where as in the others' it wasn't |
| 17:02.35 | catfishk | and the little 3G icon too |
| 17:02.43 | makkonen | huh |
| 17:03.48 | makkonen | I had the default android APN coming up on kernels that both had and lacked data... but I never checked earlier kernels to see if it wasn't there. |
| 17:04.01 | catfishk | i will keep playing. where does ppp0 come from- is it brought up by Haret/startup.txt during boot, or by Android when i try to connect? |
| 17:04.28 | makkonen | I don't know what causes the 3g icon to come up -- it came up for me on kernels that didn't even have the data channel enabled. |
| 17:05.02 | makkonen | ppp0 is brought up by the RIL sometime during android's boot process. |
| 17:05.50 | catfishk | do you think it is safe to say if it isn't up at boot, it isn't coming up? |
| 17:06.10 | catfishk | ifconfig ppp0 says no such device |
| 17:08.42 | makkonen | I think that's mostly safe to say. I'm not sure it loads the data connection right on boot -- you might need to manually start something that transfers data -- but if it doesn't form the ppp device at that point, I don't think it'll happen. |
| 17:09.44 | makkonen | I'm mostly guessing on these things, btw |
| 17:10.16 | catfishk | cool. i used your trick to get root so i can play ball now |
| 17:10.24 | catfishk | thanks |
| 17:10.40 | makkonen | I'm trying to get USB stable now, so we can run ADB and get log data as it boots. that should (could) clarify things. |
| 17:12.02 | catfishk | that would definitely be a help |
| 17:13.11 | makkonen | yeah. without good debug data, we are lost. :-) |
| 17:13.47 | catfishk | ;p. off to work. i will post later if i get some data |
| 17:13.57 | makkonen | good luck |
| 17:18.12 | tmzt | makkonen: 3GIND |
| 17:18.58 | makkonen | that's the signal to bring up the 3g symbol? |
| 17:20.03 | tmzt | from the modem I think so |
| 17:20.08 | tmzt | it's an HTC thing |
| 17:22.43 | makkonen | huh. oh. I guess that makes sense. even if the data channel is nonfunctional, if that comes over the AT channel, it thinks everything's happy. |
| 17:23.01 | tmzt | yeah |
| 17:23.10 | tmzt | because you are in a 3g area |
| 17:23.19 | tmzt | which is what the indicator is for |
| 17:23.38 | makkonen | ah. ok. so not at all a good way to determine if data's working. |
| 17:24.07 | *** join/#htc-linux bronek (i=bronek@082139015142.jeleniagora.vectranet.pl) |
| 17:24.08 | tmzt | right |
| 17:24.25 | tmzt | are you writting/working on a ril? |
| 17:24.31 | makkonen | no |
| 17:24.32 | tmzt | otherwise don't worry about that |
| 17:24.51 | tmzt | you can do COLP or something to see if the fake context is up |
| 17:25.05 | tmzt | for cdma |
| 17:25.07 | makkonen | well, someone was just asking about the 3g icon. I didn't know why it would come up. |
| 17:25.23 | tmzt | we need cdma rilj |
| 17:25.30 | tmzt | everything else is a work around |
| 17:26.25 | makkonen | I'm not spending much thought on it. right now I'm trying to figure out where usb broke. |
| 17:26.33 | makkonen | what does the rilj do? |
| 17:27.13 | makkonen | and, I assume, one has to be coded from scratch? the ones from existing cdma devices won't do? |
| 17:30.40 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 17:36.13 | tmzt | rilj is the java side |
| 17:36.28 | tmzt | no, it's open but I have no clue where the source for hero cdma is |
| 17:36.40 | makkonen | ah |
| 17:36.59 | tmzt | the issue is framework, I don't think you can use pre 2.0 rilj with 2.0 |
| 17:37.33 | makkonen | right |
| 17:40.17 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 17:48.35 | parmaster | has anyone found a cheap place to buy the T7272 version of the raphael (international version)? |
| 17:52.37 | parmaster | raph100 i guess |
| 18:01.31 | *** join/#htc-linux toi (n=toi@d54C2A96D.access.telenet.be) |
| 18:03.25 | *** part/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 18:05.59 | *** join/#htc-linux kvaster_ (n=kvaster@live.bn.by) |
| 18:07.19 | *** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
| 18:07.43 | tmzt | parmaster: hey |
| 18:07.50 | tmzt | soon I would think |
| 18:07.56 | tmzt | as tp2 is replacing them |
| 18:08.02 | tmzt | I've got my vzw tp2 |
| 18:10.27 | AstainHellbring | tmzt he's asking for gsm tp |
| 18:11.33 | *** join/#htc-linux _LittleJ (n=linuz@82.78.185.26) |
| 18:14.31 | tmzt | I know |
| 18:14.34 | tmzt | of course |
| 18:18.46 | *** join/#htc-linux BabelO__ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 18:28.26 | *** join/#htc-linux MrPippy (n=pip@adsl-75-36-53-28.dsl.sndg02.sbcglobal.net) |
| 18:38.05 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 18:39.09 | *** join/#htc-linux GlemSom (n=glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk) |
| 18:47.40 | phh | tmzt: have you seen that there is a 1.2k$ bounty for rhod ? :p |
| 18:47.53 | makkonen | wow |
| 18:48.16 | tmzt | for rhod what? |
| 18:48.28 | tmzt | ChanServ: |
| 18:48.49 | phh | android on rhod sorry |
| 18:49.03 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 18:49.18 | tmzt | level of functionality? |
| 18:49.40 | phh | well, for the full 1200k$ it needs to be a ROM :p |
| 18:49.51 | tmzt | of course |
| 18:50.08 | GeekLad | 1200k$? that's $1.2 million |
| 18:50.13 | phh | oops |
| 18:50.18 | phh | -k |
| 18:50.20 | GeekLad | lol |
| 18:50.36 | tmzt | yeah, HTC might pay attention for a million |
| 18:50.40 | GeekLad | hehehe |
| 18:50.42 | tmzt | haha |
| 18:50.44 | GeekLad | indeed |
| 18:50.59 | phh | :) |
| 18:51.04 | tmzt | I was talking with someone about a commercial installer |
| 18:51.09 | tmzt | to make nav work |
| 18:51.24 | tmzt | not to restrict code access, but for the fit and finish |
| 18:51.37 | tmzt | still only present on some of the dzo stuff |
| 18:52.33 | tmzt | I think cyanogen downloads are still an important argument though |
| 18:52.51 | tmzt | the interest in 'rooted' android devices |
| 18:52.57 | tmzt | now including Droid |
| 18:53.34 | tmzt | we need a small proxy to interface rild to ofono by the way to really fix the issues with legacy |
| 18:53.53 | tmzt | as well as time resources for a Qi port, mddi fix, and so many other things |
| 18:54.22 | tmzt | dzo says nbh can't flash yaffs2 |
| 18:54.26 | tmzt | with our spls |
| 18:54.42 | tmzt | that means we will need a recovery partition like android evices |
| 18:54.50 | tmzt | that can initialize the rootfs |
| 18:54.50 | phh | ouch |
| 18:55.42 | tmzt | and an initrd |
| 18:55.51 | phh | we would maybe first need clean working usb ? :D |
| 18:55.52 | tmzt | which I had hoped to avoid |
| 18:56.04 | tmzt | what's wrong with usb exactly? |
| 18:56.29 | tmzt | the diag thing is annoying |
| 18:56.30 | phh | random, not feature full |
| 18:56.39 | tmzt | I debugged with printks in smd-pen |
| 19:04.32 | tmzt | is adb that useful? |
| 19:04.42 | tmzt | maybe a serial console would be better? |
| 19:04.48 | tmzt | serial over usb |
| 19:04.57 | tmzt | or fixing the gadget driver |
| 19:05.07 | phh | adb is nice because it do shell + file transfer+java debugger all in one |
| 19:05.11 | tmzt | which as a composite is hard to set up the pdata for |
| 19:05.17 | tmzt | otherwise should work fine |
| 19:05.32 | tmzt | but for early debiugging |
| 19:05.40 | tmzt | why do you need it |
| 19:06.01 | tmzt | you can logcat over telnet and launch telnetd (swetland's) from init.rc |
| 19:06.55 | phh | (s/telnet/usbnet/) |
| 19:07.11 | tmzt | telnet with usbnet |
| 19:07.17 | phh | I guess I'll do that |
| 19:07.19 | makkonen | how do you logcat over telnet? |
| 19:07.26 | tmzt | type logcat |
| 19:07.34 | makkonen | oh. that's easy. |
| 19:07.45 | phh | you can also do from computer ADB_HOST=blabla adb logcat |
| 19:07.47 | phh | or something like that |
| 19:07.55 | makkonen | is there any buffer for the logs in /dev/log/ ? |
| 19:08.01 | tmzt | just disable functions except ether |
| 19:08.02 | tmzt | yes |
| 19:08.05 | tmzt | true |
| 19:08.21 | tmzt | makkonen: klogd if you install the busybox version |
| 19:08.30 | phh | tmzt: anyway I first want to make a single usb file for all boards |
| 19:08.36 | phh | every board has different default usb setting ... |
| 19:08.49 | tmzt | yeah |
| 19:09.00 | tmzt | but we should really use gadget |
| 19:09.11 | tmzt | and support rndis for windows users |
| 19:09.12 | phh | compositing would be cool |
| 19:09.19 | tmzt | compositing? |
| 19:09.26 | phh | multiple device types at the same time |
| 19:09.30 | tmzt | right |
| 19:09.36 | tmzt | but no good support in windows |
| 19:09.43 | tmzt | that's why they switch product |
| 19:09.50 | phh | oh ok |
| 19:12.10 | makkonen | how difficult is it to get usbnet functional in windows (7, specifically)? Anyone know? I'm trying to get adb working because that I already have up and running in windows. |
| 19:12.36 | *** join/#htc-linux boogeyman (n=boogeyma@unaffiliated/boogeyman) |
| 19:12.49 | makkonen | and I could just teach myself how to route the usb to my linux virtual... but for some reason that seems scary to me. |
| 19:12.56 | makkonen | also, prone to failure. |
| 19:15.25 | tmzt | just use adb over ip |
| 19:15.34 | tmzt | and proxy through the linux version |
| 19:15.42 | tmzt | same env as you posted I think |
| 19:28.49 | *** join/#htc-linux onen|openBmap (n=quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
| 19:37.15 | *** join/#htc-linux balans (n=Gebruike@212-123-149-239.ip.telfort.nl) |
| 19:39.52 | ToAsTcfh | tmzt: i was only able to strace rild. rild-htc wouldnt work and rild-ppp wouldnt either. |
| 19:40.47 | tmzt | hmm |
| 19:40.56 | tmzt | and lsof? |
| 19:41.02 | ToAsTcfh | that in 2.0 thiough |
| 19:41.17 | ToAsTcfh | i couldnt get that to work |
| 19:41.28 | tmzt | use debian |
| 19:41.38 | tmzt | saurik site |
| 19:42.13 | ToAsTcfh | yeah i downloaded it just never got to putting it on |
| 19:42.58 | tmzt | mount -o bind /proc /debian/proc |
| 19:43.06 | tmzt | mount -o bind /sys /debian/sys |
| 19:43.09 | tmzt | first |
| 19:44.08 | ToAsTcfh | ok |
| 19:45.32 | ToAsTcfh | i gotta head back to work now but when i get off at 5 ill prolly get debian up and running |
| 19:46.12 | ToAsTcfh | im guessing this is the last resort?! |
| 19:46.28 | ToAsTcfh | if this wont do it nothing will kinda thing |
| 19:54.27 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 20:15.25 | phh | tmzt: there is some gadget driver for msm7200 in current source tree, do you know if it works ? |
| 20:17.51 | tmzt | \eah |
| 20:18.18 | phh | is that '\' supposed to be a 'y' ? |
| 20:24.50 | *** join/#htc-linux Dinde (i=kayser@sur-internet.net) |
| 20:27.35 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 20:27.56 | *** join/#htc-linux zz_rosseaux (i=znc@129-167-19-84.nbiserv.com) |
| 20:35.24 | tmzt | no I don't know if there any devices without it working |
| 20:35.39 | tmzt | but it's used in qualcomm and the newer android gits |
| 20:43.13 | *** join/#htc-linux TitanMKD (n=aa@vaf26-4-88-176-72-126.fbx.proxad.net) |
| 20:43.30 | TitanMKD | hello |
| 20:45.15 | TitanMKD | anyone has a simple hint to connect Android/linux phone on internet (using PC) through USB ? |
| 20:45.36 | TitanMKD | like WinMo |
| 20:48.36 | *** join/#htc-linux GNUtoo (n=GNUtoo@host30-159-dynamic.44-79-r.retail.telecomitalia.it) |
| 20:52.29 | *** join/#htc-linux MatBee (n=MatBee@d24-150-35-2.home.cgocable.net) |
| 21:10.22 | MrPippy | makkonen: i run ubuntu in vmware on my mac and route usb to that, it works great |
| 21:10.23 | MrPippy | i |
| 21:10.46 | MrPippy | i would really like to see a dmesg from a raph800 with working data, just to see what smd channels are being allocated |
| 21:13.02 | makkonen | oh, you weren't here. |
| 21:13.55 | makkonen | disable USB_FUNCTION_DIAG in the defconfig, or directly in drivers/usb/function/diag.c |
| 21:14.04 | StarLite | where can you see your RAPH version? |
| 21:14.21 | StarLite | device info only sais touch pro 2 |
| 21:14.22 | StarLite | ... |
| 21:15.11 | StarLite | RHO100 prolly then (T7373) |
| 21:16.10 | tmzt | rhod100 |
| 21:16.18 | makkonen | for some reason, it takes up the same smd1 channel as data, and causes data not to come up. |
| 21:16.18 | makkonen | StarLite: pop the battery, it should be listed under there. |
| 21:16.36 | StarLite | ah ok :) |
| 21:16.44 | tmzt | yes, and it's an easy fix |
| 21:16.48 | StarLite | It used to show me HERM100 on my hermes :P |
| 21:16.49 | tmzt | why is this still an issue |
| 21:17.05 | tmzt | if we need to ifdef it we will do that so we don't have to tell everybody how to fix it :) |
| 21:17.24 | makkonen | which, the USB_FUNCTION_DIAG? |
| 21:18.06 | tmzt | ToAsTcfh: we are going to try to use ofono with a proxy for cdma if you want to join in on that |
| 21:18.12 | tmzt | but we need somebody to write the proxy |
| 21:18.36 | tmzt | and of course we still need to know how to negotiate ip and bring up the rmnet |
| 21:38.08 | MrPippy | disabling USB_FUNCTION_DIAG worked, so pppd runs and brings up ppp0 (with an IP), but the connection doesn't actually work |
| 21:38.46 | makkonen | huh. that's a new one. |
| 21:39.00 | phh | MrPippy: what means "doesn't actually work" ? |
| 21:39.08 | makkonen | connection doesn't work, or connection doesn't work in android apps? |
| 21:39.46 | MrPippy | scratch that, its working now :-) |
| 21:39.51 | phh | . |
| 21:39.56 | makkonen | sweet |
| 21:39.59 | leviathan | GNUtoo: hi |
| 21:40.03 | leviathan | following problem |
| 21:40.13 | leviathan | the samsung qdsp5-driver |
| 21:40.22 | leviathan | and the newer rpc-server do not work together |
| 21:40.33 | tmzt | MrPippy: from an android perspective? |
| 21:40.40 | tmzt | if you added defaultroute to the pppd line |
| 21:40.46 | tmzt | you should only need to set the dns in android |
| 21:41.05 | MrPippy | yeah it's all working in android now |
| 21:41.06 | leviathan | trying to solve the depencies and port it to the newer kernel (old rpc and old adsp) downgradet the kernel in an inacceptable dimension |
| 21:41.25 | makkonen | ah. It looks like this is the commit that brings down usb function in my raph800: [f8a613e258a5601156f266de3fc4391c67d3dae7] Add a htc_memory_smem.fake kernel parameter to fake a charger presence. |
| 21:41.32 | makkonen | I love you, git bisect |
| 21:41.34 | phh | makkonen: oO |
| 21:41.45 | leviathan | GNUtoo: I'll go sleep now, but I'll tinker around until it runs |
| 21:41.51 | leviathan | tomorrow or so |
| 21:42.09 | TitanMKD | anyone know why kernel use Git when SVN is ten 10 more easier to use ? |
| 21:42.10 | makkonen | I haven't actually tested it yet, but MrPippy said that it was something about charger that showed up on logcat before the usb went down. |
| 21:42.33 | tmzt | hah, ok |
| 21:42.34 | phh | oh right |
| 21:42.41 | MrPippy | yeah that makes sense now |
| 21:42.43 | makkonen | because Linus Torvalds laughs at the word 'easy'? |
| 21:43.05 | tmzt | I need to check that htc msmfb bisect now |
| 21:43.06 | TitanMKD | makkonen yes maybe ;) |
| 21:43.07 | phh | TitanMKD: I find git easier to use than svn -_- |
| 21:43.19 | phh | tmzt: oh don't worry it's not hard to find which one broke it |
| 21:43.24 | tmzt | 19:24 < phh> git diff |
| 21:43.24 | tmzt | 5b7c96eddecbca3f24d19b064f5e738174b43542..7db6fc5ab790bc7473a151b5d6de625697a413e2 -- htc_fb_console.c |
| 21:43.48 | phh | meaning I broke it in 7db6fc5ab790bc7473a151b5d6de625697a413e2 |
| 21:43.52 | TitanMKD | phh it is a real mess to clean local source when i do not want to keep my change and checkout the files of the rep |
| 21:44.21 | phh | ? |
| 21:44.28 | tmzt | machtype check? thanks :) |
| 21:44.33 | TitanMKD | phh on svn i just need to delete my local file and update ... |
| 21:44.40 | phh | tmzt: yes but it doesn't work. |
| 21:44.51 | phh | TitanMKD: and with git you have to do git checkout |
| 21:44.53 | phh | omg it's SO hard |
| 21:44.53 | tmzt | what did you do? |
| 21:45.01 | *** join/#htc-linux NexVision_pIRC (n=pocketir@m3c5536d0.tmodns.net) |
| 21:45.14 | TitanMKD | phh but it doesn't work sometimes |
| 21:45.16 | tmzt | vga worked fine for what it is |
| 21:45.18 | tmzt | I think |
| 21:45.21 | phh | tmzt: I tried to if(machine_is*()) it, but it didn't work as expected and I commit even if it didn't work, i should have done that |
| 21:45.21 | TitanMKD | phh just strange |
| 21:45.25 | tmzt | or cr2 already fixed this in his .exe |
| 21:45.36 | phh | should*not* |
| 21:45.36 | tmzt | no, we should all have branches |
| 21:45.43 | tmzt | reid99: the earlier linus and git question |
| 21:45.49 | tmzt | re, |
| 21:46.08 | *** join/#htc-linux MethoS- (n=clemens@134.102.106.250) |
| 21:46.12 | tmzt | I think I'm using topa machtype |
| 21:46.18 | tmzt | we need to register 400 and 500 |
| 21:46.24 | phh | TitanMKD: as says tmzt, the proper way is to commit often and revert when you're not okay with your patches |
| 21:46.25 | tmzt | please don't have a generic cdma one this time |
| 21:46.30 | tmzt | that was very confusing with raph |
| 21:46.41 | tmzt | commit on your own branch |
| 21:46.48 | tmzt | we all need some discipline |
| 21:46.55 | phh | yes |
| 21:47.01 | tmzt | let's put htcfb in the pdata then |
| 21:47.10 | tmzt | wiat |
| 21:47.17 | tmzt | we can't we need the console_initcall |
| 21:47.23 | TitanMKD | phh yes it is just i do not use often git |
| 21:47.36 | tmzt | we can get our resources from their if we have a constant struct |
| 21:47.41 | tmzt | extern |
| 21:47.50 | TitanMKD | phh but i really prefer diff with something human like WinMerge or TortoiseMerge with a GUI ;) |
| 21:48.01 | phh | TitanMKD: you mean like gitk ? |
| 21:48.08 | tmzt | try qgit or whatever |
| 21:48.09 | tmzt | yeah |
| 21:48.11 | TitanMKD | phh hmm never teste this one |
| 21:48.16 | tmzt | but it's fonts are bad |
| 21:48.22 | phh | it's tk :p |
| 21:48.32 | tmzt | then use gtk/qt tk bindings |
| 21:48.40 | TitanMKD | phh my prefered is Winmerge on win$ I have never found anything like that on Linux side :( |
| 21:48.55 | phh | I almost never need a gui for such things |
| 21:48.56 | tmzt | when I build uberide from gedit I will have this stuff :) |
| 21:49.48 | tmzt | I'm going to git revert that locally then |
| 21:49.51 | tmzt | I need to play with that command |
| 21:50.34 | phh | tmzt: the whole commit isn't to be removed since part of it actually works :/ |
| 21:50.48 | tmzt | oh |
| 21:51.03 | phh | it's just the part in htc_fb_console |
| 21:51.45 | tmzt | why doesn't it work? |
| 21:52.11 | tmzt | okay, the commit is back |
| 21:52.24 | phh | you reverted the revert ? :p |
| 21:52.39 | phh | I guess come memory addresses were miscalculated |
| 21:52.53 | tmzt | no, I git reset --hard HEAD~1 |
| 21:52.53 | phh | but at the time of writing it seemed good :/ |
| 21:52.56 | tmzt | after the revert |
| 21:52.58 | phh | ah. |
| 21:53.01 | phh | less funny |
| 21:53.14 | tmzt | thanks for the ** fix |
| 21:53.17 | tmzt | looks much nicer |
| 21:53.20 | tmzt | c is smart |
| 21:53.24 | tmzt | not really but |
| 21:53.36 | phh | the ** fix ? |
| 21:53.47 | tmzt | -unsigned char htc_fb_chars[HTC_FB_CON_MAX_ROWS][HTC_FB_CON_MAX_COLS]; |
| 21:53.47 | tmzt | -unsigned char htc_fb_fg[HTC_FB_CON_MAX_ROWS][HTC_FB_CON_MAX_COLS]; |
| 21:53.47 | tmzt | -unsigned char htc_fb_bg[HTC_FB_CON_MAX_ROWS][HTC_FB_CON_MAX_COLS]; |
| 21:53.47 | tmzt | +unsigned char **htc_fb_chars; |
| 21:53.48 | tmzt | +unsigned char **htc_fb_fg; |
| 21:53.50 | tmzt | +unsigned char **htc_fb_bg; |
| 21:54.01 | phh | I allocate memory later |
| 21:54.05 | phh | normally. |
| 21:54.06 | tmzt | yeah, ok |
| 21:54.08 | tmzt | oh |
| 21:54.12 | tmzt | don't do that in this driver |
| 21:54.17 | phh | oh? |
| 21:54.23 | tmzt | druidu did that for a reason |
| 21:54.24 | phh | it's called before machine launch ? |
| 21:54.31 | phh | ok |
| 21:54.34 | tmzt | it's called before alloc can be guaranteed to work |
| 21:54.34 | phh | that's why then |
| 21:54.47 | tmzt | might even be why it doesn't work |
| 21:54.52 | phh | so there is no way to make it multiple machine at the same time |
| 21:54.57 | tmzt | allocate the larger size, ignore |
| 21:55.01 | tmzt | ignore the difference |
| 21:55.09 | tmzt | you free this ram later in __init |
| 21:55.19 | tmzt | just declare with __init |
| 21:55.43 | tmzt | let's do a struct for the phys, offs |
| 21:55.52 | tmzt | this is messy |
| 21:56.02 | tmzt | hmm |
| 21:56.09 | tmzt | looking at your _init now |
| 21:56.36 | TitanMKD | hmm why when guys do patch on hardware they never use volatile to access memory register !! |
| 21:56.47 | tmzt | TitanMKD: linux rules |
| 21:56.50 | phh | makkonen: can you try usb with removing line 446 ? (htc_cable_status_update thing) |
| 21:56.53 | TitanMKD | that suxx |
| 21:56.58 | tmzt | read 'volatile considered harmful' |
| 21:57.03 | TitanMKD | hmm |
| 21:57.19 | tmzt | phh: no kzalloc |
| 21:57.27 | tmzt | phh: ah yeah, we just talked about that |
| 21:57.27 | makkonen | phh: yeah, in a few minutes, when my current compile finishes. |
| 21:57.28 | tmzt | oops |
| 21:57.35 | TitanMKD | but without volatile in a while maybe it can be optimized and do not read in memory but use a register |
| 21:57.44 | tmzt | just assume wvga and fall back to the phys allocation on vga |
| 21:57.50 | TitanMKD | and that create an infinite loop |
| 21:58.08 | tmzt | cr2 wants us to pass the htcfb address from haret |
| 21:58.11 | phh | tmzt: if some phone happens not to be 480pixels wide it would gives some troubles :/ |
| 21:58.15 | tmzt | as atag |
| 21:58.18 | phh | hum |
| 21:58.19 | phh | why not |
| 21:58.45 | phh | but with some fallback if not specified |
| 21:58.48 | tmzt | otherwise looks good, I think alloc is waht's failing |
| 21:58.59 | tmzt | and can you use a var not a define for offs and size |
| 21:59.04 | tmzt | for consistency |
| 21:59.27 | phh | yes that was the lazy way :D |
| 21:59.36 | tmzt | I mean for the characters map the full wvga size buffer |
| 21:59.44 | tmzt | but for the phys ram alloc the correct size |
| 21:59.56 | tmzt | you'll never fully scan out the chars on vga but that's okay |
| 22:00.12 | tmzt | there's a console update call we can use |
| 22:00.16 | tmzt | and make this a proper tty |
| 22:00.27 | TitanMKD | phh but for linux they say for I/O memory it shall be used ;) |
| 22:00.32 | tmzt | I don't care much about msmfb at this point if I can have a failsafe linux console |
| 22:00.58 | tmzt | TitanMKD: they use readw/writew |
| 22:01.03 | tmzt | readl/writel per device |
| 22:01.32 | *** join/#htc-linux Miek (n=mike@unaffiliated/mikechml) |
| 22:01.50 | TitanMKD | yes but on code i look readl/writl ... is not used ;) |
| 22:02.34 | tmzt | what coe? |
| 22:03.11 | TitanMKD | git://git.linuxtogo.org/home/groups/mobile-linux/kernel |
| 22:03.51 | TitanMKD | in vogue_gpio_read() |
| 22:04.07 | TitanMKD | adsp.c |
| 22:04.08 | tmzt | probably dzo, ask him |
| 22:05.32 | TitanMKD | why all different mach-msm are not managed in different ko ? |
| 22:05.42 | TitanMKD | that will avoid all check dones |
| 22:06.01 | TitanMKD | with if machine_is_htctitan() ... |
| 22:06.09 | TitanMKD | it is very crappy design and slow |
| 22:06.09 | tmzt | ko? |
| 22:06.16 | tmzt | you can't put boards in modules |
| 22:06.17 | TitanMKD | yes in kernel module |
| 22:06.20 | tmzt | doesn't work |
| 22:06.34 | tmzt | because that is the right way until we have ops structs or whatever |
| 22:06.36 | TitanMKD | and managed in layer to select the recognized ko to launch depending on detection |
| 22:06.37 | tmzt | where exactly is this? |
| 22:06.49 | tmzt | oh, for the adsp driver? |
| 22:06.56 | TitanMKD | yes but it is everywhere |
| 22:06.58 | tmzt | that could be a module but there's no point in having one per machine |
| 22:07.05 | TitanMKD | mixing tons of type |
| 22:07.11 | tmzt | the check is optimized out if only one device is supported in the .config |
| 22:07.19 | tmzt | yeah, it's messy |
| 22:07.22 | TitanMKD | htctitan, htcvogue and so one with tons of if() ... |
| 22:07.26 | tmzt | we are trying to switch to amss version check |
| 22:07.32 | tmzt | but for now that's how it is |
| 22:07.41 | tmzt | you are welcome to try and clean up our kernel :) |
| 22:07.49 | tmzt | phh: get anywhere? |
| 22:07.52 | TitanMKD | i'm beginner on linux kernel but i'm sure it should be cleaned |
| 22:08.06 | tmzt | I did too before I knew how much work it was |
| 22:08.16 | TitanMKD | it is just i need to read how to write good .ko ;) |
| 22:08.16 | tmzt | I want to get new stuff working :) |
| 22:08.29 | tmzt | modules are the same as builtin mostly |
| 22:08.35 | TitanMKD | yes |
| 22:08.47 | TitanMKD | i do not know where to code the detection of the machine type |
| 22:08.57 | makkonen | yeah... at the moment, it's ugly but it works. which is not ideal, but is better than pretty but it doesn't work. |
| 22:08.59 | TitanMKD | to load the good builtin module ... |
| 22:09.05 | phh | TitanMKD: you want a module per device per board ... ? |
| 22:09.13 | TitanMKD | phh yes ;) |
| 22:09.14 | tmzt | buildin modules are not ko |
| 22:09.17 | tmzt | they're builtin |
| 22:09.23 | phh | TitanMKD: what's the point ... ? |
| 22:09.27 | tmzt | qdsp should be a module but that's an option |
| 22:09.34 | tmzt | and it will still have per device issues |
| 22:09.36 | ali1234 | TitanMKD: those mach_is_xxx() things usually optimize down to (1) if the kernel isn't multiarch |
| 22:09.44 | TitanMKD | phh to have clean design and separate common and specific things |
| 22:09.59 | tmzt | usually? they do, check the defines |
| 22:10.05 | phh | TitanMKD: look a bit at the current situation |
| 22:10.09 | phh | 5 boards |
| 22:10.09 | TitanMKD | phh because with all thos test there is tons of latent bugs |
| 22:10.17 | tmzt | with what test? |
| 22:10.19 | phh | every of these have 90% of the exact same code |
| 22:10.20 | ali1234 | TitanMKD: and you can't put machine specific things into a kernel module anyway, because machine specific is normally needed before you can even get to the point of booting |
| 22:10.31 | tmzt | yeah, this is historical, we are trying to fix it |
| 22:10.42 | phh | TitanMKD: and having to keep one driver per board doesn't give any troubles in maintaining ? |
| 22:10.44 | ali1234 | if if *can* be put in a kernel module then it should probably be module params instead of machine checks |
| 22:11.07 | TitanMKD | phh just by keeping specific things |
| 22:11.25 | phh | TitanMKD: I can't see how you want to do it. |
| 22:11.39 | phh | little modules with parameters per board and big modules with the actual driver per device ? |
| 22:11.49 | phh | (here device means a device in the phone) |
| 22:11.51 | TitanMKD | phh i will just like to have interface comme to all HTC Vogue .. |
| 22:11.52 | tmzt | ali1234: I'm not sure I agree, the multitude of kernel params is bad enough |
| 22:11.58 | tmzt | not everything should be a parameter |
| 22:12.06 | ali1234 | yeah, it should |
| 22:12.08 | TitanMKD | phh to make an abstraction to have less specific code and more common code |
| 22:12.19 | ali1234 | otherwise you have to add in new detection for every machine port |
| 22:12.20 | tmzt | mtype is a parameter, it's just a low level one |
| 22:12.32 | tmzt | the check is very minimal and the fastest path is optimized already |
| 22:12.34 | phh | TitanMKD: I can't see why if(machine_is****) is a problem then ... |
| 22:12.35 | ali1234 | there's no reason why you can;t fall back to the mtype checks if the param is not supplied |
| 22:12.36 | tmzt | so it's a non-issue |
| 22:12.36 | TitanMKD | ali1234 and why not ? |
| 22:12.47 | phh | it's just the same, but without 4-lines-long files |
| 22:12.53 | tmzt | ali1234: you have to add support either way |
| 22:13.07 | tmzt | and we want to do detection based on amss version, not machine |
| 22:13.07 | TitanMKD | ali1234 it is just i have no example how to do that on linux kernel |
| 22:13.08 | ali1234 | tmzt: not if you parameterize what the module is *really* doing |
| 22:13.15 | ali1234 | i can't give examples as i do not know the code |
| 22:13.23 | TitanMKD | ali1234 in the best way of course |
| 22:13.32 | tmzt | also, the data should come from pdata if it's on the platform_bus |
| 22:13.36 | ali1234 | yes, basing it on the firmware version would make much more sense |
| 22:13.47 | tmzt | that gpio read/write in the qdsp driver is in the wrong place |
| 22:13.54 | tmzt | it should be a resource on the device |
| 22:14.08 | phh | TitanMKD: so basically you think that such a commit: http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/commit/e0b3300298ecee6e27d515ec249c066ca6a0baa8 is a bad idea ? |
| 22:14.23 | TitanMKD | does linus torvald has looked in mach-msm stuff ? |
| 22:14.36 | TitanMKD | i'm sure he will found good design for that |
| 22:14.51 | tmzt | he doesn't do this stuff |
| 22:15.00 | phh | he still is a man. |
| 22:15.00 | TitanMKD | because with new phone using other MSM chip it will became a total mess in future ... |
| 22:15.16 | tmzt | it is a mess |
| 22:15.19 | ali1234 | TitanMKD: there is no way around that, you need a mtype for each board, and that is that |
| 22:15.21 | TitanMKD | but it's just my point of view |
| 22:15.37 | tmzt | it is a mess because there isn't an upstreamed submission from Google yet that works on real hardware |
| 22:15.49 | tmzt | (excluding the halibut board, which we can't get) |
| 22:15.58 | TitanMKD | i work on closed embedded software since more than 10 years and all is done like that with BSP and TSP |
| 22:16.07 | ali1234 | haha BSP |
| 22:16.14 | tmzt | it's a mess because two vendors have gone their own way and are not using the new Qualcomm central repositories |
| 22:16.14 | TitanMKD | yes Board Support Package |
| 22:16.27 | tmzt | TitanMKD: you might do well with the ce people |
| 22:16.35 | tmzt | when they want to do something they pull out IDA |
| 22:16.40 | ali1234 | yeah, what was it someone said the other day? if the BSP changes are not upstreamed, you are not ever going to get a newer kernel version... |
| 22:17.06 | TitanMKD | ali1234 but using common interface between BSP |
| 22:17.22 | tmzt | it's a mess because we can't go to the Pavel stuff, with Samsung-derived msmfb and commit to that |
| 22:17.28 | TitanMKD | ali1234 in worst case feature is not available or not implemented using contract .. |
| 22:17.33 | ali1234 | in my experience BSP means a crappy old version of linux with changes that won't ever be upstreamed because they don't follow any of the coding standards |
| 22:17.42 | TitanMKD | ali1234 and it is simpler to do some automatic test ... |
| 22:17.51 | tmzt | because ltg htc-msm-2.6.27 and the commit-a-minute gito 'fork' are good enough |
| 22:18.04 | tmzt | board non-support package |
| 22:18.06 | ali1234 | often it's ever worse since you dont get the real linux source, and can't even compile your own kernel |
| 22:18.23 | ali1234 | or you *can* compile your own kernel as long as you dont want to use any of the BSP drivers |
| 22:18.26 | TitanMKD | ali1234 I do not speak about BSP in Linux world but in my own experiment on embedded software for critical software |
| 22:18.30 | tmzt | 19:10 < tmzt> it's a mess because we can't go to the Pavel stuff, with Samsung-derived msmfb and commit to that |
| 22:18.36 | tmzt | because we need the clock working |
| 22:18.57 | tmzt | we should really document all the changes from halibut |
| 22:19.03 | tmzt | but how much fun does that sound? |
| 22:21.25 | ali1234 | TitanMKD: no other kernel supports anywhere near as many different boards as linux, so whatever you compared it to is irrelevant. |
| 22:21.48 | ali1234 | not only does linux support a huge number of boards, it can support a large number *in one kernel* |
| 22:21.59 | ali1234 | that means the mtype checks are required |
| 22:22.05 | *** join/#htc-linux NexVision_pIRC (n=pocketir@m3c5536d0.tmodns.net) |
| 22:22.06 | TitanMKD | ali1234 yes i just try to learn on linux kernel and to code clean stuff ;) |
| 22:22.29 | ali1234 | the whole point is that you can compile one kernel binary and haveit work on any msm device |
| 22:22.46 | ali1234 | that may not currently be the case but it is the real reason why those mtype runtime tests exist |
| 22:22.48 | phh | well, wince msm device |
| 22:23.04 | phh | mixing android ans wince devices won't be done I think |
| 22:23.11 | makkonen | phh: commenting out that one line in htc_battery_smem.c fixes usb on raph800. Thanks. |
| 22:23.17 | ali1234 | phh: no any msm. all boards in arch/arm/msm or whatever should be supported by a single kernel binary |
| 22:23.23 | TitanMKD | ali1234 but it is same if it was using some sort of .ko depending on detected mtype |
| 22:23.26 | phh | ali1234: well right |
| 22:23.36 | phh | TitanMKD: what's the point of doing it ? |
| 22:23.53 | phh | currently the if(machine_isblabla) is done only once per driver in there init |
| 22:24.00 | TitanMKD | phh to optimize code and clarify without tons of if() ;) |
| 22:24.04 | phh | makkonen: can you see if the hack option still works ? |
| 22:24.17 | phh | TitanMKD: see the link I pasted ? |
| 22:24.17 | makkonen | phh: what do you mean? |
| 22:24.19 | TitanMKD | phh ha ok it should be done only one time |
| 22:24.36 | ali1234 | yes, and if you only have support for one board compiled in, the if(mach_is_XXX) is going to optimise down to if(1) ie no op |
| 22:24.38 | phh | makkonen: this patch adds a kernel option to fake the presence of a charger to android |
| 22:24.42 | TitanMKD | phh but it is not the case on current vogue ... stuff it is why I asked the question |
| 22:25.05 | ali1234 | if they've used hundreds of mach_is_xxx then it needs cleaning up |
| 22:25.18 | makkonen | phh: ah. how do I trigger it? and how do I determine if it is working? |
| 22:25.19 | TitanMKD | ali1234 it seems its the case |
| 22:25.27 | phh | ali1234: raph, raphcdma, raphcdma500, diam, diamcdma and blac |
| 22:25.33 | phh | don't know for vogue tree. |
| 22:25.59 | TitanMKD | phh what are good example to look ? |
| 22:25.59 | ali1234 | TitanMKD: in the case of modules, it is better to use platform resources which can be assigned from the board file |
| 22:26.00 | phh | makkonen: add htc_memory_smem.fake=1 to the kernel cmdline |
| 22:26.08 | phh | and see if when charger is unplugged android thinks it is |
| 22:26.20 | makkonen | that's listed in the dmesg, yeah? |
| 22:26.41 | phh | makkonen: what do you mean with "that" ? the kernel cmdline ? |
| 22:26.50 | makkonen | no, sorry. |
| 22:26.55 | TitanMKD | ali1234 have you an how to about that to explain how that should be done ? |
| 22:27.10 | TitanMKD | ali1234 or an example |
| 22:27.12 | makkonen | the status of the charger when you plug it in and unplug it is shown in the dmesg. yes? |
| 22:27.19 | phh | ali1234: i'm not even sure it's a good idea ... |
| 22:27.20 | ali1234 | look in the Documentation folder, it really contains docs about this stuff |
| 22:27.24 | phh | see board-htcraphael.c and board-htcdiamond.c |
| 22:27.31 | phh | they are almost identical ... |
| 22:27.43 | phh | makkonen: oh yes, it's shown every 10seconds |
| 22:28.08 | phh | grr, I hate doing autonomy tests |
| 22:28.10 | TitanMKD | phh ok |
| 22:28.14 | phh | it disables me from testing kernel stuff |
| 22:28.43 | phh | and my phone has been running for 16hours now /o\ |
| 22:30.32 | Captnoord | oO |
| 22:31.00 | Captnoord | on batt? |
| 22:31.15 | phh | Captnoord: yes, and the battery was only at 60% (or maybe 70%) when i started |
| 22:31.57 | Captnoord | hmmm ubuntu.. I guess... |
| 22:31.58 | Captnoord | no android |
| 22:32.02 | phh | android. |
| 22:32.06 | Captnoord | oO |
| 22:32.16 | phh | no black magic |
| 22:32.23 | Captnoord | cool |
| 22:32.32 | phh | just with the last kernel and a proper data.img |
| 22:32.43 | ali1234 | phh: the board file is for board specific things. if the code is the same between all boards, it shouldn't be in the board file... |
| 22:32.54 | ali1234 | by definition :) |
| 22:33.03 | phh | ali1234: driver loading is the same |
| 22:33.17 | phh | (I mean msm_snd, msm_nand, msm_h2w, pmem, mdp, etc) |
| 22:33.24 | ali1234 | phh: driver loading is a matter of declaring some platform devices and the associated resources |
| 22:34.05 | *** join/#htc-linux bronek (i=bronek@082139015142.jeleniagora.vectranet.pl) |
| 22:34.05 | phh | yup that's what i'm talking about |
| 22:34.05 | phh | but as most phones are almost identical |
| 22:34.05 | phh | most of the code is the same |
| 22:34.05 | ali1234 | yes, that belongs in board file |
| 22:34.17 | ali1234 | but if you have some driver which is doing a lot of mach_is_xxx then chances are you should just make it read from platform resources, what it needs |
| 22:34.49 | phh | phh @ phh-desktop /home2/pt/clean-gitorious/linux-msm/arch/arm/mach-msm % diff board-htcblackstone.c board-htcraphael.c |grep '<' |wc -l |
| 22:34.49 | phh | 119 |
| 22:34.49 | phh | phh @ phh-desktop /home2/pt/clean-gitorious/linux-msm/arch/arm/mach-msm % wc -l board-htcblackstone.c |
| 22:34.49 | phh | 485 board-htcblackstone.c |
| 22:34.49 | phh | phh @ phh-desktop /home2/pt/clean-gitorious/linux-msm/arch/arm/mach-msm % |
| 22:34.59 | phh | here is where such a behaviour leads to. |
| 22:35.21 | ali1234 | why is this bad? |
| 22:35.30 | tmzt | then you do git send-mail |
| 22:35.32 | tmzt | or format-patches |
| 22:35.38 | phh | 300 files are the same ... |
| 22:35.40 | phh | 300 lines* |
| 22:35.45 | tmzt | and send them to our unread/unsubcribed mailing list |
| 22:35.46 | phh | so when a bug is fixed in there |
| 22:35.52 | phh | you have to change both files |
| 22:36.02 | ali1234 | it's better to have 300 lines the same, than to have those 300 lines duplicated across all the driver files that you need |
| 22:36.22 | phh | uh ? |
| 22:36.26 | ali1234 | besides i dont understand the problem here |
| 22:36.28 | phh | if it's in driver it's not duplicated at all |
| 22:36.34 | ali1234 | if the lines are the same, why do you need the mach_is_xxx tests? |
| 22:36.45 | ali1234 | i'm talking about how you get rid of those tests |
| 22:36.55 | ali1234 | the answer is you put it into the board file via resources |
| 22:37.06 | ali1234 | if the code is same it dont matter where you put it, and you dont need the tests |
| 22:37.18 | phh | I see your point. |
| 22:37.30 | ali1234 | cool :) |
| 22:37.48 | phh | but there are a lot of shared "platform_devices" with many code lines, which are the same for every board |
| 22:37.52 | phh | what should we do with that ? |
| 22:38.08 | ali1234 | put it in the board, because it's only defining stuff |
| 22:38.15 | phh | basically, blackstone and raphael has the same memory 2*128 EBI + 32 SMI |
| 22:38.26 | tmzt | good |
| 22:38.31 | tmzt | is that true of some rhod as well? |
| 22:38.32 | phh | there was a "bug" so these boards had only 90MB usable |
| 22:38.46 | phh | or was it even 70 ? |
| 22:38.49 | ali1234 | what if you later found there was a bug, but only with raph? |
| 22:38.57 | phh | anyway, i first thaught of fixing only one, not the other |
| 22:39.11 | tmzt | boards are pointless |
| 22:39.36 | tmzt | google stuff has htchw.c or something now |
| 22:39.39 | tmzt | we need htcce |
| 22:39.40 | phh | tmzt: well, it removes three categories*10drivers if() at startup |
| 22:39.43 | tmzt | we need ops for somethings |
| 22:39.52 | tmzt | the rest can stay amss or mach tests |
| 22:40.17 | ali1234 | phh: thing is, you have a choice between putting it in the board, once, for each board - and having a massive table of if checks for each board somewhere in a file nobody will ever think to look in |
| 22:40.26 | phh | can't this phone run out of battery so that i can try my usb cleanup and go to bed .. bah |
| 22:40.54 | phh | ali1234: memory management is in pmem.c (4days old commit) |
| 22:41.06 | phh | if someone wants to change memory management, it's most likely he'll think of reading here |
| 22:41.13 | makkonen | phh: it looks like faking does not work. When I boot up, with htc_battery_smem.fake=1 in my cmdline, I get the 'it seems the battery is getting low' message on bootup. |
| 22:41.15 | tmzt | phh: can we get this thing reverted |
| 22:41.22 | phh | makkonen: ok |
| 22:41.24 | tmzt | if you have nothing to do waiting :) |
| 22:41.33 | phh | tmzt: you want to revert my pmem.c thing ... ? |
| 22:41.38 | tmzt | no |
| 22:41.41 | tmzt | the htcfb one |
| 22:41.42 | phh | ah |
| 22:41.47 | phh | sure |
| 22:41.50 | tmzt | I'm not using android I can't see how that affects me yet |
| 22:41.50 | phh | doing it now then |
| 22:41.54 | ali1234 | phh: i think same is true on omap. but memory management is really a special case anyway since it's so low level |
| 22:42.50 | MrPippy | if you just want to clean up the tree, most of the defines in board-htcdiamond and htcraphael.h were for pmem and aren't used anymore |
| 22:43.11 | phh | MrPippy: one thing at a time :D |
| 22:43.13 | phh | but you're rihgt |
| 22:43.15 | phh | right* |
| 22:44.34 | MrPippy | btw what is the bug that means only 90MB of RAM is usable? |
| 22:44.58 | phh | MrPippy: every pmem devices were in first bank of EBI |
| 22:45.08 | phh | and second EBI bank is unusable in android for application memory |
| 22:45.19 | phh | and it was a bug, fixed some weeks ago |
| 22:45.21 | phh | tmzt: pushed |
| 22:45.27 | ali1234 | that was fixed then...cool |
| 22:45.44 | TitanMKD | ok i understood |
| 22:45.47 | phh | ali1234: I just forgot to fix it for raphael too for some days |
| 22:45.58 | MrPippy | so pmem can go in ebi2 now? |
| 22:46.09 | phh | MrPippy: ebi2 != ebi 1 bank 2 |
| 22:46.09 | TitanMKD | when there is lot of if(ishtc) .... in fact it is test code |
| 22:46.16 | TitanMKD | which should be removed |
| 22:46.27 | phh | TitanMKD: why should it be removed ... ? |
| 22:46.32 | phh | most of the time it's just at the init time |
| 22:46.33 | TitanMKD | for example in kaiser specific board code there is some check for polaris |
| 22:46.37 | tmzt | what are the timer changes? |
| 22:46.51 | tmzt | actually, this stuff shouldn't be htc specifc at all |
| 22:46.55 | tmzt | there are other msm vendors |
| 22:46.57 | TitanMKD | but the code is in board_polaris |
| 22:47.04 | tmzt | in 2.6.27? |
| 22:47.10 | tmzt | that's not even used by us or dzo then |
| 22:47.11 | phh | tmzt: 2.6.25 for vogue |
| 22:47.15 | tmzt | ah, ok |
| 22:47.24 | TitanMKD | yes i'm on 2.6.25 vogue |
| 22:47.28 | phh | so I don't actually know the sourcecode TitanMKD is talking about :D |
| 22:47.35 | tmzt | should boot with topa now? |
| 22:47.37 | TitanMKD | it is the only one which work with my HTC Kaiser |
| 22:47.54 | phh | tmzt: don't know, I just reverted htc_fb_console thing |
| 22:48.18 | tmzt | it fastforwarded timer |
| 22:48.23 | tmzt | ah, that wasn't you |
| 22:48.41 | tmzt | leaving the ce settings there then? |
| 22:48.43 | tmzt | mhh |
| 22:48.50 | tmzt | hmm |
| 22:49.23 | phh | you're speaking about the recent patch on timer.c ? |
| 22:49.53 | tmzt | yes |
| 22:49.55 | phh | it was just a patch a guy gave me by pm on xda, and at first try it seemed to perform well, but I was totally wrong |
| 22:50.09 | TitanMKD | phh are you agree with me to cleanup code not used ? |
| 22:50.09 | phh | so now yes it uses wince setting again |
| 22:50.17 | tmzt | what's ramconsole on topa? |
| 22:50.25 | tmzt | I'm on rhod but still using topa mtype |
| 22:50.26 | phh | TitanMKD: I know nothing about vogue tree |
| 22:50.31 | tmzt | until rhod500 is registered |
| 22:51.00 | tmzt | <PROTECTED> |
| 22:51.02 | tmzt | ~ramconsoel |
| 22:51.04 | phh | tmzt: default ramconsole setting is 0x0e0000 0x20000 |
| 22:51.04 | tmzt | ~ramconsole |
| 22:51.05 | apt | from memory, ramconsole is pwf dm 0x00800000 0x00100000 |
| 22:51.12 | phh | tmzt: well it's not "everybody" |
| 22:51.15 | tmzt | cool |
| 22:51.18 | phh | it's just blac/raph/diam(/treopro ?) |
| 22:51.24 | TitanMKD | phh and in case of board-htckaiser.c the check of the machine should be only in the init and return if not the good machine right ? |
| 22:51.26 | tmzt | rhod/topa? |
| 22:51.30 | tmzt | ah, no |
| 22:51.44 | phh | tmzt: these ones has to be "ported" to pmem.c |
| 22:51.53 | phh | (and maybe pmem.c made cleaner) |
| 22:51.58 | tmzt | I want to use drm not pmem but whatever |
| 22:52.00 | *** join/#htc-linux StarLite (n=nnscript@s55916cb1.adsl.wanadoo.nl) |
| 22:52.10 | tmzt | apt: ~topa-ramconsole |
| 22:52.20 | tmzt | ~topa-ramconsole |
| 22:52.22 | phh | I really have to add an android kernel option. |
| 22:52.33 | tmzt | for? |
| 22:52.41 | phh | disable pmem stuff |
| 22:52.55 | phh | add two memory banks |
| 22:52.56 | tmzt | apt: ~topa-ramcosnole is pwf dm 0x0e000000 0x20000 |
| 22:52.57 | apt | tmzt: okay |
| 22:52.58 | phh | such things |
| 22:53.03 | tmzt | apt: ~rhod100-ramcosnole is pwf dm 0x0e000000 0x20000 |
| 22:53.04 | apt | tmzt: okay |
| 22:53.09 | tmzt | apt: ~rhod200-ramcosnole is pwf dm 0x0e000000 0x20000 |
| 22:53.09 | apt | tmzt: okay |
| 22:53.14 | tmzt | apt: forget rhod100-ramconsole |
| 22:53.14 | apt | tmzt: i didn't have anything called 'rhod100-ramconsole' to forget |
| 22:53.23 | tmzt | apt: forget rhod100-ramcosnole |
| 22:53.23 | apt | tmzt: i didn't have anything called 'rhod100-ramcosnole' to forget |
| 22:53.31 | phh | tmzt: hum sorry I might be wrong |
| 22:53.41 | phh | it might be 0x8e0000 0x020000 |
| 22:53.43 | tmzt | apt: forget ~rhod100-ramcosnole |
| 22:53.43 | apt | tmzt: i forgot ~rhod100-ramcosnole |
| 22:53.48 | tmzt | apt: forget ~rhod200-ramcosnole |
| 22:53.49 | apt | i forgot ~rhod200-ramcosnole, tmzt |
| 22:53.57 | tmzt | apt: forget ~topa-ramcosnole |
| 22:53.57 | apt | tmzt: i forgot ~topa-ramcosnole |
| 22:54.07 | tmzt | can we be sure here? |
| 22:54.21 | tmzt | apt replaces that part of my brain that never fully formed |
| 22:54.33 | phh | apt: what do you know ? |
| 22:54.37 | phh | bah. |
| 22:54.40 | tmzt | apt: list |
| 22:54.41 | apt | one warez list being sent |
| 22:55.09 | makkonen | apt: list |
| 22:55.10 | apt | one warez list being sent |
| 22:55.48 | makkonen | ...nothing happened. |
| 22:56.10 | phh | no PM ? |
| 22:56.12 | phh | apt: list |
| 22:56.12 | apt | one warez list being sent |
| 22:56.21 | phh | yup, nothing |
| 22:57.11 | makkonen | Neat. I have adb working. This will probably be very useful at some point. |
| 22:58.13 | phh | makkonen: Have you tested with rfkill on if usb works too ? |
| 22:58.34 | phh | I was about to commit a patch to disable it for cdma devices, but as it might be not related ... |
| 22:58.57 | makkonen | usb does not work on cdma devices with rfkill on. |
| 22:59.05 | phh | ok |
| 22:59.18 | TitanMKD | bye |
| 22:59.23 | phh | So i commit rfkill disabling on cdma devices ? |
| 22:59.27 | TitanMKD | and thanks for reply to my questions ;) |
| 22:59.49 | phh | makkonen: does BT works ? |
| 22:59.58 | makkonen | so the rfkill patch and the battery_smem patch are what need to be disabled for cdma usb to work. |
| 23:00.11 | makkonen | I never tested bt even with rfkill on. |
| 23:00.19 | phh | ok |
| 23:00.28 | makkonen | or I tested it once, and it didn't work. |
| 23:00.40 | makkonen | and since it is a low priority for me, I promptly forgot about it. |
| 23:01.01 | phh | well, please test it (or see if someone already tested it) |
| 23:01.09 | phh | if bluetooth works, I won't commit rfkill disactivation for cdma |
| 23:01.17 | phh | oh well |
| 23:01.18 | phh | better ideza |
| 23:01.33 | phh | makkonen: check with haret the GPIO used to enable/disable BT/wifi |
| 23:01.45 | phh | and update http://htc-linux.org/wiki/index.php?title=Raphael_GPIO |
| 23:01.47 | makkonen | how do I do that? |
| 23:02.04 | phh | see http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation |
| 23:02.08 | makkonen | great |
| 23:02.38 | makkonen | can I also use that to figure out why the u key doesn't register? I don't know what level that error is at. |
| 23:03.09 | phh | no |
| 23:03.14 | makkonen | oh well |
| 23:03.17 | phh | you'll see just 2 gpios jumping |
| 23:03.27 | phh | edit microp-ksc.c in drivers/i2c/chips |
| 23:03.35 | phh | and add some debugging printk |
| 23:04.21 | MrPippy | i've been unsure about the memory layout for diam500, and whether it is closer to diamond-gsm or raph-cdma |
| 23:04.32 | MrPippy | like how much smi, whether we have 2 banks of ebi or not |
| 23:05.00 | phh | MrPippy: I think all diams have 128MB EBI + 2*32SMI and raph have 2*128 EBI + 32 SMI |
| 23:05.32 | phh | oh btw MrPippy, I said the memory 90MB bug was fixed, it's only half true, i haven't fixed it for cdma :D |
| 23:05.41 | tmzt | msmfb? |
| 23:05.43 | tmzt | it works? |
| 23:06.23 | tmzt | but no usb |
| 23:06.37 | phh | MrPippy: try rebuilding the kernel with size=107*1024*1024 in htcraphael_cdma_fixup from board-htcraphael.c |
| 23:06.43 | tmzt | CONFIG_HTC_FB_CONSOLE_BOOT=y |
| 23:06.53 | tmzt | so I don't get it, how is msmfb working if the mddi is not supported |
| 23:07.00 | tmzt | ~seen cr2 |
| 23:07.01 | apt | cr2 <n=cr2@82.203.205.227> was last seen on IRC in channel #htc-linux, 5d 23h 37m 23s ago, saying: 'different'. |
| 23:07.06 | phh | can't there be a noop mddi ? |
| 23:07.11 | tmzt | I think there must be |
| 23:07.18 | tmzt | I will be back on in a while I think |
| 23:07.32 | tmzt | I hope we aren't holding a meeting somewhere without wifi |
| 23:07.36 | phh | there is a mddi_client_dummy.c thing |
| 23:08.13 | tmzt | is it enabled for topa? |
| 23:08.42 | tmzt | I need to be able to CFUN=99 to shutdown radio and not lose sms |
| 23:08.45 | tmzt | or boot from airplane |
| 23:09.04 | makkonen | if we can get the smd_rpcrouter issue sorted, we should be able to merge cdma into the main branch... is there anything that can be done about that? |
| 23:09.18 | tmzt | cdma raph? |
| 23:09.20 | makkonen | phh: I meant that ^ as a question for you |
| 23:09.31 | makkonen | yes |
| 23:10.05 | phh | makkonen: that's the idea, I'll retry to fix and maybe even understand this |
| 23:10.31 | makkonen | phh: ok. if I can do anything to help, just shout. |
| 23:10.42 | tmzt | so happy about mddi |
| 23:10.45 | phh | fix it yourself ? :D |
| 23:10.49 | tmzt | I though I had a long battle ahead |
| 23:10.53 | tmzt | to get X back |
| 23:11.05 | makkonen | phh: I'll give it my best. :-) |
| 23:11.06 | phh | bah my phone is still not off ... |
| 23:11.13 | phh | anyway time to sleep. |
| 23:11.16 | makkonen | ...my best is not that great. :-p |
| 23:12.17 | makkonen | tmzt: what does having mddi working mean? framebuffer is functional? |
| 23:12.18 | phh | basically do git diff <working commit tree> -- smd_rpcrouter.c, revert your smd_rpcrouter.c to the working one, and try to integrate the new changes |
| 23:12.46 | tmzt | makkonen: yes, on tp2 cdma/gsm |
| 23:12.58 | makkonen | phh: I tried that a bit and got a lot of kernel panics. I think I need to increase my understanding of what's going on before that'll be helpful. |
| 23:13.15 | phh | makkonen: I can't really help you on that anyway |
| 23:13.23 | makkonen | also, I'm about to test bt with rfkill enabled. |
| 23:13.40 | makkonen | I guess I should have some sort of bluetooth device around here. |
| 23:14.10 | phh | good tests, i'll see your results tomorrow |
| 23:14.17 | makkonen | g'night. |
| 23:16.38 | makkonen | phh: bluetooth won't turn on even with rfkill enabled. |
| 23:18.31 | *** join/#htc-linux Tinyboom (n=nahh@ti0121a340-dhcp0974.bb.online.no) |
| 23:19.17 | MrPippy | i also get this on boot "microp-klt: This hardware is not yet supported: 0b81" |
| 23:20.23 | makkonen | how far through the boot process? |
| 23:20.57 | MrPippy | when its initializing the driver |
| 23:21.30 | makkonen | I think it spits a lot of errors on boot for me, too. |
| 23:21.43 | makkonen | never looked at them too closely, though. |
| 23:23.13 | MrPippy | yeah i guess its just the lcd driver, not hugely important |
| 23:23.50 | makkonen | does your device go to sleep if you touch the touchscreen while data is transferring? |
| 23:25.16 | MrPippy | i didn't try it for long, it reset while i was trying a speed test |
| 23:25.49 | MrPippy | i'm going to try get a ram console up, hopefully there will be something there about why it resets |
| 23:26.16 | makkonen | I haven't been able to get ramconsole working yet. Good luck. |
| 23:29.19 | makkonen | and now I've gotta run. |
| 23:52.12 | *** join/#htc-linux klinux (n=fircuser@41.92.14.238) |