Proposal for a New Command to U-Boot Fuse Programming

[Simon Glass]

Hi Harsha,

On Sun, 5 Jan 2025 at 23:36, Harsha Vardhan V M <h-vm at ti.com> wrote:
>
> 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.

What format is the buffer in? Is it a text file?

Regards,
Simon