| 00:00.31 | dwaradzyn | brb |
| 00:00.48 | rolk | I see an early kernel message: polaris_init_mmc vreg enable failed (-1071542728) |
| 00:01.03 | dcordes_ | I think it's also on the kaiser |
| 00:02.38 | *** join/#htc-linux dwaradzyn (n=chatzill@chello084010231017.chello.pl) |
| 00:03.26 | rolk | I have to call it a night. It's 1 am, and I need some sleep. See you. |
| 00:03.37 | dwaradzyn | see you too |
| 00:08.40 | NetRipper | anyone with a diamond present? |
| 00:09.34 | kimhoon | gsm or cdma? |
| 00:09.41 | NetRipper | doesn't matter |
| 00:10.07 | kimhoon | ok |
| 00:10.34 | kimhoon | ive got diamond (gsm) |
| 00:10.41 | NetRipper | ok, sec, uploading |
| 00:10.46 | NetRipper | can you try a kernel for me? |
| 00:10.56 | kimhoon | yup |
| 00:11.39 | NetRipper | http://www.netripper.com/raphael/20081213_zImage_test |
| 00:11.48 | NetRipper | it has a patch by jobo |
| 00:11.55 | NetRipper | oh crap |
| 00:11.56 | NetRipper | sec |
| 00:11.56 | NetRipper | :) |
| 00:12.29 | NetRipper | abort your download if you started ;) |
| 00:12.36 | kimhoon | ok |
| 00:12.47 | NetRipper | ok you can redownload |
| 00:12.47 | NetRipper | ;) |
| 00:14.33 | NetRipper | keyboard should be enhanced |
| 00:14.35 | NetRipper | you can open/close it |
| 00:14.52 | NetRipper | (at least, when you're in android, it will draw over it next time) |
| 00:15.19 | dwaradzyn | good night |
| 00:15.36 | NetRipper | and for raphael it will go into landscape when you open the keyboard, but that doesn't apply to raph ;) |
| 00:16.13 | NetRipper | and it shouldn't flicker when loading android |
| 00:16.23 | kimhoon | test it now |
| 00:24.19 | toer | oo |
| 00:25.09 | kimhoon | Netripper. it doesn't flicker but ive got the wrong image for android :) lol |
| 00:25.14 | toer | ill go to bed and backlog the last week tomorrow :) any special progress on the raphael/diamond side? |
| 00:25.53 | NetRipper | lol ok then you probably can't test whether keyboard disappeasr when you use the on screen toggle |
| 00:25.56 | NetRipper | ;) |
| 00:25.59 | NetRipper | as it'll stay there |
| 00:29.24 | kimhoon | withs image can i use?? |
| 00:29.44 | kimhoon | sorry for android |
| 00:31.11 | NetRipper | ah |
| 00:31.12 | NetRipper | sec |
| 00:31.27 | NetRipper | http://www.netripper.com/raphael/20081204-01_raph_diam_android_v0.8/ |
| 00:31.57 | NetRipper | am just fixing the yellow dot drawing now |
| 00:34.29 | kimhoon | netripper sorry cmdline 94m or 96?? |
| 00:34.52 | NetRipper | 96 |
| 00:35.15 | kimhoon | thanks |
| 00:35.33 | NetRipper | i doubt those 2 megs will make a difference |
| 00:35.36 | NetRipper | but i've always used 96 |
| 00:35.37 | NetRipper | ;) |
| 00:35.59 | kimhoon | i don't know lol |
| 00:37.12 | kimhoon | the files from you its stuck on "trouw_pwrsink_set:stub!" do i something wrong?? |
| 00:37.33 | NetRipper | hm |
| 00:37.41 | NetRipper | if you tap anywhere on the scree |
| 00:37.44 | NetRipper | nothing happens? |
| 00:37.48 | NetRipper | and no virtual keyboard? |
| 00:37.50 | kimhoon | nothing |
| 00:37.52 | kimhoon | nope |
| 00:37.55 | NetRipper | strange |
| 00:38.11 | NetRipper | try copying everything to your internal memory (not internal storage) |
| 00:38.18 | kimhoon | ok |
| 00:39.03 | NetRipper | then run, that seems to fix it.. dont understand why it hangs though |
| 00:39.03 | NetRipper | maybe it's my compiler |
| 00:39.55 | NetRipper | you have to replace it with the other kernel though |
| 00:40.11 | NetRipper | that link i gave you first :p |
| 00:40.11 | kimhoon | the first test i used the old android.bin and that loads wel but the keyboard is vertical and the touch screen doesn't work |
| 00:40.50 | NetRipper | oh |
| 00:40.56 | NetRipper | hm |
| 00:41.12 | NetRipper | it accesses a gpio which is valid for raphael |
| 00:41.16 | NetRipper | but not for diamond |
| 00:47.12 | NetRipper | btw |
| 00:47.18 | NetRipper | the touch screen must be calibrated first with 3 taps |
| 00:47.34 | NetRipper | 1st tap is to initiate calibration, 2nd tap must be top left, 3rd tap is lower right |
| 00:47.41 | NetRipper | after that you can use touch screen in android |
| 00:48.06 | kimhoon | i know |
| 00:52.45 | kimhoon | pfff it still hangs change back to cmdline 96 to 94 lol |
| 00:53.01 | NetRipper | lol ok |
| 00:56.04 | kimhoon | who it works |
| 00:56.11 | kimhoon | cmdline 94m works |
| 00:56.28 | NetRipper | lol omg |
| 00:56.29 | NetRipper | :p |
| 00:56.32 | NetRipper | that's weird |
| 00:56.54 | NetRipper | hmm |
| 00:57.02 | kimhoon | and touchscreen works but uhm keyboard is vertical |
| 00:57.13 | NetRipper | yea ok lol |
| 00:57.26 | kimhoon | and ive got 2 red dots in my display |
| 00:57.27 | NetRipper | let me see what the same gpio is for diamond |
| 00:57.32 | NetRipper | yep those are the calibration dots |
| 00:57.41 | kimhoon | in android?? |
| 00:57.53 | NetRipper | if you calibrated in android, then yes |
| 00:58.08 | NetRipper | if you move the top bar |
| 00:58.15 | NetRipper | the top left dot will be gone |
| 00:58.34 | kimhoon | hmmm |
| 00:58.41 | NetRipper | it only updates where the screen is changed |
| 00:58.47 | NetRipper | the virtual keyboard is a dirty hack |
| 00:58.49 | NetRipper | so is the calibration |
| 01:01.23 | kimhoon | hmm but ive i use your file initrd-android-raphael.cpio.gz it hangs again |
| 01:02.11 | NetRipper | hm |
| 01:02.23 | NetRipper | what is your cmdline? |
| 01:02.43 | kimhoon | i tryd uhm 94 and 96 |
| 01:02.48 | NetRipper | i mean the full cmdline |
| 01:02.54 | NetRipper | do you have anything other next to mem=? |
| 01:03.06 | kimhoon | set cmdline "mem=94M" |
| 01:03.37 | NetRipper | and your ramaddr and ramsize? |
| 01:03.58 | kimhoon | set RAMADDR 0x10000000 |
| 01:04.35 | kimhoon | pffffffff no ramsize |
| 01:04.50 | kimhoon | set RAMSIZE 0x6000000 |
| 01:06.39 | NetRipper | lol ok |
| 01:06.42 | NetRipper | that's fine |
| 01:06.45 | NetRipper | h |
| 01:06.59 | NetRipper | i've seen the other reports that it hangs after STUB messages |
| 01:07.01 | NetRipper | no clue why |
| 01:07.18 | kimhoon | sorry forget the ramsize |
| 01:07.23 | kimhoon | it works |
| 01:07.38 | NetRipper | it works when you set the ramsize? |
| 01:07.42 | kimhoon | yup |
| 01:07.57 | NetRipper | though i think it's more of a coincedence that it works |
| 01:10.29 | kimhoon | calibrations works but the dots are wrong and the keyboard vertical |
| 01:10.55 | kimhoon | must i take a picture off it?? |
| 01:11.09 | NetRipper | dots are wrong? |
| 01:13.11 | kimhoon | the left dot is on the right corner |
| 01:13.19 | NetRipper | ah |
| 01:13.35 | NetRipper | hm.. the console itself is normal right? not landscape |
| 01:14.03 | kimhoon | and the right down corner dot is in the center |
| 01:14.09 | kimhoon | yup |
| 01:14.25 | NetRipper | lol |
| 01:14.32 | NetRipper | ok it probably has to do with the keyboard being landscape |
| 01:15.24 | *** join/#htc-linux woodson (n=CDP@c-76-101-90-149.hsd1.fl.comcast.net) |
| 01:15.33 | kimhoon | but is looks de dots are in landscape but if i calibrate normal its fine lol |
| 01:15.35 | NetRipper | would be nice if there'd be a way to detect raphael runtime |
| 01:17.07 | NetRipper | it uses keyboard code to plot the dots, not directly to framebuffer memory anymore |
| 01:17.20 | NetRipper | and keyboard code takes landscape into consideration |
| 01:17.28 | NetRipper | so the x/y aren't right anymore ;) |
| 01:43.23 | tmzt_ | NetRipper: haret knows it's raph? |
| 01:43.48 | NetRipper | tmzt_, yes, but raphael and diamond share the same mtype at the moment |
| 01:46.50 | tmzt_ | it the update thread working? |
| 01:49.03 | NetRipper | tmzt_, i haven't been working on that |
| 01:49.18 | NetRipper | you mean msm_fb right? |
| 01:50.01 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 01:50.12 | tmzt_ | right, it was discussed earlier in here |
| 01:50.40 | NetRipper | yea |
| 01:50.47 | NetRipper | i haven't dived into that |
| 02:05.27 | *** part/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 02:05.39 | NetRipper | bedtime |
| 02:05.41 | NetRipper | good night |
| 03:06.13 | *** join/#htc-linux Notorious (n=notoriou@ip68-13-242-95.ok.ok.cox.net) |
| 04:03.46 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfe495.pool.einsundeins.de) |
| 06:03.12 | maejrep | tmzt_, yes I did |
| 06:03.17 | maejrep | <NetRipper> maejrep, uncomment the RAMSIZE and set mem=96M in the cmdline |
| 06:03.17 | maejrep | <NetRipper> maejrep, and try this package: http://www.netripper.com/raphael/20081204-01_raph_diam_angstrom_usb/ |
| 06:04.25 | maejrep | I had both of those in default.txt at one time, as you said, and it was the same result. And the "anstrom-usb.cpio.gz" initrd line that is currently commented out in my default.txt is because I had previously tried that |
| 06:05.12 | maejrep | I've tried each of the initrd lines that is commented out in my default.txt, and they all do the same thing |
| 06:38.05 | tmzt_ | maejrep: what size is the initrd's? |
| 06:38.48 | tmzt_ | maejrep: I'm just not familiar with raph/diam as NetRipper and some of the others here have been |
| 06:39.13 | tmzt_ | though have you tried accessing the sd before booting linux, this was suggested earlier |
| 06:40.10 | maejrep | I don't know how |
| 06:40.16 | maejrep | unless you're talking about before starting haret |
| 06:40.31 | maejrep | cause .. I start haret from the sd card |
| 06:41.03 | tmzt_ | ok |
| 06:41.36 | tmzt_ | it's not clear what the latest kernel is from NetRipper |
| 06:41.51 | tmzt_ | suggested using 20081204? |
| 06:42.34 | maejrep | initrd-netripper-busybox-usb = 1.42M, initrd-anstrom-usb = 11.8M, initrd-angstrom = 14.8M, android.bin = 19.8M |
| 06:43.28 | maejrep | right, I've tried using his 20081204 zImage, and it wouldn't get passed console handoff (which seems to imply it was before the mddi patch, or something else broken?) |
| 06:43.41 | maejrep | right now the zImage I'm using I compiled myself |
| 06:46.26 | tmzt_ | console image: http://linuxtogo.org/~lgorris/kaiser-bootkit/angstrom-20081127.cpio.gz |
| 06:47.40 | maejrep | are you suggesting I use that? |
| 06:49.48 | tmzt_ | was trying to find a newer kernel in the log, but only see one made for diam (I think) |
| 06:50.21 | tmzt_ | we (dcordes) usually test with that console image, it's supposed to be small enough for the ram |
| 06:51.06 | tmzt_ | we need to know what the kernel prints at the end, if booting without an initrd does not panic, there's something else wrong |
| 06:51.29 | maejrep | so want me to reboot with no INITRD line? |
| 06:51.41 | tmzt_ | yes, let's try that first |
| 06:51.52 | tmzt_ | also, mem=94M |
| 06:52.08 | maejrep | ok, not 96? |
| 06:52.29 | tmzt_ | yes |
| 06:52.41 | tmzt_ | you lose 2 mb, but it won't matter |
| 06:52.54 | maejrep | k |
| 06:52.57 | maejrep | http://privatepaste.com/59n0n1cebb |
| 06:52.59 | maejrep | booting with that |
| 06:53.47 | tmzt_ | RAMSIZE and RAMADDR are from NetRipper ? |
| 06:54.04 | maejrep | yes |
| 06:54.11 | maejrep | http://www.netripper.com/raphael/20081204-01_raph_diam_angstrom_usb/default.txt |
| 06:54.23 | maejrep | and no good - stops at same spot |
| 06:54.55 | maejrep | It's definitely in the kernel, especially since it only started happening after my last git pull |
| 06:55.44 | tmzt_ | that's 96 mb |
| 06:55.49 | tmzt_ | what are the last lines |
| 06:56.03 | maejrep | also, the 10 second delays before the "GPIO Event Driver" and after "input:halibut_keypad as /class/input/input2" are not in netripper's dmesg |
| 06:56.30 | maejrep | right, the one I copied above was from netripper, not mine :) |
| 06:56.32 | tmzt_ | this is still the halibut kernel? |
| 06:56.38 | maejrep | same kernel yes |
| 06:57.03 | maejrep | the last lines are the same as before, 4x: trout_pwrsink_set:STUB! |
| 06:57.04 | tmzt_ | you mean it's not freezing anymore? |
| 06:57.06 | maejrep | sorry, trout kernel |
| 06:57.13 | maejrep | halibut keypad |
| 06:57.15 | tmzt_ | nothing about rtc ? |
| 06:57.22 | maejrep | yes, the rtc message is there too |
| 06:57.24 | maejrep | same as before |
| 06:57.29 | maejrep | and yes it's freezing at the same spot |
| 06:57.42 | tmzt_ | before those lines, what is the last message from the kernel that's not new debugging stuff |
| 06:58.01 | maejrep | there's nothing new, I haven't added any new debugging to the kernel recently |
| 06:58.10 | tmzt_ | partitions, found..., not syncing, things like that that are standard in linux bootup |
| 06:58.40 | tmzt_ | ok, what's before the rtc and pwrsink messages? |
| 06:58.52 | maejrep | http://privatepaste.com/a3f1WyIOQW |
| 06:59.05 | maejrep | clock_late_init() disabled 18 unused clocks |
| 06:59.41 | tmzt_ | the NET messages, it's not getting very far |
| 06:59.57 | tmzt_ | ok, is there any response from the keyboard? |
| 07:00.16 | maejrep | no keyboard is drawn |
| 07:00.20 | maejrep | no response to the ts |
| 07:00.24 | maejrep | and nothing from hardware keys |
| 07:00.48 | tmzt_ | is there a newer kernel on the site? |
| 07:00.59 | maejrep | which site are you referring to? |
| 07:01.32 | maejrep | this is my own kernel which is compiled from git. I see that there's an update to git, so I can try doing another pull and recompile to see if it helps |
| 07:01.54 | *** join/#htc-linux kkaze_wor (n=kaze@ABordeaux-152-1-19-113.w82-125.abo.wanadoo.fr) |
| 07:01.57 | tmzt_ | what git? can I have a git web link |
| 07:03.44 | maejrep | htc-msm-2.6.25 |
| 07:03.52 | maejrep | waiting for link to load .. |
| 07:04.03 | tmzt_ | refresh if using links2/lynx |
| 07:04.40 | tmzt_ | RAMSIZE 5E00000 |
| 07:04.52 | maejrep | no I'm on my desktop, fx3 |
| 07:04.59 | maejrep | git.linuxtogo.org isn't loading for me |
| 07:05.01 | tmzt_ | it's slow |
| 07:05.21 | maejrep | $ git status |
| 07:05.21 | maejrep | # On branch htc-msm-2.6.25 |
| 07:05.42 | tmzt_ | the development is on there? |
| 07:06.19 | maejrep | I have no idea, it's the only git repository I've seen |
| 07:06.33 | maejrep | ah there it is |
| 07:06.48 | maejrep | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.25 |
| 07:08.35 | tmzt_ | ok, can you paste .config |
| 07:09.25 | maejrep | $ diff -b arch/arm/configs/htcraphael_defconfig .config |
| 07:09.25 | maejrep | 4c4 |
| 07:09.25 | maejrep | < # Tue Oct 28 23:36:42 2008 |
| 07:09.25 | maejrep | --- |
| 07:09.25 | maejrep | > # Thu Dec 11 01:56:27 2008 |
| 07:09.40 | tmzt_ | it's defconfig then |
| 07:09.44 | maejrep | (config is identical to defconfig) |
| 07:09.53 | maejrep | still want to see it? |
| 07:10.04 | tmzt_ | http://netripper.nl/raphael/config |
| 07:10.13 | tmzt_ | can you diff this, if there's anything there paste it |
| 07:10.37 | maejrep | a lot is different |
| 07:10.51 | tmzt_ | NetRipper is building trout and halibut and I can't see why |
| 07:11.27 | tmzt_ | CONFIG_TROUT_PWRSINK ? |
| 07:11.30 | maejrep | http://privatepaste.com/0910IuSXW8 |
| 07:11.32 | maejrep | not set |
| 07:11.39 | maejrep | hmm |
| 07:11.43 | maejrep | actually it is set in netripper's |
| 07:11.45 | maejrep | but not in mine |
| 07:11.53 | maejrep | (so not in defconfig) |
| 07:11.55 | tmzt_ | right |
| 07:12.49 | maejrep | i'll try his config |
| 07:13.16 | tmzt_ | yours has MACH_HTCRAPHAEL ? |
| 07:13.20 | maejrep | yes |
| 07:14.22 | maejrep | hmm... that config is from Oct 27 that may have been before HTCRAPHAEL was added |
| 07:14.46 | tmzt_ | right, I thought it was the one used to build the kernels but it doesn't look like it |
| 07:18.13 | maejrep | yeah I haven't seen a recent config from him |
| 07:18.41 | tmzt_ | do any of the kernels on netripper.com/raphael work better? |
| 07:20.27 | tmzt_ | do you know what smc91x is? |
| 07:20.35 | maejrep | i tried a couple and they either froze at the same spot or didn't get passed console handoff |
| 07:21.09 | tmzt_ | ok, is CONFIG_TROUT_PWRSINK an option in your .config, as a "not set" ? |
| 07:21.46 | maejrep | yes: # CONFIG_TROUT_PWRSINK is not set |
| 07:22.24 | tmzt_ | ok, enable that and see if the pwrsink messages go away |
| 07:22.48 | tmzt_ | just change it in .config and use make oldconfig, don't worry about menuconfig |
| 07:24.02 | maejrep | if it helps, I am quite familiar with linux and compiling kernels :) just not on cell phones so much |
| 07:24.43 | tmzt_ | sure, someone else must have been trying to find a setting in menuconfig in the log, sorry |
| 07:25.20 | maejrep | no worries |
| 07:27.28 | maejrep | STUB lines go away, but it still stops right after the rtc line |
| 07:27.44 | maejrep | and now the delay is up to 25 seconds |
| 07:28.13 | maejrep | the extra 5 seconds are before "msm_ts_init successful" |
| 07:28.38 | tmzt_ | ok, press the green dots if I understand the instructions |
| 07:29.02 | maejrep | i think they should be red dots, but that's the thing - i never see any dots for calibration |
| 07:31.14 | tmzt_ | do you have the android power management disabled? |
| 07:31.30 | tmzt_ | wait for irq and everything under MSM7X00A ? |
| 07:31.47 | maejrep | CONFIG_ANDROID_POWER=y ? |
| 07:31.55 | tmzt_ | cat .config |grep MSM7X00A in the channel |
| 07:32.06 | tmzt_ | no |
| 07:32.31 | maejrep | wait for interrupt is not set |
| 07:32.48 | maejrep | paste it here? or link to it? |
| 07:33.07 | tmzt_ | do you get any vreg enable failed messages? |
| 07:33.12 | tmzt_ | it should be 6 lines |
| 07:33.52 | maejrep | I don't think so |
| 07:34.01 | tmzt_ | hold on |
| 07:35.49 | maejrep | http://www.privatepaste.com/ee1LJ7F52s - MSM7X00A |
| 07:35.52 | tmzt_ | that wasn't in the diff, it must have been in NetRipper .config |
| 07:36.58 | tmzt_ | can you try with IDLE_SLEEP_MODE=0 |
| 07:39.46 | tmzt_ | if you have the source can you git-grep IDLE_SLEEP_MODE |
| 07:40.53 | maejrep | http://www.privatepaste.com/80nIMzxJNC |
| 07:41.12 | maejrep | stopped at same spot |
| 07:44.11 | maejrep | i'm tempted to roll back to 6ec22f1385dcc2ca15d08361657a0b14821534b8, with hillsdale's patch instead, since that seems to be the last known good kernel for me |
| 07:44.45 | tmzt_ | don't think it took the last change |
| 07:45.01 | maejrep | huh? |
| 07:45.14 | tmzt_ | look at the git-grep output |
| 07:45.27 | maejrep | i think that's because .config isn't in git |
| 07:45.59 | tmzt_ | no, look at mach-msm/Kconfig |
| 07:45.59 | maejrep | $ grep IDLE_SLEEP_MODE= .config |
| 07:45.59 | maejrep | CONFIG_MSM7X00A_IDLE_SLEEP_MODE=0 |
| 07:46.04 | tmzt_ | I know |
| 07:46.36 | tmzt_ | I could be wrong on this one, it's not clear who wins with that Kconfig entry |
| 07:47.15 | maejrep | $ grep IDLE_SLEEP_MODE .config |
| 07:47.15 | maejrep | CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE_SUSPEND=y |
| 07:47.16 | maejrep | # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE is not set |
| 07:47.16 | maejrep | # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_APPS_SLEEP is not set |
| 07:47.41 | maejrep | I made the change from menuconfig, so it changed both |
| 07:47.47 | tmzt_ | is this all debugging stuff from SURF |
| 07:48.03 | tmzt_ | halibut |
| 07:48.10 | maejrep | which debugging stuff? |
| 07:48.31 | tmzt_ | these pm options |
| 07:48.42 | maejrep | oh, no idea |
| 07:49.18 | maejrep | would rather have a no-power-management option so I don't have to wonder if its a problem :D |
| 07:49.31 | tmzt_ | NetRipper took most of htcraphael from swetland's board-halibut it looks like |
| 07:49.45 | tmzt_ | ok, then try disabling CONFIG_PM |
| 07:50.47 | tmzt_ | trout_clock_data looks the same |
| 07:51.21 | maejrep | right, I thought he copied board-trout, and halibut-keypad? |
| 07:55.02 | tmzt_ | you are using which config? |
| 07:55.06 | tmzt_ | you are using which defconfig? |
| 07:56.58 | tmzt_ | USE_DG_TIMER and USB_GP_TIMER are both set? |
| 07:59.26 | maejrep | only USE_GP_TIMER |
| 07:59.29 | maejrep | not DG |
| 07:59.36 | maejrep | i'm using htcraphael_defconfig |
| 07:59.51 | maejrep | and with CONFIG_PM disabled, i get compile errors |
| 07:59.54 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 08:00.23 | tmzt_ | ok, I guess power collapse from idle works with both then, the help message is confusing |
| 08:02.04 | tmzt_ | the idle stuff is not configured in msm_defconfig so the defaults are used |
| 08:02.42 | swetland | GP is preferred (since it matches the 32k timer used in power collapse, sync with the a9 better, etc) |
| 08:02.44 | tmzt_ | what is CONFIG_HTC_FB_CONSOLE? that is druidu's console driver? |
| 08:03.34 | maejrep | yeah i think so |
| 08:03.37 | tmzt_ | swetland: maejrep is getting delays in the dmesg output at startup |
| 08:04.02 | swetland | what hardware? |
| 08:04.06 | tmzt_ | we don't know what is causing them, so I am trying to eliminate candidates |
| 08:04.15 | tmzt_ | htc raphael (Touch Pro) GSM |
| 08:04.30 | maejrep | no, CDMA |
| 08:04.31 | swetland | on g1, we end up waiting ~5 seconds for AMSS to respond to proc_comm on boot |
| 08:04.38 | tmzt_ | sorry |
| 08:04.49 | swetland | and the first time something needs to turn on a clock, we get stuck blocked on the radio |
| 08:04.49 | maejrep | the delays can be seen here: http://privatepaste.com/a3f1WyIOQW |
| 08:04.57 | tmzt_ | everything should be inited by windows mobile |
| 08:05.04 | maejrep | 2 10s delays, which aren't present in NetRipper's dmesg |
| 08:05.18 | tmzt_ | unless the kernel is trying to reinit it, but I don't think it can do that to a9 |
| 08:05.43 | swetland | weird. |
| 08:05.54 | swetland | you shouldn't need the pwrsink driver for anything but g1 |
| 08:06.01 | maejrep | its clear that the cdma hardware is different from the GSM |
| 08:06.04 | swetland | all it does is update estimates of current usage |
| 08:06.32 | maejrep | but what's strange is that the kernel worked fine before up until the revisions from 12 days ago for usb_ether |
| 08:06.36 | swetland | and unless the radio image cares (which the winmo ones won't -- it's a mechanism they implemented specifically for g1/dream) it does nothing |
| 08:06.56 | tmzt_ | does disabling the pwrsink cause the STUB! or is there some way to eliminate it altogether? |
| 08:07.21 | swetland | I thought that with pwrsink off *nothing* should happen or be printed |
| 08:07.35 | tmzt_ | is that in pm.c? |
| 08:07.49 | swetland | I see nothing with STUB in my kernel tree |
| 08:07.59 | swetland | htc_pwrsink.c |
| 08:08.17 | maejrep | #ifndef CONFIG_TROUT_PWRSINK |
| 08:08.17 | maejrep | static inline int trout_pwrsink_set(pwrsink_id_type id, unsigned percent) |
| 08:08.17 | maejrep | { |
| 08:08.17 | maejrep | printk("%s:STUB!\n", __func__); |
| 08:08.17 | maejrep | <PROTECTED> |
| 08:08.18 | maejrep | } |
| 08:08.29 | tmzt_ | what file maejrep ? |
| 08:08.32 | maejrep | in include/asm-arm/arch-msm/trout_pwrsink.h |
| 08:08.53 | tmzt_ | we can tell NetRipper it's not needed then |
| 08:09.15 | tmzt_ | but it shouldn't be a problem, and enabling it did not change the delays maejrep ? |
| 08:09.22 | maejrep | correct |
| 08:09.22 | swetland | I'm not sure what you've got that'd be calling it when the config option is disabled |
| 08:09.38 | swetland | but yeah, doesn't seem like it'd have anything to do with your delays |
| 08:10.06 | maejrep | $ grep -R "trout_pwrsink_set" * | wc -l |
| 08:10.06 | maejrep | 43 |
| 08:10.09 | tmzt_ | it looks like it's supposed to only be registered as a platform_driver when htc_pwrsink.o is compiled in? |
| 08:10.53 | maejrep | several other CDMA raphael users are reporting the same behavior on the forum |
| 08:11.20 | tmzt_ | with the 20081204 kernel? |
| 08:13.51 | tmzt_ | maejrep: do you see those calls anywhere other than board-trout-* ? |
| 08:14.38 | maejrep | yeah: http://www.privatepaste.com/a10272w7QH |
| 08:16.07 | tmzt_ | that's related to sd then? |
| 08:16.44 | tmzt_ | whatever it is it doesn't explain the delay |
| 08:16.58 | maejrep | going to try jobo's kernel from http://forum.xda-developers.com/showpost.php?p=3033846&postcount=1098 |
| 08:17.52 | tmzt_ | could the vreg id's just be different on 75xx? |
| 08:25.46 | tmzt_ | maejrep: do you know if anyone has gotten sd card to work on raph800 (cdma) ? |
| 08:27.26 | maejrep | I don't |
| 08:27.27 | maejrep | sorry |
| 08:27.45 | maejrep | I think there's only like 2 or 3 people active that have done any work with raph800 |
| 08:28.37 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 08:28.47 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
| 08:29.02 | maejrep | going to retry that kernel from from 11/27 with hillsdale's patch, and work my way one patch at a time until I find what broke it |
| 08:29.40 | tmzt_ | that's what git bisect is for but I've never used it |
| 08:30.29 | tmzt_ | if the vreg id's are different that might explain it, or maybe something is getting powered up/powered down that shouldn't? |
| 08:30.52 | maejrep | I wouldn't be surprised |
| 08:31.00 | maejrep | we keep finding many things that are different about raph800 |
| 08:31.27 | tmzt_ | might need to haret trace the smem proc_comm channel |
| 08:32.49 | maejrep | yeah I tried messing around with haretconsole, but wasn't really sure what I should be looking for |
| 08:33.31 | tmzt_ | can you paste a git-grep vreg_ or vreg_set ? |
| 08:34.29 | tmzt_ | of course if they are that different, we might need a new CONFIG_MSM_AMSS for raph800/500, and maybe a machid |
| 08:34.49 | tmzt_ | it appears the table is in vreg.c not pdata anyway |
| 08:37.20 | tmzt_ | what is *dev for if it's not used? it's always 0? |
| 08:40.07 | tmzt_ | vreg_enable never fails? even though vreg_get return 0 if it can't find the vreg??? |
| 08:40.29 | *** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net) |
| 08:40.39 | tmzt_ | it would OOPS then I guess, dereferrencing a NULL pointer |
| 08:41.23 | tmzt_ | g1 would silently crash immediately, that can't really happen though because the string is fixed in the board file, but it seems strange |
| 08:42.55 | tmzt_ | maejrep: do you have CONFIG_DEBUGFS enabled? you have no way to get a shell, even busybox? |
| 08:43.06 | tmzt_ | CONFIG_DEBUG_FS |
| 08:43.50 | swetland | the biggest issue you're likely to run into is that your non AMSS 6.2.+ non 7201A targets are probably running an entirely different version of the modem firmware |
| 08:43.54 | maejrep | I used to be able to get to a shell using the busybox initrd, but not in recent git |
| 08:44.04 | swetland | which may not have any support for the clock/vreg proc comm requests, etc |
| 08:44.11 | maejrep | debug_fs = y |
| 08:45.02 | tmzt_ | it appears to work on the gsm versions, I think with the same settings as 6225 in g1 |
| 08:45.35 | tmzt_ | with debugfs we can power up sd card and things and trace the values that way? |
| 08:45.55 | swetland | in theory, but that again assumes the baseband understands the proc comm requests |
| 08:46.15 | tmzt_ | anyway to know, errror messages? |
| 08:46.23 | swetland | and the CLKCTL and VREG ones were added by qualcomm, at our request, during G1 development |
| 08:46.39 | swetland | so nothing that shipped before G1 will have them, to the best of my knowledge |
| 08:47.04 | tmzt_ | these are 7500A devices, about the same time as g1 I think |
| 08:47.26 | tmzt_ | not kaiser/polaris and titan/vogue which are the non-A variant |
| 08:47.50 | swetland | it would depend if they merged that support into their builds for winmo (or unified them). I'm not sure if amss-supporting-winmo and amss-supporting-linux are the same thing yet. |
| 08:48.20 | tmzt_ | if none of the clock commands worked, the kernel would continue to boot if it was already configured by windows mobile? |
| 08:50.11 | swetland | I believe so. |
| 08:50.37 | swetland | I don't think the clock api really detects / reports failure from the proc comm stuff |
| 08:50.49 | tmzt_ | maejrep: the touchscreen does not work at all? is that what smc91x: not found means? |
| 08:50.55 | swetland | so I believe it'll just keep going, but things will blow up if the requested clocks aren't actually on |
| 08:51.02 | swetland | smc91x is an ethernet controller |
| 08:51.11 | swetland | unlikely to be on any of your hw, but there is one on SURF |
| 08:51.21 | tmzt_ | this is too close to halibut then |
| 08:52.45 | maejrep | the touchscreen never gets to a point where I can try to make it work, and again it *used* to work |
| 08:52.59 | maejrep | I used to get a console, and the virtual keyboard, and mostly everything was happy |
| 08:53.13 | tmzt_ | which kernel did you use then? |
| 08:53.14 | maejrep | except colors were messed up, which jobo seems to have figured out |
| 08:53.18 | maejrep | same kernel |
| 08:53.24 | maejrep | but older revision |
| 08:53.28 | maejrep | hence why I'm reverting revisions now |
| 08:54.12 | tmzt_ | we need to tell NetRipper to take out the smc91x stuff and pwrsink |
| 08:55.49 | tmzt_ | jobo fixed the pallete issues? |
| 08:56.40 | tmzt_ | does the 2008-10-29 version work? why is there no git history here on htcraphael |
| 08:56.45 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 08:57.02 | tmzt_ | hi cr2, do you have documentation on tracing smem? |
| 08:58.00 | cr2 | hi tmzt_ |
| 08:58.12 | tmzt_ | they are trying to implement NetChip/RNDIS with the android function driver? |
| 08:58.19 | cr2 | you need to know the ioremapped address |
| 08:58.38 | cr2 | cpq/itsy is ok for know. |
| 08:59.03 | tmzt_ | we're looking at the possibility that a9 doesn't like the proc_comm commands on raph800 |
| 08:59.14 | tmzt_ | that it might be ignoring clocks and vregs |
| 08:59.39 | tmzt_ | maejrep has a delay in dmesg output and we don't know why |
| 09:00.10 | cr2 | tmzt_: can you provide the raph800 spl ? |
| 09:00.13 | tmzt_ | is the biggest issue between RNDIS and CDC_ETHER the zero length packets? |
| 09:00.24 | tmzt_ | I can't |
| 09:00.35 | cr2 | i have the delay too, and you know my opinion: |
| 09:00.36 | maejrep | if I know how to do that, I could :p |
| 09:00.44 | tmzt_ | opinion? |
| 09:00.58 | cr2 | the current kernel is broken in 10000 ways now, so i'm surprised it works at all ? |
| 09:01.11 | maejrep | oh, it doesn't work |
| 09:01.20 | tmzt_ | possibly, is NetRipper using halibut or trout here? |
| 09:01.21 | maejrep | (on raph800) |
| 09:01.33 | tmzt_ | cr2: you have a raph100? |
| 09:01.39 | cr2 | it does not matter |
| 09:01.53 | cr2 | we need a file for raph, and a file for diamond |
| 09:02.05 | tmzt_ | ok, apart from the delay no fs is mounted and no init is called |
| 09:02.27 | tmzt_ | and booting with no initrd does not panic |
| 09:02.38 | tmzt_ | this is with current htc-msm-2.6.25 |
| 09:02.50 | cr2 | core issues to be fixed first. imho. |
| 09:03.27 | tmzt_ | if the delays are not the cause of the fs not mounting, they are just another fish |
| 09:03.35 | maejrep | it used to work -- before the patch on 2008-11-27 and with hillsdale's patch, I was able to get to a console |
| 09:03.36 | tmzt_ | and we can worry about them later |
| 09:04.08 | tmzt_ | one. if fb is working do we need druidu/HTC console anymore? |
| 09:04.14 | cr2 | give me the raph800 spl |
| 09:04.31 | cr2 | tmzt_: no. but i have no idea about android |
| 09:04.41 | tmzt_ | android? |
| 09:05.00 | tmzt_ | cr2: I don't have touch pro, maejrep does |
| 09:05.07 | cr2 | swetland: why do you put virtual adresses into /proc/iomem ? |
| 09:05.47 | maejrep | how would I get the spl? |
| 09:05.54 | cr2 | tmzt_: android uses many nonstandard things |
| 09:06.33 | cr2 | maejrep: pwf spl800 0x0 0x100000 |
| 09:06.51 | maejrep | haretconsole i assume |
| 09:07.41 | tmzt_ | I'm sorry cr2, I don't know what you mean by android as I didn't ask about it. I just meant getting a driver and board file closer to trout without the g1 specific devices, rather than halibut which has ethernet (smc91x) and other things that no phone is going to have |
| 09:08.07 | tmzt_ | my reading of htcraphael suggests it's closer to halibut than trout but I'm not sure |
| 09:08.14 | tmzt_ | the file, not the device |
| 09:09.08 | cr2 | tmzt_: smc should be removed co mpletely |
| 09:09.27 | swetland | <PROTECTED> |
| 09:09.33 | cr2 | and we need to fix the gpio usage |
| 09:09.57 | swetland | oh, might be a side effect of some of the driver resources "cheating" and using vaddrs instead of paddrs and ioremap()'ing |
| 09:10.01 | cr2 | swetland: i see virtual addresses for msm-i2c and msm-sdcc in /proc/iomem |
| 09:10.07 | swetland | that's being cleaned up in the 2.6.27 branch |
| 09:10.14 | cr2 | ok |
| 09:10.31 | cr2 | swetland: there are 2 ways to access vreg |
| 09:11.07 | cr2 | swetland: a backdoor AT channel (smd-like), and proc_comm |
| 09:11.13 | cr2 | i've partially documented it |
| 09:11.27 | swetland | also RPC |
| 09:11.40 | swetland | though reverse engineering the rpc stuff is probably an amazing pita |
| 09:12.09 | tmzt_ | cr2: the direct access with the owner bits didn't work? |
| 09:12.11 | cr2 | the clocks are controlled directly at MSM_CLK, i've done my best to document it, but it's still a PITA without the docs |
| 09:13.04 | cr2 | the SD clock bitmasks are complete fun, because even htc uses different settings for the bootloader and in wince |
| 09:13.27 | swetland | controlling the clock registers directly is potentially dangerous (though I think some winmo ports do this for some regs?) because there are a number of read-modify-write registers that the a9 actively mucks with |
| 09:13.43 | cr2 | tmzt_: i don't think we need to modify the owner bits, but we need to take care of the ALT bits |
| 09:14.40 | cr2 | swetland: well, but since you see them in the wiki, wince (all versions) does exactly that. ;) |
| 09:15.33 | cr2 | and we need some way to work around it |
| 09:18.00 | maejrep | cr2, spl800: http://privatepaste.com/3113HCwrBm |
| 09:18.33 | cr2 | the SD clock divisors, i2c, and mddi are used directly in all wince msm720xX devices i've seen so far. |
| 09:19.01 | tmzt_ | SD is completely on a11, but the clock is controlled on a9? |
| 09:19.48 | tmzt_ | or mmc card is powered by vregs on a9 but clocks and everything is only on a11, since mmc card is in vreg.c as a proc_comm vreg |
| 09:19.50 | cr2 | tmzt_: the clock management is done by the microkernel on g1 |
| 09:20.23 | swetland | mildly objects to calling anything about the 41MB modem image "micro" ^^ |
| 09:20.34 | cr2 | lol |
| 09:20.51 | swetland | but yeah, there's L4 down there somewhere at the bottom of all that so technically that's correct, I'll admin |
| 09:20.54 | swetland | admit |
| 09:21.11 | tmzt_ | something has to run the BREW games and flash lite 3 that will never be seen |
| 09:22.01 | tmzt_ | same as my phone having a 6550 connected to pxa and another phone having a 6550 that runs everything |
| 09:22.49 | cr2 | tmzt_: is the gpio alt control already merged ? |
| 09:23.03 | tmzt_ | where would that be? |
| 09:23.18 | cr2 | generic msm gpio control |
| 09:23.41 | cr2 | dzo has written the gpio_func() function afair |
| 09:24.33 | cr2 | it should override the PCOM* gpio api for g1 on wince devices. |
| 09:25.40 | tmzt_ | there's a generic_gpio.c in mach-msm in htc-msm-2.6.25 |
| 09:26.38 | tmzt_ | that's Google's, what are you looking for? |
| 09:27.11 | cr2 | look for gpio_func() in the dzo branch |
| 09:27.21 | cr2 | i don't have the url handy |
| 09:27.37 | tmzt_ | htc-vogue? |
| 09:28.20 | cr2 | yes |
| 09:29.44 | tmzt_ | MSM_GPIO1A_BASE ? that's the direct method? |
| 09:30.37 | tmzt_ | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/gpio.c;h=9bf6972688c38f94a936187b81c8dd0x5901245;hb=htc-vogue |
| 09:30.57 | maejrep | cr2, if you need me to check anything here, just let me know. bbiab |
| 09:31.16 | tmzt_ | doesn't look like it's a config option though |
| 09:33.24 | tmzt_ | pxa uses mfp for alt settings now, doesn't it? |
| 09:36.30 | tmzt_ | cr2: gpio_func(gpio, func, oe, op |
| 09:36.46 | tmzt_ | <PROTECTED> |
| 09:36.52 | tmzt_ | <PROTECTED> |
| 09:37.00 | cr2 | tmzt_: yes, this one |
| 09:37.09 | cr2 | it's similar to pxa ALT |
| 09:37.14 | tmzt_ | ok, so that's merged then? |
| 09:37.44 | cr2 | and needs to be impleneted for msm, so we can override PCOM* |
| 09:37.47 | tmzt_ | it appears qdsp and a i2c chip driver call gpio_func directly |
| 09:38.36 | tmzt_ | right, I mean the new pxa kernel uses mfp-pxa27x or something and a generic way of configuring those in the pdata |
| 09:38.39 | cr2 | maybe. the pxa alt is also used by the drivers |
| 09:38.55 | cr2 | ok. |
| 09:39.14 | cr2 | i'll be happy with the PCOM* override for now. |
| 09:39.41 | tmzt_ | why does PCOM need to be overridden? this prevents a9 from accessing those gpios? |
| 09:39.45 | cr2 | maejrep: i've dowloaded the spl |
| 09:39.54 | cr2 | no. |
| 09:40.31 | cr2 | because the proc_comm call used for gpio ALT is available only in the google a9 firmware |
| 09:40.31 | cr2 | aka microkernel |
| 09:41.00 | tmzt_ | what functions are being selected between? |
| 09:41.15 | cr2 | a9 can access the same registers anyway |
| 09:41.36 | cr2 | so it's only the question of arbitration, as swtland says. |
| 09:41.47 | cr2 | between ? |
| 09:42.18 | tmzt_ | I mean on pxa the alt function selects what the pin is used for, gpio or periphrial connections |
| 09:42.19 | cr2 | look how PCOM* is defined in gpio.h |
| 09:42.44 | cr2 | yes, its ' the same on msm |
| 09:42.49 | cr2 | in my understanding |
| 09:43.04 | cr2 | because nobody of us has the CPU docs ;) |
| 09:43.32 | tmzt_ | which gpio.h, I don't see PCOM in include/asm-arm/arch-msm/gpio.h |
| 09:43.48 | cr2 | you can select the SD pins, BT and so on. 100% as on pxa. |
| 09:44.00 | cr2 | hmm. grep for PCOM |
| 09:44.49 | cr2 | i don't have any kernel code locally, and my inet access is very slow |
| 09:46.19 | tmzt_ | I see in proc_comm.h in mach-msm |
| 09:46.59 | cr2 | btw, don't forget that A has 6 gpio banks, and non-A only 5. |
| 09:51.33 | dcordes_ | wow the trout a9 image is 41mb? |
| 09:51.41 | tmzt_ | hi dcordes_ |
| 09:51.45 | dcordes_ | hi |
| 09:52.23 | tmzt_ | they have the qmi/rmnet, rpc routing, I don't know what else in there |
| 09:54.42 | tmzt_ | cr2: (func & 0xf) means there are 4 bits available for func? |
| 09:56.32 | tmzt_ | what is s5k4b1fx.c ? |
| 09:57.30 | cr2 | cam |
| 09:57.37 | cr2 | from samsung |
| 09:57.44 | tmzt_ | for? |
| 09:57.56 | cr2 | raph has m3t. check the wiki |
| 09:58.04 | tmzt_ | right |
| 09:58.31 | tmzt_ | this should be generic not specific to msm, which gpio_func is if I understand it |
| 09:58.33 | dcordes_ | kaiser cam model name is very similar |
| 10:00.32 | cr2 | tmzt_: at least it should be synced with pxa |
| 10:00.41 | swetland | dcordes: well the image in flash is smaller. it burns 41MB of *ram* though ^^ |
| 10:01.28 | tmzt_ | gpio_func is called for sleep and exiting sleep? |
| 10:01.29 | dcordes_ | oh I thought it's the image size |
| 10:02.15 | tmzt_ | what is SMEM_GPIO_INT ? |
| 10:02.45 | cr2 | swetland: but then it includes dsp firmware for umts/gps & such. |
| 10:03.15 | tmzt_ | adsp, tv??, video stuff, ... |
| 10:04.06 | cr2 | hm, you've reminded me that i'd buy the tv cable for raph. |
| 10:04.29 | tmzt_ | parmaster wondered if it was NTSC or PAL |
| 10:04.36 | tmzt_ | video out |
| 10:05.18 | cr2 | it's vbas out. |
| 10:05.27 | cr2 | don't know how the color is ecoded |
| 10:05.49 | cr2 | depends on the firmware probably |
| 10:05.51 | tmzt_ | these are configuration functions for trout in gpio.c? |
| 10:05.57 | tmzt_ | like msm_button_* |
| 10:06.32 | tmzt_ | like msm_button_enable |
| 10:06.34 | cr2 | which ones ? |
| 10:06.56 | tmzt_ | msm_gpio_exit_sleep |
| 10:07.35 | *** join/#htc-linux dcordes___ (n=dcordes_@g228202248.adsl.alicedsl.de) |
| 10:15.11 | cr2 | s1d13774 |
| 10:15.31 | tmzt_ | cr2: vbas is s-video? (svhs)? that wouldn't determine the norm |
| 10:15.35 | tmzt_ | usb? |
| 10:15.46 | tmzt_ | sorry, video |
| 10:16.08 | tmzt_ | mp900c uses a s1dxxxx chip |
| 10:16.38 | cr2 | http://www.spezial.de/commercio/dateien/produktbeitraege/S1D13774_DB.pdf |
| 10:16.43 | cr2 | in raph800 ? |
| 10:16.52 | tmzt_ | what? |
| 10:16.58 | cr2 | vbas is composite video signal |
| 10:17.14 | cr2 | s-video is Y-C split |
| 10:17.32 | tmzt_ | ok, still doesn't specify the norm |
| 10:17.38 | cr2 | i'm looking at the raph800 spl |
| 10:17.49 | tmzt_ | interesting |
| 10:17.54 | cr2 | the resume bit is stored at a different sram address than raph100 |
| 10:18.20 | tmzt_ | so suspend/resume is handled in a9? |
| 10:18.35 | cr2 | yes |
| 10:18.49 | tmzt_ | that's an area that a11 can write too? |
| 10:18.54 | cr2 | many things are shared |
| 10:18.55 | tmzt_ | to |
| 10:19.01 | cr2 | yes |
| 10:19.28 | tmzt_ | there might not be a composite video out on mddi |
| 10:19.30 | swetland | you could power down the a11 from the a11 |
| 10:19.37 | cr2 | raph800 can have samsungs lcd, and some other too |
| 10:19.40 | swetland | but you need the a9's cooperation to ever come back |
| 10:20.17 | tmzt_ | lcd controller |
| 10:20.48 | tmzt_ | with mddi interface |
| 10:20.55 | swetland | and the a9 cannot power down if the a11 is running, so you can't approach reasonable standby times without supporting all the power collapse handshaking and fun with the a9 |
| 10:21.39 | tmzt_ | 1280KB internal ram |
| 10:22.19 | tmzt_ | LUT for gamma control on LCD |
| 10:23.33 | tmzt_ | also supports yuv input, could be nice for video codecs to draw directly to it (don't know what dsp interface to mddi supports) |
| 10:24.03 | tmzt_ | has gpios |
| 10:24.17 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 10:24.34 | tmzt_ | ntsc/pal is external chip |
| 10:27.22 | tmzt_ | maybe that chip could support olpc cafe mode |
| 10:27.55 | tmzt_ | cpu could sleep while display is refreshed from it's fb memory |
| 10:30.40 | *** join/#htc-linux Xime (n=xime@dag94-3-82-233-170-230.fbx.proxad.net) |
| 10:34.48 | *** join/#htc-linux Guimli (n=guimli@ecu69-1-82-231-127-213.fbx.proxad.net) |
| 10:35.19 | *** join/#htc-linux timebomb (n=tb@e176115217.adsl.alicedsl.de) |
| 10:46.35 | cr2 | the sd_clock init seems to be the same on raph800 |
| 10:47.42 | cr2 | gpio0x26 is SD detect |
| 10:47.49 | cr2 | wiki? |
| 10:49.12 | cr2 | pita |
| 10:49.17 | cr2 | 38 0x26 3,0 22 I + keyboard slider, irq (S) |
| 10:50.16 | cr2 | raph800 seems to be a substantially different device |
| 10:50.20 | cr2 | from raph100 |
| 11:09.39 | cr2 | 0x8c clock div is different |
| 11:09.56 | cr2 | 0xa41 vs. 0xa19 |
| 11:10.52 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 11:11.28 | cr2 | i2c speed is the same |
| 11:20.18 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c1b2.pool.einsundeins.de) |
| 11:30.38 | *** join/#htc-linux Xime (n=xime@dag94-3-82-233-170-230.fbx.proxad.net) |
| 11:46.33 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
| 11:56.26 | *** join/#htc-linux Bally3 (n=chatzill@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 11:57.06 | Bally3 | morning |
| 12:00.08 | cr2 | hehe. 12:57 |
| 12:01.03 | cr2 | tmzt_: still alive ? |
| 12:03.44 | Bally3 | they all sleeping |
| 12:04.42 | Bally3 | cr2 - noticed on the log the angstrm-usb.. tried it on the polaris and worked ust as well if not better.. is it a newer version do you kow? |
| 12:04.46 | Bally3 | know |
| 12:05.16 | cr2 | no |
| 12:05.49 | Bally3 | no probs - thanks anyway |
| 12:06.32 | cr2 | polaris is not an A cpu, the usb is working ? |
| 12:07.15 | Bally3 | I'm trying it out.. looks like it should work |
| 12:07.21 | dcordes | no pola usb doesn't work |
| 12:07.44 | dcordes | except for the keys display touchscreen it's all like kaiser |
| 12:08.58 | Bally3 | would there be any problems using the angstrom-usb version from raph then? |
| 12:09.33 | cr2 | there will be no usb hten. |
| 12:09.56 | dcordes | it's a normal angstrom build. nothing special there |
| 12:10.04 | dcordes | auto usb0 |
| 12:10.49 | Bally3 | oh right.. I felt it was more stable |
| 12:15.05 | *** join/#htc-linux mooky_ (n=suzannet@berger.projecthugo.co.uk) |
| 12:17.01 | dcordes | if you wonder what works you must first look at the kernel level and what you do with it in userspace comes afterwards |
| 12:21.30 | dcordes | cr2, http://linuxtogo.org/~lgorris/misc/x1-spl_ruusigned_072stockspl.zip the same directory also has x1 and blackstone mmu dump |
| 12:28.39 | toer | morning |
| 12:48.06 | *** join/#htc-linux Castr0 (n=castr0@96.246.168.228) |
| 14:10.53 | tsdogs | paulproteus: have you seen this? http://qtextended.org/modules/news/article.php?storyid=53 |
| 14:25.30 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
| 15:34.49 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
| 15:48.32 | *** join/#htc-linux jeanseb (n=jeanseb@gazypan.dyndns.org) |
| 15:54.32 | jeanseb | hi |
| 16:57.11 | *** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl) |
| 16:59.15 | *** join/#htc-linux diogene31_ (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 17:00.38 | *** join/#htc-linux dwaradzyn (n=chatzill@chello089079197022.chello.pl) |
| 17:01.02 | dwaradzyn | dcordes: hi |
| 17:01.25 | *** join/#htc-linux Moku (n=John@f054177242.adsl.alicedsl.de) |
| 17:01.29 | dwaradzyn | dcordes: i tried that refresh thread idea and it works for polaris |
| 17:01.50 | NetRipper | dwaradzyn, in the msm_fb driver? |
| 17:03.05 | dwaradzyn | NetRipper: yes |
| 17:03.14 | NetRipper | nice |
| 17:03.15 | NetRipper | can you make a diff? |
| 17:05.43 | dwaradzyn | dcordes: NetRipper: http://pastebin.com/m77d5e6f |
| 17:07.32 | NetRipper | tsc2003? |
| 17:07.36 | *** join/#htc-linux LunohoD_ (n=alex@e180068218.adsl.alicedsl.de) |
| 17:09.12 | dwaradzyn | NetRipper: thats for kaiser - dcordes asked for that |
| 17:09.29 | NetRipper | ok |
| 17:09.32 | dwaradzyn | i put the same into vogue-ts.c and it worked |
| 17:10.07 | NetRipper | ok |
| 17:10.25 | NetRipper | touchscreen seems a weird place for it, but ok ;) |
| 17:10.35 | dwaradzyn | screen is totally uncalibrated, thats true |
| 17:11.01 | dwaradzyn | it is just a proof of concept |
| 17:11.36 | NetRipper | yea, that's fine; ) |
| 17:12.10 | dwaradzyn | bbl |
| 17:26.58 | *** join/#htc-linux imfloflo2 (i=58b44979@gateway/web/ajax/mibbit.com/x-938b8d416e98a8f6) |
| 17:41.13 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 17:48.40 | cr2 | NetRipper: i've looked at the raph800 spl |
| 18:08.15 | dcordes | dwaradzyn ok will try alter |
| 18:08.31 | dcordes | thanks a lot |
| 18:10.22 | cr2 | dcordes: can we get some plan to merge the gpi_func() by dzo ? |
| 18:10.54 | cr2 | after renaming it msm7xxx_gpio_func() of course :) |
| 18:13.50 | *** join/#htc-linux mooky (n=suzannet@berger.projecthugo.co.uk) |
| 18:32.59 | dcordes | so we'd have dzo's gpio setup for all the 7xxx ? |
| 18:34.26 | imfloflo2 | dzo is on holidays? |
| 18:36.27 | cr2 | dcordes: yes, but we need to ifdef the sixth bank for non-A |
| 18:37.16 | *** join/#htc-linux timebomb (n=tb@e176115217.adsl.alicedsl.de) |
| 18:37.25 | cr2 | then we can add an override for PCOM* |
| 18:37.43 | *** join/#htc-linux PoohbaLT (n=Poohba@c-98-235-66-242.hsd1.nj.comcast.net) |
| 19:00.31 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
| 19:00.59 | radem205 | hey |
| 19:01.29 | radem205 | are there any progresses porting android to the kaiser or polaris? |
| 19:39.01 | *** join/#htc-linux metter (n=metter@202-75.0-85.cust.bluewin.ch) |
| 19:42.00 | *** join/#htc-linux kirberich (n=robert@dtmd-4db25739.pool.einsundeins.de) |
| 19:42.08 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 19:43.05 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 19:43.19 | TrinityDied | Vous salue bien bas |
| 19:44.11 | TrinityDied | Welcome there! |
| 19:44.16 | TrinityDied | nobody? |
| 19:47.08 | *** join/#htc-linux lavender-t (n=jerrey@c-24-17-204-47.hsd1.wa.comcast.net) |
| 19:48.10 | TrinityDied | Hello laventer |
| 19:49.46 | lavender-t | hello |
| 19:51.06 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 19:52.19 | TrinityDied | Can someone help me? |
| 19:53.47 | TrinityDied | pleasssssssse |
| 19:54.12 | TrinityDied | Une ame charitable?? |
| 19:56.25 | dcordes | au secour! |
| 19:56.37 | TrinityDied | oui? |
| 19:57.18 | dcordes | tout est calme.. |
| 19:57.36 | TrinityDied | en effet |
| 19:57.57 | TrinityDied | quel est ton probleme? |
| 19:58.09 | lavender-t | trying to make diamond mmc work. |
| 19:58.36 | TrinityDied | c'est quoi ton probleme? |
| 19:59.08 | lavender-t | got a tiny step |
| 19:59.33 | TrinityDied | lavander> with sd card can't flash. error 00068002 or 00028002 |
| 19:59.34 | lavender-t | anyone has any updates ? |
| 19:59.35 | TrinityDied | really? |
| 20:00.37 | TrinityDied | Quelqu'un peut me renseigner? pas de possibilité de flash apres splexploit |
| 20:00.42 | TrinityDied | SVP |
| 20:00.51 | lavender-t | a few steps: |
| 20:01.44 | lavender-t | 1. the board-htcraphael.c sets the mmc to be ejected by default. so i changed that to inserted. |
| 20:02.19 | NetRipper | lavender-t, hi |
| 20:03.06 | lavender-t | 2. then some mmc commands ran thru. but all failed with -ETIMEDOUT. |
| 20:03.13 | lavender-t | hi ripper :) |
| 20:03.37 | lavender-t | then i suspect the port addr was wrong |
| 20:04.09 | lavender-t | so i changed it to SDCC 2, 3 and 4 |
| 20:04.44 | NetRipper | i've attempted this as well |
| 20:04.48 | NetRipper | you keep getting the command timeouts |
| 20:05.09 | lavender-t | yeah except SDC2 :) |
| 20:05.19 | lavender-t | SDC2 i did get response back |
| 20:05.42 | lavender-t | all others timeout |
| 20:05.58 | lavender-t | so i suspect the diamond was using SDC2 |
| 20:06.09 | NetRipper | SDC2 is wifi, i believe |
| 20:06.18 | lavender-t | oh i c |
| 20:06.31 | NetRipper | but maybe it's different for diamond |
| 20:06.36 | lavender-t | no wonder i got corrupted data back |
| 20:06.52 | lavender-t | thanks for the info. |
| 20:07.19 | NetRipper | cr2 was on yesterday |
| 20:07.29 | lavender-t | so i guess the base address is wrong for mmc ? or it just isnt initialized properly |
| 20:07.33 | NetRipper | he believes we must fix clk api before we'll get sd card to work |
| 20:08.01 | lavender-t | ok ... could be |
| 20:08.09 | NetRipper | clk api on trout/dream works via proc_comm but it doesn't work that way for raphael/diamond |
| 20:08.12 | lavender-t | the proc_comm stuff ? |
| 20:08.48 | lavender-t | yeah. the command all went without response too :( |
| 20:09.01 | lavender-t | i saw you short circuited that. |
| 20:09.03 | NetRipper | appearantly the vogue/kaiser already has an alternative clk api which we should port to raphael/diamond |
| 20:09.09 | NetRipper | yea proc_comm times out |
| 20:09.56 | NetRipper | you could read back the logs to see what cr2 said yesterday |
| 20:10.02 | NetRipper | http://irclog.iclem.net/?chan=htc-linux |
| 20:10.16 | lavender-t | ok let me try to see if i can find out anything. |
| 20:10.38 | lavender-t | btw, what's your local time ? |
| 20:10.53 | lavender-t | GMT+0 ? |
| 20:11.20 | NetRipper | GMT+1 |
| 20:11.29 | lavender-t | ok i'm GMT-8 |
| 20:11.32 | NetRipper | or CET |
| 20:11.35 | NetRipper | ok |
| 20:11.41 | NetRipper | new york? |
| 20:11.52 | NetRipper | or pacific |
| 20:11.56 | lavender-t | PST |
| 20:12.20 | NetRipper | in the log starts around 21:30 |
| 20:12.24 | NetRipper | but first bit is about usb |
| 20:12.26 | dcordes | lavender-t, hi |
| 20:12.31 | lavender-t | no wonder the other day i cant ping you. :) anyways, nice to talk to you :) |
| 20:12.39 | lavender-t | hi dcordes ! |
| 20:12.57 | NetRipper | heh, it was 7am for me when you pm'ed ;) |
| 20:13.17 | dcordes | lavender-t, I commited your usb fix with a mistake I added. hope you don't hate me |
| 20:13.28 | tmzt_ | msm_update_screen is not (void), it takes parameters |
| 20:13.33 | NetRipper | dcordes, i fixed the mistake |
| 20:13.53 | lavender-t | oh no not at all. thanks very much for helping :) |
| 20:14.03 | dcordes | NetRipper, I have seen it. I identified it that way. thanks. |
| 20:14.21 | lavender-t | indeed the USB should be fixed with more code to do the real usb-ether stuff |
| 20:14.23 | NetRipper | dcordes, yea i read the thread so i updated it after testing |
| 20:14.38 | lavender-t | but i just dont have time. that was merely a hack |
| 20:14.50 | lavender-t | and i havent tried if the adb still works :) |
| 20:14.51 | dcordes | useful one |
| 20:14.57 | NetRipper | google has a ums (or umf or similar) driver for usb function, to make it work like a usb stick |
| 20:15.58 | lavender-t | ah sorry guys i have to leave for lunch |
| 20:16.09 | lavender-t | ttyl ! |
| 20:16.12 | NetRipper | later |
| 20:16.17 | dcordes | yea nice you dropped in. cya |
| 20:16.23 | *** part/#htc-linux lavender-t (n=jerrey@c-24-17-204-47.hsd1.wa.comcast.net) |
| 20:16.52 | NetRipper | back to my movie |
| 20:16.53 | NetRipper | :p |
| 20:24.20 | toer | :) |
| 20:24.59 | *** join/#htc-linux imfloflo_ (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 20:28.00 | rolk | dcordes: I'm trying to get USB device functions to work on polaris. |
| 20:28.48 | tmzt_ | rolk: have you fixed your .config, and are you using gadget or android functions? |
| 20:29.28 | rolk | I'm making progress, but on USB device controller initialization, I get a BUS error on an ulpi_write (actually, the error is on a readl from some USB PHY register). |
| 20:29.47 | rolk | It appears that it is related to the USB PHY/controller clocks not being enabled. |
| 20:30.37 | tmzt_ | what is ulpi? |
| 20:30.38 | rolk | tmzt: I fixed my .config, and using 'USB function', as that is probably including a device controller driver for the Qualcomm hardware. |
| 20:31.10 | rolk | Ah, I notices that there is a phy_init sequence in the board-kaiser/polaris.c |
| 20:32.00 | rolk | This is a sequence that is written to the USB PHY (external chip, that does the actual USB physical layer) to disable some interrupts from that thing. |
| 20:32.15 | tmzt_ | what branch are you working on? |
| 20:32.38 | rolk | When I go through the motions and the kernel boots, see it running fine, up to the ulpi_init part of the usb_reset function. |
| 20:32.48 | rolk | tmzt: android-msm-htc-2.6.25 |
| 20:33.04 | *** join/#htc-linux TrinityDied (n=manpeche@212-198-144-81.rev.numericable.fr) |
| 20:33.31 | tmzt_ | you have polaris? |
| 20:33.48 | rolk | Then I get an "Unhandled fault: external abort on linefetch". This is on the line "while((readl(USB_ULPI_VIEWPORT) & ULPI_RUN) && (--timeout)) {" |
| 20:34.00 | rolk | in msm_hsusb.c |
| 20:34.19 | rolk | It is actually the read access on USB_ULPI_VIEWPORT which fails. |
| 20:34.33 | rolk | Just before that there is a writel to that same address. |
| 20:35.44 | rolk | Other threads suggest that such an 'unhandled fault:external abort on linefetch" is due to the external peripheral not being clocked, and not capable of responding to the request of the CPU. |
| 20:36.10 | rolk | tmzt: I have a polaris, yes. |
| 20:36.39 | rolk | I was hoping to get a pointer to someone that has this working on a kaiser. |
| 20:36.58 | tmzt_ | that sounds like an arm error |
| 20:37.28 | rolk | The address of the USB_ULPI_VIEWPORT is, in my case, 0xc880e170. |
| 20:37.56 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 20:38.19 | rolk | In the mean-time I'm trying to disable this phy-init sequence. See where I go from there. |
| 20:38.32 | TrinityDied | Welcome back |
| 20:38.37 | tmzt_ | I don't see where you are on android-msm- |
| 20:38.59 | TrinityDied | does anyone can help me? |
| 20:39.03 | TrinityDied | pleasssssssse |
| 20:39.33 | tmzt_ | TrinityDied: you are asking about spl/bootloader problems? |
| 20:39.56 | TrinityDied | @tmzt_ >> can't put a rom after splxploit. |
| 20:39.58 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 20:40.00 | rolk | tmzt: what do you want to know? My branch is origin/android-msm-htc-2.6.25 |
| 20:40.23 | *** join/#htc-linux divinebovine (n=rtaylor@S01060016b6b53675.vf.shawcable.net) |
| 20:40.29 | tmzt_ | TrinityDied: ask in #xda-devs or #hpcdev |
| 20:40.47 | TrinityDied | ok thanks |
| 20:41.12 | tmzt_ | rolk: sorry, I just don't see the file/function you are talking about in gitweb |
| 20:41.52 | rolk | Its in drivers/usb/function/msm_hsusb.c |
| 20:44.45 | imfloflo | @rolk you are trying on polaris with which method ? SD card or copying on / of the device? |
| 20:45.08 | tmzt_ | there's only one register, USB_ULPI_VIEWPORT? |
| 20:47.26 | rolk | No, there are many. They are all based from the MSM_BASE_ADDR, which is defined actually in the board-htcpolaris.c file (or other board file for other machines). I'm curious whether the polaris file has the correct 'base address' |
| 20:47.49 | *** join/#htc-linux Kensan_ (n=ken@gw.ptr-80-238-205-170.customer.ch.netstream.com) |
| 20:49.13 | rolk | imfloflo: I'm current working with all files for haret on the internal storage. |
| 20:49.46 | rolk | I believe someone mentioned a guy 'ginge' that had usb working on kaiser? |
| 20:51.34 | rolk | Without the phy_init sequence the driver has the same issue with the USB_ENDPTFLUSH register. This may mean that the general MSM_HSUSB_PHYS address is not applicable to polaris. |
| 20:51.58 | tmzt_ | rolk: do you get error -71 or anything on the pc? |
| 20:54.01 | rolk | I see a message about a new *full speed* device being added to the bus (my PC accepts high speed). |
| 20:54.09 | rolk | I do see an error -71. |
| 20:54.20 | rolk | So it seems that the external PHY isn't working. |
| 20:54.39 | tmzt_ | so it can pull up D then? |
| 20:54.40 | rolk | Otherwise, it would have negotiated high speed. |
| 20:55.03 | rolk | Yes, but isn't that a hardware thing? |
| 20:55.03 | tmzt_ | can you remove ehci and try it? |
| 20:55.22 | rolk | You mean on the PC host side? |
| 20:55.29 | tmzt_ | yes |
| 20:55.46 | rolk | With some difficulty, I could. |
| 20:55.53 | rolk | Whats the theory? |
| 20:55.53 | tmzt_ | you probably want to start with serial function anyway |
| 20:56.13 | rolk | I have experience with the ether.c gadget. |
| 20:56.28 | tmzt_ | why do you say it would negotiate high speed? |
| 20:56.52 | rolk | Because the device controller is a high speed controller, and my PC is capable of high speed. |
| 20:57.07 | tmzt_ | it doesn't depend on function? |
| 20:57.36 | rolk | They would do this funky quick oscillation bit of the D+/D- lines and then indicate that the other side is indeed a high speed partner. |
| 20:57.46 | tmzt_ | removing ehci removes the ability of the pc to function with high-speed only devices |
| 20:57.55 | rolk | I know. |
| 20:58.31 | tmzt_ | nothing indicates your writes to the phy are successful? |
| 20:59.03 | rolk | I think the fact that the PC sees a new full speed device means that the funky oscillation that the host does isn't answered by the device (it should make both data lines ground I believe). |
| 20:59.13 | rolk | So I think the PHY isn't operating properly. |
| 20:59.33 | rolk | Nothing indicates that the writes to the PHY failed.... |
| 20:59.46 | rolk | Except that reading from the PHY fails. |
| 21:00.03 | rolk | One other theoary is that the USB device controller isn't clocked. |
| 21:00.15 | tmzt_ | usb_reset pulls up D+ ? |
| 21:00.42 | tmzt_ | or, you mean it enables the PHY to do it itself |
| 21:00.49 | rolk | In the init function, it calls a clk_enable, but I'm not sure this works properly. |
| 21:01.05 | tmzt_ | <PROTECTED> |
| 21:01.05 | tmzt_ | <PROTECTED> |
| 21:04.50 | rolk | A number of writes to the memory-mapped io region that starts with the MSM_HSUSB_PHYS address seem to, well, not cause a bus error or page fault. In the usb_reset() function, I see the following 'succeed': |
| 21:06.21 | rolk | /* RESET */ |
| 21:06.21 | rolk | writel(2, USB_USBCMD); |
| 21:06.21 | rolk | /* INCR4 BURST mode */ |
| 21:06.21 | rolk | writel(0x01, USB_SBUSCFG); |
| 21:06.22 | rolk | writel(0x12, USB_USBMODE); |
| 21:06.24 | rolk | /* select ULPI phy */ |
| 21:06.26 | rolk | writel(0x80000000, USB_PORTSC); |
| 21:06.28 | rolk | writel(ui->dma, USB_ENDPOINTLISTADDR); |
| 21:08.07 | tmzt_ | so, you have printk's after those before the abort messages? |
| 21:08.13 | rolk | My best guess is that the controller is not properly clocked. |
| 21:08.20 | rolk | Yes, I have. |
| 21:09.47 | tmzt_ | why does usb_free clk_put(ui->pclk) ? |
| 21:09.50 | *** join/#htc-linux nashpa (n=dliviu@dliviu.plus.com) |
| 21:11.23 | *** join/#htc-linux TrinityDied5 (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 21:12.54 | *** join/#htc-linux timebomb (n=tb@e176115217.adsl.alicedsl.de) |
| 21:13.06 | rolk | I've followed the clk_enable call. |
| 21:14.10 | rolk | It does two clk_enable() calls, one for the ui->clk ("usb_hs_clk") and one for ui->pclk ("usb_hs_pclk"). |
| 21:15.04 | rolk | In the clock.c file in arch/arm/mach-msm, this does a check on whether the clk is a ACPU_CLK or not. |
| 21:15.11 | rolk | In this case, its not. |
| 21:15.27 | rolk | And then it defers the enabling to 'pc_clk_enable'. |
| 21:15.44 | rolk | Which does, in my code base, only do something for two clocks: |
| 21:16.15 | rolk | static int pc_clk_enable(unsigned id) |
| 21:16.15 | rolk | { |
| 21:16.15 | rolk | if(id==SDC1_CLK) |
| 21:16.15 | rolk | writel(readl(MSM_CLK_CTL_BASE)|(1<<7),MSM_CLK_CTL_BASE); |
| 21:16.15 | rolk | if(id==SDC2_CLK) |
| 21:16.16 | rolk | writel(readl(MSM_CLK_CTL_BASE)|(1<<8),MSM_CLK_CTL_BASE); |
| 21:16.18 | rolk | mdelay(10); |
| 21:16.20 | rolk | return 0; |
| 21:16.22 | rolk | / return msm_proc_comm(PCOM_CLKCTL_RPC_ENABLE, &id, 0); |
| 21:16.24 | rolk | } |
| 21:16.36 | rolk | the last line (after the return 0) has been commented out... |
| 21:16.37 | tmzt_ | RPC? |
| 21:16.42 | tmzt_ | ok |
| 21:17.22 | tmzt_ | you are saying the hsusb clocks are not implemented? |
| 21:17.31 | rolk | Perhaps I can find out how to enable the clocks, as it definitely looks like the clock lines to hsusb are disabled. |
| 21:17.48 | rolk | I am saying that. |
| 21:18.28 | tmzt_ | in clock.c, I only see pc_clk_enable using RPC_ENABLE |
| 21:19.19 | rolk | Can you quote the lines? |
| 21:19.33 | rolk | (Or is that inappropriate?) |
| 21:19.59 | tmzt_ | static int pc_clk_enable(unsigned id) |
| 21:20.01 | tmzt_ | { |
| 21:20.16 | tmzt_ | <PROTECTED> |
| 21:20.19 | tmzt_ | }; |
| 21:20.54 | rolk | Yes, I checked the diff with the git repository, and I see the same originals. |
| 21:21.07 | rolk | I wonder which patch introduced that... |
| 21:21.24 | tmzt_ | looks like SanMehat's code from g1 |
| 21:21.51 | tmzt_ | where is the code with the SDC clocks? |
| 21:22.09 | rolk | I think its one of the szsoftware patches. |
| 21:22.10 | tmzt_ | have you tried this on htc-msm-2.6.25? |
| 21:22.25 | tmzt_ | or is kaiser/polaris still not on there |
| 21:22.28 | rolk | I am on android-msm-htc-2.6.25 |
| 21:22.44 | tmzt_ | right, that's where I'm looking |
| 21:24.10 | rolk | I'm going to try it anyway. In case of the clk id not being one of the mentioned SD clocks, I'm going for the original implementation and see what happens. Fun. |
| 21:24.20 | tmzt_ | rolk: why is it using pc_clk_enable in that check? |
| 21:25.48 | rolk | What do you mean? |
| 21:27.09 | tmzt_ | #define USB_HS_CLK 36 |
| 21:27.13 | tmzt_ | <PROTECTED> |
| 21:27.31 | tmzt_ | <PROTECTED> |
| 21:27.41 | tmzt_ | in clock.h |
| 21:27.53 | tmzt_ | pc is proc_comm |
| 21:27.55 | rolk | Yes, those are the id's of the clocks. |
| 21:28.24 | tmzt_ | you need to know what bit they are? |
| 21:28.41 | rolk | That would be good to know. |
| 21:29.23 | tmzt_ | where did dzo or whoever get that? |
| 21:30.09 | tmzt_ | MSM_CLK_CTL_BASE is in smem?? |
| 21:31.14 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) |
| 21:31.32 | tmzt_ | <PROTECTED> |
| 21:31.50 | tmzt_ | <PROTECTED> |
| 21:31.58 | tmzt_ | <PROTECTED> |
| 21:35.03 | rolk | I notice that the USB connection I get with the Polaris while it is in MobWin is also full speed. |
| 21:36.03 | tmzt_ | swetland said something about not having docs for hsusb, but it wasn't clear if he meant the host portion, otg, or device (client) |
| 21:36.41 | tmzt_ | rolk: can you trace writes to MSM_CLK_CTL_PHYS in haret? |
| 21:37.09 | rolk | I can, probably, if someone will tell me what to do. |
| 21:37.46 | tmzt_ | I have enough trouble translating Kevin2's wiki pages for pxa |
| 21:38.14 | rolk | Can I find info there? |
| 21:38.55 | tmzt_ | handhelds.org wiki HaRET and ApachePhoneTrace |
| 21:47.58 | *** join/#htc-linux helloworld (n=aaa@e144118.upc-e.chello.nl) |
| 21:53.09 | rolk | Ok. Found the Haret documentation, and it is quite impressive! I doubt I can see the writes to the clk registers I need. WinMob probably does that early on, before I get Haret started... |
| 21:53.53 | tmzt_ | shouldn't it enable/disable on usb plug? |
| 21:54.04 | tmzt_ | if not, why is this neccessary? |
| 21:57.18 | rolk | I'm not sure of course. I think it will enable the device controller early on (including enabling the clocks to it). That's the usual thing to do, but I don't know. |
| 22:14.14 | rolk | Ok. I checked again, and both reading from the PHY register as well as from any USB_HSUSB registers fail with this 'external abort' message. I think its a sure sign that this part of the hardware is not clocked. |
| 22:14.52 | rolk | I tried the original pc_clk_enable (with the pcom call), that does not seem to do the trick. |
| 22:16.14 | rolk | I'm going to check this CLK_CTL memory range with haret, to look for changes to it if I plug/unplug the cable. |
| 22:24.27 | tmzt_ | there is not RPC at all on non-g1 amss |
| 22:46.07 | rolk | What is this RPC? |
| 22:47.32 | tmzt_ | one method of communicating with a9 it seems |
| 22:47.50 | tmzt_ | have you been able to trace those writes? |
| 22:47.56 | rolk | Ok. Then I need to figure out what bit those clocks correspond to. |
| 22:48.06 | rolk | I'm looking into it with haret. |
| 22:48.27 | rolk | But, it;s not that easy: my remote session with haret is via USB... Hahaha. |
| 22:49.18 | rolk | I have identified a virtualk address mapping (1K, tiny page) to that physical address 0xA8600000. I now need to setup a monitor to it. |
| 22:50.12 | tmzt_ | you want to dump mmu 2 <phys> |
| 22:51.14 | rolk | Ok. |
| 22:51.33 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 22:51.43 | rolk | There are 4 mappings. |
| 22:51.58 | tmzt_ | usually ignore the tiny ones |
| 22:52.06 | tmzt_ | trace the 4ks |
| 22:52.25 | rolk | <PROTECTED> |
| 22:52.26 | rolk | <PROTECTED> |
| 22:52.26 | rolk | ----------+----------+-------------+------------------------ |
| 22:52.26 | rolk | <PROTECTED> |
| 22:52.26 | rolk | <PROTECTED> |
| 22:52.26 | rolk | 92e00000 | a8600000 | 1MB section | D=0 AP=1 ?=2000 |
| 22:52.28 | rolk | b2e00000 | a8600000 | 1MB section | D=0 AP=1 ?=2000 |
| 22:52.30 | rolk | H |
| 22:52.48 | tmzt_ | ok, then trace the 1MBs |
| 22:52.50 | rolk | The last two are from supervisor mode? |
| 22:53.13 | tmzt_ | I don't know |
| 22:56.11 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 22:59.43 | *** join/#htc-linux mooky (n=suzannet@berger.projecthugo.co.uk) |
| 23:02.45 | *** join/#htc-linux Bally3 (n=chatzill@cpc1-blac6-0-0-cust618.manc.cable.ntl.com) |
| 23:03.52 | *** join/#htc-linux dcordes_ (n=dcordes_@unaffiliated/dcordes) |
| 23:07.12 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 23:07.12 | *** join/#htc-linux TrinityDied (n=TrinityD@212-198-144-81.rev.numericable.fr) [NETSPLIT VICTIM] |
| 23:07.12 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 23:07.12 | *** join/#htc-linux Tinyboom (n=nahh@178.80-202-153.nextgentel.com) |
| 23:07.13 | *** join/#htc-linux swetland (n=swetland@nat/google/x-ac2328226c12fbc1) |
| 23:07.13 | *** join/#htc-linux Poohba (n=poohba@c-71-58-20-66.hsd1.nj.comcast.net) [NETSPLIT VICTIM] |
| 23:07.13 | *** join/#htc-linux nizox (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68) |
| 23:07.13 | *** join/#htc-linux toer (i=tore@179.81-166-86.customer.lyse.net) |
| 23:07.59 | *** join/#htc-linux jeanseb (n=jeanseb@gazypan.dyndns.org) [NETSPLIT VICTIM] |
| 23:08.00 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) [NETSPLIT VICTIM] |
| 23:08.00 | *** join/#htc-linux hairyraven (n=nobody@loy.pp.ru) [NETSPLIT VICTIM] |
| 23:08.00 | *** join/#htc-linux Dallas[h] (n=dallas@c-71-225-238-170.hsd1.pa.comcast.net) [NETSPLIT VICTIM] |
| 23:08.00 | *** join/#htc-linux tcccp (n=hey@223.66.238.89.arpa-addr.in) [NETSPLIT VICTIM] |
| 23:10.30 | *** join/#htc-linux LunohoD (n=alex@e180068218.adsl.alicedsl.de) |
| 23:10.43 | Bally3 | wow |
| 23:10.45 | dcordes_ | mickey|tv, around? |
| 23:10.53 | Bally3 | channel split |
| 23:10.56 | Bally3 | lol |
| 23:11.26 | tmzt_ | NetRipper: you are here? |
| 23:11.43 | rolk | He, tmzt. |
| 23:11.51 | NetRipper | tmzt_, yes |
| 23:11.58 | *** join/#htc-linux dcordes_ (n=dcordes_@unaffiliated/dcordes) |
| 23:11.59 | NetRipper | tmzt_, not clearminded though |
| 23:12.01 | Bally3 | hi rolk |
| 23:12.08 | rolk | I've cooked a script for haret, but it bugs me about unknown keyword `'? |
| 23:12.15 | rolk | Hi Bally3. |
| 23:12.16 | dcordes_ | NetRipper, too much tea? :) |
| 23:12.23 | NetRipper | dcordes_, entoxicated |
| 23:12.24 | NetRipper | ;) |
| 23:12.44 | *** part/#htc-linux helloworld (n=aaa@e144118.upc-e.chello.nl) |
| 23:12.46 | NetRipper | specially flavored tea, if you will |
| 23:13.27 | dcordes_ | mkay |
| 23:13.57 | Bally3 | are you inibriated ONLINE NetRipper?? :O\ |
| 23:14.00 | Bally3 | :O |
| 23:14.41 | NetRipper | holy ** i need an english dictionary for that word |
| 23:14.51 | Bally3 | lol :P |
| 23:15.05 | tmzt_ | what word? |
| 23:15.26 | NetRipper | inibriated |
| 23:15.40 | Bally3 | need to update these icons.. I dont know whether that icon means laughing or perv |
| 23:16.05 | NetRipper | icons? |
| 23:16.35 | dcordes_ | wtf |
| 23:16.45 | Bally3 | inibriated = drunk |
| 23:16.57 | NetRipper | dont tell me you have one of those irc clients that give you smiley pictures instead of the good ol' text |
| 23:17.27 | Bally3 | chatzilla yeah lol |
| 23:17.30 | NetRipper | inebriated, no im not drunk, yet |
| 23:17.34 | Bally3 | but the emoticons look gay |
| 23:17.48 | NetRipper | dcordes_, what's up? |
| 23:18.17 | Bally3 | rolk, any prgress on that usb driver then? |
| 23:18.52 | NetRipper | tmzt_, that clk talk you had earlier with rolk, was that about kaiser/polaris? |
| 23:19.03 | tmzt_ | yes |
| 23:19.11 | NetRipper | and, would it similarly work for raphael/diamond you think? |
| 23:19.27 | tmzt_ | I thought usb client worked on raph/diam? |
| 23:19.36 | NetRipper | yes, it does |
| 23:19.41 | rolk | Well, I've configured the stuff as far as I can, but the USB device controller seems 'unclocked', i.e. its clk is not enabled. |
| 23:19.44 | tmzt_ | does it use proc_comm to set the clocks? |
| 23:19.50 | NetRipper | but we need clk api for sd card appearantly |
| 23:20.02 | dcordes_ | did you guys see cr2 suggestion to unify all msm gpios and use htc-vogue gpio setup? |
| 23:20.05 | rolk | I'm trying to get the bit number for the clks. |
| 23:21.07 | Bally3 | aah - thanks for the update |
| 23:22.22 | rolk | tmzt: maybe we're lucky. |
| 23:22.34 | rolk | I have a pdump from that area with usb plugged in: |
| 23:22.36 | rolk | a8600000 | 2015fe2f 001b81d0 00000019 00000011 | /.. ............ |
| 23:22.36 | rolk | a8600010 | 00000001 00000055 00000000 00118000 | ....U........... |
| 23:22.52 | rolk | and one with usb unplugged (a few seconds apart): |
| 23:23.02 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:23.02 | rolk | a8600010 | 00000001 00000055 00000000 00118000 | ....U........... |
| 23:23.02 | rolk | a |
| 23:23.31 | tmzt_ | can you add that to the SDC check and allow HSUSB_CLK/PCLK ? |
| 23:24.43 | tmzt_ | rolk: just to test, can you do that with sd inserted/removed? |
| 23:25.04 | rolk | Seems that usb clks could be bit 10 (or 22, when counting from the other end). |
| 23:25.38 | tmzt_ | 17:08 < rolk> static int pc_clk_enable(unsigned id) |
| 23:25.40 | tmzt_ | 17:08 < rolk> { |
| 23:25.40 | tmzt_ | 17:08 < rolk> Iif(id==SDC1_CLK) |
| 23:25.40 | tmzt_ | 17:08 < rolk> IIwritel(readl(MSM_CLK_CTL_BASE)|(1<<7),MSM_CLK_CTL_BASE); |
| 23:25.40 | tmzt_ | 17:08 < rolk> Iif(id==SDC2_CLK) |
| 23:25.42 | tmzt_ | 17:08 < rolk> IIwritel(readl(MSM_CLK_CTL_BASE)|(1<<8),MSM_CLK_CTL_BASE); |
| 23:25.45 | tmzt_ | 17:08 < rolk> Imdelay(10); |
| 23:25.47 | tmzt_ | 17:08 < rolk> Ireturn 0; |
| 23:25.50 | tmzt_ | 17:08 < rolk> / Ireturn msm_proc_comm(PCOM_CLKCTL_RPC_ENABLE, &id, 0); |
| 23:25.52 | tmzt_ | 17:08 < rolk> } |
| 23:26.38 | tmzt_ | and 81d0 -> 83d0 ? |
| 23:30.29 | rolk | So, from 2015fe2f -> 2015fc2f. That hypothetically means one of the USB clks is 00000200 at the CLK_BASE. And the other would be 00000200 at CLK_BASE+1 |
| 23:31.08 | tmzt_ | ok, you can add that to your code and test? |
| 23:40.34 | rolk | First attempt, failed. |
| 23:41.55 | rolk | I'm having trouble seeing those SDC1/2 CLK bits at that register though. 1<<7 and 1<<8. In 2015fe2f these are not set? |
| 23:43.26 | tmzt_ | have you tried mmutrace? |
| 23:44.22 | tmzt_ | polaris has wifi? |
| 23:44.43 | rolk | I do notice something funny with this address range when toggling the SD card. |
| 23:45.19 | rolk | Apologize for the number of lines: |
| 23:45.20 | dcordes_ | tmzt_, yes |
| 23:45.31 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:45.32 | rolk | HaRET(16)# pdump 0xa8600000 16 |
| 23:45.32 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:45.32 | rolk | HaRET(17)# pdump 0xa8600000 16 |
| 23:45.32 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:45.32 | rolk | HaRET(18)# pdump 0xa8600000 16 |
| 23:45.36 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:45.38 | rolk | HaRET(19)# pdump 0xa8600000 16 |
| 23:45.40 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:45.42 | rolk | HaRET(20)# pdump 0xa8600000 16 |
| 23:45.44 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:45.46 | rolk | HaRET(21)# pdump 0xa8600000 16 |
| 23:45.48 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:45.50 | rolk | HaRET(22)# pdump 0xa8600000 16 |
| 23:45.52 | rolk | a8600000 | 2015ff2f 001b80d0 00000019 00000011 | /.. ............ |
| 23:45.54 | rolk | HaRET(23)# pdump 0xa8600000 16 |
| 23:45.56 | rolk | a8600000 | 2015ff2f 001b80d0 00000019 00000011 | /.. ............ |
| 23:45.58 | rolk | HaRET(24)# pdump 0xa8600000 16 |
| 23:46.00 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:46.02 | rolk | HaRET(25)# pdump 0xa8600000 16 |
| 23:46.06 | rolk | a8600000 | 2015fd2f 001b82d0 00000019 00000011 | /.. ............ |
| 23:46.08 | rolk | HaRET(26)# pdump 0xa8600000 16 |
| 23:46.10 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:46.12 | rolk | HaRET(27)# pdump 0xa8600000 16 |
| 23:46.14 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:46.16 | rolk | HaRET(28)# pdump 0xa8600000 16 |
| 23:46.18 | rolk | a8600000 | 2015fc2f 001b83d0 00000019 00000011 | /.. ............ |
| 23:46.21 | rolk | Ha |
| 23:46.22 | rolk | see how fc goes to fd, then ff then fd and then fc again? |
| 23:46.24 | rolk | Thats with popping out the card, and then back in. |
| 23:47.14 | rolk | Time is running out for me, because it has been late nights lately. I'm quickly going to try this mmutrace, and then I call it a night. |
| 23:52.49 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 23:53.16 | Bally3 | damn.. just when you seem to be on a roll too rolk :P |
| 23:53.18 | tmzt_ | rolk: ah, wifi is on sdio |
| 23:59.13 | tmzt_ | rolk: readl is long as in 16bits? |
| 23:59.35 | tmzt_ | 32bits |