On Mon, Oct 17, 2016 at 11:20 AM, Pascal Bach <pascal.b...@siemens.com>

> >
> > Whatever we replace it with has to be part of linux-yocto and the meta
> data that is
> > carried there, so it can be used for the sanity/smoke test machine for
> arch arm.
> >
> > As such, it has to be feature compatible (network capabilities, disk
> boot, etc) with
> > the existing arm versatile 926ejs platform
> >
> > There have been newer variants for ages, but since there's been no
> compelling
> > reason to upgrade, I continue to carry the existing platform support
> along to the
> > new kernels. (In fact, I've had a qemuarma9 around for nearly 3 years
> now, but
> > it lacked some disk controller support).
> My main motivation is to get valgrind running. This requires at least
> armv7 to be useful.
> Most physical boards are not powerful enough (memory and cpu) to do real
> work with valgrind.
> QEMU would be helpful for that.
> >
> > From the kernel point of view, updating the platform doesn't have any
> big benefits,
> > but for userspace it could shake out issues with toolchains and
> instructions, so
> > there is a gain to be had there.
> In order to find more bugs there would be multiple qemuarms (qemuarm =
> armv5, qemuarmv7 = armv7, ...).
> Is this what you are suggesting?

for oe-core, no. Just one qemuarm is all that we can realistically handle.
I was just
saying that from the kernel build/driver point of view, it doesn't really
matter which
one we use, as long as there is one. Hence why it is still the versatile.

If we update, I'll deprecate the arm versatile 926ejs and switch to a newer
variant by default. As long as it meets the minimum standards for the
kernel tests, a switch is possible.


> >
> > If someone is motivated, I'm happy to help work on an update to the core
> qemuarm
> > platform .. it just has to meet the criteria above.
> >
> Pascal

"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
Openembedded-core mailing list

Reply via email to