mtd/utils: sync with MTD ioctl interface rework to get rid of MEMGETOOBSEL/MEMSETOOBSEL

+++ util/nanddump.c 2 Dec 2005 06:54:11 -0000

nanddump.c +1 -0

@@ -163,6 +163,7 @@
 	struct mtd_oob_buf oob = {0, 16, oobbuf};
 	mtd_info_t meminfo;
 	char pretty_buf[80];
+	uint32_t oobavail;
 
  	process_options(argc, argv);
 

Hi Vitaly, my comments...

Quoted 10 lines

+++ util/nanddump.c 2 Dec 2005 06:54:11 -0000

nanddump.c +1 -0

@@ -163,6 +163,7 @@
     struct mtd_oob_buf oob = {0, 16, oobbuf};
     mtd_info_t meminfo;
     char pretty_buf[80];
+    uint32_t oobavail;
 
      process_options(argc, argv);
 

nanddump.c line 187

Quoted 8 lines

nanddump.c +5 -0

@@ -179,6 +180,13 @@
         exit (1);
     }
 
+    if (ioctl(fd, MEMGETOOBAVAIL, &oobavail) != 0) {
+        perror("unable to get NAND oobavail");
+        close(fd);
+        exit(1);
+    }

How about fall back to all 16/64/etc. avail?

For debugging purposes it can be nice to see the raw OOB, in case that can be shoehorned in here somehow.

Quoted 8 lines

(quoted diff) +1 -1

+++ util/nandwrite.c    2 Dec 2005 06:54:11 -0000
 
 
-           "  -j, --jffs2           force jffs2 oob layout (legacy 

support)\n"
- " -y, --yaffs force yaffs oob layout (legacy
support)\n"

Again, it may be good to keep a legacy mode around during the transition period.

Quoted 6 lines

         if (writeoob) {
             /* Read OOB data from input file, exit on failure */

- if ((cnt = read(ifd, oobreadbuf, meminfo.oobsize)) !=
meminfo.oobsize) {
+ if ((cnt = read(ifd, oobreadbuf, oobavail)) != oobavail) {

This requires the input file to be tailored to the oobavail of a specific destination device, reducing the benefit of autoplacement. It may be best to continue to pad input files oob data to the full oobsize, much like the data portion is handled.

Quoted 2 lines

+ memcpy(oobbuf, oobreadbuf, oobavail);

No need for oobreadbuf and copy if no OOB layout processing done anymore?

Todd Poynor wrote:

Quoted 8 lines

Quoted 5 lines

         if (writeoob) {
             /* Read OOB data from input file, exit on failure */

- if ((cnt = read(ifd, oobreadbuf, meminfo.oobsize)) !=
meminfo.oobsize) {
+ if ((cnt = read(ifd, oobreadbuf, oobavail)) != oobavail) {

This requires the input file to be tailored to the oobavail of a specific destination device, reducing the benefit of autoplacement. It may be best to continue to pad input files oob data to the full oobsize, much like the data portion is handled.

Well, padding doesn't work in nandwrite if the image to be written contains OOB data. The idea as I see it is if you are trying to write the image with OOB data, you should know what you're doing, and that implies knowledge of the oobavail size. On the other hand, it might be useful to implement an option for nandwrite which specifies what OOB data length user supposes (default will be the oobavail).

Quoted 8 lines

Well, padding doesn't work in nandwrite if the image to be written contains OOB data. The idea as I see it is if you are trying to write the image with OOB data, you should know what you're doing, and that implies knowledge of the oobavail size.
On the other hand, it might be useful to implement an option for nandwrite which specifies what OOB data length user supposes (default will be the oobavail).

In order to make it work as above, we'd need a way for users to find out what oobavail their mtd driver uses (in dmesg and/or a util)

, and an
option on all the fs utils to write that number of bytes. A file format that specifies what data and OOB size have been generated would do the trick, if we want to get that fancy about it. Just filling out all 16 or 64 bytes in the input file and truncating to oobavail at nandwrite time seems a lower-cost workaround.

Hi,
this patch reorganizes the MTD utls to
- not use MEMGETOOBSEL/MEMSETOOBSEL ioctls as they're planned for removal and anyway not needed
- use MEMGETOOBAVAIL ioctl to get the number of available OOB bytes and read/write OOB accordingly

Any input is most welcome.

Quoted 7 lines · Vitaly Wool

Hi,
this patch reorganizes the MTD utls to
- not use MEMGETOOBSEL/MEMSETOOBSEL ioctls as they're planned for removal and anyway not needed
- use MEMGETOOBAVAIL ioctl to get the number of available OOB bytes and read/write OOB accordingly

Quoted 3 lines

Any input is most welcome.

1. Rendering the utils unusable for older kernels is wrong.

Its simple to handle this in the utils depending on the functionality which is exposed by the kernel.

2. Your current approach prevents me to
- dump the raw flash content including OOB data
- write a nand image with given oob data

This is essential for troubleshooting and must still be possible somehow.

Quoted 7 lines

2. Your current approach prevents me to
- dump the raw flash content including OOB data
- write a nand image with given oob data

This is essential for troubleshooting and must still be possible somehow.

Lemme disagree with you here. Raw OOB content-related stuff is not IMHO the thing to debug from userland.
Suggest prinitng out the raw OOB contents for MTD_DEBUG_LEVEL3 instead.