[yocto] TUNE_PKGARCH for Microblaze
Mark Hatle
mark.hatle at windriver.com
Tue Mar 26 12:18:45 PDT 2013
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
>
More information about the yocto
mailing list