The future of qemuarm

The future of qemuarm

[Pascal Bach]

Hi

I read several discussions about lifting the default qemuarm target to armv7 or higher.
On the mailinglist and on the internet I also found several mentions about machines qemuarmv7 and qemuarma8, but I didn't find any working machine configs for them.

What are the planes here?

Is the goal to increase the default to a higher arm version?

Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?

Regards
Pascal

Re: The future of qemuarm

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On 17 October 2016 at 12:18, Pascal Bach <pascal.bach@siemens.com> wrote:

> I read several discussions about lifting the default qemuarm target to
> armv7 or higher.
> On the mailinglist and on the internet I also found several mentions about
> machines qemuarmv7 and qemuarma8, but I didn't find any working machine
> configs for them.
>
> What are the planes here?
>
> Is the goal to increase the default to a higher arm version?
>
> Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?
>

There is a qemuarm64 in master which is aarch64 based.

Ross

[-- Attachment #2: Type: text/html, Size: 1003 bytes --]

Re: The future of qemuarm

[Pascal Bach]

>
>     Is the goal to increase the default to a higher arm version?
>
>     Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?
>
>
> There is a qemuarm64 in master which is aarch64 based.
>
I'm aware of qemuarm64 but I was more talking about 32-bit arm.

Pascal

Re: The future of qemuarm

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On Mon, Oct 17, 2016 at 7:18 AM, Pascal Bach <pascal.bach@siemens.com>
wrote:

> Hi
>
> I read several discussions about lifting the default qemuarm target to
> armv7 or higher.
> On the mailinglist and on the internet I also found several mentions about
> machines qemuarmv7 and qemuarma8, but I didn't find any working machine
> configs for them.
>
> What are the planes here?
>
> Is the goal to increase the default to a higher arm version?
>
> Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?
>

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).

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.

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.

Cheers,

Bruce


>
> Regards
> Pascal
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

[-- Attachment #2: Type: text/html, Size: 2889 bytes --]

Re: The future of qemuarm

[Pascal Bach]

>
> 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?
>
> 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

Re: The future of qemuarm

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

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

>
> >
> > 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
qemuarm
variant by default. As long as it meets the minimum standards for the
oe-core/autobuilder/
kernel tests, a switch is possible.

Bruce


> >
> > 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"

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

Re: The future of qemuarm

[Aníbal Limón]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]



On 10/17/2016 10:20 AM, Pascal Bach wrote:
> 
>>
>> 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?
>>
>> 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.

I like the idea to have a new version of qemuarm instead of armv5 but
that needs to be considerate in terms of,

Do we aim to support multiple versions of qemuarm?, i'm saying this
because of the comments by Bruce about all the testing and the effort
needed to support another qemuarm variant.

If we only want one version of qemuarm, what version you suggest? and why?.

Finally i like the idea to be able to use valgrind into emulation that
will speed up debugging times.

Cheers,
	alimon

>>
> 
> Pascal
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: The future of qemuarm

[Khem Raj]

On Mon, Oct 17, 2016 at 8:48 AM, Aníbal Limón
<anibal.limon@linux.intel.com> wrote:
>
>
> On 10/17/2016 10:20 AM, Pascal Bach wrote:
>>
>>>
>>> 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?
>>>
>>> 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.
>
> I like the idea to have a new version of qemuarm instead of armv5 but
> that needs to be considerate in terms of,
>
> Do we aim to support multiple versions of qemuarm?, i'm saying this
> because of the comments by Bruce about all the testing and the effort
> needed to support another qemuarm variant.
>
> If we only want one version of qemuarm, what version you suggest? and why?.
>
> Finally i like the idea to be able to use valgrind into emulation that
> will speed up debugging times.

This has been discussed more than once in past and armv5 being the lowest common
denominator for ARM devices always won the battle. It still might be,
however it will
be interesting to know how many folks still require armv5te qemuarm. A
raise of hands
might show interest. meta-linaro does support v7 based qemu here

https://git.linaro.org/openembedded/meta-linaro.git/tree/HEAD:/meta-linaro/conf/machine

should we move this to oe-core, may b discussing it further on
architecture list can yield
better results.

>
> Cheers,
>         alimon
>
>>>
>>
>> Pascal
>>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>