[OE-core] 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
========================================================================