On Sat, Mar 12, 2016 at 10:23 AM, Khem Raj <raj.k...@gmail.com> wrote: > On Sat, Mar 12, 2016 at 8:02 PM, Otavio Salvador > <otavio.salva...@ossystems.com.br> wrote: >> On Sat, Mar 12, 2016 at 8:57 AM, Khem Raj <raj.k...@gmail.com> wrote: >>> On Sat, Mar 12, 2016 at 7:41 PM, Otavio Salvador >>> <otavio.salva...@ossystems.com.br> wrote: >>>> On Fri, Mar 11, 2016 at 9:17 PM, Khem Raj <raj.k...@gmail.com> wrote: >>>>> >>>>>> On Mar 12, 2016, at 12:58 AM, Daniel Dragomir >>>>>> <daniel.drago...@windriver.com> wrote: >>>>>> >>>>>> This patch adds tunes for 32-bit armv8a platforms. The user can select >>>>>> little or big endian, hard or soft float, the vector floating-point >>>>>> instruction set: vfpv4 or fp-armv8 and the thumb, neon, crc and crypto >>>>>> extensions. >>>>> >>>>> This does not feel right to me. Look at how thunderX looks like >>>>> ARMv8 is the time to fix this tune explodes on arm, this patch is not >>>>> helping >>>>> it. >>>>> >>>>> Do we need the hf/neon/vfp/thumb2 variants? >>>> >>>> Do you mean we ought to use hf+neon+thumb2+fp-armv8 for everyone and >>>> just have optional features in and out? >>> >>> something like that yes. Just aarch64 and aarch32 make it simple as that >> >> ARMv8.1a has different semantics, how does we handle this? > > question is do we need to handle this with tunes at all ? > what advantages are we looking for.
I don't know but this was my main design doubt. To be honest, I think hf, neon, thumb2 and fp-armv8 can be default. Crypto and crc seem to be optional and need to be enabled if the core offers it. But those are required for ARMv8.1 SoCs ... AFAIK. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
