For an fx2 it's not flash, it's an eeprom. They are cheap, come in small and larger sizes. I'm always surprised at how so many of the camera vendors end up cutting of thier nose to save a few cents in that area. For the cost of handling ONE support call dealing with driver / firmware load problems, you can pay for the eeprom on a hundred cameras when buying in typical production run quantities. At production time, the eeprom must be programmed, even if it's just to put in the vid/pid in a small one. The time delta between programming a few bytes, and a few kbytes, is lost in the noise when you account for the time it takes to hook it up, and then unhook from the equipment. Over the years I've read so much about folks having issues with drivers etc, and firmare versions, yadda yadda. If you look at something like a qhy5, the total production cost increase to put it all on board would be on the order of a buck, possibly less.
It's a mindset that spills over from high volume consumer manufacturing, cut every penny out of the production cost where possible, but, imho it's a mistake for high value items in low production volumes.
The other thing that kinda surprised me a few years ago, when I started looking into the issue in a bit of detail. If you haul out the datasheet for the fx2, and any given sensor inside the camera, there really is only one way they can be wired together. The example I was looking at then was the qhy5, and when you look at the data sheet for the Mt9M sensor, and the fx2, you quickly come to the conclusion that there are only a couple questions to be answered. Is the data path wired up with only 8 bits between sensor and fx2, or, did they wire up all 10 bits as a 16 bit shift into the fx2 usb buffers ? the other questions, which gpio are used for the autoguider ports ? If one answers those two questions, then it's not a terribly difficult project to write a firmware for the fx2 that makes the unit functional. for higher end cameras, there would be a few more questions to answer, regarding how the cooling is implemented. But again, it's one function to read a temperature somewhere, then one of the digital io pins that turns the cooler off and on.
When I started really digging into it, I was quite surprised to realize, all of our astro related cameras are an fx2 with a sensor. That's the SBIG ST-10 we got as part of a package deal when we bought an observatory lock stock and moat, as well as our SX cameras we had prior to that, and the qhy cameras we had for guiders. And as it turns out, the Meade DSI is 'yet another', altho I didn't realize it at the time.
If I had enough spare time (which I dont these days), I think it would be a fun project to start from first principles and data sheets, then work up some firmware for the various cameras. If one takes the approach of the qhy firmware, just a set of function calls that allow a program on the host to set registers etc, it's quite realistic to come up with one firmware that will work with any fx2 based cameras, and all the camera specific smarts reside on the host computer, where it's much easier to work with things.
Maybe some day, when I have more spare time, i'll start fiddling with that idea. I have more than enough fx2 based cameras here to get a long ways into that kind of a project.