Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang]

Hi RP,

Thanks, clear enough, here are the summary. For anyone who
cares about runqemu, please free to give your comments, I will
start working on it sooner.
1) Use python to replace of shell
2) Preserve the current command line options
3) Remove any machine knowledges out of runqemu scripts
4) I'm not sure whether we should remove arch knowledges out of runqemu,
   I'd like to keep them, this can make bsp add runqemu support easier.
5) Add qemu-boot.bbclass to help create boot files during build.
6) Use python3.

// Robert

On 06/23/2016 04:56 PM, Richard Purdie wrote:

On Thu, 2016-06-23 at 16:43 +0800, Robert Yang wrote:

On 06/23/2016 04:17 PM, Richard Purdie wrote:

On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
Sorry about not responding to this before now. My concerns:

a) The commandline structure is changing and I'm not sure I like
the
new one or believe its an improvement. This is particularly
problematic
from a documentation perspective. Is there a way to preserve the
existing syntax?


I did like to preserve the existing command, but the main problem is
that then we had to hardcode the MACHINE knowledge into the code,
for example, when we run:
runqemu qemux86-64 core-image-sato

The qemux86-64 should be hardcoded into the code, otherwise it
doesn't know this is a machine arg or typo.


If we use python code, we can ask bitbake if "qemux86-64" is a valid
MACHINE or not?

We could assume that images are in DEPLOY_DIR/MACHINE and at least try
looking to see if such a qemu-boot file exists? We could then error and
simply inform them that there didn't appear to be any data for "qemu86
-64" available. DEPLOY_DIR could come from bitbake -e.

We could add in functionality to make it take an argument of a path to
the qemu-boot directory so that if the first option looks like a
relative/absolute PATH, try to see if a qemu-boot file exists there. If
it doesn't, it can then fall back to slower ops?


c) I don't think qemu-boot should be added be hardcoded into
image.bbclass, we need to find a better way to do this.


Sorry, I don't quite understand this, the code inside image.bbclass
is:

+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1',
'qemu-boot',
'', d)}"
+inherit ${QEMU_BOOT_CLASS}

It doesn't look like a hardcode ?


Imagine that qemu.inc does:

IMAGE_CLASSES += "qemu-boot"

You then shouldn't need to change image.bbclass at all, its much
cleaner. I don't like much of the way image.bbclass deals with all its
subclasses at the moment and don't want to make it worse.

Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Richard Purdie]

On Thu, 2016-06-23 at 16:43 +0800, Robert Yang wrote:
> On 06/23/2016 04:17 PM, Richard Purdie wrote:
> > On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
> > Sorry about not responding to this before now. My concerns:
> > 
> > a) The commandline structure is changing and I'm not sure I like
> > the
> > new one or believe its an improvement. This is particularly
> > problematic
> > from a documentation perspective. Is there a way to preserve the
> > existing syntax?
> 
> I did like to preserve the existing command, but the main problem is
> that then we had to hardcode the MACHINE knowledge into the code,
> for example, when we run:
> runqemu qemux86-64 core-image-sato
> 
> The qemux86-64 should be hardcoded into the code, otherwise it
> doesn't know this is a machine arg or typo.

If we use python code, we can ask bitbake if "qemux86-64" is a valid
MACHINE or not?

We could assume that images are in DEPLOY_DIR/MACHINE and at least try
looking to see if such a qemu-boot file exists? We could then error and
simply inform them that there didn't appear to be any data for "qemu86
-64" available. DEPLOY_DIR could come from bitbake -e. 

We could add in functionality to make it take an argument of a path to
the qemu-boot directory so that if the first option looks like a
relative/absolute PATH, try to see if a qemu-boot file exists there. If
it doesn't, it can then fall back to slower ops?

> > c) I don't think qemu-boot should be added be hardcoded into
> > image.bbclass, we need to find a better way to do this.
> 
> Sorry, I don't quite understand this, the code inside image.bbclass
> is:
> 
> +QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1',
> 'qemu-boot', 
> '', d)}"
> +inherit ${QEMU_BOOT_CLASS}
> 
> It doesn't look like a hardcode ?

