| 00:31.22 | *** join/#htc-linux mistadman (n=mistadma@adsl-250-197-204.msy.bellsouth.net) |
| 00:54.05 | Kevin2 | dcordes: pong |
| 00:54.34 | Kevin2 | dcordes: mmutrace wasn't really designed for tracing 4K pages - but I don't think it is broken. |
| 00:55.11 | mistadman | Hey Kevin2: Whats a mmutrace? |
| 00:55.48 | *** join/#htc-linux surgex (i=surge@pool-71-186-163-107.bflony.fios.verizon.net) |
| 00:56.24 | Kevin2 | mistadman: http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation?action=highlight&value=haret |
| 00:59.33 | mistadman | Kevin2: Thanks dude! This is exactly what I was looking for. Quote: "ability to trap WinCE reads and writes to memory locations" |
| 01:00.21 | mistadman | I am trying to figure out the DPRAM and WIFI Mem maps on the Athena |
| 01:00.26 | mistadman | Thanks! |
| 01:01.02 | mistadman | I have been able to make decent progress on my port of Android for the Athena: http://forum.xda-developers.com/showthread.php?t=393389 |
| 01:01.59 | mistadman | Just using the info on the Athena Research page. But some info was missing... The info you gave me should help fill in the gaps. Thanks! |
| 01:02.20 | Kevin2 | mistadman: No problem. The haret tool has lots of hooks for finding info. |
| 01:02.48 | mistadman | Are you pretty experienced at it? |
| 01:02.57 | mistadman | mmu tracing that is... |
| 01:03.14 | Kevin2 | Yeah. I wrote the code for it. |
| 01:03.38 | mistadman | Dont I feel like an Idiot! |
| 01:03.42 | mistadman | :-( |
| 01:03.53 | Kevin2 | Not at all. |
| 01:18.59 | mistadman | Ok Kevin2. Looks good. |
| 01:19.19 | mistadman | Looks like my output doesnt match the documentation: |
| 01:19.23 | mistadman | 009110: 0297729c: mmutrace 039ffdb0: e1d20cba(ldrh) a9203fca 0000019f (00000000) |
| 01:20.17 | Kevin2 | mistadman: You need to use haretconsole. |
| 01:20.27 | mistadman | Ok |
| 01:20.39 | mistadman | I have it... BRB |
| 01:22.06 | *** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 01:26.01 | mistadman | 018.530(0000020) 03a14e20: e1d230b0(ldrh) # a9203fca==0000011a |
| 01:26.09 | mistadman | There we go. Thanks! |
| 01:27.07 | *** join/#htc-linux dcordes__ (n=dcordes@f049002040.adsl.alicedsl.de) |
| 01:29.25 | mistadman | Kevin2: Is there a way to script the commands so I would not have to retype all those commands? |
| 01:30.04 | Kevin2 | Nothing built in - I just put the commands in a text file and then cut and paste them into haretconsole. |
| 01:30.32 | mistadman | If it works, sounds good to me. Let me try... BRB |
| 01:31.46 | Kevin2 | Oh, if you want to put the text file on the device, you can tell haret to run a script on the device too. I don't use that much. |
| 01:32.09 | *** join/#htc-linux dcordes_1 (n=dcordes@f048034131.adsl.alicedsl.de) |
| 01:32.36 | mistadman | Is the script basically just a list of command or is it written in python like your console? |
| 01:32.47 | mistadman | s/command/commands/ |
| 01:33.51 | Kevin2 | Just a text file with a series of haret commands. |
| 01:37.11 | *** join/#htc-linux dcordes_2 (n=dcordes@g227177223.adsl.alicedsl.de) |
| 01:37.14 | mistadman | 009.999(0019285) IRQS GEDR1: GPIO35(99)=1 |
| 01:37.22 | dcordes_2 | Kevin2: so you think the 4K registers should not be a problem? |
| 01:38.21 | Kevin2 | 4k registers? |
| 01:39.28 | Kevin2 | Running mmutrace on registers is generally not a problem. Running mmutrace on 4k pages of system memory can be a bit tricky. |
| 01:39.34 | dcordes_2 | pages |
| 01:40.10 | dcordes_2 | the big problem in kaiser developement is we can't find out the smem registers |
| 01:40.37 | Kevin2 | But, I don't know of any problems with it - you should be able to set "permissivemmutrace" and try it. |
| 01:42.07 | *** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 01:42.14 | Kevin2 | There is a good chance your not watching all of the addresses of the smem stuff - with "dump mmu" not working, you might not be seeing a full picture of the system. |
| 01:45.13 | dcordes_ | Kevin2: I will reconstruct right now after a reboot |
| 01:45.18 | dcordes_ | maybe you could look at the output |
| 01:53.40 | *** join/#htc-linux dcordes__ (n=dcordes@g227194027.adsl.alicedsl.de) |
| 01:54.03 | dcordes__ | needs a new gateway |
| 01:56.56 | *** join/#htc-linux mistadman (n=mistadma@adsl-250-197-204.msy.bellsouth.net) |
| 01:57.06 | dcordes__ | Kevin2: can you help me testing? |
| 01:59.08 | dcordes__ | Kevin2: I'm not sure about what to do |
| 01:59.51 | *** join/#htc-linux tsdogs (n=tsdogs@62.123.180.130) |
| 02:01.37 | mistadman | Kevin2: Can you decode this: 007277: 0082c200: mmutrace 03a007c0: e7d33009(ldrb) a92001ed 0000002b (00000000) |
| 02:01.50 | mistadman | What does each column mean |
| 02:02.11 | mistadman | I know ldrb = Load Register Byte |
| 02:02.22 | mistadman | what is the dest reg |
| 02:02.31 | mistadman | 00000002b |
| 02:02.33 | mistadman | ? |
| 02:03.00 | mistadman | First column = Time |
| 02:03.39 | dcordes__ | The first column reports the time of the event, the second column shows the address of the instruction that caused the access, the next section shows an assembler representation of the instruction, and the final section shows the address of the memory accessed along with the value that was either read or written. |
| 02:04.00 | mistadman | Got it. Thanks |
| 02:05.27 | Kevin2 | dcordes__: I'm not sure what I can do to help. |
| 02:09.15 | dcordes__ | http://wiki.xda-developers.com/index.php?pagename=KaiserMemoryMap how would I usually trace the complete 1M of smem? |
| 02:10.21 | Kevin2 | I don't see "smem" on that page. |
| 02:10.32 | dcordes__ | <PROTECTED> |
| 02:10.36 | dcordes__ | sorry |
| 02:11.03 | dcordes | I did it with p2v(0x01f00000) 0x? before not sure if that's right |
| 02:11.35 | Kevin2 | Sounds like you'd want "addlist mmutrace 0xb5100000 1024*1024". |
| 02:12.53 | Kevin2 | The problem is, there may be other memory maps to 0xb5100000 that you aren't watching. With "dump mmu" not working, you may not have a good description of the Kaiser memory map. |
| 02:13.26 | dcordes | 000.157 0b907c38: e5933000(ldr) # b51fc00c==00000000 |
| 02:13.27 | dcordes | 000.157 0b907c38: e5933000(ldr) # b51fc00c==00000000 |
| 02:13.43 | dcordes | Kevin2: we have the mmu dump |
| 02:14.19 | dcordes | there are three regions in mmu dump that map to 0x01f00000 |
| 02:14.25 | dcordes | what are those 3 lines? |
| 02:16.09 | dcordes | when I turn the phone on and off (which produces massive AT in/out traffic) they keep reappearing |
| 02:16.13 | dcordes | similar ones |
| 02:16.48 | dcordes | http://rafb.net/p/brrk9D56.html |
| 02:16.53 | mistadman | Hey dcordes... Look like we are both in the same boat. |
| 02:17.10 | mistadman | I am trying to get the phone working on the Athena under Android |
| 02:17.14 | dcordes | mistadman: yes does athena have similar smem interface? |
| 02:17.27 | mistadman | It uses DPRAM |
| 02:17.37 | mistadman | http://wiki.xda-developers.com/index.php?pagename=AthenaMemoryMap |
| 02:18.09 | dcordes | mistadman: looks similar. what is the DP for? |
| 02:18.39 | mistadman | Dual-ported |
| 02:18.42 | Kevin2 | dcordes: Those lines are the memory trace reports. They represent reads and writes to the memory. |
| 02:18.53 | mistadman | http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDual-ported_RAM&ei=cSpTSNvzDIPeerm_pO0P&usg=AFQjCNGMRSPV-q--pa867foDTq_smAPkLg&sig2=GI7FmI0AlWXiSmAWOrjzeg |
| 02:18.56 | dcordes | Kevin2: sounds like what we were looking for all the time on kaiser? |
| 02:19.03 | Kevin2 | If you have three regions, you need to add all three to the "addlist mmutrace" commands. |
| 02:19.46 | dcordes | Kevin2: maybe it didn't work before because of the p2v |
| 02:19.50 | Kevin2 | dcordes: I don't know what you were looking for - but yes, that report indicates it works. |
| 02:19.50 | dcordes | I never have seen those lines before |
| 02:20.03 | dcordes | always put the phys address |
| 02:20.31 | Kevin2 | If you know the virtual address, you're better off stating it explicitly. Again, if you have three maps, you need to explicitly state all three maps. |
| 02:20.51 | Kevin2 | What does "dump mmu 2 0x01f00000 1024*1024" report? |
| 02:21.12 | dcordes | one second. I'm doing a fresh mmu dump |
| 02:22.46 | dcordes | Kevin2: that prints a list with 4K pages |
| 02:23.13 | dcordes | with physical addresses in the 0x01f* area |
| 02:23.41 | dcordes | http://rafb.net/p/n1TYZC20.html |
| 02:25.15 | dcordes | Kevin2: here's the full mmu dump http://linuxtogo.org/~lgorris/mmudump.txt |
| 02:26.38 | dcordes | 4a20a000->4a30b000 maps to 01f* |
| 02:28.09 | dcordes | then there is also 4fc00000 | 01f6a000 | Small (4K) | AP=3000 |
| 02:28.33 | dcordes | <PROTECTED> |
| 02:29.15 | dcordes | 95100000 | 01f00000 | 1MB section | D=0 AP=1 ?=7000 |
| 02:29.20 | Kevin2 | So, you want to add all of those to mmutrace. |
| 02:29.29 | dcordes | b5100000 | 01f00000 | 1MB section | D=0 AP=1 ?=7000 |
| 02:29.38 | dcordes | that's it |
| 02:30.12 | dcordes | 1024*1024 <- does that mean 1MB? |
| 02:30.17 | Kevin2 | Yes. |
| 02:30.22 | dcordes | whatis 4K? |
| 02:30.26 | Kevin2 | 4*1024 |
| 02:30.40 | dcordes | ah ok makes sense :) |
| 02:30.44 | dcordes | I'm stupid |
| 02:31.38 | mistadman | Still doesnt make sense to me. What does that make me :-p |
| 02:31.58 | mistadman | Never mind |
| 02:32.00 | mistadman | I got it |
| 02:32.01 | Kevin2 | You can combine 4a20a000 - 4a30b000 into one map. Something like: addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000) |
| 02:34.37 | dcordes | you read my mind. That's what I wanted to ask |
| 02:35.16 | dcordes | so I have the two 1MB areas, two 4K and that one |
| 02:36.30 | dcordes | ok now I have something I had before when I poked around with random values from the mmu dump |
| 02:36.39 | dcordes | after Replacing windows exception handlers... |
| 02:36.39 | dcordes | Finished installing exception handlers. |
| 02:36.54 | dcordes | I don't get any further output on the console and the phone seems frozen |
| 02:37.18 | dcordes | yes it's locked up |
| 02:37.56 | dcordes | Kevin2: could you look if I did a severe mistake? http://rafb.net/p/HpcjlF33.html |
| 02:39.49 | Kevin2 | dcordes: Looks okay to me. |
| 02:40.20 | dcordes | I did a softreset now and will try all the 4 areas one boy one |
| 02:40.24 | dcordes | s/boy/by/ |
| 02:40.57 | Kevin2 | dcordes: Oh - it locked up. Yeah - the "set permissivemmutrace" is in there for a reason. You might want to pull out the 4fc00000 ones. |
| 02:41.46 | dcordes | okay |
| 02:43.23 | dcordes | Kevin2: so I only do the two 1M pages? |
| 02:43.47 | dcordes | or also addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000) |
| 02:43.49 | Kevin2 | That's the safest. You might also get the 4a.. ones to work.. Only one way to find out. |
| 02:44.27 | dcordes | tried with 0xb5100000 and 0x95100000 in now and that works fine |
| 02:44.46 | dcordes | i.e. no lockup after 10 seconds wirq |
| 02:45.42 | dcordes | Kevin2: console mourns about objdump missing here and now. Is that a problem? |
| 02:48.17 | dcordes | when I turn on bluetooth it spits so many lines, it's giving up |
| 02:50.18 | Kevin2 | dcordes: the objdump thing just means you don't see the instruction disassembled. Are you running haretconsole on linux? |
| 02:50.26 | Kevin2 | What do you mean "it's giving up"? |
| 02:50.35 | *** join/#htc-linux mistadman (n=mistadma@adsl-250-197-204.msy.bellsouth.net) |
| 02:52.34 | dcordes | .....005.861 800592e4: e5952000(ldr) # b51fc128==00000004 |
| 02:52.34 | dcordes | 005.861 80066f68: e1403092(swp?) # b51fc138 =00000002 (b51fc138) |
| 02:52.34 | dcordes | 005861: giving up - clearing mapping |
| 02:52.46 | Kevin2 | dcordes: bleh. |
| 02:52.47 | dcordes | Kevin2: yes ubuntu |
| 02:53.07 | dcordes | that giving up is after it got spammed with reads/writes while activating bluetooth |
| 02:53.31 | dcordes | I got several different read/writes now turning phone on/off, initializing audio conenction to the modem |
| 02:53.41 | Kevin2 | If you have ubuntu, grab the objdump commands from one of the tars - eg, http://www.handhelds.org/~koconnor/haret/haretconsole-20071216.tar.gz |
| 02:53.44 | dcordes | and accessing sim contacts |
| 02:54.24 | Kevin2 | It's giving up because it encountered an unknown instruction. (It's not related to the number of reports it has.) |
| 02:55.21 | dcordes | bash: /usr/bin/arm-linux-objdump: cannot execute binary file |
| 02:56.44 | Kevin2 | Hrmm. I might have packaged a 64bit binary.. |
| 02:57.47 | dcordes | shouarm-angstrom-linux-gnueabi-objdump |
| 02:58.00 | dcordes | org.openembedded.dev/tmp/cross/bin ;) |
| 02:58.16 | Kevin2 | Yeah - that'll work - just copy it into the same directory as haret console. |
| 02:58.27 | Kevin2 | (and rename it). |
| 02:59.26 | dcordes | ok works |
| 02:59.48 | Kevin2 | Can you rerun the command that causes the "giving up". |
| 03:00.12 | dcordes | of course it's just turning on bluetooth |
| 03:00.15 | dcordes | (not turning it off) |
| 03:00.29 | dcordes | Kevin2: is it possible to cancel a wirq? |
| 03:01.01 | Kevin2 | dcordes: Unfortunately, no. |
| 03:02.38 | dcordes | I'm still tracing with the two 1M areas only |
| 03:02.40 | Kevin2 | dcordes: If you have one of the haret logs from a previous case, you can just run "./dis.py < oldlog". That will reprocess the output. |
| 03:03.02 | dcordes | it's finished now |
| 03:03.12 | dcordes | I have to comment a phone trace one second before I forget |
| 03:04.32 | dcordes | ok now to bluetooth |
| 03:05.57 | dcordes | Kevin2: http://rafb.net/p/fBR8J660.html |
| 03:06.11 | dcordes | oh I'm still tracing with the two 1M regions only |
| 03:07.53 | Kevin2 | dcordes: That doesn't have the assembler insns. |
| 03:09.05 | Kevin2 | Doesn't really matter - it's 'swpb r3, r2, [r0]' |
| 03:09.24 | Kevin2 | And yeah - mmutrace doesn't support the swp insn. |
| 03:10.09 | dcordes | sorry didn't understand that at all |
| 03:10.27 | dcordes | how can I make sure haret is able to run the program? |
| 03:10.34 | dcordes | oh I still have the 64 bit one in $PATH |
| 03:11.07 | Kevin2 | Copy the program to the same directory as haret and rename it to arm-linux-objdump |
| 03:11.19 | dcordes | already there |
| 03:11.47 | dcordes | -rwxr-xr-x 1 guybrush guybrush 686538 2008-06-14 04:58 arm-linux-objdump |
| 03:11.47 | dcordes | -rwxr-xr-x 1 guybrush guybrush 4038 2008-05-08 14:43 console |
| 03:12.13 | Kevin2 | Hrmm. That's odd. |
| 03:12.49 | Kevin2 | Try installing cegcc - for example: http://downloads.sourceforge.net/cegcc/mandriva-cegcc-mingw32ce-0.51.0-1.i586.rpm?modtime=1196986548&big_mirror=0 |
| 03:13.01 | Kevin2 | And then remove the arm-linux-objdump from the haret directory. |
| 03:23.06 | mistadman | Kevin2: bash: ./arm-linux-objdump: cannot execute binary file |
| 03:23.29 | mistadman | is arm-linux-objdump an executable? |
| 03:23.32 | Kevin2 | What does /opt/mingw32ce/bin/arm-wince-mingw32ce-objdump report? |
| 03:23.42 | dcordes | Kevin2: it's only rpm and it fscks around with alien |
| 03:24.12 | Kevin2 | Hrmm. I don't know - you can try grabbing the tar.gz and just extracting objdump. |
| 03:24.36 | mistadman | Is it an executable? |
| 03:24.54 | mistadman | Linux executable... |
| 03:28.21 | dcordes | damn sf ./arm-mingw32ce-objdump |
| 03:28.22 | dcordes | Usage: ./arm-mingw32ce-objdump <option(s)> <file(s)> |
| 03:28.36 | dcordes | (the same as the objdump from angstrom toolchain) |
| 03:28.48 | dcordes | I will replace it with the arm-linux-objdump in ./console folder |
| 03:29.00 | dcordes | err the other way around of course |
| 03:29.37 | Kevin2 | dcordes: Do you have a language other than english set for your computer? |
| 03:30.00 | dcordes | yes german |
| 03:30.52 | dcordes | 008.977 0b907d2c: e5933000(ldr) # b51fc00c==00000001 |
| 03:31.09 | Kevin2 | dcordes: Sometimes the tools give different output when a different language is in use. |
| 03:31.31 | Kevin2 | If you run: LANG=C ./dis < oldlog |
| 03:31.31 | Kevin2 | Does that change things? |
| 03:32.04 | dcordes | oldlog is just any haretconsole log? |
| 03:32.08 | Kevin2 | Yes |
| 03:32.39 | dcordes | well what should it do? |
| 03:32.51 | mistadman | Kevin2, dcordes: Can you make heads or tails out of this? http://rafb.net/p/ItUudg56.html |
| 03:33.26 | mistadman | This will probably help: http://wiki.xda-developers.com/index.php?pagename=AthenaMemoryMap |
| 03:33.36 | dcordes | 008.977 0b907d2c: ldr r3, [r3] # b51fc00c==00000001 |
| 03:33.39 | dcordes | Kevin2: better? |
| 03:33.44 | Kevin2 | dcordes: You should see a full description of the instruction - something like: 'swpb r3, r2, [r0]' |
| 03:33.50 | Kevin2 | dcordes: Yes - that is better. |
| 03:34.04 | dcordes | so it's all about the non c standard locale? |
| 03:34.18 | Kevin2 | dcordes: Yeah - I should be able to fix it in the script. |
| 03:35.00 | dcordes | I just tried to trace the funny addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000) |
| 03:35.10 | dcordes | thing and now only haret/haretconsole froze |
| 03:35.15 | dcordes | not the phone itself |
| 03:37.23 | dcordes | although I closed haret now, the phone is terrible slow |
| 03:37.52 | dcordes | not that ce had even been fast.. ^^ |
| 03:38.09 | mistadman | Hey dcordes... Do you know how to read this: http://rafb.net/p/ItUudg56.html |
| 03:38.34 | dcordes | mistadman: sorry. I'm not sure what to do with my own output at the moment |
| 03:39.17 | mistadman | You seem like you know this stuff. |
| 03:39.28 | dcordes | only semi everything |
| 03:39.52 | dcordes | are you the person from the forum who has 20 htcs? |
| 03:40.16 | Kevin2 | mistadman: You asked haret to trap accesses to 0xa9200000 -- it did that, and the log shows all the reads/writes. |
| 03:40.45 | mistadman | Yeah I know that. Now I have to figure out what it all means |
| 03:40.49 | dcordes | Kevin2: so the freeze is wanted in a way? There are no accesses shown |
| 03:41.01 | dcordes | oh that wasn't for me |
| 03:41.33 | dcordes | I will try the two 4K pages now |
| 03:41.42 | mistadman | How would I go about figuring out what it means? |
| 03:42.05 | mistadman | It has to do with AT commands |
| 03:42.55 | dcordes | mistadman: tell me when you found out :P |
| 03:43.20 | mistadman | Will do. I gonna hack on it all night. |
| 03:43.43 | mistadman | I just wish I has someone to nudge me along... |
| 03:43.58 | mistadman | I'll figure it out though. |
| 03:44.30 | Kevin2 | dcordes: You can try http://www.handhelds.org/~koconnor/haret/haret-20080613-swp.exe -- I tried to implement handling of the 'swp' insn - I don't have a test case though. |
| 03:45.32 | dcordes | tracing only 0x4fc0c000 4*1024 I get 024.869 02690460: swpb r3, r2, [r0] # 4fc0c0b4 =4fc0c0b4 (4fc0c0b4) |
| 03:45.35 | dcordes | 024869: giving up - clearing mapping |
| 03:46.05 | dcordes | it is very sensitive to turning the phone on/off |
| 03:46.23 | Kevin2 | Is that with the new haret? |
| 03:46.29 | dcordes | no |
| 03:46.37 | dcordes | I will try that in an instance |
| 03:46.55 | dcordes | yes interesting that's one valid result probably |
| 03:48.59 | dcordes | normal build gives up always on the 4K registers |
| 03:49.55 | Kevin2 | dcordes: What does "echo $LANG" report? |
| 03:50.11 | Kevin2 | (On your ubuntu machine?) |
| 03:50.22 | dcordes | in the terminal I pasted the last output from |
| 03:50.32 | dcordes | $ echo $LANG |
| 03:50.32 | dcordes | de_DE.UTF-8 |
| 03:51.00 | dcordes | arm-linux-objdump is arm-mingw32ce-objdump |
| 03:51.23 | dcordes | thanks for poking around with this btw. I'm very happy this is getting forward |
| 03:52.05 | dcordes | trying your special haret now |
| 03:53.33 | dcordes | 003.637 02690460: swpb r3, r2, [r0] # 4fc0c0b4 =4fc0c0b4 (4fc0c0b4) |
| 03:54.05 | dcordes | with swp haret |
| 03:54.30 | Kevin2 | Does it freeze? Does it keep on reporting? |
| 03:54.51 | dcordes | I did the case which didn't freeze before |
| 03:55.02 | dcordes | i.e. not the strange value |
| 03:55.11 | dcordes | addlist mmutrace 0xb5100000 1024*1024 |
| 03:55.11 | dcordes | addlist mmutrace 0x95100000 1024*1024 |
| 03:55.11 | dcordes | addlist mmutrace 0x4fc0c000 4*1024 |
| 03:55.11 | dcordes | addlist mmutrace 0x4fc00000 4*1024 |
| 03:55.23 | Kevin2 | Good. Does haret keep or reporting after the swp insn, or does it "give up"? |
| 03:55.34 | dcordes | only those. but it gives up quick because the 4K registers always print a give up read/write quickly |
| 03:56.01 | Kevin2 | The haret-swp shouldn't give up any more.. |
| 03:56.07 | dcordes | darn |
| 03:56.29 | Kevin2 | Can you post the full haretlog? |
| 03:56.33 | dcordes | 004.646 0b907d2c: ldr r3, [r3] # b51fc00c==00000001 |
| 03:56.41 | Kevin2 | (from haretconsole?) |
| 03:56.51 | dcordes | now it survived 20 seconds |
| 03:57.00 | dcordes | wait I will do one more with 60 seconds and turn on phone |
| 03:57.59 | dcordes | no it's kind of random I think as soon as smem has reads/writes it gives up when the 4K pages are added |
| 03:58.00 | Kevin2 | Wait.. There's a bug in there.. |
| 03:58.43 | Kevin2 | Hrmm. Just confusing myself. It looks okay. |
| 03:59.24 | Kevin2 | No, wait, there is a bug.. |
| 04:00.42 | Kevin2 | dcordes: Can you try http://www.handhelds.org/~koconnor/haret/haret-20080613-swp2.exe |
| 04:01.12 | dcordes | fetching on phone |
| 04:05.27 | dcordes | HaRET(1)# addlist mmutrace 0xb5100000 1024*1024 |
| 04:05.28 | dcordes | HaRET(2)# addlist mmutrace 0x95100000 1024*1024 |
| 04:05.28 | dcordes | HaRET(3)# addlist mmutrace 0x4fc0c000 4*1024 |
| 04:05.28 | dcordes | HaRET(4)# addlist mmutrace 0x4fc00000 4*1024 |
| 04:05.28 | dcordes | HaRET(5)# wirq 100 |
| 04:05.41 | dcordes | 004.295 02690460: swpb r3, r2, [r0] # 4fc0c0b4 =4fc0c0b4 (4fc0c0b4) |
| 04:05.41 | dcordes | 004295: giving up - clearing mapping |
| 04:05.43 | dcordes | :( |
| 04:09.40 | Kevin2 | dcordes: That's really odd - are you sure you're running the new haret? Can you post the full log? |
| 04:10.17 | dcordes | no therefore I just removed all haret binaries, softresetted and now fetch again |
| 04:12.40 | dcordes | Kevin2: ok that was clean now I'm 100% sure that's the correct exe |
| 04:12.45 | dcordes | http://rafb.net/p/NWyOu171.html |
| 04:13.23 | Kevin2 | dcordes: Can you post the raw haret log? |
| 04:13.30 | dcordes | yes |
| 04:14.47 | dcordes | http://linuxtogo.org/~lgorris/haretlog-20080614_061051.log |
| 04:14.54 | *** join/#htc-linux ltxda (n=ltxda@c-98-201-10-242.hsd1.tx.comcast.net) |
| 04:18.37 | mistadman | Hey dcordes!! I made a slight break through already!! |
| 04:18.45 | dcordes | mistadman: what is it? |
| 04:19.09 | mistadman | http://rafb.net/p/Eqrujv90.html |
| 04:19.29 | dcordes | what does it mean? |
| 04:19.32 | mistadman | This is the ouput of my mmutrace when I dial a number |
| 04:20.00 | dcordes | wanna see mine :) ? |
| 04:20.19 | dcordes | http://rafb.net/p/b85rEk31.html |
| 04:20.24 | mistadman | The first six lines setups my dpram for reading |
| 04:20.57 | mistadman | Line 2 is the ptr to the next read a9203fca==00000088 |
| 04:21.04 | mistadman | offset |
| 04:21.07 | dcordes | so the output is EVERYTHING which happens on the traced pages? |
| 04:21.15 | mistadman | 00000088 |
| 04:21.47 | mistadman | If you look at line 8: # a9200089==0000002b |
| 04:21.51 | dcordes | what is ptr?? |
| 04:22.00 | mistadman | a9200089 |
| 04:22.12 | mistadman | pointer |
| 04:22.19 | mistadman | points to an address |
| 04:23.00 | mistadman | Line 2 tell the cpu to start fetching at offset 00000088 + 1 |
| 04:23.20 | mistadman | which give you: a9200089 |
| 04:23.26 | dcordes | aah that makes sense |
| 04:23.34 | mistadman | If you look a the value of a9200089 |
| 04:23.49 | mistadman | Its 0000002b |
| 04:24.20 | mistadman | Which is hex for 43 |
| 04:24.42 | dcordes | ah now I get the system |
| 04:25.01 | mistadman | If you translate that to ascii: http://www.google.com/imgres?imgurl=http://www.computerhope.com/ascii.gif&imgrefurl=http://www.computerhope.com/jargon/a/ascii.htm&h=600&w=505&sz=20&tbnid=1OaLN53mzc4J::&tbnh=135&tbnw=114&prev=/images%3Fq%3Dascii&hl=en&sa=X&oi=image_result&resnum=1&ct=image&cd=1 |
| 04:25.07 | mistadman | you get "+" |
| 04:25.24 | dcordes | aha so we have an at instruction here |
| 04:25.42 | dcordes | AT+ |
| 04:25.50 | mistadman | not quite |
| 04:26.07 | mistadman | Next i did ran command in haret: |
| 04:26.22 | dcordes | addr2mod |
| 04:26.37 | mistadman | vdump 0xa9200000 1024 |
| 04:26.58 | mistadman | Here is the output: http://rafb.net/p/tVYqu681.html |
| 04:27.57 | mistadman | So if you go to the first link and decode the hex to ASCII you get: +CLCC: |
| 04:28.09 | mistadman | so on an so forth |
| 04:28.33 | dcordes | I wonder if it works similar in my output |
| 04:28.38 | mistadman | Of course this is just a small portion of a complex issue. |
| 04:29.36 | mistadman | But this will help me determine how to implement the logic behind creating a phone driver for the Athena |
| 04:30.26 | mistadman | I just looked at your output. |
| 04:30.53 | dcordes | mistadman: I think on the kaiser it's less difficult |
| 04:31.06 | mistadman | I would have to agree. |
| 04:31.10 | dcordes | we already have the serial device and we can read the AT commands from it directly from the linux kernel |
| 04:31.22 | mistadman | So whats the issue |
| 04:31.25 | mistadman | ? |
| 04:31.30 | dcordes | what I should do now is confirm the write buffer registers - but I do not know how to |
| 04:31.37 | dcordes | wanna see the code? |
| 04:32.11 | mistadman | I have already saw it. Actually, I have been following you project very closely |
| 04:32.33 | dcordes | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/kaiser-smd.c;h=713028dce388c27f288c827f1ddb0253b2afa486;hb=4134160a774aad737ac3efadd81366e3c9f27c08 280-282 |
| 04:32.36 | mistadman | I am trying to get the Athena up to where you guys are |
| 04:32.46 | dcordes | cool I'm famous |
| 04:32.57 | Kevin2 | dcordes: Can you try: http://www.handhelds.org/~koconnor/haret/haret-20080613-swp3.exe |
| 04:32.59 | dcordes | do you know how I can confirm those registers? |
| 04:33.05 | dcordes | Kevin2: sure |
| 04:33.23 | mistadman | dcordes: First you should verify you can trace the reads correctly |
| 04:33.30 | mistadman | Have you done so? |
| 04:33.36 | mistadman | Using MMU Trace |
| 04:34.15 | mistadman | Let me look at your code. On sec... |
| 04:37.11 | dcordes | Kevin2: you're da man it works |
| 04:37.28 | dcordes | no freeze |
| 04:38.26 | mistadman | You say you can read the AT commands? Don |
| 04:38.51 | mistadman | Dont you usually send AT commands? |
| 04:39.23 | mistadman | What kind of command are you reading? |
| 04:39.25 | dcordes | no idea how that's called but the modem replies in a way |
| 04:39.30 | mistadman | s/command/commands |
| 04:39.31 | dcordes | in modem lingo |
| 04:39.40 | dcordes | which looks similar like the commands you send |
| 04:39.45 | dcordes | you can read sms :) |
| 04:39.50 | dcordes | and see when somebody calls |
| 04:39.54 | mistadman | Got it |
| 04:39.55 | dcordes | it prints pages of crap |
| 04:40.12 | mistadman | Ahh... I see. |
| 04:41.02 | dcordes | Kevin2: haretlog-20080614_063536.log in my ~ |
| 04:42.41 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 04:44.58 | mistadman | dcordes: You are missing something with your mmutrace |
| 04:45.06 | mistadman | You need to do a better trace |
| 04:45.54 | mistadman | Can you post this: |
| 04:45.57 | dcordes | now I can use the Kevin2 coding magic |
| 04:46.20 | dcordes | mistadman: in the paste with phone call I had only 2x 1MB page areas |
| 04:46.20 | mistadman | addlist mmutrace 0xb5100000 0xfc124 |
| 04:47.18 | mistadman | can you try: addlist mmutrace 0xb5100000 0xfc124? |
| 04:47.27 | mistadman | And post the output... |
| 04:47.40 | dcordes | yes. how do you come to that offset? |
| 04:47.52 | mistadman | http://wiki.xda-developers.com/index.php?pagename=KaiserMemoryMap |
| 04:48.13 | mistadman | Wait |
| 04:48.19 | mistadman | Scratch that |
| 04:48.27 | mistadman | Do this instead... |
| 04:48.36 | dcordes | the offset is only valid for the physical addresses? |
| 04:49.04 | mistadman | addlist mmutrace 0xb5100000 0x545b0 |
| 04:49.06 | mistadman | No |
| 04:49.20 | mistadman | Its like saying virt + 0x545b0 |
| 04:49.35 | mistadman | So it doesnt matter physical or virt |
| 04:49.41 | dcordes | can you remove addlist mmutrace actions? |
| 04:49.55 | Kevin2 | clear mmutrace |
| 04:49.57 | mistadman | What do you means |
| 04:50.03 | dcordes | yea thx |
| 04:50.05 | mistadman | Like removelist |
| 04:50.12 | mistadman | command? |
| 04:51.35 | dcordes | mistadman: no accesses |
| 04:52.09 | mistadman | No access with this command: addlist mmutrace 0xb5100000 0x545b0 ? |
| 04:52.20 | dcordes | right |
| 04:52.40 | dcordes | turned phone on and made call while tracing |
| 04:52.59 | mistadman | Would not matter if phone is on or off |
| 04:53.08 | mistadman | Try this then |
| 04:53.34 | mistadman | vdump 0xb5100000 0x545b0 |
| 04:54.12 | dcordes | Kevin2: do you know why "addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000)" kills everything on wirq? |
| 04:54.48 | dcordes | mistadman: ok you hit one of the at fifos |
| 04:55.04 | mistadman | post your output |
| 04:55.11 | dcordes | starting at b51041f0 |
| 04:55.24 | dcordes | until b5106040 |
| 04:55.43 | dcordes | rest are zeros |
| 04:56.17 | mistadman | Let me see the output. |
| 04:56.40 | Kevin2 | dcordes: There is a large number of things that could kill it. In order for haret to trace, it has to trap a full megabyte of virtual memory. If something else in that megabyte doesn't like being trapped, it could cause everything to break. Also, if windows tries to change a mapping mid way through a trace, it will cause everything to break. |
| 04:57.18 | dcordes | mistadman: it's still dumping |
| 04:58.17 | dcordes | Kevin2: that's why it's getting slow |
| 04:58.35 | dcordes | because the mmu is dorky and windows bricks everything writing in all directions |
| 04:58.49 | mistadman | Opps... Didnt relize I told you to dump 345k |
| 05:00.01 | mistadman | If thats the case. We should be able to mmu trace. Unless like keven2 said, something weird is going on the kaiser |
| 05:01.10 | mistadman | I really believe if you can sort the mmu trace issue, this will be the key to unlocking your issue. |
| 05:01.53 | dcordes | there is only a problem with addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000) |
| 05:02.50 | dcordes | mistadman: what do you expect to see in addlist mmutrace 0xb5100000 |
| 05:02.56 | dcordes | <PROTECTED> |
| 05:03.29 | mistadman | Dcordes: Do you think the memmap page is wrong? It says your write ptrs are located at: 0x041fc and 0x04200, |
| 05:03.52 | dcordes | yes I think so because they do not work |
| 05:03.57 | dcordes | only read must be correct because read works |
| 05:03.59 | mistadman | Well it will allow you to trace the logic and verify tail and head ptrs |
| 05:04.30 | mistadman | Could just be an error in the code. Or... |
| 05:04.48 | mistadman | Wait... |
| 05:05.01 | mistadman | I just though of something... |
| 05:05.05 | dcordes | the memory map is nothing sure. it's just the mmu dump combined with observations from reverse engineering dlls or haret traces |
| 05:05.58 | mistadman | Dcordes: Do you know how the read and writes works? |
| 05:06.04 | mistadman | I think I do now |
| 05:06.11 | dcordes | mistadman: what do you mean exactly? |
| 05:06.38 | mistadman | Do you understand the logic behind how the Kaiser reads and writes AT commands? |
| 05:07.08 | dcordes | semi. I know it is a circular buffer for each in or out thing |
| 05:07.24 | dcordes | so you have an at send circular buffer and an at read circular buffer for example |
| 05:07.35 | mistadman | Follow along with me on this page: http://wiki.xda-developers.com/index.php?pagename=KaiserMemoryMap |
| 05:07.44 | dcordes | ok |
| 05:08.15 | mistadman | 0x041fc and 0x04200 points to the begining and end of data in buffer |
| 05:08.35 | mistadman | Hence "head pos" and "tail pos" |
| 05:08.43 | mistadman | Following me so far? |
| 05:09.17 | dcordes | yea. it writes so long beginning at head until tail is reached and then starts over at head? |
| 05:09.24 | dcordes | like a snake trying to eat itself :) |
| 05:09.44 | mistadman | yeap |
| 05:09.48 | Kevin2 | Good night. |
| 05:09.52 | dcordes | that's how martin__ explained it |
| 05:10.07 | dcordes | Kevin2: nightey and thanks a thousand times for the help |
| 05:10.45 | dcordes | mistadman: so how do we find out the right values? |
| 05:11.11 | mistadman | So in the case when you receive an SMS mgs. The kaiser will set the 0x04200 to point to the beginning of the buffer |
| 05:11.13 | dcordes | in case they are wrong currently |
| 05:11.36 | mistadman | Wait thats backwards |
| 05:11.36 | dcordes | like a symlink? |
| 05:11.51 | dcordes | which makes it 8 |
| 05:12.06 | mistadman | 0x041fc will point to the begining of the buffer |
| 05:12.13 | mistadman | Yes like a symlink |
| 05:12.20 | dcordes | ok |
| 05:12.27 | mistadman | and 0x04200 will be the end |
| 05:13.15 | mistadman | So basically read between the values stored at 0x041fc <---> 0x04200. |
| 05:13.54 | mistadman | If this is the case then |
| 05:14.08 | mistadman | 0x32424 will point to the RX buffer head |
| 05:14.31 | mistadman | and 0x32428 will point to end of the RX buffer |
| 05:14.42 | dcordes | yea that's how it is in the wiki |
| 05:14.56 | mistadman | So all you would have to do is: |
| 05:15.31 | mistadman | vdump 0xb5132424 4 |
| 05:15.42 | mistadman | and see what the value is |
| 05:15.48 | dcordes | b5132424 | 00001755 | U... |
| 05:16.46 | mistadman | That should be the offset to the buffer |
| 05:17.09 | dcordes | 1755? |
| 05:17.28 | mistadman | Actually, it would get us somewhere inside the buffer. |
| 05:17.55 | dcordes | I don't quite understand where did you get the virtual b51* address from now? |
| 05:17.59 | mistadman | Its a circular buffer, so we probably wont read the whole buffer at one time |
| 05:18.18 | mistadman | 0xb5000000 0xb5100000 0x01f00000 1 SHARED_MEM A9/A11 |
| 05:18.28 | dcordes | yes |
| 05:18.44 | mistadman | 0xb5100000 = wince virt |
| 05:18.55 | dcordes | yea I know but what is the offset? |
| 05:19.13 | mistadman | Im trying to figure it out now. |
| 05:19.17 | mistadman | Looking... |
| 05:19.19 | dcordes | <PROTECTED> |
| 05:19.33 | dcordes | ah now I understand you just grap the virt base and put the phys offset? |
| 05:19.39 | dcordes | s/grap/grab/ |
| 05:20.10 | mistadman | Its really not a phy offset. Just offset |
| 05:20.14 | mistadman | Or size |
| 05:21.34 | dcordes | HaRET(14)# vdump 0xb51041fc 4 |
| 05:21.34 | dcordes | b51041fc | 00000362 | b... |
| 05:22.57 | mistadman | That point to the address of your buffer |
| 05:23.02 | mistadman | with in your buffer |
| 05:23.15 | mistadman | Let me look at the code and double check |
| 05:23.17 | mistadman | on sec |
| 05:23.39 | dcordes | ok |
| 05:23.42 | mistadman | Ok |
| 05:23.45 | mistadman | Got it |
| 05:23.59 | mistadman | What does this equal? MSM_SHARED_RAM_BASE |
| 05:24.09 | dcordes | 0xb5100000 0x01f00000 |
| 05:24.16 | dcordes | it's correct in the kernel source |
| 05:24.29 | dcordes | of course it is set to the 0x01f* not hte virt |
| 05:24.50 | dcordes | include/asm-arm/arch-msm/msm_iomap.h |
| 05:25.01 | mistadman | What is it equal to 0xb5100000? Let me look. |
| 05:25.03 | mistadman | On sec |
| 05:26.29 | mistadman | Your wrong! |
| 05:26.33 | dcordes | huh? |
| 05:26.38 | mistadman | Its equal to 0xE0100000 |
| 05:26.59 | mistadman | #define MSM_SHARED_RAM_BASE 0xE0100000 |
| 05:27.06 | dcordes | are you sure? |
| 05:27.08 | dcordes | why? |
| 05:27.31 | mistadman | Check for your self: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob_plain;f=include/asm-arm/arch-msm/msm_iomap.h;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 05:27.45 | mistadman | Easy. |
| 05:28.01 | dcordes | huh |
| 05:28.11 | mistadman | Do you see it? |
| 05:28.22 | dcordes | of course linux base is not = wince virt |
| 05:28.27 | mistadman | Line 100 |
| 05:28.34 | dcordes | ye |
| 05:28.39 | mistadman | Nope wrong again. |
| 05:28.50 | dcordes | why should anything in the kernel match wince virt? |
| 05:28.51 | mistadman | Ok... Here is whats going on. |
| 05:29.13 | mistadman | I believe that has to do with the MMU. |
| 05:29.23 | mistadman | MMU controls virt to phys mappings |
| 05:29.33 | dcordes | I don't think wince virt is relevant in linux |
| 05:29.37 | dcordes | it has it's own virtual mapping |
| 05:29.48 | dcordes | wince virt is /dev/null after takeover |
| 05:29.53 | mistadman | ON the athena wince virt matches linux virt (ioremap) |
| 05:30.05 | dcordes | hm |
| 05:30.15 | mistadman | Wait... one sec |
| 05:30.34 | mistadman | http://wiki.xda-developers.com/index.php?pagename=AthenaMemoryMap |
| 05:30.40 | mistadman | Yeah I am right |
| 05:30.46 | dcordes | athena != kaiser |
| 05:30.52 | mistadman | Well at least on Athena |
| 05:31.03 | mistadman | I am almost positive |
| 05:31.16 | mistadman | Doesnt matter now. |
| 05:31.22 | dcordes | maybe because the msm tree is more specific/ more mature |
| 05:31.34 | mistadman | Could be... But |
| 05:31.55 | mistadman | Now back to : 0xE0100000 |
| 05:33.07 | mistadman | Something is weird |
| 05:33.16 | dcordes | why? |
| 05:33.42 | mistadman | I know the code is wright be cause you can receive sms messages. |
| 05:33.54 | dcordes | yes. that's the odd thing |
| 05:34.01 | dcordes | why should write be wrong then?? |
| 05:34.13 | mistadman | It may not be. |
| 05:34.25 | mistadman | I believe the answer is in the code. |
| 05:34.26 | dcordes | yes we already discussed possible other problems like irq |
| 05:34.34 | mistadman | Wait... |
| 05:35.21 | mistadman | I bet after you write to mem you need to set head and tail ptr. |
| 05:35.39 | dcordes | that would be in the code I guess |
| 05:36.17 | mistadman | Then you will probably have to send a magic command. Something like IRQ or write to an address. Then this will tell the kasier to process command in buffer |
| 05:36.29 | mistadman | Or something along that line. |
| 05:36.58 | mistadman | thats why you need to do mmu trace to see what happens and how |
| 05:37.52 | dcordes | this is just a dump assumption but: The code is the same on vogue and on vogue, it works. |
| 05:38.01 | dcordes | so why would we need a magic thing but not vogue? |
| 05:38.18 | dcordes | maybe that is one of the differences between msm7500 and msm7200 |
| 05:38.21 | mistadman | Do they have the same processors? |
| 05:38.32 | mistadman | Could be |
| 05:38.36 | dcordes | vogue msm7500, kaiser msm7200 |
| 05:39.53 | dcordes | so assuming that magic thing is really just on msm7200, how would I ever find out? |
| 05:40.03 | dcordes | (what that thing is) |
| 05:40.05 | mistadman | I have been looking a lot of hardware and there are small differences between arches of same family. |
| 05:40.23 | mistadman | Let me take a long look at the code. |
| 05:40.30 | mistadman | Hollar if you need me |
| 05:40.37 | dcordes | ok cool |
| 05:41.10 | dcordes | I know there is an irq from arm9, that reports arm11 that there is data to read. |
| 05:41.14 | dcordes | it's in the kaiser-smd.c |
| 05:41.52 | dcordes | 438 |
| 05:42.08 | dcordes | <PROTECTED> |
| 05:43.23 | mistadman | Read is ok, is there one for write? |
| 05:44.45 | dcordes | that is the question |
| 05:45.18 | dcordes | mistadman: can you tell me by the look of the code which interrupt Read is? |
| 05:45.31 | mistadman | Yes. |
| 05:45.35 | mistadman | Look at line |
| 05:45.43 | dcordes | it was too much maths :D |
| 05:46.29 | mistadman | Actually there are a couple: |
| 05:46.35 | mistadman | See lin 402 |
| 05:46.40 | mistadman | s/lin/line |
| 05:46.56 | dcordes | int smd_wait_until_writable(smd_channel_t *ch, int bytes)? |
| 05:47.13 | mistadman | Sorry line 401: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/kaiser-smd.c;h=713028dce388c27f288c827f1ddb0253b2afa486;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 05:47.47 | dcordes | oops my local code is complete different. I merged something in there.. |
| 05:47.49 | mistadman | You see? |
| 05:48.07 | dcordes | yes right that line I tried to figure which is the irq but didn't udnerstand |
| 05:48.13 | mistadman | Ok easy |
| 05:48.20 | mistadman | This is a loop |
| 05:48.30 | mistadman | for(i=0;i<7;i++) { |
| 05:48.34 | dcordes | yep |
| 05:48.36 | mistadman | That goes to 7 |
| 05:48.47 | mistadman | i will = 0 thru 7 |
| 05:49.08 | mistadman | next line 402 is where the magic happens |
| 05:49.32 | mistadman | r = request_irq(INT_A9_M2A_0+i, smd_irq_handler, IRQF_TRIGGER_RISING, "smd_dev", 0); |
| 05:49.49 | mistadman | INT_A9_M2A_0 |
| 05:49.54 | mistadman | Is your IRQ |
| 05:50.20 | mistadman | But because it is added to i: INT_A9_M2A_0+i |
| 05:50.30 | mistadman | it will be (INT_A9_M2A_0+1 |
| 05:50.33 | mistadman | (INT_A9_M2A_0+2 |
| 05:50.34 | mistadman | (INT_A9_M2A_0+3 |
| 05:50.38 | mistadman | (INT_A9_M2A_0+4 |
| 05:50.39 | mistadman | .... |
| 05:50.41 | mistadman | etc |
| 05:50.56 | mistadman | Now we just need to find the value of INT_A9_M2A_0 |
| 05:51.04 | mistadman | One sec |
| 05:51.19 | dcordes | ok |
| 05:51.48 | mistadman | Looking at the headers line 16-31 |
| 05:53.26 | dcordes | which? iomap? |
| 05:53.30 | mistadman | Ok found it: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=include/asm-arm/arch-msm/irqs.h;h=565430cfaa7e8be779469d609a4c90a7c485b2c8;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 05:53.35 | mistadman | irqs.h |
| 05:54.18 | dcordes | so the irq arm9 thows when it sends something is 0? |
| 05:54.26 | dcordes | s/thows/throws/ |
| 05:54.32 | mistadman | Exactly |
| 05:54.37 | mistadman | look at line 402 |
| 05:55.02 | mistadman | It calls smd_irq_handler() |
| 05:55.50 | dcordes | http://wiki.xda-developers.com/index.php?pagename=Kaiser_IRQ surprise surprise |
| 05:56.12 | dcordes | irq 1 and 2 show visible activity on smem activity in wince |
| 05:56.20 | mistadman | I was just going to send that link to you. LOL |
| 05:56.33 | dcordes | ;) |
| 05:56.41 | dcordes | so why is not 0 visible but only 1 and 2? |
| 05:57.03 | mistadman | What? |
| 05:57.04 | dcordes | maybe wince handels the irqs different so that it uses 1 or 2 for the receive notify? |
| 05:57.09 | mistadman | You lost me |
| 05:57.12 | dcordes | in the irq wiki |
| 05:57.18 | dcordes | ok.. sorry |
| 05:57.25 | mistadman | Im looking at it |
| 05:57.57 | mistadman | Let compare this with the vouge's irq list |
| 05:58.17 | dcordes | don't got it |
| 05:59.33 | mistadman | And its not on the wiki either |
| 05:59.55 | dcordes | dzo is a lone warrior |
| 06:00.47 | mistadman | On the wiki It says the irq 1 and 2 for the kasier is for cams |
| 06:01.03 | dcordes | nono not only |
| 06:01.14 | mistadman | Huh? |
| 06:01.29 | mistadman | What do you mean not only? |
| 06:01.32 | dcordes | it is acvite permanently when the phone is on |
| 06:02.01 | dcordes | when you have phone of and switch camera on/off you also see them in haret |
| 06:02.10 | dcordes | (I put the Kaiser Function fields) |
| 06:02.57 | mistadman | I believe you, but if thats the case then your code is wrong... |
| 06:03.06 | dcordes | ok |
| 06:03.08 | mistadman | Wait... |
| 06:03.25 | dcordes | you think we should use 1 and 2 for the notifiers? |
| 06:04.04 | mistadman | Yeah, just as I though. The code is crapped! |
| 06:04.07 | mistadman | LOL |
| 06:04.27 | dcordes | it's msm7500A code |
| 06:04.31 | dcordes | and I have msm7200 |
| 06:04.49 | dcordes | it works on the msm7500 (with the other registers for the fifos of course) |
| 06:05.00 | dcordes | do we have to invent an at send irq? |
| 06:05.03 | dcordes | function |
| 06:05.06 | mistadman | Basically, your code allocates irq 0 - 7 to check for data |
| 06:05.19 | mistadman | You dont need all though IRQs |
| 06:05.34 | mistadman | Problem is though... Do you know which? |
| 06:05.40 | mistadman | Is the right one? |
| 06:05.41 | dcordes | :( |
| 06:05.49 | dcordes | brute force? |
| 06:05.58 | mistadman | Haret |
| 06:06.04 | dcordes | how? |
| 06:06.16 | mistadman | But thats not our problem though |
| 06:06.29 | dcordes | why? |
| 06:06.30 | mistadman | At leas I dont think so |
| 06:06.47 | mistadman | Go to line 402 |
| 06:07.11 | dcordes | we always have to keep in mind that receive works the way it is and on vogue both works so it can't be that wrong |
| 06:07.15 | dcordes | yes |
| 06:07.31 | mistadman | This line says: |
| 06:07.59 | mistadman | Any time irq 0 thru 7 is raised call smd_irq_handler() |
| 06:08.04 | mistadman | Got it? |
| 06:08.14 | dcordes | not really |
| 06:08.21 | dcordes | what does it mean it's raised? |
| 06:08.45 | mistadman | every time a signal is sent over Irq |
| 06:08.52 | dcordes | ok |
| 06:09.13 | mistadman | Irq is basically a simple signal. either high or low |
| 06:09.29 | dcordes | so if irq 0,1,2,3,4,5,6 or 7 are active structure smd_irq_handler() is called? |
| 06:09.40 | mistadman | Just tells the cpu that a piece of hardware is trying to get its attention |
| 06:09.51 | dcordes | ok |
| 06:09.52 | mistadman | Yes |
| 06:10.13 | dcordes | and that raise |
| 06:10.17 | dcordes | it comes from arm9? |
| 06:10.21 | mistadman | Irq is just like tapping someone on the shoulder to get their attention |
| 06:10.26 | mistadman | no |
| 06:10.34 | mistadman | It come from hardware |
| 06:10.51 | mistadman | Other hardware |
| 06:10.56 | dcordes | I don't get this |
| 06:10.59 | mistadman | But is connect to arm8 |
| 06:11.06 | mistadman | arm9 |
| 06:11.07 | dcordes | but that hardware has drivers |
| 06:11.16 | dcordes | and those drivers rum in arm9 |
| 06:11.22 | mistadman | Write |
| 06:11.26 | mistadman | right |
| 06:11.36 | mistadman | Think of it like this: |
| 06:11.58 | mistadman | How does the cpu know when its time to read sms message |
| 06:12.00 | mistadman | ? |
| 06:12.07 | mistadman | Easy IRQ |
| 06:12.40 | mistadman | when the buffer is ready for read, it activates an IRQ line. |
| 06:12.42 | dcordes | yes but this AT bytes come from arm9 so arm9 has to raise the irq doesn't it? |
| 06:12.47 | mistadman | No |
| 06:13.05 | mistadman | AT bytes from from qualcomm modem |
| 06:13.19 | mistadman | Which is a piece of hardware |
| 06:13.25 | dcordes | how does arm11 (smd_irq_handler) know there is data? |
| 06:13.34 | dcordes | qualcomm modem=arm9 |
| 06:13.40 | mistadman | No |
| 06:13.43 | dcordes | system processor(kernel)=arm11 |
| 06:13.44 | dcordes | yes |
| 06:13.51 | mistadman | Oh |
| 06:13.51 | dcordes | trust me on that one.. |
| 06:13.57 | mistadman | Im sorry |
| 06:14.00 | dcordes | although you're the person with the background knowledge |
| 06:14.02 | mistadman | Your right |
| 06:14.15 | mistadman | two separate cpus |
| 06:14.18 | mistadman | Sorry |
| 06:14.21 | dcordes | it's a bit confusing. yes |
| 06:14.31 | dcordes | that's why you got confused on the irq page: |
| 06:14.42 | mistadman | I really like to think of the qualcomm as a blackbox |
| 06:14.43 | dcordes | the arm9 doesn't only have the modem but also cam, gps |
| 06:14.55 | dcordes | right it's a proprietary evil brick |
| 06:15.14 | mistadman | Not to interested in processor, becuse we are not suppose to play with it |
| 06:15.22 | mistadman | FCC wouldnt like it |
| 06:15.41 | mistadman | yes "proprietary evil brick" |
| 06:16.05 | mistadman | But back to explanation... |
| 06:16.22 | dcordes | whatever open source software you run on arm11, you will not so easily see the gps, modem, or camera driver |
| 06:16.39 | mistadman | When its time to read data an IRQ line is triggered |
| 06:16.48 | mistadman | You lost me again... |
| 06:17.13 | dcordes | there is a nice story about a US car manufacturer who was forced by police to access their customer's in car camera over the net to identify badboys |
| 06:17.47 | mistadman | Sounds like myth to me |
| 06:17.48 | dcordes | mistadman: and that one is triggered from the arm9 (modem) now, right? |
| 06:18.21 | mistadman | "That one" = IRQ right? |
| 06:18.27 | dcordes | mistadman: one can believe it or not it's still a nice example of what can you do with blackboxes. |
| 06:18.47 | dcordes | mistadman: yes |
| 06:19.27 | mistadman | goto line 150 |
| 06:19.39 | dcordes | restate: When there is data to read, we (arm11,kernel) receive an IRQ raise notification from the arm9 (modem) |
| 06:19.45 | dcordes | ok |
| 06:19.58 | mistadman | Awesome! |
| 06:20.01 | mistadman | Thats right |
| 06:20.14 | mistadman | and line 150 gets called |
| 06:20.36 | mistadman | or static irqreturn_t smd_irq_handler(int irq, void *data) |
| 06:20.46 | mistadman | See that> |
| 06:20.48 | mistadman | See that? |
| 06:20.57 | dcordes | wait diggin into it |
| 06:21.26 | mistadman | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/kaiser-smd.c;h=713028dce388c27f288c827f1ddb0253b2afa486;hb=4134160a774aad737ac3efadd81366e3c9f27c08#l150 |
| 06:21.34 | mistadman | Click here ^^ |
| 06:21.35 | dcordes | yea got it |
| 06:22.02 | mistadman | This is a very simple funct that just calls check_for_smd_data(); |
| 06:22.45 | mistadman | Now go to 137 |
| 06:22.52 | dcordes | there is a pritnk. useful will uncomment this |
| 06:23.01 | mistadman | Go for it |
| 06:23.16 | mistadman | printks are your friend |
| 06:23.16 | dcordes | hm my code is modified too much I need to checkout fresh |
| 06:23.42 | mistadman | do you know about "git diff" |
| 06:23.44 | dcordes | smd_channel |
| 06:23.55 | dcordes | mistadman: yes I'm pretty familiar already with it |
| 06:24.01 | mistadman | ok |
| 06:24.09 | mistadman | Are you at 137 |
| 06:24.12 | dcordes | I'm the proud "founder" of this repository :) |
| 06:24.16 | dcordes | yes |
| 06:24.24 | mistadman | Really! |
| 06:24.31 | mistadman | Linuxtogo? |
| 06:24.37 | dcordes | haha no. |
| 06:24.41 | mistadman | Oh |
| 06:24.50 | dcordes | I just had the idea making the htc-msm branch in the repository |
| 06:25.01 | mistadman | Cool |
| 06:25.07 | dcordes | because we were fooling around with diffs for weeks |
| 06:25.11 | dcordes | anyway |
| 06:25.16 | mistadman | I wish I could host my Athena Git There |
| 06:25.23 | dcordes | mistadman: yes feel free |
| 06:25.35 | dcordes | the more the merrier. It's best when we have everything at one place |
| 06:25.40 | mistadman | Maybe later you can tell me how. |
| 06:25.52 | dcordes | speak with pH5 or kevin2 about it |
| 06:25.53 | mistadman | Would get more exposure there |
| 06:26.12 | dcordes | what tree do you base on? |
| 06:26.13 | mistadman | Alright. Can I tell them you sent me to them |
| 06:26.26 | ellisway | mistadman which model of athena are u working on ? |
| 06:26.26 | mistadman | 2.6.24 vanilla |
| 06:26.33 | mistadman | x7501 |
| 06:26.42 | dcordes | you work from vanilla? Which chipset is athena? pxa? |
| 06:26.49 | mistadman | yes |
| 06:26.57 | dcordes | it will be easy merging with linuxtogo for you |
| 06:27.00 | ellisway | i`m waiting on tmobile uk to get the x7510 |
| 06:27.16 | dcordes | ellisway: mistadman where are the differences between the athenas? |
| 06:27.36 | dcordes | ellisway: ah you swapped your kaiser for it, right? |
| 06:27.41 | ellisway | good question |
| 06:27.41 | mistadman | I believe on the camera between x7501 and x7500 |
| 06:27.47 | ellisway | yeh |
| 06:27.52 | ellisway | well sent kaiser back |
| 06:28.59 | ellisway | couldn`t work with it the same as on the universal |
| 06:29.23 | mistadman | dcordes: line 137 is probably the most important part of your code |
| 06:29.38 | dcordes | mistadman: the check_for_smd_data(void) function. looks to me like smd channel is relevant there (there are several: AT send/recv, gps recv, modem data send/recv, they all have an id) |
| 06:29.55 | dcordes | I don't know where the channel n is defined |
| 06:30.01 | dcordes | cr2 talked about it |
| 06:30.46 | mistadman | we need to find: ch, &smd_ch_list, ch_list |
| 06:30.52 | mistadman | These are important |
| 06:30.59 | mistadman | on line 142 |
| 06:31.16 | dcordes | that is the channel ID I talked about above I guess |
| 06:31.28 | dcordes | let me grep the source |
| 06:31.34 | mistadman | Hey |
| 06:31.36 | mistadman | wait |
| 06:31.43 | mistadman | Look for list_for_each_entry |
| 06:32.30 | mistadman | Looks like a custom loop. Never seen anything like this in C |
| 06:33.10 | mistadman | I still have a long way to go with this language |
| 06:33.23 | dcordes | clocl.c |
| 06:33.42 | dcordes | yes same here. I hardly know any c |
| 06:33.57 | mistadman | ok ch is a struct |
| 06:33.58 | dcordes | clock.c has list_for_each_entry |
| 06:35.57 | mistadman | Now I am looking thru code I think i know what it does. |
| 06:36.53 | mistadman | static LIST_HEAD(smd_ch_list) |
| 06:37.04 | mistadman | Can you grep that |
| 06:37.12 | mistadman | What is LIST_HEAD |
| 06:37.14 | dcordes | second |
| 06:37.35 | mistadman | I think it has something to do with defining smd_ch_list |
| 06:38.33 | dcordes | kaiser-smd.c clock.c dma.c and rather irrelevant: smd_rpcrouter.c |
| 06:39.31 | dcordes | maybe that is a big mistake and rpcrouter is relevant |
| 06:39.40 | dcordes | cr2 always say we don't need it but I never asked why |
| 06:40.00 | dcordes | this is assumption is maybe because the communication done with it is specific to the software on arm9 |
| 06:40.03 | dcordes | aka AMSS |
| 06:40.11 | mistadman | You could always comment it out |
| 06:40.12 | mistadman | / |
| 06:40.14 | mistadman | // |
| 06:40.42 | dcordes | rpcrouter is much about smd channels though |
| 06:41.20 | mistadman | You could always just comment it out and try to compile |
| 06:41.36 | dcordes | the rpcrouter? |
| 06:41.38 | mistadman | If it compiles without errors, then you know its not needed :-) |
| 06:41.42 | mistadman | Yes |
| 06:42.04 | dcordes | I don't think we ever built it for kaiser |
| 06:42.42 | mistadman | built what? |
| 06:42.42 | dcordes | CONFIG_MSM_ONCRPCROUTER produces smd_rpcrouter.o etc |
| 06:42.57 | dcordes | rpc router. I don't use it and at read works without it |
| 06:42.58 | ellisway | is that static list_head right |
| 06:43.00 | dcordes | so we can ignore this |
| 06:43.19 | ellisway | i`ve never seen list_head done static only ever seen it as a struct |
| 06:44.10 | mistadman | Ok dcordes |
| 06:44.14 | dcordes | I don't know I always assume it's okay because most works on the vogue |
| 06:44.26 | mistadman | list_for_each_entry |
| 06:44.34 | dcordes | grep? |
| 06:44.42 | mistadman | and ch_list sounds interesting |
| 06:44.54 | mistadman | What is the ch_list |
| 06:45.25 | dcordes | generic_gpio.c clock.c kaiser-smd.c have list_for_each_entry |
| 06:45.27 | mistadman | list_for_each_entry loop thru ch_list |
| 06:45.34 | mistadman | What is the ch_list |
| 06:46.06 | mistadman | send channel ? receive channel? |
| 06:46.10 | dcordes | right |
| 06:46.29 | mistadman | This is important |
| 06:46.31 | dcordes | at tx/rx, umts data tx/rx, gps rx, |
| 06:46.35 | dcordes | they all have an ID |
| 06:46.40 | mistadman | Ahh |
| 06:46.41 | dcordes | but I don't know where that list is |
| 06:46.51 | dcordes | that's the smd channel number/id/whatsoever |
| 06:46.57 | dcordes | I think gps is 7 |
| 06:47.07 | dcordes | it should be somewhere in the logs but I can't find it |
| 06:47.11 | mistadman | So how do you know this? |
| 06:47.16 | dcordes | cr2 told it :) |
| 06:47.27 | mistadman | Let me see if I can find |
| 06:47.30 | mistadman | One sec |
| 06:47.51 | dcordes | I guess it's specific to chips so we should have a difference to the vogue/halibut code |
| 06:48.07 | mistadman | possibly... |
| 06:48.44 | dcordes | halibut is the device google uses for evaluation with the basic tree. On top of that are the vogue changes, and on top of that the kaiser stuff. that's what we have in the git |
| 06:49.18 | mistadman | got it |
| 06:49.33 | dcordes | and there was no change to the SMD related stuff expect of the register thing in kaiser-smd.c which is heavily commented |
| 06:49.38 | mistadman | Err... I mean... I got what you said |
| 06:50.13 | dcordes | all in all there is not too much kaiser specific in the whole tree |
| 06:50.44 | mistadman | I know, I have been following you progress... |
| 06:51.22 | mistadman | You guys basically piggy backed off of DZOs work. |
| 06:51.36 | dcordes | yep |
| 06:51.43 | dcordes | he enabled booting |
| 06:51.43 | mistadman | Because obviously the hardware is related |
| 06:52.00 | dcordes | I poked around with haret months until he did the patches that made the htcs boot |
| 06:54.00 | dcordes | did you find the channel list? |
| 06:54.46 | mistadman | Yes |
| 06:54.59 | mistadman | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=include/linux/list.h;h=75ce2cb4ff6ebc92a8fcaa557a9bd7b6b9b9b1b6;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 06:55.27 | mistadman | I found LIST_HEAD_INIT |
| 06:56.01 | mistadman | i mean LIST_HEAD |
| 06:56.09 | dcordes | include/linux/list.h sounds kind of general |
| 06:56.21 | dcordes | and not arch specific |
| 06:56.45 | mistadman | I had reading marcos |
| 07:01.10 | mistadman | dcordes: Do you know how smd_open() gets called? |
| 07:01.16 | mistadman | line 235 |
| 07:01.21 | dcordes | no |
| 07:03.05 | dcordes | that's the function with the kaiser specific register changes. |
| 07:03.47 | mistadman | This could be a clue... |
| 07:03.56 | mistadman | Go to line 279 |
| 07:04.11 | mistadman | <PROTECTED> |
| 07:04.33 | dcordes | irq 0 ?? |
| 07:04.58 | mistadman | Nope. Thats channel # |
| 07:05.13 | mistadman | I dont know what a channel is though. |
| 07:05.26 | dcordes | the thing between if and else is a channel |
| 07:05.33 | dcordes | this is the AT channel |
| 07:05.42 | dcordes | with send and recv circular buffer |
| 07:05.52 | mistadman | You lost me again... |
| 07:06.03 | mistadman | Between if and then |
| 07:06.07 | mistadman | n==0? |
| 07:06.32 | dcordes | l.280->l.285 is an smd channel |
| 07:06.37 | dcordes | AT |
| 07:06.46 | mistadman | where are you? |
| 07:06.50 | dcordes | those are the registers for the fchannel |
| 07:06.52 | dcordes | kaiser-smd.c |
| 07:06.58 | mistadman | what line |
| 07:07.06 | dcordes | 280-285 |
| 07:07.21 | dcordes | after if(n==0) { |
| 07:07.32 | mistadman | Ahhh... Sorry, I got it now... |
| 07:07.39 | dcordes | this is what was changed for kaiser |
| 07:07.44 | mistadman | l.280 threw me off |
| 07:07.54 | mistadman | I know |
| 07:07.56 | dcordes | pretty much the only kaiser specific change in the whole SMD code |
| 07:08.14 | dcordes | and the registers there represent one channel, the AT channel |
| 07:08.23 | mistadman | What I am doing is tracing thru the code in my mind |
| 07:08.40 | mistadman | stepping thru it to understand how read and writes happen |
| 07:08.53 | mistadman | More specifically how writes happen. |
| 07:08.57 | dcordes | yea I see that. unfortunately I can't do this because I don't have any C experience |
| 07:09.19 | dcordes | makes me notice I got have learned it 10 times in the time I'm dealing with kaiser |
| 07:09.32 | mistadman | I am guessing channels will end up being GPS, MODEM, Bluetooth, etc |
| 07:09.37 | mistadman | What do you think |
| 07:09.41 | dcordes | no |
| 07:09.43 | dcordes | not bluetooth |
| 07:09.45 | dcordes | it's uart |
| 07:09.52 | mistadman | Got it |
| 07:10.03 | mistadman | So whats on channels then? |
| 07:10.05 | dcordes | what I know is AT, UMTS, CAM |
| 07:10.12 | mistadman | Ok |
| 07:10.26 | dcordes | line 287-292 |
| 07:10.30 | dcordes | that's what dzo uses for umts data |
| 07:10.33 | dcordes | 3g data whatsoever |
| 07:10.37 | dcordes | afaik |
| 07:10.45 | mistadman | Let me look at kasier changes... |
| 07:10.49 | mistadman | Thinking... |
| 07:10.57 | mistadman | Checking mem address |
| 07:11.07 | mistadman | s/address/adressess |
| 07:11.13 | dcordes | I don't understand it when I compare them vs wiki |
| 07:11.14 | mistadman | s/address/adresses |
| 07:11.30 | mistadman | what dont you understand? |
| 07:12.27 | dcordes | in the code, tx buf is at MSM_SHARED_RAM_BASE+0x041fc |
| 07:12.47 | dcordes | in the wiki, ATCMD tx buf is 0x01f00000 +0x04208 |
| 07:13.51 | dcordes | I could also chose recv buf |
| 07:13.52 | dcordes | same there |
| 07:15.49 | dcordes | and except of head and tail there are start and size |
| 07:15.55 | dcordes | in the code |
| 07:17.17 | mistadman | I see what you mean |
| 07:17.35 | mistadman | But we can double check it by stepping thru the code. |
| 07:18.16 | mistadman | This portion of the code just setup mem locations. Now we need to find the read and write code |
| 07:18.53 | dcordes | ok so let's assume the read and write mem locations to be setup properly |
| 07:21.06 | mistadman | We know the read is correct right? |
| 07:21.21 | mistadman | Look at smd_read(). Line 203 |
| 07:21.45 | dcordes | mistadman: well it works. Maybe it's only partially correct or so. I can't proof it's right |
| 07:22.00 | dcordes | but at least it works |
| 07:22.19 | dcordes | if we get that far on the write it would be fine |
| 07:22.30 | dcordes | I don't think there is data missing in the read though |
| 07:22.34 | dcordes | so ok line 203 |
| 07:22.58 | mistadman | Look at the comment on line 202. |
| 07:23.11 | mistadman | Read data and then notify arm9 |
| 07:23.20 | dcordes | oh that's useful |
| 07:23.42 | mistadman | line 209 |
| 07:24.17 | dcordes | if there is data return -EINVAL? |
| 07:24.18 | mistadman | line 209 check to make sure data is more than 0 |
| 07:24.57 | mistadman | 211 says: end of data is located here. Now assign it to mytail. |
| 07:25.19 | mistadman | 211 says: end of data is located here (buffer->tail). Now assign it to mytail. |
| 07:25.42 | mistadman | 212 will loop until all data is read |
| 07:26.13 | mistadman | Notification magic happens on line 224 |
| 07:26.44 | mistadman | Yeap. Go to line 52 |
| 07:27.15 | dcordes | so each time a circular buffer is full, irq is raised so it can be picked up and be filled again? |
| 07:27.30 | mistadman | No |
| 07:28.33 | mistadman | It does a complete read of the buffer between the head and tail value. The head and tail value is a location with in the Shared Memory space |
| 07:28.46 | mistadman | Once it is read... |
| 07:28.46 | dcordes | yea got it |
| 07:29.26 | mistadman | Then some type of notification is done via: writel(1,MSM_A2M_INT(i)) on line 55 |
| 07:30.18 | dcordes | wtf is i? |
| 07:30.38 | dcordes | irq #? |
| 07:30.55 | mistadman | i is 7 - 15 |
| 07:31.50 | mistadman | can you grep for "MSM_A2M_INT" |
| 07:31.54 | dcordes | k |
| 07:32.09 | mistadman | find|xargs grep -iv "MSM_A2M_INT" |
| 07:32.57 | mistadman | I have a feeling it will correspond to IRQs. |
| 07:35.31 | dcordes | that xargs just prints everything it sees I'm using kfind for this |
| 07:36.47 | dcordes | the 4 *smd.c files so far |
| 07:38.24 | dcordes | only the smd files |
| 07:38.45 | mistadman | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/7x00-smd.c;h=8ea6e46a7f1df253d45ab4f99db008017cc1ab4c;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 07:38.49 | mistadman | Found it |
| 07:40.42 | dcordes | that's not built for kaiser |
| 07:41.01 | dcordes | only kaiser-smd.c |
| 07:42.40 | mistadman | Looks like your write |
| 07:42.44 | mistadman | right |
| 07:43.45 | *** join/#htc-linux alex[slx] (n=alex@CPE-58-169-209-120.sa.bigpond.net.au) |
| 07:43.48 | *** part/#htc-linux alex[slx] (n=alex@CPE-58-169-209-120.sa.bigpond.net.au) |
| 07:43.51 | *** join/#htc-linux alex[slx] (n=alex@CPE-58-169-209-120.sa.bigpond.net.au) |
| 07:44.36 | mistadman | MSM_A2M_INT |
| 07:44.41 | mistadman | Where is it? |
| 07:44.50 | dcordes | one minute |
| 07:45.07 | dcordes | that's what I just grpped for |
| 07:45.14 | dcordes | as I said the 4 smd.c |
| 07:45.25 | dcordes | which means it's only in kaiser-smd.c effectively |
| 07:45.43 | dcordes | I grepped the complete tree matching case |
| 07:45.59 | mistadman | Cant be |
| 07:46.20 | alex[slx] | Hi everyone. I'm having a little trouble with setting up OpenMoko on my HTC magician (O2 Xda II mini) using this guide: http://www.linuxtogo.org/~htcpxa/htcmagician/ and using image and bootloader from here: http://www.linuxtogo.org/~htcpxa/htcmagician/images/OpenMoko/. |
| 07:46.43 | mistadman | dcordes: I'm sorry... Getting tired |
| 07:46.54 | mistadman | Yes its in kaiser-smd.c |
| 07:47.01 | dcordes | me too |
| 07:47.02 | mistadman | Didnt see it |
| 07:47.31 | dcordes | but it's not elsewhere according to kfind |
| 07:47.49 | mistadman | MSM_CSR_BASE is the memory location that tells the kaiser or the arm9 we have read info |
| 07:48.03 | mistadman | MSM_CSR_BASE: What does it mean |
| 07:48.04 | mistadman | CSR |
| 07:48.09 | alex[slx] | I've set up my 2GB SD card with two partitions, vfat and ext3. I put the bootloader on the fat partition, and extracted the root filesystem into the root of the ext3 partition. Then when I run the bootloader, I get the linux boot messages and dropped to a prompt. |
| 07:48.40 | alex[slx] | It says something about can't find root tar. I'm going to try booting again, so I'll be able to get the exact message. |
| 07:49.13 | dcordes | mistadman: no clue. also came across the question before |
| 07:49.28 | dcordes | there are also other things in msm_iomap.h which I wonder |
| 07:49.28 | mistadman | Grep MSM_CSR_BASE |
| 07:49.33 | dcordes | ok |
| 07:50.09 | alex[slx] | Mounting SD card... No previous root filesystem found... FAIL FAIL FAIL FAIL... Root filesystem tar file not found. |
| 07:50.51 | mistadman | hey alex |
| 07:51.28 | alex[slx] | mistadman: Hey. |
| 07:51.30 | mistadman | alex[slx]: What is the name of the tar you extracted |
| 07:51.44 | alex[slx] | mistadman: openmoko.linux.rootfs.tar.bz2 |
| 07:52.08 | mistadman | alex[slx]: What is the name of the .exe |
| 07:52.19 | alex[slx] | Openmoko-Magician-Linux.exe |
| 07:53.08 | mistadman | alex[slx]: I think all you have to do is drop the exe and the tar (do not extract) on an sd card an run. |
| 07:53.19 | alex[slx] | mistadman: I've done that also. |
| 07:53.29 | mistadman | alex[slx]: What was the error message |
| 07:53.35 | mistadman | alex[slx]: ? |
| 07:53.44 | alex[slx] | The one I typed out before. |
| 07:53.52 | alex[slx] | Mounting SD card... No previous root filesystem found... FAIL FAIL FAIL FAIL... Root filesystem tar file not found. |
| 07:54.05 | alex[slx] | Replacing '...' with "\n" ;) |
| 07:55.18 | alex[slx] | mistadman: Oh... do I have to unbzip it and then put the resulting tar on the ext3 partition? |
| 07:55.53 | mistadman | alex[slx]: One sec |
| 07:56.57 | dcordes | mistadman: clock.h, kaiser-smd.c, pm.c, pm.h, /include/asm-arm/arch-msm/msm_iomap.h |
| 07:57.24 | mistadman | dcordes: ok |
| 07:58.39 | mistadman | alex[slx]: Alex just drop exe and bz2 on vfat formated sd card |
| 07:58.55 | mistadman | dont worry about ext2 partition |
| 07:58.56 | alex[slx] | mistadman: Ah ok. |
| 07:59.05 | alex[slx] | Ok, I'll give that a shot. |
| 07:59.48 | mistadman | 0xE0001000 |
| 08:00.07 | mistadman | dcordes: You know what |
| 08:00.14 | mistadman | dcordes: ? |
| 08:00.59 | dcordes | mistadman: nope |
| 08:01.21 | mistadman | dcordes: My theroy is that you have two virts. one for arm9 and the other for arm11 |
| 08:01.51 | dcordes | mistadman: KaiserMemoryMap distincts between them |
| 08:01.59 | mistadman | I am almost positive that 0xE0001000 is the memory location on qualcomm modem |
| 08:02.20 | alex[slx] | mistadman: FAT16/32 or doesn't matter? |
| 08:02.32 | mistadman | 0xE0001000 + offset is to tell arm9 your done reading an writing |
| 08:02.36 | mistadman | alex 32 |
| 08:02.52 | mistadman | but probably dosent matter |
| 08:03.11 | dcordes | nono can't be |
| 08:03.18 | dcordes | it would be shown in the memory map |
| 08:03.46 | dcordes | I think virt is the arm9 spaces |
| 08:03.49 | mistadman | Could be wrong. |
| 08:03.56 | mistadman | Just like on the Athena. |
| 08:04.05 | mistadman | All the ATI Regs or wrong |
| 08:04.11 | dcordes | somebody disassembled arm9 code |
| 08:04.33 | dcordes | I really think the 0xe is irrelevant |
| 08:04.54 | dcordes | no sorry I confused it |
| 08:05.00 | dcordes | 0xe is the arm11 virtual mapping right? |
| 08:05.02 | mistadman | I would argue against that and heres why |
| 08:05.08 | dcordes | *BASE in iomap.h |
| 08:05.25 | dcordes | in linux |
| 08:06.43 | mistadman | Does CSR == http://en.wikipedia.org/wiki/CSR_plc |
| 08:06.50 | alex[slx] | mistadman: Looks like it's working. Thank you :) |
| 08:07.01 | mistadman | You got it buddy! Have fun! |
| 08:07.09 | alex[slx] | mistadman: Oh I will. |
| 08:07.37 | dcordes | no man it is Corporate Social Responsibility |
| 08:07.38 | dcordes | lol |
| 08:07.47 | mistadman | Check this out |
| 08:07.48 | dcordes | http://www.mallenbaker.net/csr/CSRfiles/page.php?Story_ID=232 |
| 08:08.00 | mistadman | Do you know what smd means? |
| 08:08.04 | mistadman | SMD? |
| 08:08.21 | dcordes | shared memory dblabla |
| 08:08.26 | dcordes | device |
| 08:08.35 | mistadman | close "Shared Memory Device" |
| 08:09.24 | mistadman | It a way of communicating. Sorta like serial, but I hear its more efficient |
| 08:09.43 | dcordes | it emulates a serial interface |
| 08:09.47 | dcordes | well |
| 08:09.49 | mistadman | Sorta |
| 08:09.51 | dcordes | smd_tty.c does |
| 08:09.56 | mistadman | Now look at: http://64.233.169.104/search?q=cache:Q-l8zRNJWgAJ:baliniak.pl/android/kaiser-smd.c+MSM_A2M_INT&hl=en&ct=clnk&cd=1&gl=us |
| 08:10.20 | dcordes | marbalon's code? |
| 08:10.39 | dcordes | what's up with it? |
| 08:10.41 | mistadman | I am mixed up |
| 08:10.47 | mistadman | Too may windows open |
| 08:10.51 | mistadman | one sec |
| 08:11.06 | dcordes | you don't need to give the link each time |
| 08:11.12 | mistadman | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/7x00-smd.c;h=8ea6e46a7f1df253d45ab4f99db008017cc1ab4c;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 08:11.14 | mistadman | ok |
| 08:11.20 | dcordes | I know the repo well |
| 08:11.32 | mistadman | Ok here goes |
| 08:11.35 | dcordes | I know where's what but don't understand what it does in detail ;) |
| 08:11.39 | mistadman | notify_other_smd |
| 08:11.47 | mistadman | Got it |
| 08:11.51 | mistadman | notify_other_smd() |
| 08:11.59 | mistadman | Look at the function name |
| 08:12.13 | mistadman | key word: OTHER |
| 08:12.30 | dcordes | yea what's up with it? |
| 08:12.32 | mistadman | multiple shared mem devices |
| 08:12.39 | dcordes | I know |
| 08:13.02 | dcordes | we talked about that before: at, modem data (eth device in 7x00-smd.c), gps, camera |
| 08:13.41 | mistadman | Yeah but the arm9 mem space is 0xE0001000 |
| 08:14.04 | mistadman | and arm11 0xb5100000 |
| 08:14.47 | mistadman | Thats how they communicate and tell each other when they are rdy to send and rec data. |
| 08:14.53 | dcordes | I dout it. I think 0xe is the virtual mapping in the kernel |
| 08:14.53 | mistadman | What do you think? |
| 08:15.08 | mistadman | It is |
| 08:15.15 | dcordes | look at the other registers |
| 08:15.21 | mistadman | Which ones |
| 08:15.55 | dcordes | they all have 0xe. also things that don't flow through a2m (smd) like SD |
| 08:16.19 | mistadman | The all? |
| 08:16.27 | dcordes | iomap.h |
| 08:16.44 | dcordes | theres not just smd channels |
| 08:16.56 | dcordes | why would the non smd channels have arm9 registers assigned? |
| 08:16.58 | mistadman | Ahh... I see your point |
| 08:18.04 | mistadman | Ok then, why doesnt the wiki reflect this info? |
| 08:18.31 | dcordes | which info do you mean? |
| 08:18.56 | dcordes | my neurons are exhausted |
| 08:18.58 | mistadman | 0xE0**** Addresses |
| 08:19.11 | dcordes | good question |
| 08:19.31 | mistadman | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/io.c;h=3bb06bf26fc483ec5ba4c9f7eeee3ae81ffbb03c;hb=4134160a774aad737ac3efadd81366e3c9f27c08 |
| 08:19.33 | dcordes | maybe it doesn't require documentation because it is freely defined in the kernel |
| 08:19.38 | mistadman | I found our devices |
| 08:19.52 | *** part/#htc-linux alex[slx] (n=alex@CPE-58-169-209-120.sa.bigpond.net.au) |
| 08:19.58 | dcordes | where? |
| 08:20.12 | dcordes | I only see the complete IO listing, not the SMD channels |
| 08:20.14 | dcordes | smd ids |
| 08:20.30 | mistadman | Yes smd ids |
| 08:20.42 | mistadman | VIC |
| 08:20.43 | dcordes | you mean structure map_desc msm_io_desc |
| 08:20.45 | mistadman | CSR |
| 08:20.49 | mistadman | GPT |
| 08:20.53 | mistadman | DMOV |
| 08:20.55 | mistadman | UART1 |
| 08:20.58 | mistadman | etc... |
| 08:21.16 | mistadman | io.c |
| 08:21.28 | dcordes | uart!=smd |
| 08:21.45 | mistadman | CRS == smd |
| 08:21.51 | mistadman | CSR == smd |
| 08:22.49 | dcordes | I'm not sure what csr is |
| 08:22.50 | dcordes | and vic |
| 08:22.56 | dcordes | dmov is datamover |
| 08:23.19 | mistadman | CSR == MSM_CSR_BASE? |
| 08:23.27 | dcordes | yea |
| 08:23.36 | dcordes | I think they belong together |
| 08:26.46 | dcordes | people who could tell us what all they are, are for example dzo and cr2 |
| 08:28.03 | dcordes | I can tell that's not the list we look for |
| 08:28.11 | dcordes | the smd channels should be about 7 |
| 08:28.21 | dcordes | matches the number of irqs |
| 08:28.25 | mistadman | I think i solved the mystery: http://64.233.169.104/search?q=cache:8qMLbPUJ8hIJ:boards.fool.co.uk/Message.asp%3Fmid%3D10301840%26sort%3Dpostdate+qualcomm+CSR&hl=en&ct=clnk&cd=27&gl=us |
| 08:29.08 | dcordes | ah right now I have an association with bluetooth/csr |
| 08:29.13 | dcordes | wait |
| 08:30.08 | dcordes | the bluetooth device is TI BRF6300 |
| 08:30.19 | dcordes | it's not in smd, it's on uart |
| 08:30.29 | dcordes | smd only has modem, gps, camera |
| 08:30.39 | dcordes | s/smd/arm9/ |
| 08:30.42 | mistadman | Ok, lets look at this logically |
| 08:31.06 | dcordes | we want to know what data goes through what smd channel id right? |
| 08:31.06 | mistadman | Wiki says: SHARED_MEM A9/A11 |
| 08:31.14 | dcordes | yes |
| 08:31.19 | dcordes | a9/a11=a2m |
| 08:31.22 | mistadman | Always memory |
| 08:31.28 | dcordes | =smem=sharedmem |
| 08:31.29 | mistadman | not channel |
| 08:31.35 | mistadman | yes |
| 08:31.57 | mistadman | Channel is a way to group device with mem locations |
| 08:32.04 | dcordes | why not channel? the smem is nothing but a row of those data channels |
| 08:32.10 | dcordes | consisting of the circular buffers |
| 08:32.14 | dcordes | yea |
| 08:32.22 | mistadman | Right |
| 08:32.22 | dcordes | that's also my understanding |
| 08:32.28 | mistadman | Yes |
| 08:32.41 | mistadman | But it all comes down to address |
| 08:32.45 | dcordes | so we are stuck with the irq issue and identifying those different data channels. |
| 08:32.49 | dcordes | am I right? |
| 08:32.58 | mistadman | No |
| 08:33.01 | dcordes | what else? |
| 08:33.18 | mistadman | We first need to make sure we clearly define memory addresses |
| 08:33.38 | dcordes | ok so let's go a step back to the roots, look if the addresses are correctly with haret |
| 08:33.53 | mistadman | When i comes down to it all a computer cares about is i/o addresses not channels |
| 08:34.09 | dcordes | by the way: thank you for all the help. I won't be able to help you like this with my C skills :( |
| 08:34.26 | mistadman | Channels are what the programmer used to logically group devices and i/o and Rx / TX |
| 08:34.40 | mistadman | Thats ok. |
| 08:34.53 | mistadman | This is what open souce is all about |
| 08:35.02 | mistadman | We are all learing... |
| 08:35.08 | mistadman | We are all learning |
| 08:35.14 | mistadman | SHARED_MEM A9/A11 |
| 08:35.15 | dcordes | but always let me know if I can return the favor differently |
| 08:35.20 | mistadman | Cool |
| 08:35.23 | mistadman | Thanks |
| 08:35.33 | mistadman | SHARED_MEM A9/A11 = 0xb5100000 |
| 08:35.38 | mistadman | right? |
| 08:35.40 | dcordes | Channels are what the programmer used to logically group devices and i/o and Rx / TX => yea that's clear |
| 08:35.57 | mistadman | SHARED_MEM A9/A11 = 0xb5100000 |
| 08:36.04 | dcordes | 0xb5100000 is the wince virtual base address of the smem yes |
| 08:36.15 | mistadman | ok |
| 08:36.26 | dcordes | physical is 0x01f* |
| 08:36.36 | mistadman | So whats: 0xE0001000 |
| 08:36.38 | mistadman | ? |
| 08:36.59 | mistadman | Remember that from msm_iomap.h |
| 08:37.06 | dcordes | we know it is in iomap.h |
| 08:37.15 | dcordes | wait I think it'S even commented.. |
| 08:37.28 | mistadman | Check this out: |
| 08:37.31 | mistadman | YEs |
| 08:37.38 | mistadman | I was just looking at that |
| 08:37.47 | mistadman | <PROTECTED> |
| 08:37.47 | mistadman | <PROTECTED> |
| 08:37.47 | mistadman | <PROTECTED> |
| 08:37.47 | mistadman | <PROTECTED> |
| 08:37.57 | mistadman | ^ this? |
| 08:38.09 | dcordes | yea right see that's what I mean by kernel internal mapping |
| 08:38.21 | dcordes | it's like linux virt |
| 08:38.23 | dcordes | not wince virt |
| 08:40.20 | mistadman | I think you are going to have to first straighten this file and mem i/o out |
| 08:40.39 | mistadman | I am looking a the wiki: 0xac000000 |
| 08:40.59 | mistadman | What at that address according to the wiki? |
| 08:41.57 | *** part/#htc-linux CVirus (n=GoD@62.135.96.108) |
| 08:41.57 | mistadman | s/What/Whats |
| 08:42.45 | mistadman | Have you tried poking around with vdump |
| 08:43.05 | dcordes | yes of course. |
| 08:43.22 | dcordes | when you dump the complete 1M of smem, you can see where the fifos are |
| 08:43.31 | dcordes | ok a new term we didn't use yet in our conversation |
| 08:43.42 | dcordes | fifos=channels |
| 08:44.18 | mistadman | I can live with that |
| 08:45.38 | mistadman | Ok... Back to kaiser-smd.c |
| 08:45.39 | mistadman | smd_write() |
| 08:45.48 | mistadman | Let start there |
| 08:46.01 | mistadman | This is the main write function |
| 08:46.10 | mistadman | Maybe its just brokent |
| 08:46.18 | mistadman | s/brokent/broken |
| 08:46.50 | mistadman | There is a printk in the function you might want to play with. |
| 08:47.01 | dcordes | ok this is a very good plan |
| 08:47.08 | dcordes | I will fetch the tree so it's not broken anymore |
| 08:47.47 | mistadman | do you know how to reset branch |
| 08:48.10 | mistadman | to go to an earlier revision? |
| 08:48.15 | dcordes | it's ok |
| 08:48.18 | dcordes | hold on a minute |
| 08:54.07 | *** join/#htc-linux kiozen (n=kiozen@rgnb-4db1dae8.pool.einsundeins.de) |
| 08:59.16 | martin__ | dcordes: hey! |
| 08:59.19 | martin__ | mistadman: hey! |
| 08:59.45 | martin__ | I have just woken up and spent about half an hour catching up with the last few hours of conversation... |
| 08:59.47 | dcordes | martin__: aye joining in the fun? |
| 08:59.53 | martin__ | yup |
| 09:00.21 | dcordes | I will make use of the smd write printk |
| 09:00.32 | martin__ | so, i was really interested in the traces you guys were getting out of haret earlier |
| 09:00.34 | dcordes | mmutrace works just fine martin__ |
| 09:00.51 | dcordes | Kevin2: even improved it, removed some bugs |
| 09:00.54 | martin__ | yeah, with that we should be able to sort this |
| 09:00.59 | martin__ | i've downloaded the new haret |
| 09:01.04 | dcordes | grab the latest build he made. |
| 09:01.07 | dcordes | good |
| 09:01.17 | martin__ | might need some help figuring out the commands |
| 09:01.22 | dcordes | addlist mmutrace 0xb5100000 1024*1024 |
| 09:01.23 | dcordes | addlist mmutrace 0x95100000 1024*1024 |
| 09:01.23 | dcordes | addlist mmutrace 0x4fc0c000 4*1024 |
| 09:01.23 | dcordes | addlist mmutrace 0x4fc00000 4*1024 |
| 09:01.23 | dcordes | addlist mmutrace 0x4a20a000 (0x4a30c000 - 0x4a20a000) |
| 09:01.30 | dcordes | here you go |
| 09:01.44 | martin__ | which addresses are those? |
| 09:01.44 | dcordes | after that wirq n will show you all the reads and writes to the smem |
| 09:01.56 | martin__ | do i need the permissive mmutrace thing? |
| 09:02.12 | dcordes | martin__: look into the mmu dump. those are all virtual pages that map to the 0x01f* (smem) area |
| 09:02.19 | martin__ | if you guys can help me with the wince/haret stuff, i can deal with the C. |
| 09:02.20 | dcordes | yes it will ask you just do it |
| 09:02.37 | dcordes | sounds like a good team |
| 09:02.54 | dcordes | we have to help mistadman in exchange. he's not a kaiser but athena owner |
| 09:03.01 | dcordes | plus 50 other htcs lol |
| 09:03.05 | martin__ | heh |
| 09:03.22 | dcordes | note that the last 0x4a20a000 (0x4a30c000 - 0x4a20a000) will break everything |
| 09:03.35 | dcordes | at least if you do it that way |
| 09:03.46 | dcordes | Kevin2: detailed on why it does that. |
| 09:03.54 | martin__ | what i want to do is just look at the at write channel |
| 09:04.21 | dcordes | martin__: add the first four lines |
| 09:04.33 | dcordes | then wirq 100 |
| 09:04.37 | dcordes | make a call |
| 09:04.57 | martin__ | ok |
| 09:05.01 | dcordes | poke around. also bluetooth shows activity |
| 09:05.39 | martin__ | is this your trace of the same addresses? http://rafb.net/p/b85rEk31.html |
| 09:05.41 | dcordes | to only trace the write, maybe look at the mmu dump and only specify the virts that map to the write area |
| 09:05.51 | dcordes | yea |
| 09:05.53 | dcordes | the first 4 |
| 09:06.39 | dcordes | regarding the C everything goes down in kaiser-smd.c |
| 09:08.48 | martin__ | okay, trying to decode your trace first |
| 09:09.48 | dcordes | maybe you can try and figure out how exactly the irq notification process works |
| 09:10.15 | martin__ | i suspect it involves writing some of those bits we saw next to the head/tail. |
| 09:10.47 | martin__ | also do you want gps read working? |
| 09:10.55 | martin__ | cos that's like a 2 line fix i think. |
| 09:11.14 | dcordes | martin__: yea look at my comment |
| 09:11.37 | dcordes | also check with msm_tty if you can get the device node setup correctly |
| 09:11.44 | martin__ | you'll never get to your code there |
| 09:12.01 | dcordes | with the comment thing? |
| 09:12.25 | martin__ | if (n = 0) { AT } else { data } |
| 09:12.43 | martin__ | it assumes only two channels are being used |
| 09:13.00 | dcordes | ok let's not get confused again |
| 09:13.09 | dcordes | I'ma put the printk now |
| 09:13.10 | martin__ | if you stick "else { GPS }" on the end there without changing the previous else |
| 09:13.22 | martin__ | you'll never get to the GPS block |
| 09:13.36 | dcordes | I was 100% sure that was dumb. but it shows my intention quite well I think |
| 09:15.33 | martin__ | so channel number 0 is AT |
| 09:15.43 | martin__ | channel 2 is rpcrouter |
| 09:15.55 | martin__ | channel 5 is qmi |
| 09:15.58 | martin__ | whatever that is |
| 09:16.00 | dcordes | how'd ya figure? |
| 09:16.10 | martin__ | grep for smd_open and see where it's called |
| 09:16.15 | martin__ | the first argument is the channel number |
| 09:17.07 | dcordes | in which file? |
| 09:17.34 | martin__ | grep the whole of arch/arm/mach-msm |
| 09:17.45 | martin__ | it's called in three places |
| 09:18.03 | martin__ | smd_rpcrouter.c, smd_qmi.c, and smd_tty.c. |
| 09:18.13 | martin__ | the first two use channels 5 and 2 |
| 09:19.01 | martin__ | smd_tty.c will use the minor number of the device node you create |
| 09:19.10 | dcordes | I think the rpc is quite useless to us |
| 09:19.39 | dcordes | because it depends on the halibut version of amss |
| 09:19.48 | dcordes | the arm9 software that google use |
| 09:19.59 | martin__ | yeah, i'm just explaining how the channel nos work |
| 09:20.22 | martin__ | hang on, i'll write a quick patch to kaiser-smd.c that cleans things up. |
| 09:20.23 | dcordes | k |
| 09:22.34 | martin__ | oh! |
| 09:22.36 | martin__ | hang on |
| 09:22.43 | dcordes | sup? |
| 09:23.07 | martin__ | why don't the send.size and recv.size match the comments in smd_open()? |
| 09:23.34 | dcordes | because both come from different persons |
| 09:23.57 | dcordes | I think the comment is from a dump dzo had |
| 09:24.02 | *** join/#htc-linux pH5 (n=ph5@e178198238.adsl.alicedsl.de) |
| 09:24.08 | martin__ | hmm |
| 09:24.18 | dcordes | and the actual sizes are either from cr2 or marbalon |
| 09:24.40 | martin__ | does at receive work indefinitely? |
| 09:24.50 | martin__ | if so the 0x2000 size is probably okay |
| 09:24.53 | dcordes | wot you didn't try yet? |
| 09:25.04 | dcordes | it does. definetly in the current git head |
| 09:28.29 | dcordes | what is striking aret he two 4K pages that map to 0x01f* in the mmu dump |
| 09:28.40 | dcordes | they are so lost in there. looks like something is special about em |
| 09:29.48 | martin__ | i tried it but not for very long |
| 09:30.06 | martin__ | nearly done with this... |
| 09:36.20 | martin__ | ok, compiling |
| 09:43.09 | martin__ | dcordes: http://void.printf.net/~martin/smd-open-cleanup.diff |
| 09:43.27 | martin__ | tidies things up and adds a gps channel |
| 09:43.44 | dcordes | can you read gps? |
| 09:44.12 | martin__ | haven't tested it yet |
| 09:44.58 | martin__ | give it a try |
| 09:45.02 | martin__ | i'm working on something else... |
| 09:45.57 | dcordes | send? |
| 09:47.18 | martin__ | maybe... |
| 09:51.04 | martin__ | dcordes: okay, i know what's wrong |
| 09:51.24 | martin__ | not 100% sure how to fix it, but i know where to start. |
| 09:52.53 | martin__ | dcordes: the smd_buffer_t definition is definitely wrong |
| 09:53.02 | martin__ | the head and tail are shorts, not ints. |
| 09:54.08 | martin__ | for the at receive we're getting away with that |
| 09:54.55 | martin__ | and i suspect the gps will work the same way |
| 09:55.13 | martin__ | unless there's a problem with defining a one-way channel |
| 09:57.19 | martin__ | but for write it'll fuck things since we'll be writing where we shouldn't |
| 10:01.14 | martin__ | dcordes: ping? |
| 10:01.17 | dcordes | yes? |
| 10:04.07 | martin__ | i'm rewriting kaiser-smd.c to better fit what we actually know. |
| 10:04.28 | martin__ | it'll take me a little while |
| 10:04.49 | martin__ | could you test that patch i posted? |
| 10:05.29 | dcordes | building |
| 10:05.33 | martin__ | cool |
| 10:05.37 | dcordes | also added all printks which were commented |
| 10:13.01 | dcordes | martin__: do you know a simple free application to activate gps? |
| 10:13.14 | martin__ | google maps? |
| 10:13.18 | dcordes | don't like to grab google maps only for purpose of having a fix booting |
| 10:13.27 | martin__ | i dunno |
| 10:13.36 | martin__ | keep meaning to look for one though |
| 10:13.45 | dcordes | nvm |
| 10:13.49 | martin__ | since google maps often doesn't give the gps enough time to start |
| 10:14.17 | martin__ | so sometimes i wind up starting an even bigger mapping program |
| 10:14.23 | martin__ | just to get the gps going |
| 10:14.28 | martin__ | so i can use google maps :) |
| 10:14.44 | martin__ | think maybe that's fixed in recent google maps though |
| 10:14.56 | martin__ | lemme know what you find though |
| 10:15.12 | martin__ | a nice little gps app would be cool to have |
| 10:15.17 | dcordes | let's see if it boots at all first |
| 10:15.23 | martin__ | always a good plan |
| 10:15.29 | dcordes | positive |
| 10:15.41 | martin__ | check at receive first |
| 10:15.46 | martin__ | that shouldn't have changed |
| 10:15.51 | martin__ | all i did was reformat the code |
| 10:16.15 | martin__ | if that works, do mknod /dev/smd7 c 254 7 |
| 10:16.33 | martin__ | and try reading it for gps |
| 10:16.45 | martin__ | don't write to it though |
| 10:16.50 | martin__ | might crash the kernel |
| 10:17.03 | dcordes | oops it did change |
| 10:17.19 | martin__ | ? |
| 10:17.25 | dcordes | mknod /dev/smd0 c 254 2 && cat /dev/smd0 |
| 10:17.26 | dcordes | no such node |
| 10:17.30 | dcordes | no such device |
| 10:17.34 | martin__ | good |
| 10:17.37 | martin__ | that's what it should do |
| 10:17.40 | dcordes | ah 2 |
| 10:17.43 | dcordes | that should be 0 |
| 10:17.46 | martin__ | yup :) |
| 10:18.06 | martin__ | 2 worked before because it was just if (n = 0) { ... } else { ... } |
| 10:18.08 | dcordes | good worx |
| 10:18.29 | dcordes | it's just fine |
| 10:18.31 | dcordes | going for gps now |
| 10:18.37 | dcordes | 254 7? |
| 10:18.39 | martin__ | y |
| 10:19.57 | martin__ | oh, the suspense... |
| 10:21.46 | martin__ | what's happening? |
| 10:23.13 | dcordes | kiozen: what's a good program to get a gps fix? |
| 10:23.44 | kiozen | on mobile devices? try gpsd |
| 10:23.58 | dcordes | yes for wince |
| 10:26.40 | martin__ | dcordes: http://www.freewarepocketpc.net/ppc-tag-gps.html |
| 10:27.36 | martin__ | http://handheld.softpedia.com/catList/190,1,1,1.html |
| 10:27.54 | dcordes | are you sure minor should be 7? |
| 10:28.04 | martin__ | yes |
| 10:28.05 | martin__ | why? |
| 10:28.59 | dcordes | cause the system replis no such device when I try to cat it |
| 10:29.18 | kiozen | dcordes: you need it for wince? Isn't there an app on the device if it has gps? |
| 10:29.29 | martin__ | hmm. |
| 10:29.44 | dcordes | kiozen: no only the spyware agps updater |
| 10:30.00 | martin__ | dcordes: quickgps is spyware? |
| 10:30.33 | dcordes | martin__: yes |
| 10:30.36 | martin__ | lol |
| 10:30.44 | dcordes | a wise guy told me at least |
| 10:30.47 | martin__ | who found that out? |
| 10:30.48 | dcordes | I did |
| 10:30.58 | kiozen | dcordes: ok, never really tried with wince |
| 10:30.58 | dcordes | mknod /dev/smd0 c 254 7 |
| 10:31.00 | dcordes | and |
| 10:31.04 | dcordes | mknod /dev/smd7 c 254 7 |
| 10:31.13 | martin__ | the node name doesn't matter |
| 10:31.14 | dcordes | but I guess I could also call it /dev/fubar10 |
| 10:31.17 | martin__ | yeah |
| 10:31.27 | martin__ | but 0 and 1 work? |
| 10:31.33 | dcordes | everything replies no such file |
| 10:31.39 | dcordes | 0 works |
| 10:32.15 | martin__ | oh, fuck |
| 10:32.17 | martin__ | sorry |
| 10:32.24 | martin__ | i missed something further up in smd_open |
| 10:32.28 | kiozen | with agps the provider cantrck you very precisely if wanted. So don't be surprised if you get a commercial sms from a brand when passing their store :) |
| 10:32.32 | martin__ | <PROTECTED> |
| 10:32.32 | martin__ | <PROTECTED> |
| 10:32.51 | dcordes | cat /dev/smd1 replies the printk I added which is "[n:1] |
| 10:32.52 | dcordes | " |
| 10:33.48 | martin__ | dcordes: just delete those two lines from smd_open. |
| 10:33.58 | dcordes | ok |
| 10:35.13 | dcordes | 246,247? |
| 10:35.28 | martin__ | something like that |
| 10:35.33 | martin__ | i'm editing atm |
| 10:35.46 | martin__ | should be the only place that appears |
| 10:37.06 | martin__ | re: quickgps, by spyware i was thinking it was sending some extra stuff when it requested the new agps data |
| 10:37.31 | martin__ | agps location itself i'm not bothered about |
| 10:37.38 | martin__ | cell location is accurate enough already |
| 10:37.42 | dcordes | I think it sends extra stuff |
| 10:37.48 | martin__ | if i didn't want to be tracked, i wouldn't carry my phone... |
| 10:37.58 | dcordes | true! |
| 10:38.44 | martin__ | i'll update it over my wifi sometime and sniff it |
| 10:39.47 | martin__ | ooh, hang on |
| 10:39.53 | martin__ | are you building a new kernel yet? |
| 10:39.56 | martin__ | something else to change |
| 10:40.22 | dcordes | no I already booted it with the two lines removed. |
| 10:40.29 | martin__ | ah, okay |
| 10:40.33 | martin__ | well, should be fine |
| 10:40.37 | dcordes | what is it? |
| 10:40.51 | martin__ | so long as you don't try to create anything other than 0, 1 or 7 |
| 10:41.14 | martin__ | i forgot to release the smd creation lock before returning -ENODEV. |
| 10:41.50 | martin__ | to fix that, replace: |
| 10:41.51 | martin__ | default: |
| 10:41.58 | martin__ | <PROTECTED> |
| 10:42.02 | martin__ | with |
| 10:42.05 | martin__ | default: |
| 10:42.10 | martin__ | <PROTECTED> |
| 10:42.15 | martin__ | <PROTECTED> |
| 10:42.23 | dcordes | woooha |
| 10:42.24 | dcordes | gps works |
| 10:42.28 | dcordes | I see the nmea data flowing |
| 10:42.34 | martin__ | woo! |
| 10:42.37 | martin__ | *bows* |
| 10:42.43 | dcordes | applaudes |
| 10:42.45 | dcordes | nice work |
| 10:43.39 | martin__ | okay, that's helpful |
| 10:43.56 | martin__ | it confirms the working read isn't just a fluke specific to the at channel |
| 10:44.14 | dcordes | good |
| 10:44.50 | dcordes | now get the send working and we have gps working perfectly on the kaiser plus are in command of the modem. |
| 10:45.49 | martin__ | working on it! |
| 10:47.37 | martin__ | out of interest, what happens if you write to smd 7? |
| 10:49.01 | dcordes | are you familiar with cu? |
| 10:49.20 | dcordes | I already used it to try communicate with the smd but can't recall correct usage |
| 10:50.12 | dcordes | echo lol > /dev/smd7 |
| 10:50.24 | dcordes | spams a polite printk |
| 10:50.43 | martin__ | cu? no. |
| 10:50.48 | dcordes | release_dev: smd7: read/write wait queue active! |
| 10:50.58 | martin__ | hmm. |
| 10:51.02 | dcordes | that message appears about 50 times per second |
| 10:51.07 | dcordes | and doesn't stop |
| 10:51.15 | martin__ | better than i expected |
| 10:51.38 | martin__ | at some point i'll tidy that up so it just returns permission denied. |
| 10:51.39 | dcordes | I would like to see the head/tail printk so I can check if tail changes |
| 10:52.16 | martin__ | in the meantime, don't write to smd 7 :-) |
| 10:56.47 | *** join/#htc-linux BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 10:57.22 | dcordes | martin__: I need a nap |
| 10:57.25 | dcordes | cya |
| 10:57.29 | kiozen | hi BabelO, back from the 100 bugs? |
| 10:57.30 | martin__ | you've been up a while :) |
| 10:57.44 | BabelO | hi |
| 10:57.45 | dcordes | yep |
| 10:57.46 | martin__ | dcordes: will post something new for you to test in a bit |
| 10:57.48 | BabelO | kiozen: yes :) |
| 10:57.52 | martin__ | then i'm off out |
| 10:57.58 | martin__ | back at some point... |
| 10:57.59 | *** join/#htc-linux pikapika (n=pikapika@mar75-8-88-164-227-147.fbx.proxad.net) |
| 10:58.03 | dcordes | cool cya |
| 10:58.10 | pikapika | hi |
| 11:24.21 | *** join/#htc-linux ellisway (n=ellis@80-46-67-47.static.dsl.as9105.com) |
| 11:39.08 | *** join/#htc-linux regurgitate (n=x1@233.85.220.87.dynamic.jazztel.es) |
| 11:39.11 | regurgitate | hi |
| 11:39.23 | regurgitate | need help to detect a model of htc running |
| 11:39.32 | regurgitate | for select an apropiate lcd driver |
| 11:40.55 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 12:00.45 | *** join/#htc-linux rmoravci1 (n=rmoravci@adsl-dyn73.78-98-166.t-com.sk) |
| 12:01.23 | *** join/#htc-linux goxboxlive (n=goxboxli@208.84-48-176.nextgentel.com) |
| 12:02.48 | martin__ | dcordes: http://void.printf.net/~martin/kaiser-smd.c |
| 12:03.01 | martin__ | totally untested |
| 12:03.04 | martin__ | try if you dare. |
| 12:04.28 | martin__ | I need to go out for a bit but may carry on later |
| 12:06.54 | *** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 12:08.27 | Tonny | lol |
| 12:11.01 | regurgitate | hi guys |
| 12:11.04 | regurgitate | i have an elf |
| 12:11.21 | regurgitate | what i need to do for catch keys ? |
| 12:11.26 | regurgitate | do you have some link to read ? |
| 12:14.42 | *** join/#htc-linux LordMero (n=Gra@80-218-11-139.dclient.hispeed.ch) |
| 12:21.50 | LordMero | Hi |
| 12:22.10 | LordMero | i need to talk abut linux on artemis |
| 12:22.24 | LordMero | smn can help me? |
| 12:29.34 | BabelO | hi LordMero |
| 12:29.41 | BabelO | what happen ? |
| 12:30.28 | regurgitate | i need help top |
| 12:30.30 | regurgitate | too |
| 12:53.00 | *** join/#htc-linux regurgitate (n=x1@233.85.220.87.dynamic.jazztel.es) |
| 12:54.46 | *** part/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 13:15.10 | skodde | haret is always the only way to boot a linux kernel on Universal or there are some other options now? |
| 13:17.37 | regurgitate | is there anyway to check what hardware i have using omap registers ? |
| 13:18.13 | regurgitate | skodde, check http://handhelds.org/moin/moin.cgi/Universal |
| 13:20.00 | skodde | regurgitate: that doesn't answer my question, i already know haret and that page |
| 13:21.23 | regurgitate | <PROTECTED> |
| 13:26.43 | LordMero | hi Babel0 |
| 13:26.57 | *** join/#htc-linux regurgitate (n=x1@233.85.220.87.dynamic.jazztel.es) |
| 13:27.24 | LordMero | i would like to replace win with linux on my p3300 |
| 13:27.44 | LordMero | i was wondering if there are any instructions to follow |
| 13:29.50 | LordMero | since as i've understood it runs separatelz |
| 13:29.51 | LordMero | y |
| 13:29.55 | LordMero | right_ |
| 13:30.10 | LordMero | ? |
| 13:31.16 | *** join/#htc-linux andy_js (n=andy_js@AAmiens-152-1-38-8.w83-198.abo.wanadoo.fr) |
| 13:51.08 | mistadman | dcordes: What did i miss? |
| 13:51.23 | mistadman | dcordes: I dozed off waiting for you. Sorry! |
| 13:51.50 | mistadman | dcordes: Looks like martin fixed gps? |
| 13:53.09 | martin__ | heh, you two had a pretty late night |
| 13:53.24 | mistadman | Yeah |
| 13:53.31 | mistadman | But we had a blast |
| 13:53.45 | mistadman | martin__: I see you made some progress |
| 13:53.52 | martin__ | yeah |
| 13:53.58 | mistadman | martin__: Gps works now? |
| 13:54.02 | martin__ | since then i have largely rewritten kaiser-smd.c |
| 13:54.14 | martin__ | it was quite a mess |
| 13:54.29 | mistadman | martin__: What about phone. He couldnt send mesg to arm9 |
| 13:54.38 | mistadman | martin__: Fixed? |
| 13:54.47 | martin__ | haven't tested the rewrite yet |
| 13:54.57 | mistadman | Can I look a the patch |
| 13:55.17 | martin__ | http://void.printf.net/~martin/kaiser-smd.c |
| 13:55.42 | mistadman | I wish I could have been more help to dcordes, but I don't have a kaiser! |
| 13:55.45 | martin__ | mistadman: which phone are you working on, and what chipset is it? |
| 13:56.05 | mistadman | Athena and pxa270 |
| 13:56.31 | martin__ | ah |
| 13:56.45 | martin__ | dunno how much help you'll find in my code then |
| 13:57.04 | martin__ | but as a generic implementation of shared memory channels it's a bit of a cleaner example now |
| 13:57.21 | mistadman | Here is the status of my work: http://forum.xda-developers.com/showthread.php?t=393389 |
| 13:57.52 | mistadman | How did you find what was on what channels? |
| 13:58.15 | martin__ | mistadman: looking at dumps of the shared memory after using stuff from wince |
| 13:58.33 | mistadman | Unfortunately, I cannot grep thru source code. |
| 13:58.46 | mistadman | I have to brows git online. Very slow... |
| 13:58.56 | martin__ | ? |
| 13:59.07 | mistadman | s/brows/browse |
| 14:00.48 | mistadman | What calls: int smd_open(int n, smd_channel_t **_ch, void *priv, void (*notify)(void *, unsigned))? |
| 14:00.57 | martin__ | smd_tty_open |
| 14:01.22 | martin__ | also smd_rpcrouter.c and smd_qmi.c |
| 14:15.54 | *** join/#htc-linux kiozen_ (n=oeichler@p5492B4CD.dip0.t-ipconnect.de) |
| 14:29.54 | mistadman | <PROTECTED> |
| 14:30.09 | mistadman | So the wiki had it wrong? |
| 14:44.36 | BabelO | LordMero: you cannot at the moment |
| 15:32.04 | *** join/#htc-linux Playdeep (n=Playdeep@65.90.54.218) |
| 15:32.18 | *** part/#htc-linux Playdeep (n=Playdeep@65.90.54.218) |
| 15:56.42 | *** join/#htc-linux SmallR2002 (n=SmallR20@c-67-162-60-33.hsd1.il.comcast.net) |
| 16:23.35 | dcordes | mistadman: did you do a complete dump of your athena smem yet? |
| 16:23.56 | mistadman | dcordes: I am going thru it now |
| 16:24.13 | mistadman | Looks like martin__ hooked you up! |
| 16:24.19 | mistadman | Looking good |
| 16:25.46 | dcordes | yea it's great we can access the gps now |
| 16:25.53 | dcordes | Qlandkarte GT on kaiser |
| 16:26.08 | mistadman | Whats qlandkarte? |
| 16:26.19 | dcordes | kiozen: I need a qvga armv6 build of qtopia :) |
| 16:26.19 | mistadman | And what about the phone? |
| 16:26.36 | dcordes | it's a nice gps program made by kiozen |
| 16:26.36 | mistadman | Can you write yet? |
| 16:26.41 | dcordes | no writes |
| 16:47.35 | dcordes | got your smem dump? |
| 16:48.17 | mistadman | http://rafb.net/p/IOXGCI51.html |
| 16:48.25 | dcordes | martin__: did you polish the diff so I can commit it? |
| 16:48.40 | mistadman | Going thru it now. |
| 16:49.14 | dcordes | no I mean the vdump kind of stuff, not the mmutrace |
| 16:49.39 | kiozen | dcordes: ok, tell me if you need support to compile QLandkarte M |
| 16:50.10 | dcordes | kiozen: one openmoko guy suggested to me anyway to try and start into qtopia if X does not work |
| 16:50.17 | dcordes | I wanna show people linux!=android |
| 16:50.26 | dcordes | in the xda forum |
| 16:50.49 | AstainHellbring | lots of dumbasses posting in there about android |
| 16:51.04 | dcordes | AstainHellbring: why dumbasses? |
| 16:51.32 | lama | googledroid |
| 16:52.18 | dcordes | likely many of them don't know there is something else |
| 16:52.46 | martin__ | dcordes: no, i want to get the bigger cleanup i did working okay |
| 16:52.51 | dcordes | I need to get a connection working to kaiser in order to debug the edje based interfaces |
| 16:52.58 | dcordes | martin__: k |
| 16:53.05 | martin__ | did you have a look? |
| 16:53.21 | dcordes | you updated the diff? |
| 16:53.35 | martin__ | no, i uploaded a complete file |
| 16:53.52 | martin__ | http://void.printf.net/~martin/kaiser-smd.c |
| 16:54.20 | martin__ | the code was a hell of a mess so i've cleaned it up |
| 16:54.24 | martin__ | added some commentary |
| 16:54.42 | dcordes | where did channel 1 go? |
| 16:54.45 | AstainHellbring | just like to post dumb things that they don't know about |
| 16:54.48 | martin__ | might have broken it in the process |
| 16:55.04 | martin__ | i didn't have a dump that showed the head and tail of it |
| 16:55.18 | martin__ | so i wasn't sure about the addresses |
| 16:55.31 | AstainHellbring | curious how close you guys to writes on radio? if any idea on that of course |
| 16:55.37 | martin__ | has anyone confirmed they can read from it? |
| 16:55.52 | dcordes | martin__: hmm not in both dumps? I could swear I went online with the umts before I dumped |
| 16:56.11 | dcordes | martin__: not that I know of |
| 16:56.23 | dcordes | but it should be the same as AT and GPS |
| 16:56.38 | martin__ | it'll be the same structure |
| 16:56.44 | martin__ | but i dunno where in meme it is |
| 16:57.02 | dcordes | we need to make a new dump, making sure umts data is in |
| 16:57.15 | dcordes | now how in hell did I make those |
| 16:57.20 | martin__ | and the dumps i've got don't show anything at the addresses that were there |
| 16:57.35 | martin__ | anyway, that channel is useless untill we have at writes |
| 16:57.50 | dcordes | well the addresses that were there are irrelevant vogue stuff |
| 16:57.54 | martin__ | so i'd rather just keep to what we know works |
| 16:58.55 | dcordes | by the way. if we modify smd.c too much, it could probably be hard to stay synced with the others. Dzo integrated msm_proc_comm |
| 16:58.56 | dcordes | martin__: ok good |
| 16:58.56 | martin__ | dcordes: yeah, i realise that |
| 16:59.18 | martin__ | it's easy enough for me to shuffle things around once they're working though |
| 16:59.35 | dcordes | ok cool just try and not remove the proc comm things |
| 16:59.45 | dcordes | proc comm is mostly updates to clock.c anyway |
| 17:00.02 | martin__ | i've shunted that to the end of the file |
| 17:00.12 | martin__ | along with smem_alloc which is also just a stub |
| 17:01.02 | dcordes | martin__: http://rafb.net/p/CNv5Qr91.html |
| 17:01.11 | dcordes | I tried this with the current git but it doesn't boot |
| 17:01.38 | dcordes | it's a sort of rudimentary integration of what dzo done lately to get the sound connection to the modem working |
| 17:01.41 | martin__ | when we've got everything working, i can look at what is actually kaiser-specific, or msm7200-specific, and come up with a better organised patch for upstream. |
| 17:01.58 | dcordes | ok |
| 17:03.07 | dcordes | martin__: may I ask what you do about the write? |
| 17:03.35 | martin__ | it's possible the version i just posted will work |
| 17:03.44 | dcordes | oh |
| 17:03.53 | dcordes | have to give that a try |
| 17:03.53 | martin__ | there's quite a few changes there |
| 17:04.07 | martin__ | i'm having trouble booting again here |
| 17:04.28 | dcordes | flash a 6.1 rom |
| 17:04.56 | martin__ | someone broke the ipaq module in 2.6.26-rc5 |
| 17:05.13 | martin__ | going to boot my old kernel |
| 17:05.18 | martin__ | biab |
| 17:06.49 | dcordes | I use a light webserver where I put the things in and download them with internet explorer |
| 17:07.29 | dcordes | a script updates the zImage on the server after build and booting works all the time. very comfy |
| 17:13.09 | martin__ | woot |
| 17:13.20 | martin__ | it seems to work |
| 17:13.27 | dcordes | no shit? |
| 17:13.29 | martin__ | reading at least |
| 17:14.37 | dcordes | did you try to write? |
| 17:15.01 | martin__ | hang on |
| 17:15.18 | dcordes | I just send a ´AT\r´to smd0 |
| 17:15.28 | dcordes | it printed smd: irq 6 |
| 17:15.32 | dcordes | like 20 times |
| 17:15.51 | dcordes | the head/tail printk looks odd |
| 17:15.59 | dcordes | I will write some more bits |
| 17:16.34 | dcordes | how can I redirect the whole output so I can scroll it? |
| 17:17.18 | dcordes | looks like the old problem |
| 17:17.28 | dcordes | head changes, tail not according to the printk |
| 17:17.45 | martin__ | how can you get a > on the keyboard |
| 17:17.51 | dcordes | shift zero |
| 17:18.01 | dcordes | backslash is camera 1 |
| 17:18.20 | dcordes | brb |
| 17:19.36 | martin__ | hmm, interesting |
| 17:19.36 | martin__ | the tail did change |
| 17:22.24 | mistadman | martain__: strh does this eq read or write command? |
| 17:22.33 | mistadman | assembly->strh |
| 17:23.45 | martin__ | i don't speak assembly :) |
| 17:23.56 | mistadman | got it |
| 17:31.02 | dcordes | it change only from 0 to 1 at the beginning |
| 17:31.07 | dcordes | when I sent AT\r |
| 17:31.15 | martin__ | i have some suspicions |
| 17:31.30 | *** join/#htc-linux ltxda0 (n=ltxda@unaffiliated/ltxda) |
| 17:31.42 | martin__ | see how after that, it spams hundreds of irqs on each write but never changes the tail? |
| 17:33.57 | martin__ | i reckon that's it running right round the buffer |
| 17:34.10 | martin__ | because the head and tail are swapped going the other way |
| 17:34.17 | martin__ | rewriting the code to accomodate that. |
| 17:43.54 | *** join/#htc-linux m4rku5 (n=darkguar@p5B07509A.dip.t-dialin.net) |
| 17:46.01 | *** part/#htc-linux m4rku5 (n=darkguar@p5B07509A.dip.t-dialin.net) |
| 17:47.45 | dcordes | martin__: yea noticed the irqs |
| 17:47.53 | dcordes | the more you write, the more irqs you get |
| 17:50.08 | martin__ | dcordes: uploaded a new kaiser-smd.c |
| 17:50.18 | dcordes | ok |
| 17:50.25 | dcordes | replacing old? |
| 17:50.26 | martin__ | y |
| 17:50.30 | dcordes | http://void.printf.net/~martin/kaiser-smd.c |
| 17:50.35 | martin__ | yup |
| 17:55.24 | martin__ | hmm, this is promising |
| 17:55.49 | martin__ | now when you write to the channel you get some irq 2s as well as irq 6s |
| 17:55.57 | martin__ | which suggests a response |
| 17:56.02 | dcordes | booting |
| 17:56.34 | dcordes | will investigate the listen |
| 17:56.51 | dcordes | s/listen/response/ |
| 17:58.21 | dcordes | kiozen: what's the usual replay to AT? |
| 17:58.31 | dcordes | martin__: I think itworks |
| 17:58.35 | ellisway | ok |
| 17:58.40 | martin__ | dcordes: yeah? |
| 17:58.52 | dcordes | yea I never seen those messages starting with fatal beofre |
| 17:58.55 | ellisway | at on its own should give the response ok |
| 17:59.39 | dcordes | somebody or something broke the ctrl key gr |
| 18:00.16 | martin__ | yeah that's been pissing me off too |
| 18:00.17 | *** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 18:00.29 | dcordes | martin__: are you in the console imagE? |
| 18:00.33 | martin__ | yeah |
| 18:00.42 | dcordes | can you put commands? |
| 18:00.48 | dcordes | check if you have miniterm |
| 18:01.03 | martin__ | hang on, gotta reboot cos i can't ctrl-c. |
| 18:01.07 | dcordes | ok same |
| 18:01.49 | martin__ | i don't get why the pointers keep being zeroed though |
| 18:02.57 | dcordes | gotta poke the keyboard guy about ctrl |
| 18:03.15 | dcordes | hm no miniterm |
| 18:04.16 | martin__ | could do cat /dev/smd0 & cat > /dev/smd0 |
| 18:04.58 | dcordes | that's what I did above |
| 18:05.06 | dcordes | you mean echo / cat |
| 18:05.20 | martin__ | no i mean literally that command line |
| 18:05.27 | martin__ | cat /dev/smd0 & cat > /dev/smd0 |
| 18:06.01 | dcordes | I did "echo `AT\r` > /dev/smd0 & cat /dev/smd0" |
| 18:06.08 | dcordes | tried? |
| 18:06.12 | martin__ | ah, that'd do, yeah |
| 18:06.25 | martin__ | use cat and you can keep putting in commands though |
| 18:06.35 | martin__ | but we should sort out the ctrl key stuff |
| 18:06.52 | martin__ | was there a commit on the keyboard stuff? |
| 18:08.14 | dcordes | ah wtf |
| 18:08.29 | dcordes | board-kaiser-keypad.c |
| 18:09.27 | dcordes | cu doesn't work because it says creat /var/lock/TMP000000000000ea:Permission denied |
| 18:09.45 | martin__ | is there a /var/lock directory? |
| 18:09.51 | dcordes | yes |
| 18:10.04 | dcordes | try yourself |
| 18:10.09 | dcordes | cu -l /dev/smd0 I think |
| 18:10.48 | dcordes | I can create files in /var/lock/ w/o problems |
| 18:11.04 | martin__ | is it trying to create a device or a fifo or something? |
| 18:11.57 | dcordes | because of the line in use? |
| 18:12.01 | dcordes | maybe the -l is wrong |
| 18:25.49 | *** join/#htc-linux Othello (i=Magorium@gateway/tor/x-c8d6a37b839b1f1e) |
| 18:28.07 | dcordes | martin__: I did a screen /dev/smd0 |
| 18:28.41 | martin__ | ? |
| 18:28.49 | dcordes | you can use that to communicate |
| 18:29.06 | dcordes | it spams the crap out with smd: irq6 |
| 18:29.20 | dcordes | between you can see the AT messages from the modem coming it |
| 18:29.24 | dcordes | I can't tell if I can write |
| 18:29.28 | dcordes | too much spam |
| 18:29.37 | dcordes | it's also hard to read the head tail printk |
| 18:29.46 | martin__ | okay |
| 18:30.00 | martin__ | if we think read is working okay, comment out the printk for that |
| 18:30.12 | martin__ | and the irq printk |
| 18:30.36 | dcordes | I can see something about ARM9= and ARM11= |
| 18:30.57 | martin__ | those are the same as the previous head= and tail= |
| 18:31.08 | dcordes | I see |
| 18:31.27 | martin__ | whichever way the data is going, the addresses mean the same thing |
| 18:31.35 | martin__ | one is the arm9's pointer into the circular buffer |
| 18:31.40 | martin__ | one is the arm11's. |
| 18:32.03 | dcordes | which printk produces irq6? |
| 18:32.03 | martin__ | for write, the arm11's is head |
| 18:32.04 | dcordes | read? |
| 18:32.19 | dcordes | I see dynamic head/tail printk |
| 18:32.22 | mistadman | What did I tell you dcordes |
| 18:32.34 | martin__ | irq 6 seems to be associated with the AT write channel. |
| 18:32.36 | mistadman | other smd device |
| 18:32.39 | mistadman | Ha! |
| 18:33.08 | dcordes | martin__: I will just get rid of both irq printks |
| 18:33.16 | martin__ | they're both the same printk |
| 18:33.45 | dcordes | which line? |
| 18:33.55 | martin__ | 140 |
| 18:36.27 | martin__ | the printk's are all done with D(...) |
| 18:36.46 | martin__ | which gets defined to either printk or a do-nothing at the top of the file |
| 18:36.54 | martin__ | so you can turn on and off debugging |
| 18:37.19 | martin__ | at compile time, anyway |
| 18:37.47 | dcordes | huh don't get it |
| 18:38.04 | martin__ | see line 38 |
| 18:38.18 | martin__ | change it to if 0 if you want no debug messages |
| 18:38.41 | dcordes | well I want the head and tail |
| 18:39.07 | martin__ | yeah, just comment out the bits you want rid of then |
| 18:39.19 | martin__ | just explaining why you can't search for printk in the file... |
| 18:41.03 | dcordes | the homeless stubs are exactly the ones that get used with the proc comm patches |
| 18:41.42 | martin__ | yeah, i just wanted to move them out of the way to reduce confusion |
| 18:42.07 | dcordes | I'm a bit confused about the printk |
| 18:42.14 | martin__ | since they're not used by the smd code |
| 18:42.18 | dcordes | what exactly will I do to turn off debugging entirely? |
| 18:42.34 | martin__ | change "if 1" to "if 0" on line 39 |
| 18:42.57 | martin__ | that was already there |
| 18:43.03 | martin__ | in the old versions of the file |
| 18:43.07 | dcordes | did it |
| 18:43.22 | martin__ | i just made the printks people had added use it too |
| 18:48.19 | dcordes | martin__: I think the modem refuses to work as soon as we write crap |
| 18:48.32 | dcordes | I got the same FATAL messages as before when I wrote the AT\r |
| 18:48.34 | dcordes | anr read |
| 18:48.43 | dcordes | they terminate any data coming from the modem |
| 18:48.43 | martin__ | ok |
| 18:48.56 | martin__ | well, at least it's noticed us :) |
| 18:49.11 | dcordes | I think it definetly does |
| 18:49.22 | martin__ | what do the msgs say |
| 18:49.24 | martin__ | ? |
| 18:51.46 | dcordes | they all begin with |
| 18:51.58 | dcordes | [WCDMA] +FATAL: Task: |
| 18:52.16 | dcordes | and then followed by some id name |
| 18:52.19 | *** join/#htc-linux andy_js (n=andy@AAmiens-152-1-38-8.w83-198.abo.wanadoo.fr) |
| 18:52.33 | dcordes | I will copy a a complete line |
| 18:53.53 | martin__ | dcordes: do you have that trace from wince talking to the modem? |
| 18:54.32 | dcordes | SMD,SP=0x17f6f60, PC=0x2, SP_Limit=0x17f7ee4, State=0xfffff |
| 18:54.41 | dcordes | martin__: which one? |
| 18:54.48 | dcordes | you mean the dump or mmutrace? |
| 18:57.07 | dcordes | [WCDMA] +FATAL: Task: SMD,SP=0x17f6f60, PC=0x2, SP_Limit=0x17f7ee4, State=0xfffff (cut off at the end, don't know how to scroll the screen right) |
| 18:59.41 | dcordes | I will try the screen with the modem off |
| 18:59.46 | dcordes | then I'm off |
| 19:00.04 | dcordes | martin__: http://rafb.net/p/8tfKso50.html |
| 19:01.40 | martin__ | dcordes: yeah, see, that trace is wacky |
| 19:02.02 | martin__ | there's all this stuff going on up at smem + fc0xx |
| 19:03.12 | martin__ | that's miles away from the head/tail/buffer |
| 19:03.19 | *** join/#htc-linux LunohoD (n=alex@e180069210.adsl.alicedsl.de) |
| 19:05.06 | martin__ | dcordes: that trace suggests there's something else involved in talking to the modem too |
| 19:05.23 | martin__ | maybe those writes are something to do with the sound |
| 19:06.38 | dcordes | could be |
| 19:06.46 | martin__ | did you do a trace of the AT write channel addresses? |
| 19:07.14 | martin__ | does that work with haret now |
| 19:07.15 | martin__ | ? |
| 19:07.55 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 19:08.02 | martin__ | hey cr2 |
| 19:08.03 | dcordes | martin__: try |
| 19:08.12 | cr2 | hi |
| 19:08.15 | dcordes | hello cr2 |
| 19:08.26 | cr2 | any (good) news ? |
| 19:08.48 | dcordes | kaiser mmutrace fixed |
| 19:08.54 | cr2 | i didn't have time to read the logs |
| 19:09.02 | cr2 | of do any hacking recently ;) |
| 19:09.06 | cr2 | ok. |
| 19:09.25 | dcordes | and martin__ rewrote whole kaiser-smd.c, enabling gps read |
| 19:09.25 | cr2 | so you can see which dlls access the SD, fifos et al. ? |
| 19:09.34 | cr2 | does it work ? |
| 19:09.36 | dcordes | I'm not too sure |
| 19:09.48 | cr2 | i mean gps. |
| 19:10.06 | dcordes | yes. I see the gps messages when I cat device while gps is active on boot |
| 19:10.21 | cr2 | cat /dev/smdX ? |
| 19:10.24 | dcordes | right |
| 19:10.30 | dcordes | just prints the nmea data I think |
| 19:10.42 | cr2 | ok, that't what it should do, |
| 19:11.05 | cr2 | is it smd7 ? |
| 19:11.09 | dcordes | yes |
| 19:11.18 | cr2 | do you have it documented somewhere ? |
| 19:11.19 | dcordes | http://void.printf.net/~martin/kaiser-smd.c |
| 19:11.34 | dcordes | cr2: you put the register in the wiki |
| 19:11.41 | dcordes | don't know what I should document more |
| 19:13.05 | cr2 | so you handle 0 and 7 now. |
| 19:13.09 | cr2 | what about 1 ? |
| 19:13.28 | dcordes | we leaved it out because we don't have the net data registers yet |
| 19:13.42 | cr2 | net data ? |
| 19:13.52 | dcordes | yes the umts data |
| 19:13.58 | dcordes | or whatsoever that's called |
| 19:14.08 | cr2 | whihc data ? |
| 19:14.33 | cr2 | the fifo or the umts data access itself ? |
| 19:14.44 | dcordes | no idea |
| 19:14.48 | martin__ | if someone's absolutely sure which smem blocks are used for the umts data i'll put that back in |
| 19:14.49 | dcordes | exactly what it is |
| 19:14.54 | martin__ | likewise any other smd channels we're sure about |
| 19:15.08 | martin__ | but currently the only ones i've seen tested are AT and GPS. |
| 19:15.21 | cr2 | ok. |
| 19:15.38 | cr2 | i don't have either umts data or msm7200 :) |
| 19:16.29 | dcordes | cr2: how did I get the smem-dump-to-file-thing again? |
| 19:18.16 | cr2 | pd |
| 19:18.33 | cr2 | sorry |
| 19:18.49 | cr2 | pwf file addr size |
| 19:19.33 | cr2 | mistadman: your dpram trace looks interesting |
| 19:19.37 | dcordes | 1M size? |
| 19:19.43 | cr2 | dcordes: yes |
| 19:19.49 | cr2 | mistadman: still here ? |
| 19:19.53 | dcordes | sorry I mean what is the size bit for 1M? |
| 19:22.11 | cr2 | 0x100000 |
| 19:28.12 | martin__ | dcordes: can't seem to get that to trace |
| 19:28.15 | martin__ | can you try? |
| 19:28.35 | dcordes | almost done.. |
| 19:28.47 | martin__ | phys 0x01f041f0, wince virt 0xb51041f0, size 8204 |
| 19:29.03 | dcordes | I went online using umts, downloaded a 130K file, closed the connection, openned wifi connection, ran haret, dumped |
| 19:29.42 | dcordes | that should sufice I assume the umts buffer is still filled |
| 19:29.51 | dcordes | or umts fifo, modem data fifo whatsoever |
| 19:29.57 | martin__ | okay, that dump will be useful |
| 19:30.01 | cr2 | yes |
| 19:30.06 | cr2 | it's interesting. |
| 19:30.09 | dcordes | in msm7x00-smd.c it'S called eth0 |
| 19:30.19 | dcordes | in the comment |
| 19:30.28 | martin__ | but i need a trace of just the at tx buffer |
| 19:30.45 | dcordes | should be no problem |
| 19:30.55 | martin__ | okay, just those addresses above |
| 19:31.18 | dcordes | addlist mmutrace 0xb51041f0 0x8204 |
| 19:31.30 | martin__ | yeah i did that |
| 19:31.31 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfd503.pool.einsundeins.de) |
| 19:31.38 | martin__ | and did wirq 60 |
| 19:31.49 | dcordes | did you get reads/writes? |
| 19:31.49 | martin__ | but all i got in the output was irq stuff |
| 19:31.58 | dcordes | so no reads writes |
| 19:32.12 | martin__ | 039116: mmutrace 80065470: e1403092(swp?) b51fc138 00000000 (b51fc138) |
| 19:32.12 | martin__ | 039116: giving up - clearing mapping |
| 19:32.15 | dcordes | try adding the other virt that points to the 0x01f phys |
| 19:32.21 | dcordes | with the same size |
| 19:32.24 | dcordes | look at the mmu |
| 19:32.43 | dcordes | 0xb5100000 1MB |
| 19:32.47 | dcordes | 0x95100000 1MB |
| 19:32.51 | dcordes | 0x4fc0c000 4K |
| 19:32.56 | dcordes | 0x4fc00000 4K |
| 19:33.29 | dcordes | and then there is 0x4a20a000 (0x4a30c000 - 0x4a20a000) which freezes the kaiser when you trace it entirely |
| 19:36.34 | martin__ | yeah, it may be that the access is happening through the 4K maps |
| 19:37.17 | martin__ | 50df0000 maps there too |
| 19:37.43 | martin__ | wait, no |
| 19:37.51 | martin__ | that's 001f0000 |
| 19:38.12 | martin__ | how do you disable all the irq tracing? |
| 19:38.25 | dcordes | cr2: it appears a bit long 0x100000 |
| 19:38.27 | dcordes | zero too much? |
| 19:38.33 | dcordes | 01fbe760 | 00000000 00000000 00000000 00000000 | ................ |
| 19:39.14 | martin__ | anyway, i need to go |
| 19:39.19 | martin__ | will look at this more later |
| 19:39.25 | dcordes | yes I'm also off |
| 19:39.31 | martin__ | progress, though... |
| 19:39.31 | dcordes | I'm emailing you the smem dump |
| 19:39.34 | martin__ | cheers |
| 19:42.26 | dcordes | cyall later |
| 19:44.44 | *** part/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 20:04.20 | *** join/#htc-linux andy_js_ (n=andy@AAmiens-152-1-38-8.w83-198.abo.wanadoo.fr) |
| 20:29.48 | cr2 | hehehe. these nokia people are completely off track. |
| 20:30.27 | *** join/#htc-linux tsdogs (n=tsdogs@62.123.180.130) |
| 20:32.09 | cr2 | hi tsdogs |
| 20:32.26 | tsdogs | hi cr2 |
| 20:33.29 | cr2 | tsdogs: i've seen your link. i think nokia is officially evil now ;) |
| 20:33.45 | tsdogs | :) agreed |
| 20:35.26 | cr2 | have you seen that there is an osm2mp now, supporting route planning ? |
| 20:37.17 | tsdogs | nope |
| 20:38.20 | cr2 | it's a perl script. |
| 20:38.27 | lama | http://news.zdnet.co.uk/hardware/0,1000000091,39432956,00.htm |
| 20:38.38 | tsdogs | though osm does not have much data for route afair, BTW I mapped my city with merkaartor |
| 20:38.40 | cr2 | does not support turn restrictions, but it's easy to add. |
| 20:39.26 | cr2 | merkaartor may do some useful things. |
| 20:40.05 | cr2 | i'm using it with a geotiff2TMS script. |
| 20:40.08 | tsdogs | needs improvement on the relation and taggins side, but it's coming the good way |
| 20:41.00 | tsdogs | no idea what TMS is :) |
| 20:41.34 | cr2 | 'create area' still has 'road - properties' |
| 20:41.49 | tsdogs | hmm, I upgraded to Fedora 9, but I'm not sure anymore it was a good idea. |
| 20:42.06 | cr2 | 256x256 tiles as background. |
| 20:42.44 | tsdogs | yes, I was thinking on proposing some config file to deal with tagging, so it can bind the right ones, and can follow OSM tag changes/additions |
| 20:42.50 | cr2 | do oyu know how to change the poi->icon in merkaaartor ? |
| 20:42.51 | tsdogs | ho, ok |
| 20:43.23 | cr2 | it's the same PITA as with roadmap |
| 20:43.28 | tsdogs | I think it's hardcoded, and the icons are in a qrc file |
| 20:43.45 | cr2 | i don't see the tiny town/village 'dots' on the TMS background. |
| 20:44.02 | cr2 | and don't know how to change it. |
| 20:44.12 | tsdogs | hmm let me check :) |
| 20:44.41 | cr2 | thanks. |
| 20:47.04 | *** join/#htc-linux pikapika (n=pikapika@mar75-8-88-164-227-147.fbx.proxad.net) |
| 20:47.20 | pikapika | :) |
| 20:49.41 | tsdogs | cr2: in source Styles/Mapnik.mas |
| 20:50.14 | ellisway | evenin all |
| 20:51.46 | tsdogs | Actually you can change the Icons/Places/place_village.png :) |
| 20:52.56 | tsdogs | I think that having this in a qrc (embedded resource file) is not a real good solution |
| 20:53.03 | tsdogs | ellisway: evening :) |
| 20:54.57 | cr2 | tsdogs: ok. |
| 20:55.49 | cr2 | tsdogs: i think i'll need a serious modification to merkaartor before really using the realtions for turn restrictions. |
| 20:56.41 | tsdogs | hmm, I'm upgrading to Fedora 9, but I'm not sure it's been a good idea to have KDE4... It's missing so many things, maybe I'll switch to 4.1beta... |
| 20:57.45 | tsdogs | cr2: well turn restrictions are pretty basic in merkaartor, but there was a mentioning in ML |
| 20:59.08 | cr2 | tsdogs: i think merkaartor needs 2 things: 'verify map' function like gpsmapedit, but it's not a major one. |
| 20:59.32 | cr2 | the major one is the function to split the ways in all nodes that have >2 way segments. |
| 21:00.20 | cr2 | i don't know how merkaartor stores the nodes/ways internally. maybe this functions will be very simple to implement. |
| 21:01.57 | *** join/#htc-linux ellisway (n=ellis@80-46-67-47.static.dsl.as9105.com) |
| 21:02.49 | tsdogs | cr2: no idea, haven't looked at relations in OSM that much, but wouldn't it be a separate element? |
| 21:04.17 | cr2 | relations is a separate element, but it's a different problem. |
| 21:04.45 | tsdogs | aren't they used to specify turn restrictions? |
| 21:06.01 | cr2 | yes, but the life will be much easier if you follow the 'roadmap' topology for the "ways" |
| 21:06.23 | tsdogs | ok |
| 21:07.16 | cr2 | in roadmap each "way" has only 2 "real" nodes. |
| 21:07.30 | cr2 | and the start and at the end. |
| 21:08.04 | cr2 | all other vertices are only describing the shape. |
| 21:08.23 | tsdogs | ok so it actually would need to split the way into segments which start from a connection and end to another connection (if there is one) |
| 21:08.31 | cr2 | so you don't care about them for turn restrictions and so. |
| 21:08.41 | cr2 | yes. |
| 21:08.45 | tsdogs | then apply relations to this nodes |
| 21:08.48 | tsdogs | ok got it |
| 21:09.12 | cr2 | you can count the number of 'incoming' and 'outgoing' lines for each OSM node. |
| 21:09.30 | cr2 | if it is =1, then it's an 'end-node' |
| 21:09.40 | tsdogs | hmm, don't think it's like that in the code... |
| 21:10.03 | cr2 | if it's =2, then it's most likely a simple vertex |
| 21:10.35 | cr2 | unless the "left" and "right" tags do not match |
| 21:10.39 | tsdogs | though turn restrictions should be something like way2 to way2 from x not permitted |
| 21:10.58 | tsdogs | or to x |
| 21:11.05 | cr2 | it's not so easy. |
| 21:11.10 | tsdogs | turn restrictions can be nasty |
| 21:11.19 | cr2 | if you use the pure OSM model. |
| 21:11.43 | tsdogs | brb |
| 21:14.18 | tsdogs | reading http://wiki.openstreetmap.org/index.php/Relations/Turn_Restrictions looks pretty clear |
| 21:14.31 | tsdogs | making them is not so easy though :) |
| 21:15.21 | tsdogs | what are psv / hgv ? |
| 21:15.41 | cr2 | some vehicles |
| 21:15.45 | tsdogs | lol |
| 21:15.47 | cr2 | forgot which ones :) |
| 21:16.34 | tsdogs | probably service or something |
| 21:16.44 | cr2 | buses and such |
| 21:17.35 | tsdogs | hmm OSM is too much UK centric :) |
| 21:18.10 | cr2 | yeah, but nobody prevents you to set your own tags. |
| 21:18.38 | tsdogs | I know, psv = passenger service vehicle |
| 21:18.40 | cr2 | with a properly configured configs for osm2mp it'll not be an issue. |
| 21:18.45 | cr2 | bus :) |
| 21:19.48 | tsdogs | hgv = heavy goods vehicle |
| 21:20.15 | tsdogs | truks :) |
| 21:20.22 | cr2 | ok. |
| 21:20.57 | cr2 | ok, let's check the simple things instead :) |
| 21:21.09 | tsdogs | lol |
| 21:21.31 | cr2 | i've modified merkaator a bit, but it segfaulted after that ;) |
| 21:21.39 | tsdogs | :) |
| 21:22.01 | cr2 | i wanted to force adding the 'area=yes' tag |
| 21:22.12 | cr2 | if you've selected the 'create->area' |
| 21:22.20 | tsdogs | hmm, that's a missing one. |
| 21:22.42 | cr2 | for some weird reason, creating the area pops up the road properties in the tags. |
| 21:23.00 | cr2 | which is a major PITA for lakes and forests. |
| 21:23.21 | tsdogs | cr2: you can leave that off, and add your own |
| 21:23.58 | cr2 | i hate flash, but potlatch gui (visually) looks the most user-friendly to me of all osm programs. even if it's incomplete and has broken utf8. |
| 21:24.35 | tsdogs | I can't use potlatch it's like beeing a mac user ;) |
| 21:25.02 | cr2 | ok, but why does it segfault ? |
| 21:25.04 | cr2 | lol. |
| 21:25.14 | tsdogs | cr2: no idea. |
| 21:25.25 | tsdogs | what did u change? |
| 21:25.30 | cr2 | it's certainly easier to use for vector ops than merkaartor or josm. |
| 21:26.02 | cr2 | i've added the 'area=yes' tag next to ther 'created_by=merkaartor' |
| 21:26.12 | cr2 | wait i'll look into the source. |
| 21:27.07 | cr2 | ./Interaction/CreateAreaInteraction.cpp |
| 21:27.35 | tsdogs | found it, though I'm not sure setTag is good for a new one... |
| 21:27.46 | cr2 | void CreateAreaInteraction::createNewRoad(CommandList* L) |
| 21:27.46 | cr2 | { |
| 21:27.47 | cr2 | <PROTECTED> |
| 21:27.47 | cr2 | <PROTECTED> |
| 21:27.47 | cr2 | <PROTECTED> |
| 21:27.48 | cr2 | <PROTECTED> |
| 21:28.31 | cr2 | hehe. now i see why it's a road |
| 21:28.33 | cr2 | theRoad = new Road; |
| 21:29.11 | tsdogs | cr2: well basically it does not differ much from a road in the data |
| 21:29.49 | cr2 | ok, but popping up the road attribute dialog of a lake/forest is stupid. |
| 21:29.59 | tsdogs | yep |
| 21:29.59 | cr2 | s/of /for / |
| 21:32.09 | tsdogs | cr2: are u using svn version ? |
| 21:32.22 | *** join/#htc-linux exco (n=exco@e181099163.adsl.alicedsl.de) |
| 21:35.22 | cr2 | tsdogs: yes. |
| 21:35.55 | tsdogs | checking ... |
| 21:36.01 | cr2 | tsdogs: i seldomly use released versions for nice software :) |
| 21:36.23 | tsdogs | :) |
| 21:36.45 | tsdogs | ok it was a stupid question, I thought it just after I posted it :) |
| 21:37.31 | tsdogs | well merkaartor 1.0 would not be usable that much, I only wish the save stuff gets fixed |
| 21:38.01 | tsdogs | cr2: I made it :) |
| 21:38.10 | cr2 | ? |
| 21:38.39 | tsdogs | You need to put this: |
| 21:38.55 | tsdogs | theRoad->setTag("area","yes"); |
| 21:39.10 | tsdogs | on line 114 |
| 21:39.23 | tsdogs | after HaveFirst = false |
| 21:39.37 | cr2 | void CreateAreaInteraction::finishRoad(CommandList* L) |
| 21:39.39 | cr2 | here ? |
| 21:39.42 | tsdogs | yep |
| 21:39.47 | cr2 | ok :) |
| 21:40.13 | tsdogs | still it pops for the road type, but that's more complicated |
| 21:40.41 | cr2 | ok. |
| 21:40.45 | cr2 | compiling. |
| 21:40.49 | tsdogs | brb |
| 21:41.27 | cr2 | QMetaObject::connectSlotsByName: No matching signal for on_toolsPreferencesAction_triggered(uint) |
| 21:41.27 | cr2 | QMetaObject::connectSlotsByName: No matching signal for on_preferencesChanged() |
| 21:42.37 | cr2 | no 'area=yes' tag :( |
| 21:43.03 | cr2 | in the properties |
| 21:43.08 | tsdogs | hmm it works for me |
| 21:44.53 | tsdogs | cr2: u using 4.4? |
| 21:44.56 | cr2 | yes. |
| 21:45.02 | tsdogs | hmm I have 4.3 |
| 21:46.03 | tsdogs | do u have the undo stack ? |
| 21:46.32 | cr2 | how do i check ? |
| 21:46.57 | tsdogs | right click on the toolbar |
| 21:47.06 | tsdogs | do u have an Undo? |
| 21:47.10 | cr2 | i'm downloading a rectangle from OSM, and adding a polygon. |
| 21:47.24 | cr2 | no. |
| 21:47.38 | tsdogs | maybe u only need to svn up then :) |
| 21:47.45 | cr2 | ok. |
| 21:48.43 | cr2 | Revision 8221. |
| 21:48.59 | tsdogs | yes |
| 21:50.02 | cr2 | Undo/Redo icons. |
| 21:50.05 | tsdogs | your change works for me too |
| 21:50.52 | tsdogs | I mean that making the change you have made to my source worked for me... |
| 21:51.03 | cr2 | strange. |
| 21:51.20 | tsdogs | do you have the undo? |
| 21:51.24 | cr2 | yes. |
| 21:51.39 | tsdogs | ok, does it still segfault= |
| 21:51.41 | tsdogs | = |
| 21:51.42 | tsdogs | ? |
| 21:52.17 | cr2 | no. |
| 21:52.27 | tsdogs | but no are tag? |
| 21:52.34 | cr2 | but the 'area=yes' does not show up in the properties. |
| 21:52.36 | cr2 | yes |
| 21:53.02 | cr2 | i'll do make clean. |
| 21:53.10 | tsdogs | now it shows up even if I click on select before closing the area |
| 21:53.36 | tsdogs | what's the rectangle you are downloading? |
| 21:53.41 | cr2 | <PROTECTED> |
| 21:53.41 | cr2 | + theRoad->setTag("area", "yes"); |
| 21:53.41 | cr2 | <PROTECTED> |
| 21:53.44 | cr2 | svn diff |
| 21:54.36 | tsdogs | cr2: I moved it in the createNewRoad and also works |
| 21:54.48 | cr2 | recompiling after make clean. |
| 21:55.20 | cr2 | btw, your roadmap qt4 patches seem to go into /dev/null ;) |
| 21:55.57 | tsdogs | ;) Paul said he changed work so it'll take some time for him to review |
| 21:56.18 | tsdogs | Though I think it's not on his priorities |
| 21:56.23 | cr2 | ok. |
| 21:56.46 | tsdogs | nobody replied though :( |
| 21:57.09 | cr2 | i can't compile the latest code by Danny |
| 21:57.33 | tsdogs | I haven't even tryed actually... |
| 21:57.48 | cr2 | qt4 is broken there. |
| 21:58.00 | cr2 | obviously, because of the missing widget support. |
| 21:58.31 | cr2 | hehe. |
| 21:58.44 | cr2 | where is the compiled program ??? |
| 21:58.54 | cr2 | 12. Apr 22:57 merkaartor |
| 21:58.54 | tsdogs | binaries/debug/bin |
| 21:59.03 | tsdogs | :) |
| 21:59.06 | cr2 | lol |
| 21:59.15 | cr2 | in release/merkaartor |
| 21:59.21 | cr2 | hehehe |
| 21:59.25 | tsdogs | lol |
| 21:59.51 | cr2 | and i'm wondering why i don't see any changes :) |
| 22:00.13 | tsdogs | :) |
| 22:00.40 | tsdogs | in roadmap it seems a Makefile problem... |
| 22:00.46 | tsdogs | I'll try myself |
| 22:00.59 | cr2 | now the proxy is broken. |
| 22:02.25 | cr2 | 'host not found' |
| 22:03.07 | tsdogs | hmm, I don't use the proxy function |
| 22:03.24 | cr2 | the download window over proxy is broken too. |
| 22:03.36 | cr2 | it was working with my apr 12 version ;) |
| 22:03.41 | tsdogs | cr2: I get the same error with danny source |
| 22:04.03 | cr2 | i have a much faster machine behind the proxy. |
| 22:04.08 | cr2 | ok. |
| 22:04.33 | cr2 | Object::connect: No such signal QWebFrame::loadDone(bool) |
| 22:04.33 | cr2 | QNetworkAccess: got HTTP status code 400 which is not expected |
| 22:05.18 | cr2 | error while loading shared libraries: libQtWebKit.so.4: |
| 22:05.36 | cr2 | don't have 4.4 on this machine. |
| 22:07.49 | cr2 | ok, area=yes works. |
| 22:10.02 | tsdogs | good |
| 22:10.16 | tsdogs | I think you should put back the code where it was :) |
| 22:11.52 | cr2 | ok. |
| 22:12.22 | cr2 | i still don't understand certain things about this gui. |
| 22:12.36 | cr2 | merge nodes and such things. |
| 22:13.04 | cr2 | hmm. now i can't edit in merkaartor anymore ;) |
| 22:13.04 | tsdogs | ./unix/libosroadmap.a(roadmap_library): In function `roadmap_library_symbol': |
| 22:13.08 | tsdogs | roadmap_library.c:(.text+0x34): undefined reference to `dlsym' |
| 22:13.12 | tsdogs | roadmap_library.c:(.text+0x41): undefined reference to `dlerror' |
| 22:13.13 | cr2 | -ldl |
| 22:13.16 | tsdogs | roadmap_library.c:(.text+0x72): undefined reference to `dlclose' |
| 22:13.20 | tsdogs | ./unix/libosroadmap.a(roadmap_library): In function `roadmap_library_load': |
| 22:13.20 | tsdogs | roadmap_library.c:(.text+0x17d): undefined reference to `dlopen' |
| 22:13.20 | tsdogs | roadmap_library.c:(.text+0x18a): undefined reference to `dlerror' |
| 22:13.20 | tsdogs | collect2: ld returned 1 exit status |
| 22:13.20 | tsdogs | make: *** [dumpmap] Error 1 |
| 22:13.21 | tsdogs | removing the navigate_init function |
| 22:13.44 | cr2 | ok. |
| 22:15.34 | cr2 | proxy is completely broken. |
| 22:17.27 | cr2 | LOL |
| 22:17.32 | cr2 | #ifdef GOOGLE_ILLEGAL |
| 22:17.32 | cr2 | <PROTECTED> |
| 22:17.32 | cr2 | #endif |
| 22:18.03 | cr2 | it will not work this way. |
| 22:19.44 | tsdogs | :) |
| 22:22.10 | cr2 | hmm. how do i repair the proxy... |
| 22:22.50 | tsdogs | cr2: no idea (revert back?) |
| 22:23.48 | *** join/#htc-linux SuN (i=unices@ip5652ade4.speed.planet.nl) |
| 22:23.57 | *** join/#htc-linux LunohoD_ (n=alex@e180068194.adsl.alicedsl.de) |
| 22:25.29 | cr2 | adding printfs |
| 22:29.52 | cr2 | tsdogs: apropos nokia: "I suddenly want to throw my N810 out the window, thank jeebus they've debian for it now" |
| 22:30.08 | tsdogs | :) |
| 22:30.22 | tsdogs | let's see what happens first |
| 22:31.33 | mistadman | cr2: Hows everything |
| 22:31.59 | mistadman | cr2: What look interesting about my dpram? |
| 22:32.13 | cr2 | tsdogs: yes. |
| 22:32.31 | cr2 | mistadman: your trace confirms the head/tail registers. |
| 22:32.46 | cr2 | mistadman: what about the command size ? |
| 22:33.20 | tsdogs | cr2: I think danny source is bloated it now complains about editor plugin :) |
| 22:33.40 | cr2 | tsdogs: yes, that's what he has told in the ML |
| 22:35.11 | tsdogs | ok |
| 22:35.31 | mistadman | cr2: Not sure what you mean by command size |
| 22:35.45 | tsdogs | ok rebooting... |
| 22:35.47 | tsdogs | brb |
| 22:36.01 | mistadman | cr2: I am in the process of decoding a dump now |
| 22:36.19 | mistadman | cr2: I have it pretty much figured out |
| 22:36.50 | mistadman | cr2: have have been slowly updating the wiki, but just wanna make sure I got it right |
| 22:37.17 | cr2 | mistadman: the dump looks pretty obvious |
| 22:37.28 | mistadman | cr2: I have figured the head and tail for both the rx and tx |
| 22:38.23 | cr2 | mistadman: it's only the reset / power missing there. and the soft uart driver. maybe we'd look at the sdio_uart. or blueangel dpram, but this one is an old hack. |
| 22:38.52 | cr2 | sdio_uart looks as a most appropriate to me. |
| 22:39.16 | mistadman | cr2: Already a step ahead. I have starting porting the DPRAM code to the Athena |
| 22:40.10 | mistadman | cr2: Look at this new dump: http://rafb.net/p/qBey4d47.html |
| 22:40.23 | mistadman | cr2: I just have one stupid question |
| 22:40.36 | mistadman | cr2: All this stuff is pretty new to me. |
| 22:40.49 | *** join/#htc-linux tsdogs (n=tsdogs@62.123.180.130) |
| 22:41.41 | mistadman | cr2: Line 31 - 37 (doesnt quit match up): |
| 22:42.18 | mistadman | cr2: Is wince reading the rx buffer or writing to the rx buffer? |
| 22:42.31 | cr2 | rx is for reading. |
| 22:42.46 | cr2 | tx is for writing. |
| 22:43.24 | cr2 | it's only important to get the 3fc* registers right. |
| 22:43.58 | cr2 | mistadman: 039ffdb8 <- is it the rilgsm ? |
| 22:44.17 | mistadman | cr2: Ahhh! |
| 22:44.30 | mistadman | cr2: Very good info! |
| 22:45.05 | mistadman | cr2: Thanks! Good to know what whats doing what. |
| 22:45.12 | dcordes | mistadman: hey got progress? |
| 22:45.30 | mistadman | cr2: What command in haret tells you that? |
| 22:45.34 | cr2 | mistadman: check 'addr2mod 0x039ffdb8' |
| 22:45.59 | cr2 | all the calls are limited to 1 dll. i think it's rilgsm |
| 22:46.28 | mistadman | dcordes: Not really, just making sure my traces or 100% correct. I want to make sure wiki is accurate. |
| 22:46.49 | cr2 | dcordes: pxa270 is much easier to deal with. |
| 22:47.02 | mistadman | dcordes: Getting registers documented correctly |
| 22:47.14 | cr2 | dcordes: there is even a hardware tracing option. |
| 22:47.17 | dcordes | cr2: because it doesn't have * in modem? |
| 22:48.08 | cr2 | dcordes: because the msm6275 is a separate chip, and pxa270 has the documented hardware debugging registers. |
| 22:49.12 | cr2 | tsdogs: what do you think about submitting the buildmap_simplify(), _ssplit() and _sfree() ? |
| 22:49.26 | dcordes | I see |
| 22:49.52 | mistadman | cr2: Address 039ffdb8 not process specific |
| 22:49.52 | mistadman | <PROTECTED> |
| 22:50.56 | mistadman | cr2: Is that what you expected? |
| 22:51.27 | cr2 | mistadman: ok, i'll look. |
| 22:51.57 | cr2 | mistadman: what about cmd length? |
| 22:52.24 | mistadman | cr2: I am not sure of what your asking? Whats command length? |
| 22:54.03 | cr2 | mistadman: in the wiki -> +0x3fcc cmd length? |
| 22:56.48 | tsdogs | cr2: it's ok for me, no idea what's the use for though :) |
| 22:57.00 | mistadman | cr2: Got it. Well I think its not command length. I believe its the offset to the head of tx buffer. |
| 22:57.45 | cr2 | tsdogs: .mp parser, countries/'states/'counties' |
| 22:58.11 | cr2 | mistadman: it was just my wild guess after looking at the .dll |
| 22:58.47 | cr2 | tsdogs: i'm really using it in the .mp parser. |
| 22:59.12 | cr2 | tsdogs: but it may be better to separate the _simplify() and _ssplit() |
| 22:59.25 | tsdogs | cr2: is mp better than osm? |
| 22:59.56 | tsdogs | yes probably would clear some things up. |
| 23:00.08 | cr2 | tsdogs: mp is much more strict, and it's easy to convert into .rdm |
| 23:00.27 | cr2 | tsdogs: the "grammar" is much more strict. |
| 23:00.38 | cr2 | parsing .osm is a hell :) |
| 23:00.51 | cr2 | with its rather random tags. |
| 23:01.55 | tsdogs | ok. |
| 23:01.58 | cr2 | and funny way geometry interpretations. |
| 23:02.33 | tsdogs | :) |
| 23:03.04 | cr2 | find . -name \*.cpp | xargs grep UseProxy |
| 23:03.16 | tsdogs | :( great, a disk at the office just died.. |
| 23:03.33 | tsdogs | ho well will replace it on monday, backup should just be running now. |
| 23:04.10 | cr2 | ok. |
| 23:05.00 | tsdogs | DownloadOSM ? |
| 23:05.22 | cr2 | yes. |
| 23:06.05 | cr2 | useproxy=1 |
| 23:08.27 | cr2 | mistadman: ldrb for reading, and strh for writing. weird. |
| 23:08.30 | tsdogs | don't see anything strange there... |
| 23:08.53 | cr2 | useproxy=1 port=80 proxy_port=3128 |
| 23:09.01 | cr2 | need to dump host now. |
| 23:09.28 | mistadman | cr: Whats up with that. I thougth we were writing AT commands to the modem? |
| 23:09.44 | mistadman | cr: are we reading AT commands? Why? |
| 23:10.02 | mistadman | cr2: This is what has me confused.. |
| 23:10.04 | cr2 | #ifdef DEBUG_EVERY_CALL |
| 23:10.24 | cr2 | mistadman: you read the AT responses |
| 23:10.38 | cr2 | mistadman: and write AT commands. |
| 23:10.55 | cr2 | mistadman: sometimes the responses are "unsolicited" |
| 23:11.06 | mistadman | cr2: Whats +CLCC: command. |
| 23:11.40 | mistadman | cr2: This is the response I am getting. Other info left out |
| 23:11.54 | cr2 | mistadman: it's not a commands. |
| 23:12.24 | cr2 | command is AT+CLCC |
| 23:12.35 | cr2 | +CLCC: is the response |
| 23:13.06 | mistadman | cr2: Got it: +CLCC - Request Current Calls |
| 23:21.46 | cr2 | tsdogs: host=proxy ? |
| 23:23.19 | tsdogs | cr2: shouldn't be like that |
| 23:23.29 | tsdogs | host should be osm server |
| 23:24.00 | cr2 | yes, but i set the 'Host:' in the proxy dialog |
| 23:24.16 | cr2 | and the printf shows Web = Proxy |
| 23:24.24 | tsdogs | that should be the ProxyHost then |
| 23:24.41 | cr2 | yes. |
| 23:24.52 | cr2 | but where does it pick the "Web" from ? |
| 23:25.18 | tsdogs | from the Host |
| 23:25.18 | cr2 | aah. |
| 23:25.22 | cr2 | my bad. |
| 23:25.24 | tsdogs | which is in Data |
| 23:25.29 | cr2 | cut&paste. |
| 23:25.47 | cr2 | recompling. |
| 23:26.35 | cr2 | hmm. |
| 23:26.42 | cr2 | useproxy=1 host=openstreetmap.org:80 proxy http://proxy:3128 |
| 23:27.00 | cr2 | http is redundant ? |
| 23:28.09 | cr2 | UNEXPECTED RESPONSE: [HTTP/1.0 403 Forbidden |
| 23:28.09 | cr2 | Server: squid/2.6.STABLE14 |
| 23:28.18 | tsdogs | I think so |
| 23:28.44 | tsdogs | proxy should be proxy:3128 and host=www.openstreetmap.org:80 |
| 23:30.35 | cr2 | yes, edited that, but still get the same error |
| 23:31.37 | tsdogs | hmm, no idea how a http proxy request works :/ |
| 23:32.22 | cr2 | ok. |
| 23:33.37 | tsdogs | cr2: printour seems to be ok... |
| 23:33.57 | tsdogs | s/printour/printout |
| 23:34.24 | tsdogs | I see Proxy: localhost and Web: www.openstreetmap.org (no http there) |
| 23:35.04 | cr2 | X-Squid-Error: ERR_ACCESS_DENIED 0 |
| 23:35.10 | cr2 | strange. |
| 23:35.25 | tsdogs | there are many reasons that happens |
| 23:35.35 | tsdogs | what do you see in the access_log? |
| 23:36.22 | tsdogs | do you use authentication, or some sort of filtering? |
| 23:37.06 | cr2 | access list |
| 23:37.21 | cr2 | but it was working with the old merkaartor version |
| 23:37.31 | tsdogs | hmm, wa |
| 23:37.36 | cr2 | i'll check lynx |
| 23:37.42 | tsdogs | :) |
| 23:37.55 | cr2 | can i set proxy with w3m ? |
| 23:39.10 | tsdogs | wow they fixed the save stuff :) |
| 23:39.58 | cr2 | the {foo-bar-baz} things ? |
| 23:40.00 | tsdogs | HTTP_PROXY |
| 23:40.15 | tsdogs | or o key |
| 23:40.56 | tsdogs | export HTTP_PROXY=http://proxy:3128/ |
| 23:41.10 | tsdogs | I'm starting to think it's a / issue |
| 23:41.39 | cr2 | can't load |
| 23:41.55 | cr2 | hehe. |
| 23:42.01 | tsdogs | changed IP? |
| 23:42.04 | cr2 | the same for google.com |
| 23:42.08 | tsdogs | lol |
| 23:42.15 | cr2 | but i can use firefox. |
| 23:42.19 | cr2 | with proxy. |
| 23:42.23 | *** join/#htc-linux LunohoD_ (n=alex@e180069210.adsl.alicedsl.de) |
| 23:42.44 | tsdogs | cr2: firefox tryes the proxy, if it failes it goes straight |
| 23:42.58 | cr2 | i see it in the logs |
| 23:43.07 | tsdogs | hmm |
| 23:44.04 | tsdogs | selinux? |
| 23:44.14 | tsdogs | but that would be pretty strange |
| 23:46.41 | cr2 | no |
| 23:47.33 | cr2 | works in firefox |
| 23:48.01 | tsdogs | I'm trying with 217.218.121.12:3128 which is an open proxy and it works |
| 23:48.07 | tsdogs | slow but it works |
| 23:49.53 | cr2 | strange. |
| 23:50.25 | cr2 | w3m does not want to work over proxy at all. |
| 23:51.02 | tsdogs | cr2: are u using 0.6 api? |
| 23:51.08 | tsdogs | that does not work |
| 23:51.09 | cr2 | no. |
| 23:52.45 | tsdogs | hmm, I'm starting to think it's a problem in the webkit then |
| 23:53.13 | cr2 | bizarre |
| 23:53.18 | cr2 | only firefox works. |
| 23:53.30 | cr2 | lynx and w3m do not want to works |
| 23:53.35 | cr2 | over proxy |
| 23:53.52 | tsdogs | that's strange |
| 23:54.26 | cr2 | maybe it's too late ;) |
| 23:54.38 | tsdogs | ;) agreed, good night |
| 23:54.55 | cr2 | good night |
