In message 48822929.5050408@ovro.caltech.edu you wrote:
We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization.
A write to flash should not matter at all.
Under the right conditions, the write appears to put the flash into a command-mode, rather than read-data mode,
Hm... all flash devices I know of require a certain command sequence to be written, which should never happen "by accident". Agreed, Intel flashes are braindead by accepting the writes to arbitrary addresses within the same sector, so writing a binary image sequentially to a flash memory space may easily trigger such a problem - but this should never happen in U-Boot code.
and further reads from the flash return invalid data (as far as the processor is concerned). The write was coming from drivers code that we had not introduced,
Which exact driver are you referring to? If any driver has such a bug, it should be fixed.
The MPC8349 processor base register has the option; BRn[WP] = 1, that could be used to disable writes to the boot flash. This local bus controller register is likely
...
Writes to boot Flash could be disabled early on in the boot sequence, and then enabled again after relocation. This would protect against writes to the boot flash.
This is not the way to go. Hushing up problems has never been a solution. Instead, let's find and fix the culprit.
I figured I'd gauge if there was any interest in adding this feature before looking into it further.
Frankly: I saee this as a non-issue. Let's rather fix the bug instead.
Best regards,
Wolfgang Denk