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

Alexander Holler holler at ahsoftware.de
Fri Nov 7 06:55:28 PST 2014

Am 07.11.2014 15:31, schrieb Jon Nettleton:
> Fair enough.  Can we all agree that it should default to disabled?

Anyone who is in need to write the OTP should be able to apply a patch 
or to do a git revert in order to use that functionality.

Those which are unable to do so, might not have an idea about OTP at 
all, or they might not be aware how dangerous it is to write it (besides 
the necessary knowledge about what to change).


Alexander Holler

> -Jon
> On Fri, Nov 7, 2014 at 3:00 PM, Eric Bénard <eric at eukrea.com> wrote:
>> Hi Alexander,
>> Le Fri,  7 Nov 2014 10:43:34 +0100,
>> Alexander Holler <holler at ahsoftware.de> a écrit :
>>> Jon Nettleton made me aware that there is a driver which makes it very
>>> easy to write to the OTP from userspace.
>>> And I have to admit that I was mildly shocked.
>>> Because OTP stands for One Time Programmable, it means the write
>>> functionality of that driver can be used only once per HW and if that
>>> is done wrong, the HW might be one of those famous electronic bricks
>>> afterwards.
>>> So I've quickly written a patch which makes this driver to a friendly
>>> citizen instead of an heavily armed cowboy.
>>> I really, really think this patch should be attached to all trees which
>>> are including fsl_otp.c. It applies without any error to
>>> imx_3.10.17_1.0.1_ga, imx_3.10.31_1.1.0_beta, linux-linaro-lsk-v3.14-mx6
>>> and likely any other tree which includes that driver.
>> That's not shocking to have this feature in a reference design's BSP :
>> Freescale provides base source code to evaluate their SOC and writing
>> OTP is one feature of their SOC.
>> Then that's the end product designer's responsibility to enable/disable
>> features he wants or not on its product.
>> The solution proposed by Otavio to add an option to ease the
>> disabling of this feature is far better than fully removing the code.
>> Best regards,
>> Eric

More information about the meta-freescale mailing list