Imagine that qemu.inc does:

IMAGE_CLASSES += "qemu-boot"

You then shouldn't need to change image.bbclass at all, its much
cleaner. I don't like much of the way image.bbclass deals with all its
subclasses at the moment and don't want to make it worse.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang]

On 06/23/2016 04:17 PM, Richard Purdie wrote:

Hi Robert,

On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:

This is still WIP, I send this out to make sure that I won't walk on
wrong way too far. Please feel free to give any comments.

TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such as QEMU_SYSTEM_OPTIONS and
   QEMU_SECOND_SERIAL_OPT
* More testing


=== Taken from patch 8/8's commit message:
* Why refactor
   The old runqemu had hardcoded machine knowledge, which limited its
   usage, for example, qemu-system-foo can boot the target, but
runqemu
   can't, and we need edit runqemu/runqemu-internal a lot to support
boot
   it.

* Brief introduction on implemention
   The basic thought is that, machine/bsp developer knows clearly on
   whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1"
or
   "0"), and how to boot it, so we leave these settings in the
machine's
   configuration.
   - qemu-boot.bbclass will write machine's info to
 ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
   - We need use "runqemu -m " rather than "runqemu
"
 since the scripts knows nothing about machine any more, and the
 similar to other old options, this is good for future's
extension.
   - I have updated all the machine's configuration except qemush4,
since
 I can't find this machine anywhere.
   - Several machines such as genericx86 and genericx86-64 can be boot
by
 new runqemu without any changes.
   - Added help info for supported options such as slirp and audio.

* Usage
Usage: runqemu 
 -m , specify machine
 -k , specify kernel
 -r , specify disk image, rootfs or nfs dir
 -t , specify fstypes, supported types:
  ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio,
hddimg,
  hdddirect, vmdk, wic, qcow2, vdi
 -n, nographic, disables video console
 -K, enable KVM when running x86 and x86-64 (VT-capable CPU
required)
 -V, enables KVM with VHOST support when running x86 and x86-64
(VT-capable CPU required)
 -v, publicvnc - enable a VNC server open to all hosts
 -u, slirp mode, use user mode networking (no root privilege is
required)
 -a, support audio
 -s, enable a serial console on /dev/ttyS0
 -q  - specify custom parameters to QEMU
 -b  - specify custom kernel parameters during boot
 -p , tcp serial port number
 -B , bios directory
 -F , bios filename.

 Examples:
   runqemu -m qemuarm -n
   runqemu -m qemuarm -t ext4
   runqemu -m qemux86-64 -r core-image-sato -t ext4
   runqemu -m qemux86 -r path/to/nfsrootdir/
   runqemu -r path/to/deploy/dir/image/file.vmdk
   runqemu -m qemumips -q "-m 256"
   runqemu -m qemuppc -b "psplash=false"


Sorry about not responding to this before now. My concerns:

a) The commandline structure is changing and I'm not sure I like the
new one or believe its an improvement. This is particularly problematic
from a documentation perspective. Is there a way to preserve the
existing syntax?


I did like to preserve the existing command, but the main problem is
that then we had to hardcode the MACHINE knowledge into the code,
for example, when we run:
runqemu qemux86-64 core-image-sato

The qemux86-64 should be hardcoded into the code, otherwise it
doesn't know this is a machine arg or typo.

I will think about if we can use a general database (e.g., tmp/runqemu_data)
to save MACHINE after build, then maybe we don't have to hardcode
MACHINE into the script.



b) The question of python verses shell. I'm leaning towards making this
a python script rather than shell at this point. It would mean you'd
need python to run the scripts but we already need that for a variety
of other tools so in general I think I prefer that. We do need to make
sure the new python version supports what the current shell script does
though.


This sounds good to me.



c) I don't think qemu-boot should be added be hardcoded into
image.bbclass, we need to find a better way to do this.


Sorry, I don't quite understand this, the code inside image.bbclass is:

+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot', 
'', d)}"

+inherit ${QEMU_BOOT_CLASS}

