From: Kane-Chen-AS <kane_chen@aspeedtech.com>

This patch series introduces a QEMU model for the ASPEED OTP (One-Time
Programmable) memory, along with its integration into the Secure Boot
Controller (SBC) and supported SoCs (AST2600, AST1030).

The OTP model emulates a simple fuse array used for secure boot or
device configuration, with support for both file-backed content and
internal fallback buffers. It exposes an AddressSpace to support
transaction-based access from controllers like the SBC.

This series includes:
  - OTP memory device implementation
  - SBC integration with command decoding (READ/PROG)
  - Machine property wiring (via "otpmem" alias)
  - A functional test suite covering various initialization paths

**[RFC notice]**
This is an RFC submission. While the OTP model itself is mostly
complete, this version is primarily intended to gather feedback on the
device initialization flow-specifically how the OTP instance is created,
connected, and exposed via machine properties. Any comment on QOM 
integration style, late binding via notifier, and fallback behavior are
welcome.

In particular, I am seeking input on:
  - Whether the current notifier-based connection from SBC to OTP is
    appropriate, or if there is a preferred QOM idiom for linking
    peripheral devices post-realize.
  - The use of "optmem" as a drive alias and machine parameter handling.

A more finalized version with any requested changes, documentation,
and test refinements will follow after review.

Example usage:
```bash
qemu-system-arm -machine ast2600-evb,otpmem=otpmem-drive \
  -blockdev driver=file,filename=otpmem.img,node-name=otpmem \
  -device aspeed.otpmem,drive=otpmem,id=otpmem-drive \
  ...
```

Any feedback or suggestions are appreciated!

Thanks,
Kane

---

ChangeLog
---------
v5:
- Switched to notifier-based late binding between SBC and OTP
- Exposed 'otpmem' as a machine parameter using QOM alias mechanism
- Added fallback support when no backend is provided
- Introduced functional test suite covering multiple init configurations
- Submitted as [RFC] to gather feedback on QOM integration approach

v4:
- Replaces blockdev backend with memory-mapped AddressSpace access
- Switches from `-drive` CLI option to `otpmem` machine parameter
- Restructures the OTP device under the SBC in the QOM tree

v3:
- Minor fixes and refinements on top of v2 content

v2:
- Separated the OTP memory into a standalone QEMU device (`aspeed.otpmem`)
- Replaced ad-hoc file handling with standard `-drive` backend integration
- Linked OTP to SBC via QOM property for cleaner abstraction
- Improved memory bounds checking and irreversible programming logic

v1:
- Embedded OTP logic in the SBC model and created the backing file internally.

---

Kane-Chen-AS (4):
  hw/misc/aspeed_otp: Add ASPEED OTP memory device model
  hw/misc/aspeed_sbc: Connect ASPEED OTP memory device to SBC
  hw/arm: Integrate ASPEED OTP memory support into AST10x0 and AST2600
    SoCs
  tests/functional: Add integration tests for ASPEED OTP memory model

 hw/arm/aspeed.c                        |  20 +++
 hw/arm/aspeed_ast10x0.c                |   2 +-
 hw/arm/aspeed_ast2600.c                |   2 +-
 hw/misc/aspeed_otpmem.c                | 117 ++++++++++++++++
 hw/misc/aspeed_sbc.c                   | 179 +++++++++++++++++++++++++
 hw/misc/meson.build                    |   1 +
 hw/misc/trace-events                   |   7 +
 include/hw/misc/aspeed_otpmem.h        |  35 +++++
 include/hw/misc/aspeed_sbc.h           |   8 ++
 tests/functional/meson.build           |   1 +
 tests/functional/test_aspeed_otpmem.py |  82 +++++++++++
 11 files changed, 452 insertions(+), 2 deletions(-)
 create mode 100644 hw/misc/aspeed_otpmem.c
 create mode 100644 include/hw/misc/aspeed_otpmem.h
 create mode 100644 tests/functional/test_aspeed_otpmem.py

-- 
2.43.0

Hello Kane,

