tweaking insane.bbclass to handle MIPS SEAD-3?

tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

  students from a class of mine last year are currently playing with a
MIPS SEAD-3:

http://www.mips.com/products/development-kits/mips-sead-3/

and asked for some assistance getting oe/yocto to build for that kit.
they started with the routerstation pro content, and just wanted to
reproduce the same rootfs to run on the SEAD-3 (they would use the
provided u-boot and kernel for now). the biggest issue was changing
the endianness of the build.

  got an email this morning, they have a working rootfs, i asked for
details on everything they had to do, but for now, here's the final
issue they dealt with:

"Attached rootfs created for RS Pro, but with mips32el (little endian
config) and soft floating point. I had to comment out the endianess
check Python code from the insane.bbclass file to get the build to
work."

  so if someone wants to adjust insane.bbclass to recognize and handle
a SEAD-3, go for it. i'll post full details when i get them in case
there was anything else relevant.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Mark Hatle]

On 4/18/13 7:38 AM, Robert P. J. Day wrote:
>
>    students from a class of mine last year are currently playing with a
> MIPS SEAD-3:
>
> http://www.mips.com/products/development-kits/mips-sead-3/
>
> and asked for some assistance getting oe/yocto to build for that kit.
> they started with the routerstation pro content, and just wanted to
> reproduce the same rootfs to run on the SEAD-3 (they would use the
> provided u-boot and kernel for now). the biggest issue was changing
> the endianness of the build.
>
>    got an email this morning, they have a working rootfs, i asked for
> details on everything they had to do, but for now, here's the final
> issue they dealt with:
>
> "Attached rootfs created for RS Pro, but with mips32el (little endian
> config) and soft floating point. I had to comment out the endianess
> check Python code from the insane.bbclass file to get the build to
> work."

I'm interested in what changes are required.  Both mips and mipsel are defined 
in the insane class.  If you define 'mips', but end up building little endian, 
you WILL get errors.  But if the arch is defined as mipsel, then no errors 
should be generated.

If the arch is 'mips32' and 'mips32el' then those are simply not defined at this 
point.  But before defining them, what is the difference between mips and mips32?

(I have no experience with this particular board, so I don't know what the 
actual gcc configuration is for building functional software.)

>    so if someone wants to adjust insane.bbclass to recognize and handle
> a SEAD-3, go for it. i'll post full details when i get them in case
> there was anything else relevant.
>
> rday
>

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

On Thu, 18 Apr 2013, Mark Hatle wrote:

> On 4/18/13 7:38 AM, Robert P. J. Day wrote:
> >
> >    students from a class of mine last year are currently playing
> > with a MIPS SEAD-3:
> >
> > http://www.mips.com/products/development-kits/mips-sead-3/
> >
> > and asked for some assistance getting oe/yocto to build for that
> > kit. they started with the routerstation pro content, and just
> > wanted to reproduce the same rootfs to run on the SEAD-3 (they
> > would use the provided u-boot and kernel for now). the biggest
> > issue was changing the endianness of the build.
> >
> >    got an email this morning, they have a working rootfs, i asked
> > for details on everything they had to do, but for now, here's the
> > final issue they dealt with:
> >
> > "Attached rootfs created for RS Pro, but with mips32el (little
> > endian config) and soft floating point. I had to comment out the
> > endianess check Python code from the insane.bbclass file to get
> > the build to work."
>
> I'm interested in what changes are required.  Both mips and mipsel
> are defined in the insane class.  If you define 'mips', but end up
> building little endian, you WILL get errors.  But if the arch is
> defined as mipsel, then no errors should be generated.
>
> If the arch is 'mips32' and 'mips32el' then those are simply not
> defined at this point.  But before defining them, what is the
> difference between mips and mips32?
>
> (I have no experience with this particular board, so I don't know
> what the actual gcc configuration is for building functional
> software.)

  i'm still waiting to hear back ... do you know *theoretically* what
the recipe should have been? i gave them some initial advice but as
this was the first time i had anything to do with MIPS endianness, it
might have been horrifically bad advice.

  i pointed out the oe-core file "tune-mips32.inc", and the following:

DEFAULTTUNE ?= "mips32"

require conf/machine/include/mips/arch-mips.inc

TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
TUNECONFLICTS[mips32] = "n64 n32"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32",
"-march=mips32", "", d)}"

AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"

  so, off the top of my head, i suggested adding to local.conf:

DEFAULTTUNE := "mips32el"

since that's listed as one of the "AVAILTUNES", but i was just
guessing. from what i heard, that *partly* solved the problem but the
rest of the solution is what you read above.

  i can easily ask them to try a different recipe, they're all set up