It doesn't look like a hardcode ?



d) I think we need to document the new API/variables somewhere so that
we don't just have a random ever changing set of variables but some
kind of standard we're trying to encourage.


Sounds, good.

// Robert



Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Richard Purdie]

Hi Robert,

On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
> This is still WIP, I send this out to make sure that I won't walk on
> wrong way too far. Please feel free to give any comments.
> 
> TODO:
> * Update the one which uses runqemu, such as oeqa
> * Boot EFI image
> * Boot multilib image such as lib32-foo
> * Change the vars name such as QEMU_SYSTEM_OPTIONS and
>   QEMU_SECOND_SERIAL_OPT
> * More testing
> 
> 
> === Taken from patch 8/8's commit message:
> * Why refactor
>   The old runqemu had hardcoded machine knowledge, which limited its
>   usage, for example, qemu-system-foo can boot the target, but
> runqemu
>   can't, and we need edit runqemu/runqemu-internal a lot to support
> boot
>   it.
> 
> * Brief introduction on implemention
>   The basic thought is that, machine/bsp developer knows clearly on
>   whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1"
> or
>   "0"), and how to boot it, so we leave these settings in the
> machine's
>   configuration.
>   - qemu-boot.bbclass will write machine's info to
> ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
>   - We need use "runqemu -m " rather than "runqemu
> "
> since the scripts knows nothing about machine any more, and the
> similar to other old options, this is good for future's
> extension.
>   - I have updated all the machine's configuration except qemush4,
> since
> I can't find this machine anywhere.
>   - Several machines such as genericx86 and genericx86-64 can be boot
> by
> new runqemu without any changes.
>   - Added help info for supported options such as slirp and audio.
> 
> * Usage
> Usage: runqemu 
> -m , specify machine
> -k , specify kernel
> -r , specify disk image, rootfs or nfs dir
> -t , specify fstypes, supported types:
>  ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio,
> hddimg,
>  hdddirect, vmdk, wic, qcow2, vdi
> -n, nographic, disables video console
> -K, enable KVM when running x86 and x86-64 (VT-capable CPU
> required)
> -V, enables KVM with VHOST support when running x86 and x86-64
> (VT-capable CPU required)
> -v, publicvnc - enable a VNC server open to all hosts
> -u, slirp mode, use user mode networking (no root privilege is
> required)
> -a, support audio
> -s, enable a serial console on /dev/ttyS0
> -q  - specify custom parameters to QEMU
> -b  - specify custom kernel parameters during boot
> -p , tcp serial port number
> -B , bios directory
> -F , bios filename.
> 
> Examples:
>   runqemu -m qemuarm -n
>   runqemu -m qemuarm -t ext4
>   runqemu -m qemux86-64 -r core-image-sato -t ext4
>   runqemu -m qemux86 -r path/to/nfsrootdir/
>   runqemu -r path/to/deploy/dir/image/file.vmdk
>   runqemu -m qemumips -q "-m 256"
>   runqemu -m qemuppc -b "psplash=false"

Sorry about not responding to this before now. My concerns:

a) The commandline structure is changing and I'm not sure I like the
new one or believe its an improvement. This is particularly problematic
from a documentation perspective. Is there a way to preserve the
existing syntax?

b) The question of python verses shell. I'm leaning towards making this
a python script rather than shell at this point. It would mean you'd
need python to run the scripts but we already need that for a variety
of other tools so in general I think I prefer that. We do need to make
sure the new python version supports what the current shell script does
though.

c) I don't think qemu-boot should be added be hardcoded into 
image.bbclass, we need to find a better way to do this.

d) I think we need to document the new API/variables somewhere so that
we don't just have a random ever changing set of variables but some
kind of standard we're trying to encourage.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Andrew Jeffery]

