**** BEGIN LOGGING AT Wed Jul 14 02:59:56 2010 Jul 14 04:00:19 mrmoku|away: got a very funny thing. top bar shows that GSM is off, but when I dialed the phone - everything worked as needed. 8) Jul 14 04:39:44 mickeyl: it is fsogsmd problem 8( Jul 14 04:40:17 mickeyl: it is somewhy closed the modem just after receiving a call Jul 14 06:33:46 mickeyl: (trac e-mail notifications do not tell you about attached files) i attached to the ticket my latest _full_ weird "clcc" log. Jul 14 06:37:05 PaulFertser: I've had a bug today. fsogsmd showed that the GSM is closed after resume. I've tried to call myself from other cell. The call worked and after hang up fsogsmd closed the modem. If tried dbus command to open - failed telling that channels are already allocated. Jul 14 06:37:16 and now I have in logs: 2010-07-14T06:32:26.597265Z [DEBUG] TiCalypsoUnsolicitedResponseHandler : Dispatching AT unsolicited '%CSQ', '19, 99, 2' Jul 14 06:37:16 2010-07-14T06:32:26.597735Z [DEBUG] TiCalypsoModem <4C>: Parsing error: '%CSQ: 19, 99, 2' does not match '%CSQ: (?P\d+), (?:\d+), \d' Jul 14 06:37:16 2010-07-14T06:32:26.598154Z [WARN] TiCalypsoModem <4C>: Unexpected format for TiCalypsoPercentCSQ Jul 14 06:37:54 seems that there's a bug in regexp Jul 14 06:58:12 mickeyl: ^^ Jul 14 07:35:14 Q-Master: maybe you have the same problem as I do... Jul 14 07:35:22 Q-Master: bad battery and calypso going wild Jul 14 07:35:44 Q-Master: or did that happen while plugged in? Jul 14 07:36:50 mrmoku: nop. I've got this after resume. Also I have dos1's qi with 450/112 cpu/ram Jul 14 07:37:31 k Jul 14 08:04:02 mrmoku: this might be because of this new qi Jul 14 08:27:07 <[Rui]> hi all Jul 14 09:09:56 <[Rui]> White Screen is gone ever since the day before yesterday's update Jul 14 09:11:04 lindi-: with FixNow enabled, after suspend, my GPS prints binary data on /dev/ttySAC1 Jul 14 09:11:17 even after powering it off and on Jul 14 09:11:44 and doing stty -F /dev/ttySAC1 raw Jul 14 09:14:57 lindi-: even after CFG-RST Jul 14 09:15:01 lindi-: that's strange Jul 14 09:41:54 <[Rui]> JaMa: hi, white screen is gone, but I don't remember any kernel upgrade two days ago Jul 14 09:42:38 <[Rui]> there's some flickering now, when unblanking, and blanking is somewhat nicer (seems like it pulses down brightness) Jul 14 09:49:59 good Jul 14 10:13:22 mrmoku: is shr-quick settings gprs setting credentials already? Jul 14 10:19:01 if so, where does it take credentials from? Jul 14 10:19:30 * vanous123 editing user manual Jul 14 10:28:34 hi mickeyl Jul 14 10:35:37 vanous123: credentials are set by phonefsod when gsm registers Jul 14 10:35:46 vanous123: you find them in /etc/phonefsod.conf Jul 14 10:37:12 mrmoku: thank you, i looked but missed it Jul 14 10:41:11 mrmoku: so just for the record, i think there 2 ways of gprs credentials setting and storing. Via shr settings (/etc/shr-settings/gprs.pickle) and phoneui phonefsod.conf Jul 14 10:41:48 and i think the shr wizard sets the shr-settings credentials Jul 14 11:03:18 vanous123: if shr-settings still is using that gprs.pickle that would be wrong Jul 14 11:03:22 * mrmoku checks Jul 14 11:04:43 vanous123: [GPRS] use phonefsod interface to store PDP credentials Jul 14 11:04:51 which is ab5145fdf4b59e9c1ca5658f543143a85b4c0628 Jul 14 11:04:59 so all fine... just one way :-) Jul 14 11:05:38 really? hmm Jul 14 11:06:05 yes, can see the commit Jul 14 11:06:21 i see, now i understand Jul 14 11:06:25 OK, cool, thanks Jul 14 11:07:17 yw Jul 14 13:08:58 Hi. Jul 14 13:10:02 hi Jul 14 13:11:39 * TAsn-work is in utc + 8 (9?) :P Jul 14 13:11:43 for the first time btw. Jul 14 13:13:59 TAsn-work: working in china? :) Jul 14 13:14:10 no Jul 14 13:14:12 in korea Jul 14 13:14:13 :P Jul 14 13:15:39 TAsn-work: S or N ? :)) Jul 14 13:15:49 S Jul 14 13:15:56 I'm not allowed into N Jul 14 13:16:13 :) where about, Seoul? Jul 14 13:17:10 near Seoul, in Suwon. Jul 14 13:17:35 * TAsn-work is tired Jul 14 13:17:39 well, enjoy Kimchi and other goodies Jul 14 13:17:46 Kimchi? Jul 14 13:17:52 :) Jul 14 13:18:01 TAsn-work: http://en.wikipedia.org/wiki/Korean_cuisine#Kimchi Jul 14 13:18:15 I took an eleven hours flight, followed by a 1hr cab with airport time wasting in the middle :P Jul 14 13:18:27 vanous123, Thanks. Jul 14 13:19:02 if you like it, at the airport you can a travel pack of it on your way home Jul 14 13:19:50 yuck :P Jul 14 13:20:10 :) Jul 14 13:21:20 TAsn-work: :P Jul 14 13:21:45 TAsn-work: how long for? Jul 14 13:22:27 No idea. For now it's 4 days Jul 14 13:22:30 but it may be longer. Jul 14 13:23:35 well, good luck, hope you like it. i did. Jul 14 13:26:25 Talking about Korea or that Kimchi? :P Jul 14 13:26:45 actually both Jul 14 13:31:23 Thanks :P Though I will avoid the latter. Jul 14 13:36:32 vanous123, pm. Jul 14 13:36:39 everyone else: ciao, shower and then bed. :P Jul 14 16:12:43 anyone know the process of connecting a bluetooth device to the FR in latest shr-u ? Jul 14 16:13:55 my desktop finds it, but the FR gets nothing using hcitool scan Jul 14 16:14:13 sicu: what exactly are you searching for? Jul 14 16:14:50 vanous123: trying to connect this thing: http://www.tangogps.org/gps/articles/39-Getting-fit-with-tangoGPS-release-0.99.4.html Jul 14 16:14:58 a heartbeat monitor Jul 14 16:15:13 sicu: did you check this? http://wiki.openmoko.org/wiki/Manuals/SHR#Bluetooth Jul 14 16:15:43 not sure if emtooth has been currently working or not... Jul 14 16:16:22 vanous123: got emtooth running, but it finds nothing Jul 14 16:16:44 i'll have another read through the page you linked to and see if i get anywhere ... thanks Jul 14 16:17:02 k Jul 14 16:47:27 hi al Jul 14 16:47:40 after latest shr-u upgrade gsm stopped working Jul 14 16:47:41 =) Jul 14 16:52:29 JaMa: mrmoku ^^^ Jul 14 17:40:12 alexxy: a bit more info please ;) Jul 14 17:40:44 ok Jul 14 17:40:50 bi'll show logs later Jul 14 17:40:59 ok Jul 14 18:05:04 mrmoku, hi! I can give more info about `gps not work`, and `alarm doesn't work` Jul 14 18:05:17 just say me how, and what you want to see) Jul 14 18:27:38 <\marco> hi to all Jul 14 18:29:06 <\marco> I've spent a little while finding out why I could't sftp my FR Jul 14 18:30:30 <\marco> the adoption of openssh instead of dropbear was the "problem" Jul 14 18:30:47 <\marco> openssh has the sftp-server in a separate pkg Jul 14 18:30:49 max_posedon: :) Jul 14 18:30:53 <\marco> not installed by default Jul 14 18:31:04 max_posedon: did not try alarm for some time... but GPS always worked Jul 14 18:31:23 <\marco> I think this should be added to the shr-manual.. Where I've to put it? in which section? Jul 14 18:31:59 <\marco> any hint? :) Jul 14 18:32:05 \marco: ask vanous123 :) Jul 14 18:32:12 <\marco> thanks mrmoku :) Jul 14 18:32:18 yw Jul 14 18:32:20 <\marco> vanous123: ping :) Jul 14 18:32:49 max_posedon: let me check if both still work for me... Jul 14 18:33:14 alarm doesn't works - phone doesn't wakes up in time Jul 14 18:35:39 <\marco> about the alarm: it works for me but I think the phone wakes up too late anyway: I've to wait 5-10 second to see the alarm acknowledgment Jul 14 18:43:46 <\marco> vanous123: I've to go away now. I've noticed that openssh-sftp-server isnt' installed by default. This can be misleading for someone who is trying to use the sftp feature of nautilus ( for example ). I think shuld be added a note in the shr-manual. Which section of the manual is appropriate? thanks :) Jul 14 18:48:29 hey folks Jul 14 18:48:38 I've got trouble booting my Freerunner/SHR-T Jul 14 18:49:07 mrmoku: what actual logs do you want? Jul 14 18:49:26 it doesn't start X nor does it allow me to SSH in Jul 14 18:50:29 the screen shows four messages about unknown g_ether boot options, and then a line "INFO: RCU detected CPU 0 stall (t=something/something jiffies)" Jul 14 18:53:27 max_posedon: alarm worked Jul 14 18:53:27 gena2x: just figuring out timings now, if you're around.. Jul 14 18:53:52 mrmobil, e.g. phone was suspended, and wake up-ed in time and ringing? Jul 14 18:53:59 my pure neo Jul 14 18:54:08 yup Jul 14 18:54:12 gena2x: do you know what this "nGCSn" pin is (ideally where it's plugged into on Glamo - I can't see it on the schematic) Jul 14 18:55:01 Weiss: hi. Jul 14 18:55:12 evening :D Jul 14 18:55:30 mrmobil: mrmoku: what actual logs do you need? Jul 14 18:56:15 alexxy: phonefsod and fsogsmd Jul 14 18:56:29 Weiss: nice you didn't drop timings idea :) GCS is general chip select. Jul 14 18:56:31 ok Jul 14 18:56:54 gena2x: I stand by my word, even if it takes a little while.. Jul 14 18:57:20 http://paste.pocoo.org/show/237572/ Jul 14 18:57:24 fsogsmd.log Jul 14 18:57:44 http://paste.pocoo.org/show/237573/ Jul 14 18:57:47 gena2x: DQM{0,1} are just bank selects (most significant bits of the address)? Jul 14 18:57:48 Weiss: :) you may see in s3c timings diagram at page 5-11 (again) to see how it activated. Jul 14 18:57:50 phonefsod.log Jul 14 18:58:14 gena2x: yeah.. I'm trying to correlate that with a very similar diagram in the Glamo doc Jul 14 18:58:27 Weiss: you were able just to change priority and do this review month later :) Jul 14 18:59:49 Weiss: it is connected to glamo directly. Jul 14 19:00:21 Weiss: NGSC1 (s3c) <-> HCS (glamo) Jul 14 19:01:54 Weiss: as far as _i_ understood DQMs are really need to select some bytes from word. Jul 14 19:02:30 Weiss: so they are not really important for us. Jul 14 19:02:49 ah, ok Jul 14 19:02:57 hmm.. I don't see that HCS line on the schematic Jul 14 19:03:18 ah hang on, wrong page Jul 14 19:04:30 here itis Jul 14 19:06:58 nWBE does nothing? Jul 14 19:09:04 mrmoku: GSM stopped working here as well after upgrade 3hrs ago, but GPS is working nicely as I just took my FR for a 2hr long run to test its tracking skills ;p Jul 14 19:09:13 alexxy: does fsogsmd still respond to dbus calls? Jul 14 19:09:19 sicu: hmm :/ Jul 14 19:09:33 mrmoku: seems not Jul 14 19:09:40 but how can i actualy check it? Jul 14 19:09:55 if i restsrt phonefsod Jul 14 19:09:57 alexxy: mdbus2 -s org.freesmarthone.ogsmd Jul 14 19:10:02 fsogsmd responds on reset Jul 14 19:10:15 alexxy: restarting phonefsod won't work Jul 14 19:10:22 Hi! Is trac.freesmartphone.org the right trac for alsa requests? Jul 14 19:10:23 stop, kill fsogsmd, start Jul 14 19:10:37 Hum_: alsa statefile requests? Jul 14 19:10:47 Hum_: or what kind of request? Jul 14 19:11:06 mdbus2 -s org.freesmarthone.ogsmd Jul 14 19:11:06 [ERR]: The name org.freesmarthone.ogsmd was not provided by any .service files Jul 14 19:11:25 +p Jul 14 19:11:28 mrmoku: Yes, maybe, but also alsactrl -h shows obsolete names Jul 14 19:11:37 Weiss: yeah. just read more about DQM. Jul 14 19:11:51 Weiss: seem like i have right understanding. Jul 14 19:12:05 mrmoku: i did not understand where to get state files, so I would wait some time Jul 14 19:12:27 Hum_: state files are in /etc/freesmartphone/conf/openmoko_gta/alsa... Jul 14 19:12:47 http://paste.pocoo.org/show/237577/ Jul 14 19:12:52 mrmoku: ^^^ Jul 14 19:13:26 ahh, i searched for .state Jul 14 19:13:48 Hum_: new format... new name ;) Jul 14 19:13:57 alexxy: that is? Jul 14 19:14:07 fsogsmd log Jul 14 19:14:10 mrmoku: how about a ln -s from /etc/alsa Jul 14 19:14:11 after killing Jul 14 19:14:18 it automaticaly was restarted Jul 14 19:14:43 * mrmoku upgrading to brick his phone :P Jul 14 19:14:55 alexxy: yeah, fsogsmd get's dbus-activated Jul 14 19:15:09 Weiss: oh. wait... Jul 14 19:15:14 alexxy: and loglevel = DEBUG for phonefsod would be nice Jul 14 19:16:58 mrmoku: ah, nice of you to join us brickworkers ;p Jul 14 19:17:20 :P Jul 14 19:17:46 Weiss: aha, HLB/HUB (glamo) <-> NBE (s3c) Jul 14 19:19:10 better to say HLB/HUB (glamo) <- BE0/BE1 (s3c) Jul 14 19:19:45 * Q-Master already is brickworker too 8) Jul 14 19:21:01 gena2x: so.. Glamo expects... Jul 14 19:21:20 gena2x: Tacs: zero for both read and write. it wants nGCS at the same time as the address Jul 14 19:22:02 gena2x: Tcos: at least 5 ns for read and write (1 clock @ 100MHz? looks like the S3C rounds the timing to the next clock, so 1 clock should always give enough) Jul 14 19:22:29 gena2x: Tcoh: at least 5 ns for a write, but at least 10.5 ns for a read (maybe this explains your read problems?) Jul 14 19:22:42 gena2x: Tcah: zero just like Tacs Jul 14 19:22:58 gena2x: Tacc and Tacp - not quite sure what these are indicating - do you understand better? Jul 14 19:23:15 Weiss: forget about acp, it is for paging mode Jul 14 19:23:28 mrmoku: http://paste.pocoo.org/show/237587/ < fsogsmd Jul 14 19:23:43 mrmoku: http://paste.pocoo.org/show/237588/ < phonefsod Jul 14 19:23:46 gena2x: but we have paging mode on (as of last week)? Jul 14 19:24:07 Weiss: if beast do not support bursts forget about paging. Jul 14 19:24:25 Weiss: so, concentrate on Tacc. Jul 14 19:25:14 so.. Tacc is how long the address and data need to be maintained since the edge in nOE/nWE? Jul 14 19:25:33 (or just nOE? looking at page 5-11) Jul 14 19:26:36 gena2x: in that case, at least 30 ns for both read and write (but I'm not 100% sure the diagrams line up here) Jul 14 19:27:15 i think for read, it is just time how long s3c waits with OE lines asserted, and then reads data from D lines. Jul 14 19:27:50 for write, it is time how long s3c holds data in D lines while WE asserted. Jul 14 19:28:18 Weiss: Tacc can't be less than 4 in s3c while using nwait(our case). Jul 14 19:28:55 Weiss: so, 2+4+2 cycles. Jul 14 19:29:11 Weiss: 10 ns each Jul 14 19:29:30 that should be loads for Glamo Jul 14 19:29:55 (I wonder, what about turning nWait off in the S3C? will the world end?) Jul 14 19:30:15 Weiss: yes. Jul 14 19:31:40 Weiss: this gives us ((10^9/80)*2)/1024/1024=23Mb/s transfer speed. Jul 14 19:32:09 gena2x: ah.. nWait is used to delay the CPU in order to invoke the penalties for accessing registers (slower) Jul 14 19:32:11 Weiss: and cureent settings are... Jul 14 19:32:16 alexxy: hmm strange... Jul 14 19:32:48 Weiss: 1BC0... Jul 14 19:33:06 gena2x: reading registers is slow, particularly the 3D ones, which invokes a penalty of 7 Arbitrary Unspecified Glamo Clock Units Jul 14 19:36:35 Weiss: so current settings are: Tcah=0, Tcoh=4cl, Tacc=4cl, Tcos=4cl, Tacs=0 Jul 14 19:36:58 Weiss: so it is exacly 2 times slower to what you told. Jul 14 19:37:37 and gives us 12Mb/s ran transfer spee. Jul 14 19:37:41 and gives us 12Mb/s raw transfer spee. Jul 14 19:37:46 mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Device.SetFunctionality full true "" Jul 14 19:37:53 makes it register and show signal strength... Jul 14 19:38:28 gena2x: add up some overhead to read dram (we are doing memcpy, not memset) Jul 14 19:38:42 Weiss: and we'll get our current situation. Jul 14 19:39:02 Weiss: let me tell you raw speed with new and old values... Jul 14 19:40:11 Weiss: this values you told in fact same to my values of my testing without pages. Jul 14 19:40:21 Weiss: the 141 didn't work for me. Jul 14 19:40:27 Weiss: the 1+4+1 didn't work for me. Jul 14 19:40:34 mrmoku: yep Jul 14 19:40:45 after this it registered to network Jul 14 19:42:57 Weiss: so, with default settings i can do 18 full screen copyes in 1 second Jul 14 19:43:47 Weiss: this means 11Mb/s memcpy. Jul 14 19:44:16 alexxy: and losses provider after some time :/ Jul 14 19:44:25 yep Jul 14 19:45:06 Weiss: or i can do something near 20 fs memsets, which means ~(640*480*2*20)=12.2Mb/s Jul 14 19:46:24 Weiss: with new settings, i can do... 30 fs memsets which means ~18.4Mb/s. Jul 14 19:46:24 hmm Jul 14 19:47:27 gena2x: dinnertime, but I'll be back... Jul 14 19:47:38 Weiss: or 24 fs memcpy. which means 14.7Mb/s. Jul 14 19:57:14 Weiss: ah, miscalculated. Jul 14 19:57:41 Weiss: current settings are 4+4+4, so actully=12 Jul 14 19:57:57 Weiss: new settings are 2+4+2, so actually 8 Jul 14 19:59:08 Weiss: so old theretical speed:((10^9/120)*2)/1024/1024=15.8Mb/s Jul 14 19:59:32 mrmoku: any ideas why its b0rked Jul 14 19:59:49 Weiss: new theoretical speed were calculated in right way: 23.8Mb/s Jul 14 20:01:38 Weiss: so, we have: old theretical/real/real copy: 15.8/12.2/11 Jul 14 20:03:27 Weiss: new settings theretical/real/real copy: 23.8/18.4/14.7 Jul 14 20:05:05 Weiss: no so bad. but yesterday i did other test - seem like this speed has too few influence on mplayer, while not in frambuffer, but in xglamo. Jul 14 20:09:26 mrmoku: I did cornucopia SRCREV bump yesterday + moved OE patches to fso repo.. but tested only twice and when it worked, I've pushed the upgrade.. Jul 14 20:09:53 alexxy: not yet Jul 14 20:10:02 mrmoku: so maybe it's some patch from few new in cornucopia repo Jul 14 20:10:13 фсегфдн цщклфкщгв зщыеув фе ырк-гыукы дшые Jul 14 20:10:18 oops Jul 14 20:10:19 =) Jul 14 20:10:24 JaMa: hmm... what patches are there... checking Jul 14 20:10:31 actualy workaroud was posted in shr-users list Jul 14 20:10:45 turn on and off antena Jul 14 20:10:50 then suspedn/resume Jul 14 20:14:24 mickeyl: 03ecd71d6c68e12fef157c2072baf70cef567d94 looks strange ... Jul 14 20:14:37 alexxy: interesting Jul 14 20:15:58 Weiss: hm. but why i assumed Tcos==2? Jul 14 20:16:09 JaMa: ahh, and 5e5640f93c5667e8eaab7361622a12b3c73dcd90 is probably the reason why the SetFunctionality call fails :/ Jul 14 20:16:36 have to fix that in phonefsod... correctly retry on that error Jul 14 20:17:04 Weiss: i have to set it to 1. Jul 14 20:17:19 Weiss: so, more testing... Jul 14 20:18:03 mrmoku: ah sorry for that.. I tried it when starting services manually.. so for me I had enough delay before SetFunctionality call Jul 14 20:18:13 JaMa: ok :) Jul 14 20:18:33 JaMa: though that is just one problem... because when doing SetFunctionality manually... it looses registration after some time Jul 14 20:25:10 gena2x: so.. I haven't really been following your numbers... does "new" mean "fastest according to the Glamo spec"? Jul 14 20:28:45 Weiss: and results for 1-4-2 (theory/memset/memcpy): 27.2/18.7/??? Jul 14 20:29:01 Weiss: but something wrong happened to glamo... Jul 14 20:29:21 Weiss: it is full-screen blinking now %) Jul 14 20:29:41 and sd seek nok. Jul 14 20:30:22 :o Jul 14 20:31:06 without any touching of it. yeah. 1fps blink :) Jul 14 20:31:30 but rebooted. Jul 14 20:31:37 rechecking timings.... Jul 14 20:33:09 mickeyl: not strange... my eyes are strange :P Jul 14 20:37:42 Weiss: found mistake in bin->hex.. rechecking. Jul 14 20:41:43 WHOOOT? [ 31.310000] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 Jul 14 20:43:20 hehe, I have that too Jul 14 20:46:36 Weiss: minor artefacts at 1-4-2 Jul 14 20:51:22 hmm.. maybe try 1-6-2? Jul 14 20:51:45 if 2-4-2 is ok, 1-6-2 look worse. Jul 14 20:52:17 ok, whole round again. Jul 14 20:52:29 but in different order. Jul 14 20:55:46 Weiss: 4-4-4 (0x1BC0): (theory/memset/memcpy) 15.8/12/10.5 Jul 14 20:57:22 Weiss: 2-4-2(0x1380): (theory/memset/memcpy) 23.8/17.5/14.0 Jul 14 20:59:45 Weiss: 1-4-2 (0x0B80): (theory/memset/memcpy) 27.2/?/? Jul 14 21:00:02 Weiss: something always happening with glamo at 1-4-2. Jul 14 21:00:16 Weiss: except artifacts. Jul 14 21:01:46 Weiss: it stop responding to om screen power 1 command. Jul 14 21:02:02 Weiss: it slows down 1.5 times to the level of 4-4-4. Jul 14 21:02:36 Weiss: if set other timing after setting 1-4-2, it is still slowed. Jul 14 21:02:51 Weiss: ok, lets try 1-6-2 Jul 14 21:04:04 Weiss: also, after setting 1-4-2, uboot can't load kernel. Jul 14 21:04:12 Weiss: after power down. Jul 14 21:04:53 Weiss: but after longer power down (power-down==remove battery), it is ok. Jul 14 21:07:02 what does 0x200 correspond to? Jul 14 21:07:10 (ref http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/003786.html) Jul 14 21:07:18 Weiss: 0-4-0 Jul 14 21:07:31 oh. Jul 14 21:07:33 no... Jul 14 21:07:52 Weiss: 0-3-0 Jul 14 21:08:08 0x200 is 0-0-3-0-0 Jul 14 21:08:21 0x1BC0 is 0-4-4-4-0 Jul 14 21:09:03 doesn't the third number have to be at least 4 when nwait is being honoured by the SoC? Jul 14 21:09:10 sure. Jul 14 21:09:42 it should be >=4clk. Jul 14 21:10:05 but 2==010==3clk Jul 14 21:10:51 to test 0-4-0 you should do 0x300. Jul 14 21:12:17 Weiss: lower settings are possible, but without nwait. Jul 14 21:12:31 Weiss: lowest possible 0-0-1-0-0. Jul 14 21:13:15 Weiss: ok, testing 1-6-2. Jul 14 21:13:28 so, I wonder if Andy meant that he also disabled nwait Jul 14 21:18:08 Weiss: 1-6-2: (theory/memset/memcpy) 21.1/17.5/?? Jul 14 21:18:37 Weiss: so, Tcos==1 timing are fast with memset, but failing with memcpy. Jul 14 21:19:40 and after that glamo enters to some strange mode. Jul 14 21:19:51 'slowed' Jul 14 21:20:07 find /sys|grep regs Jul 14 21:20:10 ops Jul 14 21:20:25 wrong terminal. want glamo registers in slow mode? Jul 14 21:21:20 hmm? Jul 14 21:21:40 unlikely to be anything useful in them.. Jul 14 21:21:54 (there aren't really any useful status registers) Jul 14 21:22:58 Weiss: but something happened with glamo after setting 1-X-2. Jul 14 21:26:28 Weiss: ahh. Jul 14 21:27:05 Weiss: it can't read my glamofbtest program for sd while in 1-4-2. Jul 14 21:27:22 muppet check: these numbers are Tcos/Tacc/Tcoh? Jul 14 21:27:58 yes. Jul 14 21:28:12 (actully rechecked) Jul 14 21:30:05 it's [Tacs(2):Tcosh(1)][Tcosl(1):Tacc[3]]:[TCoh(2):Tcah(2)]:[Tacp(2):PMC(2)] Jul 14 21:30:38 value is 0xB80 Jul 14 21:30:41 for 1-4-2 Jul 14 21:31:40 B is 1011, so acc=11 (4clk) Tacs=01 (1clk) Jul 14 21:34:03 *B is 1011, so acc=11 (4clk) Tcos=01 (1clk) Jul 14 21:37:18 Weiss: the artifacts is 3-4 white points on black screen. Jul 14 21:37:32 Weiss: means that some data were not actually written. Jul 14 21:37:46 Weiss: but very rare. Jul 14 21:37:53 Weiss: but this slowdown... Jul 14 21:38:15 heh. Jul 14 21:38:22 debian-gta02:/home/gena/glamo# ls Jul 14 21:38:22 dmamemcpy Jul 14 21:38:24 ... Jul 14 21:38:29 watchmemory.sh Jul 14 21:38:29 {?k??7?G???^????5T??????E???@?%??X~@?[?????,??ppswL??w???p?8L??F?w>Q;r!???eB??>?A%?????Q??e??W??hS!S??i???y??X?,?qX???=??Z??a???????n???2?[?mS?????l??7!72?22 Jul 14 21:38:39 nice file name :) Jul 14 21:39:29 moving to flash... Jul 14 21:39:41 hehe Jul 14 21:39:43 SD card doom? Jul 14 21:39:50 Weiss: after 1-4-2. Jul 14 21:40:53 .. which is what we decided should be the minimum that's within spec? :( Jul 14 21:41:02 yeah. Jul 14 21:41:09 but 2-4-2 is ok. Jul 14 21:41:18 so. hm. Jul 14 21:41:24 we have problem with write. Jul 14 21:41:39 i think i don't read. Jul 14 21:41:51 read ok btw. Jul 14 21:42:20 and write at 1-4-2 damages something in internal glamo state. Jul 14 21:43:21 and artifacts mean we somehow out of timings. Jul 14 21:58:41 debian-gta02:/# diff badglamo.regs.3 badglamo.regs.2 Jul 14 21:58:41 8c8 Jul 14 21:58:41 < 0040: 0000 0000 0aba 86de 0002 0000 0000 0000 Jul 14 21:58:41 --- Jul 14 21:58:41 > 0040: 05db 50e8 0aba 86c6 0003 0000 0000 0000 Jul 14 21:58:42 20c20 Jul 14 21:58:44 < 0300: 0000 afaf 0108 0010 0000 0000 0000 0000 Jul 14 21:58:46 --- Jul 14 21:58:48 > 0300: 0c74 afaf 0108 0010 0000 0000 0000 0000 Jul 14 21:58:51 and 'wobbling' Jul 14 22:02:08 these are the "core" registers? Jul 14 22:02:21 Weiss: wait, i'll push all to web. Jul 14 22:03:13 bsdmn.com/openmoko/glamo/test/1-4-2regs Jul 14 22:03:27 goodregs - before test, 2 snapshots. Jul 14 22:04:03 badglamo 1 and 2 - after setting 1-4-2 and some testing, but before wobbling. Jul 14 22:04:20 badglamo.3 - after final state Jul 14 22:06:18 Weiss: so i assume we can set 2-4-2. Jul 14 22:06:25 Weiss: as a minimum. Jul 14 22:06:38 Weiss: i testing this for few days without any problems. Jul 14 22:07:07 Weiss: qtmoko (on .29 ok), my .34 and sd were ok. Jul 14 22:08:05 Weiss: or need to understand what is happening in write cycle with 1-4-2 Jul 14 22:08:37 yeah Jul 14 22:09:07 the regs 0x0040 and 0x0042 are crazy PLL registers - they definitely shouldn't be changing Jul 14 22:10:50 Weiss: sure? i see change in 0x42 between goodglamo.1 and goodglamo.2 Jul 14 22:11:15 Weiss: so, it happened while we were in good state. Jul 14 22:12:02 or maybe reading that register isn't allowed Jul 14 22:13:10 0x0300 is in that memory controller region that isn't included in the docs Jul 14 22:15:04 Weiss: i saw amazing comment about 0x300 in kernel code: GLAMO_REG_MEM_TYPE GLAMO_REG_MEM_TYPE 839 drivers/mfd/glamo-core.c { GLAMO_REG_MEM_TYPE, 0x0c74 }, /* 8MB, 16 word pg wr+rd */ Jul 14 22:15:42 so, if it is ehm... reset to 0 :) Jul 14 22:17:14 also, my .29 prints much more regs. Jul 14 22:17:26 so something else may be changed. Jul 14 22:20:03 Weiss: (i already saw similar thing why did investigation attampt for 1-4-1) Jul 14 22:20:11 *while Jul 14 22:22:50 Weiss: ok. lets continue tomorrow. Jul 14 22:23:21 Weiss: at a minimun i'll contunue tomorrow. Jul 14 22:23:40 yeah, sleepy time here Jul 14 22:24:01 Weiss: my plan is following: do measure diff of mplayer -vo fbdev, with procieve profiling data. Jul 14 22:24:29 Weiss: and measure same thing with -vo x11 with glamo accelerated driver. Jul 14 22:24:56 s/procieve/preciese/ Jul 14 22:25:27 for some 640x480 movies with really slow fps. Jul 14 22:26:40 Weiss: so, it's nice i now have official approve that 2-4-2 fits glamo specs! Jul 14 22:26:45 yeah :D Jul 14 22:26:50 "official", at least Jul 14 22:27:27 Weiss: so, i'm way close to the end of this timings story. Jul 14 22:27:44 I'm still curious about this page mode thingy Jul 14 22:27:55 it's not supposed to work, but it still kind of did.. Jul 14 22:27:58 (?) Jul 14 22:28:05 Weiss: page mode is a bit timings. Jul 14 22:28:10 *fit Jul 14 22:28:17 for write. Jul 14 22:28:55 as you told, glamo can do 30ns. Jul 14 22:29:35 and Tacp (Tacc for page) is not limited to 40ns. Jul 14 22:29:43 even with nwait. Jul 14 22:29:58 so seem just somehow it worked. Jul 14 22:30:00 ahhh! Jul 14 22:30:18 btw, it worked with Tacp==4clk. Jul 14 22:31:07 but in some rare cases failed. Jul 14 22:31:17 but worked reliably at 6clk. Jul 14 22:31:42