TUNE_PKGARCH for Microblaze

TUNE_PKGARCH for Microblaze

[Sipke Vriend]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

Hi all,



We are seeking some feedback regarding common practices for defining TUNE_PKGARCH within Yocto.



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.

-------------------



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


[-- Attachment #2: Type: text/html, Size: 12673 bytes --]

Re: TUNE_PKGARCH for Microblaze

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]


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


[-- Attachment #2: Type: text/html, Size: 15466 bytes --]

Re: TUNE_PKGARCH for Microblaze

[Sipke Vriend]

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

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

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

Re: TUNE_PKGARCH for Microblaze

[Mark Hatle]

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
>

Re: TUNE_PKGARCH for Microblaze

[Sipke Vriend]

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@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
>>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
>
>