to build and test a rootfs. what *would* have been the right approach?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Mark Hatle]

On 4/18/13 9:25 AM, Robert P. J. Day wrote:
> On Thu, 18 Apr 2013, Mark Hatle wrote:
>
>> On 4/18/13 7:38 AM, Robert P. J. Day wrote:
>>>
>>>     students from a class of mine last year are currently playing
>>> with a MIPS SEAD-3:
>>>
>>> http://www.mips.com/products/development-kits/mips-sead-3/
>>>
>>> and asked for some assistance getting oe/yocto to build for that
>>> kit. they started with the routerstation pro content, and just
>>> wanted to reproduce the same rootfs to run on the SEAD-3 (they
>>> would use the provided u-boot and kernel for now). the biggest
>>> issue was changing the endianness of the build.
>>>
>>>     got an email this morning, they have a working rootfs, i asked
>>> for details on everything they had to do, but for now, here's the
>>> final issue they dealt with:
>>>
>>> "Attached rootfs created for RS Pro, but with mips32el (little
>>> endian config) and soft floating point. I had to comment out the
>>> endianess check Python code from the insane.bbclass file to get
>>> the build to work."
>>
>> I'm interested in what changes are required.  Both mips and mipsel
>> are defined in the insane class.  If you define 'mips', but end up
>> building little endian, you WILL get errors.  But if the arch is
>> defined as mipsel, then no errors should be generated.
>>
>> If the arch is 'mips32' and 'mips32el' then those are simply not
>> defined at this point.  But before defining them, what is the
>> difference between mips and mips32?
>>
>> (I have no experience with this particular board, so I don't know
>> what the actual gcc configuration is for building functional
>> software.)
>
>    i'm still waiting to hear back ... do you know *theoretically* what
> the recipe should have been? i gave them some initial advice but as
> this was the first time i had anything to do with MIPS endianness, it
> might have been horrifically bad advice.
>
>    i pointed out the oe-core file "tune-mips32.inc", and the following:
>
> DEFAULTTUNE ?= "mips32"
>
> require conf/machine/include/mips/arch-mips.inc
>
> TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
> TUNECONFLICTS[mips32] = "n64 n32"
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32",
> "-march=mips32", "", d)}"
>
> AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
>
>    so, off the top of my head, i suggested adding to local.conf:
>
> DEFAULTTUNE := "mips32el"

A quick look at master says that that should be fine.  It will result in:

TUNE_FEATURES = "o32 fpu-hard mips32"
BASE_LIB = "lib"
TUNE_ARCH = "mipsel"
TUNE_PKGARCH = "mips32el"
PACKAGE_EXTRA_ARCHS = "mipsel mips32el"

Changing the tune to "mips32el-nf", will result in a mips32 little endian, 
soft-float system.  And there should be no sanity or other failures.

(Note, the difference between 'mips' and 'mips32' is use of -march=mips32.)

> since that's listed as one of the "AVAILTUNES", but i was just
> guessing. from what i heard, that *partly* solved the problem but the
> rest of the solution is what you read above.
>
>    i can easily ask them to try a different recipe, they're all set up
> to build and test a rootfs. what *would* have been the right approach?

If the tuning is set right, then everything else should "just work".  They can 
do the DEFAULTTUNE setting in their local.conf, but it's better to do it in 
their machine.conf file.  (Style vs required.)

They can verify the settings using 'bitbake -e' and looking for the CC flags, 
and other related items to make sure they are right for this system.

> rday
>

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

On Thu, 18 Apr 2013, Mark Hatle wrote:

> On 4/18/13 9:25 AM, Robert P. J. Day wrote:

... snip ...

> > DEFAULTTUNE ?= "mips32"
> >
> > require conf/machine/include/mips/arch-mips.inc
> >
> > TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
> > TUNECONFLICTS[mips32] = "n64 n32"
> > TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32",
> > "-march=mips32", "", d)}"
> >
> > AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
> >
> >    so, off the top of my head, i suggested adding to local.conf:
> >
> > DEFAULTTUNE := "mips32el"
>
> A quick look at master says that that should be fine.  It will result in:
>
> TUNE_FEATURES = "o32 fpu-hard mips32"
> BASE_LIB = "lib"
> TUNE_ARCH = "mipsel"
> TUNE_PKGARCH = "mips32el"
> PACKAGE_EXTRA_ARCHS = "mipsel mips32el"
>
> Changing the tune to "mips32el-nf", will result in a mips32 little
> endian, soft-float system.  And there should be no sanity or other
> failures.
>
> (Note, the difference between 'mips' and 'mips32' is use of -march=mips32.)
>
> > since that's listed as one of the "AVAILTUNES", but i was just
> > guessing. from what i heard, that *partly* solved the problem but
> > the rest of the solution is what you read above.
> >
> >    i can easily ask them to try a different recipe, they're all
> > set up to build and test a rootfs. what *would* have been the
> > right approach?
>
> If the tuning is set right, then everything else should "just work".
> They can do the DEFAULTTUNE setting in their local.conf, but it's
> better to do it in their machine.conf file.  (Style vs required.)
>
> They can verify the settings using 'bitbake -e' and looking for the
> CC flags, and other related items to make sure they are right for
> this system.

  so if i read you correctly, all i need to do is copy the existing
