i.MX28 - driver for OTP eFuses

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX28 - driver for OTP eFuses

2,661 Views
ChristophG_Baum
Contributor III

Hello Forum,

using a vanilla 3.7 Linux kernel for the i.MX28 EVK I started porting some drivers from the Freescale SDK based on 2.6.35.

The OTP driver allows reading the OTP cells via the sysfs but fails to write. I tracked the problem to a call to clk_get(). The name of the required clock seems to have changed from "hclk" to "hbus", but fixing that didn't help. sysfs shows a clock named "hbus". So what else could go wrong?

Regards

Christoph

Labels (2)
Tags (3)
14 Replies

534 Views
dimitarboevski
Contributor II

Hey, i got it working. Both reading and writing.

I'm using the clk_get_sys("hbus", NULL) function to get the clock. It should work after registering it like you do (as i saw it in your patch - it helped me a lot!) in the clk-imx28.c file.

The other thing that has changed is some regulator's name (the name is already set in the device tree). You should change it in the board file mach-mxs.c to "vddio-sd0":

static struct fsl_otp_data otp_data = {

  .fuse_name = (char **)bank_reg_desc,

  .regulator_name = "vddio-sd0",

  .fuse_num = BANKS * BANK_ITEMS,

};

Now i get a warning when the driver creates the sysfs entries if the kernel is compiled with CONFIG_DEBUG_LOCK_ALLOC set. It seems to be a problem with the kernel itself because the sysfs driver is doing things to "make lockdep happy"... but anyway, the OTP driver works.

534 Views
ChristophG_Baum
Contributor III

I uploaded a new patch that includes the fixes for clock and regulator. It now conforms to the checkpatch.pl script in the current mainline kernel (appart from the missing "signed off by").

0 Kudos

534 Views
dimitarboevski
Contributor II

Ahh, we just have to call sysfs_attr_init() to "make lockdep happy". here's a mini patch:

diff --git a/drivers/char/fsl_otp.c b/drivers/char/fsl_otp.c

index ce99bf8e..c3cc1c6 100644

--- a/drivers/char/fsl_otp.c

+++ b/drivers/char/fsl_otp.c

@@ -158,6 +158,8 @@ static int alloc_otp_attr(void)

  kattr[i].store = otp_store;

  attrs[i] = &kattr[i].attr;

+ sysfs_attr_init( attrs[i] );

+

  }

  memset(&attr_group, 0, sizeof(attr_group));

  attr_group.attrs = attrs;

0 Kudos

534 Views
fabio_estevam
NXP Employee
NXP Employee

Do you guys plan to send this patch upstream?

0 Kudos

534 Views
lategoodbye
Senior Contributor I

Hi,

took Christoph's last version and made a V3. This version is without write support because this would have a negative impact on the whole system:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html

Please send me testing feedback for i.MX23 and i.MX28.

BR Stefan

0 Kudos

534 Views
ChristophG_Baum
Contributor III

I would like to, but currently I haven't got the time. And as I'm a nobody on LAKML it is likely to be ignored, as was the DCP patch.

0 Kudos

534 Views
dimitarboevski
Contributor II

Good work.

Do you get the following warning at kernel loading:

WARNING: at kernel/lockdep.c:2986 sysfs_add_file_mode+0x80/0xe8()

( stacktrace )

BUG: key c7620028 not in .data!

.....

It's only shown when the kernel is compiled with the CONFIG_DEBUG_LOCK_ALLOC option. If you don't get the warning could you check if that option is turned off for you? I would rather not turn it off so i'm trying to get rid of those ugly 20 lines of "BUG".

0 Kudos

534 Views
ChristophG_Baum
Contributor III

Yes, I see warnings like this. I will try your patch below.

0 Kudos

534 Views
ChristophG_Baum
Contributor III

Yes, it works for me too!

Now I have some deadbeef in my i.MX28 :-)

0 Kudos

534 Views
fabio_estevam
NXP Employee
NXP Employee

Christoph,

It would help if you post your patch to the Linux ARM kernel mailing list, so that people could review what you did.

Regards,

Fabio Estevam

0 Kudos

534 Views
ChristophG_Baum
Contributor III

My (still not entirely working) patch can be found at http://www.sgoc.de/Downloads/fsl-otp.patch.

Christoph

534 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Christoph,

What does "not entirely working" mean? What is missing?

I saw your post in the linux-arm-kernel list. It would be really nice if you could post it as patch (via git send-email, preferably) so that people could review it and possibly accept it to the kernel.

Let me know if you need help with the submission process.

Also, how did you test it?

Thanks,

Fabio Estevam

0 Kudos

534 Views
ChristophG_Baum
Contributor III

Hi Fabio,

What does "not entirely working" mean? What is missing?

reading works, but writing OTP cells fails because clk_get() fails to get the handle for the CLK associated with "hclk", "hbus" or whatever. As far as I understood the code in 3.7 the name of the clock is "hbus" and it seems to get registered. A clock of this name can also be seen via /sys/kernel/debug. But clk_get() still fails. Could it be that the clock has also to be named in the device tree?

I saw your post in the linux-arm-kernel list. It would be really nice if you could post it as patch (via git send-email, preferably) so that people could review it and possibly accept it to the kernel.

Currently I'm waiting to see how the DCP patch is going.

Regards,

Christoph

0 Kudos

534 Views
ChristophG_Baum
Contributor III

Hi Fabio,

well, you may be right that the Linux ARM kernel mailing list is a better place for this question. But I didn't dare as the driver doesn't work so far.

Regards,

Christoph

0 Kudos