**** BEGIN LOGGING AT Tue Dec 10 02:59:58 2013
Dec 10 09:55:46 <ant_work> lumag: so it appears the key problem might be the presence of two logical partitions -> two status registers.
Dec 10 09:56:15 <ant_work> I'l ltry to flatten all to a single partition, disabling thus the dual work "simultaneous operations"
Dec 10 10:13:18 <lumag> ant_work, Does the mtd code touch second mtd partition?
Dec 10 10:13:30 <lumag> I thought as it is on the higher addresses, it is not touched.
Dec 10 10:15:56 <ant_work> why not? planes are exactly 1/4 of the size (64M)
Dec 10 10:16:14 <ant_work> so one part of mtd2 and mtd3 do reside on that 4th plane
Dec 10 10:16:51 <lumag> Ah.
Dec 10 10:16:58 <lumag> And each plane has it's own status reg?
Dec 10 10:17:12 <ant_work> possibly, but on boot are fused
Dec 10 10:17:27 <ant_work> boot and reset, 0-2 = 1st partition, 4 = 2nd p.
Dec 10 10:17:41 <ant_work> err.. 4th = plane 3
Dec 10 10:18:09 <ant_work> anyhow we can set one single p. setting the PCR to 000
Dec 10 10:18:49 <ant_work> don't know how much performance we loose, I think the idea was to split code and data on embedded systems
Dec 10 10:19:14 <ant_work> not much of use on a 'pda'
Dec 10 11:03:54 <lumag> I think last partition (with small pages) is used to store bootstrap data
Dec 10 11:04:01 <lumag> like comadj & ko
Dec 10 11:04:13 <lumag> I don't remember flash map.
Dec 10 11:04:25 <lumag> Do we use several 'small pages' for main mtd partition?
Dec 10 11:04:40 <lumag> If so it might be simpler to just shrink it.
Dec 10 11:04:46 <lumag> How much space would we loose?
Dec 10 11:54:52 <ant_work> lumag: yes, we could shrink the mtd to a total size of 3x4MB = 12MB
Dec 10 11:55:09 <ant_work> we'd loose 4MB - 128Kb
Dec 10 11:56:03 <lumag> I see :(
Dec 10 11:56:47 <lumag> We can change last-page partitioning, but this can interfere with firmware handling parameters
Dec 10 11:57:29 <lumag> Should not the mtd code contain handling for multiple erase regions (is that the case)?
Dec 10 11:57:45 <lumag> Or the problem is that those erase regions have different status regs?
Dec 10 11:57:57 <ant_work> regions ! = partitions
Dec 10 11:58:33 <ant_work> last 'plane' on the chip represent a partition and inside has two disctinct eraseregions
Dec 10 11:58:42 <ant_work> with different erasesize
Dec 10 11:59:14 <ant_work> Eight 4K-word Parameter Blocks
Dec 10 11:59:15 <ant_work> • One-hundred and twenty-seven 32K-word Main
Dec 10 11:59:15 <ant_work> Blocks
Dec 10 12:00:25 <ant_work> so the plane 3 has 31 32K-word blocks + 8 4K-word blocks
Dec 10 12:00:51 <ant_work> the first 3 planes have only 32K-word blocks, uniform
Dec 10 12:01:27 <ant_work> actually this 'simultaneous operation' dual work consists in:
Dec 10 12:01:30 <ant_work> • Read operations during Block Erase or (Page Buffer)
Dec 10 12:01:31 <ant_work> Program
Dec 10 12:01:31 <ant_work> • Status Register
Dec 10 12:04:06 <ant_work> afais the chip is awaken exactly in the state described by the tech sheet: all sectors locked, 2 partitions, 2 status registers
Dec 10 12:05:13 <ant_work> note that 2 simultaneous read operations on fifferent partitions are NOT allowed
Dec 10 12:08:08 <lumag> Do we have those 4K blocks in our rootfs mtd?
Dec 10 12:08:32 <ant_work> yes, the topmost blocks
Dec 10 12:08:39 <ant_work> mtd3
Dec 10 12:09:13 <ant_work> used only on boot to read comafj at al. ?
Dec 10 12:12:44 <ant_work> lumag: well, not in the rootfs, we skip the top 128Kbytes
Dec 10 12:13:00 <ant_work> we never flash it
Dec 10 12:13:05 <lumag> ok
Dec 10 12:13:39 <lumag> So second status reg belongs to the top 8x4K blocks, or to the whole 4M 'area'
Dec 10 12:13:39 <lumag> ?
Dec 10 12:14:10 <ant_work> to the 4M area/plane
Dec 10 12:14:57 <ant_work> Plane 3 180000H-1FFFFFH 300000H-3FFFFFH
Dec 10 12:15:20 <ant_work> ^^                          32M             64M
Dec 10 12:15:34 <lumag> :(
Dec 10 12:16:16 <ant_work> we can repartition (it seems..). atm I've only read the PCR
Dec 10 12:23:42 <lumag> ant_work, I have skimmed through the datasheet.
Dec 10 12:24:01 <lumag> Let's try reprogramming PCRC. It looks like it is not in OTP, so it should be safe.
Dec 10 12:24:52 <lumag> I don't get, why do they have partitions from the start.
Dec 10 12:25:08 <lumag> Is it to be able to read from one partition, while writing to the other one?
Dec 10 12:25:28 <ant_work> yes
Dec 10 12:25:35 <ant_work> the hype is 'dual work'
Dec 10 12:25:41 <lumag> ok, got it now.
Dec 10 12:25:48 <lumag> Let's try with pcrc
Dec 10 12:28:53 <ant_work> in CFI table this is indicated as 'simultaneous operations'
Dec 10 12:33:49 <ant_work> lumag: heh, finally I hope I've read PCRC correctly...
Dec 10 12:41:33 <lumag> ant_work, gtg now,
Dec 10 12:41:39 <lumag> bye
Dec 10 12:42:27 <ant_work> cu later
Dec 10 12:42:32 <ant_work> thx for the patience ;)
Dec 10 17:38:34 <ant_home> lumag: it seems 'reboot' doesn't reset PCR
Dec 10 17:38:53 <ant_home> after flashing:  Partition Configuration Register was:400
Dec 10 17:38:53 <ant_home> Status Register is:8080
Dec 10 17:38:53 <ant_home> Partition Configuration Register is now:0
Dec 10 17:39:07 <ant_home> now, after reboot it is 0 on first read
Dec 10 17:43:46 <ant_home> lumag:...for the moment all is fine...
Dec 10 17:45:12 <ant_home> jffs2 boots cleanly
Dec 10 17:47:11 <ant_home> now I'll add the patch for UBI and try that
Dec 10 17:52:09 <ant_home> btw, flashcpy can now flash the full 14336K image
Dec 10 17:52:28 <ant_home> just too good to be true ...;)
Dec 10 18:02:36 <ant_home> lumag: http://pastebin.com/YSjdyLxt
Dec 10 18:02:52 <ant_home> this hack should be converted in a proper fixup...
Dec 10 18:07:30 <ant_home> lumag: doh... poweroff now dos really power off collie..
Dec 10 18:10:20 <ant_home> well, not on every boot...
Dec 10 19:50:43 <ant_home> :/
Dec 10 19:50:48 <ant_home> on second reboot
Dec 10 19:50:50 <ant_home> jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x007f3890: Read 0xbb45a49b, calculated 0xbec39fda
Dec 10 19:51:05 <ant_home> or third..
Dec 10 22:00:05 <ant_home> finally ubifs (need couple of patches)
Dec 10 22:00:06 <ant_home> root@collie:~# ubimkvol /dev/ubi0 -N rootfs -m
Dec 10 22:00:06 <ant_home> Set volume size to 14272896
Dec 10 22:00:07 <ant_home> Volume ID 0, size 109 LEBs (14272896 bytes, 13.6 MiB), LEB size 130944 bytes (127.9 KiB), dynamic, name "rootfs", alignment 1
Dec 10 22:00:07 <ant_home> root@collie:~# ubiupdatevol -t /dev/ubi0_0
Dec 10 22:00:07 <ant_home> root@collie:~# mount -t ubifs ubi0:rootfs /mnt/.psplash/
Dec 10 22:00:09 <ant_home> UBIFS: default file-system created
Dec 10 22:00:11 <ant_home> UBIFS: background thread "ubifs_bgt0_0" started, PID 277
Dec 10 22:00:13 <ant_home> UBIFS: mounted UBI device 0, volume 0, name "rootfs"
Dec 10 22:00:15 <ant_home> UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit sizes: 8 bytes/64 bytes
Dec 10 22:00:17 <ant_home> UBIFS: FS size: 12963456 bytes (12 MiB, 99 LEBs), journal size 1047553 bytes (0 MiB, 6 LEBs)
Dec 10 22:00:19 <ant_home> UBIFS: reserved for root: 612295 bytes (597 KiB)
Dec 10 22:00:21 <ant_home> UBIFS: media format: w4/r0 (latest is w4/r0), UUID 3E19D1AF-7EA6-4D4B-990A-32400E568D8D, small LPT model
Dec 10 22:00:23 <ant_home> root@collie:~#
Dec 10 22:15:42 <ant_home> but after reboot...UBIFS: recovery needed
Dec 10 22:15:54 <ant_home> seems we still need one patch
Dec 10 22:51:46 <ant_home> like here
Dec 10 22:51:48 <ant_home> http://lxr.free-electrons.com/source/drivers/mtd/chips/cfi_cmdset_0002.c#L469
Dec 10 22:51:57 <ant_home> cfi_udelay(500);
Dec 10 22:53:12 <ant_home> (see datasheet..but funny, also for intel strataflash like on h3600 which apparently works flawlessy)
**** ENDING LOGGING AT Wed Dec 11 02:59:59 2013