sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity
OpenEmbedded "poky" with some sysmocom specific modifications. Mostly used only up to sysmocom release 201310, but the "pyro" branch is still used for 201705
25,800 Commits 8 Branches 0 Tags 142 MiB
Python 37.9%
BitBake 15.7%
C 15.5%
PHP 10%
Shell 7.2%
Other 13.4%
Go to file
Laurentiu Palcu 405be52d26 runqemu: set qemuarm memory size back to 128MB 
The following commit, 6ccd4d6, increased the RAM size for qemu machines
to 256MB due to some smart sanity tests failing on autobuilder because
more memory was needed.

Unfortunately this leads to various, potentially dangerous, issues like
the one observed during sudoku-savant project compilation:

collect: relinking
collect2: error: '_ZNK6sudoku5ClearINS_6SquareEEclERS1_' was assigned to
'board.rpo', but was not defined during recompilation, or vice versa
board.o:(.rodata+0x8): undefined reference to
`sudoku::Clear<sudoku::Square>::operator()(sudoku::Square&) const'
board.o:(.rodata+0x20): undefined reference to
`sudoku::Clear<sudoku::Sequence>::operator()(sudoku::Sequence&) const'
board.o:(.rodata+0x34): undefined reference to `typeinfo for
sudoku::Action<sudoku::Sequence>'
...AND THE LIST CONTINUES...
collect2: error: ld returned 1 exit status
make: *** [sudoku-savant] Error 1

After some tests, I found that the maximum amount of memory needed for
sudoku to compile properly is 146MB(!?!).

My attempts to create a simpler test case (using templates), in order to
replicate and isolate the issue failed. All the tests compiled just
fine.

So, my guess is that this problem is certainly memory related but the
cause might be hidden in any of the following: qemu versatile hw model,
in the kernel or, highly unlikely but not impossible, the toolchain
itself. The reason I don't really think the cause is in the toolchain is
the fact that the compilation completes just fine for 128MB on qemuarm but
also on other qemu machines (with 256MB of memory).

Since this issue might need lots of time to have a proper fix, I'll revert back
to using 128MB for qemuarm for the time being.

[YOCTO #5133]

(From OE-Core rev: 06605bd6ddd4d6a788e1a107dcf15dde1027c094)

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
 		2013-09-22 12:19:41 +01:00
bitbake bitbake: data_smart: Fix variable reference issues 2013-09-18 13:27:30 +01:00
documentation ref-manual: Added information for OEROOT and build environment 2013-09-12 16:50:12 +01:00
meta classes/imagetest-qemu: remove old image testing class 2013-09-22 12:19:41 +01:00
meta-hob meta-*/conf/layer.conf: tweak BBFILES comment 2013-04-10 09:23:17 +01:00
meta-skeleton hello-mod: Add comment for kernel module package naming 2013-08-20 15:31:24 +01:00
meta-yocto meta-yocto/layer.conf: Bump LAYERVERSION_yocto 2013-09-17 14:11:05 +01:00
meta-yocto-bsp beagleboard: update the dts location 2013-09-11 23:35:45 +01:00
scripts runqemu: set qemuarm memory size back to 128MB 2013-09-22 12:19:41 +01:00
.gitignore gitignore: only ignore meta- directories 2013-01-15 08:12:01 +00:00
LICENSE LICENSE: Clarify the license recipe source code is under 2010-06-10 10:13:18 +01:00
README README: Clarify where to send patches 2012-08-22 14:05:00 +01:00
README.hardware README.hardware: Replace atom-pc with genericx86 2013-08-27 10:55:08 +01:00
oe-init-build-env oe-init-build-env: Make it use the correct $OEROOT with zsh 2013-04-05 23:05:34 +01:00
oe-init-build-env-memres Add memory resident bitbake script 2013-08-26 11:29:44 +01:00

README 

Poky
====

Poky is an integration of various components to form a complete prepackaged
build system and development environment. It features support for building
customised embedded device style images. There are reference demo images
featuring a X11/Matchbox/GTK themed UI called Sato. The system supports
cross-architecture application development using QEMU emulation and a
standalone toolchain and SDK with IDE integration.

Additional information on the specifics of hardware that Poky supports
is available in README.hardware. Further hardware support can easily be added
in the form of layers which extend the systems capabilities in a modular way.

As an integration layer Poky consists of several upstream projects such as 
BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information 
e.g. for the hardware support. Poky is in turn a component of the Yocto Project.

The Yocto Project has extensive documentation about the system including a 
reference manual which can be found at:
    http://yoctoproject.org/documentation

OpenEmbedded-Core is a layer containing the core metadata for current versions
of OpenEmbedded. It is distro-less (can build a functional image with
DISTRO = "") and contains only emulated machine support.

For information about OpenEmbedded, see the OpenEmbedded website:
    http://www.openembedded.org/

Where to Send Patches
=====================

As Poky is an integration repository, patches against the various components
should be sent to their respective upstreams.

bitbake:
    bitbake-devel@lists.openembedded.org

meta-yocto:
    poky@yoctoproject.org

Most everything else should be sent to the OpenEmbedded Core mailing list.  If
in doubt, check the oe-core git repository for the content you intend to modify.
Before sending, be sure the patches apply cleanly to the current oe-core git
repository.
    openembedded-core@lists.openembedded.org

Note: The scripts directory should be treated with extra care as it is a mix
      of oe-core and poky-specific files.