Can the Linux user space call the SCFW API?

[flobro]

Or is it a kernel space only operation?

I would like to burn fuses in Linux for the imx8 Quad Max, and using uboot/serial loader is problematic due to the design of the product.

[Harvey021]

Hi @flobro 

Send you email with a patch

Regards

Harvey

[flobro]

Seeking does NOT work with this version in 5.10.72 on the Quad Max (you always get zeros...). I can read from the beginning of the file and stop where I need to or read the entire file to a physical file and then seek...   I wish we had actual documentation from someone familiar with the driver (Peng Fan, are you listening?) and describe what fuses you can or cannot read/ write on the iMX8 Quad family that have the SECO/SCFW parts...

[Harvey021]

I'll send you a reference, hope that can be helpful for you. 

Regards

Harvey

[flobro]

I have read that all fuses are not accessible via nvmem.

I would like to burn the SRK fuses and other security fuses... I also an having trouble mapping the fusebanks that would be used in uboot to figuring the offset in nvmem...

for example, SRK0 is at word 722, and nvmem does not show anything higher than 0x0c80, and plus the gaps  in the output of nvmem:

0000440 0000 0000 0000 0000 0000 0000 0000 0000
*
0000c00 0000 0000 2117 0f08 0607 1714 ffff ffff

so nothing in certain gaps.

[seb_haezebrouck]

0xC80 = 3200 bytes = 800 words.

Word 722 (decimal) is at byte offset 0xB48, which reads 0x00000000 in your dump. Try hexdump -v, so that hexdump does not squeeze lines.

I must confess I never tried and burn fuses through nvmem, but the Linux driver seems to support it.

[flobro]

Assuming I can write the SRK fuses, just reading the values at the offset returns an error:

dd if=/sys/devices/platform/scu/scu\:imx8qm-ocotp/imx-scu-ocotp0/nvmem skip=452 bs=4 count=1 | hexdump -v

I get "Invalid argument"

452 is the MAC1_ADDR

(assuming I have not screwed that up..)

[seb_haezebrouck]

cat /sys/.../nvmem | dd skip=452 bs=4 count=1 | hexdump -v

dd'ing directly from a sysfs pseudo-file probably does not work out very well.

[flobro]

would that not also apply to a dd write?

[seb_haezebrouck]

I am afraid so. But a small C program should do the trick.

fd = open(NVMEM_PATH, O_RDONLY);
pread(fd, &fuse_value, 4, fuse_word_offset);
close(fd);

same for writing with pwrite.

[flobro]

The c program works as long as a seek is not involved. Either pread or read with a seek beforehand returns all zeros.

If I read the whole beginning of the file (I am reading the unique id as a test at offset 0x40), I get the correct 8 bytes, but seek'ing returna all zeros.

This is such a great exact science (not!) with all the articles saying fuses are not supported, then the drivers support read/write, then the drivers dropped write only to allegedly have write added back in.  There is more to this and I would love to hear an authority on the nvmem driver to this layman (like the author Peng Fan)... But I hope too much.

Thanks for the help, and I an assuming that the original question about SCFW API can only be accessed from kernel space (which is no help).

I guess I will have to go with my silly idea of using uboot scripts which in our case is not the most efficient way.

P.S.

"Crucible" works great on the imx8mp for reading/writing fuses in Linux, but unfortunately does not  support imx8 Quad Max (I guess because of security model).

[seb_haezebrouck]

Either pread or read with a seek beforehand returns all zeros.

pread/pwrite work for me. No seek beforehand, just specify the offset as the fourth argument: pread(fd, &value, 4, 16) returns the first word of the unique ID. Similarly, I could burn the MAC fuse with pwrite.

Using 6.1.22_2.0.0 release (6.1.22 kernel), on i.MX 8QXP - but QM should be similar.

Admittedly the pread manpage mentions that the file opened must be capable of seeking. So not sure why this works, or if it is a lucky coincidence on my side. Or a compiler dependency: for the sake of speed, I compile using ubuntu aarch64_linux_gnu- Xcompiler and linking statically.

[flobro]

Unfortunately, even Uboot cannot write the first fuse for using secure boot:

@https://community.nxp.com/t5/i-MX-Processors/imx8-Quad-Max-uboot-fuse-prog-ERROR/m-p/2048429#M23428...

[Harvey021]

Found that you get an update from other case and the version of imx-seco-3.8.5.bin can be helpful.

There is SECO_FW_release_note.pdf at imx-seco-3.8.5/firmware/seco/

Regards

Harvey

[flobro]

Unfortunately I am stuck on 5.10.72 (for now), so maybe older driver...

[seb_haezebrouck]

Hi @flobro ,

The fuses are exposed already to the userspace. See linux-imx/drivers/nvmem/imx-ocotp-scu.c at lf-6.6.y · nxp-imx/linux-imx · GitHub.

You can open /sys/devices/platform/scu/scu:imx8qx-ocotp/imx-scu-ocotp0/nvmem (or a similar path for QM), and perform read/write at the proper offsets in the file to access or burn fuses. The nvmem file is a raw binary access to the whole fusemap. Just fseek to the proper offset and fread / fwrite the proper number of bytes. I'd suggest you do read trials first to make sure you get your offsets right, as burning the wrong fuses could irremediably brick your device.

fuse words 16 and 17 are good candidates, they store the device unique ID, which you can retrieve from uboot, or a sysfs entry (/sys/devices/soc0/... from memory.)

Hope this helps,

Sebastien