openembedded-core.git/meta/classes/qemuboot.bbclass, branch uninative-1.5 Mirror of openembedded-core qemuboot.bbclass: add blank lines in comments 2017-01-23T12:04:00+00:00 Robert Yang liezhi.yang@windriver.com 2016-12-06T08:33:22+00:00 3f3344d1c063b0013a9ae7203bac30ab8f4ea17c Add blank lines in comments to make it easy for readind and updating. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> 
Add blank lines in comments to make it easy for readind and updating.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
runqemu: fixes for slirp, network device and hostfwd 2017-01-23T12:04:00+00:00 Robert Yang liezhi.yang@windriver.com 2016-11-29T06:02:05+00:00 7dddd090806914a62d977730440d803e48f44763 Fixed: - Add QB_NETWORK_DEVICE to set network device, it will be used by both slirp and tap. - Set QB_NETWORK_DEVICE to "-device virtio-net-pci" in qemuboot.bbclass but runqemu will default to "-device e1000" when QB_NETWORK_DEVICE is not set, this is because oe-core's qemu targets support virtio-net-pci, but the one outside of oe-core may not, "-device e1000" is more common. - Set hostfwd by default: 2222 -> 22, 2323 -> 23, and it will choose a usable port when the one like 222 is being used. This can avoid conflicts when multilib slirp qemus are running. We can forward more ports by default if needed, and bsp.conf can custom it. - Use different mac sections for slirp and tap to fix conflicts when running both of them on the same host. [YOCTO #7887] CC: Nathan Rossi <nathan@nathanrossi.com> CC: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com> 
Fixed:
- Add QB_NETWORK_DEVICE to set network device, it will be used by both
  slirp and tap.
- Set QB_NETWORK_DEVICE to "-device virtio-net-pci" in qemuboot.bbclass
  but runqemu will default to "-device e1000" when QB_NETWORK_DEVICE is
  not set, this is because oe-core's qemu targets support
  virtio-net-pci, but the one outside of oe-core may not,
  "-device e1000" is more common.
- Set hostfwd by default: 2222 -> 22, 2323 -> 23, and it will choose a
  usable port when the one like 222 is being used. This can avoid
  conflicts when multilib slirp qemus are running. We can forward more
  ports by default if needed, and bsp.conf can custom it.
- Use different mac sections for slirp and tap to fix conflicts when
  running both of them on the same host.

