[OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
Bruce Ashfield
bruce.ashfield at windriver.com
Fri May 15 14:38:19 UTC 2015
On 2015-05-15 03:18 AM, Dmitry Eremin-Solenikov wrote:
> On 05/14/2015 05:37 PM, Bruce Ashfield wrote:
>> On 2015-05-14 09:46 AM, Richard Purdie wrote:
>>> On Wed, 2015-05-13 at 18:17 -0700, Andre McCurdy wrote:
>>>> On Tue, May 12, 2015 at 7:47 AM, Martin Jansa
>>>> <martin.jansa at gmail.com> wrote:
>>>>> On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote:
>>>>>> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov
>>>>>> <dmitry_eremin at mentor.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too
>>>>>>> little to run necessary applications. Add a new arm configuration
>>>>>>> based
>>>>>>> on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of
>>>>>>> RAM.
>>>>>>>
>>>>>>
>>>>>> Not sure I'm keen on oe-core having two almost-identical qemuarm
>>>>>> machines.
>>>>>> Why not just change the qemuarm machine to use the A9?
>>>>>
>>>>> Then we should officially drop thumb1 support, because current qemuarm
>>>>> builds are quite broken when thumb is enabled and dropping current
>>>>> qemuarm or replacing it with A9 variant will prevent oe-core to be
>>>>> testable on autobuilder. See
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
>>>>
>>>> +1 for updating qemuarm to an ARMv7 CPU.
>>>
>>> One thing I did notice about the new proposed arm machine was the lack
>>> of graphics support. We really do need a machine with graphics. If we
>>> could get a machine which had graphics and more memory that would be
>>> much more attractive to switch to.
>>>
>>> This also has implications on the kernel support (cc Bruce).
>>
>> I've been using the qemuarma9 machine in some different contexts for
>> a while now, and in fact, there's a BSP definition in linux-yocto
>> already for it.
>>
>> So from that point of view, the kernel impacts are understood.
>>
>> But not only does the qemuarma9 lack graphics, it also has issues
>> with disk and USB, so generally it isn't as usable as the arm926
>> qemu variant.
>
> I ended up enabling virtio to get disc working in qemuarma9. Such setup
> is used in provided runqemu patches. However I did not include a patch
> to linux-yocto recipe/git tree.
Interesting. That didn't work all that well when I tried, but that was
over a year ago. The solution was to use SD card images here, but they
have limitations as well.
>
>>
>> There are other options that have newer CPUs, or just changing the
>> cpu .. but a wholesale switch to the "qemuarma9" machine tends to
>> bring some new challenges.
>
> Yes, that is why in the patches I proposed qemuarma9 as an alternative
> (rather then a replacement) to plain qemuarm.
Agreed (and I got that part), but my counter argument is that there are
other machines to chose from and it is better to find one that meets all
the needs, versus maintaining two.
Bruce
>
More information about the Openembedded-core
mailing list