**** BEGIN LOGGING AT Fri Nov 29 02:59:58 2013
**** BEGIN LOGGING AT Fri Nov 29 09:18:38 2013
Nov 29 23:55:34 <lumag_> ant_home, hello
Nov 29 23:58:57 <ant_home> hi lumag_
Nov 30 00:00:14 <lumag_> Any progress with flash?
Nov 30 00:01:38 <ant_home> I have some plans but I'm still recompiling OE atm :/
Nov 30 00:02:19 <ant_home> smthg like  http://mhonarc.axis.se/jffs-dev/msg00703.html
Nov 30 00:25:04 <lumag__> ant_home, ok
Nov 30 00:25:22 <lumag__> I still suspect that it is a timings/settings issue
Nov 30 00:25:28 <ant_home> neverthless, the flashed jffs2 boots
Nov 30 00:26:46 <ant_home> can we get the timings disassembling the code on flash or the 2.4 drivers?
Nov 30 00:27:05 <ant_home> if we do not trust tech sheet and cfi query...)
Nov 30 00:34:35 <lumag__> Maybe it is a problem of bursts.
Nov 30 00:34:46 <lumag__> *using bursts.
Nov 30 00:34:55 <lumag__> It should not be,
Nov 30 00:37:53 <lumag__> I can try disassembling bootloader.
Nov 30 00:38:11 <ant_home> the torture-test and ubiupdatevol got status 8080
Nov 30 00:38:46 <lumag__> 2.4 kernel did not have write-compatible mtd driver for sharp flash.
Nov 30 00:38:53 <lumag__> Only simple mtdrom driver
Nov 30 00:38:58 <ant_home> ah
Nov 30 00:39:19 <ant_home> 80h = 10000000 = all status bits are 0
Nov 30 00:39:40 <ant_home> and the extended status is the 7th
Nov 30 00:39:51 <ant_home> (when running program buffer)
Nov 30 00:41:06 <lumag__> Maybe we should check old sharp.c driver. It might have some clues
Nov 30 00:45:19 <ant_home> lumag__: cmdset_0002 has some more tricks
Nov 30 00:45:24 <ant_home> see this recent msg:  http://lists.infradead.org/pipermail/linux-mtd/2013-April/046482.html
Nov 30 00:46:04 <ant_home> and btw otp needs probably a fixup like for some Intel
Nov 30 00:46:14 <ant_home> <------>/* Some chips have OTP located in the _top_ partition only.
Nov 30 00:46:14 <ant_home> <------>   For example: Intel 28F256L18T (T means top-parameter device) */
Nov 30 00:48:22 <ant_home> we have in cmdset_0001
Nov 30 00:48:24 <ant_home> <------>/* let's ensure we're not reading back cached data from array mode */
Nov 30 00:48:24 <ant_home> <------>INVALIDATE_CACHED_RANGE(map, chip->start + offset, size);
Nov 30 00:48:52 <ant_home> and mutex lock/unlock
Nov 30 00:57:30 <ant_home> hmmmm
Nov 30 00:57:32 <ant_home> map_word status, status_OK = CMD(0x80);
Nov 30 00:59:39 <ant_home> ...
Nov 30 00:59:41 <ant_home> <------><------>status = map_read(map, cmd_adr);
Nov 30 00:59:41 <ant_home> <------><------>if (map_word_andequal(map, status, status_OK, status_OK))
Nov 30 00:59:41 <ant_home> <------><------><------>break;
Nov 30 01:10:17 <lumag__> status = *cmd_addr;
Nov 30 01:10:27 <lumag__> if (status & status_OK == status_OK(
Nov 30 01:10:30 <lumag__> break;
Nov 30 01:10:37 <lumag__> I hate this map_* interface
Nov 30 01:14:49 <ant_home> ok, will try to cook some tests tomorrow morning
Nov 30 01:14:51 <ant_home> gn
Nov 30 01:20:06 <lumag__> gn
**** ENDING LOGGING AT Sat Nov 30 02:59:59 2013