[U-Boot-Users] [PATCH] cfi_flash.c patches

[Wolfgang Denk]

In message <430A4C2C.60506 at orkun.us> you wrote:
> 
> That is not true. There are several policies already.

Let's  agree  on  the  term   that   there   are   several   existing
implementations, ok?

> Just a couple of emails ago you were saying all sectors should be in 
> writable state in U-Boot. This is a policy which is announced today by you.

OK.

> Leaving the state of sectors (except for U-Boot managed sectors) until 
> user takes explicit lock/unlock action as they are is another policy . 

I don't call this a policy.

> Providing software protection for flash that does not have hardware 
> protection is yet another policy.

I don't call this a policy.

> It is the new patch (not from me) that is introducing new policies and 

I did not even review this  patch  yet.  I  just  commented  on  your
requirements, which I do not agree with.

> Why do you think it is OK for U-Boot to unlock sectors/blocks that it 
> knows nothing about their usage? Wouldn't leaving these sectors in a 

Because in the general case (and this is what cfi_flash is used  for)
you  don't  expect  to  have  any  hardware protected sectors. Not in
U-Boot, and neither in Linux when you for example want to  use  these
for a writable MTD partition.

> safer state a common sense approach?

Not for me. I don't like the hardware doing magic  things  to  me.  I
want to be in control over the hardware - not vice versa.

> While you see it important to protect U-Boot environment (for various 
> reasons and I agree), you do not seem to consider consistent protection 
> for another area of flash that may be storing equally vital information 
> for software system. Why?

Not on  a  *automatic*  base.  I  accept  this  only  if  explicitely
requested  by  the user (by using the "protect on" command) *and* the
board designer (by providing a  flash  implementation  that  supports
hardware  write  protection both in hardware [by selcting appropriate
flash chips] and in software [by  enabling  the  needed  features  in
U-Boot]).

As mentioned before: if you want to have this on a  board,  OK,  then
implement  it there and put apropriate big warnings and notes in your
board documentation. If this is general code which is  used  by  many
boards  that  you  don't  control  (and  do not test!) then I want to
provide a common interface. And common behaviour is that flash can be
erased and written to in the boot loader.


> Note: I had submitted a bug fix on July 2nd for a number of cfi_flash.c 
> fixes. Do you still have that in your queue? I was expecting it would go 

Yes.

> to 1.1.3 since you picked some other fixes to go in that release. I am 
> now worried that it is lost somewhere.

It's not lost. The selection of patches for 1.1.3 was done  based  on
their  complexity - simple fixes or changes that were obviously local
to one board only went in, but more complex  modifications  or  stuff
like yours that needs testing on many platforms was further delayed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.