• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 600 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Getting started with Openembedded / Angstrom on Omap3evm - cannot compile x-loader.

Chris Cotton
Prodigy 30 points

I have recently received an omap3evm and a gumstix board, and am currently taking my first steps learning how to use embedded linux.  I have set up a cross compile environment for openembedded, based upon instructions for the beagleboard which I found at: http://elinux.org/BeagleBoardAndOpenEmbeddedGit .  However, while I can compile most things without any problems, I have been unable to compile the x-loader for the omap3evm.

My local.conf file is set to:

DISTRO = "angstrom-2008.1"
BBFILES = "/home/omap/oe/openembedded/recipes/*/*.bb"
TMPDIR = "/home/omap/oe/tmp"
MACHINE = "omap3evm"
ENABLE_BINARY_LOCALE_GENERATION = "0"

And I have pulled the most recent changes from the 2009/stable git tree.

If I try to bitbake x-load, I get the following error:

NOTE: Running task 325 of 475 (ID: 7, /home/omap/oe/openembedded/recipes/x-load/x-load_git.bb, do_compile)
NOTE: package x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7: task do_compile: started
ERROR: function do_compile failed
ERROR: see log in /home/omap/oe/tmp/work/omap3evm-angstrom-linux-gnueabi/x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7/temp/log.do_compile.7898
NOTE: Task failed: /home/omap/oe/tmp/work/omap3evm-angstrom-linux-gnueabi/x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7/temp/log.do_compile.7898
NOTE: package x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7: task do_compile: failed
ERROR: TaskFailed event exception, aborting
ERROR: Build of /home/omap/oe/openembedded/recipes/x-load/x-load_git.bb do_compile failed
ERROR: Task 7 (/home/omap/oe/openembedded/recipes/x-load/x-load_git.bb, do_compile) failed
NOTE: Tasks Summary: Attempted 324 tasks of which 324 didn't need to be rerun and 1 failed.
ERROR: '/home/omap/oe/openembedded/recipes/x-load/x-load_git.bb' failed

Looking at the log file, I have the following (only relevant part of file shown):

arm-angstrom-linux-gnueabi-gcc -g  -Os   -fno-strict-aliasing  -fno-common -ffixed-r8  -D__KERNEL__ -DTEXT_BASE=0x40200800 -I/home/omap/oe/tmp/work/omap3evm-angstrom-linux-gnueabi/x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7/git/include -fno-builtin -ffreestanding -nostdinc -isystem /home/omap/oe/tmp/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.1/include -pipe  -DCONFIG_ARM -D__ARM__ -march=armv7-a  -Wall -Wstrict-prototypes -c -o board.o board.c
board.c: In function 'init_func_i2c':
board.c:52: warning: implicit declaration of function 'i2c_init'
board.c:52: error: 'CFG_I2C_SPEED' undeclared (first use in this function)
board.c:52: error: (Each undeclared identifier is reported only once
board.c:52: error: for each function it appears in.)
board.c:52: error: 'CFG_I2C_SLAVE' undeclared (first use in this function)
board.c: In function 'start_armboot':
board.c:83: warning: implicit declaration of function 'misc_init_r'
board.c:89: warning: implicit declaration of function 'mmc_init'
board.c:102: warning: implicit declaration of function 'get_mem_type'
board.c:75: warning: unused variable 'dev_desc'
make[1]: *** [board.o] Error 1
make[1]: Leaving directory `/home/omap/oe/tmp/work/omap3evm-angstrom-linux-gnueabi/x-load-1_1.42+r7+gitr73eb0caf065b3b3f407d8af5c4836624e5cc7b69-r7/git/lib'
make: *** [lib/libarm.a] Error 2
FATAL: oe_runmake failed

I have looked at board.c, and noticed that there was no inclusion of <i2c.h>.  However, adding this only rectified the line "board.c:52: warning: implicit declaration of function 'i2c_init'" and did not resolve the problems.  I think it is also worth mentioning that when I changed the machine in my local.conf file to "overo" for the gumstix overo, the x-loader compiled without errors and appears to work fine on the overo.  The board.c used in the overo build is identical to the one that is failing here.  Rummaging around the system, I have not yet managed to work out where the declarations for CFG_I2C_SPEED and CFG_I2C_SLAVE are being satisfied.

As a last note, in case it is relevant my host PC is running Ubuntu 8.10.

I have no idea what to do from here.  I had assumed that gumstix / beagleboard and the omap3evm were similar enough that the instructions I had followed would work for all of them.  Any suggestions on what I should be doing to make this work / what I am doing wrong are greatly appreciated.

 

  • 0
    TI__Mastermind 37340 points

    gumstix, beagle and mistral evm boards all use the omap35x silicon, but the hardware boards are different and so is the software to some extent.  this community primarily supports the mistral omap35x evm; beagle has its own community (www.beagleboard.org ), and I believe so does gumstix (http://www.gumstix.com/support.html ).  This does not mean you will not get a response here for the questions above (from time to time someone familiar with other boards do chime in), but I just wanted raise awarness of the target audience in this community and that other communities exist for the corresponding boards. 

  • 0 in reply to Juan Gonzales
    Prodigy 30 points

    I realise this, the question I put forward is indeed for the Mistral development board (referred to as "omap3evm" by the openembedded community).  I mentioned the gumstix as I am also going to be doing development for that target board, and I have no problems compiling x-loader for it using the same development machine.

    The problem I am having is that I am getting the errors I mentioned in my previous post when trying to compile x-loader for the Mistral omap35x evm.

  • 0 in reply to Chris Cotton
    TI__Mastermind 37340 points

    Apologies, I was focused on the open-embedded article on beagle that I missed that part.  I was doing some digging around and found this http://code.google.com/p/beagleboard/wiki/HowToGetAngstromRunning.  I am not sure how useful this is, but I figure I pass the information along just in case.

    Hopefully someone more familiar with the subject will chime in and be able to offer more help.

  • 0 in reply to Juan Gonzales
    Prodigy 30 points

    Thanks for the reply.

    Unfortunately, that is the page I found too - the first link in the 'Introduction' section takes you to the same page on building your own Angstrom distribution that I mentioned in my first post.

    I have been able to take the example PSP from the TI website, (PSP 2.00.00.01) and run it without problems.  PSP 2.00.00.01 uses the Angstrom Distribution, which is what led me to take this approach in the first place.  I'm hoping that I'm not the only one who has run into this particular issue.

  • 0 in reply to Chris Cotton
    TI__Mastermind 41665 points

    For the most part in the pursuit of supporting the Mistral OMAP3 EVM I have only used the SDK packages you get from board registration (currently SDK 1.0.2), this is a bit behind the times relative to OpenEmbedded but the X-Loader does build, at least for me. At the moment to get a fully tested and supported system you would have to use the older kernel and X-Loader that you get with the out of the box SDK release, for more cutting edge software like what you would get with OpenEmbedded you will likely find more relevant advice from the OpenEmbedded community, at least with how things are today.

    In the pursuit of actually fixing your error, I can say that the X-Loader from SDK 1.0.2 does not have this CFG_I2C_SPEED string anywhere in the source based on a quick grep, so this is something that was probably added in some later community version. The best I could suggest would be to take a look through the source and see where this is used and if it really makes sense that it should be defined (I believe it is used for some boards), it is possible that this is just a broken build out of OpenEmbedded.