This is a broader look at Opportunity's computer hardware and how it works, since I had found a bunch of these sources before @wooooooooosh posted the right answer. Seems a shame to not post it somewhere.
An earlier article (https://www.jpl.nasa.gov/news/news.php?feature=4406) also says 7:
The incidents of Opportunity's flash memory not accepting data for storage have occurred in only one of the seven banks of flash microchip circuitry on board.
This agrees with the "one of the seven banks of onboard flash memory" phrase in the quoted article. Unfortunately it turns out this is a misrepresentation. The first bank (bank 0) is not part of the 7x32MiB filesystem used for storage of scientific data, but it exists and it is also NAND flash.
Probably they think of it separately because it holds the firmware (~30MiB): the program code that runs on the CPU, and the data it needs. Leaving bank 0 as read-only (except for firmware updates) means that wearing out those flash chips from too many write cycles is very unlikely. Bad bits or other failures in bank 0 for other reasons could maybe be dealt with by booting from another bank, if the system can boot far enough to be reprogrammed remotely and update the bootloader.
NAND flash can only be read in large blocks (e.g. 512 or 4096 bytes). I don't know the page size of the flash used in Spirit / Opportunity, but according to one source they use flash chips manufactured by AMD.
Spirit's HW is similar but not identical to Opportunity's. I was able to dig up these details about their hardware, most of it consistent:
EETimes: Flash-memory snafu cripples Mars rover Spirit, says NASA:
The two Mars rovers consist of a single board computer called the RAD6000, which is reportedly built by BAE Systems in Manassas, Va. The microprocessor on the system is an older, 25-MHz part, based on IBM Corp.'s PowerPC family. It is a radiation-hardened device.
The RAD6000 does not use a hard drive for storage. Instead, data are kept in 128-MB of random access memory, although it's unclear which vendor supplies those parts. The computer runs a real-time operating system from Wind River Systems Inc.
[... also Intersil custom silicon, and Xilinx FPGAs in motor controllers etc.]
ExtremeTech: The ultimate remote admin: NASA will reformat Opportunity’s dodgy flash memory from 125 million miles away
Both Opportunity and Spirit are powered by a radiation-hardened 20MHz BAE RAD6000 computer, with 128MB of RAM, 3MB of EEPROM (firmware), and 256MB of NAND flash. The operating system (VxWorks) and critical subroutines are stored in the non-volatile EEPROM, while the flash memory is used to store less-important data — mostly captured imagery and other scientific data — while it awaits upload to NASA HQ via the Mars Global Surveyor orbiter or the Earth-based Deep Space Network. Curiosity, incidentally, has a virtually identical setup — but it uses a faster CPU (132MHz) and has lots more RAM and flash. Curiosity also has an identical backup failsafe computer that can be switched in if a fault develops — the earlier rovers only have a single computer.
Confirms that it has NAND-flash. And that the OS is Wind River's VxWorks.
(Another source said Spirit doesn't have EEPROM.) The article has a picture of a BAE single-board computer, similar to what's in Opportunity.
Tom's IT Pro: NASA Reformatted an SSD... on Mars!
...with the culprit most likely being dead NAND flash cells...
Another confirmation of using all NAND flash, as opposed to byte-addressable NOR flash which would allow execute-from-flash. So we know it must copy code from NAND into RAM on boot.
Opportunity contains 8 memory banks with 4 modules in each bank and four flash chips in each module for a total of 256 MBs of memory manufactured by AMD. The rover also contains 128 MB of RAM, 3 MB of EEPROM and runs on a 20MHz CPU.
ITworld: The day a software bug almost killed the Spirit rover
Spirit ran some hacked-together software that mirrored the DOS filesystem (FAT16 I guess?) in RAM, which failed when the FS filled up to bigger than RAM capacity.
a DOS library design flaw, a bug in some 3rd party software, and several configuration errors
Ouch. Presumably Opportunity uses FAT16 as its flash filesystem, too.
The RAD6000 CPUs has 8kiB of unified L1 cache. The PowerPC 601 it's based on also uses a unified cache, not split instruction/data caches like most CPU designs.
Some previous guesses would have been unlikely or impossible designs:
Now we know that bank 0 is special.
Before we knew that, there was speculation that it was used as parity for the other 7 banks. That would be an unlikely design: it would get 7x the amount of writes as other banks. (RAID-5 style distributed parity would be possible in theory to distribute that wear, but with flash erase-blocks being much bigger than write-blocks, not really. e.g. 256k erase block vs. 4k write block. And besides, it would be the same cells every time getting the extra writes in each stripe.)
I guessed that maybe the 8th bank was RAM, and it was on the same bus as flash. But that's not plausible for NAND-flash. It's not byte-addressable; only readable in whole pages through a flash controller chip that handle error-correction codes with page granularity. Hooking it up to the same address lines as the system RAM wouldn't make sense.
Execute-from-flash, aka execute-in-place is only done with NOR flash, not NAND. So the rover must copy copy + data it needs for whatever task its doing (e.g. orbital insertion vs. entry vs. roving on the ground) from flash bank 0 into RAM. Presumably the "no flash mode" just meant no writing data to flash, not avoiding reads of bank 0.
NAND flash can only be erased in large blocks, for example 256 kB, and can only be written in pages (e.g. 4kB at once).
The OS itself (VxWorks, a real-time embedded operating system) probably runs directly from the 3MB EEPROM even in normal operation. This counts as part of the firmware, even though it's stored separately from the code+data in flash bank 0.
Code can run directly from an EEPROM; it's byte-addressable like RAM. Probably that includes boot-time functions that load flash into RAM.
I don't know if updates from Earth ever modified the EEPROM contents, but that is plausible because EEPROM = Electrically Erasable Programmable ROM. But it's risky: any interruption or corruption could brick the rover, just like why updating the BIOS on your motherboard warns you not to turn off the power, and make sure the power is stable. Still, uploading a new image to the rover's RAM and then checksumming it would make an update pretty safe and not dependent on anything external after it started. They'd probably only do if if necessary to fix a problem they couldn't work around another way.
Apparently Spirit doesn't have a separate EEPROM, only Opportunity does. So IDK how Spirit boots. There must be something to let Spirit boot, unless the NAND flash controller automatically copies some flash to RAM, or supports reading from memory-mapped flash.
Onboard memory includes 128 megabytes of random access memory, augmented by 256 megabytes of flash memory and smaller amounts of other non-volatile memory, which allows the system to retain data even without power.