Hi Peter, Thanks for your suggestion.
Yes, I did review the existing devices under `hw/nvram/`, including `bcm2835_otp.c`, `npcm7xx_otp.c`, and others. However, I encountered two main challenges: 1. Lack of file backend support 2. Inability to support one-time programming behavior from 1 -> 0 as well as 0 -> 1 For point 1, it's manageable — some existing devices do support a file backend, or we could introduce a middleware layer to add this functionality if needed. Point 2 is a limitation of the existing mode. Most existing implementations are designed for OTP models that only support 0 -> 1 transitions. Supporting 1 -> 0 one-time programming would require significant modification. Even with a middleware layer, the logic would become quite complex, and the changes might be more intrusive than introducing a new device model. That’s why I decided to implement a new model specifically for the Aspeed OTP device. That said, I did refer to the designs in `hw/nvram/` during development, and Cédric also pointed me to `pnv_pnor.c` and `m25p80.c`, which provided helpful reference points. Please let me know if you have any concerns or further suggestions. Best Regards, Kane > -----Original Message----- > From: Peter Maydell <peter.mayd...@linaro.org> > Sent: Wednesday, June 25, 2025 6:26 PM > To: Kane Chen <kane_c...@aspeedtech.com> > Cc: Cédric Le Goater <c...@kaod.org>; Steven Lee > <steven_...@aspeedtech.com>; Troy Lee <leet...@gmail.com>; Jamin Lin > <jamin_...@aspeedtech.com>; Andrew Jeffery > <and...@codeconstruct.com.au>; Joel Stanley <j...@jms.id.au>; open > list:ASPEED BMCs <qemu-...@nongnu.org>; open list:All patches CC here > <qemu-devel@nongnu.org>; Troy Lee <troy_...@aspeedtech.com> > Subject: Re: [RFC v6 1/3] hw/misc/aspeed_otp: Add ASPEED OTP memory > device model > > On Tue, 24 Jun 2025 at 03:22, Kane Chen <kane_c...@aspeedtech.com> > wrote: > > > > From: Kane-Chen-AS <kane_c...@aspeedtech.com> > > > > 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_c...@aspeedtech.com> > > --- > > hw/misc/aspeed_otpmem.c | 85 > +++++++++++++++++++++++++++++++++ > > hw/misc/meson.build | 1 + > > include/hw/misc/aspeed_otpmem.h | 33 +++++++++++++ > > Our other otp-type devices are in hw/nvram/. > > You should probably look at whether there's any kind of already existing > conventions for these types of devices that this one should follow. (There may > be nothing appropriate, but it's worth a look, so we don't end up with half a > dozen devices that are all fairly similar but all do things in arbitrarily > different > ways.) > > thanks > -- PMM
