Hi Cédric/Philippe, OTP (One-Time Programmable) memory is a type of non-volatile memory in which each bit can be programmed only once. It is typically used to store critical and permanent information, such as the chip ID and secure boot keys. The structure and behavior of OTP memory are consistent across both the AST1030 and AST2600 platforms.
As Philippe pointed out, this proposal models the OTP memory as a flash device and utilizes a block backend for persistent storage. In contrast, existing implementations such as NPCM7xxOTPState, BCM2835OTPState, and SiFiveUOTPState expose OTP memory via MMIO and always initialize it in a blank state. The goal of this design is to allow the guest system to boot with a pre-configured OTP memory state. To support this, the OTP memory is backed by a file, simulating persistent flash behavior. The OTP memory access flow is as follows: 1. The guest issues a read or write OTP command to the Secure Boot Controller (SBC) 2. The SBC triggers the corresponding operation in the OTP controller 3. The SBC returns the result to the guest Since the guest interacts with OTP memory exclusively through the SBC, the OTP logic is implemented within aspeed_sbc.c. If there are existing architectural guidelines or design patterns that should be followed for modeling OTP devices, I would greatly appreciate your feedback. I am happy to revise the implementation accordingly and submit updated patches for further review. Thanks for your comments and review. Best Regards, Kane > -----Original Message----- > From: Cédric Le Goater <c...@kaod.org> > Sent: Friday, April 4, 2025 9:54 PM > To: Philippe Mathieu-Daudé <phi...@linaro.org>; Kane Chen > <kane_c...@aspeedtech.com>; Peter Maydell <peter.mayd...@linaro.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>; qemu-block <qemu-bl...@nongnu.org> > Cc: Troy Lee <troy_...@aspeedtech.com> > Subject: Re: [PATCH v1 0/1] hw/misc/aspeed_sbc: Implement OTP memory and > controller > > On 4/4/25 15:00, Philippe Mathieu-Daudé wrote: > > +qemu-block@ > > > > On 4/4/25 14:06, Cédric Le Goater wrote: > >> Hello, > >> > >> On 4/2/25 11:14, Kane-Chen-AS wrote: > >>> This patch introduces part of the Secure Boot Controller device, > >>> which consists of several sub-components, including an OTP memory, > >>> OTP controller, cryptographic engine, and boot controller. > >>> > >>> In this version, the implementation includes the OTP memory and its > >>> controller. The OTP memory can be programmed from within the guest > >>> OS via a software utility. > >> > >> > >> What is the OTP memory ? An external flash device or built-in SRAM ? > >> If the latter, I suggest using an allocated buffer under the SBC > >> model and avoid the complexity of the BlockBackend implementation and > >> the definition of a drive on the command line for it. The proposal is > >> bypassing a lot of QEMU layers for this purpose. > > > > More of the former, a built-in eFuse behaving more like flash. So > > using block backend for the storage seems correct to me. > > How would you define the drive backend on the command line ? > > > However I don't think > > the implementation belongs to hw/misc/aspeed_sbc; ideally we'd have > > some abstract (or interface) implementation in hw/block/otp.c -- with > > methods such program_otp_data() --, completed by hw/block/aspeed_otc.c. > > I was imagining more something like NPCM7xxOTPState or BCM2835OTPState > and not SiFiveUOTPState. > > > Current patch might be good enough to start with IMHO. > > Have you looked at the next patch and how the backend is handled ? > I will let the block people Ack this patch in that case. It's beyond my > skills. > > Thanks, > > C. >
