Building Yocto for Pandaboard

Building Yocto for Pandaboard

[Christian.Schulenberg]

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

Hi,

I'm quite new to the Yocto project, but Yocto seems so to solve a lot of my problems. I'm happy to see, that there is also support from TI for the OMAP. I already managed to build a Beagleboard version and bring some custom applications onto it. For the next days, it's important for me to switch over to Pandaboard (A revisions with OMAP4430) because of it's improved HW and the more powerful OMAP4.

As a starting point, I used the meta-ti layer. Doing so, I already got the first question, because there are two machines defined:

pandaboard and omap4430-panda

Which version is the most recent one? For my first steps I decided to go with the pandaboard configuration. I building core-image-base, because for my tasks, this seems to be the most appropriate one.

I already added to following line to my local.conf:

BBMASK = ".*/meta-ti/recipes-misc/"

which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):

clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632

This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags. Could anyone please give me some advice, how to change the flags first, because this would be the preferred way from my point of view.

I removed the clock initialization from the file, to see how far I can get afterwards. In fact, another problem comes up with ofono (problems with finding python, I guess another versioning problem here). Beside the point, that I don't understand why ofono is part of a base image, I can't find the right place to remove the ofono package from my image. Please, can someone give my some hint who to remove ofono? Using the hob is not a solution, because hob does not support removing packages, or did I miss something?

Please be patient when I'm asking some question, where the answers are obvious for you, but as I mentioned before, I'm new to Yocto and still learning ;-) Maybe, there is someone on this mailing list, who already managed to build Yocto successfully for Panda and who can help me out of my problems or give some further advice.

Thanks,
Christian


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

Re: Building Yocto for Pandaboard

[Koen Kooi]

Op 27 feb. 2012, om 09:26 heeft <Christian.Schulenberg@bmw.de> <Christian.Schulenberg@bmw.de> het volgende geschreven:

> I already added to following line to my local.conf:
>  
> BBMASK = ".*/meta-ti/recipes-misc/"
>  
> which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):
>  
> clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632
>  
> This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags.

Have you read the README in the meta-ti layer yet? That explains how to setup a working environment.

regards,

Koen

Re: Building Yocto for Pandaboard

[Philip Balister]

On 02/27/2012 03:50 AM, Koen Kooi wrote:
> 
> Op 27 feb. 2012, om 09:26 heeft <Christian.Schulenberg@bmw.de> <Christian.Schulenberg@bmw.de> het volgende geschreven:
> 
>> I already added to following line to my local.conf:
>>  
>> BBMASK = ".*/meta-ti/recipes-misc/"
>>  
>> which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):
>>  
>> clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632
>>  
>> This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags.
> 
> Have you read the README in the meta-ti layer yet? That explains how to setup a working environment.

The README contains instructions for building Angstrom, which is not the
right answer for everyone trying to use meta-ti.

Philip

Re: Building Yocto for Pandaboard

[Koen Kooi]

Op 27 feb. 2012, om 17:06 heeft Philip Balister het volgende geschreven:

> On 02/27/2012 03:50 AM, Koen Kooi wrote:
>> 
>> Op 27 feb. 2012, om 09:26 heeft <Christian.Schulenberg@bmw.de> <Christian.Schulenberg@bmw.de> het volgende geschreven:
>> 
>>> I already added to following line to my local.conf:
>>> 
>>> BBMASK = ".*/meta-ti/recipes-misc/"
>>> 
>>> which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):
>>> 
>>> clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632
>>> 
>>> This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags.
>> 
>> Have you read the README in the meta-ti layer yet? That explains how to setup a working environment.
> 
> The README contains instructions for building Angstrom, which is not the
> right answer for everyone trying to use meta-ti.

Since the recipe in question break with gcc 4.6 and/or binutils 2.22 *and* you need SOC_FAMILY in overrides angstrom is the only "out of the box" option. Other routes will involve heavy patching. I agree that needs to be addressed, but it doesn't change the solution *right now*.

And the instructions in the README set things for 'yocto', which is what people are asking for. If they asked for 'poky', that would be a totally different thing.

Re: Building Yocto for Pandaboard

[William Mills]

On 02/27/2012 11:19 AM, Koen Kooi wrote:
> Op 27 feb. 2012, om 17:06 heeft Philip Balister het volgende geschreven:
>
>> On 02/27/2012 03:50 AM, Koen Kooi wrote:
>>> Op 27 feb. 2012, om 09:26 heeft<Christian.Schulenberg@bmw.de>  <Christian.Schulenberg@bmw.de>  het volgende geschreven:
>>>
>>>> I already added to following line to my local.conf:
>>>>
>>>> BBMASK = ".*/meta-ti/recipes-misc/"
>>>>
>>>> which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):
>>>>
>>>> clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632
>>>>
>>>> This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags.
>>> Have you read the README in the meta-ti layer yet? That explains how to setup a working environment.
>> The README contains instructions for building Angstrom, which is not the
>> right answer for everyone trying to use meta-ti.
> Since the recipe in question break with gcc 4.6 and/or binutils 2.22 *and* you need SOC_FAMILY in overrides angstrom is the only "out of the box" option. Other routes will involve heavy patching. I agree that needs to be addressed, but it doesn't change the solution *right now*.
>
> And the instructions in the README set things for 'yocto', which is what people are asking for. If they asked for 'poky', that would be a totally different thing.

Denis or Koen:  Before today is over please modify the README.txt to 
describe where we are going and what is possible right now.  If Angstrom 
is the only thing possible right now it should say that until we can 
build with other layer stacks.  However it should also say that we are 
working toward a solution that will build with multiple layer stacks 
including poky.

Re: Building Yocto for Pandaboard

[Denys Dmytriyenko]

On Mon, Feb 27, 2012 at 12:06:09PM -0500, William Mills wrote:
> >>The README contains instructions for building Angstrom, which is not the
> >>right answer for everyone trying to use meta-ti.
> >Since the recipe in question break with gcc 4.6 and/or binutils 2.22 *and* you need SOC_FAMILY in overrides angstrom is the only "out of the box" option. Other routes will involve heavy patching. I agree that needs to be addressed, but it doesn't change the solution *right now*.
> >
> >And the instructions in the README set things for 'yocto', which is what people are asking for. If they asked for 'poky', that would be a totally different thing.
> 
> Denis or Koen:  Before today is over please modify the README.txt to
> describe where we are going and what is possible right now.  If
> Angstrom is the only thing possible right now it should say that
> until we can build with other layer stacks.  However it should also
> say that we are working toward a solution that will build with
> multiple layer stacks including poky.

Sure, will do.

-- 
Denys

Re: Building Yocto for Pandaboard

[Christian.Schulenberg]

Thanks a lot for your replies. Angstrom is definitely not the way I want to go at the moment, because I prefer to have a clean architecture in my project. So I have to wait, until the meta-ti layer is fixed to work with Poky without any dependencies to angstrom. Do you have any idea, how long this can take?

May be, in the meantime I try to fix some problems on my own to get Pandaboard working, because I really need to set up this device as a prototyping unit.

BR,
Christian

-----Ursprüngliche Nachricht-----
Von: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] Im Auftrag von William Mills
Gesendet: Montag, 27. Februar 2012 18:06
An: Koen Kooi
Cc: meta-ti@yoctoproject.org
Betreff: Re: [meta-ti] Building Yocto for Pandaboard



On 02/27/2012 11:19 AM, Koen Kooi wrote:
> Op 27 feb. 2012, om 17:06 heeft Philip Balister het volgende geschreven:
>
>> On 02/27/2012 03:50 AM, Koen Kooi wrote:
>>> Op 27 feb. 2012, om 09:26 heeft<Christian.Schulenberg@bmw.de>  <Christian.Schulenberg@bmw.de>  het volgende geschreven:
>>>
>>>> I already added to following line to my local.conf:
>>>>
>>>> BBMASK = ".*/meta-ti/recipes-misc/"
>>>>
>>>> which helps to bypass the first build problem. The next show stopper is building the boot loader (denx version of u-boot):
>>>>
>>>> clocks.c:415:13: internal compiler error: in decode_addr_const, at varasm.c:2632
>>>>
>>>> This seems to be a problem with the used version of gcc. I guess there are two ways to work around this: Use older version of gcc (4.5) or change compiler optimization from -Os to -O0. Unfortunately, neither can I find the right place to switch from gcc 4.6 to 4.5, nor the place to change compiler flags.
>>> Have you read the README in the meta-ti layer yet? That explains how to setup a working environment.
>> The README contains instructions for building Angstrom, which is not the
>> right answer for everyone trying to use meta-ti.
> Since the recipe in question break with gcc 4.6 and/or binutils 2.22 *and* you need SOC_FAMILY in overrides angstrom is the only "out of the box" option. Other routes will involve heavy patching. I agree that needs to be addressed, but it doesn't change the solution *right now*.
>
> And the instructions in the README set things for 'yocto', which is what people are asking for. If they asked for 'poky', that would be a totally different thing.

Denis or Koen:  Before today is over please modify the README.txt to 
describe where we are going and what is possible right now.  If Angstrom 
is the only thing possible right now it should say that until we can 
build with other layer stacks.  However it should also say that we are 
working toward a solution that will build with multiple layer stacks 
including poky.


_______________________________________________
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti

Re: Building Yocto for Pandaboard

[Koen Kooi]

Op 28 feb. 2012, om 08:52 heeft <Christian.Schulenberg@bmw.de> het volgende geschreven:

> Thanks a lot for your replies. Angstrom is definitely not the way I want to go at the moment, because I prefer to have a clean architecture in my project.

What's not clean about angstrom?

Re: Building Yocto for Pandaboard

[Christian.Schulenberg]

I'm not talking about angstrom, I'm talking about cross dependencies between poky and angstrom when using the meta-ti layer.

-----Ursprüngliche Nachricht-----
Von: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] Im Auftrag von Koen Kooi
Gesendet: Dienstag, 28. Februar 2012 08:56
An: meta-ti@yoctoproject.org
Betreff: Re: [meta-ti] Building Yocto for Pandaboard


Op 28 feb. 2012, om 08:52 heeft <Christian.Schulenberg@bmw.de> het volgende geschreven:

> Thanks a lot for your replies. Angstrom is definitely not the way I want to go at the moment, because I prefer to have a clean architecture in my project.

What's not clean about angstrom?

_______________________________________________
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti

Re: Building Yocto for Pandaboard

[Christian.Schulenberg]

Hi,

finally, I managed to bring up the Pandaboard with the meta-ti layer by myself. For all of you, who are facing the same problems and who don't want to use Angstrom, here are some hints, how to do this just using Yocto Poky:

Remove systemd in local.conf as mentioned above.

I used machine configuration for "omap4430-panda", because machine "pandaboard" did not build the kernel. Because this configuration use the sakoman bootloader, which caused some trouble for me, I switched over to (denx) u-boot. 

Use gcc4.5 instead of gcc4.6. The reason for this is a compiler error that came up when compiling the u-boot bootloader. You can change the compiler in ./meta/conf/distro/include/tcmode-default.inc , variable GCCVERSION. Another alternative might be patching the gcc4.6, because there is already a fix for this compiler error.

In the kernel configuration I needed to switch off lzop_native (CONFIG_KERNEL_LZO).

I removed ofono from the image, because I don't need it and it is just causing trouble.

I needed to remove netbase and alsa-state as well. 

With these changes I got an image for my Pandaboard and the corresponding bootloader. I worked around some problems, by just removing packages. This is acceptable for a first shot, in the next steps I need to implement at least systemd. On the other hand, I see that Koen changed the system configuration (e.g.: CONFIG_KERNEL_LZO) as well as the competing machine configurations omap4430-panda and pandaboard. May be, I'll give this update a try.

Best regards,
Christian

Re: Building Yocto for Pandaboard

[Robert P. J. Day]

  i'd like to try to reproduce what's below, so a few questions first.
is this for a regular panda, or a 4460-based panda ES?  i'm
specifically interested in the ES, but there's a good chance a regular
build will still at least boot and i'll worry about any weirdness
later.  and i don't see anything in the meta-ti layer yet
*specifically* for the 4460.

  FYI, my setup is 64-bit ubuntu 11.10 with fully pulled

  * yocto
  * meta-ti
  * meta-openembedded (with underlying meta-oe layer, of course)

  and now, the stupid questions ...

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> Hi,
>
> finally, I managed to bring up the Pandaboard with the meta-ti layer
> by myself. For all of you, who are facing the same problems and who
> don't want to use Angstrom, here are some hints, how to do this just
> using Yocto Poky:
>
> Remove systemd in local.conf as mentioned above.

  i remember that issue and, rather than remove systemd, i followed
someone else's suggestion and just added the meta-oe layer to pull it
in.  here's my layers info, does it look sane?  (is that the correct
order to get the right precedence?)

BBLAYERS ?= " \
  /home/rpjday/yocto/git/meta \
  /home/rpjday/yocto/git/meta-yocto \
  /home/rpjday/yocto/git/meta-openembedded/meta-oe \
  /home/rpjday/yocto/git/meta-ti \
  "

