| Message ID | 4E784790.4010601@denx.de |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 2011-09-20 at 09:58 +0200, Heiko Schocher wrote: > Hello, > > I tried to use mtd-util:flash_erase on a davinci am1808 based board, > and get the following error: > > flash_erase -j /dev/mtd5 0 0 > flash_erase: error!: /dev/mtd5: unable to get NAND oobinfo > error 22 (Invalid argument) What is your kernel version?
Hello Artem, Artem Bityutskiy wrote: > On Tue, 2011-09-20 at 09:58 +0200, Heiko Schocher wrote: >> Hello, >> >> I tried to use mtd-util:flash_erase on a davinci am1808 based board, >> and get the following error: >> >> flash_erase -j /dev/mtd5 0 0 >> flash_erase: error!: /dev/mtd5: unable to get NAND oobinfo >> error 22 (Invalid argument) > > What is your kernel version? Hups, sorry forgot to post this: Linux version 3.1.0-rc4-00086-gb0f6609 (hs@pollux.denx.de) (gcc version 4.5.1 (GCC) ) #1 PREEMPT Mon Sep 19 10:15:32 CEST 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: EnBW CMC, model: EnBW CMC Memory policy: ECC disabled, Data cache writethrough DaVinci da850/omap-l138/am18x variant 0x1 [...] physmap platform flash device: 02000000 at 60000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002249 Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.3. number of CFI chips: 1 4 cmdlinepart partitions found on MTD device physmap-flash.0 Creating 4 MTD partitions on "physmap-flash.0": 0x000000000000-0x000000080000 : "U-Boot" 0x000000080000-0x000000090000 : "env1" 0x000000090000-0x0000000a0000 : "env2" 0x0000000a0000-0x000000200000 : "rest" NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit) 4 cmdlinepart partitions found on MTD device davinci_nand.1 Creating 4 MTD partitions on "davinci_nand.1": 0x000000000000-0x000000020000 : "dtb" 0x000000020000-0x000000220000 : "kernel" 0x000000220000-0x000000620000 : "rootfs" 0x000000620000-0x000008000000 : "userfs" davinci_nand davinci_nand.1: controller rev. 2.5 bye, Heiko
On Tue, 2011-09-20 at 09:58 +0200, Heiko Schocher wrote: > Now the questions: > > a) is this fix Ok? (Has it i chance to go in mainline?) No, it breaks ABI. > b) in include/mtd/mtd-abi.h I found this comment: > > /* > * Obsolete legacy interface. Keep it in order not to break userspace > * interfaces > */ > struct nand_oobinfo { > > so this Interface should not be used ... which Interface should be > used instead? You are lucky because Brian already took care of this. You need to use his MEMWRITE ioctl. Try my l2 tree (or take patches from that tree) plus the "brian" branch of the mtd-utils tree. The idea is that the new ioctl should get to mainline soon, and we'll merge the brian branch into the master branch in mtd-utils. My tree: http://git.infradead.org/users/dedekind/l2-mtd-2.6.git (you can use it or pick patches from there) MTD utils tree: http://git.infradead.org/users/dedekind/mtd-utils.git (use the "brian" branch) Of course we are interested to know if it worked for you. Brian is in CC.
On Tue, 2011-09-20 at 14:27 +0300, Artem Bityutskiy wrote: > MTD utils tree: http://git.infradead.org/users/dedekind/mtd-utils.git > (use the "brian" branch) Sorry, this is the right link: http://git.infradead.org/mtd-utils.git
Hello Artem, Artem Bityutskiy wrote: > On Tue, 2011-09-20 at 14:27 +0300, Artem Bityutskiy wrote: >> MTD utils tree: http://git.infradead.org/users/dedekind/mtd-utils.git >> (use the "brian" branch) > > Sorry, this is the right link: > http://git.infradead.org/mtd-utils.git Thanks! Actually I was writing an EMail, that I could not found the brian branch ;-) I try it ... bye, Heiko
Hello Artem, Artem Bityutskiy wrote: > On Tue, 2011-09-20 at 14:27 +0300, Artem Bityutskiy wrote: >> MTD utils tree: http://git.infradead.org/users/dedekind/mtd-utils.git >> (use the "brian" branch) > > Sorry, this is the right link: > http://git.infradead.org/mtd-utils.git with this tree and the brian branch I get: root@armv5te:/home/hs/bmk/mtd-utils# ./flash_erase -j /dev/mtd7 0 0 flash_erase: error!: /dev/mtd7: unable to get NAND oobinfo error 22 (Invalid argument) root@armv5te:/home/hs/bmk/mtd-utils# :-( As I see in mtd-util:flash_erase.c line 197: if (ioctl(fd, MEMGETOOBSEL, &oobinfo) != 0) ^^^^^^^^^^^^ this is the "old" style ... which fails ... bye, Heiko
Add Liu Shuo, who was interested in similar problems with `flash_erase -j'. On Tue, Sep 20, 2011 at 6:27 AM, Heiko Schocher <hs@denx.de> wrote: > Artem Bityutskiy wrote: >> Sorry, this is the right link: >> http://git.infradead.org/mtd-utils.git > > with this tree and the brian branch I get: > > root@armv5te:/home/hs/bmk/mtd-utils# ./flash_erase -j /dev/mtd7 0 0 > flash_erase: error!: /dev/mtd7: unable to get NAND oobinfo > error 22 (Invalid argument) > root@armv5te:/home/hs/bmk/mtd-utils# > > :-( > > As I see in mtd-util:flash_erase.c line 197: > > if (ioctl(fd, MEMGETOOBSEL, &oobinfo) != 0) > ^^^^^^^^^^^^ > this is the "old" style ... which fails ... Right, I haven't fixed all uses of MEMGETOOBSEL yet, and I definitely didn't touch flash_erase yet, although the mechanisms are available now. I have provided ioctl(MEMWRITE) which, in addition to simply writing data, has information about write mode that should replace MEMGETOOBSEL. Particularly, you would be interested in MTD_OPS_AUTO_OOB, which should be the only autoplacement routine necessary. The `brian' branch that Artem mentions provides support in libmtd for using the MEMWRITE ioctl, but nandwrite is the only utility that uses it properly right now. So the next step is for you (Heiko, Liu, or somebody else that wants `flash_erase -j') to replace: `ioctl(MEMGETOOBSEL)' plus `mtd_write_oob()' with `mtd_write()' using mode `MTD_OPS_AUTO_OOB' I think it shouldn't be too difficult, but I do not have testing for JFFS2. I recommend trying to cut out all the manual layout stuff from flash_erase.c and instead making sure that `legacy_auto_oob_layout()' has up-to-date support for old layout methods (i.e., MEMGETOOBSEL), then for forward progress, you only need to make sure that the in-kernel MTD_OPS_AUTO_OOB works as desired. No more duplication of "auto" layouts in nandwrite, flash_erase, and in-kernel; just in-kernel handling of "auto" mode and legacy libmtd functions for supporting the old way. Let me know if you have questions about my MEMWRITE changes. I would be happy to clarify if needed. Brian
Hello Brian, Brian Norris wrote: > Add Liu Shuo, who was interested in similar problems with `flash_erase -j'. > > On Tue, Sep 20, 2011 at 6:27 AM, Heiko Schocher <hs@denx.de> wrote: >> Artem Bityutskiy wrote: >>> Sorry, this is the right link: >>> http://git.infradead.org/mtd-utils.git >> with this tree and the brian branch I get: >> >> root@armv5te:/home/hs/bmk/mtd-utils# ./flash_erase -j /dev/mtd7 0 0 >> flash_erase: error!: /dev/mtd7: unable to get NAND oobinfo >> error 22 (Invalid argument) >> root@armv5te:/home/hs/bmk/mtd-utils# >> >> :-( >> >> As I see in mtd-util:flash_erase.c line 197: >> >> if (ioctl(fd, MEMGETOOBSEL, &oobinfo) != 0) >> ^^^^^^^^^^^^ >> this is the "old" style ... which fails ... > > Right, I haven't fixed all uses of MEMGETOOBSEL yet, and I definitely > didn't touch flash_erase yet, although the mechanisms are available > now. > > I have provided ioctl(MEMWRITE) which, in addition to simply writing > data, has information about write mode that should replace > MEMGETOOBSEL. Particularly, you would be interested in > MTD_OPS_AUTO_OOB, which should be the only autoplacement routine > necessary. The `brian' branch that Artem mentions provides support in > libmtd for using the MEMWRITE ioctl, but nandwrite is the only utility > that uses it properly right now. > > So the next step is for you (Heiko, Liu, or somebody else that wants > `flash_erase -j') to replace: > > `ioctl(MEMGETOOBSEL)' plus `mtd_write_oob()' > > with > > `mtd_write()' using mode `MTD_OPS_AUTO_OOB' Thanks for your explanation! I have to look in this deeper. > I think it shouldn't be too difficult, but I do not have testing for > JFFS2. I recommend trying to cut out all the manual layout stuff from > flash_erase.c and instead making sure that `legacy_auto_oob_layout()' > has up-to-date support for old layout methods (i.e., MEMGETOOBSEL), > then for forward progress, you only need to make sure that the > in-kernel MTD_OPS_AUTO_OOB works as desired. No more duplication of > "auto" layouts in nandwrite, flash_erase, and in-kernel; just > in-kernel handling of "auto" mode and legacy libmtd functions for > supporting the old way. > > Let me know if you have questions about my MEMWRITE changes. I would > be happy to clarify if needed. Thanks! bye, Heiko
diff --git a/include/mtd/mtd-abi.h b/include/mtd/mtd-abi.h index a86364a..5dc6ed1 100644 --- a/include/mtd/mtd-abi.h +++ b/include/mtd/mtd-abi.h @@ -136,7 +136,7 @@ struct nand_oobinfo { __u32 useecc; __u32 eccbytes; __u32 oobfree[8][2]; - __u32 eccpos[32]; + __u32 eccpos[40]; }; struct nand_oobfree {
Hello, I tried to use mtd-util:flash_erase on a davinci am1808 based board, and get the following error: flash_erase -j /dev/mtd5 0 0 flash_erase: error!: /dev/mtd5: unable to get NAND oobinfo error 22 (Invalid argument) The problem is here: drivers/mtd/mtdchar.c line 786: if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos)) return -EINVAL; On such a plattform we have: mtd->ecclayout->eccbytes = 40 ARRAY_SIZE(oi.eccpos) = 32 following patch solves the issue: Now the questions: a) is this fix Ok? (Has it i chance to go in mainline?) b) in include/mtd/mtd-abi.h I found this comment: /* * Obsolete legacy interface. Keep it in order not to break userspace * interfaces */ struct nand_oobinfo { so this Interface should not be used ... which Interface should be used instead? Thanks! bye, Heiko