Anyway I have done a backup of the same CUSTOM.BIN, here is the file: http://www.mediafire.com/download/qad3j … BACKUP.BIN
So when I compare that to 906cebfc82efc881ea16f0f3501ba82b, it's almost identical except for six places. In every one of them, you have 0xffff where I have something else. (At least this tells you it's roughly flashing the correct file! Also, maybe yours takes less time than mine because /nodma slows my flashing down.) Possibilities:
there are glitches during your flashing (maybe try slowing it down with /delay:20 ? maybe fight harder to get /nodma working, just for the side-effect of slow-but-sure flashing?)
you're flashing just fine, but you're somehow getting errors reading back; in this case, reading multiple times seems likely to give different results; try doing it a bunch of times and seeing whether the md5sum of the backup varies
the flash on your unit is faulty and is incapable of writing data at those six locations; once you've done your best to eliminate write errors and read errors, you could test for this by writing a file of plain zeroes and seeing whether the read comes back with contains anything else
I get nothing on the serial port still. This all seems very strange to me.
The first thing CFE does is decompress the bootloader. If the CPU is really seeing those 0xffff and if they lie in the compressed data, CFE would either detect that during decompression and die, or decompress some garbage and try to run it (and die). Some bootloaders at least announce what they're doing before they try it, but from the look of the logs on the wiki it seems this CFE doesn't, so you may just see nothing. But we should also consider the possibility that your serial port connection is dodgy, unless you ruled that out earlier?
It is 128KB instead of 62KB, again I don't understand?
That's because we're using /length:20000. That's bigger than it needs to be. It doesn't do any harm.