On Sun, 22 Nov 2015 18:57:16 +1000 Adam Nielsen a.nielsen@shikadi.net wrote:
Error: Image size (8192 B) doesn't match the flash chip's size (262144 B)!
While I understand this would normally be a problem, for me it's fine - I'm only interested in the first 8kB and the rest of the chip is not important to me. But I couldn't find any options to tell flashrom to continue and flash anyway, and --force didn't help.
Don't use the force switch. It's the dark force :P
I guess I could pad out the 8kB XTIDE image to only 128kB, then double that to get a 256kB image, but it's all very kludgy!
But the right way, currently.
would it be possible to add another option to allow partial flashing?
Yes, and we are working on that. The current state of affairs can be found here: https://github.com/XVilka/flashrom/tree/libflashrom_layout One needs to write a layout file to use the additional functionality but the base for it is already integrated, see below.
You are facing two problems actually:
1. flashrom expects a 256 kB file for a 256 kB flash chip. This does not completely change even with the patches above in their current form. So you still would need to prepare a file with 256 kB, although with the patches integrated it would no longer matter what is in there because you could specify additional files for any specific address ranges which need to be just as big as that range. 2. You want to write only a part of the chip. Either 128 kB because that's what the programmer is capable of, or even less because that's what your payload size is. flashrom supports this out of the box with layout files already. So you could prepare a 256 kB file with only the first 8 kB of valid data and use a layout file to tell flashrom to only write those 8 kB and stop then.
BTW flashrom (latest stable) tells me the SST29EE020 is untested, so I would be happy to report back with my results, assuming you accept flashing a 256kB chip in a 128kB programmer as a valid test ;-)
I think our policy regarding this is not to mark them as tested because that access pattern could hide some real bugs even if that's unlikely. After all, "untested" does not mean unsupported... all chips in the code base should just work.