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 SoC (AST2600).

The OTP model emulates a simple fuse array used for secure boot or
device configuration, implemented with internal buffers; external
file/device support not included in this version. 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)
  - Direct integration in AST2600 SoC without requiring user parameters

Any feedback or suggestions are appreciated!

Kane
---

ChangeLog
---------
v2:
- Rename device from 'aspeed_otpmem' to 'aspeed_otp' and move it to hw/nvram/
- Move OTP device realization from instance_init to the realize function
- Improve error logging with qemu_log_mask() and remove unused error propagation

v1:
- Initial version

---

Kane-Chen-AS (3):
  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 AST2600 SoCs

 include/hw/misc/aspeed_sbc.h  |   5 ++
 include/hw/nvram/aspeed_otp.h |  30 +++++++++
 hw/arm/aspeed_ast2600.c       |   2 +-
 hw/misc/aspeed_sbc.c          | 119 ++++++++++++++++++++++++++++++++++
 hw/nvram/aspeed_otp.c         |  94 +++++++++++++++++++++++++++
 hw/misc/trace-events          |   5 ++
 hw/nvram/meson.build          |   4 ++
 7 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 include/hw/nvram/aspeed_otp.h
 create mode 100644 hw/nvram/aspeed_otp.c

-- 
2.43.0

On 6/27/25 04:56, 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 SoC (AST2600).
> 
> The OTP model emulates a simple fuse array used for secure boot or
> device configuration, implemented with internal buffers; external
> file/device support not included in this version. 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)
>    - Direct integration in AST2600 SoC without requiring user parameters
> 
> Any feedback or suggestions are appreciated!
> 
> Kane
> ---
> 
> ChangeLog
> ---------
> v2:
> - Rename device from 'aspeed_otpmem' to 'aspeed_otp' and move it to hw/nvram/
> - Move OTP device realization from instance_init to the realize function
> - Improve error logging with qemu_log_mask() and remove unused error propagation


v2 looks OK with the fix I asked on patch 2.

In the next round, could you please include a patch re-adding
a drive property and a block backend in AspeedOTPState ?

Last, we should work on linking the drive to a machine option
but first, let's add the drive.


Thanks,

C.




> 
> v1:
> - Initial version
> 
> ---
> 
> Kane-Chen-AS (3):
>    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 AST2600 SoCs
> 
>   include/hw/misc/aspeed_sbc.h  |   5 ++
>   include/hw/nvram/aspeed_otp.h |  30 +++++++++
>   hw/arm/aspeed_ast2600.c       |   2 +-
>   hw/misc/aspeed_sbc.c          | 119 ++++++++++++++++++++++++++++++++++
>   hw/nvram/aspeed_otp.c         |  94 +++++++++++++++++++++++++++
>   hw/misc/trace-events          |   5 ++
>   hw/nvram/meson.build          |   4 ++
>   7 files changed, 258 insertions(+), 1 deletion(-)
>   create mode 100644 include/hw/nvram/aspeed_otp.h
>   create mode 100644 hw/nvram/aspeed_otp.c
>

Hi Cédric,

Thanks for your reviewing and comments.

Regarding the drive property and block backend, my understanding is that the following changes would be required:

1. Add a BlockBackend field in AspeedOTPState
2. Register a drive property to associate the backend with the device
3. Launch QEMU using command-line options like:
   -blockdev driver=file,filename=otpmem.img,node-name=otp \
   -device aspeed.otp,drive=otp,id=otp-drive,size=16384 \

I have a question related to this setup. When using the -blockdev and -device options as above, QEMU will instantiate a standalone aspeed.otp device based on the command line. At the same time, our current implementation also creates an aspeed.otp object internally as a child of the SBC. As a result, two separate OTP devices exist in the QOM tree.

For example, based on info qom-tree, the hierarchy looks like this:
The OTP device instantiated via command-line options:
/machine (ast2600-evb-machine)
  /peripheral (container)
    /otp-drive (aspeed.otp)
      /aspeed.otp[0] (memory-region)

The OTP device instantiated from within the SBC:
    /sbc (aspeed.sbc-ast2600)
      /aspeed.sbc[0] (memory-region)
      /otp (aspeed.otp)
        /aspeed.otp[0] (memory-region)

In an earlier revision, I used a pointer like AspeedOTPState *otp along with qemu_add_machine_init_done_notifier() to locate and reuse the command-line–instantiated object, based on the assumption that there should be only one OTP instance. However, I realize this may not be a reliable approach and could lead to unexpected confusion or inconsistencies.

Given this, I would appreciate your advice on the proper way to handle this situation. Specifically, should we avoid creating the OTP device inside the SBC and rely entirely on the external device instance? Or would it be acceptable to instantiate it internally and avoid exposing it via -device?

Thanks again for your time and feedback.

Best Regards,
Kane
> -----Original Message-----
> From: Cédric Le Goater <clg@kaod.org>
> Sent: Friday, June 27, 2025 2:52 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: [PATCH v2 0/3] Add QEMU model for ASPEED OTP memory and
> integrate with SoC
> 
> On 6/27/25 04:56, 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 SoC (AST2600).
> >
> > The OTP model emulates a simple fuse array used for secure boot or
> > device configuration, implemented with internal buffers; external
> > file/device support not included in this version. 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)
> >    - Direct integration in AST2600 SoC without requiring user
> > parameters
> >
> > Any feedback or suggestions are appreciated!
> >
> > Kane
> > ---
> >
> > ChangeLog
> > ---------
> > v2:
> > - Rename device from 'aspeed_otpmem' to 'aspeed_otp' and move it to
> > hw/nvram/
> > - Move OTP device realization from instance_init to the realize
> > function
> > - Improve error logging with qemu_log_mask() and remove unused error
> > propagation
> 
> 
> v2 looks OK with the fix I asked on patch 2.
> 
> In the next round, could you please include a patch re-adding a drive property
> and a block backend in AspeedOTPState ?
> 
> Last, we should work on linking the drive to a machine option but first, let's
> add the drive.
> 
> 
> Thanks,
> 
> C.
> 
> 
> 
> 
> >
> > v1:
> > - Initial version
> >
> > ---
> >
> > Kane-Chen-AS (3):
> >    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 AST2600 SoCs
> >
> >   include/hw/misc/aspeed_sbc.h  |   5 ++
> >   include/hw/nvram/aspeed_otp.h |  30 +++++++++
> >   hw/arm/aspeed_ast2600.c       |   2 +-
> >   hw/misc/aspeed_sbc.c          | 119
> ++++++++++++++++++++++++++++++++++
> >   hw/nvram/aspeed_otp.c         |  94
> +++++++++++++++++++++++++++
> >   hw/misc/trace-events          |   5 ++
> >   hw/nvram/meson.build          |   4 ++
> >   7 files changed, 258 insertions(+), 1 deletion(-)
> >   create mode 100644 include/hw/nvram/aspeed_otp.h
> >   create mode 100644 hw/nvram/aspeed_otp.c
> >

On 6/27/25 11:09, Kane Chen wrote:
> Hi Cédric,
> 
> Thanks for your reviewing and comments.
> 
> Regarding the drive property and block backend, my understanding is that the following changes would be required:
> 
> 1. Add a BlockBackend field in AspeedOTPState
> 2. Register a drive property to associate the backend with the device

Let's do 1. and 2. first.

The rest has been discussed already in previous emails.
Please go through them.

Thanks,

C.