routerstationpro.conf to, say, sead3.conf, and add the single line:

DEFAULTTUNE := "mips32el-nf"         <--- add that
require conf/machine/include/tune-mips32.inc

  that about right? i'll give that a shot right away just to see if it
builds.  can't test it without the kit but building will still be a
useful exercise.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Mark Hatle]

On 4/18/13 10:44 AM, Robert P. J. Day wrote:
> On Thu, 18 Apr 2013, Mark Hatle wrote:
>
>> On 4/18/13 9:25 AM, Robert P. J. Day wrote:
>
> ... snip ...
>
>>> DEFAULTTUNE ?= "mips32"
>>>
>>> require conf/machine/include/mips/arch-mips.inc
>>>
>>> TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
>>> TUNECONFLICTS[mips32] = "n64 n32"
>>> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32",
>>> "-march=mips32", "", d)}"
>>>
>>> AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
>>>
>>>     so, off the top of my head, i suggested adding to local.conf:
>>>
>>> DEFAULTTUNE := "mips32el"
>>
>> A quick look at master says that that should be fine.  It will result in:
>>
>> TUNE_FEATURES = "o32 fpu-hard mips32"
>> BASE_LIB = "lib"
>> TUNE_ARCH = "mipsel"
>> TUNE_PKGARCH = "mips32el"
>> PACKAGE_EXTRA_ARCHS = "mipsel mips32el"
>>
>> Changing the tune to "mips32el-nf", will result in a mips32 little
>> endian, soft-float system.  And there should be no sanity or other
>> failures.
>>
>> (Note, the difference between 'mips' and 'mips32' is use of -march=mips32.)
>>
>>> since that's listed as one of the "AVAILTUNES", but i was just
>>> guessing. from what i heard, that *partly* solved the problem but
>>> the rest of the solution is what you read above.
>>>
>>>     i can easily ask them to try a different recipe, they're all
>>> set up to build and test a rootfs. what *would* have been the
>>> right approach?
>>
>> If the tuning is set right, then everything else should "just work".
>> They can do the DEFAULTTUNE setting in their local.conf, but it's
>> better to do it in their machine.conf file.  (Style vs required.)
>>
>> They can verify the settings using 'bitbake -e' and looking for the
>> CC flags, and other related items to make sure they are right for
>> this system.
>
>    so if i read you correctly, all i need to do is copy the existing
> routerstationpro.conf to, say, sead3.conf, and add the single line:
>
> DEFAULTTUNE := "mips32el-nf"         <--- add that
> require conf/machine/include/tune-mips32.inc
>
>    that about right? i'll give that a shot right away just to see if it
> builds.  can't test it without the kit but building will still be a
> useful exercise.

Yes that should work.

--Mark

> rday
>

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

On Thu, 18 Apr 2013, Mark Hatle wrote:

> On 4/18/13 10:44 AM, Robert P. J. Day wrote:
> >
> >    so if i read you correctly, all i need to do is copy the existing
> > routerstationpro.conf to, say, sead3.conf, and add the single line:
> >
> > DEFAULTTUNE := "mips32el-nf"         <--- add that
> > require conf/machine/include/tune-mips32.inc
> >
> >    that about right? i'll give that a shot right away just to see if it
> > builds.  can't test it without the kit but building will still be a
> > useful exercise.
>
> Yes that should work.

  it's chugging away as we speak, no config warnings. i wonder what my
former students ran into that they *originally* told me the build
wasn't entirely successful. still waiting to hear back but this looks
good, thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

  if one created a BSP for the MIPS SEAD-3, where would it go? i
notice there's no current MIPS-related OE layer anywhere. i'm assuming
http://layers.openembedded.org/layerindex/ is the canonical source
these days for layer locations, yes? the only MIPS match one gets
there is for the qemumips machine.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Paul Eggleton]

