[U-Boot-Users] RFQ: disable flash writes until after relocation?

[Wolfgang Denk]

In message <48822929.5050408 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A mouse is an elephant built by the Japanese.