**** BEGIN LOGGING AT Thu May 28 02:59:58 2015
May 28 14:53:06 <lumag> hello ant_work bluelightning
May 28 14:54:01 <ant_work> hello lumag
May 28 15:53:33 <ant_work> slowly progressing with the mtdparts
May 28 15:54:09 <ant_work> I have reordered the ideas about changes 2.4 -> 2.6 -> 3.x
May 28 15:54:32 <ant_work> lot was lost with 2.6
May 28 15:57:55 <ant_work> btw, these older nand chip had only the first (erase)block guaranteed (16Kb on older pxa, 128Kb for SL-C3100/3200)guaranteed
May 28 15:58:43 <ant_work> after that the second block could be remapped thus need logical addressing
May 28 16:12:37 <ant_work> what I have to understand now is whether the drivers/mtd/nand/sharpsl.c is only good for mtd2 and mtd3
May 28 16:26:16 <ant_work> lumag: btw, I hope this has been resolved by n ow
May 28 16:26:19 <ant_work> "a 128MB flash chip can exceeds the amount of memory kmalloc can allocate"
May 28 16:27:06 <lumag> no. One should not kmalloc such big areas.
May 28 16:27:26 <lumag> Why do you need it anyway? (If you really want to kmalloc 128Mb)
May 28 16:27:28 <ant_work> #if defined (CONFIG_ARCH_PXA_AKITA) || defined (CONFIG_ARCH_PXA_BORZOI)
May 28 16:27:28 <ant_work> 	oobs = consistent_alloc(GFP_KERNEL, mtd->oobsize * page_num + mtd->erasesize,&oobs_phys );
May 28 16:27:28 <ant_work> #else
May 28 16:27:28 <ant_work> 	oobs = kmalloc(mtd->oobsize * page_num + mtd->erasesize, GFP_KERNEL);
May 28 16:27:28 <ant_work> #endif
May 28 16:28:08 <ant_work> sharp_sl_logical.c
May 28 16:29:25 <lumag> This should now be handled by the mtd core, isn't it?
May 28 16:29:36 <lumag> At least up to some point.
May 28 16:29:48 <ant_work> I have seen references that 'it was fixed in  mtd'
May 28 16:29:57 <lumag> At least akita.c provides oob info to the core.
May 28 16:30:09 <lumag> s/akita.c/spitz.c/
May 28 16:30:53 <ant_work> btw: see the original sin
May 28 16:30:55 <ant_work> http://infobot.rikers.org/%23oe/20050418.html.gz
May 28 16:31:03 <ant_work> 16:42.56	RP	The sl_logical stuff can be ignored for now (we don't use that under 2.6)
May 28 16:31:05 <ant_work> ^^
May 28 16:31:24 <ant_work> ?_?
May 28 16:34:28 <lumag> I'd assume (assume!) that sl_logical was a wear+bb level used by sharp because there was no jffs2 or it wasn't usable, or whatever.
May 28 16:35:31 <lumag> There is little point reimplementing that part -- ubi and jffs2 do their own work on oob/wear-level/etc.
May 28 16:35:53 <lumag> So we should just read the partitioning info.
May 28 16:36:27 <lumag> I'm not sure if there is anything else important/interesting there.
May 28 16:36:43 <ant_work> th epoint is we are after block[0]
May 28 16:37:04 <ant_work> block[1] could be not at the phys address we read
May 28 16:37:24 <ant_work> (very bad luck,whatever)
May 28 16:38:07 <lumag> Do you mean that they have partitioning info implemented with 'logical' addersses instead of physical ones
May 28 16:38:42 <ant_work> whay then add thi s header...
May 28 16:38:44 <lumag> Or that the partitions can be non-contiguous
May 28 16:38:49 <ant_work> both
May 28 16:39:04 <lumag> :(
May 28 16:39:06 <ant_work> we should see the bootloader sources to understand
May 28 16:39:22 <ant_work> you remember it copies atags at the wrong / deprecated address
May 28 16:39:36 <lumag> Yep.
May 28 16:39:46 <ant_work> and the other LCD Phase etc
May 28 16:40:17 <ant_work> so it reads different blocks, and the first blocks are used for Mainte
May 28 16:40:23 <ant_work> http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm
May 28 16:41:48 <lumag> Well. We have sharpsl_params for the phase, etc.
May 28 16:41:54 <ant_work> with akita/spitz the 0x060000 addr would be after 2 mainte + 1 8 param blocks
May 28 16:41:56 <lumag> They are filled by the bootloader into the mem.
May 28 16:42:23 <ant_work> yes, it does have idea of logical mapping? is it guaranteed first blocks are good
May 28 16:42:24 <ant_work> ?
May 28 16:43:53 <ant_work> with akita/spitz with 128Kb erasesize the 0x060000 addr would be after 2 mainte + 1 param  blocks
May 28 16:44:08 <ant_work> ^ much further for poodle/corgi
May 28 16:44:56 <ant_work> after 16 mainte + 8 param 16kb blocks
May 28 16:45:47 <ant_work> nor was much better, just much more expensive...
May 28 16:47:05 <ant_work> lumag: the bootloader does also pass the atag cmdline but iirc this memory range is overwritten early on boot
May 28 16:47:21 * lumag is reading updater.sh
May 28 16:49:44 <ant_work> qemu did add the arm_oldparams at one point
May 28 16:49:46 <ant_work> https://lists.nongnu.org/archive/html/qemu-devel/2007-07/msg00344.html
May 28 16:50:49 <lumag> IIUC only kernel is written using 'logical' mapping
May 28 16:51:12 <lumag> rootfs and home are written directly
May 28 16:52:01 <lumag> Hmm. bootloaders is also written using nandlogical
May 28 16:52:12 <ant_work> here the disasssembly of part of bootloader
May 28 16:52:13 <ant_work> http://www.oesf.org/forum/lofiversion/index.php/t3361.html
May 28 16:52:57 <ant_work> yes, it seems only first 7MB mtd is using this FTL
May 28 16:59:09 <ant_work> well, reading the pdf of wjhat should be the nand
May 28 16:59:11 <ant_work> Toshiba TH58512FT
May 28 16:59:17 <ant_work> http://icwic.com/icwic/data/pdf/cd/cd018/a/115653.pdf
May 28 16:59:42 <ant_work> they say: guaranteed good blocks: min 4016 max 4096
May 28 16:59:58 <ant_work> at the tim eof shipment...
May 28 17:00:40 <lumag> Yep.
May 28 17:00:52 <lumag> There will some badblocks on the nand
May 28 17:09:41 <ant_work> to avoid all this possible problems we could try to catch the copy of cmdline in ram
May 28 17:10:01 <ant_work> but afair the address seems to vary between models
May 28 17:10:21 <ant_work> maybe when we read COMADJ and stuff
May 28 17:11:20 <ant_work> but I fear it was passed on some specific address so it gets lost when R2 is overwritten...coinfused here
May 28 17:16:57 <ant_work> bbl
May 28 21:15:16 <lumag> ant_home,
May 28 21:15:18 <lumag> hexdump -C /dev/mtd1 | grep -C 3 FSRO
May 28 21:15:18 <lumag> 000287f0  5f bb ff eb 41 0f 8f e2  5d bb ff eb 05 0c 85 e2  |_...A...].......|
May 28 21:15:18 <lumag> 00028800  5b bb ff eb 06 0f 8f e2  59 bb ff eb 41 dc 8d e2  |[.......Y...A...|
May 28 21:15:18 <lumag> 00028810  f0 80 bd e8 6d 61 69 6e  6c 69 6e 75 78 70 61 72  |....mainlinuxpar|
May 28 21:15:18 <lumag> 00028820  61 6d 3d 00 0a 00 00 00  46 53 52 4f 00 00 00 00  |am=.....FSRO....|
May 28 21:15:20 <lumag> 00028830  72 6f 5f 73 69 7a 65 3d  00 00 00 00 63 6f 6e 73  |ro_size=....cons|
May 28 21:15:22 <lumag> 00028840  6f 6c 65 3d 74 74 79 53  30 20 72 6f 6f 74 3d 2f  |ole=ttyS0 root=/|
May 28 21:15:24 <lumag> 00028850  64 65 76 2f 6d 74 64 62  6c 6f 63 6b 32 00 00 00  |dev/mtdblock2...|
May 28 21:15:26 <lumag> --
May 28 21:15:28 <lumag> 00070dd0  98 52 00 eb 00 00 50 e3  01 00 00 1a 04 00 a0 e1  |.R....P.........|
May 28 21:15:30 <lumag> 00070de0  70 80 bd e8 10 40 84 e2  10 60 86 e2 01 09 56 e3  |p....@...`....V.|
May 28 21:15:32 <lumag> 00070df0  f3 ff ff ba 00 00 a0 e3  70 80 bd e8 42 4f 4f 54  |........p...BOOT|
May 28 21:15:34 <lumag> 00070e00  00 00 00 00 46 53 52 4f  00 00 00 00 46 53 52 57  |....FSRO....FSRW|
May 28 21:15:36 <lumag> 00070e10  00 00 00 00 f0 4f 2d e9  41 dc 4d e2 01 00 a0 e3  |.....O-.A.M.....|
May 28 21:15:40 <lumag> 00070e20  ff 76 ff eb 00 80 a0 e1  00 00 a0 e3 fc 76 ff eb  |.v...........v..|
May 28 21:15:42 <lumag> 00070e30  00 70 a0 e1 02 00 a0 e3  f9 76 ff eb 00 a0 a0 e1  |.p.......v......|
May 28 21:15:44 <lumag> --
May 28 21:15:46 <lumag> 006416b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 21:15:48 <lumag> *
May 28 21:15:50 <lumag> 00664000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 21:15:52 <lumag> 00664010  00 00 70 00 00 00 d0 01  46 53 52 4f 00 00 00 00  |..p.....FSRO....|
May 28 21:15:54 <lumag> 00664020  00 00 d0 01 00 00 00 04  46 53 52 57 00 00 00 00  |........FSRW....|
May 28 21:15:56 <lumag> 00664030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 21:15:58 <lumag> *
May 28 21:16:00 <lumag> 00668000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 21:16:02 <lumag> 00668010  00 00 70 00 00 00 d0 01  46 53 52 4f 00 00 00 00  |..p.....FSRO....|
May 28 21:16:04 <lumag> 00668020  00 00 d0 01 00 00 00 04  46 53 52 57 00 00 00 00  |........FSRW....|
May 28 21:16:06 <lumag> 00668030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 21:16:10 <lumag> *
May 28 21:16:12 <lumag> dev:    size   erasesize  name
May 28 21:16:14 <lumag> mtd0: 006e0000 00800000 "Boot PROM Filesystem"
May 28 21:16:16 <lumag> mtd1: 00700000 00004000 "System Area"
May 28 21:16:18 <lumag> mtd2: 01600000 00004000 "Root Filesystem"
May 28 21:16:20 <lumag> mtd3
May 28 21:17:22 <ant_home> hi
May 28 21:18:20 <ant_home> first one seems the copy in Mainte used by the partitioner by sashz
May 28 21:18:40 <ant_home> iirc is at different offset each model
May 28 21:23:09 <lumag> I've booted into 2.4 rescue kernel and dumped mtd1 there.
May 28 21:23:15 <lumag> I got the same picture.
May 28 21:24:22 <ant_home> then mtd must be mapped to 0x064000 on pxa or smthg like that...
May 28 21:25:12 <ant_home> but if you read the logical address you refer to base=00
May 28 21:28:25 <lumag> git dropped some while ago
May 28 21:28:57 <lumag> I tried to read that data on c860, but got mtd error and then empty dump.
May 28 21:29:48 <ant_home> I have here 3 dumps taken from collie at 60004 and are like yours
May 28 21:29:53 <ant_home> er.. from poodle
May 28 21:32:55 <lumag> damn. rescue kernel on c860 also gives EIO
May 28 21:34:00 <ant_home> try with nandlogical pls
May 28 21:35:31 <ant_home> iirc you need to patch the kernel loader in diag for the models with 128kb nand
May 28 21:36:43 <lumag> ant_home, I booted 2.4 kernel
May 28 21:39:48 <lumag> # nandlogical /dev/mtd1 READP 0x60000 48 /tmp/test
May 28 21:39:48 <lumag> Dumping data starting at 0x00060000 and ending at 0x00060030...
May 28 21:39:48 <lumag> Dumping 60000 - 60030
May 28 21:39:48 <lumag> # cat /tmp/test
May 28 21:39:48 <lumag> 0x00060000: 0x00 0x00 0x00 0x00 0x00 0x00 0x70 0x00 0x42 0x4f 0x4f 0x54 0x00 0x00 0x00 0x00
May 28 21:39:49 <lumag> 0x00060010: 0x00 0x00 0x70 0x00 0x00 0x00 0xd0 0x01 0x46 0x53 0x52 0x4f 0x00 0x00 0x00 0x00
May 28 21:39:51 <lumag> 0x00060020: 0x00 0x00 0xd0 0x01 0x00 0x00 0x00 0x04 0x46 0x53 0x52 0x57 0x00 0x00 0x00 0x00
May 28 21:39:53 <lumag> true
May 28 21:40:43 <lumag> My tosa has to charge up before being able to boot
May 28 21:42:07 <ant_home> same addresses are used by the partitioner tool (pdaxrom)
May 28 21:42:32 <ant_home> fsro_resize.c
May 28 21:42:54 <ant_home> (in survive-1.1.0 as nandlogical)
May 28 21:44:06 <lumag> Hmm.
May 28 21:44:25 <lumag> On c860 I'm able to read the flash via nandlogical
May 28 21:44:27 <lumag> # nandlogical /dev/mtd1 READP 0x60000 48 /tmp/test
May 28 21:44:27 <lumag> Dumping data starting at 0x00060000 and ending at 0x00060030...
May 28 21:44:27 <lumag> Dumping 60000 - 60030
May 28 21:44:27 <lumag> # cat /tmp/test
May 28 21:44:27 <lumag> 0x00060000: 0x00 0x00 0x00 0x00 0x00 0x00 0x70 0x00 0x42 0x4f 0x4f 0x54 0x00 0x00 0x00 0x00
May 28 21:44:28 <lumag> 0x00060010: 0x00 0x00 0x70 0x00 0x00 0x00 0xc0 0x03 0x46 0x53 0x52 0x4f 0x00 0x00 0x00 0x00
May 28 21:44:30 <lumag> 0x00060020: 0x00 0x00 0xc0 0x03 0x00 0x00 0x00 0x04 0x46 0x53 0x52 0x57 0x00 0x00 0x00 0x00
May 28 21:44:52 <ant_home> 0x03c000 seemscorrect
May 28 21:46:19 <lumag> # cat /proc/mtd
May 28 21:46:19 <lumag> dev:    size   erasesize  name
May 28 21:46:19 <lumag> mtd0: 006d0000 00020000 "Filesystem"
May 28 21:46:19 <lumag> mtd1: 00700000 00004000 "smf"
May 28 21:46:19 <lumag> mtd2: 03500000 00004000 "root"
May 28 21:46:20 <lumag> mtd3: 04400000 00004000 "home"
May 28 21:46:28 <lumag> 35+7 = 3c
May 28 21:47:10 <ant_home> yes, we have the offsets there
May 28 21:47:45 <lumag> Well. We need just two pages of flash, so you should be able to simplify scan_logical for the kernel. Just look for those two offsets.
May 28 21:50:39 <lumag> Hmm.
May 28 21:51:32 <lumag> This is a dump of c860 captured with offset 256 * 4096 = 0x100000
May 28 21:51:43 <lumag> hexdump -C /media/lumag/7987-F90D/test.bin  | grep -C 3 FSRO
May 28 21:51:44 <lumag> *
May 28 21:51:44 <lumag> 00563ff0  53 48 41 52 50 21 31 2e  34 30 00 00 00 00 60 04  |SHARP!1.40....`.|
May 28 21:51:44 <lumag> 00564000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 21:51:44 <lumag> 00564010  00 00 70 00 00 00 c0 03  46 53 52 4f 00 00 00 00  |..p.....FSRO....|
May 28 21:51:44 <lumag> 00564020  00 00 c0 03 00 00 00 04  46 53 52 57 00 00 00 00  |........FSRW....|
May 28 21:51:46 <lumag> 00564030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 21:51:48 <lumag> *
May 28 21:51:50 <lumag> 00568000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 21:51:52 <lumag> 00568010  00 00 70 00 00 00 c0 03  46 53 52 4f 00 00 00 00  |..p.....FSRO....|
May 28 21:51:54 <lumag> 00568020  00 00 c0 03 00 00 00 04  46 53 52 57 00 00 00 00  |........FSRW....|
May 28 21:51:56 <lumag> 00568030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 21:51:58 <lumag> *
May 28 21:52:00 <lumag> So the same offset
May 28 21:54:51 <lumag> ok, now booting tosa 2.4
May 28 21:57:01 <lumag> logical address is the same
May 28 21:57:50 <lumag> again i/o err
May 28 21:58:08 <ant_home> can you try with nanddump?
May 28 21:59:57 <ant_home> heh, I'm reading the old 2.4 mtd/nand_ecc.c and there is a Lineo change...
May 28 22:00:15 <lumag> no nanddump on 2.4 rescue :(
May 28 22:00:22 <ant_home> ah...
May 28 22:01:36 <ant_home> nand_ids.c back then was also patched
May 28 22:01:50 <ant_home> to add akita at the time
May 28 22:02:40 <ant_home> there has been similar rework as for NOR, where the generic CFI works with almost any chip
May 28 22:03:45 <lumag> ok. on tosa I got different offsets.
May 28 22:04:14 <lumag> *
May 28 22:04:14 <lumag> 00067ff0  53 48 41 52 50 21 31 2e  31 32 20 45 00 00 b3 36  |SHARP!1.12 E...6|
May 28 22:04:14 <lumag> 00068000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 22:04:14 <lumag> 00068010  00 00 70 00 00 00 30 02  46 53 52 4f 00 00 00 00  |..p...0.FSRO....|
May 28 22:04:14 <lumag> 00068020  00 00 30 02 00 00 00 04  46 53 52 57 00 00 00 00  |..0.....FSRW....|
May 28 22:04:15 <lumag> 00068030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 22:04:17 <lumag> *
May 28 22:04:19 <lumag> 0006c000  00 00 00 00 00 00 70 00  42 4f 4f 54 00 00 00 00  |......p.BOOT....|
May 28 22:04:21 <lumag> 0006c010  00 00 70 00 00 00 30 02  46 53 52 4f 00 00 00 00  |..p...0.FSRO....|
May 28 22:04:23 <lumag> 0006c020  00 00 30 02 00 00 00 04  46 53 52 57 00 00 00 00  |..0.....FSRW....|
May 28 22:04:25 <lumag> 0006c030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
May 28 22:04:27 <lumag> *
May 28 22:04:29 <lumag> That is minus 600000
May 28 22:04:39 <lumag> So it's not possible to just read at that offset.
May 28 22:04:55 <ant_home> only with nandlogical
May 28 22:05:21 <lumag> Yep.
May 28 22:05:51 <ant_home> possibly the string was put after the kernel in mainte so for each device the addr is different
May 28 22:06:18 <ant_home> or some perverse coder...
May 28 22:06:34 <lumag> SHARP! .. is just a trailer of the previous kernel I assume.
May 28 22:07:54 <ant_home> on poodle I have SHARP!1.00 E at 0x064004 + BFF0
May 28 22:08:19 <lumag> So in kernel i'd suggest to do a scan for fixed offsets (0x60000), instead of doing full logical -> phys map, as is done by kexecboot.
May 28 22:08:58 <ant_home> so no need to fill the complete structures?
May 28 22:12:22 <ant_home> referring to afs or redboot, both checks for a MAGIC
May 28 22:13:06 <ant_home> well, it seems this parameter area has one
May 28 22:13:51 <ant_home> /
May 28 22:13:51 <ant_home> typedef struct NAND_PARTITION_INFO {
May 28 22:13:51 <ant_home> 	unsigned long startadr;
May 28 22:13:51 <ant_home> 	unsigned long endadr;
May 28 22:13:51 <ant_home> 	unsigned char magic[4];
May 28 22:13:51 <ant_home> 	unsigned long reserve;
May 28 22:13:53 <ant_home> } NAND_PARTITI
May 28 22:14:26 <ant_home> fun is, the struc is not used in 2.4...
May 28 22:14:48 <ant_home> maybe only in the maintenance kernel
**** ENDING LOGGING AT Fri May 29 02:59:59 2015