I am trying to make use of the template/skeleton in include/nuttx/efuse.h
It 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"?
Thank you!
>-----Original Message-----
>From: Tim Hardisty <t...@hardisty.co.uk>
>Sent: Tuesday, April 25, 2023 7:33 PM
>To: dev@nuttx.apache.org
>Subject: SAMA5 secure fuse controller driver
>
>The SAMA5 support has no driver for the secure fuse peripheral. Kconfig
>allows you to “enable” it but there’s no underlying code.
>
>Before I go ahead and create a character driver for this, is the omission
>for a “good” reason?
>
>The driver would handle the relatively straightforward management of
>programming the fuses, as well as obviously allowing you to read values.
>If another arch has anything similar please point me in its direction so
>I can create one that’s similar.
>
>Thanks,
>
>TimJTi.
