meta-baryon flexibility

meta-baryon flexibility

[Jim Abernathy]

In an effort to explore how independent a layer could be to the 
underlying hardware, I took the meta-baryon NAS layer and got it built 
from master using the n450 BSP.  With that working I decided to replace 
the n450 with sugarbay.  While the n450 can support X11 and sato, it was 
not generated by design in the baryon build.

However, when I changed to sugarbay, the build stops because X11 is 
needed.  To get around this I had to comment out some things in the 
conf/machine/sugarbay.conf file in the BSP.


#XSERVER ?= "${XSERVER_IA32_BASE} \
#           ${XSERVER_IA32_EXT} \
#           ${XSERVER_IA32_I965} \
#           "

#VA_FEATURES ?= "gst-va-intel va-intel"

#MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"

Why didn't I have to do this in the n450??

JIm A

Re: meta-baryon flexibility

[Joshua Lock]

On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote:
> In an effort to explore how independent a layer could be to the 
> underlying hardware, I took the meta-baryon NAS layer and got it built 
> from master using the n450 BSP.  With that working I decided to replace 
> the n450 with sugarbay.  While the n450 can support X11 and sato, it was 
> not generated by design in the baryon build.
> 
> However, when I changed to sugarbay, the build stops because X11 is 
> needed.  To get around this I had to comment out some things in the 
> conf/machine/sugarbay.conf file in the BSP.
> 
> 
> #XSERVER ?= "${XSERVER_IA32_BASE} \
> #           ${XSERVER_IA32_EXT} \
> #           ${XSERVER_IA32_I965} \
> #           "
> 
> #VA_FEATURES ?= "gst-va-intel va-intel"
> 
> #MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
> 
> Why didn't I have to do this in the n450??

The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to
recommend the gst-va-intel and va-intel recipes when building this
machine.

RRECOMMENDS are automatically installed as a dependency (in this case,
of task-machine-base, see task-base.bbclass) but can be removed without
causing the package which pulled it in to be removed (see the Poky
reference manual glossary on *_RRECOMMENDS).

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html

I'd suggest the RRECOMMENDS actually be added at a more granular level
than the machine. Perhaps you could file a bug against the BSP?

Cheers,
Joshua

Re: meta-baryon flexibility

[James Abernathy]

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

On Tue, Jul 17, 2012 at 6:19 PM, Joshua Lock <josh@linux.intel.com> wrote:

>
> On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote:
> > In an effort to explore how independent a layer could be to the
> > underlying hardware, I took the meta-baryon NAS layer and got it built
> > from master using the n450 BSP.  With that working I decided to replace
> > the n450 with sugarbay.  While the n450 can support X11 and sato, it was
> > not generated by design in the baryon build.
> >
> > However, when I changed to sugarbay, the build stops because X11 is
> > needed.  To get around this I had to comment out some things in the
> > conf/machine/sugarbay.conf file in the BSP.
> >
> >
> > #XSERVER ?= "${XSERVER_IA32_BASE} \
> > #           ${XSERVER_IA32_EXT} \
> > #           ${XSERVER_IA32_I965} \
> > #           "
> >
> > #VA_FEATURES ?= "gst-va-intel va-intel"
> >
> > #MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
> >
> > Why didn't I have to do this in the n450??
>
> The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to
> recommend the gst-va-intel and va-intel recipes when building this
> machine.
>
> RRECOMMENDS are automatically installed as a dependency (in this case,
> of task-machine-base, see task-base.bbclass) but can be removed without
> causing the package which pulled it in to be removed (see the Poky
> reference manual glossary on *_RRECOMMENDS).
>
>
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
>
> I'd suggest the RRECOMMENDS actually be added at a more granular level
> than the machine. Perhaps you could file a bug against the BSP?
>
>
So if I understand this, it would be better for one of the image.bb files
that focused on media to include this particular RRECOMMENDS statement.
That way others not interested in media and graphic could still use the BSP
unchanged.

In my case the baryon build would work without modifiying the BSP????

Jim A


> Cheers,
> Joshua
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

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

Re: meta-baryon flexibility

[Joshua Lock]

On 18/07/12 04:40, James Abernathy wrote:
> On Tue, Jul 17, 2012 at 6:19 PM, Joshua Lock <josh@linux.intel.com
> <mailto:josh@linux.intel.com>> wrote:
>
>
>     On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote:
>      > In an effort to explore how independent a layer could be to the
>      > underlying hardware, I took the meta-baryon NAS layer and got it
>     built
>      > from master using the n450 BSP.  With that working I decided to
>     replace
>      > the n450 with sugarbay.  While the n450 can support X11 and sato,
>     it was
>      > not generated by design in the baryon build.
>      >
>      > However, when I changed to sugarbay, the build stops because X11 is
>      > needed.  To get around this I had to comment out some things in the
>      > conf/machine/sugarbay.conf file in the BSP.
>      >
>      >
>      > #XSERVER ?= "${XSERVER_IA32_BASE} \
>      > #           ${XSERVER_IA32_EXT} \
>      > #           ${XSERVER_IA32_I965} \
>      > #           "
>      >
>      > #VA_FEATURES ?= "gst-va-intel va-intel"
>      >
>      > #MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
>      >
>      > Why didn't I have to do this in the n450??
>
>     The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to
>     recommend the gst-va-intel and va-intel recipes when building this
>     machine.
>
>     RRECOMMENDS are automatically installed as a dependency (in this case,
>     of task-machine-base, see task-base.bbclass) but can be removed without
>     causing the package which pulled it in to be removed (see the Poky
>     reference manual glossary on *_RRECOMMENDS).
>
>     http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
>
>     I'd suggest the RRECOMMENDS actually be added at a more granular level
>     than the machine. Perhaps you could file a bug against the BSP?
>
> So if I understand this, it would be better for one of the image.bb
> <http://image.bb> files that focused on media to include this particular
> RRECOMMENDS statement.  That way others not interested in media and
> graphic could still use the BSP unchanged.

Arguably, yes. But (devil's advocate) what about image recipes which 
aren't part of the core? i.e. if you've been using a different board to 
develop a custom image and then switch to using the sugarbay wouldn't 
you want the accelerated video to "just work"?

I'd suggest a possible solution would be to define an opt-in 
IMAGE_FEATURES[1][2] for multimedia which the sugarbay BSP can add these 
recipes to.

Joshua

1. 
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-IMAGE_FEATURES
2. 
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image
-- 
Joshua Lock
         Yocto Project
         Intel Open Source Technology Centre