| 00:30.12 | BabelO | happy new year everybody |
| 00:30.17 | BabelO | and good night |
| 00:51.19 | *** join/#htc-linux ruzster (i=ruzster@220-213-140-248.pool.fctv.ne.jp) |
| 01:34.52 | bernt | happy new year! |
| 01:35.29 | bernt | we have a fog, you can see max 10 meters sometimes only 5 ... |
| 03:01.37 | *** join/#htc-linux bernt_ (n=bernt@dslb-084-060-110-166.pools.arcor-ip.net) |
| 05:16.13 | *** join/#htc-linux the_sys0p (i=the_sys0@gateway/tor/x-7e8badc74f3602a2) |
| 08:34.09 | *** join/#htc-linux BabelO (n=Fabrice@2a01:5d8:52ee:1c1c:250:fcff:fe46:5573) |
| 09:17.00 | BabelO | hi |
| 09:34.36 | *** join/#htc-linux Marex-notebook (n=marex@gwfm10-3-250.802.cz) |
| 10:18.34 | bernt | BabelO: hi |
| 10:24.27 | BabelO | hi bernt |
| 11:27.47 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfbbfb.pool.einsundeins.de) |
| 11:29.45 | *** join/#htc-linux goxboxlive (n=goxboxli@81.80-202-132.nextgentel.com) |
| 12:07.18 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfbbfb.pool.einsundeins.de) |
| 12:12.36 | goxboxlive | good morning |
| 12:21.22 | *** join/#htc-linux st_lim (n=st_lim@cm119.epsilon73.maxonline.com.sg) |
| 12:21.26 | st_lim | hi |
| 12:21.45 | st_lim | thanks to the latest opt.qtopia.tar.bz2 from goxboxlive |
| 12:22.22 | st_lim | I have a rather functional dopod... |
| 12:22.30 | st_lim | but I have the following problems: |
| 12:22.40 | st_lim | a. when I disconnect it from the usb cable, |
| 12:22.51 | st_lim | the system shuts down/resets after some time. |
| 12:22.54 | st_lim | why? |
| 12:23.28 | st_lim | b. when it is disconnected, I cannot get it to boot from the linux system at all. why? |
| 12:23.42 | *** part/#htc-linux st_lim (n=st_lim@cm119.epsilon73.maxonline.com.sg) |
| 12:31.47 | *** join/#htc-linux ruzster (i=ruzster@220-213-140-248.pool.fctv.ne.jp) |
| 13:39.04 | *** join/#htc-linux rob_w (n=bob@X1007.x.pppool.de) |
| 13:57.47 | *** join/#htc-linux rakeem (n=rakeem@n219078211158.netvigator.com) |
| 14:01.24 | rakeem | Happy new year peoples.... |
| 14:39.04 | *** join/#htc-linux Robwoerle (n=bob@Mad58.m.pppool.de) |
| 14:45.44 | *** join/#htc-linux tsdogs (n=tsdogs@62.123.180.130) |
| 14:54.51 | rakeem | Hey tsdogs... |
| 14:56.57 | par | happy new year! |
| 15:00.28 | tsdogs | rakeem: hi. |
| 15:00.47 | tsdogs | par: to u too (and all that har on the channel :) |
| 15:20.04 | *** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 15:41.44 | *** join/#htc-linux pH5 (n=ph5@e178232075.adsl.alicedsl.de) |
| 16:02.01 | BabelO | hi pH5 :) |
| 16:10.38 | goxboxlive | hi BabelO pH5 Happy new year. |
| 16:13.02 | rakeem | Happy new year guys... I'm pretty chuffed too, 'cos I got my girlfriend a Wii for Christmas, and the day before yesterday it was hacked to run unsigned binaries! It's gonna be a nice mediacentre soon...! |
| 16:17.02 | BabelO | happy new year all :) |
| 16:17.24 | BabelO | goxboxlive: did you see post about universal 4 hour ago ? |
| 16:18.31 | rakeem | BabelO: What posts? |
| 16:19.26 | BabelO | rakeem: in the log of this channel |
| 16:19.39 | goxboxlive | BabelO: no |
| 16:21.02 | *** join/#htc-linux ymerejt (n=jerry@ip-199.net-89-3-212.rev.numericable.fr) |
| 16:21.09 | ymerejt | all: happy new year |
| 16:21.27 | goxboxlive | u 2 ymerejt |
| 16:21.53 | diogene31 | Happy new year everyone. |
| 16:21.54 | goxboxlive | BabelO: probably becaase of he is using a newer wm6 or something |
| 16:23.52 | rakeem | Hehe... BabelO has to hack his own network... |
| 16:25.56 | BabelO | ;) |
| 16:29.50 | rakeem | BabelO: I upgraded my BA to WM5 and it boots linux no problem. WM6 wouldn't though... |
| 16:30.32 | rakeem | It's a pretty clean WM5 image too... I can pass you the link if you need it... |
| 16:30.32 | BabelO | rakeem: i haven't tested wm6 on ba |
| 16:31.44 | rakeem | It lasted about ten minutes on mine. As soon as I discovered the Haret / Linux problem it was gone... |
| 16:34.34 | rakeem | BabelO: That's interesting what you said about boardID on the BA re: Sleep. How do I find mine, 'cos I've never had it wake up properly... |
| 16:41.04 | BabelO | rakeem: easy way : you have it when you start linux, in dmesg |
| 16:53.19 | Kevin2 | Hi |
| 16:53.58 | Kevin2 | diogene31: Hey, any luck finding out why tracing doesn't work for you on haret? |
| 16:58.28 | rakeem | Anyone know how I can get a working xmonobut, or any other copy/paste function in the a terminal on GPE? |
| 16:59.56 | diogene31 | kevin2: Hi. No, not a slightest clue. I dissassembled some drivers on wince to see how they work (GPIO, ...) |
| 17:00.25 | diogene31 | Kevin2: I still don't understand why exception tracing doesn't always work :( |
| 17:03.55 | Kevin2 | Did you get a chance to try -- 16:57 Kevin2 diogene31: Can you try a "wi 10" with "addlist traces cp 15 0 2 0 0" ? (The cp15,2 register stores the mmu base.) |
| 17:07.02 | diogene31 | Kevin2: Yes, I tried. Not a trace came out. |
| 17:16.28 | *** join/#htc-linux jeanseb (n=jeanseb@gazypan.dyndns.org) |
| 17:16.32 | Kevin2 | diogene31: Can you post the output from "pd 0x40100000 0x30". Also, did you ever post the output from earlyharetlog.txt? |
| 17:16.33 | bernt | rakeem: Can you tell me the link for WM5 on BA? |
| 17:16.45 | rakeem | Yeah, hang on.... |
| 17:17.01 | rakeem | Happy new year BTW... |
| 17:25.39 | rakeem | bernt: Here you go... I suggest using the kitchen from the second set of links as you can drop in your own .cabs and build them into ROM... http://forum.xda-developers.com/showthread.php?t=302335 |
| 17:29.34 | diogene31 | Kevin2: http://pastebin.fr/734 |
| 17:29.40 | *** join/#htc-linux AlGe (n=alge@chello080109231226.4.uni-klu.teleweb.at) |
| 17:32.38 | bernt | rakeem: thank you. |
| 17:35.36 | rakeem | There's a wifi bug you should know about: After reset it won't power up wifi from the commmgr, you have to go to the settings page and click Turn on wireless radio (or something). You can then use the commgr applet until your next reset. |
| 17:39.27 | Kevin2 | diogene31: It would be interesting to see if haret can catch any accesses to the uart -- open two haret sessions, run wi with mmutrace in one, and in the other, run a pd on the uart registers. You should see the haret accesses in the wi window. |
| 17:40.14 | diogene31 | Kevin2: Good idea. I'm on it. |
| 17:49.39 | diogene31 | Kevin2: Test done. The second haret didn't see the access of the first. |
| 17:49.56 | Kevin2 | Wow! Sounds like a locked down TLB. |
| 17:50.13 | diogene31 | Kevin2: Explain please. |
| 17:50.29 | Kevin2 | Do you have the ARM documentation? |
| 17:51.20 | diogene31 | Kevin2: Of course. Tell me just the right chapter. |
| 17:51.50 | Kevin2 | In the ARM ARM book it is section 3.7.8. |
| 17:52.30 | Kevin2 | In the Intel XScaleĀ® Core Developer's Manual it is section 3.4.3 |
| 17:53.11 | Kevin2 | If haret can't even see its own accesses, the only thing I can think of is that the TLBs are stale and the processor isn't going through the MMU. |
| 17:54.27 | Kevin2 | The cpu flush stuff is supposed to clear out the TLBs (see asmstuff.S - line 56), so that would leave a locked down TLB.. |
| 17:57.29 | diogene31 | Kevin2: Just to be sure about my test: I ran 2 different haret executables, each one on a different tcp port. Do we agree on the test case ? |
| 17:58.16 | Kevin2 | diogene31: Sounds okay to me. (BTW, it is easier to just connect twice to the same haret, but that shouldn't affect the outcome of the test.) |
| 17:58.35 | Kevin2 | What were the exact mmutrace and pd commands that you ran? |
| 17:59.09 | diogene31 | Kevin2: 1st: addlist mmutrace p2v(0x40100000) 0x30; ibit irqs 11 26; wi 10 |
| 17:59.24 | diogene31 | Kevin2: 2nd: pd 0x40100000 0x30 |
| 18:00.07 | Kevin2 | And you saw valid output from pd while wi was still running? |
| 18:00.28 | diogene31 | Kevin2: And my documentation is "Arm architecture reference manual". Could you point me where to find the same doc you use to ease our technical exchange. |
| 18:00.46 | Kevin2 | Just to double check, can you run dump cp(15) in both haret and verify the mmubase is the same? |
| 18:00.51 | diogene31 | Kevin2: The first pd was valid, and after that, I got only exceptions. |
| 18:02.10 | Kevin2 | The links to the docs I use are at: http://www.handhelds.org/moin/moin.cgi/ApacheHardware |
| 18:02.14 | diogene31 | Kevin2: Confirmed, mmubase is the same (0xa0890000) |
| 18:02.44 | Kevin2 | What do you mean by "after that, I got only exceptions"? |
| 18:04.32 | diogene31 | Kevin2: Have a look at http://pastebin.fr/735 |
| 18:05.31 | Kevin2 | Heh - we outsmarted ourselves.. Haret looked up the new address. :-) |
| 18:06.13 | Kevin2 | In the first window - run show p2v(0x40100000) and then run vd <that addr> |
| 18:06.19 | Kevin2 | in the second window. |
| 18:07.12 | Kevin2 | (When in mmutrace, haret creates a second set of mappings starting at 0xe1100000 so that it can properly emulate the accesses. The second haret actually saw that the first mapping wasn't available and started using the second dummy mapping.) |
| 18:08.38 | *** join/#htc-linux Marex-notebook (n=marex@vasut.kolej.mff.cuni.cz) |
| 18:09.03 | *** join/#htc-linux AlGe (n=alge@chello080109231226.4.uni-klu.teleweb.at) |
| 18:11.03 | diogene31 | Kevin2: Tested, and yes, it's haret emulation. After you command, I access back my UART. |
| 18:12.16 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbf836a.pool.einsundeins.de) |
| 18:12.48 | Kevin2 | So, can haret trap its own accesses to the uart? |
| 18:15.16 | diogene31 | Kevin2: No. Not on the wonderful Mio A701 :) |
| 18:15.51 | Kevin2 | Just so that we're on the same page - what are the commands you ran this time? |
| 18:20.04 | diogene31 | Kevin2: 1st: wi 10, 2nd: vd 0xe1100000 0x30 |
| 18:21.19 | Kevin2 | diogene31: In first window, what does show p2v(0x40100000) report? We want to use vd of that address in the second window. |
| 18:25.43 | diogene31 | Kevin2: Oops, sorry for the wrong test. This time, I did : 1st: show p2v(0x40100000) -> 0xa6600000, wi 10, 2nd: vd 0xa6600000 0x30 |
| 18:25.58 | diogene31 | Kevin2: And doing that, haret saw the memory access. |
| 18:26.50 | Kevin2 | Okay. That means the issue is not with the TLB. |
| 18:33.04 | Kevin2 | diogene31: Can you run: dump mmu 2 cp(15,0,2,0,0) 16*1024 |
| 18:35.48 | Kevin2 | You may be able to do a pxa trace on the mmu tables themselves -- to see if wince is actually calling virtualcopy before accessing the uart. |
| 18:36.42 | Kevin2 | The only other thing that I can think of is that wince is actually changing the mmu base before accessing the uart. I don't know of a way to trap that. |
| 18:37.32 | diogene31 | Kevin2: As for the mmu dump : http://pastebin.fr/736 |
| 18:41.08 | Kevin2 | Hrmm. Another possibility is that wince is disabling the mmu before accessing the uart. |
| 18:43.12 | Kevin2 | diogene31: You can try running: set trace 0xfffd0000 ; set tracemask 0x3fff ; wi 20 |
| 18:43.32 | Kevin2 | To try and trap accesses to the mmu table mapping at 0xfffd0000. |
| 18:44.48 | Kevin2 | You can then retry with 0xa0890000. You can also try with 0x80890000, and 0x2a180000 -- but these seem unlikely. |
| 18:45.21 | diogene31 | Kevin2: The "set trace 0xfffd0000" hung my PDA. |
| 18:46.00 | Kevin2 | diogene31: Okay - sorry. |
| 18:48.45 | diogene31 | Kevin2: No problem. I expected it to happen sooner or later :) |
| 18:49.17 | diogene31 | Kevin2: Got an idea why ? |
| 18:50.05 | Kevin2 | diogene31: No - other than we can get into weird recursion stuff if we abort something while handling an abort. |
| 18:50.40 | Kevin2 | Where does it hang? Do you get to: Finished installing exception handlers. ? |
| 18:53.13 | diogene31 | Kevin2: No, it froze just after "wi 10" |
| 18:57.32 | Kevin2 | diogene31: BTW, what is the ffuart hooked up to? Is there any chance the processor isn't actually reading from the uart? |
| 19:03.29 | Kevin2 | diogene31: You could try running "set trace 0x40100000" and "set tracemask 0xff". If the processor accesses the uart with the mmu disabled, this will probably lock up the phone. If the processor doesn't access the uart with the mmu disabled, you shouldn't see any traces. |
| 19:03.42 | diogene31 | Kevin2: GSM. And my phone works properly. |
| 19:03.58 | diogene31 | Kevin2: OK. I'm back in 30mn to report. |
| 19:23.16 | paulproteus | Morning, everyone. |
| 19:25.29 | AlGe | hi, all |
| 19:26.51 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 19:31.58 | AlGe | Im just wondering why I get blinking (every +- 2seconds) kbbacklight on my BA after echoing "input-key" into /sys/class/led/blueangel:kbdbackli/trigger. It doesnt happen every time I enable it, and sometimes it also stops after a while and returns to normal behaviour (backliht on on key press for about 2 seconds and then off until next keypress). |
| 19:33.28 | AlGe | because also touch events bring the backlight on: can it be that the really noisy touch screen driver is bouncing and generating this? |
| 19:36.09 | *** join/#htc-linux LunohoD_ (n=alex@e180074235.adsl.alicedsl.de) |
| 19:37.14 | bernt | AlGe: do you also have the backup battery enabled? |
| 19:37.28 | bernt | (in the kernel) |
| 19:38.07 | AlGe | yes, i think |
| 19:39.10 | AlGe | and its values are useless (those in /sys/class/power_supply/backup-battery) |
| 19:39.13 | dcordes | hi all |
| 19:39.57 | bernt | I had to disable the backup battery, to have normal use off my touchscreen -- with the backup bat it was nearly unusable through receiving ghost events. |
| 19:40.38 | AlGe | ok, im seeing the same jitter and event echoing |
| 19:40.48 | diogene31 | Kevin2: I'm back. And it appears that "set trace 0x40100000" doesn't show any trace, so I guess the MMU is enabled when the CPU accesses the UART. |
| 19:40.53 | bernt | So give it a try with a kernel without backup battery support ;-) |
| 19:41.08 | AlGe | well, recompile time |
| 19:50.32 | Kevin2 | diogene31: Okay. |
| 19:51.40 | diogene31 | Kevin2: I have more info. After trying to watch GPIOs, I know that I see some of them (through mmutrace), but not all of them. |
| 19:52.53 | *** join/#htc-linux hollo_ (n=hollo@3e6b025d.rev.stofanet.dk) |
| 19:54.33 | Kevin2 | diogene31: Why do you think some gpios go unreported? |
| 19:54.48 | diogene31 | Kevin2: I see the other accesses through "watch gpios". |
| 19:55.40 | diogene31 | Kevin2: It's the same issue I think. There is a case when mmutrace is somehow disabled. |
| 19:56.50 | Kevin2 | diogene31: You see output pin changes during "watch gpios"? Changes of input pins are normal. |
| 19:58.14 | diogene31 | Kevin2: Sorry, I wasn't clear enough. I was refering to output GPIOs, and especially the one to turn on/off the GSM (GPIO24 in my case). |
| 19:59.15 | diogene31 | Kevin2: I know this is what turns on the GSM (watch GPIO + my GSM linux driver tell me I'm right). But mmutrace misses this activation. |
| 20:00.03 | steve-_ | TI OMAP 850 Technical Reference Manual: http://freeworld.thc.org/OMAP850_TRM.pdf . Hope this is helpful. The link will disappear in 15 minutes. |
| 20:00.25 | steve-_ | (greetings from the gsm project people at wiki.thc.org/gsm btw.). |
| 20:01.58 | dcordes | printed with soy ink |
| 20:02.26 | steve-_ | :> |
| 20:03.25 | Kevin2 | diogene31: Hrmm. Are you sure you're watching all of the virtual mappings to the GPIO registers? |
| 20:05.01 | steve-_ | do you know pHillip Zabel? |
| 20:05.10 | dcordes | pH5? |
| 20:05.20 | Kevin2 | steve-_: That is pH5. |
| 20:05.29 | steve-_ | ah ok. |
| 20:06.34 | steve-_ | does anyone have more OMAP850 specs? |
| 20:07.29 | diogene31 | Kevin2: Yep, sure (there's only one, as for UARTS) I don't count (the second cached one) |
| 20:07.32 | Kevin2 | diogene31: Can you try another simple test - open two haret telnet connections - in the first run "set trace 0xa6600000", "set tracemask 0xfffff", and "wi 20". In the second window run a "vd 0xa6600000 0x30" during the wi. |
| 20:09.37 | BabelO | steve-_: no more specs than the git-omap kernel sources |
| 20:10.55 | diogene31 | Kevin2: Done. And I see the "debug traces" if this is what you were expecting. |
| 20:13.39 | paulproteus | steve-_, Yay GSM project (-: |
| 20:14.02 | Kevin2 | diogene31: Okay. The only thing I can think of then is that something is either modifying the mmu table and then restoring it -- or, something is selecting an entirely new mmu table and then switching back. |
| 20:15.14 | Kevin2 | diogene31: If this is correct, you may still be able to use the "set trace" mechanism, but you'll need to figure out what virtual address the code is actually using. |
| 20:15.51 | Kevin2 | (The pxa tracing stuff doesn't depend on the mmu tables, so the code can't be using the 0xa6600000 addrs.) |
| 20:23.38 | *** join/#htc-linux rmoravcik (n=rmoravci@adsl-dyn53.91-127-139.t-com.sk) |
| 20:25.46 | diogene31 | Kevin2: Agreed. I'll dig a bit. |
| 20:26.47 | diogene31 | Kevin2: BTW, are you accepting patches for the haret source code, especially regarding PXA GPIO handling (PXA having 120 GPIOs and not 84). |
| 20:27.02 | diogene31 | ? |
| 20:30.22 | Kevin2 | diogene31: Sure - send patches to the mailing list. |
| 20:30.56 | Kevin2 | diogene31: BTW, is there a reason to use wgpio over watch gpios? |
| 20:32.13 | diogene31 | Kevin2: OK, good. |
| 20:32.36 | diogene31 | Kevin2: And I don't really understand the question. I use "watch gpios", not "wgpio" |
| 20:33.37 | Kevin2 | Okay - I don't understand your point about 84 gpios then (only the old "wgpio" command had that limit). Watch gpios should be scanning all 120. |
| 20:35.41 | diogene31 | Kevin2: My concern is about "dump gpios" actually. |
| 20:40.20 | Kevin2 | diogene31: Okay. I just use "watch gpios 0" (or even just "watch gpios"). |
| 20:41.18 | Kevin2 | bbl |
| 20:50.40 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
| 22:12.05 | LunohoD | steve-_: hello? |
| 22:16.15 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbf90ee.pool.einsundeins.de) |
| 22:52.37 | *** join/#htc-linux ruzster (i=ruzster@220-213-140-248.pool.fctv.ne.jp) |
| 23:43.21 | *** join/#htc-linux Keizer (n=keizer@24.144.16.26) |