**** BEGIN LOGGING AT Wed Dec 04 02:59:58 2013
Dec 04 13:54:11 <ant_work> hi lumag_
Dec 04 13:54:18 <lumag_> hello ant_work
Dec 04 13:55:02 <ant_work> lumag_: while struggling with mtd, have you sent to broonie the SD driver for review?
Dec 04 13:55:12 <lumag_> No.
Dec 04 13:55:35 <lumag_> It depends on rewritten locomo support.
Dec 04 13:55:50 <lumag_> And it broke fb resume
Dec 04 13:56:45 <lumag_> And why send it to broonie?
Dec 04 13:56:48 <ant_work> ok, I remember he said to use the _one_transfer and not _transfer and to add workqueue.
Dec 04 13:56:58 <lumag_> Ah, Mark is now SPI maintainer
Dec 04 13:57:09 <lumag_> I used spi-bitbang, which does that already
Dec 04 13:57:32 <ant_work> yep, I've seen (not that I understand much ;)
Dec 04 13:57:48 <lumag_> Basically it's a framework for simple spi host drivers.
Dec 04 13:58:10 <ant_work> I know it only wrt Kconfig options
Dec 04 13:58:21 <lumag_> Not to be confused by the name -bigbang, which came from 'gpio bitbanging' driver, where you have several GPIO linees which you toggle by hand
Dec 04 14:00:16 <ant_work> about mtd... some indices in that printk heap
Dec 04 14:01:17 <lumag_> Did not have time to look. Sorry.
Dec 04 14:02:41 <lumag_> Did you find anything there?
Dec 04 14:03:00 <ant_work> maybe
Dec 04 14:03:23 <ant_work> before going 'crazy' (the inline_map_read 0 lines)
Dec 04 14:03:33 <ant_work> there is a suspicious sequencxe
Dec 04 14:04:10 <ant_work> around #551  http://pastebin.com/U650dAP2
Dec 04 14:04:33 <ant_work> block erase?
Dec 04 14:04:34 <ant_work> inline_map_write 200020
Dec 04 14:04:34 <ant_work> inline_map_write d000d0
Dec 04 14:04:46 <ant_work> maybe was suspended before
Dec 04 14:05:25 <ant_work> this happens during the buffer write loop
Dec 04 14:06:26 <ant_work> oh, and besides that I'm perplexed: sometimes the status is read
Dec 04 14:06:27 <ant_work> inline_map_read 80808080
Dec 04 14:06:41 <ant_work> other times
Dec 04 14:06:43 <ant_work> inline_map_read 800080
Dec 04 14:07:02 <ant_work> as far as I see, the AND operations don't change
Dec 04 14:07:22 <ant_work> i.e. 0x800080 & 0x30
Dec 04 14:07:38 <ant_work> is 0x80808080 & 0x30
Dec 04 14:08:39 * lumag_ is currently looking at http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=291024269292. 
Dec 04 14:08:44 <lumag_> That is somewhat strange.
Dec 04 14:09:37 <ant_work> I fear this can lead to improper Xstatus readings...
Dec 04 14:10:02 <lumag_> All readings should be one-byte wide (well 0x00 byte 0x00 byte)
Dec 04 14:11:11 <ant_work> see
Dec 04 14:11:12 <ant_work> if (map_word_andequal(map, status, status_OK, status_OK))
Dec 04 14:11:52 <ant_work> 277         for (i=0; i<map_words(map); i++) {
Dec 04 14:11:52 <ant_work> 278                 if (val1.x[i] != val2.x[i])
Dec 04 14:11:53 <ant_work> 279                         return 0;
Dec 04 14:11:53 <ant_work> 280         }
Dec 04 14:11:53 <ant_work> 281         return 1;
Dec 04 14:11:57 <lumag_> Yes, I'm talking about hardware - each chip is should return 1 byte width status (IIUC).
Dec 04 14:12:24 <lumag_> Sorry, gtg now.
Dec 04 14:12:29 <ant_work> bye
Dec 04 14:12:31 <lumag_> I'll be back in a few hours.
Dec 04 14:47:20 <lumag> ant_work, I'm back
Dec 04 15:12:07 <ant_work> that was fast ;)
Dec 04 23:32:25 <ant_home> lumag: I think I might have founs mthg in the buffer write program
Dec 04 23:33:23 <ant_home> seems that XSR is read 800080
Dec 04 23:33:55 <ant_home> but SR gives 80808080
Dec 04 23:35:01 <ant_home> anyway, comparing the buffer write examples ( )
Dec 04 23:37:27 <ant_home> inline_map_write d000d0
Dec 04 23:37:27 <ant_home> inline_map_read 0
Dec 04 23:38:07 <ant_home> that means after confirming the program buffer Status Register SR.7 = 0
Dec 04 23:38:16 <ant_home> WSM Busy
Dec 04 23:38:32 <ant_home> (See table 2 for error checking)
Dec 04 23:51:52 <lumag> ant_home, I think now I understand how I sound for you sometimes. Can't follow your ideas :)
Dec 04 23:52:58 <ant_home> you see, I miss the e-engineer formation needed to solve those cases ;)
Dec 04 23:54:06 <ant_home> as far as I see, the WSM is not ready, though the code continues to write to the buffer
Dec 04 23:55:30 <ant_home> I was reading the examples here  https://github.com/andrea-adami/collie-nor-flash/blob/master/Buffer-DSA00390028.pdf
Dec 04 23:56:25 <ant_home> XSR or SR should return 1
Dec 04 23:57:06 <ant_home> that is 80H
Dec 04 23:58:57 <ant_home> 10000000
Dec 05 00:01:10 <ant_home> so in the log I have it happens:
Dec 05 00:01:11 <ant_home> inline_map_write e800e8
Dec 05 00:01:12 <ant_home> inline_map_read 800080
Dec 05 00:01:24 <ant_home> (ok, buffer program available)
Dec 05 00:01:50 <ant_home> then the inline_map_write f000f and 16x inline_map_write XX
Dec 05 00:02:00 <ant_home> then the issue:
Dec 05 00:02:15 <ant_home> we send program confirmation
Dec 05 00:02:16 <ant_home> inline_map_write d000d0
Dec 05 00:02:31 <ant_home> and the first answer we get is 0
Dec 05 00:02:31 <ant_home> inline_map_read 0
Dec 05 00:02:54 <ant_home> SR.7 = 0 ⇒ WSM Busy
Dec 05 00:02:54 <ant_home> (See Table 2 for error checking.)
Dec 05 00:03:17 <ant_home> the error checking code is also dubious...
Dec 05 00:07:57 <ant_home> ok, will continue tomorrow
Dec 05 00:07:59 <ant_home> gn
Dec 05 00:29:10 <bikerer> hrmf, finally got my kexecboot image to stay alive after booting android, but still adb is awol
Dec 05 00:29:34 <bikerer> cant seem to activate developer options at all o0
**** ENDING LOGGING AT Thu Dec 05 02:59:58 2013