**** BEGIN LOGGING AT Thu Nov 07 02:59:58 2013
Nov 07 09:08:51 <ant_work> lumag_: gm
Nov 07 09:09:03 <lumag_> hello ant_work
Nov 07 09:09:20 <ant_work> lurking in the code, I see things like http://lxr.free-electrons.com/source/include/linux/mtd/cfi.h#L493
Nov 07 09:09:36 <ant_work> return val.x[0] & 0xff;
Nov 07 09:11:56 <ant_work> or e.g. fixup_st_m28w320cb  ->  (cfi->cfiq->EraseRegionInfo[1] & 0xffff0000) | 0x3e;
Nov 07 09:13:23 <ant_work> I'm pretty sure we have to & 0xffff the readings of CFI query to 0x98
Nov 07 09:17:15 <ant_work> "The device outputs "00H" data on upper byte (DQ15-8) in the read query mode. When verifying the query code information the upper byte data should be ignored"
Nov 07 09:17:50 <ant_work> appendix page 60
Nov 07 09:20:15 <lumag_> That is about 0x00
Nov 07 09:20:27 <lumag_> and that bit is ignored
Nov 07 09:20:35 <lumag_> well. not ignored, handled.
Nov 07 09:20:44 <ant_work> flipped...
Nov 07 09:20:47 <lumag_> The problem is in the upper word
Nov 07 09:20:53 <lumag_> D31-16
Nov 07 09:21:04 <lumag_> Which come from second flash chip
Nov 07 09:21:05 <ant_work> I'd have expected 0x0000 and we got 0xffff
Nov 07 09:21:08 <lumag_> or should come
Nov 07 09:21:45 <lumag_> See: after receving 0x98 command, every chip will respond on its data bits.
Nov 07 09:22:04 <lumag_> And each chip should receive command
Nov 07 09:22:11 <ant_work> even if interleaved?
Nov 07 09:22:23 <lumag_> That is why I asked you to print commands.
Nov 07 09:22:30 <lumag_> Do you remember :
Nov 07 09:22:43 <lumag_> cfi_send_gen_cmd->VAL: f000f0
Nov 07 09:22:54 <lumag_> That is f0 for one chip and f0 for another one
Nov 07 10:19:56 <ant_work> lumag_: could it be that the ghost chip detected on 0x1000000 is bogus?
Nov 07 10:20:09 <lumag_> yes
Nov 07 10:20:22 <lumag_> it is just a misdetected "alias" of 0x0000 chip
Nov 07 10:20:52 <ant_work> would you  try changing map_desc collie_io_desc[] __initdata = {
Nov 07 10:20:54 <ant_work> ?
Nov 07 10:20:55 <lumag_> Aliasing detection code relies on enabling/disabling qry and checking that other chips still show cry
Nov 07 10:20:59 <lumag_> *qry
Nov 07 10:21:19 <lumag_> but as you shortcuted that, chips always return 'qry' and thus alias detection fails.
Nov 07 10:21:40 <lumag_> I'm really not sure why did they have two 32Mb zones originally.
Nov 07 10:21:42 <ant_work> we only have 16MB, we know that
Nov 07 10:21:55 <lumag_> If you remember our discussion, we can limit that to one 16Mb zone
Nov 07 10:22:31 <ant_work> but how could it help the detection?
Nov 07 10:22:50 <lumag_> You won't see 'ghosts'
Nov 07 10:23:18 <ant_work> so jedec is more robust
Nov 07 10:23:36 <lumag_> jedec is robust because you did not shortcut that
Nov 07 10:23:41 <ant_work> heh
Nov 07 10:24:03 <lumag_> I'm really puzzled what happens with upper-word chip
Nov 07 10:25:41 <ant_work> lumag_: we are really near....
Nov 07 10:26:41 <ant_work> our blueligtning would probably take the return 0/1 hack for now ;)
Nov 07 10:28:43 <ant_work> somewhere I read that even if paired on a 32bit bus you have to talk to each chip with word = 16bit - > cfi_read_query16
Nov 07 10:29:14 <bluelightning> I'm fine with hacks if it works ;)
Nov 07 10:29:24 <lumag_> Hmm. Now with more details you can ask on linux-mtd
Nov 07 10:29:26 <bluelightning> I really appreciate all the work you guys have been doing lately
Nov 07 10:30:35 <ant_work> here we are getting to near to the hardware for my competence...
Nov 07 10:31:09 <ant_work> too
Nov 07 10:35:41 <ant_work> lumag_: I need a bit of luck and find dwmw2 on irc
Nov 07 10:36:05 <ant_work> then I can point him to the ML ;)
Nov 07 10:39:55 <lumag_> I have put my current work to https://github.com/lumag/linux/tree/sa1100
Nov 07 10:40:05 <lumag_> It is not perfect (yet)
Nov 07 10:41:42 <lumag_> and still no gpio/pin config handling
Nov 07 11:02:21 <ant_work> ok, I've sent a monster-msg to linux-mtd
Nov 07 11:02:33 <ant_work> now I'll try to lure someone...
Nov 07 11:05:29 <ant_work> lumag_
Nov 07 11:05:31 <ant_work> <ant_work> dwmw2: furthter findings wrt that Sharp NOR flash. I see now how it fails..don't know why ;)
Nov 07 11:05:31 <ant_work> <ant_work> dwmw2: Query Q: 510051 -> Answer Q: ffff0051
Nov 07 11:05:31 <ant_work> <dwmw2> because you haven't configured the bus correctly for 32-bit access yet?
Nov 07 11:05:42 <ant_work> it is hardwired isn't?
Nov 07 11:12:02 <lumag_> It is not hardwired
Nov 07 11:12:30 <lumag_> I also had this idea.
Nov 07 11:12:34 <ant_work> <ant_work> I see in the Service Man: ROMP capacity (x32 bus fixed) nCS0 -> 16MB  nCS1 -> Not Use, .
Nov 07 11:13:01 <lumag_> However I'm defeated because following reads from that flash read all 32 bits correctly
Nov 07 11:13:16 <ant_work> yes, is just the Q R Y
Nov 07 11:13:39 <lumag_> (subdev->map.bankwidth = (MSC0 & MSC_RBW) ? 2 : 4
Nov 07 11:14:05 <ant_work> <ant_work> dwmw2: I've put all details in my msg on the ML. Following reads are OK, is just the test failing. Thanks in advance.
Nov 07 11:14:05 <lumag_> I suggest to say that argument to dwmw2
Nov 07 11:14:32 <lumag_> More  important: data reads are ok
Nov 07 11:15:10 <ant_work> I've said it
Nov 07 11:18:59 <ant_work> lumag_: MSC0 & MSC_RBW .. could you pls translate? Are the values ok?
Nov 07 11:19:10 <lumag_> I don't know
Nov 07 11:19:26 <lumag_> But in fact it _reads_ bus width from hardware
Nov 07 11:19:30 <ant_work> #define MSC0            __REG(0xa0000010)  /* Static memory Control reg. 0 */
Nov 07 11:19:42 <ant_work> 1496 #define MSC_RBW         0x0004          /* ROM/static memory Bus Width     */
Nov 07 11:21:20 <ant_work> MSC & MSC_RBW is 0 here
Nov 07 11:21:24 <ant_work> false
Nov 07 11:21:45 <lumag_> no-no
Nov 07 11:21:56 <lumag_> MSC is reading from the register
Nov 07 11:22:08 <ant_work> err..
Nov 07 11:22:46 <lumag_> It might be that collie flash configures chip select for ROM instead of CFI mem, but I doubt that
Nov 07 11:26:20 <ant_work> there was that 'strange' gate-array
Nov 07 11:30:33 <lumag_> no, that is not an issue
Nov 07 11:30:35 <lumag_> I hope
Nov 07 11:39:40 <lumag_> The only problem can be if timings are incorrect
Nov 07 11:59:53 <ant_work> heh
Nov 07 11:59:54 <ant_work> <dwmw2> hm, timing?
Nov 07 11:59:55 <ant_work> <ant_work> data reads are ok
Nov 07 12:05:38 <lumag_> you can try adding some mdelay to cmd_send_gen_cmd
Nov 07 12:05:46 <lumag_> e.g. mdelay(10) after map_write()
Nov 07 12:05:53 <lumag_> and #include <linux/delay.h>
Nov 07 12:06:17 <lumag_> That would help if we are reading flash too fast (i.e. if it doesn't have time to change internal state).
Nov 07 12:06:36 <lumag_> I will think about reprogramming memory controller.
Nov 07 12:06:57 <lumag_> If you will be doing experiments, can you please do a register dump of MSC
Nov 07 12:07:17 <lumag_> I will send a patch in a moment
Nov 07 12:11:49 <ant_work> I've compared the values in CFI table wuth the appendix
Nov 07 12:11:58 <ant_work> mostly the same
Nov 07 12:12:41 <ant_work> one seems different  Maximum byte/word write timeout: 256 µs
Nov 07 12:14:06 <ant_work> no, I was wrong, are the same
Nov 07 12:14:14 <ant_work> just different order
Nov 07 12:15:01 <lumag_> http://pastebin.com/UqHW3hm1
Nov 07 12:15:41 <lumag_> Then I can check if it is programmed properly
Nov 07 12:15:48 <ant_work> I see
Nov 07 12:15:59 <ant_work> I'll do that in a couple of hours
Nov 07 12:16:20 * ant_work babysitting today...kid has 39 °C
Nov 07 12:16:37 <ant_work> call of duty (my wife...)
Nov 07 12:17:09 <lumag_> :(
Nov 07 12:21:07 <ant_work> he's asking me 'cause he badly want a pen to play with touchscreen.. I tried to say that his ipad is betetr but still he wants the pen ;)
Nov 07 12:21:29 <ant_work> he wants some snes/gameboy emulator on Z ;)
Nov 07 12:26:29 <lumag_> :)
Nov 07 12:26:46 <lumag_> I think there was snes for Z in opie
Nov 07 12:27:30 <lumag_> or you can buy a pen for capacitive touchscreen ;)
Nov 07 12:28:28 <ant_work> heh
Nov 07 12:28:48 <ant_work> there is a ZGRom distro
Nov 07 12:29:01 <ant_work> done by dromede for spitz. games only
Nov 07 12:30:02 <ant_work> in his hands spitz could last 2-3 days...
Nov 07 12:34:03 <lumag_> :)
Nov 07 12:36:02 <ant_work> he's now 6 and plays with iphone 3GS since he was 2 yrs old. That's a solid device ;)
Nov 07 12:48:42 <lumag_> My 2-years old daughter  killed eeepc 901
Nov 07 12:49:09 <lumag_> she liked it very much, but now it hangs all the times.
Nov 07 13:23:50 <ant_work> lumag_: table 15 Example of Query Structure Output
Nov 07 13:24:09 <ant_work> The partition address must be ...within the partition..
Nov 07 13:24:20 <ant_work> so maybe on the second chip?
Nov 07 13:25:34 <ant_work> cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
Nov 07 13:35:31 <lumag_> You can check what is selected...
Nov 07 13:36:10 <lumag_> gtg
Nov 07 18:20:14 <ant_home> lumag:
Nov 07 18:20:16 <ant_home> Register a0000000 value b464b465
Nov 07 18:20:16 <ant_home> Register a0000004 value aaaaaa9f
Nov 07 18:20:16 <ant_home> Register a0000008 value aaaaaaaa
Nov 07 18:20:16 <ant_home> Register a000000c value aaaaaaaa
Nov 07 18:20:16 <ant_home> Register a0000010 value fff8e352
Nov 07 18:20:17 <ant_home> Register a0000014 value fff12419
Nov 07 18:20:19 <ant_home> Register a0000018 value 994a2945
Nov 07 18:20:21 <ant_home> Register a000001c value 30300191
Nov 07 18:20:23 <ant_home> Sharp Scoop Device found at 0x40800000 -> 0xc4846000
Nov 07 20:06:36 <ant_home>  84         case SA1100_CS0_PHYS:
Nov 07 20:06:36 <ant_home>  85                 subdev->map.bankwidth = (MSC0 & MSC_RBW) ? 2 : 4;
Nov 07 20:07:35 <ant_home>  0xfff8e352 & 0x0004 = 0
Nov 07 20:07:46 <ant_home> bandwith = 4
Nov 07 20:07:49 <ant_home> 2^4  32
Nov 07 20:08:02 <ant_home> ;)
Nov 07 20:08:06 <ant_home> where is the issue?
Nov 07 20:08:23 <ant_home> seems 16 to me
Nov 07 20:10:40 <ant_home> jokes apart... MTD_MAP_BANK_WIDTH_4 is "Support 32-bit buswidth"
Nov 07 21:15:16 <lumag_> evening ant_home  Jay7
Nov 07 21:15:33 <ant_home> wb lumag_
Nov 07 21:28:24 <ant_home> lumag_: check the logs for registers dump
Nov 07 21:29:36 <lumag_> which one?
Nov 07 21:29:43 <lumag_> link...
Nov 07 21:29:46 <ant_home> channel log
Nov 07 21:30:10 <ant_home> http://logs.nslu2-linux.org/livelogs/kexecboot.txt
Nov 07 22:51:46 <ant_home> bluelightning: 5 patches coming
Nov 07 22:51:58 <ant_home> doing a build/run test right now
Nov 07 22:53:38 <ant_home> wipe the old collie ;)
Nov 07 22:54:43 <bluelightning> ant_home: ok :)
Nov 07 22:54:46 <bluelightning> cool
Nov 07 22:54:57 <ant_home> lumag_: any other debug after that?
Nov 07 22:55:48 <ant_home> bluelightning: it sorts out the issue could not be the framebuffer but the lcd/backlight...
Nov 07 22:57:41 <ant_home> bluelightning: is there an open bug about the override reordering? CAn layer priority influence?
Nov 07 22:58:20 <ant_home> RP is strangely silent but this is serious breakage imho
Nov 07 22:58:49 <ant_home> at least say, heads up: fix your layer so and so
Nov 07 22:59:02 <ant_home> I hate silent changes....
Nov 07 22:59:42 <ant_home> there are minimum 3-4 fixes to do for the initramfs-pollution (update-rc, etc..) ;)
Nov 07 23:00:29 <ant_home> our poor layers are exposed to all changes: perfect targets for testing :p
Nov 07 23:02:56 <lumag_> ant_home, no, I'm mostly out of ideas.
Nov 07 23:04:28 <ant_home> lumag_: the registers of LCD maybe?
Nov 07 23:04:44 <ant_home> for the other issue...
Nov 07 23:20:26 <lumag_> for the fl/bl.
Nov 07 23:20:47 <lumag_> I'm not yet ready for that issue, sorry.
Nov 07 23:21:33 <lumag_> ant_home, regarding memory, we can try lowering timing requirements.
Nov 07 23:23:01 <ant_home> I've seen in mach/SA-1100.h there are the timings
Nov 07 23:23:04 <lumag_> On next test run, can you please add "MSC0 = 0xfff8fff8". or "MSC0 = 0xfff8fffa;" after that printing loop.
Nov 07 23:23:55 <lumag_> This would add maximum delay and (the first one) remove all read/write optimizations.
Nov 07 23:27:49 <ant_home> ok
Nov 07 23:28:05 <ant_home> now, I was booting  http://pastebin.com/6az0Z3EB
Nov 07 23:28:21 <ant_home> I've resized to SZ_16M
Nov 07 23:28:57 <ant_home> now seems better: sa1100-0: 1 set(s) of 2 interleaved chips --> 1 partitions of 16384 KiB
Nov 07 23:29:28 <ant_home> unfortunately on this boot was locked again...
Nov 07 23:31:09 <lumag_> :(
Nov 07 23:31:11 <ant_home> btw, I think we have to add the mtd3 /ex mtd5 on top and mark it RO
Nov 07 23:31:29 <lumag_> Maybe it fails to exit from qry mode somewhere?
Nov 07 23:31:50 <ant_home> now, I have removed many of the further checks yesterday
Nov 07 23:31:54 <ant_home> exactly
Nov 07 23:32:17 <ant_home> I'll retry with just the first 2
Nov 07 23:32:36 <ant_home> the 0xF0 and the 0xFF
Nov 07 23:32:53 <ant_home> fwiw F= is not documented as reset on Intel
Nov 07 23:33:02 <lumag_> The most important response from card that I would like to see in logs is the 'Q' readings - val[0].x[0]
Nov 07 23:33:02 <ant_home> F0 seems AMD, FF Intel
Nov 07 23:34:45 <ant_home> lumag_: heh, flash_unlock was instantaneous ;)
Nov 07 23:35:27 <ant_home> the chips are much better detected now
Nov 07 23:35:30 <lumag_> Ah, I misunderstood you.
Nov 07 23:35:35 <ant_home> no
Nov 07 23:35:41 <ant_home> on boot was locked :/
Nov 07 23:35:43 <lumag_> I thought that the whole boot locked. not the rw/
Nov 07 23:35:52 <lumag_> like hanged
Nov 07 23:35:57 <ant_home> I've unlocked from shell
Nov 07 23:36:02 <ant_home> w/o hangs
Nov 07 23:36:16 <lumag_> Do you have the strataflash-like fixup?
Nov 07 23:36:18 <ant_home> much quicker than before: instantaneous
Nov 07 23:36:22 <ant_home> no
Nov 07 23:36:32 <ant_home> this flash is much better
Nov 07 23:36:51 <ant_home> it is the instant locking
Nov 07 23:37:00 <ant_home> that 32 feature
Nov 07 23:37:32 <ant_home> before, with jedec, was driven with standard single eraseblock-unlock
Nov 07 23:37:52 <lumag_> ah :)
Nov 07 23:38:00 <lumag_> fixup might help with boot-lock problem.
Nov 07 23:38:10 <lumag_> But it is up to you to interpret your results ;)
Nov 07 23:38:11 <ant_home> well, in theory is not needed ...
Nov 07 23:38:43 <ant_home> this RO on boot was present by: adding CFI debug, adding OTP
Nov 07 23:38:56 <ant_home> now I have OTP but yesterday was ok
Nov 07 23:39:25 <lumag_> Some internal magic/side effect maybe
Nov 07 23:39:28 <ant_home> yesterday I did remove the other probe for QRY after the 'old Intel'
Nov 07 23:39:38 <ant_home> I'll retry this
Nov 07 23:40:13 * lumag_ is still thinking about simple-but-effective-temporary-pinctrl-replacement
Nov 07 23:40:21 <ant_home> or maybe it is because I've resized the flash to 16MB
Nov 07 23:40:49 <lumag_> experimental physics law: turn only one knob at a time.
Nov 07 23:40:56 <ant_home> yea
Nov 07 23:41:12 <ant_home> (I have the patched file of yesterday ;)
Nov 07 23:42:49 <lumag_> I have another problem - I'm trying to design few support functions (to control GAFR & PPC) that can be easily removed when we switch to device tree ;)
Nov 07 23:44:54 <ant_home> sorry for bothering you so much on collie...
Nov 07 23:57:23 <ant_home> lumag_: pure fun.. on 3rd reboot is RW, after the unlock on the second one
Nov 07 23:57:31 <ant_home> same kernel, same image
Nov 07 23:57:50 <ant_home> I'll pull battery out now
Nov 07 23:58:01 <lumag_> ant_home, n/p
Nov 07 23:58:25 <lumag_> remote debugging is a funny thing. Never tried that  before ;)
Nov 07 23:59:12 <ant_home> this can really be some timing
Nov 08 00:02:55 <ant_home> seems if you flash_unlock and reboot, on next boot stays RW
Nov 08 00:03:10 <ant_home> on first cold-boot seems always failing...
Nov 08 00:12:31 <lumag_> ant_home, no. it just means that it is not being properly unlocked by the kernel.
Nov 08 00:14:20 <lumag_> Hmm.
Nov 08 00:14:32 <lumag_> mtd core calls mtd_unlock on add_mtd_device
Nov 08 00:14:33 <ant_home> I'l ladd unlock for sharp, let see
Nov 08 00:14:59 <ant_home> anyway, resizing to 16M does not make differences
Nov 08 00:15:02 <lumag_> if it is writeable and power locked
Nov 08 00:15:08 <lumag_>         if ((mtd->flags & MTD_WRITEABLE) && (mtd->flags & MTD_POWERUP_LOCK)) {
Nov 08 00:15:20 <lumag_> I'd really suggest strataflash fixup
Nov 08 00:15:28 <lumag_> or some other kind of it
Nov 08 00:15:38 <ant_home> ok
Nov 08 00:15:53 <ant_home> strange, though, there must be some 'global lock'
Nov 08 00:16:03 <lumag_> note, it should be CFI_MFR_SHARP, 0xb0.
Nov 08 00:16:10 <lumag_> not 0xb1 as I  wrote initially
Nov 08 00:16:17 <ant_home> sure, I put ANY
Nov 08 00:16:19 <ant_home> ;)
Nov 08 00:16:20 <lumag_> *or just any for debug purpose
Nov 08 00:16:22 <lumag_> :)
Nov 08 00:17:31 <lumag_> I think we have to tell to mtd layer that flash is locked.
Nov 08 00:17:58 <lumag_> IANAME - (I am not an MTD expert) though
Nov 08 00:42:33 <lumag_> gn
**** ENDING LOGGING AT Fri Nov 08 02:59:58 2013