If it that easy, then maybe migrate through the files in
something like 1K chunks with dd, writing the next 1K chunk
from the file in flash to a 1K file on RAM Disk then back.
I think this is just for the few files in /boot, to refresh
the kernel, yes? The kernel is running in RAM, so you can
write to it the kernel binary file in /boot while running.
Actually, the kernel is the one thing I was not going to do in this go round. Since we have the image file and instructions for re-imaging the NOR flash with the kernel image, if we get permission to do that, I would use that approach instead. And if they had fielded either of the last two firmware upgrades that require the new kernel, even that would not be a question as the NOR would have been recently refreshed already. It is more the files in /boot, /bin, and /sbin that I am worried about getting refreshed. And some of the files in /bin and /sbin might be open and in use while trying to do the update, which is what has me going around the long way around.
I would be afraid of using dd because of the bad blocks. Although yaffs puts all the directory and file data for each page in the out of band bytes for each page, so that you could copy each page somewhere else and it would still work, that still seems a bit risky. If we use the file functions through yaffs, it will not only work around any bad blocks, but also increment the 2 bit page counter so that it can tell which page is current if power drops suddenly while the old and new versions are both still resident. And it will also mark the old pages as deleted and erase blocks where it can, so that should cover more ground than using dd directly. However, I have used dd to read the binary image of the flash, including the OOBs. But I have not yet decoded them enough to write a script to duplicate the processes in yaffs.