if systemd is truly a problem, i can take it out.

> I used machine configuration for "omap4430-panda", because machine
> "pandaboard" did not build the kernel.  i suspect the "pandaboard"
> file will be disappearing given its superfluity.

i noticed that already, that's what i'll be using as well.

> Because this configuration use the sakoman bootloader, which caused
> some trouble for me, I switched over to (denx) u-boot.

  and you did that how?

> Use gcc4.5 instead of gcc4.6. The reason for this is a compiler
> error that came up when compiling the u-boot bootloader. You can
> change the compiler in ./meta/conf/distro/include/tcmode-default.inc
> , variable GCCVERSION. Another alternative might be patching the
> gcc4.6, because there is already a fix for this compiler error.

  based on what i read here:

http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg24283.html

can i just add that line

GCCVERSION = "4.7%"

to my local.conf?  might as well jump up to gcc 4.7.

  and i currently get a fetch error for udev 173, so i set the
PREFERRED_VERSION to 181.  did you not get such an error?  more later.

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Christian.Schulenberg]

Hi,

I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.

You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:

#EXTRA_IMAGEDEPENDS = "x-load u-boot-sakoman " -> remove or comment this line out
EXTRA_IMAGEDEPENDS += "u-boot" -> I used this line, but because omap4430-panda.conf includes omap3.inc, it should be obsolete. Same definition is in there. X-Load can be removed from omap3.inc from my point of view, because it's not necessary.

#PREFERRED_PROVIDER_virtual/bootloader = "u-boot-sakoman"  -> remove or comment this line out
PREFERRED_PROVIDER_virtual/bootloader = "u-boot"

Your question about gcc4.7: I haven't used this version yet.

I have build core-image-base as well as core-image-basic successfully for Pandaboard. I connect to the board via the serial interface, so I don't need a configured eth0 yet.

Thanks for your suggestion about systemd. I will try to pull in system in the next days.

BR,
Christian




-----Ursprüngliche Nachricht-----
Von: Robert P. J. Day [mailto:rpjday@crashcourse.ca] 
Gesendet: Montag, 5. März 2012 14:05
An: Schulenberg Christian, EI-42
Cc: meta-ti mailing list
Betreff: Re: [meta-ti] Building Yocto for Pandaboard


  i'd like to try to reproduce what's below, so a few questions first.
is this for a regular panda, or a 4460-based panda ES?  i'm
specifically interested in the ES, but there's a good chance a regular
build will still at least boot and i'll worry about any weirdness
later.  and i don't see anything in the meta-ti layer yet
*specifically* for the 4460.

  FYI, my setup is 64-bit ubuntu 11.10 with fully pulled

  * yocto
  * meta-ti
  * meta-openembedded (with underlying meta-oe layer, of course)

  and now, the stupid questions ...

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> Hi,
>
> finally, I managed to bring up the Pandaboard with the meta-ti layer
> by myself. For all of you, who are facing the same problems and who
> don't want to use Angstrom, here are some hints, how to do this just
> using Yocto Poky:
>
> Remove systemd in local.conf as mentioned above.

  i remember that issue and, rather than remove systemd, i followed
someone else's suggestion and just added the meta-oe layer to pull it
in.  here's my layers info, does it look sane?  (is that the correct
order to get the right precedence?)

BBLAYERS ?= " \
  /home/rpjday/yocto/git/meta \
  /home/rpjday/yocto/git/meta-yocto \
  /home/rpjday/yocto/git/meta-openembedded/meta-oe \
  /home/rpjday/yocto/git/meta-ti \
  "

if systemd is truly a problem, i can take it out.

> I used machine configuration for "omap4430-panda", because machine
> "pandaboard" did not build the kernel.  i suspect the "pandaboard"
> file will be disappearing given its superfluity.

i noticed that already, that's what i'll be using as well.

> Because this configuration use the sakoman bootloader, which caused
> some trouble for me, I switched over to (denx) u-boot.

  and you did that how?

> Use gcc4.5 instead of gcc4.6. The reason for this is a compiler
> error that came up when compiling the u-boot bootloader. You can
> change the compiler in ./meta/conf/distro/include/tcmode-default.inc
> , variable GCCVERSION. Another alternative might be patching the
> gcc4.6, because there is already a fix for this compiler error.

  based on what i read here:

http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg24283.html

can i just add that line

GCCVERSION = "4.7%"

to my local.conf?  might as well jump up to gcc 4.7.

  and i currently get a fetch error for udev 173, so i set the
PREFERRED_VERSION to 181.  did you not get such an error?  more later.

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Robert P. J. Day]

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> Hi,
>
> I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
>
> You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
>
> #EXTRA_IMAGEDEPENDS = "x-load u-boot-sakoman " -> remove or comment this line out
> EXTRA_IMAGEDEPENDS += "u-boot" -> I used this line, but because omap4430-panda.conf includes omap3.inc, it should be obsolete. Same definition is in there. X-Load can be removed from omap3.inc from my point of view, because it's not necessary.
>
> #PREFERRED_PROVIDER_virtual/bootloader = "u-boot-sakoman"  -> remove or comment this line out
> PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
>
> Your question about gcc4.7: I haven't used this version yet.
>
> I have build core-image-base as well as core-image-basic successfully for Pandaboard. I connect to the board via the serial interface, so I don't need a configured eth0 yet.
>
> Thanks for your suggestion about systemd. I will try to pull in system in the next days.

  without making any of the above changes (since it doesn't appear it
would affect what i'm doing), i'm getting a build error that goes back
many months:

ERROR: Function failed: do_compile_perf (see /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/temp/log.do_compile_perf.29777 for further information)
NOTE: make -j 8 -C /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda LD=arm-poky-linux-gnueabi-ld --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda  prefix=/usr NO_NEWT=1 NO_DWARF=1
make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
PERF_VERSION = ti.ubuntu.2.6.35.993.3
make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
    GEN common-cmds.h
    * new build flags or prefix
touch .perf.dev.null
    GEN perf-archive
    CC builtin-annotate.o
    CC builtin-bench.o
    CC bench/sched-messaging.o
    CC bench/sched-pipe.o
    CC bench/mem-memcpy.o
    CC builtin-diff.o
    CC builtin-sched.o
bench/sched-pipe.c: In function 'bench_sched_pipe':
bench/sched-pipe.c:58:6: error: variable 'ret' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make: *** [bench/sched-pipe.o] Error 1
make: *** Waiting for unfinished jobs....
    CC builtin-buildid-list.o
builtin-sched.c: In function 'process_sched_event':
builtin-sched.c:373:12: error: variable 'delta' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'run_one_test':
builtin-sched.c:564:39: error: variable 'std_dev' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'replay_switch_event':
builtin-sched.c:801:27: error: variable 'next' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'map_switch_event':
builtin-sched.c:1406:17: error: variable 'sched_out' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make: *** [builtin-sched.o] Error 1
rm .perf.dev.null
make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
ERROR: oe_runmake failed


  i'd thought that had been addressed some time back.  did you not see
that build error?  does that mean using a different version of gcc
would resolve it?

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Christian.Schulenberg]

No, as I wrote previously, the compiler error I have belongs to the source code of the bootloader (seems to be a problem with structure aligning). The problem you have is in the kernel.

-----Ursprüngliche Nachricht-----
Von: Robert P. J. Day [mailto:rpjday@crashcourse.ca] 
Gesendet: Montag, 5. März 2012 16:17
An: Schulenberg Christian, EI-42
Cc: meta-ti@yoctoproject.org
Betreff: Re: AW: [meta-ti] Building Yocto for Pandaboard

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> Hi,
>
> I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
>
> You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
>
> #EXTRA_IMAGEDEPENDS = "x-load u-boot-sakoman " -> remove or comment this line out
> EXTRA_IMAGEDEPENDS += "u-boot" -> I used this line, but because omap4430-panda.conf includes omap3.inc, it should be obsolete. Same definition is in there. X-Load can be removed from omap3.inc from my point of view, because it's not necessary.
>
> #PREFERRED_PROVIDER_virtual/bootloader = "u-boot-sakoman"  -> remove or comment this line out
> PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
>
> Your question about gcc4.7: I haven't used this version yet.
>
> I have build core-image-base as well as core-image-basic successfully for Pandaboard. I connect to the board via the serial interface, so I don't need a configured eth0 yet.
>
> Thanks for your suggestion about systemd. I will try to pull in system in the next days.

  without making any of the above changes (since it doesn't appear it
would affect what i'm doing), i'm getting a build error that goes back
many months:

ERROR: Function failed: do_compile_perf (see /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/temp/log.do_compile_perf.29777 for further information)
NOTE: make -j 8 -C /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda LD=arm-poky-linux-gnueabi-ld --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda  prefix=/usr NO_NEWT=1 NO_DWARF=1
make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
PERF_VERSION = ti.ubuntu.2.6.35.993.3
make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
    GEN common-cmds.h
    * new build flags or prefix
touch .perf.dev.null
    GEN perf-archive
    CC builtin-annotate.o
    CC builtin-bench.o
    CC bench/sched-messaging.o
    CC bench/sched-pipe.o
    CC bench/mem-memcpy.o
    CC builtin-diff.o
    CC builtin-sched.o
bench/sched-pipe.c: In function 'bench_sched_pipe':
bench/sched-pipe.c:58:6: error: variable 'ret' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make: *** [bench/sched-pipe.o] Error 1
make: *** Waiting for unfinished jobs....
    CC builtin-buildid-list.o
builtin-sched.c: In function 'process_sched_event':
builtin-sched.c:373:12: error: variable 'delta' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'run_one_test':
builtin-sched.c:564:39: error: variable 'std_dev' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'replay_switch_event':
builtin-sched.c:801:27: error: variable 'next' set but not used [-Werror=unused-but-set-variable]
builtin-sched.c: In function 'map_switch_event':
builtin-sched.c:1406:17: error: variable 'sched_out' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make: *** [builtin-sched.o] Error 1
rm .perf.dev.null
make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
ERROR: oe_runmake failed


  i'd thought that had been addressed some time back.  did you not see
that build error?  does that mean using a different version of gcc
would resolve it?

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5863 bytes --]

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> No, as I wrote previously, the compiler error I have belongs to the
> source code of the bootloader (seems to be a problem with structure
> aligning). The problem you have is in the kernel.

  i know ... my question was why you *weren't* getting that build
error.  i'm speculating that when you switched back to gcc 4.5 to
solve the u-boot issue, you might have avoided the perf build error as
well.

  i'm trying a gcc 4.5 build right now.

rday

