On Aug 12, 2009, at 8:41 PM, Stuart Gray wrote:
> This is what I have done except from the part of changing the SRCREV.
> What I do not understand is why the line file://rc8-to-
> final.diff;patch=1 \
> needs to be in this .bb file. Should it not only appear within linux-
Well, if I can take a guess, whoever created the linux-omap3 recipe,
intended it to be the latest one for the omap. Plus they also created
linux-omap3-2.6.30.bb recipe. So, at the time of creation, both
both end up building linux-omap3-2.6.30.
That rc8-to-final.patch is unnecessary now.
> Now I would like to ask about SRCREV and how I should best use it. I
> realise it will control which version of the repository I will get,
> but are there any rules to guarantee you get a good image?
When you run the bitbake command, the git repository will be
downloaded to overo-oe/sources/git folder.
From there, it will create a tar ball of the git repository, around
380 to 400MB I think.
Then from that tar ball, an image corresponding to all the commits
upto the value you specified in SRCREV will get extracted into another
tar ball, that is around 78MB.
This tar ball is then extracted, and then all the patches that you
have specified in the recipe will be applied to the sources, the
kernel will get configured, and then the compilation process will be
So, there is nothing more to that, your images will be good, as long
as you clean and rebuild the same recipe. But don't go from a higher
recipe to a lower one.
Don't worry about getting a good image. I haven't found any issue with
getting a good image and the builds are always accurately reproducible
> I only raise this concern as I seem to be getting random results
> when I build and run my image. I was running kernel 2.6.29.x, but
> since moving to 2.6.30 I seem to be having various issues like:
> 1. If I modify the kernel to include smsc911x I still need to
> modify /etc/modules to get ethernet to work, but when I was running
> 2.6.29 changing the kernel was all I had to do to get ethernet
> 2. When I boot I cannot get wireless ethernet to work.
Perhaps Steve can comment on this. You need to check the v2.6.29
smsc911x patch, I know there is one in there for 2.6.29, and check the
v2.6.30 files, and see if there is any change. If so, then you need to
create a patch and apply the changes to v2.6.30. I'm just stating this
off hand without actually looking into the files. Also take a look at
the defconfig for v2.6.29 and v2.6.30 and test it out.
I've been tracking the v2.6.29, v2.6.30 and v2.6.31 kernel. A lot of
work is being done in v2.6.31 esp with respect to DSS2 and OMAP-PM
integration. It's in a state of flux now, and it looks like it will be
stable in v2.6.32 and there is a upcoming merge for that release.
For the moment, I would suggest if v2.6.29 works, then you set
DEFAULT_PREFERENCE = "-1" to the linux-omap3-2.6.30 recipe, and just
build and work with the linux-omap3-2.6.29 recipe.
I don't think it is a problem with bitbake, or the build process, but
in the state of the kernel sources and the patches applied to each
version. I think the smsc911x drivers were probably hand-patched to
work with the overo early (just guessing here, steve would be the best
guy to comment on this), and then later on it was included in the
mainline, which would explain why it disappears from the patches
applied to the overo for newer kernel versions (again jotting this
down from memory).
> It all started to go wrong when I did a git pull after noticing an
> update to qt4-embedded-gles_4.5.2.bb which was preventing me
> compiling qt4-embedded_4.5.2.
> After I did the git pull I deleted my tmp directory and rebuilt from
> scratch, but I am quickly losing confidence in the source that I now
Just revert back to v2.6.29, the build image should be identical
However, since you have already built v2.6.30, you will have to delete
the entire tmp folder, and rebuild once again.
Other wise your rootfs will contain module drivers for both v2.6.29
and v2.6.30 kernels as artifacts, if you try to build v2.6.29 after
having built v2.6.30. It happened to me. The network modules stopped
working properly, and it was because I had built v2.6.30 and then
tried to go back to v2.6.29.
> Did you have any problems like this when ascending the learning curve?
It was a nightmare learning bitbake, but it was worth it. It's a nice
I'm more used to commercial systems like IBM Telelogic Synergy and IBM
Rational ClearCase, but you only need those system when using it with
other s/w lifecycle tools like DOORS or Rhapsody for UML development,
and need traceability from requirements to the change-set and all the
models that were used to generate the code. For working with hand-
coded source files, git and bitbake does an excellent job.
Bitbake is really slow though, but it gets the job done.