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