>
> -----Ursprüngliche Nachricht-----
> Von: Robert P. J. Day [mailto:rpjday@crashcourse.ca]
> Gesendet: Montag, 5. März 2012 16:17
> An: Schulenberg Christian, EI-42
> Cc: meta-ti@yoctoproject.org
> Betreff: Re: AW: [meta-ti] Building Yocto for Pandaboard
>
> On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
>
> > Hi,
> >
> > I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
> >
> > You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
> >
> > #EXTRA_IMAGEDEPENDS = "x-load u-boot-sakoman " -> remove or comment this line out
> > EXTRA_IMAGEDEPENDS += "u-boot" -> I used this line, but because omap4430-panda.conf includes omap3.inc, it should be obsolete. Same definition is in there. X-Load can be removed from omap3.inc from my point of view, because it's not necessary.
> >
> > #PREFERRED_PROVIDER_virtual/bootloader = "u-boot-sakoman"  -> remove or comment this line out
> > PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
> >
> > Your question about gcc4.7: I haven't used this version yet.
> >
> > I have build core-image-base as well as core-image-basic successfully for Pandaboard. I connect to the board via the serial interface, so I don't need a configured eth0 yet.
> >
> > Thanks for your suggestion about systemd. I will try to pull in system in the next days.
>
>   without making any of the above changes (since it doesn't appear it
> would affect what i'm doing), i'm getting a build error that goes back
> many months:
>
> ERROR: Function failed: do_compile_perf (see /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/temp/log.do_compile_perf.29777 for further information)
> NOTE: make -j 8 -C /home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda LD=arm-poky-linux-gnueabi-ld --sysroot=/home/rpjday/yocto/builds/omap4430_panda/tmp/sysroots/omap4430-panda  prefix=/usr NO_NEWT=1 NO_DWARF=1
> make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
> PERF_VERSION = ti.ubuntu.2.6.35.993.3
> make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
> make: Entering directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
>     GEN common-cmds.h
>     * new build flags or prefix
> touch .perf.dev.null
>     GEN perf-archive
>     CC builtin-annotate.o
>     CC builtin-bench.o
>     CC bench/sched-messaging.o
>     CC bench/sched-pipe.o
>     CC bench/mem-memcpy.o
>     CC builtin-diff.o
>     CC builtin-sched.o
> bench/sched-pipe.c: In function 'bench_sched_pipe':
> bench/sched-pipe.c:58:6: error: variable 'ret' set but not used [-Werror=unused-but-set-variable]
> cc1: all warnings being treated as errors
>
> make: *** [bench/sched-pipe.o] Error 1
> make: *** Waiting for unfinished jobs....
>     CC builtin-buildid-list.o
> builtin-sched.c: In function 'process_sched_event':
> builtin-sched.c:373:12: error: variable 'delta' set but not used [-Werror=unused-but-set-variable]
> builtin-sched.c: In function 'run_one_test':
> builtin-sched.c:564:39: error: variable 'std_dev' set but not used [-Werror=unused-but-set-variable]
> builtin-sched.c: In function 'replay_switch_event':
> builtin-sched.c:801:27: error: variable 'next' set but not used [-Werror=unused-but-set-variable]
> builtin-sched.c: In function 'map_switch_event':
> builtin-sched.c:1406:17: error: variable 'sched_out' set but not used [-Werror=unused-but-set-variable]
> cc1: all warnings being treated as errors
>
> make: *** [builtin-sched.o] Error 1
> rm .perf.dev.null
> make: Leaving directory `/home/rpjday/yocto/builds/omap4430_panda/tmp/work/omap4430_panda-poky-linux-gnueabi/linux-omap4-2.6.35.7-r0/git/tools/perf'
> ERROR: oe_runmake failed
>
>
>   i'd thought that had been addressed some time back.  did you not see
> that build error?  does that mean using a different version of gcc
> would resolve it?
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>

-- 

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

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

Re: Building Yocto for Pandaboard

[Robert P. J. Day]

On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:

> Hi,
>
> I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
>
> You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:

  i noticed that koen just submitted a sizable patch that gets rid of
that conf file for the panda, and standardizes on the pandaboard.conf
file (at least that's what it looked like).

  under the circumstances, it might be worth just waiting until that
patch works its way through the system and start testing all over
again when it hits.

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Gary Thomas]

On 2012-03-05 09:39, Robert P. J. Day wrote:
> On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
>
>> Hi,
>>
>> I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
>>
>> You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
>
>    i noticed that koen just submitted a sizable patch that gets rid of
> that conf file for the panda, and standardizes on the pandaboard.conf
> file (at least that's what it looked like).
>
>    under the circumstances, it might be worth just waiting until that
> patch works its way through the system and start testing all over
> again when it hits.

Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Building Yocto for Pandaboard

[Denys Dmytriyenko]

On Mon, Mar 05, 2012 at 09:43:13AM -0700, Gary Thomas wrote:
> On 2012-03-05 09:39, Robert P. J. Day wrote:
> >On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
> >
> >>Hi,
> >>
> >>I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
> >>
> >>You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
> >
> >   i noticed that koen just submitted a sizable patch that gets rid of
> >that conf file for the panda, and standardizes on the pandaboard.conf
> >file (at least that's what it looked like).
> >
> >   under the circumstances, it might be worth just waiting until that
> >patch works its way through the system and start testing all over
> >again when it hits.
> 
> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)

FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...

-- 
Denys

Re: Building Yocto for Pandaboard

[Robert P. J. Day]

On Mon, 5 Mar 2012, Denys Dmytriyenko wrote:

> On Mon, Mar 05, 2012 at 09:43:13AM -0700, Gary Thomas wrote:
> > On 2012-03-05 09:39, Robert P. J. Day wrote:
> > >On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
> > >
> > >>Hi,
> > >>
> > >>I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
> > >>
> > >>You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
> > >
> > >   i noticed that koen just submitted a sizable patch that gets rid of
> > >that conf file for the panda, and standardizes on the pandaboard.conf
> > >file (at least that's what it looked like).
> > >
> > >   under the circumstances, it might be worth just waiting until that
> > >patch works its way through the system and start testing all over
> > >again when it hits.
> >
> > Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
>
> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...

  ok, i can see the new content and i just pulled into meta-ti and
meta-openembedded.  so, starting all over again, is there now a
known recipe for building for the panda with a minimum of
customziation?

  i think i'm going to start a new wiki page. :-)

rday

-- 

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

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

Re: Building Yocto for Pandaboard

[Koen Kooi]

Op 5 mrt. 2012, om 18:13 heeft Robert P. J. Day het volgende geschreven:

> On Mon, 5 Mar 2012, Denys Dmytriyenko wrote:
> 
>> On Mon, Mar 05, 2012 at 09:43:13AM -0700, Gary Thomas wrote:
>>> On 2012-03-05 09:39, Robert P. J. Day wrote:
>>>> On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
>>>>> 
>>>>> You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
>>>> 
>>>>  i noticed that koen just submitted a sizable patch that gets rid of
>>>> that conf file for the panda, and standardizes on the pandaboard.conf
>>>> file (at least that's what it looked like).
>>>> 
>>>>  under the circumstances, it might be worth just waiting until that
>>>> patch works its way through the system and start testing all over
>>>> again when it hits.
>>> 
>>> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
>> 
>> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
> 
>  ok, i can see the new content and i just pulled into meta-ti and
> meta-openembedded.  so, starting all over again, is there now a
> known recipe for building for the panda with a minimum of
> customziation?

Yes, use the setup-scripts mentioned in the wiki, zero customization needed.

Re: Building Yocto for Pandaboard

[Denys Dmytriyenko]

On Mon, Mar 05, 2012 at 06:15:54PM +0100, Koen Kooi wrote:
> 
> >>> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
> >> 
> >> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
> > 
> >  ok, i can see the new content and i just pulled into meta-ti and
> > meta-openembedded.  so, starting all over again, is there now a
> > known recipe for building for the panda with a minimum of
> > customziation?
> 
> Yes, use the setup-scripts mentioned in the wiki, zero customization needed.

Anyone else is seeing this on Panda's 3.1 kernel in do_install? Using GNU make 
3.82, but seems SECONDEXPANSION with PHONY rules don't work...

...
  INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
  INSTALL sound/soc/codecs/snd-soc-wm9081.ko
  INSTALL sound/usb/snd-usb-audio.ko
  INSTALL sound/usb/snd-usbmidi-lib.ko
  INSTALL sound/usb/misc/snd-ua101.ko
  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/emi26/
  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/emi62/
make[1]: *** No rule to make target `/OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/./', needed by `/OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/ti_3410.fw'.  Stop.
make[1]: *** Waiting for unfinished jobs....
  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/kaweth/
make: *** [_modinst_post] Error 2
ERROR: oe_runmake failed

-- 
Denys

Re: Building Yocto for Pandaboard

[Koen Kooi]

Op 5 mrt. 2012, om 21:29 heeft Denys Dmytriyenko het volgende geschreven:

> On Mon, Mar 05, 2012 at 06:15:54PM +0100, Koen Kooi wrote:
>> 
>>>>> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
>>>> 
>>>> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
>>> 
>>> ok, i can see the new content and i just pulled into meta-ti and
>>> meta-openembedded.  so, starting all over again, is there now a
>>> known recipe for building for the panda with a minimum of
>>> customziation?
>> 
>> Yes, use the setup-scripts mentioned in the wiki, zero customization needed.
> 
> Anyone else is seeing this on Panda's 3.1 kernel in do_install? Using GNU make 
> 3.82, but seems SECONDEXPANSION with PHONY rules don't work...

I'm seeing it on my fedora machines, but not in my debian machines. Tweaking the defconfig usually helps

regards,

Koen


> 
> ...
>  INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
>  INSTALL sound/soc/codecs/snd-soc-wm9081.ko
>  INSTALL sound/usb/snd-usb-audio.ko
>  INSTALL sound/usb/snd-usbmidi-lib.ko
>  INSTALL sound/usb/misc/snd-ua101.ko
>  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/emi26/
>  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/emi62/
> make[1]: *** No rule to make target `/OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/./', needed by `/OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/ti_3410.fw'.  Stop.
> make[1]: *** Waiting for unfinished jobs....
>  MKDIR   /OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/pandaboard-angstrom-linux-gnueabi/linux-omap4-3.1.0-r1/image/lib/firmware/kaweth/
> make: *** [_modinst_post] Error 2
> ERROR: oe_runmake failed
> 
> -- 
> Denys

Re: Building Yocto for Pandaboard

[Denys Dmytriyenko]

On Mon, Mar 05, 2012 at 09:31:30PM +0100, Koen Kooi wrote:
> 
> Op 5 mrt. 2012, om 21:29 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > On Mon, Mar 05, 2012 at 06:15:54PM +0100, Koen Kooi wrote:
> >> 
> >>>>> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
> >>>> 
> >>>> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
> >>> 
> >>> ok, i can see the new content and i just pulled into meta-ti and
> >>> meta-openembedded.  so, starting all over again, is there now a
> >>> known recipe for building for the panda with a minimum of
> >>> customziation?
> >> 
> >> Yes, use the setup-scripts mentioned in the wiki, zero customization needed.
> > 
> > Anyone else is seeing this on Panda's 3.1 kernel in do_install? Using GNU make 
> > 3.82, but seems SECONDEXPANSION with PHONY rules don't work...
> 
> I'm seeing it on my fedora machines, but not in my debian machines. Tweaking 
> the defconfig usually helps

Koen,

Can you please test if the patch I just sent fixes the issue for your Fedora, 
but doesn't break your Debian builds? Thanks.

-- 
Denys

Re: Building Yocto for Pandaboard

[Denys Dmytriyenko]

On Mon, Mar 05, 2012 at 05:28:33PM -0500, Denys Dmytriyenko wrote:
> On Mon, Mar 05, 2012 at 09:31:30PM +0100, Koen Kooi wrote:
> > 
> > Op 5 mrt. 2012, om 21:29 heeft Denys Dmytriyenko het volgende geschreven:
> > 
> > > On Mon, Mar 05, 2012 at 06:15:54PM +0100, Koen Kooi wrote:
> > >> 
> > >>>>> Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
> > >>>> 
> > >>>> FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
> > >>> 
> > >>> ok, i can see the new content and i just pulled into meta-ti and
> > >>> meta-openembedded.  so, starting all over again, is there now a
> > >>> known recipe for building for the panda with a minimum of
> > >>> customziation?
> > >> 
> > >> Yes, use the setup-scripts mentioned in the wiki, zero customization needed.
> > > 
> > > Anyone else is seeing this on Panda's 3.1 kernel in do_install? Using GNU make 
> > > 3.82, but seems SECONDEXPANSION with PHONY rules don't work...
> > 
> > I'm seeing it on my fedora machines, but not in my debian machines. Tweaking 
> > the defconfig usually helps
> 
> Koen,
> 
> Can you please test if the patch I just sent fixes the issue for your Fedora, 
> but doesn't break your Debian builds? Thanks.

My testing so far:

I see the previously mentioned breakage on my up-to-date Gentoo system with 
make 3.82, but it works w/o any problems on Ubuntu 10.04 with make 3.81.

After applying the patch I sent to the list, the breakage on Gentoo is gone 
and Ubuntu still builds fine.

I'd wait for now for any other confirmations or onjections before pushing it 
to meta-ti master. Thanks.

-- 
Denys

Re: Building Yocto for Pandaboard

[Brian Hutchinson]

On Mon, Mar 5, 2012 at 8:39 PM, Denys Dmytriyenko <denis@denix.org> wrote:

> I'd wait for now for any other confirmations or onjections before pushing it
> to meta-ti master. Thanks.
>

I'm trying to follow all this and translate it to Netra (I know,
probably big mistake) since I don't have Panda.  I'm on Debian too.

B

Re: Building Yocto for Pandaboard

[Marc Butler]

