| 00:02.52 | mdrobnak | ali1234, you here? |
| 00:02.59 | ali1234 | hi |
| 00:03.25 | mdrobnak | So it sounds like you have some ideas :-) |
| 00:03.42 | ali1234 | sure. |
| 00:03.49 | ali1234 | LOADS |
| 00:04.13 | mdrobnak | LOL |
| 00:04.15 | ali1234 | the first one is to try only using the upper bank |
| 00:04.32 | mdrobnak | Don't remember if I tried that one. |
| 00:05.27 | ali1234 | mi->bank[0].start = PAGE_ALIGN(PHYS_OFFSET+0x10000000); |
| 00:05.27 | ali1234 | mi->bank[0].node = PHYS_TO_NID(mi->bank[0].start); |
| 00:05.27 | ali1234 | mi->bank[0].size = (128 * 1024 * 1024); |
| 00:05.29 | mdrobnak | So am I modifying the fixup? |
| 00:05.36 | mdrobnak | I'll take that as a yes. |
| 00:05.37 | mdrobnak | :-) |
| 00:05.38 | ali1234 | and dont enable bank[1] at all |
| 00:06.29 | *** join/#htc-linux nozze (n=nozze@u193-11-162-41.studentnatet.se) |
| 00:06.56 | ali1234 | the second one is to put more debugging into pmem.c to see where exactly it is actually triggering the crash |
| 00:07.17 | mdrobnak | I enabled that small amount of debug to get as much as I did.. |
| 00:07.43 | ali1234 | the third one is to disable the OOM killer and really test out the memory banks |
| 00:08.08 | mdrobnak | Also, building my own copy of Android had no difference, it was using the generic Software OpenGL, and that crashed.. |
| 00:08.16 | ali1234 | yes |
| 00:08.22 | ali1234 | the problem is in the pmem driver somehow |
| 00:08.23 | mdrobnak | so it's definitely a mapping issue either in pmem or some reserved area |
| 00:08.25 | ali1234 | i'm sure of that |
| 00:08.37 | ali1234 | but looking at it i can't see a reason why it crashes |
| 00:08.54 | ali1234 | it doesn't touch anything inside what you have mapped as general memory |
| 00:09.01 | ali1234 | at least it isn't supposed to |
| 00:09.24 | mdrobnak | heh |
| 00:09.29 | mdrobnak | *supposed to* |
| 00:09.33 | ali1234 | yeah |
| 00:09.55 | ali1234 | all i can think is that it can;t grab a big enough uninterrupted stretch of virtual memory to map into |
| 00:10.22 | ali1234 | the thing is pmem only does it's mapping when the pmem device is opened |
| 00:10.29 | ali1234 | that's why it only crashes when android starts using the pmem |
| 00:10.48 | ali1234 | so you could maybe write a small test program to exercise pmem rather than booting all of android |
| 00:10.55 | ali1234 | that's idea number 4 |
| 00:11.23 | ali1234 | actually 'cat /dev/pmem' might be enough to crash it (or whatever the device node is called) |
| 00:12.24 | mdrobnak | Ok, with the rest of the #defines at the default, it does not boot with the 128MB bank only. |
| 00:12.48 | mdrobnak | I think I *did* try that. |
| 00:13.29 | mdrobnak | That's because MSM_LINUX_BASE is at 0x100000 |
| 00:13.54 | mdrobnak | Or.. |
| 00:14.29 | ali1234 | try changing it to 0x2000000 |
| 00:14.33 | ali1234 | 0x20000000 |
| 00:14.49 | ali1234 | then you'll have to change the bank size to 89 |
| 00:15.08 | *** join/#htc-linux thedicemaster (n=thedicem@j89051.upc-j.chello.nl) |
| 00:15.29 | ali1234 | how it works is you have a ram bank at 0x10000000 which is 128mb |
| 00:15.57 | ali1234 | up to 0x15900000 is general purpose, and after that is reserved and shared with the FB/DSP etc |
| 00:16.07 | ali1234 | and that region is accessed through pmem |
| 00:16.35 | mdrobnak | So here's my confusion.. |
| 00:16.42 | ali1234 | 0x59 being 89mb |
| 00:16.56 | ali1234 | then pmem operates within the rest |
| 00:17.25 | mdrobnak | On the RaphaelMemoryMap page, it looks like 2 banks...1 of 9xMB and the other is 128MB which total is around 220MB... |
| 00:18.02 | mdrobnak | Ok, so yeah, we're on the same page, sorry. |
| 00:18.04 | mdrobnak | took me a sec. |
| 00:18.29 | ali1234 | you have (in theory) 0x10000000 to 0x15900000 (which is 89 * 1024 *1024 bytes) and 0x20000000 to 0x28000000 (128mb) |
| 00:18.49 | ali1234 | and 0x15900000 to 0x18000000 is where pmem is operating |
| 00:19.03 | ali1234 | the defines in board-raphael.h set all that up |
| 00:19.10 | ali1234 | so try playing around with those |
| 00:19.18 | ali1234 | but i suspect the pmem areas are fixed in hardware |
| 00:19.50 | ali1234 | but since there is no overlap at all between pmem and general memory, i can't see a reason why you cant use only the upper bank |
| 00:20.41 | ali1234 | all pmem does is give you a memory mapped file representing a block of physical ram - exactly like /dev/mem does, except limited to some small fixed regions |
| 00:20.47 | ali1234 | at least that's what i understand |
| 00:20.58 | *** join/#htc-linux rashire2 (n=ed1112wa@pool-98-114-209-5.phlapa.fios.verizon.net) |
| 00:21.06 | ali1234 | i hope this is making sense to you |
| 00:21.28 | mdrobnak | It does for the most part. |
| 00:22.10 | mdrobnak | I'm just having fun with device connectivity :-) |
| 00:23.09 | ali1234 | hmm... so it doesn't boot at all with only the upper bank selected? |
| 00:23.24 | ali1234 | maybe the upper bank is not a full 128 mb like the lower one |
| 00:23.28 | mdrobnak | Nope, still not working. |
| 00:23.39 | mdrobnak | Unless I screwed something up. |
| 00:23.40 | mdrobnak | one sec |
| 00:23.42 | ali1234 | try just the upper bank, but set the size to 64mb |
| 00:24.43 | mdrobnak | Crap. I updated the .h but not the .c for 89MB |
| 00:24.49 | ali1234 | the h? |
| 00:24.55 | ali1234 | you shouldn't need to touch that |
| 00:25.35 | mdrobnak | #define MSM_EBI_BASE 0x20000000 |
| 00:25.35 | mdrobnak | #define MSM_EBI_SIZE 0x5900000 |
| 00:25.50 | ali1234 | yeah, leave those exactly as they were before |
| 00:25.55 | mdrobnak | #define MSM_LINUX_BASE MSM_EBI_BASE |
| 00:25.55 | mdrobnak | #define MSM_LINUX_SIZE 0x5900000 |
| 00:25.57 | ali1234 | we dont want to move the pmem |
| 00:26.10 | mdrobnak | Well, that was 0x1000000, not 20 |
| 00:26.14 | ali1234 | right |
| 00:26.32 | ali1234 | they only affect the pmem mapping i think |
| 00:26.46 | mdrobnak | hmm. |
| 00:27.07 | ali1234 | i dont think MSM_LINUX_BASE is used outside that file even |
| 00:27.19 | ali1234 | it's just used to say "pmem is after this much general ram" |
| 00:27.47 | ali1234 | really it should be used in the .c file to set the size of bank 0 |
| 00:27.55 | ali1234 | but for our experiemtn, just leave it at 0x10000000 |
| 00:28.16 | mdrobnak | ok. |
| 00:29.18 | mdrobnak | <PROTECTED> |
| 00:29.18 | mdrobnak | <PROTECTED> |
| 00:29.18 | mdrobnak | <PROTECTED> |
| 00:29.23 | mdrobnak | So that's the only change for now. |
| 00:33.10 | ali1234 | no make it 128 :) |
| 00:33.28 | mdrobnak | That's what I did the first time, and it didn't boot. |
| 00:33.37 | ali1234 | hmm |
| 00:33.45 | ali1234 | ok, in that case try 64 |
| 00:33.49 | ali1234 | to be safe |
| 00:33.59 | ali1234 | it might be even smaller than the other one |
| 00:34.55 | mdrobnak | The device is supposed to have 288MBs..' |
| 00:35.04 | ali1234 | it's just a test... |
| 00:35.29 | ali1234 | 288mb doesnt make much sense |
| 00:35.34 | ali1234 | 256 + 32? |
| 00:35.54 | ali1234 | 32 is the proc_comm at 0x0, not general purpose |
| 00:36.02 | ali1234 | then there's the two 128mb banks |
| 00:36.12 | ali1234 | of which one is 89mb + pmem |
| 00:36.21 | ali1234 | and the other is shared with god knows what :) |
| 00:36.24 | mdrobnak | heh |
| 00:36.33 | mdrobnak | yeah I always thought 288 was a odd # |
| 00:38.07 | mdrobnak | getting windows mobile to connect in ubuntu is a pain in the butt |
| 00:38.13 | ali1234 | it sure is |
| 00:38.17 | ali1234 | i dont even bother |
| 00:38.38 | ali1234 | just put kernel on sd card :) |
| 00:40.23 | ali1234 | the point of the tests is to narrow down what the real problem is |
| 00:40.41 | mdrobnak | Does not boot with 89MB. |
| 00:40.52 | ali1234 | hmm |
| 00:41.03 | ali1234 | ok |
| 00:41.17 | mdrobnak | Doesn't even go to the console. It freezes at Go Go Go |
| 00:41.17 | ali1234 | how about if you make bank 0 have only 1mb and bank 1 be 128mb |
| 00:41.32 | ali1234 | ah i think i know why |
| 00:41.35 | mdrobnak | (none so far have passed that point) |
| 00:41.46 | ali1234 | kernel is in bank 0 by bootloader |
| 00:41.53 | ali1234 | so kernel cant run itself |
| 00:42.09 | mdrobnak | OH DUH |
| 00:42.11 | ali1234 | try making bank 0 be small, eg 16mb, and bank 1 128mb |
| 00:42.23 | mdrobnak | No, I can change the ram addr to be 0x20000 instead of 10.. |
| 00:42.33 | ali1234 | it might not run properly if oyu do that |
| 00:42.41 | ali1234 | it might expect to be at 0x10000000 |
| 00:43.05 | mdrobnak | Well, if we do that, we're in the exact same situation again of two split banks. |
| 00:43.11 | ali1234 | right |
| 00:43.24 | mdrobnak | I'm going to try 20 firs |
| 00:43.25 | ali1234 | at the moment i have several theories of what is happening |
| 00:44.59 | mdrobnak | I have noticed windows takes longer to boot since I'm messing with this stuff |
| 00:45.18 | ali1234 | yes i get that too |
| 00:45.18 | ali1234 | seems to help if you remove the sd card |
| 00:45.26 | ali1234 | of course i use totally different hardware :) |
| 00:45.32 | mdrobnak | what are you using? |
| 00:45.41 | ali1234 | wizard/omap |
| 00:45.48 | ali1234 | it has nothing like this crazy stuff :) |
| 00:45.56 | ali1234 | but it only has 64mb anyway |
| 00:46.09 | ali1234 | and no crazy proc_comm |
| 00:46.18 | mdrobnak | Oh, the 8125. |
| 00:46.21 | mdrobnak | That's a good phone. |
| 00:46.45 | ali1234 | from what i have seen, the TI architecture is a lot nicer than MSM |
| 00:46.58 | ali1234 | to program for, anyway |
| 00:47.06 | mdrobnak | The MSM architecture gets no love from the devs, lets put it that way lol |
| 00:47.49 | ali1234 | have oyu ever tried making both banks 89mb? |
| 00:49.15 | mdrobnak | NO |
| 00:49.18 | mdrobnak | sorry |
| 00:49.19 | mdrobnak | nope |
| 00:49.31 | ali1234 | that would be the last thing to try here i guess |
| 00:49.36 | ali1234 | before we move on to idea 2 |
| 00:51.03 | mdrobnak | UGH |
| 00:51.09 | mdrobnak | It's not showing up as a drive now |
| 00:51.17 | mdrobnak | I want to throw it across the room |
| 00:51.18 | mdrobnak | lol |
| 00:51.22 | ali1234 | here's a tip |
| 00:51.30 | ali1234 | there's a little ftp server for WM |
| 00:51.34 | mdrobnak | This is what makes it so frustrating - this is not developing code on a pc and debugging, it's MUCH MUCH harder. |
| 00:51.40 | mdrobnak | really? |
| 00:51.44 | ali1234 | connect on wifi and upload kernel that way |
| 00:51.46 | mdrobnak | What's the name? |
| 00:51.48 | ali1234 | it never fails |
| 00:51.50 | mdrobnak | Yes, that sounds like a good idea. |
| 00:51.55 | ali1234 | hmm i forget |
| 00:52.00 | ali1234 | it's made by some japanese guy |
| 00:52.02 | ali1234 | hang on |
| 00:52.28 | ali1234 | i used to use it all the way back to ce 3.0 |
| 00:52.34 | ali1234 | still works fine on WM |
| 00:52.52 | ali1234 | maybe i have it on a cd somewhere... hang on |
| 00:53.41 | mdrobnak | heheh |
| 00:53.58 | mdrobnak | http://www.mochasoft.dk/freeware/ftpd.htm ? |
| 00:55.16 | ali1234 | thats not the one i used but sure |
| 00:55.20 | ali1234 | whatever works |
| 00:55.43 | mdrobnak | Well, it's only in exe so far.. |
| 00:55.47 | mdrobnak | which is useless in Ubuntu |
| 00:55.47 | mdrobnak | lol |
| 00:55.56 | ali1234 | wine |
| 00:56.00 | ali1234 | but hang on |
| 00:56.04 | ali1234 | found the cd i think |
| 00:56.23 | mdrobnak | Found |
| 00:57.57 | ali1234 | http://hp.vector.co.jp/authors/VA002682/ftpd52d.exe |
| 00:58.00 | ali1234 | i think that's it |
| 00:58.06 | ali1234 | also exe |
| 00:58.22 | ali1234 | but it may well be a windows ce exe :) |
| 00:58.48 | *** join/#htc-linux LTxda (n=anon@unaffiliated/ltxda) [NETSPLIT VICTIM] |
| 00:58.48 | *** join/#htc-linux furtardo (n=mks@nat/yahoo/x-ecrqseykaxwnrjfl) [NETSPLIT VICTIM] |
| 00:58.48 | *** join/#htc-linux mickey_away (i=mickey@openmoko/coreteam/mickey) |
| 00:58.55 | mdrobnak | hehe |
| 00:59.40 | ali1234 | wait that's a windows server |
| 00:59.46 | ali1234 | lol, not the one |
| 01:00.08 | ali1234 | http://www.oohito.com/wince/arm_j.htm |
| 01:00.24 | ali1234 | that's the real one, i remember the name eiichiro ito |
| 01:02.03 | ali1234 | it's a zip, you can download it straight onto the device :) |
| 01:02.14 | mdrobnak | This one works OK. |
| 01:02.18 | mdrobnak | It looks so funny |
| 01:02.21 | mdrobnak | cause it's from PPC 2003 |
| 01:03.08 | ali1234 | (this is why i suggested tftp support for haret btw) |
| 01:03.22 | ali1234 | but then i realised i dont even know how to compile haret, much less hack on it |
| 01:04.29 | mdrobnak | heh |
| 01:04.57 | mdrobnak | Well, that didn't work. |
| 01:05.20 | mdrobnak | So tell me what your other ideas are |
| 01:05.56 | ali1234 | still crashed like before? |
| 01:06.17 | ali1234 | ok so the next step is to drill down through pmem and see where it is actually crashing |
| 01:06.19 | mdrobnak | Yeah, I see half the screen, half black |
| 01:06.32 | ali1234 | more interested in dmesg really |
| 01:07.35 | mdrobnak | well lets see if there is anything there |
| 01:07.39 | *** join/#htc-linux tmzt (n=tmzt@adsl-99-52-65-233.dsl.akrnoh.sbcglobal.net) |
| 01:08.29 | ali1234 | anyway, i'd like to know if you can cause the crash without loading android |
| 01:09.05 | mdrobnak | well I dont know of anything else using pmem.,. |
| 01:09.48 | ali1234 | there should be a pmem device in /dev (maybe four of them depending how it works) |
| 01:10.44 | *** join/#htc-linux marcin88 (n=marcin@chello089078160132.chello.pl) |
| 01:11.01 | mdrobnak | Getting dmesg now |
| 01:11.36 | ali1234 | do you have a shell on the device? |
| 01:12.32 | mdrobnak | Yeah. Just need to swap the root image. |
| 01:13.56 | mdrobnak | Nope, this dmesg is from this morning. |
| 01:14.16 | mdrobnak | <PROTECTED> |
| 01:14.55 | ali1234 | hmm.. meaning what? |
| 01:16.15 | mdrobnak | That compile was from this morning. |
| 01:16.19 | mdrobnak | It didn't even boot the kernel. |
| 01:17.08 | ali1234 | with 89+89? |
| 01:17.41 | mdrobnak | No, just the upper bank of 89. |
| 01:17.44 | mdrobnak | You wanted 89+89? |
| 01:18.10 | ali1234 | right |
| 01:18.17 | ali1234 | try 89+89, then we give up on this |
| 01:18.29 | ali1234 | unless that works, which changes everything |
| 01:18.44 | ali1234 | or be conservative, do 89+64 |
| 01:18.51 | mdrobnak | It'll boot, but crash. |
| 01:18.55 | mdrobnak | Both will. |
| 01:18.57 | ali1234 | right |
| 01:19.07 | ali1234 | if you're sure about that, then no need to try it |
| 01:19.17 | ali1234 | so, the next thing is messing with pmem |
| 01:19.59 | mdrobnak | ftp is so much easier |
| 01:19.59 | mdrobnak | lol |
| 01:20.53 | mdrobnak | 89+89 boots |
| 01:21.04 | ali1234 | does it crash at android? |
| 01:21.18 | ali1234 | or if you are on shell, can you crash it by messing with the pmem device? |
| 01:21.30 | mdrobnak | crahsed at android |
| 01:21.42 | mdrobnak | Should reboot in a moment. |
| 01:21.57 | mdrobnak | I'm looking at pmem, nothing looks crazy. |
| 01:22.12 | ali1234 | pmem.c? |
| 01:22.58 | mdrobnak | yeah |
| 01:23.04 | mdrobnak | didnt reboot, had to hit it |
| 01:23.30 | ali1234 | that's different? |
| 01:23.57 | ali1234 | pastebin dmesg from that please |
| 01:24.08 | ali1234 | if you can get it to do anything different to usual i want to see dmesg :) |
| 01:26.38 | mdrobnak | getting dmesg |
| 01:26.49 | mdrobnak | well, I've had it go both ways |
| 01:27.02 | mdrobnak | sometimes it reboots on its own, sometimes not. |
| 01:27.58 | mdrobnak | still going |
| 01:28.02 | mdrobnak | done |
| 01:30.01 | mdrobnak | [ 17.023590] [RR] send control message cmd=7 srv.cmd=7 prog=00000001:d2dcfb60 id=-752902312:c0164318 |
| 01:30.01 | mdrobnak | [ 31.225646] [drivers/misc/pmem.c:pmem_open:335] current 139 file d3c84860(1) |
| 01:30.01 | mdrobnak | [ 31.241516] [drivers/misc/pmem.c:pmem_allocate:388] no allocator<6>[drivers/misc/pmem.c:pmem_map_pfn_range:510] map offset 0 len 800000 |
| 01:30.18 | mdrobnak | cr2 said that the id being negative on the RPC shows the memory is corrupt. |
| 01:30.26 | mdrobnak | It should be a 0 or 1 |
| 01:30.39 | mdrobnak | That's the same crash as usual. |
| 01:31.50 | mdrobnak | http://pastebin.com/m2453c087 |
| 01:33.28 | mdrobnak | Ok booted to shell. |
| 01:33.29 | ali1234 | got a line number showing negative rpc? |
| 01:33.58 | mdrobnak | 510 right before the crash |
| 01:34.16 | mdrobnak | this rootfs doesn't have a /dev/pmem |
| 01:36.34 | ali1234 | maybe not created |
| 01:36.37 | ali1234 | no matter |
| 01:36.43 | ali1234 | here's what to do: |
| 01:38.36 | ali1234 | [ Â 31.455291] Unable to handle kernel paging request at virtual address c7184000 |
| 01:38.40 | ali1234 | is the real crash |
| 01:39.02 | ali1234 | the question is why that happened |
| 01:39.12 | ali1234 | first step is to find what line of code caused it |
| 01:39.27 | ali1234 | to me it looks very pmem related |
| 01:39.58 | ali1234 | so add lots of debugging into the pmem driver (using DLOG) |
| 01:41.28 | ali1234 | can you paste a dmesg with 1 bank and no crash, for comparison? |
| 01:43.27 | mdrobnak | I can just boot with mem=89M. Sure, one minute. |
| 01:43.42 | ali1234 | in pmem.c i would add a lot debugging into these functions: |
| 01:44.04 | ali1234 | pmem_setup around anything involving ioremap/kmalloc |
| 01:44.53 | ali1234 | pmem_ioctl, especially PMEM_MAP |
| 01:45.06 | ali1234 | pmem_remap maybe too |
| 01:46.06 | mdrobnak | Hey, here's a crazy idea. |
| 01:46.11 | mdrobnak | One last thing to try |
| 01:46.15 | ali1234 | pmem_remap_pfn_range since that shows up on the dmesg |
| 01:46.21 | mdrobnak | but my math is off |
| 01:46.48 | mdrobnak | How can we remap all the PMEM and above stuff to the end of the memory (0x28000000) |
| 01:47.57 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 01:49.27 | ali1234 | just add 0x10000000 to all of them |
| 01:49.34 | ali1234 | but, i dont think that will work |
| 01:49.55 | ali1234 | since it is shared memory with the dsp it is probably at a fixed address |
| 01:50.03 | ali1234 | but try if oyu want |
| 01:52.30 | mdrobnak | going to boot with mem=89M in a sec first |
| 01:54.33 | mdrobnak | "Android/PMEM: The PMEM (physical memory) driver is used to provide contiguous physical memory regions to userspace libraries that interact with the digital signal processor (DSP) and other hardware that cannot cope with scatter-gather." |
| 01:54.39 | mdrobnak | Hmm you may be right |
| 01:55.05 | ali1234 | yeah i know, i read that too :) |
| 01:55.29 | ali1234 | sooo... |
| 01:55.47 | ali1234 | i could be completely off here |
| 01:56.03 | ali1234 | but it looks like the pmem is having trouble when the second bank is enabled |
| 01:57.23 | ali1234 | that's all i'm really sure of |
| 01:57.34 | mdrobnak | doh wrong rootfs |
| 01:57.41 | mdrobnak | and I have to look up some pf rule stuff soon |
| 01:58.00 | mdrobnak | replacing a redicuously expensive firewall with OpenBSD, lol |
| 01:59.02 | mdrobnak | Yeah, I have only seen one mailing list item about pmem |
| 02:02.08 | mdrobnak | Ok android booting this time |
| 02:02.47 | mdrobnak | This is interesting |
| 02:02.57 | mdrobnak | so even when it DOES NOT crash, I see one line with a negative RPC call |
| 02:03.01 | mdrobnak | using mem=89M |
| 02:03.04 | mdrobnak | ok, at home screen. |
| 02:03.51 | mdrobnak | [ 17.004302] [RR] send control message cmd=7 srv.cmd=7 prog=00000001:c4ed3c20 id=-992038144:c02cf17c |
| 02:03.51 | mdrobnak | [ 31.150970] [drivers/misc/pmem.c:pmem_open:335] current 141 file c4ba64a0(1) |
| 02:03.51 | mdrobnak | [ 31.167602] [drivers/misc/pmem.c:pmem_allocate:388] no allocator<6>[drivers/misc/pmem.c:pmem_map_pfn_range:510] map offset 0 len 800000 |
| 02:03.51 | mdrobnak | [ 31.415039] [drivers/misc/pmem.c:pmem_open:335] current 141 file c3029f40(1) |
| 02:03.51 | mdrobnak | [ 31.416015] [drivers/misc/pmem.c:pmem_ioctl:1147] connect |
| 02:03.52 | mdrobnak | [ 31.416107] [drivers/misc/pmem.c:pmem_connect:833] connect c3029f40 to c4ba64a0 |
| 02:03.54 | mdrobnak | [ 31.424255] [drivers/misc/pmem.c:pmem_open:335] current 141 file c3029ec0(1) |
| 02:03.56 | mdrobnak | [ 31.424835] [drivers/misc/pmem.c:pmem_ioctl:1147] connect |
| 02:03.58 | mdrobnak | [ 31.424896] [drivers/misc/pmem.c:pmem_connect:833] connect c3029ec0 to c4ba64a0 |
| 02:04.00 | mdrobnak | [ 31.425262] [drivers/misc/pmem.c:pmem_open:335] current 141 file c3029e40(1) |
| 02:04.02 | mdrobnak | [ 31.425476] [drivers/misc/pmem.c:pmem_ioctl:1147] connect |
| 02:04.04 | mdrobnak | [ 31.425537] [drivers/misc/pmem.c:pmem_connect:833] connect c3029e40 to c4ba64a0 |
| 02:07.07 | mdrobnak | Good job to those working on power management, it nicely dims the LCD :-) |
| 02:07.16 | mdrobnak | http://pastebin.com/m61c36904 |
| 02:07.33 | mdrobnak | That's a working boot. I didn't get the first few seconds, but it's the same as a crash probably. |
| 02:08.11 | mdrobnak | I have a /dev/pmem now |
| 02:08.21 | mdrobnak | # ls -l pmem |
| 02:08.21 | mdrobnak | crw-rw---- 1 1000 1003 10, 1 Sep 21 22:02 pmem |
| 02:10.01 | ali1234 | yes, i think that negative number is caused merely by a signed/unsigned mismatch in the logging code |
| 02:10.25 | ali1234 | ie it's a red herring :) |
| 02:10.49 | mdrobnak | yet another :-) |
| 02:11.10 | ali1234 | the interesting part is the pmem stuff line 161 - 171 |
| 02:11.25 | mdrobnak | Shutting down android. Going to try my crazy remap idea. |
| 02:11.29 | ali1234 | the crash happened right in the middle of that |
| 02:11.39 | mdrobnak | Yeah right after "no allocator" |
| 02:11.59 | ali1234 | actually no |
| 02:12.08 | ali1234 | notice the missing /n concatenates two lines |
| 02:12.22 | ali1234 | "no allocator" is correct for two of the four pmem devices anyway |
| 02:12.51 | ali1234 | i suspect the problem is with the second device which does have an allocator - and happens when the allocate happens |
| 02:13.08 | *** join/#htc-linux pleemans (n=toi@d54C2A96D.access.telenet.be) |
| 02:14.22 | mdrobnak | Ouch. |
| 02:14.31 | mdrobnak | Reboots at FB handover hehe |
| 02:17.30 | mdrobnak | So I'm not sure what we do. |
| 02:17.42 | ali1234 | we put loads and loads of debugging into pmem.c |
| 02:17.54 | ali1234 | until we find the exact line where it crashes |
| 02:18.12 | ali1234 | or rather, you do :) |
| 02:18.35 | *** join/#htc-linux stickboy (n=anonymou@128.153.211.18) |
| 02:19.07 | mdrobnak | <PROTECTED> |
| 02:19.24 | mdrobnak | That's already in pmem_setup, but I don't see that in dmesg. |
| 02:20.24 | ali1234 | it might be much earlier |
| 02:21.03 | ali1234 | as a last resort, put DLOG on every other line of the whole damn driver |
| 02:22.21 | mdrobnak | lol |
| 02:23.19 | mdrobnak | [ 3.403503] pmem: 1 init |
| 02:23.19 | mdrobnak | [ 3.409790] pmem_adsp: 0 init |
| 02:23.19 | mdrobnak | [ 3.416137] pmem_gpu0: 0 init |
| 02:23.19 | mdrobnak | [ 3.422515] pmem_gpu1: 0 init |
| 02:24.24 | ali1234 | you need to read through the driver and get a feel for the flow of execution, then try to narrow down the problem location |
| 02:24.41 | ali1234 | it isn't in early init for sure |
| 02:24.53 | ali1234 | it happens when something actually opens the device |
| 02:25.17 | ali1234 | one question which would be easy to answer is which of the four devices actually bugs out |
| 02:25.38 | ali1234 | i suspect it is the adsp |
| 02:26.27 | mdrobnak | Actually I think it's gpu0 |
| 02:26.34 | mdrobnak | I shouldn't say actually. |
| 02:26.39 | mdrobnak | I think it's gpu0 |
| 02:26.40 | mdrobnak | :-) |
| 02:29.04 | ali1234 | well, what to do is add more verbode debugging so you know which device the messages refer to |
| 02:29.34 | ali1234 | expect to be looking at the dmesg dumps a few hundred times :) |
| 02:30.52 | mdrobnak | Actually, I think we'll get it fast because I just added process name and type being opened :) |
| 02:31.04 | ali1234 | cool |
| 02:31.26 | mdrobnak | Or not. |
| 02:31.29 | mdrobnak | :-/ |
| 02:31.30 | ali1234 | hmm |
| 02:32.04 | ali1234 | have a look in menuconfig, at the kernel hacking section |
| 02:32.11 | ali1234 | maybe something in there can debug memory mappings |
| 02:32.21 | ali1234 | it will produce a lot of output though |
| 02:33.24 | mdrobnak | well at least I will get the calling proc name this time |
| 02:33.53 | ali1234 | yes |
| 02:34.07 | ali1234 | looking at the android code to see what order it does things may help too |
| 02:36.05 | mdrobnak | Doh |
| 02:36.10 | mdrobnak | forgot to remove the + 0x100000 |
| 02:42.45 | mdrobnak | Ok, lets see what dmesg says now |
| 02:48.17 | *** join/#htc-linux root2 (n=root@rgnb-5d874ded.pool.mediaWays.net) |
| 02:54.27 | mdrobnak | [ 31.287231] [drivers/misc/pmem.c:pmem_open:335] current 146 file d7e75420(1) |
| 02:54.28 | mdrobnak | [ 31.302673] [drivers/misc/pmem.c:pmem_open:336] name: SurfaceFlinger<6> |
| 02:54.33 | mdrobnak | Not much of a surprise there. |
| 02:55.00 | mdrobnak | we could look in surfaceflinger to see what pmem it uses |
| 02:55.27 | tmzt | interesting that it gets the name of the requester |
| 02:55.29 | tmzt | I didn't know that |
| 02:55.52 | tmzt | you don't really want to look at surfaceflinger directly though |
| 02:55.59 | tmzt | probably libagl |
| 02:56.02 | tmzt | or pixelflinger |
| 02:57.12 | mdrobnak | well, I put in a current->comm into the log |
| 02:58.21 | tmzt | what is comm? |
| 02:58.48 | mdrobnak | Process Name :-) |
| 02:58.59 | mdrobnak | I think command Line actually |
| 03:00.46 | tmzt | yeah, that makes sense |
| 03:00.50 | mdrobnak | <PROTECTED> |
| 03:00.51 | mdrobnak | <PROTECTED> |
| 03:00.51 | ali1234 | just grep the android source for /dev/pmem and you'll find the culprit |
| 03:01.02 | ali1234 | ^ wheee |
| 03:01.03 | mdrobnak | Well, it looks like it uses the main pmem on firs allow |
| 03:01.05 | mdrobnak | *alloc |
| 03:01.32 | mdrobnak | It tries to allocate 8MB |
| 03:01.55 | ali1234 | hmm |
| 03:02.13 | ali1234 | makes me think |
| 03:02.40 | ali1234 | maybe android allocates a buffer in normal memory and tries to use accelerated copy between that, and the pmem device |
| 03:02.50 | ali1234 | and maybe that fails if they are in different banks |
| 03:02.53 | tmzt | if you have it all checked out try repo for-all git grep |
| 03:02.58 | tmzt | but not sure that's right |
| 03:03.17 | mdrobnak | yeah I have the whole thing :-) |
| 03:03.49 | mdrobnak | I built it from source, to answer if that would fix it, because of people saying OpenGL is broken.. |
| 03:04.01 | mdrobnak | well the default build uses software OpenGL |
| 03:04.04 | tmzt | broken how? |
| 03:04.21 | tmzt | yeah, you have to have libhgl and dzo's fixes to tell the amss to use 3d |
| 03:04.22 | mdrobnak | I dunno, that's what cr2 thought might have been a problem. |
| 03:04.35 | ali1234 | the default build doesn't use pmem at all does it? |
| 03:04.52 | mdrobnak | yeah, pmem is used in a few places I think |
| 03:05.02 | ali1234 | of course it probably doesnt have dialer support either |
| 03:05.12 | ali1234 | meh, i dont know |
| 03:05.21 | mdrobnak | tmzt: repo grep pmem will do it |
| 03:05.28 | ali1234 | keep drilling down on the pmem driver until you find the exact line where it crashes |
| 03:05.41 | tmzt | hah, they fixed it |
| 03:05.52 | dzo | mdrobnak: if you disable pmem, abdroid should still boot, just won't use accel 2D. |
| 03:05.57 | mdrobnak | external/opencore/android/samples/android_surface_output_fb.cpp:static const char* pmem_adsp = "/dev/pmem_adsp"; |
| 03:05.57 | mdrobnak | external/opencore/android/samples/android_surface_output_fb.cpp:static const char* pmem = "/dev/pmem"; |
| 03:06.07 | ali1234 | ah, an expert :) |
| 03:06.14 | mdrobnak | tmzt - well it broke in the middle |
| 03:06.16 | tmzt | dzo: looks like smi64 is broken |
| 03:06.17 | mdrobnak | Hey dzo |
| 03:06.43 | mdrobnak | Well, hell, if that gets me 214MBs of RAM until we figure out how to fix pmem, lets try that! |
| 03:06.50 | dzo | so does it die accessing pmem or pmem_adsp? |
| 03:07.00 | tmzt | I can't even boot :) |
| 03:07.14 | tmzt | but it's pulling git right now, to remote storage and very slow |
| 03:07.28 | dzo | just take the pmem entries out of the board file. |
| 03:07.53 | tmzt | not enough to disable in .config? |
| 03:08.42 | mdrobnak | dzo: Can't tell if it's pmem or pmem_adsp |
| 03:08.49 | mdrobnak | in the samples refs adsp |
| 03:09.00 | mdrobnak | but libsurfaceflinger in VRamHeap.cpp is just pmem |
| 03:09.04 | dzo | tmzt: that will work too, but if you take them out of devices[], they won't be loaded either. |
| 03:09.16 | tmzt | well, it didn't work |
| 03:09.22 | tmzt | when I tried that a few days ago |
| 03:09.25 | dzo | then pmem isn;t the problem. |
| 03:09.30 | tmzt | right |
| 03:09.43 | tmzt | it vibrates twice and never gets to fbcon |
| 03:09.58 | ali1234 | tmzt: are you talking abut the same problem as mdrobnak? |
| 03:10.10 | dzo | can you allocate any of the second bank as ram? |
| 03:10.11 | tmzt | what device does he have? |
| 03:10.18 | ali1234 | raph |
| 03:10.22 | mdrobnak | 110 |
| 03:10.29 | ali1234 | with two ram banks |
| 03:10.34 | tmzt | possibly |
| 03:10.40 | mdrobnak | dzo: if I pull out pmem, qdsp5 adsp_driver and hw3d won't build |
| 03:10.41 | dzo | what if you only have 1 bank starting at 0x20000000, does that work? |
| 03:10.50 | mdrobnak | we tried that earlier |
| 03:10.56 | mdrobnak | not sure if I did it right |
| 03:11.03 | mdrobnak | but no, it didn't |
| 03:11.30 | dzo | ok, take them out of devices[] in the board file. |
| 03:11.41 | tmzt | can we add smi to device specific? |
| 03:12.15 | dzo | yes, sure. just change the addresses before the device is added. |
| 03:12.56 | tmzt | ok, then how do I integrate the seperate headers from diamond into a raphael board file? |
| 03:13.42 | tmzt | - msm_proc_comm_wince(&vibra, 0); |
| 03:13.44 | tmzt | + blac_set_vibrate(1); |
| 03:13.56 | mdrobnak | making |
| 03:14.12 | ali1234 | mdrobnak: if all else fails (ie there's a unfixable hardware reason why two banks doesn't work) then you could always implement the second bank as a swap device :) |
| 03:14.29 | mdrobnak | That would work fine lol |
| 03:14.32 | tmzt | we can only do what the radio lets us |
| 03:14.45 | dzo | use mach_is_htcdiamond() etc.. |
| 03:15.12 | tmzt | that would mean recombining the devices or spliting the board based on smi size instead of raph/diam |
| 03:16.26 | mdrobnak | lets see |
| 03:16.41 | mdrobnak | Sorry, no dice. |
| 03:17.01 | mdrobnak | 09-21 19:16:33.555 I/SurfaceFlinger( 137): SurfaceFlinger is starting |
| 03:17.01 | mdrobnak | 09-21 19:16:33.565 I/SurfaceFlinger( 137): SurfaceFlinger's main thread ready to run. Initializing graphics H/W... |
| 03:17.01 | mdrobnak | 09-21 19:16:33.565 E/MemoryHeapBase( 137): error opening /dev/pmem: No such file or directory |
| 03:17.01 | mdrobnak | 09-21 19:16:33.565 E/SurfaceFlinger( 137): Couldn't open /sys/power/wait_for_fb_sleep or /sys/power/wait_for_fb_wake |
| 03:17.02 | mdrobnak | 09-21 19:16:33.715 D/SurfaceFlinger( 137): pid 137 requesting gpu core (owner = -1) |
| 03:17.04 | mdrobnak | 09-21 19:16:33.715 W/SurfaceFlinger( 137): couldn't grant gpu core to pid 137 |
| 03:17.06 | mdrobnak | 09-21 19:16:33.715 D/EGL ( 137): requestGPU returned -1 |
| 03:17.08 | mdrobnak | 09-21 19:16:33.725 E/GLLogger( 137): h/w accelerated eglGetDisplay() failed (EGL_SUCCESS) |
| 03:17.10 | mdrobnak | Still crashed. |
| 03:17.22 | mdrobnak | Does that rule out pmem? |
| 03:17.24 | tmzt | only android? so your kernel works on raph110? |
| 03:17.45 | mdrobnak | I've tested it with memtester to 200MB of RAM no problems |
| 03:18.14 | mdrobnak | I'm curious to see dmesg |
| 03:19.22 | mdrobnak | getting it now |
| 03:19.51 | ali1234 | you could selectively disable pmem devices until you find the one that crashes... |
| 03:20.30 | ali1234 | wait, it crashes anyway? |
| 03:20.39 | ali1234 | interested to see dmesg too :) |
| 03:21.29 | dzo | if you disable pmem and it still crashes then pmem can't be the problem. are you sure the banks are set up correctly? node 0 |
| 03:24.04 | mdrobnak | All pmem devices disabled, still crashes on SurfaceFlinger |
| 03:24.44 | mdrobnak | http://pastebin.com/m6c997f5c |
| 03:25.13 | ali1234 | lol |
| 03:25.20 | ali1234 | pmem is nothing to do with it then |
| 03:25.23 | ali1234 | damn |
| 03:32.21 | mdrobnak | dzo: Thoughts? |
| 03:35.43 | ali1234 | you could try allocating all the memory in the upper bank so that nothing can touch it |
| 03:35.52 | ali1234 | (within the kernel) |
| 03:36.14 | ali1234 | maybe the other core is using some region in it, and you're corrupting that |
| 03:37.27 | mdrobnak | That's possible. Maybe the proc_comm stuff is to blame. |
| 03:38.03 | mdrobnak | or maybe our map is incorrect. I'm not sure. |
| 03:38.44 | ali1234 | you could also make the upper bank size 1 page long |
| 03:38.53 | ali1234 | and try various addresses in the bank for that 1 page |
| 03:39.02 | ali1234 | to minimize collision possiblity |
| 03:39.17 | ali1234 | over even |
| 03:39.27 | ali1234 | make two banks in the lower ram |
| 03:39.45 | ali1234 | that might be really enlightening |
| 03:40.09 | ali1234 | it would confirm or rule out whether the problem is intrinsic to having two banks defined |
| 03:40.27 | ali1234 | assuming it actually boots |
| 03:41.26 | mdrobnak | hah |
| 03:41.27 | mdrobnak | well |
| 03:41.34 | mdrobnak | it's way past bed time here |
| 03:45.01 | mdrobnak | I have to get to sleep. If people leave me commands to run, I'll do it when I get a moment and report back. I'm not sure how to break up the banks and what I'd have to do with the .h stuff, so I'd need some more guidance / a patch.. |
| 03:51.38 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 04:03.49 | *** join/#htc-linux goxboxlive (n=jrs@mail2.hjellnesconsult.no) |
| 04:24.02 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 04:34.17 | *** join/#htc-linux droid0011 (n=g1@p4FDCEBEB.dip.t-dialin.net) |
| 04:42.51 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 04:44.46 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 04:49.57 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 05:07.44 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 05:15.46 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 05:22.38 | *** join/#htc-linux luc (n=luc@89.115.128.35) |
| 05:29.11 | *** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz) |
| 05:52.22 | *** join/#htc-linux x29a (n=x29a@unaffiliated/x29a) |
| 05:52.25 | *** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz) |
| 06:01.10 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 06:06.34 | *** join/#htc-linux kiozen (n=oeichler@84.146.19.92) |
| 06:15.49 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 06:27.12 | *** join/#htc-linux JDShadowline (n=JDShadow@97.101.243.247) |
| 06:33.21 | *** join/#htc-linux Kevin2 (n=Kevin2@207-237-194-161.c3-0.avec-ubr2.nyr-avec.ny.cable.rcn.com) |
| 06:37.26 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 06:41.15 | *** join/#htc-linux pleemans (n=toi@d51A49C45.access.telenet.be) |
| 07:03.18 | *** join/#htc-linux dzo_ (n=dzo@121.98.128.127) |
| 07:07.46 | *** join/#htc-linux c4software (n=vbrossea@217.112.64.97) |
| 07:12.30 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 07:12.57 | c4software | Hi everyone |
| 07:24.10 | NetRipper | im not everyone, but hi |
| 07:24.23 | c4software | Hi NetRipper |
| 07:24.24 | c4software | :) |
| 07:24.30 | NetRipper | :) |
| 07:31.11 | *** join/#htc-linux kvaster (n=kvaster@93.84.112.80) |
| 07:33.08 | *** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz) |
| 07:36.38 | *** join/#htc-linux FR^2 (n=frzwo@2001:41d0:1:ed2f:0:0:0:cafe) |
| 08:05.46 | *** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz) |
| 08:11.06 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 08:28.38 | *** join/#htc-linux dzo_ (n=dzo@121.98.128.127) |
| 08:43.35 | c4software | dzo: are you here ? |
| 08:44.52 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 08:58.25 | *** join/#htc-linux Captnoord (n=Captnoor@81.71.164.123) |
| 09:05.34 | *** join/#htc-linux c4software1 (n=vbrossea@217.112.64.97) |
| 09:39.02 | *** join/#htc-linux kvaster (n=kvaster@93.84.112.80) |
| 10:01.11 | *** join/#htc-linux kvaster (n=kvaster@93.84.112.80) |
| 10:02.45 | Captnoord | mdrobnak I wonder if we handle CopyRegions |
| 10:08.37 | *** join/#htc-linux Gnutoo (n=gnutoo@host142-37-dynamic.117-80-r.retail.telecomitalia.it) |
| 10:14.22 | *** join/#htc-linux kvaster (n=kvaster@93.84.112.80) |
| 10:15.35 | Captnoord | PMEM Heap address |
| 10:15.35 | Captnoord | 0xA80811DC |
| 10:15.46 | Captnoord | PMEM heap size 0x700000 |
| 10:16.33 | Captnoord | nope |
| 10:16.36 | Captnoord | 0xA80811DC is main memory end |
| 10:16.57 | Captnoord | PMEM physical address is 0xA80811D8 |
| 10:22.08 | *** join/#htc-linux leaigor (n=laigor@188.134.36.14) |
| 10:24.58 | *** join/#htc-linux goxboxlive (n=jrs@mail2.hjellnesconsult.no) |
| 10:48.52 | Captnoord | NKForceCleanBoot |
| 10:48.53 | Captnoord | lol |
| 11:19.48 | *** join/#htc-linux StarLite` (n=nnscript@85.145.108.166) |
| 11:21.54 | mdrobnak | stumbles into room. Morning. |
| 11:22.16 | mdrobnak | No coffee yet :-) |
| 11:22.17 | ali1234 | morning :D |
| 11:22.50 | mdrobnak | You're here? When do you sleep? hehehe |
| 11:23.38 | Captnoord | morning |
| 11:23.58 | Captnoord | regarding your adventures with getting more ram..... |
| 11:24.19 | Captnoord | in nk.exe there is a bit of info regarding PMEM |
| 11:24.40 | mdrobnak | ? really? |
| 11:24.43 | mdrobnak | that's interesting. |
| 11:24.49 | mdrobnak | I thought that was an Android-only thing |
| 11:24.51 | Captnoord | yup |
| 11:24.54 | Captnoord | .text:80005E60 aKMainmemoryend unicode 0, <[K] MainMemoryEndAddress = 0x%08X> |
| 11:24.54 | Captnoord | .text:80005E60 ; DATA XREF: .text:aKMainmemoryendExo |
| 11:24.54 | Captnoord | .text:80005E60 DCW 0xD |
| 11:24.54 | Captnoord | .text:80005E60 DCW 0xA |
| 11:24.54 | Captnoord | .text:80005E60 unicode 0, <>,0 |
| 11:24.57 | Captnoord | .text:80005EA8 aKPmemheapphyad unicode 0, <[K] PmemHeapPhyAddr = 0x%08X> |
| 11:24.57 | Captnoord | .text:80005EA8 ; DATA XREF: .text:aKPmemheapphyadExo |
| 11:25.00 | Captnoord | .text:80005EA8 DCW 0xD |
| 11:25.00 | Captnoord | .text:80005EA8 DCW 0xA |
| 11:25.04 | Captnoord | .text:80005EA8 unicode 0, <>,0 |
| 11:25.07 | Captnoord | .text:80005EE8 aKDwpmemheapsiz unicode 0, <[K] dwPmemHeapSize = 0x%08X> |
| 11:25.16 | Captnoord | but I don't know if its the same.... |
| 11:25.29 | ali1234 | Mainmemoryend suggests it is |
| 11:25.39 | Captnoord | yup |
| 11:25.45 | ali1234 | but we rules out pmem as direct cause of crash by disabling it... |
| 11:25.49 | ali1234 | *ruled |
| 11:25.55 | mdrobnak | Yes. |
| 11:26.08 | Captnoord | yea... I have read that |
| 11:26.14 | Captnoord | or is it red |
| 11:26.15 | Captnoord | nah |
| 11:26.26 | Captnoord | I was more interested in finding the 2e bank stuff |
| 11:26.28 | Captnoord | but found this |
| 11:26.32 | mdrobnak | Something bothers me - why does WinCE break the memory into 4 banks, and we only use 2. It *looks* contiguous, but what's the reason? |
| 11:26.51 | Captnoord | paging...... |
| 11:26.56 | Captnoord | DMA |
| 11:27.08 | mdrobnak | Wouldn't we be subject to the same issues in Linux? |
| 11:27.17 | Captnoord | copying big amount of data from 1 page to the other |
| 11:27.18 | mdrobnak | Ie, aren't those hardware issues? |
| 11:27.21 | Captnoord | more pages..... |
| 11:27.23 | Captnoord | would be better |
| 11:27.36 | Captnoord | yup they are... |
| 11:27.40 | Captnoord | just speaking my mind |
| 11:27.59 | mdrobnak | Then I think we should try breaking it into 4 regions, like in Windows. |
| 11:28.01 | ali1234 | 4 banks? how |
| 11:28.17 | mdrobnak | ali1234, Look at the memory map. |
| 11:28.24 | mdrobnak | It shows 4 seperate address regions |
| 11:28.45 | mdrobnak | Perhaps banks were the wrong term to use. |
| 11:28.52 | Captnoord | and in the same nk.exe |
| 11:28.53 | Captnoord | there is |
| 11:28.53 | Captnoord | OEMEnumExtensionDRAM |
| 11:29.06 | Captnoord | and for what I can see |
| 11:29.13 | ali1234 | i think xda wiki is broken |
| 11:29.17 | Captnoord | hmm hard to explain.... |
| 11:29.19 | ali1234 | trying to dl the php file :( |
| 11:29.22 | Captnoord | lemme pastebin |
| 11:30.00 | Captnoord | http://pastebin.com/m758c17b0 |
| 11:30.13 | mdrobnak | ali1234, Use http://htc-linux.org |
| 11:30.22 | Captnoord | and i'm especialy interested in |
| 11:30.22 | Captnoord | .text:80057324 ORR R1, R1, #0x300000 ; 0x8E000000 | 0x300000 = 8E300000 |
| 11:30.23 | Captnoord | .text:80057328 ORR R0, R0, #0x900000 ; 0x8B000000 | 0x900000 = 8B900000 |
| 11:30.23 | Captnoord | .text:8005732C ORR LR, LR, #0x900000 ; 0x88000000 | 0x900000 = 88900000 |
| 11:30.23 | Captnoord | .text:80057330 ORR R2, R2, #0xA00000 ; 0x85000000 | 0xA00000 = 85A00000 |
| 11:30.30 | Captnoord | the comments are mine |
| 11:30.31 | Captnoord | btw |
| 11:30.34 | mdrobnak | http://htc-linux.org/wiki/index.php?title=Raphael |
| 11:31.13 | mdrobnak | On the memory page, Captnoord ? |
| 11:31.23 | Captnoord | yea I kow |
| 11:31.26 | Captnoord | checking now |
| 11:31.48 | ali1234 | mdrobnak: you mean the 4 parts of bank 2? |
| 11:31.56 | mdrobnak | Captnoord, Or the comments on the .text code you just pasted? |
| 11:31.59 | mdrobnak | ali1234, Yes. |
| 11:32.51 | Captnoord | ; 0x8E000000 | 0x300000 = 8E300000 |
| 11:32.54 | Captnoord | those are mine comments |
| 11:32.58 | mdrobnak | Ah. |
| 11:33.13 | mdrobnak | Sorry. Still early. |
| 11:33.24 | Captnoord | nah my crap english |
| 11:33.34 | mdrobnak | Hah, you do fine. |
| 11:33.40 | ali1234 | mdrobnak: well they are not mapped contiguous on WM that's why they're listed separately |
| 11:33.50 | ali1234 | but that's doesn't really tell us much |
| 11:33.59 | mdrobnak | Well, we have it as one big block. |
| 11:34.17 | ali1234 | yeah |
| 11:34.21 | ali1234 | virtual mapping though |
| 11:34.29 | mdrobnak | But in terms of addressing, they *look* contiguous. |
| 11:34.32 | ali1234 | it's general purpose so we dont care how the virtual mapping looks |
| 11:34.41 | ali1234 | in physical addressing they are |
| 11:34.42 | mdrobnak | 0x20000000 0x26 SDRAM (bank 2) |
| 11:34.46 | ali1234 | but look at the wince mapping |
| 11:34.51 | mdrobnak | 0x22600000 0x17 SDRAM (bank 2) |
| 11:34.53 | ali1234 | there are gaps |
| 11:35.05 | mdrobnak | 0x23d00000 0x27 SDRAM (bank 2) |
| 11:35.10 | mdrobnak | <PROTECTED> |
| 11:35.19 | mdrobnak | Ah, I see what you're saying |
| 11:35.20 | ali1234 | 0xa5a00000 + 0x02600000 != 0xa8900000 |
| 11:35.34 | ali1234 | but that's just virtual addresses, and tells us nothing really |
| 11:35.45 | Captnoord | nope |
| 11:35.53 | mdrobnak | Ok, so maybe the MS guys *are * just crazy. LOL |
| 11:36.07 | Captnoord | there is always a reason |
| 11:36.18 | mdrobnak | I was so focused on the physical addresses, didn't notice the gaps in the virtual. |
| 11:36.19 | ali1234 | sure. we just dont know it |
| 11:36.27 | Captnoord | but... what I supposed to say was that it seems that the 2e bank also has a limit |
| 11:36.31 | Captnoord | I mean |
| 11:36.44 | Captnoord | somewhere you shouldn't write... or use it for our purposes |
| 11:36.49 | Captnoord | I think |
| 11:36.49 | ali1234 | yep |
| 11:37.16 | mdrobnak | Here's what I know. |
| 11:37.23 | Captnoord | within the OEMinit function |
| 11:37.28 | mdrobnak | When we moved PMem, and then started messing with the ranges... |
| 11:37.45 | Captnoord | there are some links with paging..... |
| 11:37.50 | Captnoord | I dono if thats interesting? |
| 11:38.15 | mdrobnak | When I didn't use 0x20000000 through 0x21000000 , and had it set to 32MB size, it booted to Android all the way. And it ran for a minute or two, then crashed. No other configuration more then 89MB booted or ran that far. |
| 11:38.37 | ali1234 | you never said that... |
| 11:38.51 | mdrobnak | That was from days ago |
| 11:38.53 | mdrobnak | sorry |
| 11:39.02 | ali1234 | so you did get some kind of success? |
| 11:39.20 | ali1234 | this is why i suggest 89mb in bank[0] and 1 page (4kb) in bank 1 |
| 11:39.27 | ali1234 | and try putting it the start and the end |
| 11:39.38 | mdrobnak | As soon as you tried to do anything useful it crashed. Didn't get a dmesg for it though |
| 11:41.38 | mdrobnak | Thing is, according to the Memory Map on the wiki, it should be perfectly usable. |
| 11:41.50 | ali1234 | maybe it is wrong or has missing info |
| 11:41.51 | mdrobnak | I also wrote values to 0x200000 and read them back no problem in haret. |
| 11:42.03 | mdrobnak | (err 0x20000000) |
| 11:42.04 | ali1234 | it's 0x20000000 |
| 11:42.14 | ali1234 | 8 digits always :) |
| 11:42.23 | c4software1 | dzo: With your lastest modification disable pwrsink my screen don't turn off. Just the backlight is turned off. |
| 11:42.54 | mdrobnak | Here's a thought -- maybe the low level routines to address the other bank of ram has an issue? |
| 11:42.59 | mdrobnak | Maybe the map itself is right? |
| 11:43.05 | ali1234 | maybe. check it |
| 11:43.23 | mdrobnak | I'll get right on that. |
| 11:43.24 | mdrobnak | lol |
| 11:43.36 | ali1234 | i have no idea where it is |
| 11:43.38 | mdrobnak | I've never done this low-level of stuff before |
| 11:45.21 | mdrobnak | Captnoord, any ideas? :-) |
| 11:45.51 | Captnoord | where to look? |
| 11:46.11 | mdrobnak | Well, then again, even if I knew where to look, I'd have no idea if it was right or wrong.. |
| 11:46.36 | Captnoord | but you know and read the flow |
| 11:46.40 | Captnoord | if you check it |
| 11:47.39 | Captnoord | the init function also init's the L1 and L2 cache of the cpu |
| 11:47.48 | Captnoord | I dono if we can use that |
| 11:48.36 | Captnoord | hmmmm |
| 11:48.58 | Captnoord | I think I found something that is something like a global var related to the memory stuff |
| 11:49.18 | Captnoord | as its used as a argument for both the extended DRAM and the normal ram init |
| 11:49.19 | mdrobnak | What file? |
| 11:49.24 | Captnoord | nk.exe |
| 11:49.25 | Captnoord | asm |
| 11:49.33 | Captnoord | reading the asm atm... |
| 11:49.38 | Captnoord | wince file from the spl |
| 11:49.45 | Captnoord | or.... |
| 11:49.46 | Captnoord | nah |
| 11:49.55 | Captnoord | core application I mean |
| 11:51.01 | mdrobnak | oh |
| 11:51.01 | Captnoord | hmmmmm |
| 11:51.20 | Captnoord | arm asm is wierd stuff if your used to x86 |
| 11:51.24 | mdrobnak | what device is that dump from? A 100? |
| 11:51.43 | Captnoord | aaahhh |
| 11:51.43 | Captnoord | lol I see now its a branch |
| 11:51.43 | Captnoord | yup |
| 11:51.54 | Captnoord | LDREQ is a load if equal branch |
| 11:52.49 | Captnoord | I think it checks if a second bank is there |
| 11:53.05 | mdrobnak | That's useful code.. |
| 11:53.18 | Captnoord | CMP R3, #0x100 |
| 11:53.22 | Captnoord | thats obviouse |
| 11:53.28 | Captnoord | R3 contains |
| 11:53.34 | Captnoord | LDR R3, [R5] |
| 11:53.42 | Captnoord | so r3 = *r5 |
| 11:54.05 | Captnoord | and r5 = 0xA80810C0 |
| 11:56.33 | Captnoord | hooking my phone now |
| 11:56.39 | Captnoord | to check the address |
| 11:58.45 | mdrobnak | So you have a RAPH100 Captnoord ? What have you tried to run on it in terms of Linux stuff? |
| 11:58.52 | Captnoord | yup |
| 11:58.55 | Captnoord | android runs on it |
| 11:58.58 | Captnoord | sound works |
| 11:59.28 | Captnoord | but atm I run windows mobile bleh... as its best for battery |
| 11:59.30 | Captnoord | for now |
| 12:00.47 | mdrobnak | Android runs, but with how much RAM? :-) |
| 12:01.15 | Captnoord | I haven't checked... i'm atm working on windows as i'm working on school stuff |
| 12:01.24 | Captnoord | so can't build myself a fresh kernel |
| 12:01.54 | Captnoord | but i've helped cr2 a bit with the rpc stuff |
| 12:02.04 | Captnoord | but ya all might know that |
| 12:02.33 | Captnoord | lol |
| 12:02.43 | Captnoord | needed to download that mobility centre |
| 12:02.51 | Captnoord | bleh |
| 12:03.10 | mdrobnak | I've been spinning my weels on this RAM stuff - I was trying to debug the RIL a bit, but without more RAM, it's hard to use. |
| 12:03.34 | mdrobnak | At least the RIL can get the MCC / MNC now by itself. |
| 12:03.52 | Captnoord | hehe |
| 12:04.09 | Captnoord | I think |
| 12:04.12 | Captnoord | that OEMEnumExtensionDRAM function |
| 12:04.28 | Captnoord | is to map the continues addresses to the second mem bank |
| 12:04.36 | Captnoord | somehow |
| 12:04.44 | Captnoord | as it kinda a callback somehow |
| 12:05.11 | Captnoord | but that would be stupid |
| 12:08.36 | Captnoord | also messages like |
| 12:08.37 | Captnoord | .text:80002BD8 aErrorXipRegion unicode 0, <ERROR! XIP region span accross discontigious memory!!! Sy> |
| 12:08.37 | Captnoord | .text:80002BD8 ; DATA XREF: .text:off_8003B810o |
| 12:08.37 | Captnoord | .text:80002BD8 unicode 0, <stem Halted!> |
| 12:10.06 | Captnoord | but xip is rom space? |
| 12:11.22 | Captnoord | lol |
| 12:11.25 | Captnoord | that took forever |
| 12:11.26 | Captnoord | lolz |
| 12:13.42 | mdrobnak | xip = Execute In Place |
| 12:13.48 | mdrobnak | Yes, XIP is ROM I think |
| 12:13.56 | Captnoord | HaRET(7)# vdump 0xA80810C0 4 |
| 12:13.56 | Captnoord | a80810c0 | 00000100 | .... |
| 12:14.05 | Captnoord | CMP R3, #0x100 |
| 12:14.27 | mdrobnak | That would be true :-) |
| 12:14.30 | Captnoord | but I don't know if this is hardcoded |
| 12:14.34 | Captnoord | I mean.... |
| 12:14.37 | Captnoord | hardware wise |
| 12:14.41 | Captnoord | in the mem map |
| 12:14.56 | Captnoord | I would need someone who doesn't have the second bank |
| 12:14.57 | Captnoord | todo the same |
| 12:14.59 | *** join/#htc-linux thedicemaster (n=thedicem@j89051.upc-j.chello.nl) |
| 12:15.06 | Captnoord | if it would return 0 |
| 12:15.14 | Captnoord | then we might know something |
| 12:15.41 | mdrobnak | I should probably check there LOL |
| 12:15.45 | mdrobnak | j/k |
| 12:16.01 | mdrobnak | Someone with the RAPH500 should be able to answer that question |
| 12:16.22 | Captnoord | or a diamond |
| 12:18.17 | Captnoord | so |
| 12:18.24 | Captnoord | main mem addr end |
| 12:19.09 | Captnoord | HaRET(10)# vdump 0xA80811D8 4 |
| 12:19.09 | Captnoord | a80811d8 | 00200000 | .. . |
| 12:19.21 | Captnoord | pmem physical addr |
| 12:19.35 | Captnoord | HaRET(11)# vdump 0xA80811D8 4 |
| 12:19.35 | Captnoord | a80811d8 | 00200000 | .. . |
| 12:19.39 | Captnoord | thats obviouse |
| 12:19.40 | Captnoord | lol |
| 12:20.01 | Captnoord | and pmem heap size |
| 12:20.12 | Captnoord | HaRET(12)# vdump 0xA80811DC 4 |
| 12:20.13 | Captnoord | a80811dc | 00700000 | ..p. |
| 12:20.20 | Captnoord | lets check the second bank init stuff |
| 12:21.00 | Gnutoo | ~seen druidu |
| 12:21.50 | Captnoord | nope can't tell anything from that |
| 12:22.01 | Captnoord | and how helps me |
| 12:22.02 | Captnoord | or* |
| 12:26.18 | *** join/#htc-linux phnom (i=simomn@pub99-168.pub.luth.se) |
| 12:30.29 | *** join/#htc-linux FR^2 (n=frzwo@2001:41d0:1:ed2f:0:0:0:cafe) |
| 12:30.53 | Captnoord | http://bolingconsulting.com/blog/?p=4 |
| 12:32.02 | *** join/#htc-linux cr2 (n=cr2@109.84.201.73) |
| 12:32.30 | Captnoord | cr2 you got a phone with 1 mem bank? |
| 12:33.27 | cr2 | Captnoord: i've read a lot of BS in the log |
| 12:33.56 | Captnoord | yea |
| 12:33.59 | Captnoord | I know shit |
| 12:34.02 | Captnoord | i'm just speaking my mind |
| 12:34.16 | mdrobnak | Captnoord, that's interesting about the WinCE memory model. |
| 12:34.21 | cr2 | it's all documented in wiki |
| 12:34.33 | cr2 | there are 3 banks on raph100 |
| 12:35.31 | cr2 | 32M@0x0 (aka SMI) 128M@0x10000000 (aka EBI1) and 128M@0x20000000 (don't know the name, probably EBI1 too) |
| 12:36.12 | cr2 | parts of SMI and EBI1 are used by wince SPL, QCSBL, OEMSBL, AMSS |
| 12:36.28 | cr2 | and are "hardware" protected (aka MPU) |
| 12:36.59 | cr2 | maybe we can add some html colors to wiki, so it's visible |
| 12:37.30 | cr2 | some MPU bits can be disabled, you you can see what is there (and maybe change ;) |
| 12:38.10 | cr2 | i doubt that something in 128M@0x20000000 is protected by MPU , but can't prove it |
| 12:38.50 | cr2 | the 89M limit for EBI1 is pure software (board-*.h) |
| 12:39.20 | cr2 | the real MPU/AMSS limit is 128M-13M=115M |
| 12:40.00 | cr2 | the free (non-MPU'd) SMI ram can be reused too |
| 12:40.35 | cr2 | so if you are not interested in android, the 3 bank linux ram layout can be made |
| 12:41.17 | cr2 | 8.5MB@0x0 + 115MB@0x10000000 + 128M@0x20000000 |
| 12:41.30 | Captnoord | thanks... for this insight :D |
| 12:41.30 | cr2 | err |
| 12:41.43 | cr2 | 8.5MB@0x80000 + 115MB@0x10000000 + 128M@0x20000000 |
| 12:42.16 | cr2 | but the spl MPU can be disabled (see diamond code of dzo) |
| 12:42.30 | cr2 | for you can wipe the SMI copy of spl too |
| 12:42.37 | cr2 | and free more 512K |
| 12:43.14 | cr2 | but then you need to take care of dynamic RAM allocation for the FB (should be easy) |
| 12:43.31 | cr2 | and ADSP,MDP and CAM (and GPU and GPU1) |
| 12:44.09 | cr2 | btw, we are missing the CAMERA block in the raph board file (cf. sapphire) |
| 12:44.44 | cr2 | what are the requirements for the ADSP block, MDP and CAM (also ADSP actually) needs to be clarified. |
| 12:44.49 | cr2 | back to work :) |
| 12:45.13 | Captnoord | lol |
| 12:45.17 | Captnoord | we got owned |
| 12:45.31 | ali1234 | HA |
| 12:46.05 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 12:46.21 | ali1234 | the requirements of ADSP, GPU0 and GPU1 are pmem mappings, and they are entirely within the lower bank (0x10000000) according to the board file |
| 12:46.39 | mdrobnak | Captnoord, lol |
| 12:46.42 | ali1234 | so none of that explains why enabling the upper bank is causing a crash |
| 12:46.54 | mdrobnak | LOL |
| 12:47.19 | mdrobnak | I think I should try changing 89 -> 115 and seeing if that doesn't crash. I think it's going to. |
| 12:47.40 | mdrobnak | Alas, I'm working on PF firewall rules, then need to go to work. |
| 12:47.40 | ali1234 | unless the dynamically allocated ram has to be in the samr ram bank as the pmem sections (which is entirely possible, and you should check what other memory the drivers allocate) |
| 12:48.15 | Captnoord | I think its totaly related to android as cr2 mentioned he tested this all with ramdisk stuff |
| 12:48.17 | Captnoord | or |
| 12:48.18 | Captnoord | memtest |
| 12:48.21 | Captnoord | or what ever |
| 12:49.12 | ali1234 | anyway you slice it, a kernel crash is a kernel bug |
| 12:51.01 | mdrobnak | Well, here's the thing - has anyone tested something OTHER then Android that was not just a ramdisk running a memory test? Ie, used the framebuffer, and sound, at the same time? |
| 12:51.17 | mdrobnak | I did the ramdisk thing too, and it worked fine. |
| 12:51.33 | mdrobnak | But obviously something's not right. |
| 12:51.51 | mdrobnak | If someone had a working OpenMoko build I'd try that. |
| 12:52.03 | mdrobnak | I tried looking into it, and it looked like a pain to build. |
| 12:54.52 | ali1234 | try a gizard rootfs |
| 12:54.54 | Captnoord | lol |
| 12:55.00 | ali1234 | it has a framebuffer X server |
| 12:55.01 | Captnoord | maybe check pmem_android.h |
| 12:55.20 | Captnoord | android_pmem.h |
| 12:55.26 | Captnoord | just speaking my mind guys |
| 12:55.51 | mdrobnak | Same with all of us, lol. |
| 12:56.02 | ali1234 | lots of rootfs tarballs here you can play with: http://tinderbox.dev.gentoo.org/embedded/linwizard |
| 12:56.33 | ali1234 | the binaries should be ok on msm, even if not fully optimized, they should at least run |
| 12:56.35 | mdrobnak | What's that compiled for? Will that work on the MSM? |
| 12:56.45 | mdrobnak | lol nevermind |
| 12:57.19 | ali1234 | we dont have any sound support in there |
| 12:57.38 | ali1234 | no sound on our phones yet |
| 12:57.55 | mdrobnak | well, why wouldn't we? Our kernel has support, no? |
| 12:58.11 | ali1234 | probably not alsa sound, no |
| 12:58.19 | mdrobnak | Oh. |
| 12:58.28 | ali1234 | but either way we have no apps in those tarballs that can use sound |
| 12:58.51 | mdrobnak | Well, if the drivers are loaded, and we can exercise video, that's a start. |
| 12:58.58 | mdrobnak | (audio drivers) |
| 12:59.07 | mdrobnak | (not alsa audio, I know) |
| 13:00.22 | mdrobnak | Anyway, off to get ready for work. Back in 8-9 hours. |
| 13:08.10 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 13:08.20 | *** join/#htc-linux GlemSom (n=glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk) |
| 13:17.46 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 13:21.37 | *** join/#htc-linux Zinbolic (n=zinbolic@84.238.80.215) |
| 13:28.42 | *** join/#htc-linux townkat_work (n=townkat_@89.122.203.209) |
| 13:40.44 | ali1234 | yeah, excalibur it is |
| 13:40.55 | ali1234 | whoops, wrong window |
| 13:45.04 | *** join/#htc-linux scheich (n=georg@79.197.219.51) |
| 13:51.18 | *** join/#htc-linux MethoS- (n=clemens@134.102.106.250) |
| 13:58.46 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 14:10.52 | *** part/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 14:31.36 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 15:04.16 | *** join/#htc-linux SOG (n=SOG@n219079053203.netvigator.com) |
| 15:22.15 | *** join/#htc-linux luc (n=luc@89-115-128-35.cl.ipv4ilink.net) |
| 15:28.17 | *** join/#htc-linux richard333 (n=richard@adsl-072-149-006-119.sip.mia.bellsouth.net) |
| 15:28.22 | richard333 | hey guys |
| 15:32.31 | richard333 | adb devices returns my phone |
| 15:32.34 | richard333 | but when i try eclipse |
| 15:32.40 | richard333 | its not detected there |
| 15:32.43 | richard333 | running windows xp 32bit |
| 15:35.59 | richard333 | ddms works it shows the running processes |
| 15:36.11 | richard333 | but i can't get eclipse w adt working, anyone help pls? |
| 15:41.23 | *** join/#htc-linux Zinbolic (n=zinbolic@84.238.80.215) |
| 15:48.58 | *** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
| 15:55.03 | *** join/#htc-linux onen|openBmap (n=quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
| 15:58.33 | *** join/#htc-linux jarski (n=jarski@82-128-214-231-Karjasilta-TR1.suomi.net) |
| 16:01.49 | *** join/#htc-linux jarski (n=jarski@82-128-214-231-Karjasilta-TR1.suomi.net) |
| 16:13.32 | *** join/#htc-linux pH5 (n=ph5@e178215097.adsl.alicedsl.de) |
| 16:32.34 | *** join/#htc-linux stickboy (n=anonymou@128.153.211.18) |
| 16:38.43 | jarski | Hi guys, I have blac100. I took latest raphael android package from connect UTB and replaced kernal image with dwaradzyns and it boots... |
| 16:39.37 | jarski | but I get message box in android that "power off" shutting down |
| 16:40.28 | jarski | I guess it is something with pm and battery |
| 16:40.57 | jarski | any ideas how to get pass that problem? |
| 16:59.25 | *** join/#htc-linux stickboy (n=anonymou@128.153.178.77) |
| 17:04.17 | *** join/#htc-linux randomblame (n=kevin@173.12.174.62) |
| 17:08.26 | *** join/#htc-linux FR^2 (n=frquadra@frquadrat.de) |
| 17:09.02 | randomblame | We gonna rock down to Electric Avenue |
| 17:09.02 | randomblame | And then we'll take it higher |
| 17:24.58 | *** join/#htc-linux MrPippy (n=pip@adsl-75-36-57-196.dsl.sndg02.sbcglobal.net) |
| 17:26.17 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 17:28.54 | *** join/#htc-linux balans (n=Administ@83.84.58.101) |
| 17:36.08 | *** join/#htc-linux Nanto (n=Vegita@54031C33.catv.pool.telekom.hu) |
| 17:47.18 | richard333 | hey jarski r u there? |
| 17:47.47 | jarski | yep |
| 17:48.13 | richard333 | i have a raph100 |
| 17:48.21 | richard333 | and i tried the latest pckg from connect utb |
| 17:48.35 | richard333 | do the files go in the root of the sd or do they go in sd/tmp like before? |
| 17:48.48 | jarski | root |
| 17:50.08 | richard333 | have u gotten it to boot up yet? |
| 17:50.16 | richard333 | btw whats a blac100? |
| 17:50.37 | jarski | blac100 is blackstone i.e. touch HD |
| 17:51.21 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 17:52.09 | richard333 | nice, have u seen the htc leo? |
| 17:52.45 | randomblame | lol if I owned a touch hd I'd be pissed off to see the leo |
| 17:52.58 | jarski | :) |
| 17:53.07 | richard333 | or excited to have an even better phone down the line |
| 17:53.17 | richard333 | that is if u can afford to sell ur current one and pay the difference |
| 17:53.57 | richard333 | id get the touch hd but theres no usa 3g |
| 17:54.13 | randomblame | yeah thats a serious drawback |
| 17:55.58 | randomblame | oooh Karmic Koala comes out oct. 29 |
| 17:57.55 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 17:58.35 | *** part/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 18:04.56 | richard333 | alright great its running |
| 18:04.59 | richard333 | but its super slow |
| 18:05.17 | richard333 | its not even the hero build and its hella slow trying to do anything |
| 18:05.34 | jarski | ok :) |
| 18:06.15 | richard333 | how can i browse my phone's content on android via usb on my computer? |
| 18:06.29 | richard333 | i tried ddms file explorer but it doesnt load anything |
| 18:10.11 | thedicemaster | i think it's easier to just do that in windows mobile. |
| 18:11.28 | *** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
| 18:14.43 | richard333 | yeah but having to restart to go to winmo, just to copy a file to the system seems kinda impractical |
| 18:14.53 | richard333 | i'd like to remove any dependencies to having to go to winmo |
| 18:26.31 | *** join/#htc-linux stickboy (n=anonymou@128.153.178.77) |
| 18:30.19 | *** join/#htc-linux pleemans (n=toi@84.194.169.109) |
| 18:46.42 | *** join/#htc-linux cr2 (n=cr2@109.85.29.232) |
| 18:47.22 | *** join/#htc-linux dwaradzyn (n=chatzill@chello089079067084.chello.pl) |
| 18:47.27 | dwaradzyn | hi cr2 |
| 18:48.08 | dwaradzyn | cr2: could you summarize how audiopaths should be changed in order to enable audio for blac100 (and not break other devices)? |
| 18:49.22 | dwaradzyn | i think its the msm_audio_path(int i) in msm_hw.c is our target. but what is missing there? |
| 18:51.22 | cr2 | dwaradzyn: you need to load some data for the dsp at some magic address |
| 18:52.00 | cr2 | dwaradzyn: do you know how dzo accesses /sys/class/vogue_hw/audio in the android libs ? |
| 18:52.44 | dwaradzyn | cr2: no. i can look into it, if it is the right thing to do |
| 18:53.07 | cr2 | i think that the current config is phone-only |
| 18:53.27 | cr2 | the code for kaiser is more extensive |
| 18:54.02 | cr2 | but afaik the kaiser does not support BT headset |
| 18:55.57 | *** join/#htc-linux kiozen (n=kiozen@rgnb-5d87d769.pool.mediaWays.net) |
| 18:57.00 | cr2 | hi kiozen |
| 18:57.30 | kiozen | hi cr2 |
| 18:58.19 | kiozen | any news in the htc-linux corner? |
| 18:58.29 | kiozen | looking forward to the palm pre |
| 18:58.59 | kiozen | think this will be my 1st smart phone |
| 18:59.09 | *** join/#htc-linux pr0p (n=asdf@87.70.54.117) |
| 19:01.10 | cr2 | we are moving forward, the only difficult thing remaining is BT |
| 19:01.22 | cr2 | does palm pre support gps ? |
| 19:01.34 | cr2 | which cpu is that ? |
| 19:02.42 | dwaradzyn | cr2: i see it now. it is far more complicated in htc-vogue branch. there is a lot of magic in that code too |
| 19:03.02 | kiozen | cr2: yes has gps |
| 19:03.35 | pr0p | hello cr2 and dwaradzyn : came from the xda forums :) , with my HTC in my hand ! |
| 19:03.54 | cr2 | kiozen: which gps chip ? |
| 19:04.38 | pr0p | can i compile with portable ubuntu ? or i have to compile on a non-portable one ? |
| 19:04.46 | kiozen | cr2: http://de.wikipedia.org/wiki/Palm_Pre |
| 19:04.46 | cr2 | dwaradzyn: i think you should dump the 0x140 bytes for +0xfc300 for each audio state. |
| 19:05.24 | cr2 | dwaradzyn: it's a tedious work, but i don't see any other way to do it. |
| 19:05.39 | dwaradzyn | cr2: indeed we currenty have audio path 2 and 5 which seem to be phone audio start and phone audio end. does audio work only for calling on raphs and diams now? |
| 19:06.32 | dwaradzyn | cr2: well i'll try to do that. its a chance to get familiar with haret. and repeticio mater studiores est :) |
| 19:06.35 | cr2 | 2 and 5 are "random" numbers |
| 19:06.43 | cr2 | lol |
| 19:07.02 | *** join/#htc-linux MrPippy_ (n=pip@adsl-75-36-57-196.dsl.sndg02.sbcglobal.net) |
| 19:07.12 | cr2 | dwaradzyn: actually you may dump the whole audio-relevant area |
| 19:07.22 | cr2 | of even the full 1MB each time |
| 19:07.58 | cr2 | kiozen: nothing about gps ? |
| 19:08.35 | cr2 | 320x480 |
| 19:08.41 | kiozen | hm, seems to be agps :( |
| 19:09.12 | cr2 | it may mean everythng |
| 19:09.49 | *** join/#htc-linux osilvan (n=o@87.222.122.224) |
| 19:09.50 | cr2 | on msm they use phone DSP to process the gps signal |
| 19:15.06 | kiozen | beats me, I can't find any information about the chip |
| 19:21.04 | dwaradzyn | pr0p: don't know |
| 19:23.02 | cr2 | dwaradzyn: actually it may be an easier way than to analyze the wavedev.dll disassembly |
| 19:24.05 | cr2 | dwaradzyn: btw, where did you get the alt gpio settings for blac100 SD ? |
| 19:25.02 | dwaradzyn | cr2: ? |
| 19:25.43 | dwaradzyn | cr2: for the xda builds i only changed max clock rate, nothing else |
| 19:26.27 | cr2 | each alt gpio has the alt parameter (write-only) |
| 19:27.00 | cr2 | sdc3 DAT3 2,184,0 |
| 19:27.03 | cr2 | things like that |
| 19:27.17 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 19:27.30 | *** join/#htc-linux patp (n=patp@87-194-56-160.bethere.co.uk) |
| 19:27.34 | cr2 | blac100 values are not entered here -> http://www.htc-linux.org/wiki/index.php?title=Raphael_GPIO |
| 19:28.02 | cr2 | they may be the same as raph100, but it needs to be checked. |
| 19:28.14 | patp | dwaradzyn hi |
| 19:28.32 | dwaradzyn | patp: hi |
| 19:28.33 | cr2 | i want to edit topaz wiki, and think about the best layout for them |
| 19:29.05 | *** join/#htc-linux yak007 (n=yak007@ip4da92b8e.direct-adsl.nl) |
| 19:29.45 | patp | still some prob getting sd support using your kernel build; I don't get it, I have /dev/mmcblk0p1 using the old build but not with your new one. |
| 19:30.27 | cr2 | patp: do you have the sdhc.dll from your phone ? |
| 19:30.32 | tmzt | hey cr2 |
| 19:30.39 | tmzt | pulling |
| 19:30.48 | cr2 | tmzt: hehe :) |
| 19:31.02 | patp | cr2: need reboot, hangon |
| 19:31.16 | tmzt | cr2: Pre is omap3450 |
| 19:31.28 | cr2 | tmzt: what about gps ? |
| 19:31.40 | tmzt | probably in the msm6800, not sure though |
| 19:32.45 | cr2 | ok |
| 19:32.58 | tmzt | we are using apm emulations? |
| 19:33.11 | cr2 | don't know |
| 19:33.29 | *** join/#htc-linux dcordes (n=luke@unaffiliated/dcordes) |
| 19:33.42 | dcordes | hi |
| 19:33.44 | dwaradzyn | tmzt: i think palm pre is omap3430 (same as nokia n900) |
| 19:34.40 | tmzt | ah, yeah |
| 19:34.49 | cr2 | dcordes: what do you think about becoming the haret patch master ? |
| 19:36.06 | *** part/#htc-linux droid0011 (n=g1@p4FDCEBEB.dip.t-dialin.net) |
| 19:36.48 | dcordes | cr2, that would be nice. but I can't tell how much time I will have left for all this when university starts in few days. |
| 19:36.49 | dwaradzyn | patp: mmc works for me out of the box. i don't have another card atm to test but sandisk 16gb class2 works every time |
| 19:38.09 | cr2 | dcordes: ok |
| 19:39.17 | *** join/#htc-linux yak0072 (n=yak007@ip4da92b8e.direct-adsl.nl) |
| 19:39.52 | *** join/#htc-linux onen|openBmap (n=quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) [NETSPLIT VICTIM] |
| 19:42.31 | patp | cr2: http://www.4shared.com/file/134636931/5e370968/SDHC.html |
| 19:43.37 | patp | dwaradzyn: mine's a Sandisk 4gb class 4. |
| 19:45.20 | yak0072 | hi all, have a question about the latest blac kernel and the raphael andriod port, it boots but it goes straight to shutdown? |
| 19:45.49 | yak0072 | and tnx for all the work on the kernelstuff |
| 19:46.07 | yak0072 | is it possible to "disable" the poweroff? |
| 19:47.01 | dwaradzyn | patp: i am incredibly lucky with sd cards and linux then :) on my polaris it was working too when others reported that it is not working for them... could you pastebin full dmesg? |
| 19:51.51 | townkat | dwaradzyn: how close are we to android with audio ? |
| 19:52.33 | tmzt | on? |
| 19:52.39 | dwaradzyn | townkat: not really close. a lot of reversing is needed for blac |
| 19:54.34 | *** join/#htc-linux pattp (n=patp@87-194-56-160.bethere.co.uk) |
| 19:55.08 | pattp | sorry, got bsod. |
| 19:55.13 | cr2 | lol |
| 19:55.59 | thedicemaster | better look up the error on that BSoD |
| 19:56.09 | pattp | dwaradzyn: can't get dmesg, as I haven't been able to do the ssh over usb thing in windows or vbox-ubuntu |
| 19:56.40 | pattp | thedicemaster: nah, it immediately rebooted. screw it, when you use windows, it's like weather. |
| 19:57.05 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 19:57.10 | dwaradzyn | pattp: you can dump ram_console (in haret use command "pwf ram_console.txt 0xe000d 0x20000") |
| 20:01.08 | cr2 | hm. the DEX crash may be avoided if the code will check the dex_ready flag. |
| 20:06.01 | luc | hey cr2 |
| 20:06.16 | luc | what driver do you use for wireless? |
| 20:06.22 | luc | ti or Kalle Valo ? |
| 20:07.10 | tmzt | I'm trying something, I've split out the cdma500 and cloned the diam include file |
| 20:07.19 | cr2 | luc: not yet |
| 20:07.41 | luc | will be beter tu use Kalle Valo ? |
| 20:07.48 | pattp | dwaradzyn: OK, I have haretconsole connected. when I run that cmd it produces a file on the phone, but that file doesn't have dmesg in. Should I boot linux? |
| 20:08.02 | luc | did you test any of them? |
| 20:08.05 | tmzt | I hope to rename that to raph-smi32 raph-smi64 or something similar |
| 20:08.43 | cr2 | tmzt: on may phones this config is reported by oemsbl/amss in smem |
| 20:08.51 | cr2 | s/may/many/ |
| 20:08.54 | tmzt | what is? |
| 20:09.01 | dwaradzyn | pattp: yes. after reset repeat haret thing. do you use my build? |
| 20:09.10 | pattp | dwaradzyn, no wait, I'm an idiot, it is a dmesg. I didn't recognise it, not being white on black! |
| 20:09.32 | cr2 | tmzt: 32 vs 64 |
| 20:09.41 | tmzt | ah, ok |
| 20:09.55 | tmzt | I can add the detect later but I already have an mtype |
| 20:10.01 | cr2 | ok |
| 20:10.14 | tmzt | HTC Raphael CDMA phone 500 (MACH_HTCRAPHAEL_CDMA500) [Y/n/?] (NEW) y |
| 20:10.18 | cr2 | if there any ANDROID config option ? |
| 20:10.27 | tmzt | I wonder if I ever included the proper mach definition before |
| 20:10.48 | cr2 | so the android-specific things can be wrapped |
| 20:11.14 | tmzt | on 2.6.31 |
| 20:11.58 | pattp | dwaradzyn: https://privatepaste.com/20K4Dlkx0j |
| 20:12.21 | tmzt | now it's not booting at all |
| 20:12.26 | pattp | kernel was compiled from new git clone today |
| 20:16.04 | cr2 | pll0=mpll |
| 20:16.18 | cr2 | topa nk is interesting |
| 20:16.33 | tmzt | is it tcx0 or tcxo? |
| 20:16.47 | tmzt | tcxo is temperature-controller crystal oscillator |
| 20:16.59 | tmzt | controlled |
| 20:21.11 | pattp | [ 3.383178] mmc0: Slot eject status = 1 |
| 20:21.18 | tmzt | what client chip is raphael panel for? |
| 20:21.22 | pattp | [ 3.577697] mmc1: Slot eject status = 0 |
| 20:21.44 | cr2 | bic 0xa00 |
| 20:21.59 | cr2 | tmzt: tcx0 is 19.2MHz |
| 20:22.02 | pattp | [ 75.956054] mmc1: Slot status change detected (1 -> 0) |
| 20:22.25 | cr2 | bic 0xa00 for clock disable ? |
| 20:22.34 | tmzt | we have so many symbol conflcts |
| 20:22.36 | cr2 | i2c in this case |
| 20:22.57 | cr2 | raph should support epson and tishiba |
| 20:23.16 | tmzt | is there a reason for including the board header in that file? |
| 20:25.08 | tmzt | I can't see why, (in mmc), it uses gpio numbers not names |
| 20:25.35 | cr2 | tmzt: ? |
| 20:26.02 | tmzt | ok, in -panel it's the resources |
| 20:26.05 | cr2 | we need to add human readable names for toshiba and epson, since we know them |
| 20:26.08 | tmzt | maybe we should move that to the board |
| 20:26.23 | tmzt | right, but that should be by client/lcm, not machine |
| 20:26.30 | cr2 | tmzt: it's much better in codeaurora code |
| 20:26.35 | tmzt | yeah, true |
| 20:26.43 | tmzt | but I'm trying to avoid duplication |
| 20:27.18 | tmzt | and we need to keep our tree buildable also |
| 20:27.40 | *** join/#htc-linux c4software (n=Adium@roo49-2-88-161-139-221.fbx.proxad.net) |
| 20:30.07 | pattp | hmmm. anyone know where mtype sets the sdcc id? |
| 20:30.22 | tmzt | per device fixup? |
| 20:32.43 | cr2 | pattp: ok, looking at your file |
| 20:35.13 | c4software | hi everyone |
| 20:35.14 | c4software | :) |
| 20:36.30 | cr2 | alt is 48 |
| 20:38.54 | cr2 | 48 on raph100 too |
| 20:38.56 | cr2 | hmm |
| 20:39.50 | cr2 | vreg is 800000 |
| 20:40.20 | cr2 | "gp6",BT 23 0x800000 |
| 20:40.51 | cr2 | the same on rarh100 |
| 20:41.49 | cr2 | sd detect 026 |
| 20:42.09 | cr2 | like on raph800 |
| 20:42.25 | c4software | always any sign of dzo ? |
| 20:42.27 | cr2 | dwaradzyn: which sd detect pin you use ? |
| 20:42.31 | tmzt | how do I get this to boot/init the htcfb again? |
| 20:42.36 | tmzt | I'm using the same code |
| 20:42.54 | dzo | i'm here but only for 5 mins |
| 20:42.55 | dwaradzyn | cr2: how do i find that out? |
| 20:43.30 | c4software | dzo, have you seen my pm ? |
| 20:44.15 | c4software | for the backlight issue when you have disabled the pwrsync option ? |
| 20:45.27 | dzo | it looks like the mddi commands are correct perhaps the client power is slightly different or it could be timing problems. |
| 20:46.13 | dzo | i think it's close, you will need to do some more tracing. try tracing gpios while turning the panel on. |
| 20:46.20 | c4software | the backlight is correctly turned off. But the screen say on. (with the panel option at 2 in startup.txt |
| 20:46.49 | c4software | if you explain how i have to do this i will do this for you :) |
| 20:47.36 | cr2 | .sdcard_status_gpio = 38, |
| 20:47.42 | cr2 | dwaradzyn: it's ok |
| 20:48.21 | cr2 | dwaradzyn: must be something else |
| 20:48.30 | dzo | sorry, i don't have time now, i'll look at the code later and see if i can spot anything. the gpio addresses to trace are 0xb2e00000 + 0x00400000 |
| 20:49.05 | dwaradzyn | cr2: i have four times mmc1: command timeout in dmesg. but no more |
| 20:49.26 | c4software | okay. i note this on a document on my computer. maybe some people can help my to trace gpio :) |
| 20:50.02 | dzo | c4software: you are using the diamond mtype right? |
| 20:50.02 | c4software | if i found something i send to you a pm |
| 20:50.38 | c4software | okay ? |
| 20:50.40 | c4software | yep |
| 20:50.45 | dzo | thanks, a dmesg might help too. |
| 20:51.04 | c4software | i Used the 1805 mtype |
| 20:52.36 | pattp | cr2, dwaradzyn: do you want to see a dmesg from a boot that works (using kernel from Feb)? |
| 20:53.55 | *** join/#htc-linux Reactor16 (n=Reactor1@ns1.ultravpn.fr) |
| 20:54.20 | dwaradzyn | pattp: not needed. but you may want to see mine dmesg. its at: http://pastebin.com/m258f5cf3 |
| 20:54.53 | c4software | someone have time to help me to track gpio and dmesg ? |
| 20:56.14 | tmzt | ah, I left out a mach check in -panel |
| 20:56.21 | tmzt | but it worked before |
| 20:57.23 | townkat | i am building a linux virtual machine with vmware , what linux distribution should i use for kernel building ? |
| 20:57.37 | ali1234 | ubuntu |
| 20:57.51 | tmzt | ubuntu server is fine |
| 20:57.59 | townkat | thnx |
| 20:58.25 | c4software | anyone :$ |
| 20:59.02 | pattp | dwaradzyn: what ROM do you have on your HD? Mine is Topix 3.0, which is a mongrel build |
| 20:59.34 | *** join/#htc-linux dwaradzyn (n=chatzill@chello089079067084.chello.pl) |
| 21:00.21 | ali1234 | c4software: did you read this http://handhelds.org/moin/moin.cgi/HaRET_20Documentation ? |
| 21:00.33 | c4software | im on it :) |
| 21:00.57 | dwaradzyn | pattp: duttys xt 3.3. i think rom this does not matter here |
| 21:01.45 | c4software | i always forgot the haret shell. ^^ |
| 21:02.08 | c4software | thanks for the link ali1234 :) |
| 21:06.07 | pattp | dwaradzyn: are you sure it doesn't matter? The hw is initialized by windows drivers, maybe there is something different in the Topix ROM - some of the drivers are from Topaz for example. |
| 21:07.19 | ali1234 | apt, gpio tracing? |
| 21:07.20 | apt | somebody said gpio tracing was at http://handhelds.org/moin/moin.cgi/HaRET_20Documentation |
| 21:07.20 | c4software | ali1234: you have time to help me a little :$. i'm a little bit confused :S |
| 21:07.25 | ali1234 | \o/ |
| 21:07.52 | ali1234 | c4software: what's up? |
| 21:08.05 | c4software | i think i tracing the good things wirq 0xb2e00000 << to trac the 0xb2e00000 adress its correct ? |
| 21:08.26 | ali1234 | dunno, that doesn't sound like gpios |
| 21:09.09 | ali1234 | i never tried to trace interrupts |
| 21:09.57 | c4software | erf :S |
| 21:10.45 | townkat | tmzt, why server? desktop won't do it ? |
| 21:11.51 | ali1234 | townkat: because kernel compile is done entirely in a shell, installing desktop will just waste space and cpu time |
| 21:12.16 | townkat | thnx |
| 21:12.51 | ali1234 | also i think you need to install from the server disk to get a kernel with pae support, without that it wont work in a vm |
| 21:13.01 | ali1234 | although they may have fixed that by now |
| 21:13.40 | c4software | damn |
| 21:13.42 | c4software | HaRET(3)# clear TRACES |
| 21:13.42 | c4software | HaRET(4)# addlist TRACES p2v(0xb2e00000) |
| 21:13.43 | c4software | HaRET(5)# wirq 10 |
| 21:13.46 | townkat | i am downloading the server right now, i may need more help later, thnx alot :) |
| 21:13.49 | c4software | its hang the telnet conenction :S |
| 21:14.04 | c4software | and my diamond too :S |
| 21:14.31 | ali1234 | it will hang for 10 seconds |
| 21:14.56 | c4software | oO |
| 21:15.01 | c4software | why ? |
| 21:15.20 | ali1234 | because tracing all interrupts is quite processor intensive |
| 21:15.29 | ali1234 | and you told it to do it for 10 seconds |
| 21:15.58 | c4software | i have sft reset the phone i will do this again. but i maybe don't watch the good things ? |
| 21:16.04 | c4software | i'm not sure |
| 21:17.26 | c4software | i have restart the command :) wait for a result |
| 21:18.17 | ali1234 | try wirq 1 first |
| 21:18.22 | ali1234 | 1 second |
| 21:18.58 | c4software | damn connectin with diamond lost. |
| 21:21.48 | c4software | wirq 1 |
| 21:21.59 | c4software | waiting for a result |
| 21:22.13 | ali1234 | hmm |
| 21:22.45 | c4software | diamond hang. damn :P |
| 21:22.49 | ali1234 | wel, irqs are tricky, if the wrong one is lost, it will crash |
| 21:23.00 | c4software | i do something wrong maybe |
| 21:24.14 | ali1234 | maybe you didn't filter the irqs with ibit, and it is just spamming itself to death |
| 21:24.48 | ali1234 | or maybe it just doesnt work on your hardware yet |
| 21:25.40 | c4software | on diam100 ? |
| 21:26.21 | c4software | joinlist TRACES GPIOS << If i do this its seems working |
| 21:26.34 | c4software | i have a lot of data on screen |
| 21:26.35 | c4software | :D |
| 21:26.55 | c4software | but its all GPIOS i just want 0xb2e00000 |
| 21:27.32 | ali1234 | you probably want mmutrace for tracing memory access? |
| 21:28.53 | c4software | to be exact i don't really know what exactly i have to trace : dzo say to me "the gpio addresses to trace are 0xb2e00000 + 0x00400000" |
| 21:31.53 | ali1234 | i'm not familiar with that hardware architecture so i can't help any further, sorry |
| 21:32.50 | c4software | no problem :) thanks for your help ali1234:) |
| 21:43.00 | *** join/#htc-linux cr2 (n=cr2@109.85.29.232) |
| 21:43.28 | *** join/#htc-linux [1]Captnoord (n=Captnoor@81.71.164.123) |
| 21:44.54 | cr2 | lol, it was some java programmer |
| 21:44.58 | cr2 | <PROTECTED> |
| 21:45.00 | cr2 | <PROTECTED> |
| 21:45.03 | cr2 | <PROTECTED> |
| 21:45.03 | cr2 | <PROTECTED> |
| 21:52.21 | cr2 | <PROTECTED> |
| 21:52.23 | cr2 | <PROTECTED> |
| 21:52.24 | cr2 | <PROTECTED> |
| 21:52.26 | cr2 | <PROTECTED> |
| 21:52.27 | cr2 | <PROTECTED> |
| 21:52.39 | cr2 | quite different numbers. for msm7x27 |
| 21:54.05 | cr2 | real innovation in usb functions. tcp/ip is not good enough. |
| 21:54.35 | tmzt | more usb functions? |
| 21:55.45 | cr2 | <PROTECTED> |
| 21:55.47 | cr2 | <PROTECTED> |
| 21:56.12 | cr2 | cdc_ether is not include. |
| 21:56.15 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 21:56.56 | cr2 | wtf i would like generic nmea usb multiplexed function ? |
| 21:57.06 | cr2 | i will better run gpsd over cdc_ether |
| 21:58.22 | cr2 | we need to recheck the SND endpoint list: |
| 21:58.25 | cr2 | <PROTECTED> |
| 21:58.27 | cr2 | <PROTECTED> |
| 21:58.28 | cr2 | <PROTECTED> |
| 21:58.30 | cr2 | <PROTECTED> |
| 21:58.30 | *** join/#htc-linux Patrick_Bateman (n=infidel2@unaffiliated/swc666/x-4934821) |
| 21:58.31 | cr2 | <PROTECTED> |
| 21:58.33 | cr2 | it may be quite different |
| 21:59.03 | cr2 | i know only 4 on raph. |
| 21:59.26 | cr2 | may be different on blac100 (at least the order) |
| 22:00.59 | cr2 | <PROTECTED> |
| 22:01.16 | richard333 | hey guys sorry to disturb, i have a problem on the kaiser sometimes when i make/receive a call the earpiece doesn't work, they can hear me but i cant hear them |
| 22:01.32 | cr2 | they use builtin lcdc more often |
| 22:02.11 | cr2 | richard333: something is wrong in the audio routing, quite complex area ;) |
| 22:04.11 | richard333 | maybe i could change the radio version i have, or do i have to just wait for a newer rom w this issue fixed? |
| 22:04.18 | cr2 | heh |
| 22:04.24 | cr2 | still dm1 ;) |
| 22:04.27 | cr2 | &msm_device_uart_dm1 |
| 22:05.39 | cr2 | it is mdp gpio ? |
| 22:05.43 | cr2 | 1129 static struct msm_panel_common_pdata mdp_pdata = { |
| 22:05.45 | cr2 | 1130 .gpio = 97, |
| 22:06.23 | cr2 | tmzt: i like such code |
| 22:06.26 | cr2 | 1133 static void __init msm_fb_add_devices(void) |
| 22:06.28 | cr2 | 1134 { |
| 22:06.29 | cr2 | 1135 msm_fb_register_device("mdp", &mdp_pdata); |
| 22:06.31 | cr2 | 1136 msm_fb_register_device("pmdh", 0); |
| 22:06.32 | cr2 | 1137 msm_fb_register_device("lcdc", &lcdc_pdata); |
| 22:06.34 | cr2 | 1138 } |
| 22:06.36 | cr2 | want to switch to codeaurora :) |
| 22:10.49 | cr2 | another combination |
| 22:10.54 | cr2 | <PROTECTED> |
| 22:10.55 | cr2 | <PROTECTED> |
| 22:10.57 | cr2 | <PROTECTED> |
| 22:10.58 | cr2 | <PROTECTED> |
| 22:11.00 | cr2 | <PROTECTED> |
| 22:11.54 | townkat | is this guide good for blac too ? |
| 22:11.54 | townkat | http://htc-android.com/viewtopic.php?f=13&t=172 |
| 22:16.07 | townkat | never mind, i found the one for blackstone |
| 22:16.37 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 22:20.17 | tmzt | cr2: what is this? |
| 22:20.28 | tmzt | I like the msm_fb_register_device |
| 22:20.34 | tmzt | I would also like to see htc_hw used |
| 22:21.55 | *** join/#htc-linux kvaster (n=kvaster@live.bn.by) |
| 22:25.56 | townkat | is this adress good ? git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git |
| 22:26.41 | townkat | is in the wiki and is pretty old, i was wondering if its still actual |
| 22:30.08 | cr2 | PM 0x30000061 pm_* |
| 22:30.11 | cr2 | tmzt: aa |
| 22:30.26 | cr2 | #define PMIC_RPC_PROG 0x30000061 |
| 22:31.40 | cr2 | <PROTECTED> |
| 22:31.41 | cr2 | <PROTECTED> |
| 22:32.08 | cr2 | 23,24 on raph |
| 22:32.19 | tmzt | I can't figure this out |
| 22:32.29 | tmzt | raph100? |
| 22:32.53 | cr2 | 107 #define MIC_SET_VOLT_PROC 30 |
| 22:33.11 | cr2 | 28 on raph100 |
| 22:34.09 | *** join/#htc-linux Untouchab1e (n=Untoucha@239-15-8.connect.netcom.no) |
| 22:43.45 | cr2 | <PROTECTED> |
| 22:46.07 | tmzt | well, I think I might have found the problem |
| 22:46.18 | tmzt | -gps.o is only included on HTCRAPHAEL, not the cdma devices |
| 22:46.24 | tmzt | but it's in the devices list |
| 22:47.24 | cr2 | cdma is different |
| 22:47.38 | tmzt | yeah, so I can't see why it's in the list |
| 22:47.58 | tmzt | the framebuffer is not being initialized now that I've changed the files |
| 22:48.01 | tmzt | and I can't see why |
| 22:48.08 | tmzt | even htc_fb |
| 22:48.14 | cr2 | strange |
| 22:50.10 | cr2 | tmzt: do we demux the dex irqs ? |
| 22:50.22 | cr2 | i doubt it |
| 22:50.41 | tmzt | don't think so |
| 22:50.55 | tmzt | we don't even give them irq numbers do we? |
| 22:52.56 | cr2 | m2a_6 |
| 22:57.52 | *** join/#htc-linux cr2 (n=cr2@109.85.29.232) |
| 22:58.07 | cr2 | looks familiar |
| 23:06.53 | tmzt | well, putting the .config back fixes it (with raph800 mtype) |
| 23:07.04 | tmzt | completely lost |
| 23:09.38 | tmzt | ah, it could be because I'm using diam gpios, not raph |
| 23:09.40 | tmzt | in my header |
| 23:09.57 | tmzt | I thought the device fixup would work though |
| 23:12.12 | cr2 | good night |
| 23:29.58 | *** join/#htc-linux mrmoku|a` (n=mrmoku@ppp-93-104-172-111.dynamic.mnet-online.de) |
| 23:43.40 | *** join/#htc-linux stickboy (n=anonymou@128.153.211.18) |
| 23:44.09 | *** join/#htc-linux pronik``` (n=user@g229177001.adsl.alicedsl.de) |