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