| 00:32.38 | mistadman | dcordes: Whats up? Did you ever get the phone working? |
| 01:08.27 | DesktopMa | If something needs tested on diamond just poke me |
| 01:45.34 | DesktopMa | back later, pc is about to crash :P |
| 01:46.34 | DesktopMa | (DesktopMan on the forums, so if there's diamond related stuff to be done pm me there works too) |
| 01:51.31 | *** join/#htc-linux DesktopMa (n=DesktopM@hybellovas41.grm.hia.no) |
| 02:31.26 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 03:20.06 | *** join/#htc-linux DesktopMM (n=DesktopM@hybellovas41.grm.hia.no) |
| 03:44.59 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 04:10.06 | *** join/#htc-linux LunohoD_ (n=alex@e180065170.adsl.alicedsl.de) |
| 05:32.16 | *** join/#htc-linux Othello__ (i=Magorium@gateway/tor/x-ad31ace212c5614b) |
| 05:47.38 | *** join/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com) |
| 05:48.35 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfdbee.pool.einsundeins.de) |
| 06:42.22 | *** join/#htc-linux goxboxlive (n=goxboxli@160.84-48-176.nextgentel.com) |
| 06:50.17 | martin__ | Kevin21: what do you make of the "Tiny (1K)" mappings that appear at 0x4a300000 in http://void.printf.net/~martin/kaiser-mmu.txt ? cr2 thinks they're a mistake. |
| 07:09.19 | AstainHellbring | so we up to anything fun? |
| 07:09.29 | AstainHellbring | is bored atm... waiting for server rsync to finish |
| 07:09.41 | martin__ | still failing to trace kaiser smem access |
| 07:12.03 | AstainHellbring | damn still locking up on read attempts? |
| 07:12.14 | martin__ | ? |
| 07:12.21 | martin__ | i think you're thinking of the serial stuff |
| 07:12.27 | AstainHellbring | ahh yah I must be |
| 07:12.33 | martin__ | sounds like ginge has that sussed, we were just looking at the wrong uart |
| 07:12.47 | AstainHellbring | I've only caught little bits of stuffs here and there |
| 07:13.02 | AstainHellbring | wrong uart huh so which one the right one? |
| 07:13.06 | martin__ | with the shared memory stuff, dcordes was getting lockups when trying to trace |
| 07:13.13 | martin__ | but that doesn't seem to happen for me |
| 07:13.21 | AstainHellbring | hmm interesting |
| 07:13.23 | martin__ | i just don't see any of the accesses to the smem |
| 07:14.08 | martin__ | and it looks like the stuff dcordes saw wasn't smem |
| 07:14.25 | martin__ | just some other stuff mapped into the same range |
| 07:16.26 | AstainHellbring | hmm |
| 07:18.04 | martin__ | so |
| 07:18.46 | AstainHellbring | so we still don't know exactly where to watch to see whats going on fully with the radio huh? |
| 07:18.53 | martin__ | we know where to watch |
| 07:18.56 | martin__ | we don't see anything |
| 07:19.04 | martin__ | mmutrace doesn't catch the accesses |
| 07:19.12 | AstainHellbring | so gotta tap into it differently? |
| 07:19.32 | martin__ | don't really see how |
| 07:20.05 | martin__ | looking at http://handhelds.org/moin/moin.cgi/HaRET_20Tracing_20Details, it seems there's one most likely explanation |
| 07:20.39 | martin__ | which is that the wince code creates a new mapping, uses it, and then throws it away |
| 07:20.52 | martin__ | so it's not showing up in our mmu dump |
| 07:20.56 | AstainHellbring | ahh ic |
| 07:22.51 | martin__ | but i've tried dumping the mmu with a data connection running |
| 07:23.01 | martin__ | and i don't see anything extra |
| 07:23.33 | martin__ | which leaves DMA access |
| 07:24.31 | martin__ | but it seems odd the processor would have some peripheral that existed just to do DMA to a circular buffer in shared memory |
| 07:25.19 | AstainHellbring | that does seem odd |
| 07:37.31 | *** join/#htc-linux dcordes (n=akita@f048235025.adsl.alicedsl.de) |
| 07:38.52 | dcordes | hi |
| 07:39.44 | AstainHellbring | hiya dcordes |
| 07:49.51 | martin__ | dcordes: hey |
| 07:49.55 | martin__ | just sent you an email |
| 07:52.04 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 08:02.08 | martin__ | ginge_: where do things stand with the serial stuff? |
| 08:02.19 | martin__ | sounded at first like we were going for the wrong uart? |
| 08:02.43 | martin__ | but now you're back to trying to init uart1 properly? |
| 08:02.58 | ginge_ | well... overview:- UART1 crashes on read. UART2 initialises fine and I can open it perfectly. |
| 08:03.07 | martin__ | oh, sweet |
| 08:03.12 | ginge_ | How do I know if the Bluetooth device works? |
| 08:03.27 | ginge_ | if it does AT it isnt listening |
| 08:03.27 | martin__ | will need to do some hciattach magic to access it |
| 08:04.29 | ginge_ | I was poking around UART1 because I was curious as to what it is |
| 08:04.41 | martin__ | do you get the same crash for UART3? |
| 08:04.44 | ginge_ | yes |
| 08:04.54 | martin__ | probably 1 and 3 just aren't used then |
| 08:05.06 | ginge_ | I guessed as much |
| 08:05.22 | martin__ | dunno where the info that the BT was on uart1 came from |
| 08:05.42 | ginge_ | thats what the msm7500 press release has on it |
| 08:06.03 | martin__ | ah, and someone just assumed it was uart1? |
| 08:06.10 | ginge_ | I guess ?? |
| 08:06.14 | martin__ | wince only opens uart2? |
| 08:06.48 | ginge_ | not sure. I don't really know what I am looking at when mapping addresses through haret |
| 08:06.58 | martin__ | can help a bit with that |
| 08:07.08 | martin__ | i'm getting the hang of it now |
| 08:07.31 | martin__ | btw it sounds like all kaiser linux developers are also building quadrocopters |
| 08:08.09 | ginge_ | well:- http://headfuzz.co.uk/files/android/uart1.txt is the raw dump |
| 08:08.37 | ginge_ | well:- http://headfuzz.co.uk/files/android/kaiser-uart1-trace is some poking around mapping those addresses |
| 08:08.44 | ginge_ | and almost certainly wrong :) |
| 08:09.20 | martin__ | you think that all maps to uart1? |
| 08:09.43 | ginge_ | I thought so at first, but there looks to be an offset in there |
| 08:09.58 | ginge_ | and uart1 still dies in a pool of vomit |
| 08:10.15 | martin__ | well |
| 08:10.27 | martin__ | hmm |
| 08:10.31 | martin__ | lemme look at the mappings |
| 08:14.22 | martin__ | hmm, yeah, looks like wince is using uart1 |
| 08:15.02 | martin__ | it has that 4a40e000 mapping |
| 08:15.20 | martin__ | and no equivalent small mappings for the other two uarts |
| 08:16.13 | ginge_ | yeah |
| 08:16.38 | martin__ | what version of haret are you using btw? |
| 08:17.37 | ginge_ | erm... latest I think. cant look right this second |
| 08:17.55 | martin__ | http://handhelds.org/~koconnor/haret/haret-20080613-swp3.exe is what you want for kaiser i think |
| 08:18.54 | martin__ | & if you use haretconsole you'll get some clearer decoding |
| 08:19.59 | ginge_ | haretconsole? I telnet in to get these dumps. Is that what you mean? |
| 08:20.16 | martin__ | no, there's a package called haretconsole |
| 08:20.30 | martin__ | that telnets in for you and parses the output a bit |
| 08:20.36 | ginge_ | ooo |
| 08:21.17 | martin__ | http://handhelds.org/~koconnor/haret/haretconsole-0.5.1.tar.gz |
| 08:21.33 | martin__ | unpack it and do ./console <ip address> |
| 08:21.45 | ginge_ | nice one, cheers. |
| 08:21.55 | martin__ | if you edit dis.py and set OBJDUMP to point to your arm-none-eabi-objdump |
| 08:22.08 | ginge_ | okay, so hciattach on the uart2 failed to initialise anything |
| 08:22.16 | martin__ | it'll do nice disassembly of the instructions too |
| 08:22.47 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 08:22.48 | martin__ | ginge_: there's going to be some options and also a firmware file to load |
| 08:23.03 | martin__ | but it really looks like the BT is on UART1 anyway |
| 08:23.44 | ginge_ | really really looks like it |
| 08:23.50 | martin__ | you saw traffic on your traces when you used the BT? |
| 08:24.09 | ginge_ | I havn't traced that yet |
| 08:24.11 | ginge_ | I will do it now |
| 08:24.26 | martin__ | what were you doing during the uart1.txt trace |
| 08:24.27 | martin__ | ? |
| 08:24.33 | ginge_ | switch bluetooth on |
| 08:24.45 | martin__ | okay, and it seemed to time with that? |
| 08:25.10 | ginge_ | yes. Nothing happened in the trace log until I clicked on bluetooth on |
| 08:25.25 | martin__ | okay, fine |
| 08:25.33 | martin__ | that's enough to convince me |
| 08:26.30 | martin__ | so at the moment you're working on getting the init sequences to match up? |
| 08:27.26 | ginge_ | yeah |
| 08:27.41 | ginge_ | even if I get them exactly the same, it still goes wrong |
| 08:27.50 | ginge_ | well, nearly exacltly the same |
| 08:27.57 | ginge_ | cr2 said it was dma |
| 08:28.04 | ginge_ | (i should be looking at) |
| 08:28.44 | ginge_ | ahh this is so much better to read now. |
| 08:30.09 | ginge_ | mmu dump show 0xa9a00000 is at address 0x4a40e000 the traces show matching registers at 0x4a40f000 any relevance |
| 08:32.21 | martin__ | the uart2 registers are at phys 0xa9b00000 which is a whole 1M above uart1 |
| 08:32.50 | martin__ | so it's not that |
| 08:38.10 | martin__ | haret gets exceptions trying to dump any of this stuff directly |
| 08:38.28 | martin__ | which is consistent with the read hangs linux was getting |
| 08:39.20 | ginge_ | http://headfuzz.co.uk/files/android/mmudump.txt |
| 08:39.55 | martin__ | yeah, i get the same |
| 08:40.13 | ginge_ | why does uart1 have a tiny 1k page? |
| 08:40.33 | martin__ | presumably that's what the wince driver maps to talk to it |
| 08:40.58 | martin__ | 4a40e000 is probably somewhere in the address space of the driver |
| 08:41.29 | ginge_ | it is in the bluetooth dll |
| 08:41.36 | martin__ | yup, bingo |
| 08:41.52 | ginge_ | but the writes are going to address + offset 0x1000 |
| 08:42.05 | martin__ | ah |
| 08:42.13 | martin__ | interesting |
| 08:42.17 | ginge_ | can you confirm that logic? |
| 08:42.36 | martin__ | do you have a new trace with haretconsole style output? |
| 08:42.59 | ginge_ | one mo |
| 08:45.05 | ginge_ | I didnt set up the object dump yet. Would you prefer that I did? |
| 08:46.01 | martin__ | might as well |
| 08:46.16 | martin__ | working on reproducing this myself too |
| 08:49.01 | ginge_ | how do I get arm-none-eabi-objdump |
| 08:49.39 | martin__ | it should be in the toolchain you're building the kernel with |
| 08:49.52 | *** join/#htc-linux okias (i=ejabberd@poseidon.kraja.cz) |
| 08:50.06 | ginge_ | apparently not |
| 08:50.20 | martin__ | what toolchain are you using? |
| 08:51.10 | ginge_ | um, the one off the kaiser install guide... |
| 08:51.34 | ginge_ | i think its called something else |
| 08:52.07 | ginge_ | arm-none-linux-gnueabi-objdump |
| 08:52.16 | martin__ | ah |
| 08:52.19 | martin__ | arm-2008q1/bin/arm-none-eabi-objdump |
| 08:52.33 | martin__ | you must have a different toolchain |
| 08:52.36 | ginge_ | arm-2008q1/bin/arm-none-linux-gnueabi-objdump |
| 08:52.56 | ginge_ | different build script by the looks of it |
| 08:52.58 | martin__ | yeah |
| 08:52.59 | ginge_ | oh well |
| 08:54.27 | martin__ | hmm |
| 08:54.30 | ginge_ | ok, got it |
| 08:54.40 | martin__ | what range did you mmutrace? I can't seem to get this |
| 08:55.04 | ginge_ | 0x4a40e000 0xc000 |
| 08:55.11 | ginge_ | seemed a big enough range to start with |
| 08:56.03 | martin__ | ah, was trying a 1k range |
| 08:56.10 | martin__ | probably haret doesn't like that |
| 08:56.42 | martin__ | yup, i get the same trace |
| 08:58.35 | ginge_ | http://headfuzz.co.uk/files/android/uartnew.txt if you want to compare |
| 09:00.04 | ginge_ | You will see in the trace these lines:- |
| 09:00.04 | ginge_ | 001.754 03fa195c: stmgeia r0!, {r3, r4} # 4a414000 =04ff3601001.754 03fa195c: stmgeia r0!, {r3, r4} # 4a414004 =003d0900which correspond to UART_MR1 and UART_MR2 functionality based on looking at the linux code |
| 09:00.15 | ginge_ | but notice how they are in different ranges again |
| 09:00.26 | martin__ | hmm |
| 09:00.35 | martin__ | i logged mine but the file is empty |
| 09:00.59 | ginge_ | I just set the terminal buffer to unlimited and directed through a redirect |
| 09:01.01 | martin__ | ah, no, it's witten now |
| 09:01.52 | martin__ | http://void.printf.net/~martin/bluetooth-init.txt |
| 09:02.04 | martin__ | feck |
| 09:02.19 | martin__ | that's not the decoded version |
| 09:02.45 | ginge_ | I see its the same output |
| 09:02.55 | ginge_ | pretty much line for line, if not exactly |
| 09:02.59 | martin__ | ah, you can pipe your raw dumps through dis.py |
| 09:03.05 | martin__ | would expect so |
| 09:04.17 | martin__ | it sure spends a lot of time writing ffffffff |
| 09:04.33 | martin__ | smells like shoddy coding |
| 09:04.38 | ginge_ | I have a feeling that is a red herring |
| 09:05.25 | martin__ | so, there is a bloody great offset isn't there |
| 09:06.58 | martin__ | hey |
| 09:07.04 | martin__ | hang on a minute |
| 09:07.30 | martin__ | these writes are way beyond the original 4a40e000 mapping |
| 09:07.36 | martin__ | that was only 1k size |
| 09:08.20 | martin__ | 4a40f000 must be a new mapping |
| 09:09.31 | ginge_ | I was just thinking the same |
| 09:09.31 | ginge_ | 4k offset |
| 09:09.31 | *** join/#htc-linux hagisbasheruk (n=hagisbas@78.148.135.168) |
| 09:09.59 | martin__ | so it's possible this new mapping actually points to a different uart |
| 09:10.13 | ginge_ | possibly. Like Uart2 :/ |
| 09:10.17 | martin__ | yup |
| 09:10.34 | ginge_ | which would mean it is working pretty well, just not talking bluetooth yet |
| 09:10.43 | martin__ | yeah |
| 09:10.44 | martin__ | hmm |
| 09:10.56 | martin__ | have you tried dumping the mmu with bluetooth on? |
| 09:11.05 | ginge_ | if you run mknod /dev/ttyMSM0 c 253 0 |
| 09:11.15 | ginge_ | you can talk to the device with hciattach |
| 09:11.24 | ginge_ | yeah I tried with on and off |
| 09:11.28 | martin__ | ok, will try that |
| 09:11.46 | martin__ | i've got the firmware file, it was lying around in the android emulator image! |
| 09:12.01 | ginge_ | !?! |
| 09:12.04 | martin__ | yeah |
| 09:12.15 | martin__ | clearly they just used stuff off their dev board |
| 09:12.57 | martin__ | which has the same bt |
| 09:13.21 | ginge_ | do you have a page detailing th halibut? |
| 09:13.30 | martin__ | no |
| 09:13.39 | martin__ | i know it's an msm7500a |
| 09:13.41 | *** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 09:15.02 | ginge_ | so... how do we use it |
| 09:15.55 | martin__ | i'll look into that |
| 09:16.26 | martin__ | just trying to work out where 0x4a40f000 maps |
| 09:16.30 | ginge_ | can you put it up somewhere? or point me to where it is in the sdk |
| 09:17.02 | *** join/#htc-linux mistadman (n=mistadma@adsl-156-124-98.msy.bellsouth.net) |
| 09:17.15 | martin__ | ginge_: it's /etc/firmware/brf6300.bin in their image |
| 09:18.25 | martin__ | and you need a version of hciattach that understands the TI type |
| 09:19.36 | martin__ | the HP ipaq hx4700 uses the brf6150 chip |
| 09:19.45 | martin__ | and that works in linux |
| 09:19.55 | martin__ | brf6150 firmware file is also in the android image |
| 09:20.14 | martin__ | might be some hciattach patches in their code or something |
| 09:21.40 | *** join/#htc-linux pH5 (n=ph5@p5485CE66.dip.t-dialin.net) |
| 09:23.57 | martin__ | http://handhelds.org/hypermail/hx4700-port/5/0525.html |
| 09:26.23 | ginge_ | http://gnulinux.biz/files/Universal/firmware/TIInit_3.2.26.bts |
| 09:26.36 | ginge_ | close enough? |
| 09:26.50 | martin__ | well, that's for 6150 |
| 09:26.58 | martin__ | and that's from 2005 |
| 09:27.07 | ginge_ | hmm |
| 09:27.20 | martin__ | the fact there's .bin files in the android image |
| 09:27.30 | martin__ | suggests that hciattach has been patched more cleanly |
| 09:27.36 | martin__ | to support a ti type |
| 09:27.40 | martin__ | with normal firmware loading |
| 09:28.48 | ginge_ | hmm |
| 09:29.11 | ginge_ | so I need to build an angstrom image |
| 09:29.36 | martin__ | with the firmware in, yeah |
| 09:30.22 | martin__ | google for hciattach-ti-bts.patch |
| 09:30.29 | martin__ | that was the original patch i think |
| 09:30.49 | martin__ | http://dev.openbossa.org/trac/mamona/browser/packages/bluez/bluez-utils-3.24/hciattach-ti-bts.patch?rev=6d921003cdfe14e7b23d3024baeb4890211294d6 |
| 09:31.32 | ginge_ | yeah, looks good |
| 09:32.06 | martin__ | like i said, think that's superseded now though |
| 09:33.29 | martin__ | yup, 'texas' is a supported type in recent bluez |
| 09:33.56 | martin__ | they just haven't updated the man page |
| 09:34.21 | martin__ | i think there's an hciattach already in the angstrom image |
| 09:34.23 | martin__ | which may be fine |
| 09:34.58 | ginge_ | trying now |
| 09:36.20 | ginge_ | initialisation timed out |
| 09:36.30 | martin__ | :( |
| 09:37.37 | pH5 | hi martin__, ginge_ |
| 09:37.39 | pH5 | are you saying hciattach will be superseded completely, or just the ti bts script upload? |
| 09:37.49 | pH5 | (and if so, do you know, by what?) |
| 09:38.13 | martin__ | The ti bts script thing (-S parameter) seems to have already been superseded by the 'texas' type |
| 09:38.37 | martin__ | the firmware files may just be the bts scripts from TI |
| 09:39.15 | martin__ | ginge_: what hciattach options did you use? |
| 09:39.28 | ginge_ | pH5: hi |
| 09:39.30 | ginge_ | I didn't turn on bluetooth before init. I will try again |
| 09:39.37 | ginge_ | /dev/ttyMSM0 texas 115200 |
| 09:40.00 | martin__ | hmm |
| 09:40.14 | martin__ | not sure if you really want bluetooth on already |
| 09:40.18 | martin__ | surely this should turn it on |
| 09:40.26 | martin__ | but probably there's a gpio somewhere that powers it up |
| 09:40.41 | ginge_ | you would hope so, but there is that register space in the wiki that has BT related next to it |
| 09:40.54 | martin__ | maybe we'll need to find that so we can turn it on in linux and have it in a fresh state for the hciattach |
| 09:41.29 | ginge_ | the windows mobile driver send reset twice to refresh the hardware, at least to the serial port portion |
| 09:41.54 | martin__ | yeah |
| 09:41.58 | martin__ | hmm |
| 09:42.05 | martin__ | we know where in the bluetooth dll that happens |
| 09:42.19 | martin__ | maybe we should disassemble that and see what else it does at the same time |
| 09:42.37 | ginge_ | souunds reasonable |
| 09:44.32 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 09:45.04 | martin__ | anyway, going to get some breakfast... |
| 09:45.17 | ginge_ | mmm breakfast. Good idea |
| 09:48.49 | martin__ | ginge_: try hciattach -n -s 115200 /dev/ttyMSM0 texas 115200 flow |
| 09:49.02 | martin__ | (from /etc/init.rc in the android image) |
| 09:49.43 | ginge_ | 4th time lucky booting zimage |
| 09:49.53 | ginge_ | the more code I cram into this kernel, the less it wants to boot |
| 09:59.42 | AstainHellbring | linux can be a bitchy thing some days |
| 10:21.01 | *** join/#htc-linux pH5_ (n=ph5@p5485CE66.dip.t-dialin.net) |
| 10:23.59 | ginge_ | martin__: Initialization timed out |
| 10:32.05 | *** join/#htc-linux gibi92 (n=bourgoin@obs92-2-82-230-37-168.fbx.proxad.net) |
| 10:33.03 | martin__ | ginge_: Bugger. |
| 10:33.50 | ginge_ | I miht try booting android, although I am not sure if it has bluetooth interface yet |
| 10:35.17 | martin__ | ginge_: I get the same result running that on an empty serial port on my PC |
| 10:35.31 | martin__ | it suggests there's just nothing there |
| 10:35.35 | martin__ | or that it's powered off |
| 10:37.57 | *** part/#htc-linux gibi92 (n=bourgoin@obs92-2-82-230-37-168.fbx.proxad.net) |
| 10:47.16 | *** join/#htc-linux dzo (n=dzo@121.98.128.127) |
| 10:48.57 | dzo | hi all |
| 11:07.20 | ginge_ | is there a guide to putting together an angstrom console image with the kaiser configs already inthere |
| 11:12.32 | okias | Hello, have any HTC device support for Wifi? |
| 11:38.06 | *** join/#htc-linux BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 11:38.54 | okias | *support for wifi under linux |
| 12:06.19 | par | universal for sure |
| 12:08.22 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 12:11.27 | mistadman | dcordes: Whats up? Did you ever get the phone working? |
| 12:13.34 | *** join/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com) |
| 12:13.47 | dcordes | mistadman: no |
| 12:13.53 | dcordes | what about athena? |
| 12:14.00 | mistadman | dcordes: Damn. |
| 12:14.23 | mistadman | dcordes: Well you have inspired me to write a phone driver for the Athena. |
| 12:14.37 | mistadman | dcordes: I have been hacking on it for a week now. |
| 12:15.07 | mistadman | dcordes: Good news is that is works! |
| 12:15.13 | dcordes | any success yet? |
| 12:15.16 | dcordes | wo |
| 12:15.23 | dcordes | congratulations |
| 12:15.42 | mistadman | dcordes: Bad news is I am fiddling around with getting the DPRAM to power up and reset. GPIO crap. |
| 12:16.10 | mistadman | dcordes: Once I get that figured it should be good to go. |
| 12:16.56 | mistadman | dcordes: cr2 said he was going to look in to it for me. I hope he has better luck than I had. |
| 12:18.47 | dcordes | ok good luck with that |
| 12:19.00 | mistadman | dcordes: Thanks! |
| 12:23.07 | *** join/#htc-linux pH5_ (n=ph5@p5485CE66.dip.t-dialin.net) |
| 12:26.33 | dcordes | okias: also blueangel |
| 12:27.05 | dcordes | martin__: ginge_ hi. next step is to disassemble bluetooth dll? |
| 12:27.16 | ginge_ | martin__: HaRET(2)# dump mmu 2 0xa0200000 (BT related) Virtual | Physical | Description | Flags address | address | | ----------+----------+-------------+------------------------ 4a40f000 | a0200000 | Tiny (1K) | AP=3 ?=80 91500000 | a0200000 | 1MB section | D=0 AP=1 ?=2000 b1500000 | a0200000 | 1MB section | D=0 AP=1 ?=2000 |
| 12:27.23 | ginge_ | see that address! |
| 12:28.32 | ginge_ | dcordes: yes, I think so |
| 12:28.43 | ginge_ | although I just found that elusive map |
| 12:28.53 | dcordes | ginge_: yes a0200000=BT related in memory map |
| 12:29.19 | ginge_ | we did some traces on bluetooth init before and got in a tangle working out the offsets |
| 12:30.40 | okias | dcordes: :-) but i can't find any info about blueangel wifi :-( |
| 12:31.48 | dcordes | ginge_, martin__: probably dzo did some work on the vogue uart/bluetooth already |
| 12:32.26 | dcordes | fwiw |
| 12:35.36 | cr2 | hi |
| 12:36.00 | cr2 | martin__: which dll is 0x03fa ? |
| 12:36.02 | mistadman | cr2: Sup! |
| 12:36.06 | cr2 | hi mistadman |
| 12:36.39 | mistadman | cr2: Did you get a chance to look into the DPRAM Power/Reset issue? |
| 12:37.05 | cr2 | no, i've just reached the computer. need to repair the car too ;) |
| 12:38.43 | mistadman | cr2: If you are as good with cars as you are with hardware, then it shouldnt be a problem for you. LOL! |
| 12:40.28 | cr2 | cars are also hardware ;) |
| 12:40.57 | dcordes | cr2: HaRET(2)# addr2mod 0x03fa0000 |
| 12:40.59 | mistadman | cr2: Point well taken. |
| 12:40.59 | dcordes | Unable to create tool help snapshot |
| 12:44.38 | dcordes | cr2: any idea what that error is about? |
| 12:58.47 | *** join/#htc-linux Othello (i=Magorium@gateway/tor/x-0082e6e3f161683c) |
| 13:07.25 | martin__ | ginge_: new idea! |
| 13:07.42 | ginge_ | martin__: oh? |
| 13:07.58 | martin__ | look on your wince filesystem for \Windows\TIInit_4_2_38.bts |
| 13:08.12 | martin__ | bts != firmware |
| 13:08.18 | martin__ | i think we need both |
| 13:08.27 | martin__ | and the bts is the same thing used by wince |
| 13:08.41 | martin__ | angstrom hciattach should have the bts support built in |
| 13:10.16 | martin__ | cook an initrd with that file in and try hciattach ttyMSM0 texas -S TIInit_4_2_38.bts |
| 13:13.07 | dcordes | martin__: cooking |
| 13:13.23 | martin__ | dcordes: you need your kernel patched to use uart2 |
| 13:13.49 | dcordes | I'll put the bluetooth stuff, miniterm, screen, cu |
| 13:14.42 | dcordes | bluez-utils-3.9? |
| 13:15.06 | dcordes | hciattach - attach serial devices via UART HCI to BlueZ stack |
| 13:15.09 | martin__ | not sure what version you need |
| 13:15.14 | dcordes | it's the latest |
| 13:15.16 | martin__ | k |
| 13:15.18 | dcordes | in OE# |
| 13:15.28 | martin__ | yeah, OE repository has this patch in |
| 13:15.32 | dcordes | want any extra stuff? |
| 13:15.37 | ginge_ | excellent can you make /dev/ttyMS0 mode 0777 and mknod c 253 0 |
| 13:15.50 | dcordes | I'll put a script in ~ |
| 13:16.02 | ginge_ | var/lock too because of cu |
| 13:16.44 | martin__ | then mix well and bake at 200 for 20 minutes |
| 13:16.55 | dcordes | I'd say 40 |
| 13:16.59 | dcordes | have to bake from scratch |
| 13:17.37 | martin__ | dcordes: can you include the brf6300.bin from the android image too |
| 13:17.41 | martin__ | in /etc/firmware |
| 13:17.47 | dcordes | yep |
| 13:18.02 | martin__ | excellent |
| 13:18.07 | martin__ | this is going to be tasty! |
| 13:18.37 | dcordes | you bet |
| 13:22.43 | cr2 | hehe. enough with the car for today. need a replacement part... |
| 13:23.02 | cr2 | dcordes: 03fa3870 |
| 13:24.31 | dcordes | HaRET(1)# addr2mod 0x03fa3870 |
| 13:24.32 | dcordes | Unable to create tool help snapshot |
| 13:24.52 | cr2 | martin__: can you check it ? |
| 13:24.57 | martin__ | stand by |
| 13:25.15 | cr2 | dcordes: you may have different firmware, so different addresses. |
| 13:25.39 | dcordes | cr2: radio rom a.k.a. amss? or bt firmware? |
| 13:26.22 | cr2 | wince rom |
| 13:26.26 | martin__ | HaRET(1)# addr2mod 0x03fa3870 |
| 13:26.27 | martin__ | Address 03fa3870 not process specific in module: coredll.dll (03f4e000 - 03fe4000) |
| 13:26.53 | martin__ | that's uk orange stock rom |
| 13:28.14 | martin__ | cr2: where did you get that address from? |
| 13:28.49 | dcordes | cr2: I'm on 'dutty's may 22nd' |
| 13:29.43 | cr2 | strange that it's coredll |
| 13:29.55 | cr2 | but the address looks like coredll |
| 13:30.06 | cr2 | martin__: from your BT startup. |
| 13:30.21 | martin__ | ah, right |
| 13:30.22 | cr2 | 001215: mmutrace 03fa3870: e8a31002(stmia) 4a413824 ffffffff (00000000) |
| 13:32.27 | marajin | huh.. when xmoo says the modem works under linux console, does he mean two way communication? |
| 13:33.10 | *** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 13:33.22 | cr2 | martin__: i think that all these smem offsets should be available through some other 0x1f* located structure. |
| 13:33.59 | martin__ | you're thinking they appear more than once in the physical map? |
| 13:34.09 | cr2 | APROC, QDSP, USBOTG, GPS |
| 13:34.40 | cr2 | no, but they should be referenced from some common place. |
| 13:35.02 | cr2 | because i don't see them hardcoded anywhere. |
| 13:35.49 | martin__ | hmm |
| 13:35.56 | martin__ | has anyone ever dumped the entire physical memory? |
| 13:36.01 | ginge_ | 0x9c000000 has some interesting stuff going on in there. What is that register range? |
| 13:37.16 | martin__ | it's down in the memory map wiki page as "ffffffff..." |
| 13:37.24 | cr2 | ginge_: kaisermemeorymap |
| 13:37.30 | martin__ | don't see it in msm_iomap.h |
| 13:37.37 | martin__ | what are you seeing there? |
| 13:37.55 | ginge_ | yeah, I see that, but I saw a reference to a board that uses that address for the dma (I think) for network card |
| 13:38.37 | martin__ | think it's being used for other dma stuff? |
| 13:38.47 | ginge_ | th thought has crossed my mind |
| 13:38.58 | martin__ | dump it and look for anything other than f's? |
| 13:39.00 | ginge_ | i was poking around there looking for my log registers |
| 13:39.13 | ginge_ | just recovering from a crash |
| 13:42.49 | dcordes | marajin: no |
| 13:43.40 | martin__ | cr2: what are you doing, disassembling wince dlls? |
| 13:46.13 | cr2 | martin__: no, looking at the diamond 0x1f dump |
| 13:46.29 | marajin | dcordes: So basically it mostly works the same under android and the console stuff anyway? |
| 13:47.03 | marajin | except that android isn't understanding gsm |
| 13:47.13 | martin__ | cr2: is that up somewhere? |
| 13:49.03 | dcordes | martin__: uuh yes |
| 13:49.38 | martin__ | dcordes: stop tab completing :) |
| 13:50.14 | dcordes | marajin: uuh yes. we wills tart caring about userland phone applications as soon as kernel level works |
| 13:50.32 | *** join/#htc-linux JEEB (n=kanakana@a88-114-192-27.elisa-laajakaista.fi) |
| 13:50.43 | marajin | dcordes: Yeah no worries, I was just wondering wtf Xmoo was talking about on the forum |
| 13:50.56 | martin__ | we can read from the modem |
| 13:50.59 | martin__ | just can't write |
| 13:51.03 | marajin | I know we can read from it |
| 13:51.11 | martin__ | maybe that's what he was refering to? |
| 13:51.13 | marajin | Xmoo's post just implied something else was doable |
| 13:51.15 | marajin | probably |
| 13:51.18 | marajin | it's just misleading |
| 13:51.54 | cr2 | martin__: what is 0xa0200000 1 BT related ? |
| 13:52.28 | martin__ | i don't know |
| 13:52.48 | martin__ | never looked at it and dunno why it's marked bt related |
| 13:53.16 | ginge_ | cr2: it is mapped into a virtual register 4k above the uart1 register and the bluetooth code writes to it |
| 13:54.35 | *** part/#htc-linux okias (i=ejabberd@poseidon.kraja.cz) |
| 13:55.51 | cr2 | martin__: http://wiki.xda-developers.com/index.php?pagename=DiamondMemoryMap |
| 13:56.21 | cr2 | martin__: looks like kaiser, but there is 1 difference -> 0xa5e00000 0x02000000 0x20 |
| 13:56.34 | martin__ | what chip is the diamond? |
| 13:56.36 | dcordes | cr2: pmic? |
| 13:56.49 | cr2 | but it may have been some debug card. |
| 13:56.58 | cr2 | don't know. |
| 13:57.46 | martin__ | cr2: could i see a pdump of the shared memory? |
| 13:57.58 | martin__ | would be useful to compare |
| 13:59.59 | cr2 | martin__: i guess you'd ask DesktopMa |
| 14:00.23 | martin__ | DesktopMM: ping |
| 14:01.06 | martin__ | Ah, MSM7201A. |
| 14:01.42 | martin__ | dcordes: how's that initrd doing? |
| 14:04.35 | *** join/#htc-linux Othello__ (i=Magorium@gateway/tor/x-8c60bc53b62f80aa) |
| 14:05.40 | cr2 | martin__: what is sku ? |
| 14:07.01 | martin__ | ? |
| 14:07.32 | martin__ | where? |
| 14:08.02 | cr2 | htc phones |
| 14:08.17 | cr2 | hehehe. mickeysoft goes security |
| 14:08.21 | cr2 | <PROTECTED> |
| 14:09.45 | martin__ | sku usually means some sort of product number |
| 14:10.32 | cr2 | ok |
| 14:11.57 | cr2 | RAPH300 |
| 14:12.05 | cr2 | what's that ? |
| 14:12.36 | cr2 | interesting. HTC_DrvEscape:LCD_REQUEST_PMEM... |
| 14:13.10 | marajin | RAPH300 is just the hardware design code from HTC I think |
| 14:13.20 | marajin | It's a raphael codename version 300 |
| 14:13.29 | Kevin21 | martin__: arm v6 processors don't have 1K pages. They changed the layout of the mmu table and haret doesn't know how to parse the new format. When you see 1k pages, you probably have a 4k page with a bunch of new flags set. |
| 14:13.43 | martin__ | Ahhhh. |
| 14:14.04 | martin__ | is there any chance of fixing that or is it all undocumented? |
| 14:14.25 | Kevin21 | martin__: So, top item on the "why don't traces work" list is not having all the virtual addresses. Since "dump mmu" doesn't work, there is a good chance you don't have all the addresses. |
| 14:14.45 | cr2 | hi Kevin21 |
| 14:14.46 | martin__ | dump mmu works, apart from there sometimes being 1k pages |
| 14:15.23 | Kevin21 | martin__: It is fully documented. However, it basically needs a rewrite of several of the mmu functions in haret. It'll take some time to do. |
| 14:15.25 | martin__ | but i guess some of those may actually be 4k pages pointing to smem that we're misreading |
| 14:15.42 | cr2 | Kevin21: mach-types update for haret needed. |
| 14:15.46 | cr2 | Trying to detect machine (Plat='PocketPC' OEM='HTC Touch Diamond P3700') |
| 14:15.46 | cr2 | Wince reports processor: core=MSM7201A-528MHz name=??? cat= vend=QUALCOMM |
| 14:15.48 | Kevin21 | martin__: It outputs misleading info. It isn't just the 1k pages either. |
| 14:15.53 | Kevin21 | cr2: Hi. |
| 14:16.02 | martin__ | Kevin21: Okay. |
| 14:16.06 | dcordes | martin__: there was a problem. had to remove already built stuff (tempdir) and now updating metadata |
| 14:16.21 | martin__ | dcordes: k |
| 14:17.04 | martin__ | Kevin21: let me know if I can do anything to help with it. We're pretty stuck on Kaiser without solid tracing so happy to do what I can to contribute to haret. |
| 14:17.40 | Kevin21 | cr2: Can you send a patch over? Do you want commit access to haret? |
| 14:17.50 | martin__ | I guess this'll be applicable to all the new devices coming out anyway... |
| 14:18.56 | cr2 | Kevin21: no, i don't have commit access. |
| 14:19.05 | marajin | man I oughta take a crash course in this shit, I can code but I have NFC about stuff this low-level |
| 14:19.49 | Kevin21 | martin__: The docs are in the ARM v6 guide available from the main arm site. Someone just needs to code it all up. |
| 14:19.57 | cr2 | martin__: does it say something to you -> |
| 14:20.01 | cr2 | smem_proc_comm_get_status |
| 14:20.01 | cr2 | smem_proc_comm_send_cmd |
| 14:20.01 | cr2 | smem_proc_comm_set_status |
| 14:20.39 | Kevin21 | cr2: Do you want commit access? I have no idea how to get it to you - I haven't been able to raise any of the admins at hh.org. However, I can setup a repo on linuxtogo.org. |
| 14:21.14 | martin__ | cr2: proc_comm is one of the smem channels between the a9 and a11 |
| 14:21.30 | martin__ | cr2: and gets used for various miscellaneous stuff |
| 14:21.35 | martin__ | as i understand it |
| 14:22.32 | martin__ | haven't really looked at it - it's just on the list as one more thing that'll hopefully work when we've figured out the smem writes |
| 14:22.39 | cr2 | %T{4=Dying,5=Dead,6=Buried,7=Slpg,39=Awak,0=Rung,1=Runab,2=RunBlkd,3=RunNeeds} |
| 14:22.50 | cr2 | Kevin21: ok, we should think about it. |
| 14:23.46 | martin__ | cr2: It's some sort of process management interface or the arm9 I think |
| 14:24.36 | cr2 | martin__: ok. |
| 14:25.02 | dcordes | proc_comm is an smem channel? |
| 14:25.55 | martin__ | Kevin21: Okay. If I get a chance I'll look through the current tracing code and see if I can make sense of it, then see what would have to change for arm6. |
| 14:26.19 | martin__ | dcordes: it uses the smem, I thought |
| 14:26.26 | martin__ | functions for it lying around the smd code |
| 14:26.31 | Kevin21 | martin__: I don't think there is any change needed to the tracing code. My understanding is that the change is in "dump mmu" and related "mmu" functions. |
| 14:26.43 | martin__ | dunno if it uses the same sort of channel |
| 14:26.49 | martin__ | Kevin21: ah, okay |
| 14:27.06 | dcordes | martin__: wasn't aware it has an own channel |
| 14:27.12 | martin__ | if it's just a matter of understanding the dump correctly that's probably a lot easier |
| 14:27.24 | dcordes | ok build started finally |
| 14:27.31 | dcordes | I hope it will get the bluetooth stuff right |
| 14:34.34 | Kevin21 | Seemy hermes died outright. I think I may have let the battery get too low. |
| 14:34.43 | Kevin21 | s/Seemy/Seems/ |
| 14:34.58 | martin__ | cr2: proc_comm is a mechanism for sending commands to the arm9 |
| 14:35.16 | martin__ | see arch/arm/mach-msm/proc_comm.h for a list of commands |
| 14:35.31 | martin__ | smd.c in the same directory for implementation on MSM7500A. |
| 14:35.42 | martin__ | basically you write the command to somewhere in shared memory |
| 14:35.59 | martin__ | and write a register somewhere to notify the ARM9 |
| 14:36.15 | martin__ | and when it's done it writes something back and you get an interrupt |
| 14:37.20 | martin__ | there's power control, nvram access, RTC stuff, battery checks, RPC stuff, and maybe some GPIOs out there too |
| 14:37.53 | martin__ | currently none of it works on vogue or kaiser |
| 14:38.11 | dcordes | not on vogue either? I thought dzo uses it |
| 14:38.26 | martin__ | int msm_proc_comm(unsigned cmd, unsigned *data1, unsigned *data2) |
| 14:38.27 | martin__ | { return -1; |
| 14:38.27 | martin__ | } |
| 14:38.33 | dcordes | he added vogue-hw.c which enables pm vibration |
| 14:38.38 | dcordes | and I think that uses proc comm |
| 14:38.42 | dcordes | martin__: where's that from? |
| 14:38.46 | martin__ | vogue-smd.c |
| 14:38.51 | dcordes | in our tree? |
| 14:38.53 | martin__ | yeah |
| 14:39.00 | martin__ | maybe he's done some new stuff since then |
| 14:39.04 | dcordes | that's not uptodate at all with dzo's stuffs |
| 14:39.07 | dcordes | yes |
| 14:39.07 | martin__ | k |
| 14:39.21 | dcordes | OTE: Running task 688 of 1776 |
| 14:39.28 | martin__ | it's probably a pretty easy thing for someone to get working |
| 14:39.43 | Kevin21 | Nope - my Hermes is okay - just needed to sit in the charger a bit longer. |
| 14:40.02 | martin__ | dcordes: if you want a project... |
| 14:40.18 | dcordes | martin__: http://it029000.massey.ac.nz/vogue/ dzo keeps his latest patches and builds there |
| 14:40.57 | dcordes | I tried enabling proc comm (just merged vogue-smd.c, vreg.c) |
| 14:41.02 | dcordes | didn't work |
| 14:44.25 | martin__ | won't do anything for a kaiser build |
| 14:44.37 | martin__ | you'd have to port changes over from vogue-smd to kaiser-smd |
| 14:46.11 | martin__ | anyway looks like all proc_comm stuff is still commented out in http://it029000.massey.ac.nz/vogue/diffs |
| 14:46.23 | dcordes | I put the vogue-smd stuff into kaiser-smd |
| 14:46.57 | dcordes | martin__: but what about the /arch/arm/mach-msm/clock.c |
| 14:47.10 | dcordes | file? there's a lot of proc changes |
| 14:47.25 | martin__ | yeah, they're all commenting out the msm_proc_comm calls |
| 14:47.32 | dcordes | oh ok |
| 14:48.17 | dcordes | so vogue-hw.c is not using proc_comm I assume then |
| 14:50.10 | dcordes | I wonder where it went in his latest patch |
| 14:50.37 | dcordes | it's in the Makefile but the file is not being created in that patch |
| 14:50.47 | martin__ | yeah i just saw that |
| 14:54.17 | dcordes | martin__: http://linuxtogo.org/~lgorris/somedzopatch.diff |
| 14:55.14 | *** join/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com) |
| 14:57.39 | dcordes | guess he modified vogue-hw.c but didn't re git-add it before he git-diffed |
| 14:58.28 | dcordes | task 837 of 1776 |
| 14:59.04 | martin__ | yeah, the vibrate stuff in vogue-hw uses msm_proc_comm |
| 14:59.16 | martin__ | so he's got at least the basics of it working |
| 14:59.37 | dcordes | but where are those basics taking place? |
| 14:59.44 | martin__ | the clock stuff is still commented out but that may only be good for halibut |
| 14:59.47 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 15:00.27 | martin__ | dcordes: msm_proc_comm() in vogue-smd.c |
| 15:04.41 | dcordes | martin__: that functions has two data and one command channel |
| 15:05.01 | dcordes | base+PC_COMMAND? |
| 15:05.52 | dcordes | is base=smem base? |
| 15:12.02 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 15:25.35 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 15:30.30 | dcordes | I'll be back when the build is done |
| 15:46.49 | cr2 | martin__: still here ? |
| 15:55.28 | *** join/#htc-linux Steiniii (i=Steiniii@cpe90-146-27-97.liwest.at) |
| 15:55.42 | Steiniii | hi community |
| 15:56.39 | Steiniii | what version works with my HTC BlueAngel? |
| 16:17.03 | marajin | heh |
| 16:17.08 | marajin | the joys of the build process |
| 16:26.08 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 16:28.18 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 16:37.05 | DesktopMa | off to work, back in a bit |
| 16:40.35 | dcordes | cr2: did you have some kaiser owner specific thing? |
| 16:45.48 | dcordes | build almost done |
| 16:46.31 | marajin | what're you building? seems to be taking a good while |
| 16:48.04 | dcordes | martin__: linuxtogo.org/~lgorris |
| 16:48.40 | dcordes | it's the image with cu screen bluez-utils but it's in tar.gz and doesn't have the firmware becfause I g2g quick later |
| 16:49.44 | marajin | Huh, but you've had it building forlike hours |
| 16:56.11 | martin__ | cd |
| 16:56.18 | martin__ | er, wrong terminal :) |
| 16:56.21 | martin__ | hey guys |
| 16:57.18 | martin__ | dcordes: will give that a try |
| 16:57.21 | martin__ | cheers |
| 17:02.12 | cr2 | martin__: http://wiki.xda-developers.com/index.php?pagename=DiamondMemoryMap |
| 17:03.44 | cr2 | dcordes: i've made a mistake and edited http://wiki.xda-developers.com/index.php?pagename=Kaiser_IRQ |
| 17:03.51 | cr2 | dcordes: have a look :) |
| 17:26.51 | *** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) |
| 17:27.47 | *** join/#htc-linux pikapika (n=pikapika@mar75-8-88-164-227-147.fbx.proxad.net) |
| 17:28.20 | pikapika | :) |
| 17:29.28 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 17:50.37 | *** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 17:52.25 | dcordes_ | martin__: dunno what went wrong but image is broken |
| 17:52.31 | dcordes_ | will fix in an hour when I'm home |
| 17:53.37 | martin__ | k |
| 17:54.16 | dcordes_ | martin__: did you look at kaiser irq upgrade? |
| 17:54.34 | dcordes_ | 1 is smd tx irq and 2 is smd rx irq according to it |
| 17:55.02 | dcordes_ | do we have it that way in the kaiser-smd.c? |
| 17:55.20 | martin__ | i wasn't sure if there were seperate irqs for each channel |
| 17:55.37 | martin__ | anyway, busy for a while... |
| 17:57.18 | dcordes_ | bbl |
| 18:12.08 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 18:46.30 | *** join/#htc-linux kiozen (n=oeichler@93.134.93.164) |
| 18:49.11 | *** join/#htc-linux Sliss__ (n=chatzill@250.110-65-87.adsl-dyn.isp.belgacom.be) |
| 19:01.38 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 19:20.17 | *** join/#htc-linux pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 19:24.44 | *** join/#htc-linux DesktopMa (n=DesktopM@c09EC653E.static.bluecom.no) |
| 19:55.43 | *** join/#htc-linux hagisbasheruk (n=hagisbas@78.148.135.168) |
| 20:20.20 | *** join/#htc-linux LunohoD_ (n=alex@e180072235.adsl.alicedsl.de) |
| 20:36.27 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfdbee.pool.einsundeins.de) |
| 20:45.57 | *** join/#htc-linux mistadman (n=mistadma@adsl-156-124-98.msy.bellsouth.net) |
| 20:50.16 | lama | http://youtube.com/watch?v=TeibTojapCg&feature=related (?) |
| 20:51.14 | *** join/#htc-linux BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 20:52.00 | *** join/#htc-linux BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 20:54.01 | Kevin21 | dcordes_ / martin__: I decided to take a look at armv6 mmu stuff. I should have something in a little while. |
| 20:55.30 | DesktopMa | lama: is that video made in the 80s? :P |
| 20:56.44 | lama | with VHS :P |
| 20:57.15 | *** join/#htc-linux AlGe (n=alge@chello080109231226.4.uni-klu.teleweb.at) |
| 20:58.42 | DesktopMa | indeed |
| 21:00.18 | cr2 | DesktopMa: http://wiki.xda-developers.com/index.php?pagename=DiamondMemoryMap |
| 21:01.14 | DesktopMa | looking good. wish I could help fill it out but I'm not entirely up to speed yet |
| 21:01.36 | cr2 | mistadman: .fifosize = 64, ? |
| 21:02.33 | cr2 | DesktopMa: i've added some useful data here http://wiki.xda-developers.com/index.php?pagename=Kaiser_IRQ |
| 21:03.01 | cr2 | DesktopMa: but it was a mistake. maybe it's wrong for kaiser :) |
| 21:03.55 | DesktopMa | hehe |
| 21:05.26 | mistadman | cr2: No thats the AT ctrl size. Fifos Tx 512/ Rx 512 |
| 21:05.44 | cr2 | 512 bytes |
| 21:06.50 | cr2 | mistadman: do you get the irqs ? |
| 21:06.56 | mistadman | cr2: Are looking at my code from yesterday? |
| 21:07.01 | cr2 | yes |
| 21:07.09 | mistadman | cr2: Yes. |
| 21:08.01 | mistadman | cr2: In the code I showed you it didnt define .fifosize. Why did you think it was 64? |
| 21:08.54 | mistadman | cr2: Here is the code again. There was an error in the last post: http://rafb.net/p/oCkQHS28.html |
| 21:09.39 | mistadman | http://rafb.net/p/TVIhUT17.html |
| 21:09.46 | cr2 | static struct uart_port dpram_port = { |
| 21:09.50 | cr2 | <PROTECTED> |
| 21:09.54 | cr2 | <PROTECTED> |
| 21:09.54 | cr2 | <PROTECTED> |
| 21:09.54 | cr2 | <PROTECTED> |
| 21:09.54 | cr2 | <PROTECTED> |
| 21:09.55 | cr2 | <PROTECTED> |
| 21:09.55 | cr2 | }; |
| 21:12.05 | cr2 | you register only 1 irq ? |
| 21:12.17 | mistadman | cr2: I didn't think it mattered. My code seem to run fine. I thought it was tty buffer definition. Didn't think it would matter to change unless it affected performance. |
| 21:12.47 | cr2 | dpram_remove() doesn't free the irq(s). |
| 21:13.13 | mistadman | cr2: Yeah just for AT: GPIO 51 00080000 DPR-AT I FE 1 |
| 21:13.48 | mistadman | cr2: Good point about dpram_remove(). |
| 21:14.13 | cr2 | there are more DPR-* irqs, but then you'd take care of the other registers too. |
| 21:14.21 | cr2 | control registers. |
| 21:14.48 | mistadman | cr2: Didnt catch that. Especially since I have never planed on unloading the driver. |
| 21:15.15 | mistadman | cr2: Yes |
| 21:15.22 | cr2 | ok. |
| 21:15.27 | mistadman | cr2: I was focusing on AT command for now |
| 21:15.38 | cr2 | yes. |
| 21:15.43 | cr2 | so this driver works ? |
| 21:16.24 | mistadman | cr2: Yes and no. I can see incomming calls comming thru |
| 21:16.39 | mistadman | cr2: ril doesnt respond though |
| 21:17.16 | mistadman | cr2: And I seem to not be able to send commands to the dpram. It doesnt respond. |
| 21:17.46 | mistadman | cr2: I also havent figured out the right GPIOs for reset or power. |
| 21:17.50 | cr2 | can you connect with 'cu' ? |
| 21:18.02 | mistadman | cr2: cu? |
| 21:18.32 | cr2 | yes |
| 21:18.50 | cr2 | does the dpram generate irqs ? |
| 21:18.54 | mistadman | cr2: Not sure what you mean... :-/ |
| 21:19.14 | mistadman | cr2: What is a cu? |
| 21:19.16 | cr2 | you have an irq handler. |
| 21:20.09 | cr2 | http://packages.debian.org/en/etch/cu |
| 21:20.58 | mistadman | cr2: I got it. No I was using the Android built in app. |
| 21:21.07 | mistadman | cr2: /etc/init.testmenu |
| 21:22.05 | mistadman | cr2: Base on my mmu trace, once the dpram is powered. It response with "Command Interpreter Reay" |
| 21:22.29 | mistadman | cr2: I was trying to get to the point where the dpram was init correctly. |
| 21:23.08 | cr2 | AT Command Interpreter Ready comes after successful reset. |
| 21:23.15 | cr2 | 1-3 sec |
| 21:24.40 | mistadman | cr2: Another reason I wanted to make sure the DPRAM was correctly initialized was because the 0x3fce register is not responding correctly based on my mmu trace. |
| 21:25.27 | mistadman | cr2: You are suppose to update it with the last buffer address used during tx. |
| 21:25.46 | mistadman | cr2: I believe it tells the DPRAM were to look for next command. |
| 21:26.01 | mistadman | cr2: When I write to it, it doent change. |
| 21:26.16 | mistadman | cr2: Everything else is perfect |
| 21:26.55 | mistadman | cr2: The 0x3fc6 register responds when the DPRAM is ready for next command. |
| 21:27.07 | mistadman | cr2: At least I think. |
| 21:27.39 | cr2 | hmm. i didn't look at rilgsm... |
| 21:27.46 | cr2 | ok. |
| 21:28.29 | mistadman | cr2: I think this is where dcordes is stuck. On the kaiser he can receive but not transmit. |
| 21:29.14 | mistadman | cr2: Does haret mess with any of the GPIOs or IRQs when boot in to the Linux Kernel? |
| 21:29.20 | mistadman | cr2: Because... |
| 21:30.04 | mistadman | cr2: If Windows Mobile initializes the hardware correctly, I would think it would work in linux. |
| 21:30.25 | DesktopMa | seems that way |
| 21:30.26 | mistadman | cr2: If this is the case then I may be missing something in my driver. |
| 21:30.38 | mistadman | cr2: Just not sure. |
| 21:30.40 | DesktopMa | since on some phones you can keep conversations going while rebooting into android :P |
| 21:30.56 | cr2 | you can't rely on wince anyway. |
| 21:31.18 | cr2 | the phone should be able to resume from sleep too |
| 21:31.31 | cr2 | hehe. ati resume ;) |
| 21:31.33 | mistadman | cr2: Am almost 100% sure my driver operates just like the MMU Trace. |
| 21:31.54 | mistadman | cr2: Unless haret is not showing me something... |
| 21:33.55 | *** join/#htc-linux pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au) |
| 21:35.17 | mistadman | I am switching over to my 3G card. I'll be right back... |
| 21:53.39 | *** join/#htc-linux dzo (n=dzo@121.98.128.127) |
| 22:03.56 | cr2 | hi dzo |
| 22:23.41 | Kevin2 | Anyone want to be a guinea pig? http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu.exe |
| 22:24.06 | Kevin2 | I coded up arm6 mmu table parsing purely from the spec - I can't test locally. |
| 22:25.34 | DesktopMa | can test it on diamond if you want |
| 22:25.56 | cr2 | DesktopMa: yes, you are the best candidate :) |
| 22:26.33 | DesktopMa | am I supposed to try to run something |
| 22:26.39 | DesktopMa | or just see what it says |
| 22:26.51 | cr2 | dump mmu |
| 22:27.32 | DesktopMa | and the mmu dump command is "dump mmu"? :P |
| 22:27.52 | cr2 | yes. |
| 22:28.06 | cr2 | you've already did it with the old haret. |
| 22:28.36 | DesktopMa | different pc so didn't have the txt file :P |
| 22:29.31 | DesktopMa | hmm no files created |
| 22:33.15 | cr2 | earlyharetlog.txt |
| 22:33.28 | cr2 | and add 'dump mmu' to default.txt |
| 22:33.31 | cr2 | boot :) |
| 22:33.47 | cr2 | i.e. Run with 'default.txt' |
| 22:36.25 | DesktopMa | right. www.auby.no/files/diamond/mmu.txt |
| 22:37.38 | cr2 | looks much better. |
| 22:37.45 | cr2 | Kevin2: ping |
| 22:39.11 | cr2 | Kevin2: APX XN and T probably need some help text in the header. |
| 22:40.31 | Kevin2 | cr2: pong |
| 22:40.49 | cr2 | 85900000 | 15000000 | 16MB section | CB AP=1 T=7 ?=100000 |
| 22:40.53 | cr2 | looks strange |
| 22:41.16 | cr2 | does v6 support 16MB pages ? |
| 22:41.59 | cr2 | somehting is broken here. |
| 22:42.00 | Kevin2 | Yes. And I think wince isn't programming it correct (hence the ?=) |
| 22:42.18 | cr2 | a6700000 | 02000000 | 16MB section | AP=1 T=7 ?=100000 |
| 22:42.18 | cr2 | a6800000 | 02000000 | 16MB section | AP=1 T=7 ?=200000 |
| 22:42.44 | cr2 | it's 1MB virtual offset |
| 22:43.20 | Kevin2 | Hrmm. That can't be right.. |
| 22:45.51 | Kevin2 | Yeah, it's a bug. |
| 22:49.33 | Kevin2 | Can you try: http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu2.exe |
| 22:50.06 | Kevin2 | cr2: Sure - I'll describe APX, XN, and T once someone describes them to me. :-) |
| 22:51.22 | DesktopMa | www.auby.no/files/diamond/mmu2.txt |
| 22:55.11 | Kevin2 | DesktopMa: Thanks. cr2 - how's it look? |
| 22:59.29 | *** join/#htc-linux hagisbasheruk (n=hagisbas@78.148.135.168) |
| 23:00.21 | Kevin2 | So, XN is no-execute, APX effectively means read-only (even from privileged mode), and T is TEX.. |
| 23:02.33 | cr2 | Kevin2: looks good now |
| 23:02.43 | cr2 | Kevin2: TEX =2 or 7 it seems |
| 23:18.57 | cr2 | mistadman: the phone/dpram power/reset are gpio85 and 2 cpld1 gpios. |
| 23:19.42 | cr2 | mistadman: and the pxa alt/dir/level settings for the irq gpios. |
| 23:23.32 | Kevin2 | http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu3.exe --- just improves the header and APX reporting. |
| 23:27.53 | DesktopMa | www.auby.no/files/diamond/mmu3.txt |
| 23:29.07 | cr2 | nG: Not-Global |
| 23:29.44 | *** join/#htc-linux marex (n=marex@85-132-216-250-eth3-gwfm10-user.802.cz) |
| 23:30.15 | cr2 | hm. wm9750 :) |
| 23:30.39 | marex | cr2, hello ... long time no se ;) |
| 23:31.05 | cr2 | :) |
| 23:31.07 | *** join/#htc-linux mistadman (n=mistadma@32.129.172.75) |
| 23:32.05 | cr2 | mistadman: dpram power understood. |
| 23:32.31 | mistadman | cr2: Cool. |
| 23:32.40 | cr2 | mistadman: btw, it should be possible to enable some debug dumping to rilgsm |
| 23:32.43 | mistadman | cr2: Now help me understand! LOL |
| 23:33.18 | mistadman | cr2: How does it work? |
| 23:35.16 | mistadman | cr2: Nevermind, looking thru IRC Logs now. BRB.. |
| 23:36.46 | cr2 | cpld(2,2)=1, msleep 10, gpio85=1, (it was power, now reset) , cpld(2,4)=1, msleep 400, cpld(2,4)=0, setup_all_dpram_pxairqs() |
| 23:36.52 | cr2 | for powerup. |
| 23:37.21 | mistadman | cr2: Man, how did you figure that out? Haret? |
| 23:37.29 | dzo | hi cr2 |
| 23:38.07 | cr2 | cpld(2,4)=1, msleep 400, cpld(2,4)=0, msleep 10, gpio85=0, cpld(2,2)=0 |
| 23:38.09 | *** join/#htc-linux ali1234 (n=al@62.24.214.38) |
| 23:38.11 | cr2 | for powerdown. |
| 23:38.23 | cr2 | no. it's from rilgsm |
| 23:38.46 | dzo | Got my vogue working fairly well now, been using it as a phone for a few days running android. |
| 23:39.03 | cr2 | you also need to "unsetup" the pxa irq gpios on dpram release. |
| 23:39.11 | cr2 | dzo: nice. |
| 23:39.28 | mistadman | cr2: Ok, will do. |
| 23:39.50 | cr2 | dzo: i've added the diamond irq descriptions to kaiser ;) are they the same on vogue ? |
| 23:39.56 | mistadman | cr2: Did you reverse engineer rilgsm on WM? |
| 23:40.07 | cr2 | dzo: http://wiki.xda-developers.com/index.php?pagename=Kaiser_IRQ |
| 23:40.14 | cr2 | mistadman: yes. |
| 23:40.30 | mistadman | cr2: What tools did you use? |
| 23:40.30 | dzo | anybody got SD working on msm, it doesn't seem to generate interrupts. yes, IRQs are very similar. |
| 23:40.31 | cr2 | mistadman: you must be new in this field ? :D |
| 23:41.01 | cr2 | dzo: and the M2A irqs ? |
| 23:41.22 | mistadman | cr2: Yes. but I have done reverse engineering, just not on an ARM Platform. |
| 23:41.26 | dzo | i just changed irq 6 on the wiki, I know how this works, its for proc_comm. |
| 23:42.01 | mistadman | cr2: But I am a fast learner. ;-) |
| 23:42.11 | dzo | A11 writes to SMEM then waits for irq6 from A9. |
| 23:42.13 | cr2 | dzo: DEX in my books |
| 23:42.17 | dcordes | dzo: are all the items in front of the bracket controlled through proc_comm? |
| 23:42.30 | dzo | yes, thats the wince name for it. |
| 23:43.11 | cr2 | mistadman: i have an old _licensed_ version on ida |
| 23:43.15 | dzo | yes and more, battery status, audio path, charging. |
| 23:43.17 | cr2 | s/on /of / |
| 23:43.39 | mistadman | cr2: Ok, thats what I need to know. |
| 23:43.50 | dcordes | dzo: also backlight and display power? |
| 23:43.58 | cr2 | dzo: what about pmic ? |
| 23:44.29 | mistadman | cr2: And run it directly from the target platform (the pda)? |
| 23:45.03 | dzo | no backlight is in MSM_CLK_CTL on vogue, I added it to the Titan memory map wiki. |
| 23:45.17 | cr2 | mistadman: no, i've dissected the rom. |
| 23:46.05 | dzo | its CLK_CTL+0x54 and 0x58. |
| 23:46.06 | cr2 | mistadman: you can't debug the kernel on the target with ida. my 4.8 version can't do target debugging even for the user apps. |
| 23:46.36 | cr2 | dzo: should be the same on kaiser i guess. |
| 23:46.40 | mistadman | cr2: And you can load rom images/parts/DLLs in to Ida? |
| 23:46.53 | dcordes | dzo: cr2 clock control is same on kaiser as on vogue? |
| 23:47.40 | DesktopMa | do phones with the same chipset map registers differently? or only for other io not supplied by the chipset |
| 23:47.44 | cr2 | +0x58 orr 0x100. bkl ? |
| 23:47.50 | mistadman | cr2: One last stupid question. Is there an api for accessing CPLDs? |
| 23:47.51 | dzo | pmi is done by proc_comm and also another mechanism called smsm_proc_comm in the android kernel that allows power collapse. |
| 23:48.33 | cr2 | mistadman: yes, it's already implemented in the athena code. |
| 23:48.37 | dzo | cr2: yes and the 12 lsbs of 0x58 do brightness. |
| 23:48.47 | *** join/#htc-linux marex (n=marex@85-132-216-250-eth3-gwfm10-user.802.cz) |
| 23:48.58 | dzo | s/0x58/0x54/ |
| 23:49.06 | cr2 | dzo: ok. |
| 23:49.12 | marex | cr2, hi, btw j/w is there any tool for operating with msm devices under linux ? |
| 23:49.19 | dcordes | cr2: do you put that in wiki? |
| 23:49.28 | marex | cr2, I want to tinker a bit with msm6250 based device |
| 23:49.32 | cr2 | dzo: do the SD CLK bits match ? |
| 23:49.48 | marex | cr2, so ... is there any flasher for msm7200 based devices that runs under linux ? |
| 23:49.55 | cr2 | marajin: msm6250 is the phone on universal |
| 23:50.10 | cr2 | marex: msm6250 is the phone on universal |
| 23:50.17 | marex | cr2, msm6250 is also core cpu of siemens SXG75 ;) |
| 23:50.26 | marex | the software runs on that ... |
| 23:50.35 | cr2 | marex: the only linux flasher that works is for hermes. afair. |
| 23:50.35 | dzo | to completely switch off the display you have to do some proc_comm stuff, disable the mdp and mddi clocks and set some remote MDDI registers. |
| 23:50.48 | marex | cr2, can you point me at it ? |
| 23:51.13 | marex | hmm ... that's samsung based |
| 23:51.19 | marex | probably no use for me |
| 23:51.20 | cr2 | marex: there was a guy who wanted to work on sxg75. he posted some interesting links to modaco. |
| 23:51.59 | cr2 | marex: the msm6250 phone rom for universal is decoded, but it's a PITA. |
| 23:51.59 | marex | cr2, do you have irc history or the links ? |
| 23:52.10 | marex | I see ... :S |
| 23:52.32 | *** part/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com) |
| 23:52.32 | marex | I never wrote cpu support before though :p |
| 23:53.08 | cr2 | dzo: the MDDI regs are panel dependent, but it should be relatively easy given some patience to document it to a better extent than what i've done so far. |
| 23:53.27 | dzo | there are at least 3 SD clocks all controlled differently as far as I can see. A0 and A4 are the host clock , enabled by bit 7 in 00 (from memory) |
| 23:54.21 | dcordes | dumping kaiser mmu.. |
| 23:54.23 | cr2 | ok. |
| 23:54.32 | cr2 | dcordes: good. |
| 23:54.52 | cr2 | dzo: btw, haret supports armv6 mmu decoding now. |
| 23:55.52 | dzo | cr2: yes, I just turn off the backlight for now, how much power would it save to do it properly, there is a really useful proc_comm call that tells you the current in and out of the battery. seems to me that the radio uses so much power that little things on the A11 side won't make much difference. |
| 23:56.29 | dzo | did it not before? |
| 23:57.10 | dzo | tracing LDM and STM is really useful on the latest haret, thanks kevin. |
| 23:57.15 | cr2 | dzo: the map attributes were wrong before. now it knows about TEX, APX & co. |
| 23:57.43 | dzo | thats good, does kaiser trace OK now. |
| 23:58.28 | cr2 | mistadman: do you have gps and bt working ? |
| 23:58.30 | dzo | kaiser people should be tracing MSM_CSR to find the A2M locations for SMEM buffers. |
| 23:58.53 | dcordes | martin__: new console image done. only need the firmware now. what's the filenames we need? |