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.k...@gmail.com> wrote:
>>>
>>>
>>> On Mar 19, 2013, at 9:08 PM, Sipke Vriend <sipke.vri...@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
>>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
>
>
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
