**** BEGIN LOGGING AT Sat Dec 28 02:59:58 2013 Dec 28 13:29:28 lumag_: I have a now idea but I'm lost agains typecasting Dec 28 13:29:38 ant_home, hello Dec 28 13:30:18 maybe this applies wrt 0xFFFF in the first 'bank' ? Dec 28 13:30:20 <------>/* According to JEDEC "Standard Manufacturer's Identification Code" Dec 28 13:30:20 <------> * (http://www.jedec.org/download/search/jep106W.pdf) Dec 28 13:30:20 <------> * several first banks can contain 0x7f instead of actual ID Dec 28 13:30:20 <------> */ Dec 28 13:31:37 the idea of patch is http://pastebin.com/D8krjL1Q Dec 28 13:32:17 but the error is /mtd/chips/cfi_util.c:50:2: error: incompatible types when returning type 'long unsigned int' but 'map_word' was expected Dec 28 13:32:23 so I have to do some memcpy Dec 28 13:33:01 maybe only one chip is answering to cfi query? Dec 28 13:35:19 you see, all subsequent calls to map_read are ok, 2 interleaved 16 Dec 28 13:35:28 it is just the initial detection code failing Dec 28 13:36:34 and the very first probe is Dec 28 13:36:35 inline_map_write 980098 ofs 154 Dec 28 13:36:35 inline_map_read ffff0051 ofs 40 Dec 28 13:36:35 inline_map_read ffff0052 ofs 44 Dec 28 13:36:35 inline_map_read ffff0059 ofs 48 Dec 28 13:37:22 but further logs of ubi/jffs2 utils shows 2 chips responding Dec 28 13:37:34 another indice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/chips/cfi_probe.c?id=987d24018dc83d27e491674c50ff2272f51eb719 Dec 28 13:37:59 fi_read_query16 works fine Dec 28 13:38:11 *cfi_read_query16 Dec 28 13:58:43 I dont know :( Dec 28 13:59:46 It really looks like second chip not receiving QRY. However I don't know why that is happening. Dec 28 14:12:01 I've read again the functions in map.h and these appear to handle for 1 word = 32bit width. Then the code splits for 2 chips Dec 28 14:12:36 these functions are ok in the other calls apart QRY code Dec 28 14:13:22 still sometimes they return 0x808080 as for 4 chips 8b... Dec 28 14:13:26 ? Dec 28 14:14:04 anyway, let see if that modified patch works Dec 28 14:14:48 about partitioning, I'd love to have it done in collie.c Dec 28 14:15:05 the bonus is, device is in read array mode after that Dec 28 14:51:57 :/ no good effect.. Dec 28 14:52:10 lumag_: pls see http://www.infradead.org/pipermail/linux-mtd/2005-December/014519.html Dec 28 14:56:04 it seems we should expect a 16 bit answer at a given address on the 32bit bus Dec 28 14:58:20 Then how would we detect second chip? Dec 28 14:58:36 Author talks about sending 8-bit probe to 32-bit width bus. Dec 28 14:58:42 the code about alias is confusing Dec 28 14:58:45 Ahm. Dec 28 14:58:49 32-bit probe Dec 28 14:58:58 word = 4bytes Dec 28 14:59:22 offset 0x10 -> 0x40 as byte address Dec 28 14:59:24 His situation: sent 0x00000098. (so 'high' chip is in read mode, 'low' chip receives QRY command) Dec 28 14:59:47 ehm..which one is chip(0) and (1)? Dec 28 15:00:08 Then he reads 0x0000 0051 (high 0x0000 comes from read data, low is 'Q'). Thus QRY thinks that it is one 32-bit width chip. Dec 28 15:00:33 Had he sent 0x0098 0098, he would have received 0x0051 0051 - both chips would respond Dec 28 15:00:38 That is my understanding Dec 28 15:03:43 hm, so you think both should respond to CFI query? Dec 28 15:03:54 why does the code chec for aliases? Dec 28 15:04:19 the check is exactly the same QRY detection code Dec 28 15:05:40 if I'm not wrong, we just see the memory linear, starting from 0x0 and with each 32bit word split 2bytes on one chip and 2 bytes on the other Dec 28 15:06:24 so at any address we peek both chips Dec 28 15:06:51 Consider the following: we have 1 16-bit chip on 32-bit bus. Dec 28 15:07:07 Ah now. Dec 28 15:07:10 not. Dec 28 15:07:43 We have two 2-Mb chips at 2Mb bus (from the address width perspective). Dec 28 15:07:54 Sorry. Dec 28 15:07:59 two 1-Mb Dec 28 15:08:21 MTD code will identify first chip, compute length, then probe after that chip, find next chip, etc. Dec 28 15:08:36 So QRY probing will correctly identify both chips Dec 28 15:08:49 * here chips are not interleaved, but present sequentially Dec 28 15:08:58 yes, I see Dec 28 15:09:14 If we drop second 1Mb chip, the highest line will be unconnected, so a 1Mb chip will be detected twice. Dec 28 15:10:00 ok, as it happens with the 32MB mask we have for collie if not resized Dec 28 15:10:14 2xdetection Dec 28 15:10:21 I follow;) Dec 28 15:14:32 lumag_: I'll ask linusw to add souple of printk on map.h and see h3600 2xstrataflash logs... Dec 28 15:15:07 it's another 2x16 on 32b Dec 28 20:57:14 lumag, for fun.. it seems bankwidth must be set to 2 (16 bit)... Dec 28 20:57:24 http://www.informit.com/articles/article.aspx?p=1187102&seqNum=8 Dec 28 20:57:39 from Essential Linux Device Drivers Dec 28 21:38:11 lumag: maybe we misunderstand: bank 0 is CS0 so the sa1100 bus can shared by 2 pairs of interleaved chips if CS1 would exist (not on collie)? Dec 28 21:38:57 s/we/I/ Dec 28 21:40:27 he he Dec 28 21:40:38 I get detection without that ugly hack Dec 28 21:40:53 the new one is not so nasty... Dec 28 21:45:27 lumag_: the commented bootlog http://pastebin.com/GeSYcsv2 Dec 28 21:46:35 I 'alias' the final val [Q,R,Y] basing on the read of one single chip Dec 28 21:47:02 so it must be in Qery Mode (0x98) Dec 28 21:47:18 much better than previous hack... Dec 28 21:49:25 Heh. How did you do that? Dec 28 21:49:50 partitioning does not work. Dec 28 21:49:53 I show you if you promise to do that with 2-3 lines ;) Dec 28 21:50:13 We still need to fix PCRC Dec 28 21:50:22 can you do that in collie.c Dec 28 21:50:25 ? Dec 28 21:50:44 We can do that if it's absolutely required. Dec 28 21:51:07 Should we do PCRC fixup before QRY detection? Dec 28 21:51:17 That would be the only reason to do that in collie.c Dec 28 21:52:42 http://pastebin.com/9MdVgXSk Dec 28 21:52:52 I'm trying to clean it better.. Dec 28 21:52:58 'Q is 510051' - is that reading from a chip or your print. Dec 28 21:53:19 my hedit Dec 28 21:53:35 true reading is 0xff0051 Dec 28 21:53:41 0xffff0051 Dec 28 21:54:42 there must be a better way, like shifting 0051 left Dec 28 21:54:49 and adding it Dec 28 21:55:18 Hmm. Dec 28 21:55:26 /<---->myval[0] = cfi_read_sharp(map, base + osf*0x10, cfi) - 0xFFAE0000 - 0x10000; Dec 28 21:55:26 /<---->myval[0] = cfi_read_sharp(map, base + osf*0x10, cfi) - 0xFFAE0000 - 0x4000 * osf; Dec 28 21:55:26 /<---->myval[1] = cfi_read_sharp(map, base + osf*0x11, cfi) - 0xFFAD0000 - 0x4000 * osf; Dec 28 21:55:26 /<---->myval[2] = cfi_read_sharp(map, base + osf*0x12, cfi) - 0xFFA60000 - 0x4000 * osf; Dec 28 21:55:26 /<---->myval[0] = cfi_read_sharp(map, base + osf*0x10, cfi) - (0x3FEB8000 + 0x4000) * osf; Dec 28 21:55:39 This still does not fix the upper chip reading. Dec 28 21:55:59 nope but the CFI values are read (8bit) Dec 28 21:56:17 then successive readings i.e. from status register appear ok Dec 28 21:56:19 So only QRY does not work for the 'upper' chip? Dec 28 21:56:24 seems so Dec 28 21:56:43 That is really _so_ strange Dec 28 21:57:19 more strange is the example shows map bankwidth = 16 even with buswidth 32 Dec 28 21:58:18 I retry now with interleave 2, and width 2...takes just few mins Dec 28 21:58:32 soo strange... ;) Dec 28 22:02:54 ah, finally we need that little fixup for manufacturer Sharp and CFI 1.3: there are two more fields wrt burst read so the 'nr of partition' is 2 offsets later Dec 28 22:03:23 Yep. And even with that fix Linux would get partitioning wrong. Dec 28 22:03:32 heh, 0 Dec 28 22:10:38 so lumag: ((0xffff0051 & 0xffff) << 16) + 0xffff0051 Dec 28 22:11:20 err: ((0xffff0051 & 0xffff) << 16) + 0x0051 Dec 28 22:11:33 should be this liner Dec 28 23:14:28 OOPS / BUG Dec 28 23:14:29 PC is at simple_map_init+0xc/0x44 Dec 28 23:14:29 LR is at sa1100_mtd_probe+0x170/0x340 Dec 28 23:15:17 I see mapwidth is set in sa1100-flash.map Dec 29 00:41:03 ok... detection works vanilla if map bankwidth is set to 2 (16B) and interleave to 1 (but then we have one single chip...8192 kb) Dec 29 00:41:42 http://pastebin.com/0Bn9jhC9 **** ENDING LOGGING AT Sun Dec 29 02:59:58 2013