Proposal for a New Command to U-Boot Fuse Programming

[Harsha Vardhan V M]

I would like to propose a new command for U-Boot's fuse programming 
functionality to address the challenges posed by the current 
implementation. While the existing fuse prog command works well for 
programming individual fuse values, it becomes cumbersome especially 
when dealing with large-scale programming requirements.

Current Command: fuse prog [-y] <bank> <word> <hexval> [<hexval>...]

This command programs one or more fuse words starting from a specific 
<bank> and <word> with the hex values given as input.

While functional, it lacks the efficiency and robustness needed for 
programming a significant number of fuses or handling structured fuse 
configuration data. Repeatedly specifying values for each fuse bank and 
word is not only time-consuming but also prone to errors during manual 
input or scripting. This approach does not leverage the ability to 
process pre-structured data in memory. For users with complex 
programming needs, the current method becomes an obstacle rather than a 
tool.

Proposed Command: fuse writebuff

NAME
fuse writebuff - Program fuse data using a memory-based structured buffer.

SYNOPSIS
fuse writebuff <command_id> <addr>

DESCRIPTION
The fuse writebuff command provides a new method for programming fuses 
by leveraging a structured buffer in memory. Instead of requiring 
explicit <bank> and <word> parameters for each fuse word, this command 
operates on a structured buffer in memory at <addr>, that contains all 
the necessary data and programming details, allowing bulk or structured 
programming in a single operation. This approach simplifies workflows, 
reduces manual input, and improves flexibility for complex programming 
scenarios.

PARAMETERS
• <command_id>
Specifies the programming mode or indicates how the buffer data should 
be interpreted. This parameter is a u32 value that identifies the 
operational context or configuration for the programming process. 
Examples of command_id usage might include:
  • A programming mode
  • A specific interpretation of the buffer layout.
  • A mode for validating the buffer before programming.

• <addr>
The starting memory address of the buffer containing the structured fuse 
programming data. This parameter is of type ulong and points to a block 
of memory where the programming data and any associated metadata reside.

USAGE
The fuse writebuff command reads the buffer at <addr> and interprets it 
according to the specified <command_id>. The structure of the buffer 
should contain all necessary details for programming fuses, such as the 
values to be written to the fuse, optional metadata for validation or 
programming constraints and any configuration data required for the 
operation.

EXAMPLES
1. fuse writebuff 1 0x80000000
In this example:
•    command_id is 1, specifying a particular programming mode or a 
buffer format.
•    addr is 0x80000000, pointing to the starting memory address where 
the structured buffer resides.

RETURN VALUES
• 0: The operation was successful.
• Non-zero: An error occurred during the operation. Errors may include 
invalid command_id, inaccessible memory at <addr>, or issues with the 
buffer contents.

The corresponding function, fuse_writebuff(u32 command_id, ulong addr), 
would process this data in a single invocation. This approach 
significantly streamlines and simplifies workflows where fuse 
programming involves predefined rules or structured data, enabling users 
to prepare a struct buffer in memory that encapsulates the entire fuse 
programming configuration. I believe fuse writebuff simplifies 
workflows, reduces error risks, and provides the extensibility needed 
for advanced usage scenarios like programming large or complex fuse 
configurations.

Request for Feedback

Does this proposal look good? If so, I will start to work on an RFC 
patch to implement the proposed changes.

Best regards,
Harsha Vardhan V M
h-vm at ti.com