On Sat, Mar 12, 2016 at 10:06 PM, Otavio Salvador <[email protected]> wrote: > On Sat, Mar 12, 2016 at 10:23 AM, Khem Raj <[email protected]> wrote: >> On Sat, Mar 12, 2016 at 8:02 PM, Otavio Salvador >> <[email protected]> wrote: >>> On Sat, Mar 12, 2016 at 8:57 AM, Khem Raj <[email protected]> wrote: >>>> On Sat, Mar 12, 2016 at 7:41 PM, Otavio Salvador >>>> <[email protected]> wrote: >>>>> On Fri, Mar 11, 2016 at 9:17 PM, Khem Raj <[email protected]> wrote: >>>>>> >>>>>>> On Mar 12, 2016, at 12:58 AM, Daniel Dragomir >>>>>>> <[email protected]> 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.
exactly, so lets see if crypto and crc can actually we offerred differently via CCARGS instead -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
