**** BEGIN LOGGING AT Mon Dec 02 02:59:58 2013
Dec 02 10:42:53 <ant_work> lumag, I see errors also with FORCE_WORD_WRITE 0
Dec 02 11:43:44 <ant_work> lumag, and the old sharp driver had  sharp_do_wait_for_ready ->
Dec 02 11:43:44 <ant_work>  timeo = jiffies + HZ * 10;
Dec 02 11:43:57 <ant_work> now everywhere it is
Dec 02 11:43:58 <ant_work>  timeo = jiffies + HZ;
Dec 02 12:44:50 <lumag> ant_work, hello.
Dec 02 12:44:57 <lumag> We can try increasing timeout.
Dec 02 12:45:20 <ant_work> hi
Dec 02 12:46:10 <ant_work> ehm..are we using nohz / hz=0 / hz = 100 exactly?
Dec 02 12:46:43 <ant_work> something changed for sa1100 ?
Dec 02 12:47:36 <ant_work> anyhow, misteriously I can flash the ubi volume....
Dec 02 12:58:10 <ant_work> lumag: having tried with all three options disabled I'd say the error is elsewhere
Dec 02 12:58:14 <ant_work> ( 39 /* #define CMDSET0001_DISABLE_ERASE_SUSPEND_ON_WRITE */
Dec 02 12:58:14 <ant_work>  40 /* #define CMDSET0001_DISABLE_WRITE_SUSPEND */
Dec 02 12:58:14 <ant_work>  41
Dec 02 12:58:14 <ant_work>  42 // debugging, turns off buffer write mode if set to 1
Dec 02 12:58:14 <ant_work>  43 #define FORCE_WORD_WRITE 0)
Dec 02 13:01:08 <ant_work> I've seen in the logs
Dec 02 13:01:09 <ant_work>   printk(KERN_WARNING "SR.4 or SR.5 bits set in buffer write (status %lx). Clearing.\n", status.x[0]);
Dec 02 13:01:26 <ant_work> and this means som eerror during buffer program
Dec 02 13:02:10 <ant_work> I think it is here, before rewuming, that the error happens
Dec 02 13:02:22 <ant_work> s/rewuming/resuming/
Dec 02 13:03:24 <lumag> Does that status.x[0] make sense?
Dec 02 13:03:50 <lumag> I have checked u-boot sources.
Dec 02 13:04:21 <lumag> There are 3 boards programming MSC0 register (for NOR). All of them use non-burst mode, while collie's bootloader specifically enables bursts
Dec 02 13:04:29 <lumag> That also might be a problem.
Dec 02 13:04:50 <ant_work> > SR.4 or SR.5 bits set in buffer write (status ffffffff). Clearing.
Dec 02 13:07:03 <ant_work> th edocs explicitely says that if the erase/write program is interrupted the chip stays in FL_STATUS
Dec 02 13:07:44 <lumag> staus ~0 is extremly suspicious for me.
Dec 02 13:09:19 <ant_work> same as in our infamous message
Dec 02 13:09:22 <ant_work> 1700                 printk(KERN_ERR "%s: Chip not ready for buffer write. Xstatus = %lx, status = %lx\n",
Dec 02 13:09:22 <ant_work> 1701                                 map->name, Xstatus.x[0], status.x[0]);
Dec 02 13:09:36 <ant_work> >sa1100: Chip not ready for buffer write. Xstatus = 80808080, status = 80808080
Dec 02 13:10:08 <ant_work> I'll try HZ * 10 as first....
Dec 02 13:11:21 <ant_work> btw, last 2 comments from dwmw2
Dec 02 13:11:23 <ant_work> dwmw2> have you got logs of the precise pattern of reads/writes, and compared with the datasheet?
Dec 02 13:11:31 <ant_work> <dwmw2> it's easy enough to put the prints into the map read and write functions, right?
Dec 02 13:11:33 <ant_work> heh...
Dec 02 13:12:45 <ant_work> lumag: there is a typical case for failure, it is when you have written n-1 times to the buffer (so you are within the 32K range address)
Dec 02 13:12:54 <ant_work> next write causes program error
Dec 02 13:13:31 <lumag> Just add those printks :)
Dec 02 13:21:01 <ant_work> seems we are in the case of  4.10 Page Buffer Program Command
Dec 02 13:42:59 <ant_work> btw, the x[0] is set in inline_map_read
Dec 02 13:43:22 <ant_work> r.x[0] = __raw_readl(map->virt + ofs);
Dec 02 13:43:34 <ant_work> return r;
Dec 02 15:32:56 <lumag> Yes.
Dec 02 15:33:26 <lumag> See - normally CFI flash behaves like a rom - set an address, get the data.
Dec 02 15:33:43 <lumag> After writing special command sequences, you can read registers.
Dec 02 15:35:20 <lumag> Instead of data
Dec 02 15:52:45 <ant_work> yes, after 0xF0
Dec 02 15:53:50 <ant_work> err.. 0x70
Dec 02 15:58:12 <ant_work> lumag, there is one point where I could not find evidence in the docs about issuing a CMD(0x70)
Dec 02 15:58:18 <ant_work> http://lxr.free-electrons.com/source/drivers/mtd/chips/cfi_cmdset_0001.c#L1007
Dec 02 16:03:25 <lumag> an evidence that it is safe?
Dec 02 16:04:16 <ant_work> the workflow doesn't show any 0xF0 after a 0xD0 (resume)
Dec 02 16:04:28 <ant_work> instead, I see 0xFF (read array)
Dec 02 16:04:41 <ant_work> no evidence it is needed
Dec 02 16:05:03 <ant_work> and here the status is not read
Dec 02 16:22:13 <lumag> In my case (error during unlock/bootup) adding extra map_write(map, CMD(0x70), adr) in a FL_STATUS loop
Dec 02 17:05:23 <ant_work> probably in chip_ready
Dec 02 17:06:21 <lumag> yes
Dec 02 17:07:07 <ant_work> which is called by get_chip
Dec 02 17:08:43 <ant_work> I don't understand FL_SYNCING
Dec 02 17:09:50 <ant_work> I see an old patch for contenttion
Dec 02 17:09:51 <ant_work> http://lists.infradead.org/pipermail/linux-mtd-cvs/2008-September/006304.html
Dec 02 17:12:10 <ant_work> ok, heading home. will try some hacks later
Dec 02 17:12:19 <ant_work> bbl
Dec 02 20:55:54 <ant_home> lumag__: I've put all the interesting docs here  https://github.com/andrea-adami/collie-nor-flash
Dec 02 20:56:16 <ant_home> Jay7: there are pre-built images for akita there
Dec 02 20:56:41 <Jay7> cool!
Dec 02 20:56:59 <Jay7> I've built sato image but haven't tried it yet
Dec 02 21:50:52 <ant_home> lumag: increased timeo but flashcp still fails...
Dec 02 21:51:05 <ant_home> and
Dec 02 21:51:06 <ant_home> root@collie:~# ubimkvol /dev/ubi0 -N rootfs -m
Dec 02 21:51:06 <ant_home> Set volume size to 14272896
Dec 02 21:51:06 <ant_home> SR.4 or SR.5 bits set in buffer write (status 23494255). Clearing.
Dec 02 23:52:57 <ant_home> lumag__: I'm collecting the logs
Dec 02 23:53:30 <ant_home> first, w/out COMPLEX_MAPPINGS
Dec 03 00:13:15 <ant_home> http://pastebin.com/xQ4X9B1H
**** ENDING LOGGING AT Tue Dec 03 02:59:58 2013