On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote:
>   if one created a BSP for the MIPS SEAD-3, where would it go? i
> notice there's no current MIPS-related OE layer anywhere. i'm assuming
> http://layers.openembedded.org/layerindex/ is the canonical source
> these days for layer locations, yes? the only MIPS match one gets
> there is for the qemumips machine.

I guess there isn't one yet, so if you'd like to create and publish one, go 
for it. There's some info on how that should be done in the OE layers FAQ:

http://www.openembedded.org/Layers_FAQ

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Robert P. J. Day]

On Fri, 19 Apr 2013, Paul Eggleton wrote:

> On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote:
> >   if one created a BSP for the MIPS SEAD-3, where would it go? i
> > notice there's no current MIPS-related OE layer anywhere. i'm
> > assuming http://layers.openembedded.org/layerindex/ is the
> > canonical source these days for layer locations, yes? the only
> > MIPS match one gets there is for the qemumips machine.
>
> I guess there isn't one yet, so if you'd like to create and publish
> one, go for it. There's some info on how that should be done in the
> OE layers FAQ:
> http://www.openembedded.org/Layers_FAQ

  short note -- the wiki page "Creating a new Layer":

http://www.openembedded.org/wiki/Creating_a_new_Layer

seems out of date, in that the "Best practices" section refers to
qt4.inc and the QT_SQL_DRIVER_FLAGS variable:

"An example here would be the way Qt 4 database support plugins are
configured - OE-core doesn't have MySQL or PostgreSQL, however meta-oe
does, so meta-oe uses .bbappends to modify a variable
QT_SQL_DRIVER_FLAGS to enable the appropriate plugins. This variable
was added to qt4.inc in OE-core specifically to allow meta-oe to be
able to control which plugins are built."

  i don't think so:

$ git show 64c6887ca19d2ce52e538186c93163dddf68438f
commit 64c6887ca19d2ce52e538186c93163dddf68438f
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date:   Wed Apr 10 15:57:59 2013 +0000

    qt4: remove bbappend content

    These changes to Qt's configuration need to be applied in distro layers,
    not in meta-oe.

    (We have to preserve the PRINC value to avoid PR going backwards.)

    Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

  might want to pick a different example.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: tweaking insane.bbclass to handle MIPS SEAD-3?

[Paul Eggleton]

On Friday 19 April 2013 06:53:59 Robert P. J. Day wrote:
> On Fri, 19 Apr 2013, Paul Eggleton wrote:
> > On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote:
> > >   if one created a BSP for the MIPS SEAD-3, where would it go? i
> > > 
> > > notice there's no current MIPS-related OE layer anywhere. i'm
> > > assuming http://layers.openembedded.org/layerindex/ is the
> > > canonical source these days for layer locations, yes? the only
> > > MIPS match one gets there is for the qemumips machine.
> > 
> > I guess there isn't one yet, so if you'd like to create and publish
> > one, go for it. There's some info on how that should be done in the
> > OE layers FAQ:
> > http://www.openembedded.org/Layers_FAQ
> 
>   short note -- the wiki page "Creating a new Layer":
> 
> http://www.openembedded.org/wiki/Creating_a_new_Layer
> 
> seems out of date, in that the "Best practices" section refers to
> qt4.inc and the QT_SQL_DRIVER_FLAGS variable:
> 
> "An example here would be the way Qt 4 database support plugins are
> configured - OE-core doesn't have MySQL or PostgreSQL, however meta-oe
> does, so meta-oe uses .bbappends to modify a variable
> QT_SQL_DRIVER_FLAGS to enable the appropriate plugins. This variable
> was added to qt4.inc in OE-core specifically to allow meta-oe to be
> able to control which plugins are built."
> 
>   i don't think so:
> 
> $ git show 64c6887ca19d2ce52e538186c93163dddf68438f
> commit 64c6887ca19d2ce52e538186c93163dddf68438f
> Author: Paul Eggleton <paul.eggleton@linux.intel.com>
> Date:   Wed Apr 10 15:57:59 2013 +0000
> 
>     qt4: remove bbappend content
> 
>     These changes to Qt's configuration need to be applied in distro layers,
> not in meta-oe.
> 
>     (We have to preserve the PRINC value to avoid PR going backwards.)
> 
>     Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
>     Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> 
>   might want to pick a different example.

Ah yes, I looked at that recently and made a mental note to change it which I 
then promptly forgot. It's fixed now (using the same example, but mentioning 
where the appends should go), thanks for pointing this out.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre