<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Thanks for starting this conversation Andrew.  I'll add my thoughts here too. </div>
<div dir="ltr" > </div>
<div dir="ltr" >I think we will eventually get to modeling specific systems.  So we should prepare for that in our architecture.  Nothing wrong with baby steps though.  IBM Power Firmware has found tremendous value in modeling every single server we support since Power6.  They use SIMICS and have a department of head count devoted to modeling systems.  As more systems support the Aspeed BMC based servers there will be more developers asking for simulation support. It is easy to see carving out a developer to support more models.  That only works though if we provide a fertile simple environment. </div>
<div dir="ltr" > </div>
<div dir="ltr" >It is baby steps though and there is nothing wrong with a " <font face="Default Monospace,Courier New,Courier,monospace" size="2" >relaxed accuracy constraints</font> " model for now.  The advances made already has allowed us to use a qemu model that uses the same apps and kernel version as a Palmetto.  Having a road map that slaps on the real Ethernet later seems reasonable. </div>
<div dir="ltr" > </div>
<div dir="ltr" >So in short I think we want to create a build environment that allows for inaccurate systems.  Over time that environment should grow from palmettoish to wedgeish, Zaius and witherspoonish</div>
<div dir="ltr" > </div>
<div dir="ltr" > 
<div><br>Chris Austen<br>POWER Systems Enablement Manager<br>(512) 286-5184 (T/L: 363-5184)
<div> </div>
<div> </div>
<blockquote data-history-content-modified="1" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Andrew Jeffery <andrew@aj.id.au><br>To: OpenBMC <openbmc@lists.ozlabs.org><br>Cc: Patrick Williams <patrick@stwcx.xyz>, Teddy Reed <teddy.reed@gmail.com>, Cédric Le Goater <clg@kaod.org>, Joel Stanley <joel@jms.id.au>, Chris Austen/Austin/IBM@IBMUS<br>Subject: Aims for BMC emulation in qemu<br>Date: Thu, May 19, 2016 1:37 AM<br> 
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >Hey all,<br><br>There's some divide as to whether our qemu machine types should<br>accurately describe the hardware, or whether compromises can be made.<br>We've been at one extreme with the poky vexpress-based qemuarm system,<br>but are progressing towards machine types that are a better reflection<br>of the Aspeed SoCs.<br><br>Cédric, Teddy, Joel and myself have been working on modelling the SoCs'<br>devices but some are more complex than others. For example getting<br>network up and running is desirable, but the the ftgmac100 code that<br>exists[1] has critical bugs and isn't upstream (though we've started<br>fixing it[2][3]). We could use a different NIC (e.g. the Cadence GEM),<br>but this doesn't reflect the hardware.<br><br>So, do we compromise or not, or can we avoid the problem altogether?<br><br>Accuracy of the models is useful for kernel and u-boot development,<br>where you can iterate quickly on your own machine to gain confidence<br>before deploying to hardware (but obviously requires the models to<br>exist).<br><br>Alternatively, compromising on the models can allow us to accelerate<br>userspace development, where some of the hardware details are<br>abstracted. For example, it would be useful to add a network device so<br>the robotframework tests[4] can be run. Depending on what you are<br>testing, you might not care for any hardware details.<br><br>At the moment we have a palmetto-bmc machine type in upstream qemu<br>(2.6.0) which describes the core devices. Maybe the solution is to keep<br>such machine types as an accurate reflection of the hardware, and<br>define others that have relaxed accuracy constraints for different<br>circumstances. I expect we'd be maintaining a fork if we did so, but it<br>would evaporate over time as more models were developed.<br><br>What are your thoughts?<br><br>Andrew<br><br><br>[1] <a href="https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02601.html" target="_blank" >https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02601.html</a><br>[2] <a href="https://github.com/shenki/qemu/tree/ftgmac100" target="_blank" >https://github.com/shenki/qemu/tree/ftgmac100</a><br>[3] <a href="https://github.com/amboar/qemu/tree/ast2400-net-ftgmac100" target="_blank" >https://github.com/amboar/qemu/tree/ast2400-net-ftgmac100</a><br>[4] <a href="https://github.com/mkumatag/openbmc-automation" target="_blank" >https://github.com/mkumatag/openbmc-automation</a></font></div>
<div id="MIMEAttachInfoDiv" style="display:none" title="pgp-signature|signature.asc" > </div></blockquote></div></div></div><BR>