Skip to contentSkip to conversation

meta-baryon flexibility

DISCUSSION Jim Abernathy 2 participants 4 messages Jul 17, 2012 – Jul 18, 2012

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 16 lines · 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} \
#           "
Quoted 5 lines

#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

#2 lore raw
Quoted 34 lines · Joshua Lock
Quoted 16 lines · 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} \
#           "
Quoted 5 lines

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

Quoted 6 lines

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

Quoted 9 lines

Cheers,
Joshua

_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

#3 lore raw
Quoted 41 lines · James Abernathy

On Tue, Jul 17, 2012 at 6:19 PM, Joshua Lock <[email protected] <mailto:[email protected]>> 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

Quoted 7 lines

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

Signature · 3 lines
Joshua Lock
        Yocto Project
        Intel Open Source Technology Centre