On Mon, Mar 05, 2012 at 12:13:59PM -0500, Robert P. J. Day wrote:
> On Mon, 5 Mar 2012, Denys Dmytriyenko wrote:
> 
> > On Mon, Mar 05, 2012 at 09:43:13AM -0700, Gary Thomas wrote:
> > > On 2012-03-05 09:39, Robert P. J. Day wrote:
> > > >On Mon, 5 Mar 2012, Christian.Schulenberg@bmw.de wrote:
> > > >
> > > >>Hi,
> > > >>
> > > >>I'm using a Pandaboard Rev A4, so it is in fact an OMAP4430 board.
> > > >>
> > > >>You can change to u-boot bootloader in /meta-ti/conf/machine/omap4430-panda.conf:
> > > >
> > > >   i noticed that koen just submitted a sizable patch that gets rid of
> > > >that conf file for the panda, and standardizes on the pandaboard.conf
> > > >file (at least that's what it looked like).
> > > >
> > > >   under the circumstances, it might be worth just waiting until that
> > > >patch works its way through the system and start testing all over
> > > >again when it hits.
> > >
> > > Yes, you'll also get a newer kernel (3.0.2 last I looked, not 2.6.35)
> >
> > FYI, there is already 3.1 for Panda in meta-ti with -1 D_P...
> 
>   ok, i can see the new content and i just pulled into meta-ti and
> meta-openembedded.  so, starting all over again, is there now a
> known recipe for building for the panda with a minimum of
> customziation?
> 
>   i think i'm going to start a new wiki page. :-)

If this works for you, I would be eager to know the process. And happy
to verify in another environment.

-m

building Yocto for Pandaboard

[jfabernathy]

I'm trying to build the pandaboard BSP for Yocto.  I cloned the meta-ti 
repository in the poky directory and tried to build core-image-sato for 
both machine pandaboard and omap4430-panda. However, I immediately get 
an error because bitbake is looking for 
recipes-images/angstrom/systemd-image.bb, which is required in the 
ti-hw-bringup-image.bb image recipe.

All I really included was the machine name change in local.conf and 
added the meta-ti layer in bblayers.conf.

Did I miss a step?

Jim A

Re: building Yocto for Pandaboard

[Koen Kooi]

There's a README in the layer, read it and follow the instructions

Op 8 feb. 2012 om 22:58 heeft jfabernathy <jfabernathy@gmail.com> het volgende geschreven:

> I'm trying to build the pandaboard BSP for Yocto.  I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image recipe.
> 
> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
> 
> Did I miss a step?
> 
> Jim A
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-08 14:58, jfabernathy wrote:
> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
> recipe.
>
> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>
> Did I miss a step?

This was discussed last week.  Add this line to your local.conf
   BBMASK = ".*/meta-ti/recipes-misc/"
This will skip some BeagleBoard/BeagleBone recipes that are not
currently working in a Yocto tree.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: building Yocto for Pandaboard

[jfabernathy]

On 02/08/2012 05:05 PM, Gary Thomas wrote:
> On 2012-02-08 14:58, jfabernathy wrote:
>> I'm trying to build the pandaboard BSP for Yocto. I cloned the 
>> meta-ti repository in the poky directory and tried to build 
>> core-image-sato for both machine pandaboard and
>> omap4430-panda. However, I immediately get an error because bitbake 
>> is looking for recipes-images/angstrom/systemd-image.bb, which is 
>> required in the ti-hw-bringup-image.bb image
>> recipe.
>>
>> All I really included was the machine name change in local.conf and 
>> added the meta-ti layer in bblayers.conf.
>>
>> Did I miss a step?
>
> This was discussed last week.  Add this line to your local.conf
>   BBMASK = ".*/meta-ti/recipes-misc/"
> This will skip some BeagleBoard/BeagleBone recipes that are not
> currently working in a Yocto tree.
>
Thanks a bunch. That got it going.  The README said nothing, so I'm glad 
you jumped in with this hint.  I just joined the meta-ti mailing list today.

I know I'm going to need a pointer to how to put the yocto image on an 
SDcard.  I would assume it's similar to how you put ubuntu or angstrom??

JIm A

Re: building Yocto for Pandaboard

[Koen Kooi]

Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:

> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>> On 2012-02-08 14:58, jfabernathy wrote:
>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>> recipe.
>>> 
>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>> 
>>> Did I miss a step?
>> 
>> This was discussed last week.  Add this line to your local.conf
>>  BBMASK = ".*/meta-ti/recipes-misc/"
>> This will skip some BeagleBoard/BeagleBone recipes that are not
>> currently working in a Yocto tree.
>> 
> Thanks a bunch. That got it going.  The README said nothing

Stop spreading such lies!

koen@dominion:/OE/tentacle/sources/meta-ti$ cat README 
This layer depends on:

URI: git://git.openembedded.org/openembedded-core
branch: master
revision: HEAD

URI: git://git.angstrom-distribution.org/meta-angstrom
branch: master
revision: HEAD

URI: git://git.openembedded.org/meta-openembedded
branch: master
revision: HEAD

It is recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom

This will set it up for the OpenEmbedded-core layout instead of the old
OpenEmbedded-dev layout. You can optionally tweak sources/layers.txt and conf/bblayers.conf to (de)select BSP layers.

Send pull requests to meta-ti@yoctoproject.org

Main layer maintainers: Denys Dmytriyenko <denys@ti.com>
                        Koen Kooi <k-kooi@ti.com>

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-08 15:18, Koen Kooi wrote:
>
> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:
>
>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>>> recipe.
>>>>
>>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>>
>>>> Did I miss a step?
>>>
>>> This was discussed last week.  Add this line to your local.conf
>>>   BBMASK = ".*/meta-ti/recipes-misc/"
>>> This will skip some BeagleBoard/BeagleBone recipes that are not
>>> currently working in a Yocto tree.
>>>
>> Thanks a bunch. That got it going.  The README said nothing
>
> Stop spreading such lies!

It's not a lie, just a perspective.  Not everyone wants to run Angstrom,
but they might want to use the TI layer (kernels, DSP support, etc)

>
> koen@dominion:/OE/tentacle/sources/meta-ti$ cat README
> This layer depends on:
>
> URI: git://git.openembedded.org/openembedded-core
> branch: master
> revision: HEAD
>
> URI: git://git.angstrom-distribution.org/meta-angstrom
> branch: master
> revision: HEAD
>
> URI: git://git.openembedded.org/meta-openembedded
> branch: master
> revision: HEAD
>
> It is recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom
>
> This will set it up for the OpenEmbedded-core layout instead of the old
> OpenEmbedded-dev layout. You can optionally tweak sources/layers.txt and conf/bblayers.conf to (de)select BSP layers.
>
> Send pull requests to meta-ti@yoctoproject.org
>
> Main layer maintainers: Denys Dmytriyenko<denys@ti.com>
>                          Koen Kooi<k-kooi@ti.com>
>
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: building Yocto for Pandaboard

[Koen Kooi]

Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende geschreven:

> On 2012-02-08 15:18, Koen Kooi wrote:
>> 
>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:
>> 
>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>>>> recipe.
>>>>> 
>>>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>>> 
>>>>> Did I miss a step?
>>>> 
>>>> This was discussed last week.  Add this line to your local.conf
>>>>  BBMASK = ".*/meta-ti/recipes-misc/"
>>>> This will skip some BeagleBoard/BeagleBone recipes that are not
>>>> currently working in a Yocto tree.
>>>> 
>>> Thanks a bunch. That got it going.  The README said nothing
>> 
>> Stop spreading such lies!
> 
> It's not a lie, just a perspective. 

It *is* a lie, since the README is non-empty. Regardless of what you want to do, the README does contain content.

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-08 15:27, Koen Kooi wrote:
>
> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende geschreven:
>
>> On 2012-02-08 15:18, Koen Kooi wrote:
>>>
>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:
>>>
>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>>>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>>>>> recipe.
>>>>>>
>>>>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>>>>
>>>>>> Did I miss a step?
>>>>>
>>>>> This was discussed last week.  Add this line to your local.conf
>>>>>   BBMASK = ".*/meta-ti/recipes-misc/"
>>>>> This will skip some BeagleBoard/BeagleBone recipes that are not
>>>>> currently working in a Yocto tree.
>>>>>
>>>> Thanks a bunch. That got it going.  The README said nothing
>>>
>>> Stop spreading such lies!
>>
>> It's not a lie, just a perspective.
>
> It *is* a lie, since the README is non-empty. Regardless of what you want to do, the README does contain content.

Sorry, I thought you were referring to my work-around to get this
going in Yocto.  Obviously, he was looking for more info in the
README than just how to use this layer with Angstrom and I agree
that this "trick" probably does not belong in the README.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: building Yocto for Pandaboard

[James Abernathy]

On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:

> On 2012-02-08 15:27, Koen Kooi wrote:
>> 
>> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende geschreven:
>> 
>>> On 2012-02-08 15:18, Koen Kooi wrote:
>>>> 
>>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:
>>>> 
>>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>>>>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>>>>>> recipe.
>>>>>>> 
>>>>>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>>>>> 
>>>>>>> Did I miss a step?
>>>>>> 
>>>>>> This was discussed last week.  Add this line to your local.conf
>>>>>>  BBMASK = ".*/meta-ti/recipes-misc/"
>>>>>> This will skip some BeagleBoard/BeagleBone recipes that are not
>>>>>> currently working in a Yocto tree.
>>>>>> 
>>>>> Thanks a bunch. That got it going.  The README said nothing
>>>> 
>>>> Stop spreading such lies!
>>> 
>>> It's not a lie, just a perspective.
>> 
>> It *is* a lie, since the README is non-empty. Regardless of what you want to do, the README does contain content.
> 
> Sorry, I thought you were referring to my work-around to get this
> going in Yocto.  Obviously, he was looking for more info in the
> README than just how to use this layer with Angstrom and I agree
> that this "trick" probably does not belong in the README.
> 
> -- 

Wow!  Sorry I jumped into a mailing list I obviously don't understand or belong in.  I apologize if I offended.  I did read the README, but it didn't make a bit of sense to me because it talked about angstrom, which I don't know anything about and wondered what that had to do with yocto.  My current Yocto knowledge is based on the meta-intel layer, which doesn't mention angstrom.  It sounds like the hint/trick that Gary mentioned will make bitbake build with just yocto, which is what I want.  My goal is more of a proof of concept.  I'd like to prove if you could take the same image recipe and move it from Pandaboard to Atom and vice versa.  That way a developer could pick the hardware platform based on the performance, features, and cost.  The software effort should be minimal to move if the Yocto concept works as advertised.

Jim A
 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: building Yocto for Pandaboard

[William Mills]

On 02/08/2012 05:51 PM, James Abernathy wrote:
>
> On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:
>
>> On 2012-02-08 15:27, Koen Kooi wrote:
>>>
>>> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende geschreven:
>>>
>>>> On 2012-02-08 15:18, Koen Kooi wrote:
>>>>>
>>>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende geschreven:
>>>>>
>>>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>>>>>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>>>>>>> recipe.
>>>>>>>>
>>>>>>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>>>>>>
>>>>>>>> Did I miss a step?
>>>>>>>
>>>>>>> This was discussed last week.  Add this line to your local.conf
>>>>>>>   BBMASK = ".*/meta-ti/recipes-misc/"
>>>>>>> This will skip some BeagleBoard/BeagleBone recipes that are not
>>>>>>> currently working in a Yocto tree.
>>>>>>>
>>>>>> Thanks a bunch. That got it going.  The README said nothing
>>>>>
>>>>> Stop spreading such lies!
>>>>
>>>> It's not a lie, just a perspective.
>>>
>>> It *is* a lie, since the README is non-empty. Regardless of what you want to do, the README does contain content.

I for one read that as Gary intended, that the README did not say 
anything about how to get it to work with Yocto.  Can we word things is 
a less confrontational way please?

>>
>> Sorry, I thought you were referring to my work-around to get this
>> going in Yocto.  Obviously, he was looking for more info in the
>> README than just how to use this layer with Angstrom and I agree
>> that this "trick" probably does not belong in the README.
>>
>> --
>
> Wow!  Sorry I jumped into a mailing list I obviously don't understand or belong in.

There was nothing wrong with your question.

As Gary said there has not been too many end user questions on meta-ti 
yet.  Of course someone has to be first.

meta-ti is still in early development.  It started life working only in 
an Angstrom context.  We are making changes that will make most of it 
work with just oe-core or yocto/poky but that is not ready yet.  Gary's 
work around is an interesting approximation of what we are shooting for.

> I apologize if I offended.  I did read the README, but it didn't make a bit of sense to me because it talked about angstrom, which I don't know anything about and wondered what that had to do with yocto.  My current Yocto knowledge is based on the meta-intel layer, which doesn't mention angstrom.  It sounds like the hint/trick that Gary mentioned will make bitbake build with just yocto, which is what I want.  My goal is more of a proof of concept.  I'd like to prove if you could take the same image recipe and move it from Pandaboard to Atom and vice versa.  That way a developer could pick the hardware platform based on the performance, features, and cost.  The software effort should be minimal to move if the Yocto concept works as advertised.
>
> Jim A
>
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: building Yocto for Pandaboard

[Brian Hutchinson]

 On Wed, Feb 8, 2012 at 8:16 PM, William Mills <wmills@ti.com> wrote:
> As Gary said there has not been too many end user questions on meta-ti yet.

 All I care about is meta-ti as that is what all our products are based
 on.  I've been watching subject for a while now trying to discern all
 the issues and make a wise choice.

 I'm wanting to switch from Arago to whatever TI supports next as I
 supply the rest of our development team with tools and images that
 they build applications on for our products and I can't jerk them
 around changing distros.

 Regards,

 Brian

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
>  On Wed, Feb 8, 2012 at 8:16 PM, William Mills <wmills@ti.com> wrote:
> > As Gary said there has not been too many end user questions on meta-ti yet.
> 
>  All I care about is meta-ti as that is what all our products are based
>  on. I've been watching subject for a while now trying to discern all
>  the issues and make a wise choice.

Brian,

>  I'm wanting to switch from Arago to whatever TI supports next as I
>  supply the rest of our development team with tools and images that
>  they build applications on for our products and I can't jerk them
>  around changing distros.

As you are aware, Arago is not going away - there is work going on in 
meta-arago layer to update/port it to the new Yocto infrastructure.

Arago/meta-arago is still going to be the official platform distribution for 
TI SDK products. But, a separate meta-ti layer was created early in the 
process to detach and unify the BSP layer and allow people to use TI hardware 
with different distributions. And that's actually part of the problem, as 
distributions like religions conflict with each other in a single layer... :)

-- 
Denys

Re: building Yocto for Pandaboard

[Brian Hutchinson]

On Thu, Feb 9, 2012 at 11:36 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> Arago/meta-arago is still going to be the official platform distribution for
> TI SDK products. But, a separate meta-ti layer was created early in the
> process to detach and unify the BSP layer and allow people to use TI hardware
> with different distributions. And that's actually part of the problem, as
> distributions like religions conflict with each other in a single layer... :)

Hey Denys, good to hear from you again!

Sorry for totally hi-jacking this thread .... so what should be the
roadmap for someone like me who works on TI products and has to
generate images now?  Do I use Yocto with meta-ti and in the future
when the dust settles use Yocto with meta-arago?

I've heard bits and pieces of things changing but I guess I never knew
enough of the TI roadmap to know for sure what I should be doing so
that I steer our team/company in the right direction for all these
changes.  I'm currently using Arago to generate our images (separate
CSL toolchain (old), and the generated packages are old too).

Regards,

Brian

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 11:54:37AM -0500, Brian Hutchinson wrote:
> On Thu, Feb 9, 2012 at 11:36 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> > Arago/meta-arago is still going to be the official platform distribution for
> > TI SDK products. But, a separate meta-ti layer was created early in the
> > process to detach and unify the BSP layer and allow people to use TI hardware
> > with different distributions. And that's actually part of the problem, as
> > distributions like religions conflict with each other in a single layer... :)
> 
> Hey Denys, good to hear from you again!

Brian, nice to talk to you again!

> Sorry for totally hi-jacking this thread .... so what should be the
> roadmap for someone like me who works on TI products and has to
> generate images now?  Do I use Yocto with meta-ti and in the future
> when the dust settles use Yocto with meta-arago?

First, meta-arago is not meant to replace meta-ti, it's meant to complement 
it. Yocto Project makes heavy use of layers and there are different types of 
layers - base, BSP, apps and distro. There used to be a visual diagram of how 
layers stack on top of one another, but I can't find it now. There is a nice 
comprehesive list of known layers, grouped by their type:
http://www.openembedded.org/wiki/LayerIndex

With that in mind, meta-ti is meant to be a pure BSP layer, while meta-arago 
is shaping up to contain 2 sub-layers - distro one and extra sw apps one.

You'd be able to use meta-ti in different combinations of layers with 
different distro layers - none, angstrom, arago and poky/yocto. When meta-ti 
is used together with meta-arago distro, it should provide the same features 
and same functionality as old Arago.

All this is within realms of the Yocto Project. Sometimes it's confusing when 
one refers to Yocto as a wider framework and the build sytem, vs. Yocto/Poky 
as a distribution layer and/or reference release... Please refer to Richard's 
earlier email in this thread for further clarification.

> I've heard bits and pieces of things changing but I guess I never knew
> enough of the TI roadmap to know for sure what I should be doing so
> that I steer our team/company in the right direction for all these
> changes.  I'm currently using Arago to generate our images (separate
> CSL toolchain (old), and the generated packages are old too).

The old Arago, which is based on the Classic OpenEmbedded, is used by several 
TI SDK products. Mostly due to the continuing support and maintenance of the 
existing products, the new development had constrained resources and slow 
progress.

-- 
Denys

Re: building Yocto for Pandaboard

[Philip Balister]

On 02/09/2012 08:36 AM, Denys Dmytriyenko wrote:
> On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
>>  On Wed, Feb 8, 2012 at 8:16 PM, William Mills <wmills@ti.com> wrote:
>>> As Gary said there has not been too many end user questions on meta-ti yet.
>>
>>  All I care about is meta-ti as that is what all our products are based
>>  on. I've been watching subject for a while now trying to discern all
>>  the issues and make a wise choice.
> 
> Brian,
> 
>>  I'm wanting to switch from Arago to whatever TI supports next as I
>>  supply the rest of our development team with tools and images that
>>  they build applications on for our products and I can't jerk them
>>  around changing distros.
> 
> As you are aware, Arago is not going away - there is work going on in 
> meta-arago layer to update/port it to the new Yocto infrastructure.
> 
> Arago/meta-arago is still going to be the official platform distribution for 
> TI SDK products. But, a separate meta-ti layer was created early in the 
> process to detach and unify the BSP layer and allow people to use TI hardware 
> with different distributions. And that's actually part of the problem, as 
> distributions like religions conflict with each other in a single layer... :)
> 

Denys, from my point of view, there are two issues we need to solve:

1) Defining the meta-ti toolchain dependencies. Angstrom uses gcc-4.5
for various reasons. Will the TI programs work against all gcc versions
available from oe-core/meta-oe?

2) Image construction pieces in oe-core are not all there yet. This is
what leads to angstrom specific bits creeping into the BSP layer. I've
talked with Paul Eggleton and Koen about this at FOSDEM. We should sit
down next week at ELC and see if we can come up with a set os tasks we
can push into oe-core that let all layer/distro combinations produce
working images.

Philip

Re: building Yocto for Pandaboard

[Brian Hutchinson]

On Thu, Feb 9, 2012 at 11:59 AM, Philip Balister <philip@balister.org> wrote:

> .... We should sit
> down next week at ELC and see if we can come up with a set os tasks we

I'd like to sit in on this too ... maybe you guys could straighten me
out (maybe being the key word) :)

Regards,

Brian

Re: building Yocto for Pandaboard

[Jeff Osier-Mixon]

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

On Thu, Feb 9, 2012 at 9:05 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Thu, Feb 9, 2012 at 11:59 AM, Philip Balister <philip@balister.org>
> wrote:
>
> > .... We should sit
> > down next week at ELC and see if we can come up with a set os tasks we
>
> I'd like to sit in on this too ... maybe you guys could straighten me
> out (maybe being the key word) :)
>

I would very much like to sit in the corner and take notes. I'll even buy a
round. :)


>
> Regards,
>
> Brian
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

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

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 10:17:15AM -0800, Jeff Osier-Mixon wrote:
> On Thu, Feb 9, 2012 at 9:05 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
> 
> > On Thu, Feb 9, 2012 at 11:59 AM, Philip Balister <philip@balister.org>
> > wrote:
> >
> > > .... We should sit
> > > down next week at ELC and see if we can come up with a set os tasks we
> >
> > I'd like to sit in on this too ... maybe you guys could straighten me
> > out (maybe being the key word) :)
> >
> 
> I would very much like to sit in the corner and take notes. I'll even buy a
> round. :)

Can you get us a room then? :)

-- 
Denys

Re: building Yocto for Pandaboard

[Jeff Osier-Mixon]

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

Absolutely, just name a time

On Thu, Feb 9, 2012 at 10:20 AM, Denys Dmytriyenko <denis@denix.org> wrote:

> On Thu, Feb 09, 2012 at 10:17:15AM -0800, Jeff Osier-Mixon wrote:
> > On Thu, Feb 9, 2012 at 9:05 AM, Brian Hutchinson <b.hutchman@gmail.com
> >wrote:
> >
> > > On Thu, Feb 9, 2012 at 11:59 AM, Philip Balister <philip@balister.org>
> > > wrote:
> > >
> > > > .... We should sit
> > > > down next week at ELC and see if we can come up with a set os tasks
> we
> > >
> > > I'd like to sit in on this too ... maybe you guys could straighten me
> > > out (maybe being the key word) :)
> > >
> >
> > I would very much like to sit in the corner and take notes. I'll even
> buy a
> > round. :)
>
> Can you get us a room then? :)
>
> --
> Denys
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

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

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-09 09:59, Philip Balister wrote:
> On 02/09/2012 08:36 AM, Denys Dmytriyenko wrote:
>> On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
>>>   On Wed, Feb 8, 2012 at 8:16 PM, William Mills<wmills@ti.com>  wrote:
>>>> As Gary said there has not been too many end user questions on meta-ti yet.
>>>
>>>   All I care about is meta-ti as that is what all our products are based
>>>   on. I've been watching subject for a while now trying to discern all
>>>   the issues and make a wise choice.
>>
>> Brian,
>>
>>>   I'm wanting to switch from Arago to whatever TI supports next as I
>>>   supply the rest of our development team with tools and images that
>>>   they build applications on for our products and I can't jerk them
>>>   around changing distros.
>>
>> As you are aware, Arago is not going away - there is work going on in
>> meta-arago layer to update/port it to the new Yocto infrastructure.
>>
>> Arago/meta-arago is still going to be the official platform distribution for
>> TI SDK products. But, a separate meta-ti layer was created early in the
>> process to detach and unify the BSP layer and allow people to use TI hardware
>> with different distributions. And that's actually part of the problem, as
>> distributions like religions conflict with each other in a single layer... :)
>>
>
> Denys, from my point of view, there are two issues we need to solve:
>
> 1) Defining the meta-ti toolchain dependencies. Angstrom uses gcc-4.5
> for various reasons. Will the TI programs work against all gcc versions
> available from oe-core/meta-oe?

I've had good luck with the meta-ti layer + Poky (oe-core & meta-yocto).
I have my own kernels (for other OMAP boards that are not mainline), so
I don't use the meta-ti kernel recipes, but I do use much of the rest,
including the DSP bits.

>
> 2) Image construction pieces in oe-core are not all there yet. This is
> what leads to angstrom specific bits creeping into the BSP layer. I've
> talked with Paul Eggleton and Koen about this at FOSDEM. We should sit
> down next week at ELC and see if we can come up with a set os tasks we
> can push into oe-core that let all layer/distro combinations produce
> working images.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 10:12:21AM -0700, Gary Thomas wrote:
> On 2012-02-09 09:59, Philip Balister wrote:
> >On 02/09/2012 08:36 AM, Denys Dmytriyenko wrote:
> >>On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
> >>>  On Wed, Feb 8, 2012 at 8:16 PM, William Mills<wmills@ti.com>  wrote:
> >>>>As Gary said there has not been too many end user questions on meta-ti yet.
> >>>
> >>>  All I care about is meta-ti as that is what all our products are based
> >>>  on. I've been watching subject for a while now trying to discern all
> >>>  the issues and make a wise choice.
> >>
> >>Brian,
> >>
> >>>  I'm wanting to switch from Arago to whatever TI supports next as I
> >>>  supply the rest of our development team with tools and images that
> >>>  they build applications on for our products and I can't jerk them
> >>>  around changing distros.
> >>
> >>As you are aware, Arago is not going away - there is work going on in
> >>meta-arago layer to update/port it to the new Yocto infrastructure.
> >>
> >>Arago/meta-arago is still going to be the official platform distribution for
> >>TI SDK products. But, a separate meta-ti layer was created early in the
> >>process to detach and unify the BSP layer and allow people to use TI hardware
> >>with different distributions. And that's actually part of the problem, as
> >>distributions like religions conflict with each other in a single layer... :)
> >>
> >
> >Denys, from my point of view, there are two issues we need to solve:
> >
> >1) Defining the meta-ti toolchain dependencies. Angstrom uses gcc-4.5
> >for various reasons. Will the TI programs work against all gcc versions
> >available from oe-core/meta-oe?
> 
> I've had good luck with the meta-ti layer + Poky (oe-core & meta-yocto).
> I have my own kernels (for other OMAP boards that are not mainline), so
> I don't use the meta-ti kernel recipes, but I do use much of the rest,
> including the DSP bits.

Can you elaborate on what your custom kernels are based on? Thanks.

-- 
Denys

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-09 10:15, Denys Dmytriyenko wrote:
> On Thu, Feb 09, 2012 at 10:12:21AM -0700, Gary Thomas wrote:
>> On 2012-02-09 09:59, Philip Balister wrote:
>>> On 02/09/2012 08:36 AM, Denys Dmytriyenko wrote:
>>>> On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
>>>>>   On Wed, Feb 8, 2012 at 8:16 PM, William Mills<wmills@ti.com>   wrote:
>>>>>> As Gary said there has not been too many end user questions on meta-ti yet.
>>>>>
>>>>>   All I care about is meta-ti as that is what all our products are based
>>>>>   on. I've been watching subject for a while now trying to discern all
>>>>>   the issues and make a wise choice.
>>>>
>>>> Brian,
>>>>
>>>>>   I'm wanting to switch from Arago to whatever TI supports next as I
>>>>>   supply the rest of our development team with tools and images that
>>>>>   they build applications on for our products and I can't jerk them
>>>>>   around changing distros.
>>>>
>>>> As you are aware, Arago is not going away - there is work going on in
>>>> meta-arago layer to update/port it to the new Yocto infrastructure.
>>>>
>>>> Arago/meta-arago is still going to be the official platform distribution for
>>>> TI SDK products. But, a separate meta-ti layer was created early in the
>>>> process to detach and unify the BSP layer and allow people to use TI hardware
>>>> with different distributions. And that's actually part of the problem, as
>>>> distributions like religions conflict with each other in a single layer... :)
>>>>
>>>
>>> Denys, from my point of view, there are two issues we need to solve:
>>>
>>> 1) Defining the meta-ti toolchain dependencies. Angstrom uses gcc-4.5
>>> for various reasons. Will the TI programs work against all gcc versions
>>> available from oe-core/meta-oe?
>>
>> I've had good luck with the meta-ti layer + Poky (oe-core&  meta-yocto).
>> I have my own kernels (for other OMAP boards that are not mainline), so
>> I don't use the meta-ti kernel recipes, but I do use much of the rest,
>> including the DSP bits.
>
> Can you elaborate on what your custom kernels are based on? Thanks.