[YOCTO #7887]

CC: Nathan Rossi <nathan@nathanrossi.com>
CC: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
qemuboot.bbclass: use IMGDEPLOYDIR 2017-01-19T22:45:41+00:00 Robert Yang liezhi.yang@windriver.com 2016-11-22T10:13:00+00:00 0704f15d1ad7483f80ffa18fa32b6115923641cf So that "bitbake <image> -ccleansstate" can remove qemuboot.conf Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
So that "bitbake <image> -ccleansstate" can remove qemuboot.conf

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta: remove True option to getVar calls 2016-12-16T08:30:03+00:00 Joshua Lock joshua.g.lock@intel.com 2016-12-14T21:13:04+00:00 7c552996597faaee2fbee185b250c0ee30ea3b5f getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
qemuboot.bbclass: do not hook into do_rootfs 2016-11-30T15:47:14+00:00 Patrick Ohly patrick.ohly@intel.com 2016-11-24T09:51:13+00:00 c8260447ed115bc5be7df9b25e449a7744d9f2df Writing qemuboot.conf in write_qemuboot_conf() does not modify the rootfs and thus conceptually shouldn't be executed as part of rootfs creation. Running it as separate task is cleaner and fixes the problem of missing qemuboot.conf files for meta-swupd virtual images; those images replace do_rootfs and ROOTFS_POSTPROCESS_COMMANDs don't run at all. The task gets added such that it runs roughly at the same time as before. Probably it doesn't actually need to depend on do_rootfs, but this way we don't write a useless qemuboot.conf in cases where do_rootfs fails. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Writing qemuboot.conf in write_qemuboot_conf() does not modify the
rootfs and thus conceptually shouldn't be executed as part of rootfs
creation.

Running it as separate task is cleaner and fixes the problem of
missing qemuboot.conf files for meta-swupd virtual images; those
images replace do_rootfs and ROOTFS_POSTPROCESS_COMMANDs don't run at
all.

The task gets added such that it runs roughly at the same time as
before. Probably it doesn't actually need to depend on do_rootfs, but
this way we don't write a useless qemuboot.conf in cases where
do_rootfs fails.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
qemuboot.bbclass: Setup the vardeps for write_qemuboot_conf 2016-11-06T23:35:15+00:00 Nathan Rossi nathan@nathanrossi.com 2016-10-29T13:50:19+00:00 c568f6ce06512a108cada5c7100eb1f6de73f2ff Setting up the vardeps on write_qemuboot_conf forces the updating of variables in qemuboot.conf when machine/deploy configuration changes. This is particularly useful when developing or setting up the qemuboot (e.g. changing QB_* variables) for new targets or when changing deployment variables (e.g. KERNEL_IMAGETYPE). Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Setting up the vardeps on write_qemuboot_conf forces the updating of
variables in qemuboot.conf when machine/deploy configuration changes.
This is particularly useful when developing or setting up the qemuboot
(e.g.  changing QB_* variables) for new targets or when changing
deployment variables (e.g. KERNEL_IMAGETYPE).

Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Remove RM_OLD_IMAGE, it's no longer useful 2016-10-15T08:48:28+00:00 Joshua Lock joshua.g.lock@intel.com 2016-10-12T20:46:41+00:00 93631befe8b962bf99524746b49f4ebca336175c Since the move to put image deployment under sstate control in d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically removed before a new image is deployed (the default behaviour of the sstate logic). RM_OLD_IMAGE is therefore no longer required to provide this behaviour, remove the variable and its users. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Since the move to put image deployment under sstate control in
d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically
removed before a new image is deployed (the default behaviour of the
sstate logic).

RM_OLD_IMAGE is therefore no longer required to provide this
behaviour, remove the variable and its users.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
qemuboot: don't fail when QB_DEFAULT_KERNEL isn't symlink 2016-09-28T14:02:54+00:00 Martin Jansa martin.jansa@gmail.com 2016-09-28T07:28:49+00:00 a11d0d8641b7dfb05c78645cf21f2c04a08c4822 * in some cases we might set QB_DEFAULT_KERNEL to the real filename instead of symlink and then this whole readlink work around actually breaks the build, because os.readlink fails on normal files: >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86-master-20160927084848.bin') 'bzImage-linux-yocto-qemux86.bin' >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin') Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [Errno 22] Invalid argument: '/jenkins/mjansa/build-starfish-master-mcf/BUILD/deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin' Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
* in some cases we might set QB_DEFAULT_KERNEL to the real filename
  instead of symlink and then this whole readlink work around actually
  breaks the build, because os.readlink fails on normal files:

  >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86-master-20160927084848.bin')
  'bzImage-linux-yocto-qemux86.bin'
  >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  OSError: [Errno 22] Invalid argument: '/jenkins/mjansa/build-starfish-master-mcf/BUILD/deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin'

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuboot.bbclass: don't fail on very first build 2016-09-20T14:10:35+00:00 André Draszik git@andred.net 2016-09-16T10:06:29+00:00 ee4697350a553a36ca17b9376911e56eee43a465 During the very first build, the DEPLOY_DIR_IMAGE directory might not have been created yet, causing the creation of the qemuboot.conf config file to fail. This is because write_qemuboot_conf() runs at rootfs creation time, i.e. before deploy. So let's create the directory if necessary before trying to write the config file. Signed-off-by: André Draszik <git@andred.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
During the very first build, the DEPLOY_DIR_IMAGE
directory might not have been created yet, causing
the creation of the qemuboot.conf config file to
fail.

This is because write_qemuboot_conf() runs at
rootfs creation time, i.e. before deploy.

So let's create the directory if necessary before
trying to write the config file.

Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuboot: also write the kernel link name to the conf file 2016-09-19T08:07:06+00:00 Joshua Lock joshua.g.lock@intel.com 2016-09-18T07:39:26+00:00 3ccbaaad75f0a53d8bcf6a5c748ec80c96a383bd This will allow runqemu to fall back to trying the link name when a file matching the full name can't be found. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
This will allow runqemu to fall back to trying the link name when
a file matching the full name can't be found.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>