**** BEGIN LOGGING AT Wed Dec 11 02:59:59 2013
Dec 11 08:28:33 <ant_work> lumag: gm
Dec 11 08:29:17 <ant_work> WIP https://github.com/andrea-adami/meta-handheld/commits/master
Dec 11 08:31:36 <ant_work> (the PCR hack needs to be moved elsewhere)
Dec 11 08:33:34 <ant_work> now, can it be that sa1100/collie doesn't flush the chips before reboot/poweroff?
Dec 11 08:34:05 <ant_work> this could explain the bad CRC of jffs2
Dec 11 12:51:23 <ant_work> bluelightning: er.. the collie params for UBI where thought for NAND...then I discovered it has NOR onboard...
Dec 11 12:51:40 <ant_work> this is apatch independent on the kernel, pls commit it when possible
Dec 11 12:51:53 <ant_work> https://github.com/andrea-adami/meta-handheld/commit/f480d87056919cb6aa08b840ed6479bb53eefec8
Dec 11 12:51:58 <ant_work> thx
Dec 11 12:59:36 <lumag> ant_work,hello.
Dec 11 13:00:02 <lumag> I'd suggest to move it to quirks (like strataflash, etc).
Dec 11 13:00:12 <lumag> If that is not too late.
Dec 11 13:02:30 <lumag> Also we would probably need to overwrite the restart callback to also reset the flash.
Dec 11 13:02:41 <lumag> So that it comes back as multiple-partition device.
Dec 11 13:03:01 <ant_work> yes, so maybe it even answers QRY
Dec 11 13:03:40 <lumag> Quircks are done after QRY, aren't they?
Dec 11 13:03:53 <ant_work> btw we can remove strataflash-fix
Dec 11 13:03:58 <ant_work> won't help
Dec 11 13:03:59 <lumag> CFI aplies fixups depending on vendor id/device id,
Dec 11 13:04:06 <lumag> ant_work, ok :)
Dec 11 13:04:20 <ant_work> last test of last night ;)
Dec 11 13:05:11 <ant_work> lumag: where would you add  http://lxr.free-electrons.com/source/drivers/mtd/chips/cfi_cmdset_0002.c#L492
Dec 11 13:05:24 <ant_work> we surely need 0,5sec here
Dec 11 13:05:42 <lumag> To put_chip ;)
Dec 11 13:05:49 <lumag> As it's done in cmdset_0002
Dec 11 13:05:51 <ant_work> I think this is the cause of my issues after reboot. this or no-flush/sync
Dec 11 13:06:34 <lumag> Maybe we need to forcely reset the flash just before restart
Dec 11 13:07:11 <lumag> BTW: I have sent few patches tonight - IrDA and gpio keys.
Dec 11 13:07:27 <lumag> Could you please check & ack them :)
Dec 11 13:08:15 <ant_work> sure
Dec 11 13:09:02 <lumag> thx
Dec 11 13:09:39 <ant_work> btw, irda client/server can be tested from Diag Mode menus ;)
Dec 11 13:09:44 <ant_work> from another Z
Dec 11 13:10:00 <lumag> Haojian has finally sent the PR with tosa keyboard patch.
Dec 11 13:10:12 <lumag> 3.14 will have correct keymap.
Dec 11 13:10:27 <ant_work> that took long...
Dec 11 13:10:33 <lumag> Yep
Dec 11 13:11:01 <lumag> SA1100 patches take even longer. RMK is completely busy and unresponsive.
Dec 11 13:11:04 <ant_work> hm.. can it refer to reset/sync?   http://lists.infradead.org/pipermail/linux-mtd/2013-May/046765.html
Dec 11 13:11:55 <lumag> The patch is ok.
Dec 11 13:12:05 <lumag> Maybe we need to update sa1100_destroy.
Dec 11 13:12:07 <lumag> Let me check
Dec 11 13:16:43 <lumag> Hmm.
Dec 11 13:16:47 <lumag> There is some handling there.
Dec 11 13:17:01 <lumag> Check the cfi_intelext_destroy, cfi_intelext_reset, etc.
Dec 11 13:17:11 <lumag> We might want to expand that reset/restore_locks/etc. handling.
Dec 11 13:17:19 <lumag> This is cmdset_0001
Dec 11 13:18:02 <ant_work> or maybe collie/sa1100 cuts the VPP before the write/erase is finished ?
Dec 11 13:18:50 <ant_work> I remember to have logged a map_read and map_write on reboot
Dec 11 13:19:05 <lumag> Strange.
Dec 11 13:19:13 <lumag> Intelext has support for multiple partition devices.
Dec 11 13:19:29 <lumag> Can you also try MTD_CONCAT=y and your fixup disabled?
Dec 11 13:19:48 <lumag> See the cfi_intelext_partition_fixup
Dec 11 13:20:01 <lumag> "this function has the potential to distort the reality"!
Dec 11 13:21:02 <lumag> I like your fixup though.
Dec 11 13:22:09 <lumag> I'd suggest to check what happens in the end of cfi_intelext_destroy - read the PCR and then reset it again with 0xff (or is it 0xf0?) command
Dec 11 13:22:38 <lumag> Maybe our fine chip needs other reset sequence (0xff vs. 0xf0) or it might need some additional steps to have PRCR back to normal one.
Dec 11 13:23:57 <ant_work> 0xF0 is only for AMD
Dec 11 13:24:09 <ant_work> but it is to return to Read Array
Dec 11 13:24:49 <lumag> Yes.
Dec 11 13:24:52 <ant_work> and finally most info seem ignored
Dec 11 13:24:54 <ant_work> http://lxr.free-electrons.com/source/include/linux/mtd/cfi.h#L172
Dec 11 13:25:04 <ant_work> FIXME
Dec 11 13:25:04 <lumag> After leaving Linux, flash should be in read mode.
Dec 11 13:25:39 <lumag> Do we hit that fixme?
Dec 11 13:26:08 <lumag> I like eBay. Some are selling collies for just $19, some for $199
Dec 11 13:27:12 <ant_work> the partition stuff is not shown in the CFI table I see on collie
Dec 11 13:27:21 <ant_work> just the eraseregions
Dec 11 13:29:04 <lumag> Maybe it is skipped somehow.
Dec 11 13:29:09 <lumag> I will check.
Dec 11 13:30:21 <ant_work> fwiw Intel Extended Table is at 31H, Sharp is at 39H
Dec 11 13:31:02 <ant_work> as indicated in offset 15H
Dec 11 13:33:58 <ant_work> anyway, what I'm not understanding is, the erase is on on especific block and this block belongs to a specific plane so has its SR
Dec 11 13:34:32 <ant_work> hoiw is it that it answers ready while in truth it is busy?
Dec 11 13:34:55 <ant_work> maybe the code is passing an address on the next block/plane
Dec 11 13:35:26 <ant_work> normnal Intel flash don't care about addrerss but for Sharp must be *within partition*
Dec 11 13:35:30 <lumag> It looks like it should allocate additional mtd chips with changed base addresses
Dec 11 13:35:57 <lumag> If it gets too complicated, let's live with a single partition and forget about all the crap.
Dec 11 13:36:10 <ant_work> o_O
Dec 11 13:36:24 <lumag> If we can sort out the reset/halt problem
Dec 11 13:37:04 <ant_work> finally, it would be nice to see how the CFI-flasher in mtd0 copies the image. maybe we can log it on terminal
Dec 11 13:37:43 <ant_work> but again, sequentially block by block should not be a problem
Dec 11 13:38:02 <ant_work> simultaneous operations is the problem
Dec 11 13:38:39 <ant_work> here I get lost with mutexes and friends;) up to you
Dec 11 13:39:02 <ant_work> but yes, reset/poweroff is b0rked on collie
Dec 11 13:47:38 <ant_work> lumag: one final note (for now): table 22.1 of the appendix says that in case of single partition bit 9 (Simultaneous operations) are not supported
Dec 11 13:48:01 <lumag> simultaneous operations?
Dec 11 13:48:04 <ant_work> so this shouldn't ever show in the CFI answer/table after the PCR is set to 0
Dec 11 13:48:11 <lumag> What is that?
Dec 11 13:48:28 <ant_work> read one part while erasing other. there is a matrix of ops
Dec 11 13:49:17 <ant_work> it is about that bit 31 set
Dec 11 13:49:17 <lumag> Ah, it is unsupported as there are no other parts ;)
Dec 11 13:49:35 <lumag> So we can completely forget about that.
Dec 11 13:49:37 <ant_work> yes, they strangely talk about 44-lead SOP
Dec 11 13:50:28 <ant_work> we could otherwise mask/unset that bit9...
Dec 11 13:55:24 <ant_work> heh..but i.e. 51H (partition information) is not updated even changing PCR. Let's hope 3EH (Features) is updated
Dec 11 15:00:26 <lumag> ant_work,                 /*
Dec 11 15:00:26 <lumag>                  * All functions below currently rely on all chips having
Dec 11 15:00:26 <lumag>                  * the same geometry so we'll just assume that all hardware
Dec 11 15:00:26 <lumag>                  * partitions are of the same size too.
Dec 11 15:00:26 <lumag>                  */
Dec 11 15:00:39 <lumag> That is probably the case.
Dec 11 15:00:55 <lumag> *not* the case
Dec 11 15:01:59 <lumag> according to datasheet 3fh is updated
Dec 11 15:09:53 <lumag> Hmm.
Dec 11 15:09:56 <lumag> numregions = -
Dec 11 15:09:58 <lumag> numregions = 0
Dec 11 15:10:01 <lumag> numparts = 1
Dec 11 15:10:05 <lumag> Strange.
Dec 11 15:10:10 <lumag> That is w/o your fixup
Dec 11 15:12:07 <lumag> ant_work, I don't see bit31 enabled in FeaturesSupported.
Dec 11 15:12:13 <lumag> So FIXME does not apply to us
Dec 11 15:16:24 <lumag> fe224668dff97dd8899bd559d1608cc9285db67b
Dec 11 15:16:30 <lumag> Thomas was looking there
Dec 11 15:23:57 <ant_work> I remember that patch
Dec 11 15:25:10 <ant_work> same geometry = we could even dare to test 4 partitions
Dec 11 15:25:28 <ant_work> as last hope ;)
Dec 11 15:33:29 <lumag> ant_work, Do we have the up-to-date Intel/Ext PRI description somewhere?
Dec 11 15:33:53 <lumag> I found one of the issues - kernel looks for partitioning data in wrong location.
Dec 11 15:34:44 <ant_work> doh
Dec 11 15:37:18 <ant_work> lumag..googling for the PRI desc I found this thread...exactly our situation...
Dec 11 15:37:21 <ant_work> http://osdir.com/ml/linux.drivers.mtd/2001-11/msg00086.html
Dec 11 15:37:27 <ant_work> 2001 !
Dec 11 15:39:48 <lumag> ***
Dec 11 15:39:53 <lumag> They (sharp) got it wrong.
Dec 11 15:41:02 <lumag> *0x4d is 0, but then follow 3 syncro configs (= 0x0)
Dec 11 15:45:06 <ant_work> afaik this chip (and the strataflash as well) cannot do syncronous/burst read
Dec 11 15:53:16 <lumag> Yes, but for this chip cfi  PRI has 3 slots (for that).
Dec 11 15:55:23 <lumag> I'll try a quick hack
Dec 11 15:57:16 <lumag> OK. I got cfi code to read the 'partitioning'.
Dec 11 15:57:39 <lumag> However then we fall into the problem of a comment I posted ~hour ago.
Dec 11 15:57:40 <lumag> See:
Dec 11 15:57:52 <lumag> sa1100-0: 1 set(s) of 2 interleaved chips --> 2 partitions of 8192 KiB
Dec 11 15:58:16 <lumag> It goes for two equal chips
Dec 11 15:58:20 <lumag> (subchips)
Dec 11 15:58:28 <lumag> I'll be back in a hour (or so).
Dec 11 15:58:52 <lumag> It looks like we have to modify partitioning no matter what (or to change cfi code significantly).
Dec 11 15:59:02 <lumag> I'd propose to just switch to single-partitioning mode.
Dec 11 16:00:32 <ant_work> change PCR are just two lines + eventual status checks ;)
Dec 11 16:00:33 <ant_work> +1
Dec 11 16:14:42 <ant_work> btw this coukd explain the verify failure we observed with flashcpy at 10490K + (1792 mtd0 + mtd1) = 12292  we are in the 4 plane
Dec 11 16:14:44 <ant_work> bbl
Dec 11 23:18:01 <ant_home> lumag: testing  http://pastebin.com/u07P0XEw
Dec 11 23:19:07 <lumag> ant_home, +partitioning fix?
Dec 11 23:19:31 <ant_home> yes, and -strataflash fix
Dec 11 23:20:27 <ant_home> this driver is ugly :/
Dec 11 23:20:36 <ant_home> 75Kb
Dec 11 23:20:46 <ant_home> I'm not used ;)
Dec 11 23:21:31 <ant_home> is like a patchwork made of hacks
Dec 11 23:21:50 <ant_home> sad life for the e-engineers ;)
Dec 11 23:23:07 <lumag> You see. We have a spec. Plenty of them. CFI 1.0, 1.1, .. 1.4
Dec 11 23:23:17 <lumag> And then we have plenty of engineers to read them.
Dec 11 23:23:27 <lumag> Each one has it own reading ;)
Dec 11 23:24:55 <ant_home> he he, no unemployement
Dec 11 23:24:56 <lumag> Kind of
Dec 11 23:24:56 <lumag> And so each hardware vendor has 'it own' flash
Dec 11 23:24:56 <ant_home> tragic if you have a deadline
Dec 11 23:25:48 <ant_home> it would be too funnt if Sharp failed to implement its own chips on a Sharp-branded consumer device ...
Dec 11 23:25:54 <ant_home> some head
Dec 11 23:26:05 <ant_home> cut
Dec 11 23:26:26 <ant_home> shipped as read-only...hmm..
Dec 11 23:27:16 <ant_home> ok, built, flashing now
Dec 11 23:32:00 <ant_home> why does kexec take so long on collie...can we do it XIP maybe?
Dec 11 23:36:06 <ant_home> lumag: seems it doesn't help
Dec 11 23:36:08 <ant_home> http://pastebin.com/hXrX8hvt
Dec 11 23:36:24 <ant_home> no reboot btw, just umount/remount
Dec 11 23:37:27 <lumag> Hmm.
Dec 11 23:40:28 <ant_home> afair this is new: UBIFS: reserved for root: 0 bytes (0 KiB)
Dec 11 23:41:45 <ant_home> I try now with empty volume like tested yesterday
Dec 11 23:44:59 <ant_home> lumag: not yet rebooted
Dec 11 23:45:00 <ant_home> http://pastebin.com/HFRsvuWz
Dec 11 23:45:45 <lumag> So first mount works, second does not :(
Dec 11 23:45:57 <ant_home> yes
Dec 11 23:45:58 <lumag> Slight suggestion:
Dec 11 23:47:05 <lumag> could you add MSC0 = (MSC0 & 0xffff0000) | 0xfff8 to collie_init somewhere before adding mtd?
Dec 11 23:55:43 <ant_home> before platform_add_devices?
Dec 11 23:55:46 <lumag> Yep
Dec 11 23:56:17 <lumag> This is to relax flash timings and to disable all bursts
Dec 12 00:11:33 <ant_home> ok, cold boot
Dec 12 00:14:39 <ant_home> :/ same
Dec 12 00:14:44 <ant_home> UBIFS error (pid 441): check_lpt_type: invalid type (15) in LPT node type 2
Dec 12 00:15:13 <ant_home> I'll try quicly jffs2 then I'll have to go
Dec 12 00:19:54 <ant_home> well, it survives to mount-remount
Dec 12 00:20:29 <ant_home> now booting from it
Dec 12 00:24:46 <ant_home> http://pastebin.com/4u6KHzNX
Dec 12 00:25:19 <ant_home> clean at first...
Dec 12 00:25:30 <ant_home> then issues after reboot
Dec 12 00:30:48 <ant_home> anyway, I've booted 4-5 times from mtd and it is not corrupted
Dec 12 00:30:56 <ant_home> booted = kexecbooted
Dec 12 00:31:58 <ant_home> ah, finally
Dec 12 00:31:59 <ant_home> root@collie:~# jffs2: Error garbage collecting node at 00769e88!
Dec 12 00:33:57 <ant_home> jffs2 finallt gave up  http://pastebin.com/BxSdY8FS
Dec 12 00:34:15 <ant_home> lumag: have to go, will be back friday night
Dec 12 00:34:23 <ant_home> thx for the support
Dec 12 00:34:26 <ant_home> gn
Dec 12 00:34:26 <lumag> :(
Dec 12 00:34:27 <lumag> gn
**** ENDING LOGGING AT Thu Dec 12 02:59:59 2013