A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex.
Otherwise, the repository uses a 'task-base-gumstix' recipe to do most
of the work for various other recipes in keeping with the old svn
style. Note this does not match the current OE style of just adding
machine-specific stuff conditionally to the task-base recipe---I tried
and couldn't get this to work properly so if anyone has a fix for this
I'd love to see it :).
The git repository currently provides four Verdex images (thanks Joseph):
I had some problems building the last two because of the problems
reported on the branch with news & gnumeric etc. but I'm confident
these will go away as bugs get fixed upstream. I'd try the
verdex-console-image for a start.
For loading the code, essentially follow the instructions for Overo
for booting from a microSD card.
P.S. If you do get those errors related to task-base, please post them
so I can look through them.
On Sat, Feb 27, 2010 at 11:10 AM, mlq <mark.l.quilling@...> wrote:
> I am also trying to build the verdex image and have sucessfully built the
> minimal-image and kernel; however when I build the console image i.e.
> bitbake console-image it dies on building the task-base. Basically it is
> looking in the task base folder but is missing the extensions for the
> particular tasks (task-base-x, missing x; sorry I dont have the output in
> front of me). I have 2 questions;
> What is the correct recipe to bitbake for the verdex? (i cant seem to find
> any verdex-specific recipes in the repo)
> What procedure should we follow to flash the mmc? (I was able to boot using
> the FAT16 partition and gumstix-factory.script from the old svn repo but I
> am not sure if we should be using a similar setup to the overo with xload?)
> Another related question which is not critical is when I add recipes to
> user.collection/recipes bitbake does not see them - is there typical reason
> for this?
> Connie C wrote:
>> Hi Joseph,
>> Thanks for the help. I'm definitely using the bash profile. Followed all
>> those steps. I also followed the second sequence of code to make the
>> verdex-oe directory and I have the bitbake,build, and org.openembedded.dev
>> directories inside. I think everything looks okay up to there with what
>> you posted.
>> After removing my user.collection and com.gumstix.collection from the
>> verdex-oe directory, I removed the extraneous tmp directory and ran
>> bitbake verdex-console-image and got:
>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '' DEPENDS on or
>> otherwise requires it)
>> I had gotten this originally after I changed >>echo 0 >
>> and was trying to access the .bb file directly as a result.
>> Something with how my bitbake is set up?
>> bionicjoe wrote:
>>> Hi, I corrected one critical line below ...
>>> From: Joseph Kortje <jpktech@...>
>>> To: General mailing list for gumstix users.
>>> Sent: Fri, February 26, 2010 9:12:35 PM
>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex
>>> Hi Connie
>>> Most of what Ash checked in for verdex-oe came originally from myself and
>>> a few others
>>> so I can help you.
>>> It builds clean for me.
>>> So, lets' review ....
>>> What OS distribution are you building with?
>>> If it's Ubuntu, please confirm that you did the instruction to not
>>> reconfigure bash as dash.
>>>>>First I installed all the files in the new directory
>>> These should be the steps to follow:
>>> $ mkdir -p ~/verdex-oe
>>> $ cd ~/verdex-oe
>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git
>>> $ cd org.openembedded.dev
>>> $ git checkout --track -b verdex origin/verdex
>>> $ cd ~/verdex-oe
>>> $ git clone git://git.openembedded.net/bitbake bitbake
>>> $ cd bitbake
>>> $ git checkout 1.8.18
>>> $ cd ~/verdex-oe
>>> $ cp -r org.openembedded.dev/contrib/gumstix/build .
>>>>>echo 0 > /proc/sys/vm/mmap_min_addr
>>> Yes, that should work.
>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit
>>> and add the line
>>> vm.mmap_min_addr = 0
>>> (Save and then reboot).
>>>>> First the bitbake complained that it could not find user
>>>>>collection in verdex-oe, so I copied user.collection and
>>>>>com.gumstix.collection over into the directory.
>>> There is no requirement to copy over user.collection from th older
>>> gumstix-oe build environment path.
>>> The purpose of user.collection is to override the search path for bitbake
>>> recipes. If any bitbake recipes
>>> in the user.collection path have the same base name as the ones used in
>>> org.openembedded.dev then they would be used
>>> in place of the official ones. Unless the developer has a specific
>>> reason for adding an override or customization
>>> or new bitbake recipe, and understands what he/she is doing with it (and
>>> the consequences)
>>> I suggest not putting anything in user.collection folder (or don't use
>>> the folder at all).
>>> Any old user.collection recipes that were used in the old gumstix-oe SVN
>>> based projects will not necessarily be compatible
>>> with the newer verdex-oe stuff since we are using a newer Angstrom
>>> distribution, newer Kernel, newer bitbake,
>>> etc. Developers that have such recipes would need to revisit them to
>>> port them to the new code base.
>>> The warning about not finding user.collection can therefore simply be
>>> ignored since you are (presumably)
>>> not going to be wanting to override any of the standard bitbake recipes
>>> or add any of your own
>>> customized ones yet.
>>> The old "com.gumstix.collection" and any files in that folder should not
>>> be added to this path and
>>> is not supported anymore in the Git based OE architecture. Any of the
>>> relevant patches or recipes (previously called packages)
>>> from the previous com.gumstix.collection are now already integrated into
>>> the git based verdex branch org.openembedded.dev recipes.
>>> (There are some exceptions such as support for audio, and robostix which
>>> are currently not ported to the new verdex-oe branch. Still working
>>> on it ....).
>>> Here is how to fix your build environment:
>>> First, you need to clean out the incorrect files that were added to the
>>> build path ....
>>> cd ~/verdex-oe
>>> sudo rm -rf com.gumstix.collection
>>> sudo rm -rf user.collection
>>> In this case, since the build cache is probably messed up, we need to
>>> start with a clean build
>>> sudo rm -rf tmp
>>> bitbake verdex-console-image
>>> Note: Please don't add ".bb" to the end of the bitbake recipe names in
>>> the bitbake command.
>>> Also, you can omit the -b option.
>>> BTW, please make sure that you have plenty of space in your /home
>>> I use a 300GB partition albeit building for several projects for
>>> OpenEmbedded and I still find that
>>> my space gets eaten up really fast ...
>>> I recommend at least 40-60GB is needed to build verdex-oe (both
>>> verdex-console-image and verdex-palmtop-image).
>>> Let me know your results ...
>>> PS: Tip for building faster on dual or quad core cpu ....
>>> # Uncomment these lines to enable parallel make.
>>> # This allows make to spawn mutliple processes to take advantage of
>>> # processors. Useful on SMP machines
>>> PARALLEL_MAKE = "-j 4"
>>> BB_NUMBER_THREADS = "4"
> View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.html
> Sent from the Gumstix mailing list archive at Nabble.com.
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> gumstix-users mailing list