On Fri, 2016-05-20 at 10:43 +0800, Robert Yang wrote:
> 
> On 05/20/2016 10:31 AM, Robert Yang wrote:
> > 
> > Hi Nathan,
> > 
> > Thanks, but I'm sorry to say that this is only a RFC, we may change
> > it a lot, I will talk with RP, and let you when we have progresses.
> Oonce we change it a lot, for example, change runqemu to use python
> rather than shell script, your current work based on these patches
> may not work:-(, I will let you know once we have final decisions.

Any word on what direction these patches will take? I'm also looking to
make use of them in the near future, but will hold off if they will
change so significantly.

Cheers,

Andrew

signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang]

On 05/20/2016 10:31 AM, Robert Yang wrote:

Hi Nathan,

Thanks, but I'm sorry to say that this is only a RFC, we may change
it a lot, I will talk with RP, and let you when we have progresses.


Oonce we change it a lot, for example, change runqemu to use python
rather than shell script, your current work based on these patches
may not work:-(, I will let you know once we have final decisions.

// Robert



// Robert

On 05/19/2016 10:57 PM, Nathan Rossi wrote:

On Tue, May 10, 2016 at 6:13 PM, Robert Yang  wrote:

Hello,

This is still WIP, I send this out to make sure that I won't walk on
wrong way too far. Please feel free to give any comments.


Hi Robert,

This is great! So I went ahead and tested out converting the
qemumicroblaze and qemuzynq machines to work with these changes, as
well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.

Everything seems to work well, I was able to boot all the meta-xilinx
QEMU machines. Although there were a couple of things that I noticed
when getting these machines going:

QEMU_DTB, should probably be named QEMU_DTB_OPTIONS or alternatively
can just be included as part of QEMU_OPTIONS from within the bitbake
environment. But it would be nice to be able to just define the name
of the DTB and the runqemu scripts do the finding (like for kernel and
rootfs).

The "-s" and the "-n" runqemu options add "console=ttyS0" to the
kernel options regardless of target. For qemuzynq you might have
noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).

It is probably worth pulling in serial kernel options from a bitbake
variable.

Regards,
Nathan



TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such as QEMU_SYSTEM_OPTIONS and
   QEMU_SECOND_SERIAL_OPT
* More testing


=== Taken from patch 8/8's commit message:
* Why refactor
   The old runqemu had hardcoded machine knowledge, which limited its
   usage, for example, qemu-system-foo can boot the target, but runqemu
   can't, and we need edit runqemu/runqemu-internal a lot to support boot
   it.

* Brief introduction on implemention
   The basic thought is that, machine/bsp developer knows clearly on
   whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or
   "0"), and how to boot it, so we leave these settings in the machine's
   configuration.
   - qemu-boot.bbclass will write machine's info to
 ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
   - We need use "runqemu -m " rather than "runqemu "
 since the scripts knows nothing about machine any more, and the
 similar to other old options, this is good for future's extension.
   - I have updated all the machine's configuration except qemush4, since
 I can't find this machine anywhere.
   - Several machines such as genericx86 and genericx86-64 can be boot by
 new runqemu without any changes.
   - Added help info for supported options such as slirp and audio.

* Usage
Usage: runqemu 
 -m , specify machine
 -k , specify kernel
 -r , specify disk image, rootfs or nfs dir
 -t , specify fstypes, supported types:
  ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg,
  hdddirect, vmdk, wic, qcow2, vdi
 -n, nographic, disables video console
 -K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
 -V, enables KVM with VHOST support when running x86 and x86-64
(VT-capable CPU required)
 -v, publicvnc - enable a VNC server open to all hosts
 -u, slirp mode, use user mode networking (no root privilege is required)
 -a, support audio
 -s, enable a serial console on /dev/ttyS0
 -q  - specify custom parameters to QEMU
 -b  - specify custom kernel parameters during boot
 -p , tcp serial port number
 -B , bios directory
 -F , bios filename.

 Examples:
   runqemu -m qemuarm -n
   runqemu -m qemuarm -t ext4
   runqemu -m qemux86-64 -r core-image-sato -t ext4
   runqemu -m qemux86 -r path/to/nfsrootdir/
   runqemu -r path/to/deploy/dir/image/file.vmdk
   runqemu -m qemumips -q "-m 256"
   runqemu -m qemuppc -b "psplash=false"

