openembedded-core.git/meta/classes/qemuboot.bbclass, branch master-next Mirror of openembedded-core qemuboot.bbclass: save relative paths in conf file 2017-04-20T06:55:20+00:00 brian avery brian.avery@intel.com 2017-04-19T19:49:04+00:00 235243d7be5df57df4767e4710b846e83f0aa9fd This saves relative paths in the qemuboot.conf file instead of absolute paths. This is to allow the images and kernels to be relocated and still have the testimage and runqemu work. [YOCTO #11375] Signed-off-by: brian avery <brian.avery@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
This saves relative paths in the qemuboot.conf file instead of absolute
paths. This is to allow the images and kernels to be relocated and still
have the testimage and runqemu work.

[YOCTO #11375]

Signed-off-by: brian avery <brian.avery@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
qemuboot: write native sysroot of qemu-helper into qemuboot.conf 2017-04-12T22:55:54+00:00 Ed Bartosh ed.bartosh@linux.intel.com 2017-04-12T20:41:00+00:00 0f207bfc1f7a4fd509b78d32bbe1a8d4ebea8053 Native sysroot of qemu-helper contains all required tools (qemu-system and tunctl atm) for runqemu to work. It's not removed by rm_dir and should always exist. It makes sense to write it into qemuboot.conf to make runqemu to use it as a default directory for native tools. This should also speed up runqemu as it doesn't need to run to run 'bitbake qemu-helper -e' to get its native sysroot. [YOCTO #11266] [YOCTO #11193] Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Native sysroot of qemu-helper contains all required tools
(qemu-system and tunctl atm) for runqemu to work. It's not
removed by rm_dir and should always exist. It makes sense
to write it into qemuboot.conf to make runqemu to use it
as a default directory for native tools.

This should also speed up runqemu as it doesn't need to run
to run 'bitbake qemu-helper -e' to get its native sysroot.

[YOCTO #11266]
[YOCTO #11193]

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu: do not rely on grepping images 2017-04-11T17:10:49+00:00 Robert Yang liezhi.yang@windriver.com 2017-04-11T09:21:28+00:00 a99deb30a0138594147ae28aab016fe4b74b8959 Fixed when the image is large and not enough memory: grep: memory exhausted Aborted [YOCTO #11073] Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Fixed when the image is large and not enough memory:
  grep: memory exhausted
  Aborted

[YOCTO #11073]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>