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. 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.
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. Thanks, C.