// Robert

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib rbt/runqemu

http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu


Robert Yang (8):
   qemu-boot.bbclass: add it for runqemu
   qemu.inc: set QEMU_BOOT_SUPPORTED to 1
   qemuarm.conf: set vars for runqemu
   arch-arm64.inc: set vars for runqemu
   arch-x86.inc: set vars for 

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang]

Hi Nathan,

Thanks, but I'm sorry to say that this is only a RFC, we may change
it a lot, I will talk with RP, and let you when we have progresses.

// Robert

On 05/19/2016 10:57 PM, Nathan Rossi wrote:

On Tue, May 10, 2016 at 6:13 PM, Robert Yang  wrote:

Hello,

This is still WIP, I send this out to make sure that I won't walk on
wrong way too far. Please feel free to give any comments.


Hi Robert,

This is great! So I went ahead and tested out converting the
qemumicroblaze and qemuzynq machines to work with these changes, as
well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.

Everything seems to work well, I was able to boot all the meta-xilinx
QEMU machines. Although there were a couple of things that I noticed
when getting these machines going:

QEMU_DTB, should probably be named QEMU_DTB_OPTIONS or alternatively
can just be included as part of QEMU_OPTIONS from within the bitbake
environment. But it would be nice to be able to just define the name
of the DTB and the runqemu scripts do the finding (like for kernel and
rootfs).

The "-s" and the "-n" runqemu options add "console=ttyS0" to the
kernel options regardless of target. For qemuzynq you might have
noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).
It is probably worth pulling in serial kernel options from a bitbake
variable.

Regards,
Nathan



TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such as QEMU_SYSTEM_OPTIONS and
   QEMU_SECOND_SERIAL_OPT
* More testing


=== Taken from patch 8/8's commit message:
* Why refactor
   The old runqemu had hardcoded machine knowledge, which limited its
   usage, for example, qemu-system-foo can boot the target, but runqemu
   can't, and we need edit runqemu/runqemu-internal a lot to support boot
   it.

* Brief introduction on implemention
   The basic thought is that, machine/bsp developer knows clearly on
   whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or
   "0"), and how to boot it, so we leave these settings in the machine's
   configuration.
   - qemu-boot.bbclass will write machine's info to
 ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
   - We need use "runqemu -m " rather than "runqemu "
 since the scripts knows nothing about machine any more, and the
 similar to other old options, this is good for future's extension.
   - I have updated all the machine's configuration except qemush4, since
 I can't find this machine anywhere.
   - Several machines such as genericx86 and genericx86-64 can be boot by
 new runqemu without any changes.
   - Added help info for supported options such as slirp and audio.

* Usage
Usage: runqemu 
 -m , specify machine
 -k , specify kernel
 -r , specify disk image, rootfs or nfs dir
 -t , specify fstypes, supported types:
  ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg,
  hdddirect, vmdk, wic, qcow2, vdi
 -n, nographic, disables video console
 -K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
 -V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable 
CPU required)
 -v, publicvnc - enable a VNC server open to all hosts
 -u, slirp mode, use user mode networking (no root privilege is required)
 -a, support audio
 -s, enable a serial console on /dev/ttyS0
 -q  - specify custom parameters to QEMU
 -b  - specify custom kernel parameters during boot
 -p , tcp serial port number
 -B , bios directory
 -F , bios filename.

 Examples:
   runqemu -m qemuarm -n
   runqemu -m qemuarm -t ext4
   runqemu -m qemux86-64 -r core-image-sato -t ext4
   runqemu -m qemux86 -r path/to/nfsrootdir/
   runqemu -r path/to/deploy/dir/image/file.vmdk
   runqemu -m qemumips -q "-m 256"
   runqemu -m qemuppc -b "psplash=false"

// Robert

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu

