Hi Cédric, I may have misunderstood the otpmem machine option. Please correct me if I am wrong.
> -----Original Message----- > From: Cédric Le Goater <c...@kaod.org> > Sent: Monday, April 28, 2025 7:01 PM > To: 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> > Cc: Troy Lee <troy_...@aspeedtech.com> > Subject: Re: [PATCH v3 3/3] hw/arm: Integrate Aspeed OTP memory into > AST10x0 and AST2600 SoCs > > Hello, > > > I understand that using a machine option (e.g., -M > > ast2600-evb,otpmem=xxx) to specify the OTP memory drive is similar to > > the modeling used for flash devices in the Q35 machine. However, in > > the real ASPEED hardware, the OTP memory is physically part of the > > Secure Boot Controller (SBC) > > So this argument is a good reason to let the Aspeed SBC model own the > otpmem model and not the SoC. It fits better HW design. > > > and is not designed to be removable or swappable. > > Yes. Then, in that case, you should provide a static array of uin8t_t defined > at > reset, which was my first suggestion. But you said you wanted to be able to > change the initial values. I am bit lost in what you want to achieve. Please > explain. In the HW design, the OTP memory can be used to store the chip ID, secure settings, or the key for secure boot. The initial value I want to set is something like the chip ID, which is a fixed value for each chip and should not change after reset. Therefore, I provided an API to set default values, so that these values can be configured more easily during the SoC or SBC realize stage. > > If you want to be able to change the initial values, you need to take into > account the QEMU user interface in the design. Being able to define the > otpmem backend using a blockdev is better for the long term support. > '-drive' is a poor interface we would like to remove. What would happen if > another device of the machine needed a format=raw drive ? how would the > drives be assigned ? depending on the command line ordering like we do for > mtd drives ? :/ > > Anyhow, wiring the block backend to the device of the machine is Let's first > start by defining the basic model. I will move the backend to use blockdev. I previously thought that -drive internally created a blockdev backend, but I understand now that it also introduces other issues. Thanks for the clarification. > > > Allowing users to > > specify the OTP memory through a machine option might imply otherwise, > > which could be misleading compared to the actual hardware behavior. > I don't understand your point here. Putting the otpmem model under SBC fits > better HW design. Please explain. > > > That said, if maintaining consistency with QEMU’s device modeling > > principles (as done for flash devices) is preferred over strict > > hardware modeling fidelity, I am willing to adjust the implementation > > accordingly. > > QEMU is an emulator. We try to avoid modeling shortcuts, but for usability and > complexity reasons, we sometimes do. > > > > > Could you please confirm if you still prefer following the edk2 flash > > model for OTP memory, despite the slight mismatch with hardware > > behavior? > > AFAIUI, the current proposal is not matching HW. Please explain the mismatch. The Secure Boot Controller (SBC) includes some components like OTP memory, crypto engine, boot controller, and so on. All components within the SBC are fixed and cannot be changed. If we allow an otpmem machine option, it may imply that different types or sizes of OTP memory models are supported, such as: * Different size: -M ast2600-evb,otpmem=otpmem-64k-drive * Different model: -M ast2600-evb,otpmem=flash-drive However, in the real hardware design, there is only one fixed model for the OTP memory. Based on this, I am not sure if introducing an otpmem machine option is appropriate. > Thanks, > > C. > Best Regards, Kane
