NWR04B: My descent into little-endian binary arithmetic hell

Currently writing this entry in emacs. Once upon a time, I stopped using emacs for fear of what loading a 20MB editor would do to the mail server I was working on, and learned to love vi. Prompted by ESR's Art of Unix Programming, I've decided to try pick up emacs again. It's interesting....Anyhow: Right now I'm trying to figure out why the hell writing to flash on the NWR04B is not working. First off, I've edited the map file for the flash devices (drivers/mtd/maps/cx84200-flash.c for those of you playing the home game) so that I've got two partitions declared:

static struct mtd_partition cx84200_partitions[] = {
        {
                name:           "bootloader",
                size:           0x00020000,
                offset:         0x00000000,
                mask_flags:     MTD_WRITEABLE, /* force read-only */
        }, {
                name:           "root_fs",
                // Codeman's original:
                // size:        0x000fa000,
                // My efforts at making a root partition:
                size:           0x00040000,
                offset:         0x000f0000,
}

The first I'm not really doing anything with, but it could (as the title suggests) be turned into a bootloader partition someday. The second is where I'm concentrating my efforts. The read-only flag that was originally in there was removed once I figured out it might help matters. :-) Okay, so now what? Well, got a jffs2 image that I created, so let's try the obvious:

# cat test.jffs2 > /dev/mtd1

...and it just hangs. (I still haven't bothered to figure out how to make CTRL-C interrupt a process yet...something to do with the terminal, I think.) Up the debugging output and you see MTD_open, and then nothing. I had a look at the part of the driver (drivers/mtd/chips/sst39vf080.c) to see what's going on here, and I managed to figure it out a bit. The write operation tries to write one byte at a time, then reads it back to make sure it got read. If so, move on to the next byte; if not, try 256 more times (I guess waiting to see if it just needs a moment) and see if that works. If yes, next byte; if not, give up on the write entirely. I threw in some messages to track that, and one that shows what value it's reading back from flash after the write. After throwing in ridiculous amounts of debugging info to track this, it seems that the write of the first byte is simply not working. The write fails, and cat just keeps on trying (or something). A bunch of looking around finally turned up the MTD-JFFS-HOWTO from (I think) the guy who wrote the MTD driver. 'S full of all sorts of helpful hints, like:

• you can do cp test.jffs2 /dev/mtd1 to copy stuff to flash (but I got the same result as with cat),
• you can mount an erased block device, then just copy files to it w/o formatting it (mount /dev/mtdblock1 /mnt && cp foo /mnt), and
• you need to erase a flash partition if it has anything on it before just blindly copying files over.

Well, fuck. So I follow the directions for the 2.4 kernel support, and figure out how to compile the flash_eraseall utility. Wonderful! Ready to go! Just gotta erase this here partition, and... Only no, that doesn't work: I get the same error re: the byte not being written as before. I'm currently throwing in even more unholy amounts of debugging than before, and teaching myself the simplest bits of binary arithmetic you can image, in order to confirm that, yes, write protection is being turned off...I think. This little-endian thing still confuses the hell out of me. The datasheet sez that, at the address the enable_write() operation is accessing, there are 32 bits set aside for controlling the first bank of flash (which is what we're after here). The 26th bit is write-protect (1 for on, 0 for off). enable_write() reads all 32 bits at that address, &'s it with 0x04000000, and then WP should be off. So the unholy debugging shows that the long int being read:

• before turning off write-protect: 0x1400ffef
• what it wants to write to turn off WP: 0x1000ffef
• what it reads back after, checking how it went: 0x1000ffef

Okay, so that works. Maybe I'll give the flashcp utility (part of the MTD tree) a try and see how that goes.