Stock 3.0 (mainline) plus some local enhancements, board support, etc.
We also use Poky as the baseline for other products which are PowerPC based.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 08:59:51AM -0800, Philip Balister wrote:
> On 02/09/2012 08:36 AM, Denys Dmytriyenko wrote:
> > On Thu, Feb 09, 2012 at 11:23:14AM -0500, Brian Hutchinson wrote:
> >>  On Wed, Feb 8, 2012 at 8:16 PM, William Mills <wmills@ti.com> wrote:
> >>> As Gary said there has not been too many end user questions on meta-ti yet.
> >>
> >>  All I care about is meta-ti as that is what all our products are based
> >>  on. I've been watching subject for a while now trying to discern all
> >>  the issues and make a wise choice.
> > 
> > Brian,
> > 
> >>  I'm wanting to switch from Arago to whatever TI supports next as I
> >>  supply the rest of our development team with tools and images that
> >>  they build applications on for our products and I can't jerk them
> >>  around changing distros.
> > 
> > As you are aware, Arago is not going away - there is work going on in 
> > meta-arago layer to update/port it to the new Yocto infrastructure.
> > 
> > Arago/meta-arago is still going to be the official platform distribution for 
> > TI SDK products. But, a separate meta-ti layer was created early in the 
> > process to detach and unify the BSP layer and allow people to use TI hardware 
> > with different distributions. And that's actually part of the problem, as 
> > distributions like religions conflict with each other in a single layer... :)
> > 
> 
> Denys, from my point of view, there are two issues we need to solve:

Philip,

These are very good points you raise!

> 1) Defining the meta-ti toolchain dependencies. Angstrom uses gcc-4.5
> for various reasons. Will the TI programs work against all gcc versions
> available from oe-core/meta-oe?

We've discussed it internally and with some of the other involved parties. 
Right now gcc-4.5 with Linaro patches from meta-oe is still the recommended 
toolchain. We need to validate gcc-4.6 from oe-core though. Few people (Bill 
Mills and Khem Raj among others) are currently at Linaro Connect trying to 
convince Linaro guys to get serios and provide an official meta-linaro layer 
for Yocto.

> 2) Image construction pieces in oe-core are not all there yet. This is
> what leads to angstrom specific bits creeping into the BSP layer. I've
> talked with Paul Eggleton and Koen about this at FOSDEM. We should sit
> down next week at ELC and see if we can come up with a set os tasks we
> can push into oe-core that let all layer/distro combinations produce
> working images.

Some work has already started in regards to tasks and images in meta-ti and 
meta-arago to clean them up and simplify the dependencies. I agree, there is a 
need for a better framework from OE-Core to define base tasks and avoid 
cluttering BSP layers with distro-specific dependencies. Let's talk next week 
at ELC.

-- 
Denys

Re: building Yocto for Pandaboard

[Maupin, Chase]

> -----Original Message-----
> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> bounces@yoctoproject.org] On Behalf Of James Abernathy
> Sent: Wednesday, February 08, 2012 4:52 PM
> To: Gary Thomas
> Cc: meta-ti@yoctoproject.org
> Subject: Re: [meta-ti] building Yocto for Pandaboard
> 
> 
> On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:
> 
> > On 2012-02-08 15:27, Koen Kooi wrote:
> >>
> >> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende
> geschreven:
> >>
> >>> On 2012-02-08 15:18, Koen Kooi wrote:
> >>>>
> >>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende
> geschreven:
> >>>>
> >>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
> >>>>>> On 2012-02-08 14:58, jfabernathy wrote:
> >>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned
> the meta-ti repository in the poky directory and tried to build
> core-image-sato for both machine pandaboard and
> >>>>>>> omap4430-panda. However, I immediately get an error because
> bitbake is looking for recipes-images/angstrom/systemd-image.bb,
> which is required in the ti-hw-bringup-image.bb image
> >>>>>>> recipe.
> >>>>>>>
> >>>>>>> All I really included was the machine name change in
> local.conf and added the meta-ti layer in bblayers.conf.
> >>>>>>>
> >>>>>>> Did I miss a step?
> >>>>>>
> >>>>>> This was discussed last week.  Add this line to your
> local.conf
> >>>>>>  BBMASK = ".*/meta-ti/recipes-misc/"
> >>>>>> This will skip some BeagleBoard/BeagleBone recipes that are
> not
> >>>>>> currently working in a Yocto tree.
> >>>>>>
> >>>>> Thanks a bunch. That got it going.  The README said nothing
> >>>>
> >>>> Stop spreading such lies!
> >>>
> >>> It's not a lie, just a perspective.
> >>
> >> It *is* a lie, since the README is non-empty. Regardless of what
> you want to do, the README does contain content.
> >
> > Sorry, I thought you were referring to my work-around to get this
> > going in Yocto.  Obviously, he was looking for more info in the
> > README than just how to use this layer with Angstrom and I agree
> > that this "trick" probably does not belong in the README.
> >
> > --
> 
> Wow!  Sorry I jumped into a mailing list I obviously don't
> understand or belong in.  I apologize if I offended.  I did read
> the README, but it didn't make a bit of sense to me because it
> talked about angstrom, which I don't know anything about and
> wondered what that had to do with yocto.  My current Yocto
> knowledge is based on the meta-intel layer, which doesn't mention
> angstrom.  It sounds like the hint/trick that Gary mentioned will
> make bitbake build with just yocto, which is what I want.  My goal
> is more of a proof of concept.  I'd like to prove if you could take
> the same image recipe and move it from Pandaboard to Atom and vice
> versa.  That way a developer could pick the hardware platform based
> on the performance, features, and cost.  The software effort should
> be minimal to move if the Yocto concept works as advertised.

Jim, you are welcome here.  As was mentioned before there have been a lot of discussions about this layer.  One of the goals for the meta-ti layer will be to work with just oe-core and yocto and not require meta-angstrom.  We are moving that direction and the use case you are trying and your experiences with it are important.  Thanks for taking the time to give this a shot.

> 
> Jim A
> 
> > ------------------------------------------------------------
> > Gary Thomas                 |  Consulting for the
> > MLB Associates              |    Embedded world
> > ------------------------------------------------------------
> > _______________________________________________
> > meta-ti mailing list
> > meta-ti@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-ti
> 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: building Yocto for Pandaboard

[jfabernathy]

On 02/09/2012 08:01 AM, Maupin, Chase wrote:
>> -----Original Message-----
>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>> bounces@yoctoproject.org] On Behalf Of James Abernathy
>> Sent: Wednesday, February 08, 2012 4:52 PM
>> To: Gary Thomas
>> Cc: meta-ti@yoctoproject.org
>> Subject: Re: [meta-ti] building Yocto for Pandaboard
>>
>>
>> On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:
>>
>>> On 2012-02-08 15:27, Koen Kooi wrote:
>>>> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende
>> geschreven:
>>>>> On 2012-02-08 15:18, Koen Kooi wrote:
>>>>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende
>> geschreven:
>>>>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>>>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned
>> the meta-ti repository in the poky directory and tried to build
>> core-image-sato for both machine pandaboard and
>>>>>>>>> omap4430-panda. However, I immediately get an error because
>> bitbake is looking for recipes-images/angstrom/systemd-image.bb,
>> which is required in the ti-hw-bringup-image.bb image
>>>>>>>>> recipe.
>>>>>>>>>
>>>>>>>>> All I really included was the machine name change in
>> local.conf and added the meta-ti layer in bblayers.conf.
>>>>>>>>> Did I miss a step?
>>>>>>>> This was discussed last week.  Add this line to your
>> local.conf
>>>>>>>>   BBMASK = ".*/meta-ti/recipes-misc/"
>>>>>>>> This will skip some BeagleBoard/BeagleBone recipes that are
>> not
>>>>>>>> currently working in a Yocto tree.
>>>>>>>>
>>>>>>> Thanks a bunch. That got it going.  The README said nothing
>>>>>> Stop spreading such lies!
>>>>> It's not a lie, just a perspective.
>>>> It *is* a lie, since the README is non-empty. Regardless of what
>> you want to do, the README does contain content.
>>> Sorry, I thought you were referring to my work-around to get this
>>> going in Yocto.  Obviously, he was looking for more info in the
>>> README than just how to use this layer with Angstrom and I agree
>>> that this "trick" probably does not belong in the README.
>>>
>>> --
>> Wow!  Sorry I jumped into a mailing list I obviously don't
>> understand or belong in.  I apologize if I offended.  I did read
>> the README, but it didn't make a bit of sense to me because it
>> talked about angstrom, which I don't know anything about and
>> wondered what that had to do with yocto.  My current Yocto
>> knowledge is based on the meta-intel layer, which doesn't mention
>> angstrom.  It sounds like the hint/trick that Gary mentioned will
>> make bitbake build with just yocto, which is what I want.  My goal
>> is more of a proof of concept.  I'd like to prove if you could take
>> the same image recipe and move it from Pandaboard to Atom and vice
>> versa.  That way a developer could pick the hardware platform based
>> on the performance, features, and cost.  The software effort should
>> be minimal to move if the Yocto concept works as advertised.
> Jim, you are welcome here.  As was mentioned before there have been a lot of discussions about this layer.  One of the goals for the meta-ti layer will be to work with just oe-core and yocto and not require meta-angstrom.  We are moving that direction and the use case you are trying and your experiences with it are important.  Thanks for taking the time to give this a shot.
>
Thanks, glad the proof of concept falls into the groups thinking as 
well.  I will monitor for progress on the use of just the Yocto Linux 
for this POC.  I've tested Angstrom, and while it works on Pandaboard 
does not achieve what my goal is.

I did post another question regarding an error I got while building just 
with Yocto. Not sure if a solution for it exists yet without going down 
the Angstrom route as others have suggested.

Thanks again,

JIm A

>> Jim A
>>
>>> ------------------------------------------------------------
>>> Gary Thomas                 |  Consulting for the
>>> MLB Associates              |    Embedded world
>>> ------------------------------------------------------------
>>> _______________________________________________
>>> meta-ti mailing list
>>> meta-ti@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-ti
>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti

Re: building Yocto for Pandaboard

[Koen Kooi]

Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:

> On 02/09/2012 08:01 AM, Maupin, Chase wrote:
>>> -----Original Message-----
>>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>>> bounces@yoctoproject.org] On Behalf Of James Abernathy
>>> Sent: Wednesday, February 08, 2012 4:52 PM
>>> To: Gary Thomas
>>> Cc: meta-ti@yoctoproject.org
>>> Subject: Re: [meta-ti] building Yocto for Pandaboard
>>> 
>>> 
>>> On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:
>>> 
>>>> On 2012-02-08 15:27, Koen Kooi wrote:
>>>>> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende
>>> geschreven:
>>>>>> On 2012-02-08 15:18, Koen Kooi wrote:
>>>>>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende
>>> geschreven:
>>>>>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>>>>>>>>> On 2012-02-08 14:58, jfabernathy wrote:
>>>>>>>>>> I'm trying to build the pandaboard BSP for Yocto. I cloned
>>> the meta-ti repository in the poky directory and tried to build
>>> core-image-sato for both machine pandaboard and
>>>>>>>>>> omap4430-panda. However, I immediately get an error because
>>> bitbake is looking for recipes-images/angstrom/systemd-image.bb,
>>> which is required in the ti-hw-bringup-image.bb image
>>>>>>>>>> recipe.
>>>>>>>>>> 
>>>>>>>>>> All I really included was the machine name change in
>>> local.conf and added the meta-ti layer in bblayers.conf.
>>>>>>>>>> Did I miss a step?
>>>>>>>>> This was discussed last week.  Add this line to your
>>> local.conf
>>>>>>>>>  BBMASK = ".*/meta-ti/recipes-misc/"
>>>>>>>>> This will skip some BeagleBoard/BeagleBone recipes that are
>>> not
>>>>>>>>> currently working in a Yocto tree.
>>>>>>>>> 
>>>>>>>> Thanks a bunch. That got it going.  The README said nothing
>>>>>>> Stop spreading such lies!
>>>>>> It's not a lie, just a perspective.
>>>>> It *is* a lie, since the README is non-empty. Regardless of what
>>> you want to do, the README does contain content.
>>>> Sorry, I thought you were referring to my work-around to get this
>>>> going in Yocto.  Obviously, he was looking for more info in the
>>>> README than just how to use this layer with Angstrom and I agree
>>>> that this "trick" probably does not belong in the README.
>>>> 
>>>> --
>>> Wow!  Sorry I jumped into a mailing list I obviously don't
>>> understand or belong in.  I apologize if I offended.  I did read
>>> the README, but it didn't make a bit of sense to me because it
>>> talked about angstrom, which I don't know anything about and
>>> wondered what that had to do with yocto.  My current Yocto
>>> knowledge is based on the meta-intel layer, which doesn't mention
>>> angstrom.  It sounds like the hint/trick that Gary mentioned will
>>> make bitbake build with just yocto, which is what I want.  My goal
>>> is more of a proof of concept.  I'd like to prove if you could take
>>> the same image recipe and move it from Pandaboard to Atom and vice
>>> versa.  That way a developer could pick the hardware platform based
>>> on the performance, features, and cost.  The software effort should
>>> be minimal to move if the Yocto concept works as advertised.
>> Jim, you are welcome here.  As was mentioned before there have been a lot of discussions about this layer.  One of the goals for the meta-ti layer will be to work with just oe-core and yocto and not require meta-angstrom.  We are moving that direction and the use case you are trying and your experiences with it are important.  Thanks for taking the time to give this a shot.
>> 
> Thanks, glad the proof of concept falls into the groups thinking as well.  I will monitor for progress on the use of just the Yocto Linux for this POC.

