Attention is currently required from: Angel Pons, Christian Walter, Lean Sheng Tan, Leon Groß, Nico Huber, Patrick Rudolph, Paul Menzel.
Benjamin Doron has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/77905?usp=email )
Change subject: mb/emulation: Add SIMICS QSP support ......................................................................
Patch Set 15:
(2 comments)
Commit Message:
https://review.coreboot.org/c/coreboot/+/77905/comment/cb3f1f40_bf738173 : PS9, Line 20:
Sorry for the confusion. […]
Intel provides some documentation as part of the Slim Bootloader project: https://slimbootloader.github.io/supported-hardware/qsp.html
The short of it is: download and install the public release, open the GUI and start a .simics script file.
Note: I do not recommend running "firststeps.simics". As part of 'improving the user experience,' or something like that, they suppress Simics messages. These sometimes tell you which registers are unimplemented. I can potentially provide the script I use, but I don't have Simics installed at this time, and I haven't memorised the paths.
Patchset:
PS4: Sheng, I think it's important to distinguish between Simics Base, the backend (provides general device modelling, an instruction interpreter and JIT compiler), only needing some architecture-specific code to enable a fast simulator, and Simics QSP, a specific board model. I agree that Simics Base is - as far as I know - an industry standard simulator used both internally and externally, but here we have to think of Simics QSP. Simics QSP is not as capable/accurate a model as others.
(For instance, to my knowledge, SeaBIOS is unsupported because the model doesn't emulate/simulate the PAM registers. If they would be added, it would become more capable.)
That said, this board port is fairly self-contained, and Simics is a good development environment, in my option. To those familiar with it, it would be nice to work on coreboot in it. I agree it would be nice to get this into the official public release. That would also help the case for implementing more chipset support to the model, if anyone there is open to that.
This sounds really nice. Why not start with that? If the binary is
accepted, let's maintain it upstream?
Can we work on this?