On 6/19/25 08:41, Kane Chen wrote:
> From: Kane-Chen-AS <kane_chen@aspeedtech.com>
> 
> This patch series introduces a QEMU model for the ASPEED OTP (One-Time
> Programmable) memory, along with its integration into the Secure Boot
> Controller (SBC) and supported SoCs (AST2600, AST1030).
> 
> The OTP model emulates a simple fuse array used for secure boot or
> device configuration, with support for both file-backed content and
> internal fallback buffers. It exposes an AddressSpace to support
> transaction-based access from controllers like the SBC.
> 
> This series includes:
>    - OTP memory device implementation
>    - SBC integration with command decoding (READ/PROG)
>    - Machine property wiring (via "otpmem" alias)
>    - A functional test suite covering various initialization paths
> 
> **[RFC notice]**
> This is an RFC submission. While the OTP model itself is mostly
> complete, this version is primarily intended to gather feedback on the
> device initialization flow-specifically how the OTP instance is created,
> connected, and exposed via machine properties. Any comment on QOM
> integration style, late binding via notifier, and fallback behavior are
> welcome.
> 
> In particular, I am seeking input on:
>    - Whether the current notifier-based connection from SBC to OTP is
>      appropriate, or if there is a preferred QOM idiom for linking
>      peripheral devices post-realize.
>    - The use of "optmem" as a drive alias and machine parameter handling.
> 
> A more finalized version with any requested changes, documentation,
> and test refinements will follow after review.
> 
> Example usage:
> ```bash
> qemu-system-arm -machine ast2600-evb,otpmem=otpmem-drive \
>    -blockdev driver=file,filename=otpmem.img,node-name=otpmem \
>    -device aspeed.otpmem,drive=otpmem,id=otpmem-drive \
>    ...
> ```
> 
> Any feedback or suggestions are appreciated!
> 
> Thanks,
> Kane
> 
> ---
> 
> ChangeLog
> ---------
> v5:
> - Switched to notifier-based late binding between SBC and OTP
> - Exposed 'otpmem' as a machine parameter using QOM alias mechanism
> - Added fallback support when no backend is provided
> - Introduced functional test suite covering multiple init configurations
> - Submitted as [RFC] to gather feedback on QOM integration approach
> 
> v4:
> - Replaces blockdev backend with memory-mapped AddressSpace access
> - Switches from `-drive` CLI option to `otpmem` machine parameter
> - Restructures the OTP device under the SBC in the QOM tree
> 
> v3:
> - Minor fixes and refinements on top of v2 content
> 
> v2:
> - Separated the OTP memory into a standalone QEMU device (`aspeed.otpmem`)
> - Replaced ad-hoc file handling with standard `-drive` backend integration
> - Linked OTP to SBC via QOM property for cleaner abstraction
> - Improved memory bounds checking and irreversible programming logic
> 
> v1:
> - Embedded OTP logic in the SBC model and created the backing file internally.
> 
> ---
> 
> Kane-Chen-AS (4):
>    hw/misc/aspeed_otp: Add ASPEED OTP memory device model
>    hw/misc/aspeed_sbc: Connect ASPEED OTP memory device to SBC
>    hw/arm: Integrate ASPEED OTP memory support into AST10x0 and AST2600
>      SoCs
>    tests/functional: Add integration tests for ASPEED OTP memory model
> 
>   hw/arm/aspeed.c                        |  20 +++
>   hw/arm/aspeed_ast10x0.c                |   2 +-
>   hw/arm/aspeed_ast2600.c                |   2 +-
>   hw/misc/aspeed_otpmem.c                | 117 ++++++++++++++++
>   hw/misc/aspeed_sbc.c                   | 179 +++++++++++++++++++++++++
>   hw/misc/meson.build                    |   1 +
>   hw/misc/trace-events                   |   7 +
>   include/hw/misc/aspeed_otpmem.h        |  35 +++++
>   include/hw/misc/aspeed_sbc.h           |   8 ++
>   tests/functional/meson.build           |   1 +
>   tests/functional/test_aspeed_otpmem.py |  82 +++++++++++
>   11 files changed, 452 insertions(+), 2 deletions(-)
>   create mode 100644 hw/misc/aspeed_otpmem.c
>   create mode 100644 include/hw/misc/aspeed_otpmem.h
>   create mode 100644 tests/functional/test_aspeed_otpmem.py
> 

I would like to see first a proposal without a BlockBackend and
without an 'optmem' machine property. Please rework the series
accordingly.

Thanks,

C.

Hi Cédric,

Sure, I will submit a follow-up patch that includes the following changes:

1. Introduce a new OTP memory device model, which provides in-memory storage and implements basic MMIO read/write via address space.
2. Initialize the OTP memory device as a child of the SBC controller.
3. Add command handling logic in the SBC to operate on the OTP memory, supporting both read and program operations.
4. Introduce TYPE_ASPEED_AST2600_SBC to support OTP memory attachment via the SBC class attribute in the AST2600 SoC.
5. Add trace events to facilitate debugging and tracing of OTP memory operations.

As requested, the BlockBackend integration, the otpmem machine property, and the related alias handling will be removed.
Please let me know if there is anything else that should be adjusted.

