iMX6ULL with 5.4 kernel BSP OCOTP access ?

[mirceaciocan]

Hello, how is the OCOTP eFuse register access organized compared with the older BSPs with kernel 4.x, are they still available as:

/sys/fsl_otp/HW_OCOTP... individually named pseudo-files or are they accessed via the new clumsy block interface ?

What about the write support from inside of the running Linux (NOT U-Boot, not manufacturing tools), is it available ?

Many thanks,

Mircea

[gusarambula]

Hello Mircea,

For the i.MX8 processors all fuse writes should pass through u-boot or directly through the SCU, there is no Linux user space support for burning fuses.

I hope this helps!
Regards,

[mirceaciocan]

Hello @gusarambula and thank you for the quick reply, unfortunately, it is fully incorrect and misleading and I hope you'll edit or delete it. Let me explain:

- The original question was about the OTP fuses support in the new BSP based on kernel 5.4.x, if the user-space access is supported in it and if the original, sane way, of accessing them via the /sys/fsl_otp/HW_OCOTP_* pseudo-files. I think it was reasonably clear formulated.

Sadly, the answer you gave me is incorrect wrt the 5.4.x based BSP:

"For the i.MX8 processors all fuse writes should pass through u-boot or directly through the SCU, there is no Linux user space support for burning fuses."

False, the driver that is selected ./drivers/nvmem/imx-ocotop.c has full read/write access to eFuses, even for iMX8 series.

Furthermore the page that you linked at is fully obsolete, even the link to the linux-imx is invalid, pointing to the long gone Freescale git server.

What is worse is that the Linux user-mode support is implied to be like the old driver, but this not the case, the driver in the latest 5.4 BSP is the new, ultra-cumbersome, driver that does not have the named fuses anymore, but looks like some kind memory block, where one should spend serious time calculating offsets to be able to do the most simple operation, like setting a MAC address. If this is somehow more reliable and less error prone than the old one where you can just look in the datasheet name of the register and do a echo 0xXXXXXXXX > /sys/fsl_otp/HW_OCOTP_MAC0 and be done with it, I fail to see it, personally I consider it pure laziness to not maintain the names table, is not like they are changing every few days.

Anyways, the correct answer seem to be:

For the current 5.4 kernel BSP the user space access to the eFuses seem to be there, but the /sys/fsl_otp system is gone :smileysad:.

If somebody already ported the old driver to this BSP I will be most happy to hear about it, the current way to access the fuses is insane IMHO.

[sjuengst · Accepted solution]

Mircea Ciocan, it only takes 4 changes to get the old fsl_otp driver back:

1. Add the following to drivers/char/Kconfig:

config FSL_OTP

      tristate "Freescale On-Chip OTP Memory Support"

      depends on HAS_IOMEM && OF

      help

        If you say Y here, you will get support for a character device

        interface into the One Time Programmable memory pages that are

        stored on the some Freescale i.MX processors.  This will not get

        you access to the secure memory pages however.  You will need to

        write your own secure code and reader for that.

        To compile this driver as a module, choose M here: the module

        will be called fsl_otp.

        If unsure, it is safe to say Y.

2. Add the following to drivers/char/Makefile:

obj-$(CONFIG_FSL_OTP)          += fsl_otp.o

3. Copy drivers/char/fsl_otp.c from an older BSP (I used 4.9.88).

4. Add CONFIG_FSL_OTP to your defconfig.

Enjoy!

[mirceaciocan]

I can confirm, with the driver snagged from 4.19.35 BSP, ported to 5.4.60 and with iMX6ULL, everything works perfectly.

I can only plead one more time for the NXP to re-include the sane driver in the BSP, as it offers the best way, IMO, to access the eFuses and maybe look at the work of one other contributor in the forum, that ported it to iMX8 series as well.

Even if internally there may be differences, offering a clear and consistent interface to the eFuses, that is easy to check with the Reference Manual, is a big plus compared with the actual cluster flip that we have now.

[tylernol]

we just did for ULZ + 5.4 . NXP should really put the OTP sysfs driver  officially back into 5.4. 

[mirceaciocan]

Hi Tyler, care to share your implementation ? It is of course the best if NXP will put it back in the official BSP, to not carry yet another patch during the lifetime of the device, but the actual kernel implementation is really disgusting and also dangerous.