Common eFuse Interface

[cederom]

• Various MCU use eFuse for non-volatile hardware and security configuration.
• There is no common eFuse driver implementation in NuttX at this moment.
• Documentation is required in this area.
• Each arch configures eFuse on its own with its own nomenclature.
• Common eFuse Interface + driver examples would be nice to have.
• Various MCU implementations should be rewritten to a common eFuse Interface.

[cederom]

How about this one https://github.com/apache/nuttx/blob/master/drivers/efuse/efuse.c ?

[TimJTi]

Looks like a good starting point, thanks! I'll try and use this for a SAMA5 Secure Fuse driver and see how I get on.

On 25 Apr 2023, at 22:10, CeDeROM @.***> wrote:

How about this one https://github.com/apache/nuttx/blob/master/drivers/efuse/efuse.c ?

[TimJTi]

So... include/nuttx/efuse.h defines:

struct efuse_param { FAR const efuse_desc_t *field; size_t size; FAR uint8_t data; };

With the explanation:

/* The efuse_param is used by the application to inform which field(s)

• will be passed to the ioctl() operation.
• • 'efuse_desc_t *field[]': contains one or more field and it
• it terminated by a NULL to indicate there is no more fields.
• NOTE: normally the application don't need to create these fields
• they are mapped inside an arch efuse table and referenced
• in a header file inside include/nuttx/efuse/ directory.
• • size: how many bits the field(s) use
• • data: an application side allocated buffer where the read operation
• will store the efuse bits, so the number of allocated bytes
• need to be enough to store all bits. For write operation, this
• pointer contains the bits to be written. */

There are no implementations that use this. Perhaps it's because it's the end of a long week, but I can't get my head around what I'm supposed to do with this.

Can some kind person explain how it is to be used, please?

Perhaps use the example of the SAMA5D2 that has 32 bit fuses (SFC_DR0 through SFC_DR23)? What should the "arch efuse table" look like, where would it be, and how is it to be referenced in a (new) header file?

Also, data is a uint8_t, but this arch has 32 bit "fields". Should I just stick with 8 bit "fields" and have 4 times as many? Or have I missed the point of "fields"?

[TimJTi]

Spent some time today, and it does seem likely this should do the job, bot specifically and generically. Even though the SAMA5D2 I'm working with has 32 bit fuse registers there's no need for me to worry about the 32 vs 8 bit fields, as we just need to return 4 bytes if a full 32 bit fuse read is wanted (with suitable checks that the data struct member is large enough for the requested size, for example) but in may cases read/writes will be of individual fuse bits.

Once I have something implemented I will submit as a draft PR for critique.

I see the efuse files were co-authored by @xiaoxiang781216 - any information you can add? For example is it based on Linux or Android methods that I can compare to?

[TimJTi]

I have found that the esp32 processors have efuse support that makes use of the efuse driver core that @cederom linked to. It does the job, although has a few style issues that I will fix on the way.

I now have a working driver for sama5d2 which I will submit as a PR after more testing next week.

Therefore, I would say that the issue here is actually already covered, although additional documentation would be useful and I'll see what I can add.

[cederom]

Thank you @TimJTi :-) Good documentation is always welcome :-) Please create a separate PR for that :-)

[TimJTi]

See PR9252