linux/poky.git/scripts, branch dora-toaster

yocto-kernel: Use variable-substituted BBLAYERS

2013-10-04T15:07:46+00:00

The current find_bblayers() code finds and parses the BBLAYERS variable manually, and therefore doesn't handle variable substitution, which causes problems if used. This change makes find_bblayers() use the variable-substituted BBLAYERS instead. Fixes [YOCTO #5106] (From meta-yocto rev: 1629ac04e909143dc2c275c256094cb44c6cc43c) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie

wic: Add OpenEmbedded-specific implementation

2013-10-01T21:56:03+00:00

Reuses the mic/livecd infrastructure but heavily subclasses and modifies it to adapt to the special needs of building images from existing OpenEmbedded build artifacts. In addition to the OE-specific mic objects and modifications to the underlying infrastructure, this adds a mechanism to allow OE kickstart files to be 'canned' and made available to users via the 'wic list images' command. Two initial OE kickstart files have been added as canned .wks files: directdisk, which implements the same thing as the images created by directdisk.bbclass, and mkefidisk, which can essentially be used as a replacement for mkefidisk.sh. Of course, since creation of these images are now driven by .wks files rather than being hard-coded into class files or scripts, they can be easily modified to generate different variations on those images. They also don't require root priveleges, since they don't use mount to create the images. They don't however write to media like mkefidisk.sh does, but rather create images that can be written onto media. (From OE-Core rev: f87acc5e59d3c2c39ff171b5557977dab4c8f4a6) Signed-off-by: Tom Zanussi Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

wic: Add mic w/pykickstart

2013-10-01T21:56:03+00:00

This is the starting point for the implemention described in [YOCTO 3847] which came to the conclusion that it would make sense to use kickstart syntax to implement image creation in OpenEmbedded. I subsequently realized that there was an existing tool that already implemented image creation using kickstart syntax, the Tizen/Meego mic tool. As such, it made sense to use that as a starting point - this commit essentially just copies the relevant Python code from the MIC tool to the scripts/lib dir, where it can be accessed by the previously created wic tool. Most of this will be removed or renamed by later commits, since we're initially focusing on partitioning only. Care should be taken so that we can easily add back any additional functionality should we decide later to expand the tool, though (we may also want to contribute our local changes to the mic tool to the Tizen project if it makes sense, and therefore should avoid gratuitous changes to the original code if possible). Added the /mic subdir from Tizen mic repo as a starting point: git clone git://review.tizen.org/tools/mic.git For reference, the top commit: commit 20164175ddc234a17b8a12c33d04b012347b1530 Author: Gui Chen Date: Sun Jun 30 22:32:16 2013 -0400 bump up to 0.19.2 Also added the /plugins subdir, moved to under the /mic subdir (to match the default plugin_dir location in mic.conf.in, which was renamed to yocto-image.conf (moved and renamed by later patches) and put into /scripts. (From OE-Core rev: 31f0360f1fd4ebc9dfcaed42d1c50d2448b4632e) Signed-off-by: Tom Zanussi Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

wic: Initial code for wic (OpenEmbedded Image Creator)

2013-10-01T21:56:03+00:00

Initial implementation of the 'wic' command. The 'wic' command generates partitioned images from existing OpenEmbedded build artifacts. Image generation is driven by partitioning commands contained in an 'Openembedded kickstart' (.wks) file specified either directly on the command-line or as one of a selection of canned .wks files (see 'wic list images'). When applied to a given set of build artifacts, the result is an image or set of images that can be directly written onto media and used on a particular system. 'wic' is based loosely on the 'mic' (Meego Image Creator) framework, but heavily modified to make direct use of OpenEmbedded build artifacts instead of package installation and configuration, things already incorporated int the OE artifacts. The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to the letter 'w', because 'oeic' is impossible to remember or pronounce. This covers the mechanics of invoking and providing help for the command and sub-commands; it contains hooks for future commits to connect with the actual functionality, once implemented. Help is integrated into the 'wic' command - see that for details on usage. (From OE-Core rev: 95455ae4251e06d66e60945092b784d2d9ef165c) Signed-off-by: Tom Zanussi Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

mkefidisk.sh: Allow using a loopback mounted file

2013-09-30T21:11:58+00:00

It should be possible to generate a disk to a file using a loopback device with mkefidisk.sh, which is useful for booting simulators. To make this possible the partitions for the loop back need to work similarly to the mmc devices. The mkfs.vfat also requires and additional argument to force it to write to something other then a real disk. Example: qemu-img create -f raw bigdisk 4G dev=`sudo losetup -f` sudo losetup $dev bigdisk mkefidisk.sh $dev tmp-eglibc/deploy/images/qemux86/core-image-minimal-qemux86.hddimg /dev/sda sudo losetup -d $dev Note: Also a bug was fixed in the mkefidisk.sh where if the disk you are writing to initially has an invalid label the size of the first partition will be computed incorrectly. For the simulator disk creation this is generally always the case, but this can happen with real hardware as well. (From OE-Core rev: 254899824900f2e8c6a34d2ad1b8cbea91acb4ae) Signed-off-by: Jason Wessel Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

runqemu: Use correct kvm CPU options for qemux86* with kvm

2013-09-26T15:37:56+00:00

The existing -cpu host option caused kernel panics when people attempted to use the kvm option. After research and discussion, the best options appear to be the kvm32/kvm64 cpu types so lets use these instead. These resolve the kernel issues for me. [YOCTO #3908] (From OE-Core rev: bdc6d3be6ffa4ed358153f9c9332b632324f5833) Signed-off-by: Richard Purdie

relocate_sdk.py: make it work also with python 3

2013-09-26T15:37:55+00:00

Strings in Python 3, by default, are assumed to contain unicode characters. In previous versions of python (<3), unicode strings are explicitly declared with u"abc". If not, than they're automatically converted to bytes. This doesn't happen anymore in Python 3. Since we're dealing with binary files, opened in byte mode, make sure that we explicitly convert all strings to bytes to make both python 2 and 3 happy. Other changes: * add a safety check to make sure relocation did not change the file size; * a couple of cosmetic changes (wrap long lines so that we don't have to scroll to reach the end of them); (From OE-Core rev: 175f20e27eadc79df16109961f5ce6232705e96f) Signed-off-by: Laurentiu Palcu Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

scripts/runqemu: write temp file into correct location

2013-09-24T16:57:03+00:00

We want the temporary file to be written in /tmp not the current directory. (From OE-Core rev: fcb40c11998030eb5fce89ce5a9ca567870aafa9) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

yocto-bsp: add 3.10/remove 3.8 kernel from templates

2013-09-24T11:01:47+00:00

For Yocto 1.5, 3.10 is the preferred kernel and 3.8 is obsolete. This also removes any mention of emgd from the templates - we want to discourage users from using it - it will be obsolete soon in any case. Fixes [YOCTO #5107] (From meta-yocto rev: 4dd4bf6ac2dcc7652ec8f807df02298546bdb41b) Signed-off-by: Tom Zanussi Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

runqemu: set qemuarm memory size back to 128MB

2013-09-22T11:19:41+00:00

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::operator()(sudoku::Square&) const' board.o:(.rodata+0x20): undefined reference to `sudoku::Clear::operator()(sudoku::Sequence&) const' board.o:(.rodata+0x34): undefined reference to `typeinfo for sudoku::Action' ...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 Signed-off-by: Richard Purdie