Dear Wolfgang,
Wolfgang Denk wrote:
Because there simply *is* *no* policy at all. Especially not in a
That is not true. There are several policies already.
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.
Leaving the state of sectors (except for U-Boot managed sectors) until user takes explicit lock/unlock action as they are is another policy . This has been the policy so far which I would call "common sense" policy.
Providing software protection for flash that does not have hardware protection is yet another policy.
one-size-fits-all driver like cfi_flash which is what we are talking about.
If you have special requirements please feel free to implement these in your board specific code. But don't try to enforce your special ideas of how things should be on everybody else.
I am not trying to implement anything. Existing code works well for me (well after a couple of fixes which I submitted a patch for).
It is the new patch (not from me) that is introducing new policies and ways that needs to be questioned and discussed since it is effecting a common driver. This new patch is enforcing new ideas and policies. I've raised a number of issue with the new approach which you see to conveniently avoided. Could you please answer the following?
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 safer state a common sense approach?
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?
Best regards, Tolunay
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 to 1.1.3 since you picked some other fixes to go in that release. I am now worried that it is lost somewhere.
http://sourceforge.net/mailarchive/message.php?msg_id=12234135