<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 11:20 AM, Pascal Bach <span dir="ltr"><<a href="mailto:pascal.bach@siemens.com" target="_blank">pascal.bach@siemens.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
> Whatever we replace it with has to be part of linux-yocto and the meta data that is<br>
> carried there, so it can be used for the sanity/smoke test machine for arch arm.<br>
><br>
> As such, it has to be feature compatible (network capabilities, disk boot, etc) with<br>
> the existing arm versatile 926ejs platform<br>
><br>
> There have been newer variants for ages, but since there's been no compelling<br>
> reason to upgrade, I continue to carry the existing platform support along to the<br>
> new kernels. (In fact, I've had a qemuarma9 around for nearly 3 years now, but<br>
> it lacked some disk controller support).<br>
</span>My main motivation is to get valgrind running. This requires at least armv7 to be useful.<br>
Most physical boards are not powerful enough (memory and cpu) to do real work with valgrind.<br>
QEMU would be helpful for that.<br>
<span class="">><br>
> From the kernel point of view, updating the platform doesn't have any big benefits,<br>
> but for userspace it could shake out issues with toolchains and instructions, so<br>
> there is a gain to be had there.<br>
</span>In order to find more bugs there would be multiple qemuarms (qemuarm = armv5, qemuarmv7 = armv7, ...).<br>
Is this what you are suggesting?<br></blockquote><div><br><br></div><div>for oe-core, no. Just one qemuarm is all that we can realistically handle. I was just<br></div><div>saying that from the kernel build/driver point of view, it doesn't really matter which<br></div><div>one we use, as long as there is one. Hence why it is still the versatile.<br><br></div><div>If we update, I'll deprecate the arm versatile 926ejs and switch to a newer qemuarm<br></div><div>variant by default. As long as it meets the minimum standards for the oe-core/autobuilder/<br></div><div>kernel tests, a switch is possible.<br><br></div><div>Bruce<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
> If someone is motivated, I'm happy to help work on an update to the core qemuarm<br>
> platform .. it just has to meet the criteria above.<br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">Pascal<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>