On 2020-03-30 2:57 a.m., Mikko Rapeli wrote:
Hi,
Generic approaches for reducing yocto target image size where buildhistory
is an important source of information:
* review and minimize distro features, enable only what you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-distro
* review and minimize image recipe, install only those image features and
packages
which you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image
* review the needed binary packages: traverse the tree of dependencies what
you need,
review every single recipe and change PACKAGECONFIG or build flags to remove
features which you do not need. This it may be possible to remove large set
of dependencies from images, e.g. language bindings, debug tools. In some
cases
one just needs a single binary executable or shared library but it is
bundled
in a larger binary package with more complex dependencies. For these cases
add a bbappend to custom layers to change the packaging to only include what
you need.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGECONFIG
* change compiler flags from default O2 to Os optimization. This can work for
some recipes which are not prerformance critical or to the whole build. Note
that many SW components break this in their own build scripts by adding
O2 or even O3 by default. Check from buildhistory that binary sizes go
smaller
after switch from O2 to Os and review every important recipe which did not.
You may be able to save up to 15% in rootfs size this way, but all depends
on the details of SW components and image contents.
see poky/meta/conf/bitbake.conf
I've followed this for multiple products and found out that poky is nice to
work with
but BSP layers add or depend on all kinds of extra things that products do not
need.
Thus I have ended by BBMASK'ing away large parts of BSP layer recipes in distro
configs. This with multiple x86 and ARM BSP layers from various SoC vendors.
I've also seen this problem and was frustrated by it.
The BSP vendors/developers want to test the full feature set of the
hardware but they often don't bother stripping out packages after
confirming that everything works. This results in bloat that can
be a problem for some users.
Using BBMASK is a good coping mechanism! :)
It would also be good if BSP developers split the BSP into the
essential elements and extras. Where to draw the line between
two such categories can tricky. One could also have finer-grained
packagegroups but splitting things into essential and extras is
a good start.
In WR Linux, we have a setup tool that let's you add 'features'
This comes from a layer that improves ease of use for some people:
https://github.com/WindRiver-Labs/wr-template/blob/WRLINUX_10_19_BASE/README
and is always used in the WR Linux distro.
And as can be seen here:
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_19_BASE/wrlinux-distro/templates/feature/bsp-extras
There is a generic BSP independent feature that you can add to
a setup:
feature/bsp-extras
Adds some useful tools defined by the BSP_EXTRAS_PACKAGES option
in the BSP layer.
To see the list of available tools, run the bitbake -e command in
a sourced terminal, and look for the BSP_EXTRAS_PACKAGES.
Maybe this description will help get BSP developers to agree on
doing something similar regardless of the 'setup/wr-template' layer.
Good luck and keep your BSPs minimal!
../Randy
Also, RTFM :)
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-a-tiny-system
Hope this helps,
-Mikko
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49089): https://lists.yoctoproject.org/g/yocto/message/49089
Mute This Topic: https://lists.yoctoproject.org/mt/72609037/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
