On 04/29/2016 05:45 PM, Richard Purdie wrote:
On Tue, 2016-04-26 at 11:42 +0800, Robert Yang wrote:
Hello,
The qemu-native can boot a lot of machines, but oe-core's runqemu can
only
boot a few of them which are hardcoded into runqemu. I'd like to
change
it little to make it drop the hardcode and can boot more machines.
Here
are some basic thoughts, please feel free to give your comments.
runqemu is a helpful script which can help us boot images easily, but
it
has a lot of hard code for machine + args. I'd like to remove these
from
runqemu, and make it as a frame. The logical is that, who knows
clearly
about whether qemu can boot the machine and how to boot it (args),
the
answer is the machine/bsp developer, so we can:
* Add a var like QEMU_SUPPORTED = "yes/no" in the bsp conf file
(default to no)
* Add a var like QEMU_BOOT_ARGS = "foo" if there are special args.
* Let do_rootfs or do_image_foo write data such as QEMU_BOOT_ARGS to
DEPLOY_DIR_IMAGE/runqemu/ or tmp/deploy/images/runqemu/, we can
treat
the "runqemu/" dir as a database, and anything we need there, for
example,
efi/pcbios, root args, and so on. We won't miss anything since all
the
images which can be boot by runqemu are built by oe-core.
* Then we can easily add supported machine to runqemu from the bsp
itself
without change runqemu.
I will start working on it if there is no objections, and make sure
it won't
break any current supported machines.
I guess we have some decisions to make. Firstly, is that script better
in shell or python at this point? Originally, shell made sense but I'm
starting to wonder if it would be clearer in python.
If we left it as shell, I'd envisaged it going through something like
BBPATH and sourcing files from each of the layers to build up its own
list of supported machines. The trouble is we can't easily get BBPATH
in the shell environment since we can't assume bitbake and we ideally
want it to work outside of our build environment.
Thanks for the reply, my thought is that move part of the implementation
into a class called runqemu.bbclass (or other names), and leave the runqemu
as a shell script, when QEMU_BOOT_SUPPORTED = "1", runqemu.bbclass will
create a:
tmp/deploy/images/<machine>/runqemu
And the content in runqemu can be: (for example, arm)
QEMU="/path/to/sysroots/x86_64-linux/usr/bin/qemu-system-arm -m 128 -machine
versatilepb "
TUNE_ARCH="arm"
QEMU_DEFAULT_KERNEL="zImage-qemuarm.bin"
QEMU_DEFAULT_FSTYPE="ext4"
QEMU_MEM="-m 128"
[maybe more]
All of these variables can be defined in bsp layer or conf files. I will
add some default values there according to TUNE_ARCH, so that the bsp may
not need do anything to boot from qemu when QEMU_BOOT_SUPPORTED = "1".
// Robert
With the development of devtool, I'm wondering if runqemu should become
another such "command", written in python and working in any of the
environments we'd expect devtool to work (eSDK, main build). If we did
that, we'd have the layers and could easily access BBPATH and search
for additional modules to add support for additional machines.
Thoughts?
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
