* Migration info - runqemu @ 2016-10-14 1:48 Paul Eggleton 2016-10-14 2:12 ` Robert Yang 0 siblings, 1 reply; 8+ messages in thread From: Paul Eggleton @ 2016-10-14 1:48 UTC (permalink / raw) To: yocto; +Cc: Lock, Joshua, Scott Rifenbark Hi folks, We need some info for the migration section of the 2.2 manual about what the user needs to do to adapt to the new python-based runqemu. Robert / Joshua, can one of you please write something short that explains what users need to do (i.e. changes to the metadata for BSPs, or any other changes in operation)? It doesn't need to be polished, Scott Rifenbark will take care of that. Just replying to this email with Scott on CC should be sufficient. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-14 1:48 Migration info - runqemu Paul Eggleton @ 2016-10-14 2:12 ` Robert Yang 2016-10-14 8:01 ` robert.berger@gmane 2016-10-14 8:35 ` Lock, Joshua G 0 siblings, 2 replies; 8+ messages in thread From: Robert Yang @ 2016-10-14 2:12 UTC (permalink / raw) To: Paul Eggleton, Scott Rifenbark; +Cc: Lock, Joshua, yocto Hi Paul and Scott, Here it is, and please feel free to comment, most of them are from qemuboot.bbclass: The new runqemu is a python script, it requires a <image-name>-<machine>.qemuboot.conf to boot the bsp, the qemuboot.conf is generated by qemuboot.bbclass during build rootfs, qemu boot arguments can be set in bsp's conf file, and qemuboot.bbclass will save them to qemuboot.conf. Note, "QB" means Qemu Boot, the following vars can be set in conf files, such as <bsp.conf> to make it can be boot by runqemu: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" QB_MEM: memory, e.g., "-m 512" QB_MACHINE: qemu machine, e.g., "-machine virt" QB_CPU: qemu cpu, e.g., "-cpu qemu32" QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu kvm64', set it when support kvm. QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append option, e.g., "console=ttyS0 console=tty" QB_DTB: qemu dtb name QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support audio QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used when QB_AUDIO_DRV is set. QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda QB_TAP_OPT: netowrk option for 'tap' mode, e.g., "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-device,netdev=net0" Note, runqemu will replace "@TAP@" with the one which is used, such as tap0, tap1 ... QB_SLIRP_OPT: network option for SLIRP mode, e.g., "-netdev user,id=net0 -device virtio-net-device,netdev=net0" QB_ROOTFS_OPT: used as rootfs, e.g., "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" Note, runqemu will replace "@ROOTFS@" with the one which is used, such as core-image-minimal-qemuarm64.ext4. QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" QB_TCPSERIAL_OPT: tcp serial port option, e.g., " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" Note, runqemu will replace "@PORT@" with the port number which is used. Usage: IMAGE_CLASSES += "qemuboot" See "runqemu help" for more info // Robert On 10/14/2016 09:48 AM, Paul Eggleton wrote: > Hi folks, > > We need some info for the migration section of the 2.2 manual about what the > user needs to do to adapt to the new python-based runqemu. Robert / Joshua, > can one of you please write something short that explains what users need to > do (i.e. changes to the metadata for BSPs, or any other changes in operation)? > It doesn't need to be polished, Scott Rifenbark will take care of that. Just > replying to this email with Scott on CC should be sufficient. > > Thanks, > Paul > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-14 2:12 ` Robert Yang @ 2016-10-14 8:01 ` robert.berger@gmane 2016-10-14 8:35 ` Lock, Joshua G 1 sibling, 0 replies; 8+ messages in thread From: robert.berger@gmane @ 2016-10-14 8:01 UTC (permalink / raw) To: yocto; +Cc: Paul Eggleton, public-yocto-EtnWKYl6rD/WsZ/bQMPhNw, Lock, Joshua Hi Robert, On 2016-10-14 05:12, Robert Yang wrote: > > QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" > QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" ... Could you also please mention which of those values are obligatory and what are the default values in case they are not contained in the config file? Regards, Robert ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-14 2:12 ` Robert Yang 2016-10-14 8:01 ` robert.berger@gmane @ 2016-10-14 8:35 ` Lock, Joshua G 2016-10-14 9:16 ` Robert Yang 1 sibling, 1 reply; 8+ messages in thread From: Lock, Joshua G @ 2016-10-14 8:35 UTC (permalink / raw) To: Eggleton, Paul, Yang, Liezhi (Wind River), srifenbark@gmail.com Cc: yocto@yoctoproject.org On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: > Hi Paul and Scott, > > Here it is, and please feel free to comment, most of them are from > qemuboot.bbclass: > > The new runqemu is a python script, it requires a > <image-name>-<machine>.qemuboot.conf to boot the bsp, the > qemuboot.conf > is generated by qemuboot.bbclass during build rootfs, qemu boot > arguments can be set in bsp's conf file, and qemuboot.bbclass will > save > them to qemuboot.conf. Can we also document when qemuboot.conf required and what benefits it brings? Previous usage patterns should also be supported, right? Thanks, Joshua > > Note, "QB" means Qemu Boot, the following vars can be set in conf > files, such as <bsp.conf> to make it can be boot by runqemu: > > QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" > QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" > QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" > QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" > QB_MEM: memory, e.g., "-m 512" > QB_MACHINE: qemu machine, e.g., "-machine virt" > QB_CPU: qemu cpu, e.g., "-cpu qemu32" > QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu > kvm64', > set it when support kvm. > QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append > option, e.g., "console=ttyS0 console=tty" > QB_DTB: qemu dtb name > QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support > audio > QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used > when QB_AUDIO_DRV is set. > QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda > QB_TAP_OPT: netowrk option for 'tap' mode, e.g., > "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n > o -device > virtio-net-device,netdev=net0" > Note, runqemu will replace "@TAP@" with the one which > is used, > such as tap0, tap1 ... > QB_SLIRP_OPT: network option for SLIRP mode, e.g., > "-netdev user,id=net0 -device virtio-net- > device,netdev=net0" > QB_ROOTFS_OPT: used as rootfs, e.g., > "-drive id=disk0,file=@ROOTFS@,if=none,format=raw > -device > virtio-blk-device,drive=disk0" > Note, runqemu will replace "@ROOTFS@" with the one > which is used, > such as core-image-minimal-qemuarm64.ext4. > QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" > QB_TCPSERIAL_OPT: tcp serial port option, e.g., > " -device virtio-serial-device -chardev > socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device > virtconsole,chardev=virtcon" > Note, runqemu will replace "@PORT@" with the port > number > which is used. > > Usage: > IMAGE_CLASSES += "qemuboot" > See "runqemu help" for more info > > // Robert > > On 10/14/2016 09:48 AM, Paul Eggleton wrote: > > > > Hi folks, > > > > We need some info for the migration section of the 2.2 manual about > > what the > > user needs to do to adapt to the new python-based runqemu. Robert / > > Joshua, > > can one of you please write something short that explains what > > users need to > > do (i.e. changes to the metadata for BSPs, or any other changes in > > operation)? > > It doesn't need to be polished, Scott Rifenbark will take care of > > that. Just > > replying to this email with Scott on CC should be sufficient. > > > > Thanks, > > Paul > > --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-14 8:35 ` Lock, Joshua G @ 2016-10-14 9:16 ` Robert Yang 2016-10-15 21:22 ` Trevor Woerner [not found] ` <CAFNP8Ou9P=v+ohhXMr0gC2Kb4kwiuk2DuTrhJDHgxVLFLZvqOg@mail.gmail.com> 0 siblings, 2 replies; 8+ messages in thread From: Robert Yang @ 2016-10-14 9:16 UTC (permalink / raw) To: Lock, Joshua G, EGGLETON, PAUL, srifenbark@gmail.com Cc: yocto@yoctoproject.org On 10/14/2016 04:35 PM, Lock, Joshua G wrote: > On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: >> Hi Paul and Scott, >> >> Here it is, and please feel free to comment, most of them are from >> qemuboot.bbclass: >> >> The new runqemu is a python script, it requires a >> <image-name>-<machine>.qemuboot.conf to boot the bsp, the >> qemuboot.conf >> is generated by qemuboot.bbclass during build rootfs, qemu boot >> arguments can be set in bsp's conf file, and qemuboot.bbclass will >> save >> them to qemuboot.conf. > > Can we also document when qemuboot.conf required and what benefits it > brings? Previous usage patterns should also be supported, right? Yes, the benefit is that the machine knowledge are not hardcoded into runqemu any more, the bsp can define its own arguments to make it can be boot by runqemu. And previous usage patterns also be supported. // Robert > > Thanks, > > Joshua > >> >> Note, "QB" means Qemu Boot, the following vars can be set in conf >> files, such as <bsp.conf> to make it can be boot by runqemu: >> >> QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" >> QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" >> QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" >> QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" >> QB_MEM: memory, e.g., "-m 512" >> QB_MACHINE: qemu machine, e.g., "-machine virt" >> QB_CPU: qemu cpu, e.g., "-cpu qemu32" >> QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu >> kvm64', >> set it when support kvm. >> QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append >> option, e.g., "console=ttyS0 console=tty" >> QB_DTB: qemu dtb name >> QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support >> audio >> QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used >> when QB_AUDIO_DRV is set. >> QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda >> QB_TAP_OPT: netowrk option for 'tap' mode, e.g., >> "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n >> o -device >> virtio-net-device,netdev=net0" >> Note, runqemu will replace "@TAP@" with the one which >> is used, >> such as tap0, tap1 ... >> QB_SLIRP_OPT: network option for SLIRP mode, e.g., >> "-netdev user,id=net0 -device virtio-net- >> device,netdev=net0" >> QB_ROOTFS_OPT: used as rootfs, e.g., >> "-drive id=disk0,file=@ROOTFS@,if=none,format=raw >> -device >> virtio-blk-device,drive=disk0" >> Note, runqemu will replace "@ROOTFS@" with the one >> which is used, >> such as core-image-minimal-qemuarm64.ext4. >> QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" >> QB_TCPSERIAL_OPT: tcp serial port option, e.g., >> " -device virtio-serial-device -chardev >> socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device >> virtconsole,chardev=virtcon" >> Note, runqemu will replace "@PORT@" with the port >> number >> which is used. >> >> Usage: >> IMAGE_CLASSES += "qemuboot" >> See "runqemu help" for more info >> >> // Robert >> >> On 10/14/2016 09:48 AM, Paul Eggleton wrote: >>> >>> Hi folks, >>> >>> We need some info for the migration section of the 2.2 manual about >>> what the >>> user needs to do to adapt to the new python-based runqemu. Robert / >>> Joshua, >>> can one of you please write something short that explains what >>> users need to >>> do (i.e. changes to the metadata for BSPs, or any other changes in >>> operation)? >>> It doesn't need to be polished, Scott Rifenbark will take care of >>> that. Just >>> replying to this email with Scott on CC should be sufficient. >>> >>> Thanks, >>> Paul >>> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-14 9:16 ` Robert Yang @ 2016-10-15 21:22 ` Trevor Woerner [not found] ` <CAFNP8Ou9P=v+ohhXMr0gC2Kb4kwiuk2DuTrhJDHgxVLFLZvqOg@mail.gmail.com> 1 sibling, 0 replies; 8+ messages in thread From: Trevor Woerner @ 2016-10-15 21:22 UTC (permalink / raw) To: Robert Yang Cc: Lock, Joshua G, yocto@yoctoproject.org, srifenbark@gmail.com, EGGLETON, PAUL On Fri, Oct 14, 2016 at 5:16 AM, Robert Yang <liezhi.yang@windriver.com> wrote: > Yes, the benefit is that the machine knowledge are not hardcoded into > runqemu any more, the bsp can define its own arguments to make it can be > boot by runqemu. And previous usage patterns also be supported. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CAFNP8Ou9P=v+ohhXMr0gC2Kb4kwiuk2DuTrhJDHgxVLFLZvqOg@mail.gmail.com>]
* Re: Migration info - runqemu [not found] ` <CAFNP8Ou9P=v+ohhXMr0gC2Kb4kwiuk2DuTrhJDHgxVLFLZvqOg@mail.gmail.com> @ 2016-10-19 9:31 ` Lock, Joshua G 2016-10-19 9:52 ` Robert Yang 0 siblings, 1 reply; 8+ messages in thread From: Lock, Joshua G @ 2016-10-19 9:31 UTC (permalink / raw) To: Yang, Liezhi (Wind River), srifenbark@gmail.com Cc: yocto@yoctoproject.org, Eggleton, Paul [-- Attachment #1: Type: text/plain, Size: 5215 bytes --] Hi Scott, My only real concern is where we say "The script requires a configuration file…". The configuration file isn't compulsory. Previous usage models are supported, as noted below. The configuration file enables fine-grained tuning of options passed to qemu without the runqemu script hard-coding any knowledge about different machines, using it is convenient (especially when trying to use QEMU with machines other than the qemu* machines in OE-Core) but not mandatory. Robert, would you agree? Could you review the docs changes Scott has made? Thanks, Joshua On Fri, 2016-10-14 at 09:24 -0700, Scott Rifenbark wrote: Everyone, I updated the section about runqemu being ported to Python. I don't understand a lot of it so I did my best to clean up the basic texts and changes you sent. Look it over here http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#migration-2.2-runqemu-ported-to-python and provide me with fixes. Things are getting down to the wire so if you want changes in the RC get them to me as quick as possible. Thanks, Scott On Fri, Oct 14, 2016 at 2:16 AM, Robert Yang <liezhi.yang@windriver.com<mailto:liezhi.yang@windriver.com>> wrote: On 10/14/2016 04:35 PM, Lock, Joshua G wrote: On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: Hi Paul and Scott, Here it is, and please feel free to comment, most of them are from qemuboot.bbclass: The new runqemu is a python script, it requires a <image-name>-<machine>.qemuboot.conf to boot the bsp, the qemuboot.conf is generated by qemuboot.bbclass during build rootfs, qemu boot arguments can be set in bsp's conf file, and qemuboot.bbclass will save them to qemuboot.conf. Can we also document when qemuboot.conf required and what benefits it brings? Previous usage patterns should also be supported, right? Yes, the benefit is that the machine knowledge are not hardcoded into runqemu any more, the bsp can define its own arguments to make it can be boot by runqemu. And previous usage patterns also be supported. // Robert Thanks, Joshua Note, "QB" means Qemu Boot, the following vars can be set in conf files, such as <bsp.conf> to make it can be boot by runqemu: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" QB_MEM: memory, e.g., "-m 512" QB_MACHINE: qemu machine, e.g., "-machine virt" QB_CPU: qemu cpu, e.g., "-cpu qemu32" QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu kvm64', set it when support kvm. QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append option, e.g., "console=ttyS0 console=tty" QB_DTB: qemu dtb name QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support audio QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used when QB_AUDIO_DRV is set. QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda QB_TAP_OPT: netowrk option for 'tap' mode, e.g., "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n o -device virtio-net-device,netdev=net0" Note, runqemu will replace "@TAP@" with the one which is used, such as tap0, tap1 ... QB_SLIRP_OPT: network option for SLIRP mode, e.g., "-netdev user,id=net0 -device virtio-net- device,netdev=net0" QB_ROOTFS_OPT: used as rootfs, e.g., "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" Note, runqemu will replace "@ROOTFS@" with the one which is used, such as core-image-minimal-qemuarm64.ext4. QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" QB_TCPSERIAL_OPT: tcp serial port option, e.g., " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" Note, runqemu will replace "@PORT@" with the port number which is used. Usage: IMAGE_CLASSES += "qemuboot" See "runqemu help" for more info // Robert On 10/14/2016 09:48 AM, Paul Eggleton wrote: Hi folks, We need some info for the migration section of the 2.2 manual about what the user needs to do to adapt to the new python-based runqemu. Robert / Joshua, can one of you please write something short that explains what users need to do (i.e. changes to the metadata for BSPs, or any other changes in operation)? It doesn't need to be polished, Scott Rifenbark will take care of that. Just replying to this email with Scott on CC should be sufficient. Thanks, Paul --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. [-- Attachment #2: Type: text/html, Size: 7498 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Migration info - runqemu 2016-10-19 9:31 ` Lock, Joshua G @ 2016-10-19 9:52 ` Robert Yang 0 siblings, 0 replies; 8+ messages in thread From: Robert Yang @ 2016-10-19 9:52 UTC (permalink / raw) To: Lock, Joshua G, srifenbark@gmail.com Cc: yocto@yoctoproject.org, EGGLETON, PAUL Hi Joshua, On 10/19/2016 05:31 PM, Lock, Joshua G wrote: > Hi Scott, > > My only real concern is where we say "The script requires a configuration file…". > > The configuration file isn't compulsory. Previous usage models are supported, as > noted below. If we want to officially support runqemu boot the target without qemuboot.conf, we should also document that. Use runqemu without qemuboot.conf: * Supported machines qemuarm qemuarm64 qemux86 qemux86-64 qemuppc qemumips qemumips64 qemumipsel qemumips64el And the usage is: $ runqemu <machine> <rootfs> <kernel> [options] For example: $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic Please feel free to give your comments. I'm sorry to say that I have to go now. // Robert > > The configuration file enables fine-grained tuning of options passed to qemu > without the runqemu script hard-coding any knowledge about different machines, > using it is convenient (especially when trying to use QEMU with machines other > than the qemu* machines in OE-Core) but not mandatory. > > Robert, would you agree? Could you review the docs changes Scott has made? > > Thanks, > > Joshua > > On Fri, 2016-10-14 at 09:24 -0700, Scott Rifenbark wrote: >> Everyone, >> >> I updated the section about runqemu being ported to Python. I don't >> understand a lot of it so I did my best to clean up the basic texts and >> changes you sent. Look it over here >> http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#migration-2.2-runqemu-ported-to-python >> and provide me with fixes. Things are getting down to the wire so if you want >> changes in the RC get them to me as quick as possible. >> >> Thanks, >> Scott >> >> On Fri, Oct 14, 2016 at 2:16 AM, Robert Yang <liezhi.yang@windriver.com >> <mailto:liezhi.yang@windriver.com>> wrote: >>> >>> >>> On 10/14/2016 04:35 PM, Lock, Joshua G wrote: >>>> On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: >>>>> Hi Paul and Scott, >>>>> >>>>> Here it is, and please feel free to comment, most of them are from >>>>> qemuboot.bbclass: >>>>> >>>>> The new runqemu is a python script, it requires a >>>>> <image-name>-<machine>.qemuboot.conf to boot the bsp, the >>>>> qemuboot.conf >>>>> is generated by qemuboot.bbclass during build rootfs, qemu boot >>>>> arguments can be set in bsp's conf file, and qemuboot.bbclass will >>>>> save >>>>> them to qemuboot.conf. >>>>> >>>> >>>> Can we also document when qemuboot.conf required and what benefits it >>>> brings? Previous usage patterns should also be supported, right? >>>> >>> >>> Yes, the benefit is that the machine knowledge are not hardcoded into >>> runqemu any more, the bsp can define its own arguments to make it can be >>> boot by runqemu. And previous usage patterns also be supported. >>> >>> // Robert >>> >>> >>>> >>>> Thanks, >>>> >>>> Joshua >>>> >>>>> >>>>> Note, "QB" means Qemu Boot, the following vars can be set in conf >>>>> files, such as <bsp.conf> to make it can be boot by runqemu: >>>>> >>>>> QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" >>>>> QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" >>>>> QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" >>>>> QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" >>>>> QB_MEM: memory, e.g., "-m 512" >>>>> QB_MACHINE: qemu machine, e.g., "-machine virt" >>>>> QB_CPU: qemu cpu, e.g., "-cpu qemu32" >>>>> QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu >>>>> kvm64', >>>>> set it when support kvm. >>>>> QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append >>>>> option, e.g., "console=ttyS0 console=tty" >>>>> QB_DTB: qemu dtb name >>>>> QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support >>>>> audio >>>>> QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used >>>>> when QB_AUDIO_DRV is set. >>>>> QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda >>>>> QB_TAP_OPT: netowrk option for 'tap' mode, e.g., >>>>> "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n >>>>> o -device >>>>> virtio-net-device,netdev=net0" >>>>> Note, runqemu will replace "@TAP@" with the one which >>>>> is used, >>>>> such as tap0, tap1 ... >>>>> QB_SLIRP_OPT: network option for SLIRP mode, e.g., >>>>> "-netdev user,id=net0 -device virtio-net- >>>>> device,netdev=net0" >>>>> QB_ROOTFS_OPT: used as rootfs, e.g., >>>>> "-drive id=disk0,file=@ROOTFS@,if=none,format=raw >>>>> -device >>>>> virtio-blk-device,drive=disk0" >>>>> Note, runqemu will replace "@ROOTFS@" with the one >>>>> which is used, >>>>> such as core-image-minimal-qemuarm64.ext4. >>>>> QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" >>>>> QB_TCPSERIAL_OPT: tcp serial port option, e.g., >>>>> " -device virtio-serial-device -chardev >>>>> socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device >>>>> virtconsole,chardev=virtcon" >>>>> Note, runqemu will replace "@PORT@" with the port >>>>> number >>>>> which is used. >>>>> >>>>> Usage: >>>>> IMAGE_CLASSES += "qemuboot" >>>>> See "runqemu help" for more info >>>>> >>>>> // Robert >>>>> >>>>> On 10/14/2016 09:48 AM, Paul Eggleton wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We need some info for the migration section of the 2.2 manual about >>>>>> what the >>>>>> user needs to do to adapt to the new python-based runqemu. Robert / >>>>>> Joshua, >>>>>> can one of you please write something short that explains what >>>>>> users need to >>>>>> do (i.e. changes to the metadata for BSPs, or any other changes in >>>>>> operation)? >>>>>> It doesn't need to be polished, Scott Rifenbark will take care of >>>>>> that. Just >>>>>> replying to this email with Scott on CC should be sufficient. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>> >>>> >>> >> ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-10-19 9:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-14 1:48 Migration info - runqemu Paul Eggleton
2016-10-14 2:12 ` Robert Yang
2016-10-14 8:01 ` robert.berger@gmane
2016-10-14 8:35 ` Lock, Joshua G
2016-10-14 9:16 ` Robert Yang
2016-10-15 21:22 ` Trevor Woerner
[not found] ` <CAFNP8Ou9P=v+ohhXMr0gC2Kb4kwiuk2DuTrhJDHgxVLFLZvqOg@mail.gmail.com>
2016-10-19 9:31 ` Lock, Joshua G
2016-10-19 9:52 ` Robert Yang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.