Yocto or Poky? Because if you want yocto, angstrom very much *is* yocto. If you want Poky, that's something different.

Re: building Yocto for Pandaboard

[Maupin, Chase]

> -----Original Message-----
> From: Koen Kooi [mailto:koen@dominion.thruhere.net]
> Sent: Thursday, February 09, 2012 7:54 AM
> To: jfabernathy
> Cc: Maupin, Chase; meta-ti@yoctoproject.org
> Subject: Re: [meta-ti] building Yocto for Pandaboard
> 
> 
> Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:
> 
> > On 02/09/2012 08:01 AM, Maupin, Chase wrote:
> >>> -----Original Message-----
> >>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> >>> bounces@yoctoproject.org] On Behalf Of James Abernathy
> >>> Sent: Wednesday, February 08, 2012 4:52 PM
> >>> To: Gary Thomas
> >>> Cc: meta-ti@yoctoproject.org
> >>> Subject: Re: [meta-ti] building Yocto for Pandaboard
> >>>
> >>>
> >>> On Feb 8, 2012, at 5:34 PM, Gary Thomas wrote:
> >>>
> >>>> On 2012-02-08 15:27, Koen Kooi wrote:
> >>>>> Op 8 feb. 2012, om 23:22 heeft Gary Thomas het volgende
> >>> geschreven:
> >>>>>> On 2012-02-08 15:18, Koen Kooi wrote:
> >>>>>>> Op 8 feb. 2012, om 23:11 heeft jfabernathy het volgende
> >>> geschreven:
> >>>>>>>> On 02/08/2012 05:05 PM, Gary Thomas wrote:
> >>>>>>>>> On 2012-02-08 14:58, jfabernathy wrote:
> >>>>>>>>>> I'm trying to build the pandaboard BSP for Yocto. I
> cloned
> >>> the meta-ti repository in the poky directory and tried to build
> >>> core-image-sato for both machine pandaboard and
> >>>>>>>>>> omap4430-panda. However, I immediately get an error
> because
> >>> bitbake is looking for recipes-images/angstrom/systemd-
> image.bb,
> >>> which is required in the ti-hw-bringup-image.bb image
> >>>>>>>>>> recipe.
> >>>>>>>>>>
> >>>>>>>>>> All I really included was the machine name change in
> >>> local.conf and added the meta-ti layer in bblayers.conf.
> >>>>>>>>>> Did I miss a step?
> >>>>>>>>> This was discussed last week.  Add this line to your
> >>> local.conf
> >>>>>>>>>  BBMASK = ".*/meta-ti/recipes-misc/"
> >>>>>>>>> This will skip some BeagleBoard/BeagleBone recipes that
> are
> >>> not
> >>>>>>>>> currently working in a Yocto tree.
> >>>>>>>>>
> >>>>>>>> Thanks a bunch. That got it going.  The README said
> nothing
> >>>>>>> Stop spreading such lies!
> >>>>>> It's not a lie, just a perspective.
> >>>>> It *is* a lie, since the README is non-empty. Regardless of
> what
> >>> you want to do, the README does contain content.
> >>>> Sorry, I thought you were referring to my work-around to get
> this
> >>>> going in Yocto.  Obviously, he was looking for more info in
> the
> >>>> README than just how to use this layer with Angstrom and I
> agree
> >>>> that this "trick" probably does not belong in the README.
> >>>>
> >>>> --
> >>> Wow!  Sorry I jumped into a mailing list I obviously don't
> >>> understand or belong in.  I apologize if I offended.  I did
> read
> >>> the README, but it didn't make a bit of sense to me because it
> >>> talked about angstrom, which I don't know anything about and
> >>> wondered what that had to do with yocto.  My current Yocto
> >>> knowledge is based on the meta-intel layer, which doesn't
> mention
> >>> angstrom.  It sounds like the hint/trick that Gary mentioned
> will
> >>> make bitbake build with just yocto, which is what I want.  My
> goal
> >>> is more of a proof of concept.  I'd like to prove if you could
> take
> >>> the same image recipe and move it from Pandaboard to Atom and
> vice
> >>> versa.  That way a developer could pick the hardware platform
> based
> >>> on the performance, features, and cost.  The software effort
> should
> >>> be minimal to move if the Yocto concept works as advertised.
> >> Jim, you are welcome here.  As was mentioned before there have
> been a lot of discussions about this layer.  One of the goals for
> the meta-ti layer will be to work with just oe-core and yocto and
> not require meta-angstrom.  We are moving that direction and the
> use case you are trying and your experiences with it are important.
> Thanks for taking the time to give this a shot.
> >>
> > Thanks, glad the proof of concept falls into the groups thinking
> as well.  I will monitor for progress on the use of just the Yocto
> Linux for this POC.
> 
> Yocto or Poky? Because if you want yocto, angstrom very much *is*
> yocto. If you want Poky, that's something different.

I believe it is fair to say that that we should be able to use meta-ti with only openembedded-core and also with openembedded-core + meta-yocto.  Basically if there is something in meta-ti that requires things in meta-angstrom then those should be moved to either meta-angstrom or meta-arago correct?



> 

Re: building Yocto for Pandaboard

[Richard Purdie]

On Thu, 2012-02-09 at 14:54 +0100, Koen Kooi wrote:
> Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:
> > On 02/09/2012 08:01 AM, Maupin, Chase wrote:
> >>> Wow!  Sorry I jumped into a mailing list I obviously don't
> >>> understand or belong in.  I apologize if I offended.  I did read
> >>> the README, but it didn't make a bit of sense to me because it
> >>> talked about angstrom, which I don't know anything about and
> >>> wondered what that had to do with yocto.  My current Yocto
> >>> knowledge is based on the meta-intel layer, which doesn't mention
> >>> angstrom.  It sounds like the hint/trick that Gary mentioned will
> >>> make bitbake build with just yocto, which is what I want.  My goal
> >>> is more of a proof of concept.  I'd like to prove if you could take
> >>> the same image recipe and move it from Pandaboard to Atom and vice
> >>> versa.  That way a developer could pick the hardware platform based
> >>> on the performance, features, and cost.  The software effort should
> >>> be minimal to move if the Yocto concept works as advertised.
> >> Jim, you are welcome here.  As was mentioned before there have been
> a lot of discussions about this layer.  One of the goals for the
> meta-ti layer will be to work with just oe-core and yocto and not
> require meta-angstrom.  We are moving that direction and the use case
> you are trying and your experiences with it are important.  Thanks for
> taking the time to give this a shot.
> >> 
> > Thanks, glad the proof of concept falls into the groups thinking as
> well.  I will monitor for progress on the use of just the Yocto Linux
> for this POC.
>
> Yocto or Poky? Because if you want yocto, angstrom very much *is*
> yocto. If you want Poky, that's something different.

I think there are a few things need to get cleared up here as this is
likely confusing for people.

The Yocto Project is the overall project which is working on improving
embedded Linux for people in whatever areas those improvements are
needed in. This involves things like eglibc, creating standard formats
for hardware definitions (BSPs) and has also involved some work on build
system which are derived from OpenEmbedded.

The Yocto Project uses Poky as its reference build system which is a
combination of Bitbake, OE-Core, a load of documentation and a very
small shim called meta-yocto. Its purpose is to provide a known good
base system people can build on top of by adding layers.

Angstrom is similar to Poky in that its a mix of components allowing
people to build things. It includes Bitbake and OE-Core and some other
pieces. It has an equivalent to meta-yocto with different functionality.
I'll let Koen as one of its maintainers describe what its purpose is.
One difference is that is has a specific set of hardware targets and
provides prebuilt package feeds which Poky does not (nor does the Yocto
Project).

meta-ti is intended as a hardware support layer for various TI products.

The trouble is that some of these components have been around for a
while and it hasn't always been possible to neatly layer things. In
particular, meta-ti historically has a dependency on Angstrom.

Work is underway to remove that dependency so meta-ti can operate freely
with both Poky and Angstrom, or just with OE-Core and Bitbake as
separate pieces. There is no architectural problem with this and it is
the intention of everyone involved. There is the question of sorting
some of the mechanics and making the change whilst not causing problems
for existing users. I'm really happy to see progress on this!

So in answer to Jim's question, you will be able to use meta-ti with
Poky directly but right now, there are some details being worked through
and it doesn't quite work. Perhaps we could mention that in the meta-ti
README so people can see what the plan is as well as the current
situation?

Cheers,

Richard

Re: building Yocto for Pandaboard

[jfabernathy]

On 02/09/2012 10:33 AM, Richard Purdie wrote:
> On Thu, 2012-02-09 at 14:54 +0100, Koen Kooi wrote:
>> Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:
>>> On 02/09/2012 08:01 AM, Maupin, Chase wrote:
>>>>> Wow!  Sorry I jumped into a mailing list I obviously don't
>>>>> understand or belong in.  I apologize if I offended.  I did read
>>>>> the README, but it didn't make a bit of sense to me because it
>>>>> talked about angstrom, which I don't know anything about and
>>>>> wondered what that had to do with yocto.  My current Yocto
>>>>> knowledge is based on the meta-intel layer, which doesn't mention
>>>>> angstrom.  It sounds like the hint/trick that Gary mentioned will
>>>>> make bitbake build with just yocto, which is what I want.  My goal
>>>>> is more of a proof of concept.  I'd like to prove if you could take
>>>>> the same image recipe and move it from Pandaboard to Atom and vice
>>>>> versa.  That way a developer could pick the hardware platform based
>>>>> on the performance, features, and cost.  The software effort should
>>>>> be minimal to move if the Yocto concept works as advertised.
>>>> Jim, you are welcome here.  As was mentioned before there have been
>> a lot of discussions about this layer.  One of the goals for the
>> meta-ti layer will be to work with just oe-core and yocto and not
>> require meta-angstrom.  We are moving that direction and the use case
>> you are trying and your experiences with it are important.  Thanks for
>> taking the time to give this a shot.
>>> Thanks, glad the proof of concept falls into the groups thinking as
>> well.  I will monitor for progress on the use of just the Yocto Linux
>> for this POC.
>>
>> Yocto or Poky? Because if you want yocto, angstrom very much *is*
>> yocto. If you want Poky, that's something different.
> I think there are a few things need to get cleared up here as this is
> likely confusing for people.
>
> The Yocto Project is the overall project which is working on improving
> embedded Linux for people in whatever areas those improvements are
> needed in. This involves things like eglibc, creating standard formats
> for hardware definitions (BSPs) and has also involved some work on build
> system which are derived from OpenEmbedded.
>
> The Yocto Project uses Poky as its reference build system which is a
> combination of Bitbake, OE-Core, a load of documentation and a very
> small shim called meta-yocto. Its purpose is to provide a known good
> base system people can build on top of by adding layers.
>
> Angstrom is similar to Poky in that its a mix of components allowing
> people to build things. It includes Bitbake and OE-Core and some other
> pieces. It has an equivalent to meta-yocto with different functionality.
> I'll let Koen as one of its maintainers describe what its purpose is.
> One difference is that is has a specific set of hardware targets and
> provides prebuilt package feeds which Poky does not (nor does the Yocto
> Project).
>
> meta-ti is intended as a hardware support layer for various TI products.
>
> The trouble is that some of these components have been around for a
> while and it hasn't always been possible to neatly layer things. In
> particular, meta-ti historically has a dependency on Angstrom.
>
> Work is underway to remove that dependency so meta-ti can operate freely
> with both Poky and Angstrom, or just with OE-Core and Bitbake as
> separate pieces. There is no architectural problem with this and it is
> the intention of everyone involved. There is the question of sorting
> some of the mechanics and making the change whilst not causing problems
> for existing users. I'm really happy to see progress on this!
>
> So in answer to Jim's question, you will be able to use meta-ti with
> Poky directly but right now, there are some details being worked through
> and it doesn't quite work. Perhaps we could mention that in the meta-ti
> README so people can see what the plan is as well as the current
> situation?
>
> Cheers,
>
> Richard
>
When you look at Yocto project from a marketing point of view, which is 
not something the open source community usually concentrates on for 
obvious reasons, it would be a very positive message to be able to talk 
about, and demonstrate with examples of taking the same project and 
moving it from one architecture to another with minimal effort, as long 
as both architectures supported the key features like media playback 
acceleration, 3D, sound, HDMI, etc.

