On 10/2/26 9:16 AM, [email protected] wrote:
Hello Kuwano-san,
Add two subcommands, rdreg and wrreg, to read and write SPI NOR
registers respectively. The registers are always accessed using
register specific access opcode and arbitrary amount of data are
read from SPI NOR register and stored to memory or loaded from
memory and written to SPI NOR register. This is useful in case
the SPI NOR non-volatile registers have to be configured in some
non-standard way, or when debugging the SPI NOR configuration.
Example usage:
Read 6 Bytes of SPI NOR ID (Read ID opcode is 0x9e):
"
=> sf rdreg 0x9e $loadaddr 6
=> md.b $loadaddr 6
00000000: 20 ba 20 10 44 00
"
Read Micron Nonvolatile Configuration Register (opcode 0xb5):
"
=> sf rdreg 0xb5 $loadaddr 2
=> md.b $loadaddr 2
00000000: ff ff
"
Write 0xfffe (LSByte first) into Micron Nonvolatile Configuration
Register (opcode 0xb1):
"
=> mw.b 0x00000000 0xfe
=> mw.b 0x00000001 0xff
=> sf wrreg 0xb1 $loadaddr 2
"
Signed-off-by: Marek Vasut <[email protected]>
I understand register access from CLI is useful for developing and debugging.
However, if we want to make this a generic debugging feature, we need to
consider many vendor/chip-specific variations. For example, non-volatile
register write require polling the status until completion (which is currently
missing from your implementation)
Isn't polling only a matter of reading the status register, so it should
be easy to script using "sf rdreg"/"setexpr var *address"/"while test
var -eq ..." already ?
. Some registers require address cycles for
access. Some registers require latency cycles for reads, and so on.
The spi_nor_read_reg() passes SPI_MEM_OP_NO_ADDR to the operation, so
maybe what we would need here is separate generic issuer of SPI NOR ops
subcommand ? That is, something like "sf op <parameters passed to
SPI_MEM_OP>" ?
Unless we can support these known variations, I think this feature should
remain a temporary local modification.
I would really like to avoid having to maintain downstream patches,
those do not help anyone. But maybe there is a way to expand this patch
to make it upstreamable ?
--
Best regards,
Marek Vasut
