Re: [PATCH 0/1] arm: imx: fsl_otp: make fuses (OTP memory) read-only

[Bob Cochran <yocto@mindchasers.com>]

On 11/09/2014 10:09 AM, Eric Bénard wrote:
> Hi Alexander,
>
> Le Sun, 09 Nov 2014 11:14:39 +0100,
> Alexander Holler <holler@ahsoftware.de> a écrit :
>
>> Am 08.11.2014 19:49, schrieb Alexander Holler:
>>
>>> I'm not confused, at least not in regard what you want to suggest. Of
>>> course, I'm totally confused about the fact that almost nobody else
>>> before has critized that write functionality of this driver, also I'm
>>> already used to the fact that I'm unable to understand many things which
>>> are happing in todays world. But nobody is perfect. ;)
>>
>> Just to make it more clear what this thread is about, here is a relevant
>> sentence copied form the reference manual for the chip:
>>
>> "In order to avoid "rogue" code performing erroneous writes to OTP, a
>> special unlocking sequence is required for writes to the fuse banks."
>>
> That's why adding an unlock sysfs entry would match the required
> sequence to unlock the write access on the user point of view, but
> that's Freescale's problem and policy.


Hi,

My preference would be to have an otp recipe under 
meta-fsl-arm/recipes-manufacturing and in the recipe would be the otp 
kernel patch that could be applied along with user space code to 
exercise it.

As an un-applied patch, I would never have to worry about it bricking my 
board.  However, when it comes time to use the feature in a 
manufacturing environment, it's there for me.

And for extra safety, give the patch an unusual suffix (e.g., .otp) so 
it doesn't accidentally get swept into a kernel patch set.

Bob






>
>> Now guess why the HW was designed this way. And then look again at the
>> driver which nullifies the careful implementation in the HW. It doesn't
>> have to be the fault of the author, e.g. he just might have written it
>> for internal use. The problem is that it went into kernels for public
>> use and nobody has seen a problem. Might be because of missing knowledge
>> about what the driver does at all or whatever. I don't know.
>>
> Evaluation boards come with unlocked/unburned fuse so if a designer
> wants to evaluate his fuse configuration on an EVB during the design
> phase of his custom product he may need this driver especially when
> using Freescale's MFG Tools.
> If your Wandboard has unburned fuses and their kernel has this driver,
> then ask them why they keep this features open to their users by default
> (this can be because the SOM are intended to be used in final products
> and they let the final user of their SOM burn what he wants in the fuse
>   - his own MAC address for example - so here again that's the job of the
> end product designer to remove this feature once he launch his product
> on the market).
>
> Best regards,
> Eric
>