While hardware companies tend to cringe when you make it too easy to 
move back and forth, the reality is, if you have a high volume product 
you can't justify or afford to throw excess performance, thermals, 
power, and cost where it is not needed.  For example a cheap digital 
signage application that just throws advertisement, or menu data on the 
screen could be done with an ARM processor like OMP3/4, but if you had a 
higher end product that needed to do extensive video analytics for 
customer profiling and advertising effectiveness, you're going to want a 
Core i5/i7.  It would be of great benefit to take the Yocto project that 
did the digital sign on the ARM and quickly get it up and running on the 
Core i5 and then concentrate on the analytics application.

I think this portability is a better sell, if it's all Yocto.  We all 
know that really smart people can move around from different Linux 
versions and development methods, but it's an easier sale to a customer 
management when you say it can all be done on Yocto and that it's easily 
demonstrated.

JIm A

>
>
>

Re: building Yocto for Pandaboard

[Jack Mitchell]

On 09/02/12 16:30, jfabernathy wrote:
> On 02/09/2012 10:33 AM, Richard Purdie wrote:
>> On Thu, 2012-02-09 at 14:54 +0100, Koen Kooi wrote:
>>> Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:
>>>> On 02/09/2012 08:01 AM, Maupin, Chase wrote:
>>>>>> Wow!  Sorry I jumped into a mailing list I obviously don't
>>>>>> understand or belong in.  I apologize if I offended.  I did read
>>>>>> the README, but it didn't make a bit of sense to me because it
>>>>>> talked about angstrom, which I don't know anything about and
>>>>>> wondered what that had to do with yocto.  My current Yocto
>>>>>> knowledge is based on the meta-intel layer, which doesn't mention
>>>>>> angstrom.  It sounds like the hint/trick that Gary mentioned will
>>>>>> make bitbake build with just yocto, which is what I want.  My goal
>>>>>> is more of a proof of concept.  I'd like to prove if you could take
>>>>>> the same image recipe and move it from Pandaboard to Atom and vice
>>>>>> versa.  That way a developer could pick the hardware platform based
>>>>>> on the performance, features, and cost.  The software effort should
>>>>>> be minimal to move if the Yocto concept works as advertised.
>>>>> Jim, you are welcome here.  As was mentioned before there have been
>>> a lot of discussions about this layer.  One of the goals for the
>>> meta-ti layer will be to work with just oe-core and yocto and not
>>> require meta-angstrom.  We are moving that direction and the use case
>>> you are trying and your experiences with it are important.  Thanks for
>>> taking the time to give this a shot.
>>>> Thanks, glad the proof of concept falls into the groups thinking as
>>> well.  I will monitor for progress on the use of just the Yocto Linux
>>> for this POC.
>>>
>>> Yocto or Poky? Because if you want yocto, angstrom very much *is*
>>> yocto. If you want Poky, that's something different.
>> I think there are a few things need to get cleared up here as this is
>> likely confusing for people.
>>
>> The Yocto Project is the overall project which is working on improving
>> embedded Linux for people in whatever areas those improvements are
>> needed in. This involves things like eglibc, creating standard formats
>> for hardware definitions (BSPs) and has also involved some work on build
>> system which are derived from OpenEmbedded.
>>
>> The Yocto Project uses Poky as its reference build system which is a
>> combination of Bitbake, OE-Core, a load of documentation and a very
>> small shim called meta-yocto. Its purpose is to provide a known good
>> base system people can build on top of by adding layers.
>>
>> Angstrom is similar to Poky in that its a mix of components allowing
>> people to build things. It includes Bitbake and OE-Core and some other
>> pieces. It has an equivalent to meta-yocto with different functionality.
>> I'll let Koen as one of its maintainers describe what its purpose is.
>> One difference is that is has a specific set of hardware targets and
>> provides prebuilt package feeds which Poky does not (nor does the Yocto
>> Project).
>>
>> meta-ti is intended as a hardware support layer for various TI products.
>>
>> The trouble is that some of these components have been around for a
>> while and it hasn't always been possible to neatly layer things. In
>> particular, meta-ti historically has a dependency on Angstrom.
>>
>> Work is underway to remove that dependency so meta-ti can operate freely
>> with both Poky and Angstrom, or just with OE-Core and Bitbake as
>> separate pieces. There is no architectural problem with this and it is
>> the intention of everyone involved. There is the question of sorting
>> some of the mechanics and making the change whilst not causing problems
>> for existing users. I'm really happy to see progress on this!
>>
>> So in answer to Jim's question, you will be able to use meta-ti with
>> Poky directly but right now, there are some details being worked through
>> and it doesn't quite work. Perhaps we could mention that in the meta-ti
>> README so people can see what the plan is as well as the current
>> situation?
>>
>> Cheers,
>>
>> Richard
>>
> When you look at Yocto project from a marketing point of view, which 
> is not something the open source community usually concentrates on for 
> obvious reasons, it would be a very positive message to be able to 
> talk about, and demonstrate with examples of taking the same project 
> and moving it from one architecture to another with minimal effort, as 
> long as both architectures supported the key features like media 
> playback acceleration, 3D, sound, HDMI, etc.
>
> While hardware companies tend to cringe when you make it too easy to 
> move back and forth, the reality is, if you have a high volume product 
> you can't justify or afford to throw excess performance, thermals, 
> power, and cost where it is not needed.  For example a cheap digital 
> signage application that just throws advertisement, or menu data on 
> the screen could be done with an ARM processor like OMP3/4, but if you 
> had a higher end product that needed to do extensive video analytics 
> for customer profiling and advertising effectiveness, you're going to 
> want a Core i5/i7.  It would be of great benefit to take the Yocto 
> project that did the digital sign on the ARM and quickly get it up and 
> running on the Core i5 and then concentrate on the analytics application.
>
> I think this portability is a better sell, if it's all Yocto.  We all 
> know that really smart people can move around from different Linux 
> versions and development methods, but it's an easier sale to a 
> customer management when you say it can all be done on Yocto and that 
> it's easily demonstrated.
>
> JIm A
>
>>
>>
>>
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Jim,

This is the exact scenario that I am undergoing with my company. I am 
attempting to use Yocto to prove platform mobility under Linux with a 
common set of applications which can then be specialised on a per 
product/hardware basis. It seems as though this is a very lucrative idea 
with the speed of SoC development these days!

Regards,
Jack.

Re: building Yocto for Pandaboard

[Philip Balister]

On 02/09/2012 08:30 AM, jfabernathy wrote:

...

>> Richard
>>
> When you look at Yocto project from a marketing point of view, which is
> not something the open source community usually concentrates on for
> obvious reasons, it would be a very positive message to be able to talk
> about, and demonstrate with examples of taking the same project and
> moving it from one architecture to another with minimal effort, as long
> as both architectures supported the key features like media playback
> acceleration, 3D, sound, HDMI, etc.
> 

Actually, at least some of us in the open source community pay close
attention to marketing.

> While hardware companies tend to cringe when you make it too easy to
> move back and forth, the reality is, if you have a high volume product
> you can't justify or afford to throw excess performance, thermals,
> power, and cost where it is not needed.  For example a cheap digital
> signage application that just throws advertisement, or menu data on the
> screen could be done with an ARM processor like OMP3/4, but if you had a
> higher end product that needed to do extensive video analytics for
> customer profiling and advertising effectiveness, you're going to want a
> Core i5/i7.  It would be of great benefit to take the Yocto project that
> did the digital sign on the ARM and quickly get it up and running on the
> Core i5 and then concentrate on the analytics application.
> 
> I think this portability is a better sell, if it's all Yocto.  We all
> know that really smart people can move around from different Linux
> versions and development methods, but it's an easier sale to a customer
> management when you say it can all be done on Yocto and that it's easily
> demonstrated.

Yocto is becoming a very overloaded word at the moment. But the key idea
is that we can focus on building out from oe-core to support our
products using the same tools, no matter what the product scale. From
very simple devices to products that resemble their desktop brothers.

Philip

> 
> JIm A
> 
>>
>>
>>
> 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: building Yocto for Pandaboard

[Denys Dmytriyenko]

On Thu, Feb 09, 2012 at 03:33:47PM +0000, Richard Purdie wrote:
> On Thu, 2012-02-09 at 14:54 +0100, Koen Kooi wrote:
> > Op 9 feb. 2012, om 14:11 heeft jfabernathy het volgende geschreven:
> > > On 02/09/2012 08:01 AM, Maupin, Chase wrote:
> > >> Jim, you are welcome here.  As was mentioned before there have been
> > a lot of discussions about this layer.  One of the goals for the
> > meta-ti layer will be to work with just oe-core and yocto and not
> > require meta-angstrom.  We are moving that direction and the use case
> > you are trying and your experiences with it are important.  Thanks for
> > taking the time to give this a shot.
> > >> 
> > > Thanks, glad the proof of concept falls into the groups thinking as
> > well.  I will monitor for progress on the use of just the Yocto Linux
> > for this POC.
> >
> > Yocto or Poky? Because if you want yocto, angstrom very much *is*
> > yocto. If you want Poky, that's something different.
> 
> I think there are a few things need to get cleared up here as this is
> likely confusing for people.
> 
> The Yocto Project is the overall project which is working on improving
> embedded Linux for people in whatever areas those improvements are
> needed in. This involves things like eglibc, creating standard formats
> for hardware definitions (BSPs) and has also involved some work on build
> system which are derived from OpenEmbedded.
> 
> The Yocto Project uses Poky as its reference build system which is a
> combination of Bitbake, OE-Core, a load of documentation and a very
> small shim called meta-yocto. Its purpose is to provide a known good
> base system people can build on top of by adding layers.
> 
> Angstrom is similar to Poky in that its a mix of components allowing
> people to build things. It includes Bitbake and OE-Core and some other
> pieces. It has an equivalent to meta-yocto with different functionality.
> I'll let Koen as one of its maintainers describe what its purpose is.
> One difference is that is has a specific set of hardware targets and
> provides prebuilt package feeds which Poky does not (nor does the Yocto
> Project).
> 
> meta-ti is intended as a hardware support layer for various TI products.
> 
> The trouble is that some of these components have been around for a
> while and it hasn't always been possible to neatly layer things. In
> particular, meta-ti historically has a dependency on Angstrom.
> 
> Work is underway to remove that dependency so meta-ti can operate freely
> with both Poky and Angstrom, or just with OE-Core and Bitbake as
> separate pieces. There is no architectural problem with this and it is
> the intention of everyone involved. There is the question of sorting
> some of the mechanics and making the change whilst not causing problems
> for existing users. I'm really happy to see progress on this!
> 
> So in answer to Jim's question, you will be able to use meta-ti with
> Poky directly but right now, there are some details being worked through
> and it doesn't quite work. Perhaps we could mention that in the meta-ti
> README so people can see what the plan is as well as the current
> situation?

Richard,

Thank you for such a detailed and constructive message!

I won't repeat what has been already said several times about our plans to 
ensure meta-ti works with other distributions and OE-Core only...

I just wanted to clarify the historical dependency of meta-ti on Angstrom, 
as it's initial focus, driven by Koen and Jason, was mostly on supporting 
existing BeagleBoard platforms and recently released BeagleBone. The lack 
of flexibility is rather unintentional. :)

-- 
Denys

Re: building Yocto for Pandaboard

[Gary Thomas]

On 2012-02-08 15:11, jfabernathy wrote:
> On 02/08/2012 05:05 PM, Gary Thomas wrote:
>> On 2012-02-08 14:58, jfabernathy wrote:
>>> I'm trying to build the pandaboard BSP for Yocto. I cloned the meta-ti repository in the poky directory and tried to build core-image-sato for both machine pandaboard and
>>> omap4430-panda. However, I immediately get an error because bitbake is looking for recipes-images/angstrom/systemd-image.bb, which is required in the ti-hw-bringup-image.bb image
>>> recipe.
>>>
>>> All I really included was the machine name change in local.conf and added the meta-ti layer in bblayers.conf.
>>>
>>> Did I miss a step?
>>
>> This was discussed last week. Add this line to your local.conf
>> BBMASK = ".*/meta-ti/recipes-misc/"
>> This will skip some BeagleBoard/BeagleBone recipes that are not
>> currently working in a Yocto tree.
>>
> Thanks a bunch. That got it going. The README said nothing, so I'm glad you jumped in with this hint. I just joined the meta-ti mailing list today.

The README assumes you want to build using Angstrom.  I've found that
with only a little extra care, you can use this layer just fine with
Yocto.

As for the meta-ti mailing list, it hasn't seen much of anything except
discussions about how to manage the layer.  Certainly not user-level
questions like this.  Also, my mention of BBMASK was on the Yocto list :-)

>
> I know I'm going to need a pointer to how to put the yocto image on an SDcard. I would assume it's similar to how you put ubuntu or angstrom??

You can use (or adapt) this script http://angstrom.s3.amazonaws.com/demo/beagleboard/mkcard.txt

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------