History log of /openbmc/qemu/hw/nvram/aspeed_otp.c (Results 1 – 3 of 3)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v10.1.0
# d6dc027c 12-Aug-2025 Kane-Chen-AS <kane_chen@aspeedtech.com>

hw/nvram/aspeed_otp: Add OTP programming semantics and tracing

Implement correct OTP programming behavior for Aspeed OTP:
- Support read-modify-write flow with one-way bit programming:
* prog_bit

hw/nvram/aspeed_otp: Add OTP programming semantics and tracing

Implement correct OTP programming behavior for Aspeed OTP:
- Support read-modify-write flow with one-way bit programming:
* prog_bit uses 0s as the "to-be-programmed" mask.
* Even-indexed words: 0->1, odd-indexed words: 1->0.
* Reject non-programmable requests and log conflicts.
- Enable unaligned accesses in MemoryRegionOps.
Since each OTP address maps to a 1DW (4B) or 2DW (8B) block in the
backing store, upper-layer accesses may be unaligned to block
boundaries.

This matches the irreversible, word-parity-dependent programming rules
of Aspeed SoCs and exposes changes via QEMU trace events.

Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250812094011.2617526-6-kane_chen@aspeedtech.com
[ clg: Fixed PRIx64 format in aspeed_otp_write() ]
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...


# c79e29ef 12-Aug-2025 Kane-Chen-AS <kane_chen@aspeedtech.com>

hw/nvram/aspeed_otp: Add 'drive' property to support block backend

This patch introduces a 'drive' property to the Aspeed OTP device,
allowing it to be backed by a block device. Users can now preloa

hw/nvram/aspeed_otp: Add 'drive' property to support block backend

This patch introduces a 'drive' property to the Aspeed OTP device,
allowing it to be backed by a block device. Users can now preload
OTP data via QEMU CLI using a block backend.

Example usage:
./qemu-system-arm \
-blockdev driver=file,filename=otpmem.img,node-name=otp \
-global aspeed-otp.drive=otp \
...

If the drive is provided, its content will be loaded as the initial OTP
state. Otherwise, an internal memory buffer will be used.

Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250812094011.2617526-5-kane_chen@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...


# 12ef88d8 12-Aug-2025 Kane-Chen-AS <kane_chen@aspeedtech.com>

hw/nvram/aspeed_otp: Add ASPEED OTP memory device model

Introduce a QEMU device model for ASPEED's One-Time Programmable (OTP)
memory.

This model simulates a word-addressable OTP region used for se

hw/nvram/aspeed_otp: Add ASPEED OTP memory device model

Introduce a QEMU device model for ASPEED's One-Time Programmable (OTP)
memory.

This model simulates a word-addressable OTP region used for secure
fuse storage. The OTP memory can operate with an internal memory
buffer.

The OTP model provides a memory-like interface through a dedicated
AddressSpace, allowing other device models (e.g., SBC) to issue
transactions as if accessing a memory-mapped region.

Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250812094011.2617526-2-kane_chen@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...