[yocto] TUNE_PKGARCH for Microblaze

Sipke Vriend sipke.vriend at xilinx.com
Tue Mar 26 17:45:17 PDT 2013 

Thanks Mark!

That information has been very useful. Looks like some python code will be 
the way we need to go.

>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.

Agreed, we intend to have a 'full' and 'lite' as standard tunes for the user to work 
with and build on as required.

Regards
Sipke


On Wednesday, 27 March 2013 5:19 AM, Mark Hatle wrote:
>
>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 at gmail.com> wrote:
>>>
>>>
>>> On Mar 19, 2013, at 9:08 PM, Sipke Vriend <sipke.vriend at 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 at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>_______________________________________________
>yocto mailing list
>yocto at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
>
>

More information about the yocto mailing list