On 2015-04-07 10:33, Martin Jansa wrote:
On Tue, Apr 07, 2015 at 10:29:14AM -0600, Gary Thomas wrote:
On 2015-04-07 10:19, Martin Jansa wrote:
On Tue, Apr 07, 2015 at 08:52:36AM -0600, Gary Thomas wrote:
I'm building for multiple ARM i.MX6 platforms. These have
the same SoC, but slightly different peripherals. As far as
I can tell, they should be able to share everything except
for a few ${MACHINE} specific packages, e.g. the kernel and
u-boot.
Sadly, that doesn't seem to be the case. The architecture
specific packages are being split into two categories - plain
ARM/Cortex-A9 and those that have i.MX6 specific optimizations.
For example, after building a complete image (on the order of
core-image-sato), I have this split:
$ ls tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/
acl gst-player libsamplerate0
modutils-initscripts shadow-sysroot
alsa-utils gst-plugins-bad libsm mpeg2dec
shared-mime-info
apmd gst-plugins-good libsndfile1 mplayer2
speex
atk gst-plugins-ugly libsoup-2.4 mtdev
sqlite3
attr gstreamer libtheora ncurses
startup-notification
base-passwd gstreamer1.0 libtirpc neon
strace
...
gst-ffmpeg libpostproc matchbox-wm
scrnsaverproto zlib
gst-fluendo-mpegmux libproxy mkfontdir
settings-daemon
gst-meta-base libpthread-stubs mkfontscale shadow
$ ls tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/
alsa-lib gst-plugins-base imx-gpu-viv libfslparser libsdl
xf86-video-imxfb-vivante
cairo gstreamer1.0-plugins-bad libdrm libfslvpuwrap mesa
xserver-xorg
firmware-imx gstreamer1.0-plugins-base libfslcodec libglu pulseaudio
It's the second category that is causing problems. They do not
seem to end up in any shareable sstate at all. If I try to rebuild
using only sstate, i.e. build my complete image to success, then
remove 'tmp' and rebuild, using the sstate-cache from the first go,
all of the above packages (alsa-lib, ..., xserver-xorg) are all
rebuilt from scratch. Those recipes do seem to end in my sstate-cache,
but they are never reused from it.
What would make this happen? How can I prevent it?
As is, sstate is not really shareable between these i.MX6 targets
as so much is being rebuilt all the time...
Any ideas or pointers gladly welcomed.
Try openembedded-core/scripts/sstate-diff-machines.sh
to see why.
Can this work if I build for the two machines in separate trees?
Yes, you can generate the report in each tree separately and then
compare them in one of them.
Also, I'm really trying to find out why a build for the same machine
doesn't reuse sstate, in the same build tree, back-to-back builds
(no metadata changes)
Sorry, is "the same build tree" something else than "the two machines in
separate trees" or are you testing both?
Both actually, but at the moment the most interesting problem
is for a given machine that sstate is not being [re]used for
these recipes.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
