**** BEGIN LOGGING AT Mon Dec 30 02:59:58 2013 Dec 30 10:57:32 lumag_: I'm testing with PCR 700 = 4 partitions... Dec 30 10:58:15 btw you were right: Sharp has two empty unexpected fields, they are to blame ;) Dec 30 10:58:17 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/chips/cfi_cmdset_0001.c?id=6f6ed056d2d5de7af9f0c14cf5bc73707eeb0a88 Dec 30 11:00:47 the value at that offset is the number of Sync Read Configs following fields. Sharp has 0 but still takes trwo offsets for CONF2 and CONF3 Dec 30 11:01:35 the +2 in the code is because CONF1 is always present, marked as reserved Dec 30 11:01:48 (If I don't get it wrong ;) Dec 30 11:07:42 ant_work, Hello Dec 30 11:07:54 Yes, that is what I was talking about. Dec 30 11:08:05 I lost the irclogs.. :/ Dec 30 11:08:21 They simply copied filed offsets from some Strataflash (?) - but did not update them. Dec 30 11:08:44 Strataflash marks tha offset for conf1 as reserved Dec 30 11:08:55 newer flashes have 5 Sync modes Dec 30 11:09:49 what I found (new) is some flashes with >1 OTP blocks have extra 10 fields Dec 30 11:10:11 this is intelext_otpinfo Dec 30 11:10:38 ie. in the tech sheet of Intel 28F640L18 Dec 30 11:11:53 and this fields are between OTP info and Burst/Page Read info... Dec 30 11:12:57 still CFI 1.3 Dec 30 11:14:18 ok, let fix that to the poor owners ;) Dec 30 11:15:54 hm.. this is perhaps the code Dec 30 11:15:55 653 offs = (extp->NumProtectionFields - 1) * Dec 30 11:15:55 654 sizeof(struct cfi_intelext_otpinfo); Dec 30 11:18:20 our OTP Block appears 1 + 4 Dec 30 11:19:22 at following address we have Burst Read Info Dec 30 11:20:00 ..better to add some printk Dec 30 11:21:49 lumag_: https://github.com/andrea-adami/meta-handheld/commits/master Dec 30 11:22:00 just missing the partitions fix Dec 30 11:22:12 hope to finish it this evening Dec 30 11:22:19 bbl Dec 30 11:22:33 :) **** BEGIN LOGGING AT Mon Dec 30 12:01:50 2013 Dec 30 12:39:42 lumag_: do you think the detection hack should check for all 3 QRY? Dec 30 13:05:59 heh, I've discovered a bug in Windows7 calculator...bitshift is wrong for hex ;) Dec 30 13:06:18 I was re-checking the test and got strange results... Dec 30 13:06:37 1H << 16 = 400000 ??? Dec 30 13:07:11 1 << 16 = 65536 OK Dec 30 13:07:34 you see why Win drivers are buggy sometimes ? ;) Dec 30 13:08:32 ok, the result is in Dword.. Dec 30 13:09:18 pretty cumbersome calculator, good for me I hse toe one of Gnome :) Dec 30 13:09:27 bbl Dec 30 13:09:29 bye **** ENDING LOGGING AT Tue Dec 31 02:59:58 2013