Re: TUNE_PKGARCH for Microblaze

[Mark Hatle <mark.hatle@windriver.com>]

On 3/26/13 1:12 AM, Sipke Vriend wrote:
> Hi all,
>
> With help from Khem's email we have been able to perform 'some' sanity
> checking against the microblaze architecture.
>
> The TUNECONFLICTS assist us in ensuring conflicting features are flagged during
> the bitbake sanity check, however because Microblaze's features are
> independently configurable, we would like to do some additional 'sanity
> checking'.
>
> Using a hierarchical method of features, like in arm, is not really viable for
> Microblaze, so if there are alternate existing ways we would like to use them
> rather than creating localised bb classes to do this for us.
>
> 1. Is there a way similar to TUNECONFLICTS for "paired" features, i.e. if one
>     feature exists another must also?
>     (Certain microblaze versions must have a set of features if a particular
>     feature is enabled).

The values in the conflicts can be adjusted programatically.  It may be what you 
need in this case.  Use inline python such as:

TUNECONFLICTS[foo] = "${@bb.utils.contains("TUNE_FEATURES", "some_feature", 
"conflict_if_set", "conflict_if_not_set", d)}"

> 2. Is there a way to define that certain features must exist, other than
>     defining multiple machines   (e.g. in endian case we would like to ensure one
>     of them is picked)?

You can add a bit of python code that can again use the contains item.  The code 
may need to be in a custom class though to execute.

python() {
     if <your arch selected>:
         if <no endian selected>:
             bb.fatal("You must select an endian")
}

> 3. Additionally (or instead of 1 and 2) is there a way we can introduce/append a
>     'sanity check' into the bitbake layer model - i.e. inform bitbake to
>     run 'our complex sanity' check?

See above.. it will require a custom class.. you can make your tunes/arch file 
include the class using INHERIT += "your_class.bbclass".

> As a continuation from my last email, the following is a list of possible Microblaze
> architecture features, which can be supplied in the machine and/or local.conf
> file. Lack of  a hardware feature means the soft version is used.
>
> big-endian/little-endian
> vXXX where XXX is a microblaze version (like v830)
> barrel-shift
> multiply-high multiply-low
> pattern-compare
> reorder
> divide-hard
> fpu-hard fpu-hard-extended
>
> Additionally we plan to modify the package name slightly, e.g.
> microblazeel-v840-bs-ml-div-fe-cmp-re
> microblazeel-v830-bs-mh
> microblazeel-v830

I think it's a good idea to have some standard tunes with functionality that is 
reasonable for a testable demo environment.  If the developers want to tailor it 
further, they should be able to either by manually selecting the features or 
creating a custom tune file.

This was the intent when the original tune system was introduced.  There was no 
way we would know every possible combination, so making a way the developer 
could specify it was the best answer we could come up with.  The TUNE_FEATURES 
adds the ability for the compiler and other packages to dynamically switch based 
on whatever the developer has configured.  It can be used for blacklisting code, 
changing optimizations, etc.

--Mark

> Regards
> Sipke
>
>> On Mar 20, 2013, at 4:44 PM, Khem Raj <mailto:raj.khem@gmail.com> wrote:
>>
>>
>> On Mar 19, 2013, at 9:08 PM, Sipke Vriend <sipke.vriend@xilinx.com> wrote:
>>
>>
>> Hi all,
>>
>> We are seeking some feedback regarding common practices for defining TUNE_PKGARCH within Yocto.
>>
>>
>> usually its dictated by architecture, ABI and other processor features. the current tune files have good ways to express the relationships
>> you would translate the below table into set of TUNE_FEATURES and define PACKAGE_EXTRA_ARCHS if you need to express compatibility between different tunes
>>
>> Look at arm tunes they are the best examples of complexity
>>
>>
>> We need to define a unique TUNE_PKGARCH for the possible configuration of Microblaze architecture.
>> Our proposal is short unique string for each HW feature which is enabled in Microblaze.
>>
>> For 'extensive hardware usage' architecture, this would result in something like:
>> mbebv730-bs-mh-div-fb-cmp
>> mbebv840-bs-mh-div-fb-cmp-re
>> mbelv840-bs-ml-div-fe-cmp-re
>> and for architecture with no 'hardware usage':
>> mbebv730
>> mbebv840
>> mbelv840
>>
>> The table below details the unique strings and their relation to compiler and hardware flags, and a couple of versions of Microblaze architecture.
>> (If this table does not show cleanly switch to fixed width font)
>> -------------------
>> String Compiler Flag        Hardware Flag         CPU versions
>>        -mcpu=vX.YY.Z                              v7.30.a v8.40.a
>>
>> mbel   -mlittle-endian      C_ENDIANNESS (LITTLE) -       o
>> mbeb   -mbig-endian         C_ENDIANNESS (BIG)    x       o
>>
>> bs     -mxl-barrel-shift    C_USE_BARREL          o       o
>>
>> ml     -mnoxl-soft-mul      C_USE_HW_MUL (MUL32)  o       o
>> mh     -mxl-multiply-high   C_USE_HW_MUL (MUL64)  o       o
>>
>> div    -mnoxl-soft-div      C_USE_DIV             o       o
>>
>> fb     -mhard-float         C_USE_FPU (BASIC)     o       o
>> fe     -mxl-float-convert   C_USE_FPU (EXTENDED)  o       o
>> fe     -mxl-float-sqrt      C_USE_FPU (EXTENDED)  o       o
>>
>> cmp   -mxl-pattern-compare  C_USE_PCMP_INSTR      o       o
>>
>> re    -mxl-reorder          C_USE_REORDER_INSTR   -       o
>>
>> Where '-' means unavailable 'x' is only option and 'o' is optional.
>> -------------------
>>
>>
>>
>> you can express this with TUNECONFLICTS and TUNEVALID
>>
>> and may be create heirarchy of tune files which builds upon common tunings.
>>
>>
>> Note the table rows have hardware feature 'groupings', which means only one of the strings should be present within the TUNE_PKGARCH. For example the Floating Point Unit hardware feature can be defined by either fb (for basic mode) or fe (for extended mode).
>>
>> Regards
>> Sipke
>>
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>