Best regards,
Kane
> -----Original Message-----
> From: Cédric Le Goater <clg@kaod.org>
> Sent: Friday, June 20, 2025 1:44 PM
> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy
> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew
> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>;
> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
> here <qemu-devel@nongnu.org>
> Cc: Troy Lee <troy_lee@aspeedtech.com>
> Subject: Re: [RFC v5 0/4] Add QEMU model for ASPEED OTP memory and
> integrate with SoCs
> 
> Hello Kane,
> 
> On 6/19/25 08:41, Kane Chen wrote:
> > From: Kane-Chen-AS <kane_chen@aspeedtech.com>
> >
> > This patch series introduces a QEMU model for the ASPEED OTP (One-Time
> > Programmable) memory, along with its integration into the Secure Boot
> > Controller (SBC) and supported SoCs (AST2600, AST1030).
> >
> > The OTP model emulates a simple fuse array used for secure boot or
> > device configuration, with support for both file-backed content and
> > internal fallback buffers. It exposes an AddressSpace to support
> > transaction-based access from controllers like the SBC.
> >
> > This series includes:
> >    - OTP memory device implementation
> >    - SBC integration with command decoding (READ/PROG)
> >    - Machine property wiring (via "otpmem" alias)
> >    - A functional test suite covering various initialization paths
> >
> > **[RFC notice]**
> > This is an RFC submission. While the OTP model itself is mostly
> > complete, this version is primarily intended to gather feedback on the
> > device initialization flow-specifically how the OTP instance is
> > created, connected, and exposed via machine properties. Any comment on
> > QOM integration style, late binding via notifier, and fallback
> > behavior are welcome.
> >
> > In particular, I am seeking input on:
> >    - Whether the current notifier-based connection from SBC to OTP is
> >      appropriate, or if there is a preferred QOM idiom for linking
> >      peripheral devices post-realize.
> >    - The use of "optmem" as a drive alias and machine parameter handling.
> >
> > A more finalized version with any requested changes, documentation,
> > and test refinements will follow after review.
> >
> > Example usage:
> > ```bash
> > qemu-system-arm -machine ast2600-evb,otpmem=otpmem-drive \
> >    -blockdev driver=file,filename=otpmem.img,node-name=otpmem \
> >    -device aspeed.otpmem,drive=otpmem,id=otpmem-drive \
> >    ...
> > ```
> >
> > Any feedback or suggestions are appreciated!
> >
> > Thanks,
> > Kane
> >
> > ---
> >
> > ChangeLog
> > ---------
> > v5:
> > - Switched to notifier-based late binding between SBC and OTP
> > - Exposed 'otpmem' as a machine parameter using QOM alias mechanism
> > - Added fallback support when no backend is provided
> > - Introduced functional test suite covering multiple init
> > configurations
> > - Submitted as [RFC] to gather feedback on QOM integration approach
> >
> > v4:
> > - Replaces blockdev backend with memory-mapped AddressSpace access
> > - Switches from `-drive` CLI option to `otpmem` machine parameter
> > - Restructures the OTP device under the SBC in the QOM tree
> >
> > v3:
> > - Minor fixes and refinements on top of v2 content
> >
> > v2:
> > - Separated the OTP memory into a standalone QEMU device
> > (`aspeed.otpmem`)
> > - Replaced ad-hoc file handling with standard `-drive` backend
> > integration
> > - Linked OTP to SBC via QOM property for cleaner abstraction
> > - Improved memory bounds checking and irreversible programming logic
> >
> > v1:
> > - Embedded OTP logic in the SBC model and created the backing file
> internally.
> >
> > ---
> >
> > Kane-Chen-AS (4):
> >    hw/misc/aspeed_otp: Add ASPEED OTP memory device model
> >    hw/misc/aspeed_sbc: Connect ASPEED OTP memory device to SBC
> >    hw/arm: Integrate ASPEED OTP memory support into AST10x0 and
> AST2600
> >      SoCs
> >    tests/functional: Add integration tests for ASPEED OTP memory model
> >
> >   hw/arm/aspeed.c                        |  20 +++
> >   hw/arm/aspeed_ast10x0.c                |   2 +-
> >   hw/arm/aspeed_ast2600.c                |   2 +-
> >   hw/misc/aspeed_otpmem.c                | 117
> ++++++++++++++++
> >   hw/misc/aspeed_sbc.c                   | 179
> +++++++++++++++++++++++++
> >   hw/misc/meson.build                    |   1 +
> >   hw/misc/trace-events                   |   7 +
> >   include/hw/misc/aspeed_otpmem.h        |  35 +++++
> >   include/hw/misc/aspeed_sbc.h           |   8 ++
> >   tests/functional/meson.build           |   1 +
> >   tests/functional/test_aspeed_otpmem.py |  82 +++++++++++
> >   11 files changed, 452 insertions(+), 2 deletions(-)
> >   create mode 100644 hw/misc/aspeed_otpmem.c
> >   create mode 100644 include/hw/misc/aspeed_otpmem.h
> >   create mode 100644 tests/functional/test_aspeed_otpmem.py
> >
> 
> I would like to see first a proposal without a BlockBackend and without an
> 'optmem' machine property. Please rework the series accordingly.
> 
> Thanks,
> 
> C.
> 
> 
> 
> 

Hello Kane,

On 6/23/25 05:23, Kane Chen wrote:
> Hi Cédric,
> 
> Sure, I will submit a follow-up patch that includes the following changes:
> 
> 1. Introduce a new OTP memory device model, which provides in-memory storage and implements basic MMIO read/write via address space.
> 2. Initialize the OTP memory device as a child of the SBC controller.
> 3. Add command handling logic in the SBC to operate on the OTP memory, supporting both read and program operations.
> 4. Introduce TYPE_ASPEED_AST2600_SBC to support OTP memory attachment via the SBC class attribute in the AST2600 SoC.
> 5. Add trace events to facilitate debugging and tracing of OTP memory operations.
> 
> As requested, the BlockBackend integration, the otpmem machine property, and the related alias handling will be removed.
> Please let me know if there is anything else that should be adjusted.


Looks good.

Then, we will re-introduce the BlockBackend and last, the 'otpmem'
machine property.

Thanks,

C.