[yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

[Andre McCurdy]

On Tue, May 30, 2017 at 6:15 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Tue, May 30, 2017 at 6:52 PM, Alejandro Hernandez
> <alejandro.hernandez at linux.intel.com> wrote:
>> On 05/30/2017 05:32 PM, Andre McCurdy wrote:
>>> On Tue, May 30, 2017 at 1:12 PM, Alejandro Hernandez
>>> <alejandro.hernandez at linux.intel.com> wrote:
>>>>
>>>> Hey Leo,
>>>>
>>>> Nope, this change only applies to qemuARM, the other ARM based BSPs are
>>>> based on > ARMv6
>>>>
>>>> Alejandro
>>>>
>>>>
>>>> On 05/30/2017 02:59 PM, Leonardo Sandoval wrote:
>>>>>
>>>>> Alex,
>>>>>
>>>>> is this change only applies to qemu arm? I wonder if the native arm
>>>>> arch
>>>>> needs a similar series.
>>>>>
>>>>> Leo
>>>>>
>>>>> On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
>>>>>>
>>>>>> The SMP kernel config presents issues on qemuarm because:
>>>>>>
>>>>>> CONFIG_SMP=y
>>>>>> Dependencies Missing:
>>>>>>     - CPU_V6K or CPU_V7:
>>>>>>       These are selected by setting:
>>>>>>       CONFIG_ARCH_MULTI_V7=y
>>>>>>       or
>>>>>>       CONFIG_ARCH_MULTI_V6=y
>>>>>>
>>>>>> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
>>>>>> incompatible with CONFIG_SMP.
>>>
>>> Maybe time to think (again) about updating OE's qemu ARM builds to ARMv7.
>>
>> I believe qemu has deep issues with newer ARMs, and thats why it's been
>> kept like that.
>
> Qemu itself should be fine with the newer ARMs .. but we've just targeted a
> lowest common
> denominator (and simple) ARM arch for this target. Since the primary goal
> isn't testing the ISA or arch
> specifics via qemuarm/qemuarm64 (rather, sanity, base arch support, etc).
>
> That being said, as long as a newer platform/board was chosen that had full
> disk support
> (something that the qemuarma9 lacks), then it is feasible to do an update to
> something
> newer. Alternatively, we could keep the platform the same and update the CPU
> definition .. but
> there's not a huge value in that.

Keeping the existing platform but updating the CPU would have the
advantage that qemuarm could then share binaries and sstate with real
world ARM targets.

It would also be a step towards defining an official "generic ARMv7"
tuning target within OE, which could be used as the default
DEFAULTTUNE for all ARMv7 targets.

> But if we did bring in something newer, we'd have to drop the existing
> qemuarm and document that
> we aren't doing any coverage on the older ARM arches.
>
> Bruce
>