Robert Yang (8):
   qemu-boot.bbclass: add it for runqemu
   qemu.inc: set QEMU_BOOT_SUPPORTED to 1
   qemuarm.conf: set vars for runqemu
   arch-arm64.inc: set vars for runqemu
   arch-x86.inc: set vars for runqemu
   arch-mips.inc: set vars for runqemu
   arch-powerpc.inc: set vars for runqemu
   runqemu/runqemu-internal: refactor it

  meta/classes/image.bbclass |   3 +
  meta/classes/qemu-boot.bbclass |  39 ++
  

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Nathan Rossi]

On Tue, May 10, 2016 at 6:13 PM, Robert Yang  wrote:
> Hello,
>
> This is still WIP, I send this out to make sure that I won't walk on
> wrong way too far. Please feel free to give any comments.

Hi Robert,

This is great! So I went ahead and tested out converting the
qemumicroblaze and qemuzynq machines to work with these changes, as
well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.

Everything seems to work well, I was able to boot all the meta-xilinx
QEMU machines. Although there were a couple of things that I noticed
when getting these machines going:

QEMU_DTB, should probably be named QEMU_DTB_OPTIONS or alternatively
can just be included as part of QEMU_OPTIONS from within the bitbake
environment. But it would be nice to be able to just define the name
of the DTB and the runqemu scripts do the finding (like for kernel and
rootfs).

The "-s" and the "-n" runqemu options add "console=ttyS0" to the
kernel options regardless of target. For qemuzynq you might have
noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).
It is probably worth pulling in serial kernel options from a bitbake
variable.

Regards,
Nathan

>
> TODO:
> * Update the one which uses runqemu, such as oeqa
> * Boot EFI image
> * Boot multilib image such as lib32-foo
> * Change the vars name such as QEMU_SYSTEM_OPTIONS and
>   QEMU_SECOND_SERIAL_OPT
> * More testing
>
>
> === Taken from patch 8/8's commit message:
> * Why refactor
>   The old runqemu had hardcoded machine knowledge, which limited its
>   usage, for example, qemu-system-foo can boot the target, but runqemu
>   can't, and we need edit runqemu/runqemu-internal a lot to support boot
>   it.
>
> * Brief introduction on implemention
>   The basic thought is that, machine/bsp developer knows clearly on
>   whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or
>   "0"), and how to boot it, so we leave these settings in the machine's
>   configuration.
>   - qemu-boot.bbclass will write machine's info to
> ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
>   - We need use "runqemu -m " rather than "runqemu "
> since the scripts knows nothing about machine any more, and the
> similar to other old options, this is good for future's extension.
>   - I have updated all the machine's configuration except qemush4, since
> I can't find this machine anywhere.
>   - Several machines such as genericx86 and genericx86-64 can be boot by
> new runqemu without any changes.
>   - Added help info for supported options such as slirp and audio.
>
> * Usage
> Usage: runqemu 
> -m , specify machine
> -k , specify kernel
> -r , specify disk image, rootfs or nfs dir
> -t , specify fstypes, supported types:
>  ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg,
>  hdddirect, vmdk, wic, qcow2, vdi
> -n, nographic, disables video console
> -K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
> -V, enables KVM with VHOST support when running x86 and x86-64 
> (VT-capable CPU required)
> -v, publicvnc - enable a VNC server open to all hosts
> -u, slirp mode, use user mode networking (no root privilege is required)
> -a, support audio
> -s, enable a serial console on /dev/ttyS0
> -q  - specify custom parameters to QEMU
> -b  - specify custom kernel parameters during boot
> -p , tcp serial port number
> -B , bios directory
> -F , bios filename.
>
> Examples:
>   runqemu -m qemuarm -n
>   runqemu -m qemuarm -t ext4
>   runqemu -m qemux86-64 -r core-image-sato -t ext4
>   runqemu -m qemux86 -r path/to/nfsrootdir/
>   runqemu -r path/to/deploy/dir/image/file.vmdk
>   runqemu -m qemumips -q "-m 256"
>   runqemu -m qemuppc -b "psplash=false"
>
> // Robert
>
> The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:
>
>   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
>   
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu
>
> Robert Yang (8):
>   qemu-boot.bbclass: add it for runqemu
>   qemu.inc: set QEMU_BOOT_SUPPORTED to 1
>   qemuarm.conf: set vars for runqemu
>   arch-arm64.inc: set vars for runqemu
>   arch-x86.inc: set vars for runqemu
>   arch-mips.inc: set vars for runqemu
>   arch-powerpc.inc: set vars for runqemu
>   runqemu/runqemu-internal: refactor it
>
>  meta/classes/image.bbclass |   3 +
>  meta/classes/qemu-boot.bbclass |  39 ++
>  meta/conf/bitbake.conf |   3 +
>  meta/conf/machine/include/arm/arch-arm64.inc  

[OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang]

Hello,

This is still WIP, I send this out to make sure that I won't walk on
wrong way too far. Please feel free to give any comments.

TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such as QEMU_SYSTEM_OPTIONS and
  QEMU_SECOND_SERIAL_OPT
* More testing


=== Taken from patch 8/8's commit message:
* Why refactor
  The old runqemu had hardcoded machine knowledge, which limited its
  usage, for example, qemu-system-foo can boot the target, but runqemu
  can't, and we need edit runqemu/runqemu-internal a lot to support boot
  it.

* Brief introduction on implemention
  The basic thought is that, machine/bsp developer knows clearly on
  whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or
  "0"), and how to boot it, so we leave these settings in the machine's
  configuration.
  - qemu-boot.bbclass will write machine's info to
${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
  - We need use "runqemu -m " rather than "runqemu "
since the scripts knows nothing about machine any more, and the
similar to other old options, this is good for future's extension.
  - I have updated all the machine's configuration except qemush4, since
I can't find this machine anywhere.
  - Several machines such as genericx86 and genericx86-64 can be boot by
new runqemu without any changes.
  - Added help info for supported options such as slirp and audio.

* Usage
Usage: runqemu 
-m , specify machine
-k , specify kernel
-r , specify disk image, rootfs or nfs dir
-t , specify fstypes, supported types:
 ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg,
 hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
-V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable 
CPU required)
-v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required)
-a, support audio
-s, enable a serial console on /dev/ttyS0
-q  - specify custom parameters to QEMU
-b  - specify custom kernel parameters during boot
-p , tcp serial port number
-B , bios directory
-F , bios filename.

Examples:
  runqemu -m qemuarm -n
  runqemu -m qemuarm -t ext4
  runqemu -m qemux86-64 -r core-image-sato -t ext4
  runqemu -m qemux86 -r path/to/nfsrootdir/
  runqemu -r path/to/deploy/dir/image/file.vmdk
  runqemu -m qemumips -q "-m 256"
  runqemu -m qemuppc -b "psplash=false"

// Robert

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

  test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu

Robert Yang (8):
  qemu-boot.bbclass: add it for runqemu
  qemu.inc: set QEMU_BOOT_SUPPORTED to 1
  qemuarm.conf: set vars for runqemu
  arch-arm64.inc: set vars for runqemu
  arch-x86.inc: set vars for runqemu
  arch-mips.inc: set vars for runqemu
  arch-powerpc.inc: set vars for runqemu
  runqemu/runqemu-internal: refactor it

 meta/classes/image.bbclass |   3 +
 meta/classes/qemu-boot.bbclass |  39 ++
 meta/conf/bitbake.conf |   3 +
 meta/conf/machine/include/arm/arch-arm64.inc   |   7 +
 meta/conf/machine/include/arm/arch-armv6.inc   |   2 +
 meta/conf/machine/include/mips/arch-mips.inc   |   5 +
 meta/conf/machine/include/powerpc/arch-powerpc.inc |   5 +
 meta/conf/machine/include/qemu.inc |   2 +
 meta/conf/machine/include/tune-cortexa8.inc|   2 +
 meta/conf/machine/include/x86/arch-x86.inc |   6 +
 meta/conf/machine/qemuarm.conf |   3 +
 scripts/runqemu| 603 +++---
 scripts/runqemu-internal   | 678 +++--
 13 files changed, 505 insertions(+), 853 deletions(-)
 create mode 100644 meta/classes/qemu-boot.bbclass

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core