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

Eric Bénard eric at eukrea.com
Fri Nov 7 08:03:17 PST 2014

Hi Alexander,

Le Fri, 07 Nov 2014 16:23:10 +0100,
Alexander Holler <holler at ahsoftware.de> a écrit :

> Am 07.11.2014 16:07, schrieb Otavio Salvador:
> > On Fri, Nov 7, 2014 at 1:04 PM, Eric Bénard <eric at eukrea.com> wrote:
> >> Hi Jon,
> >>
> >> Le Fri, 7 Nov 2014 15:31:15 +0100,
> >> Jon Nettleton <jon.nettleton at gmail.com> a écrit :
> >>> Fair enough.  Can we all agree that it should default to disabled?
> >>
> >> On your product sure, on the evaluation board that's more questionable.
> >>
> >> When an evaluation board's user reach this sysfs entries to do a write
> >> to it I believe that's not a random choice but a user's choice.
> >>
> >> Maybe adding a otp_unlock entry to the sysfs before allowing write could
> >> secure more the feature when running on the evaluation boards so that
> >> the user can think twice before writing to the fuses.
> >
> > I like Eric's idea of the unlock sysfs entry for this purpose.
> Maybe I should mention that this extremly dangerous driver already was 
> posted for submission into the (production) kernel and nobody had a 
> problem with it's write functionality, just with some other stuff.
In LAKML there was a post for a driver (for 23/28 at the moment) where
write support was dropped :

In mainline kernel :
- on the i.MX there is only one function used to get the MAC :
- read only fuse infrastructure was integrated for Tegra :

In Freescale's released kernel, the feature is available but one more
time I think that's not a production kernel but a base source code to
evaluate SOC's features on an evaluation board and then design
your own products where it's your responsibility to add / remove

> And even if it's ok for FSL to promote this feature with their BSP, I 
> have absolutely no love for the way it was done. It now is likely part 
> of many production kernels, something never should have happened.
It's the developer's responsibility to add/remove features on _their_
production kernel for _their_ product.

> And I still see absolutely no need to have some one time functionality 
> as part of the kernel, regardless how usefull it might be for some 
> developers. It's a waste of time and resources to include that write 
> functionality in something meant for the greater public. Especially 
> something that dangerous.
If you look how Freescale has designed their "Manufacturing tool" and
check a few of their xml files, you will understand why they need this
kind of low level access features in the kernel ;-)

Here on real products we do all that at bootloader level using a
special production version of the bootloader but that's an other story.

Best regards,

More information about the meta-freescale mailing list