Re: [yocto] 2.2 release note material

2016-10-19 Thread Bruce Ashfield 

On 2016-10-19 10:25 PM, Paul Eggleton wrote:

Hi all,

I've been gathering material for the 2.2 release notes, here is what I have at
the moment. Things missing:

* Any new features/enhancements for the kernel tools - Bruce, is there
anything worth noting?


It is probably worth mentioning a few things on that front, I'll provide
some raw bullets points here .. and they can be wordsmithed as needed:

 - kernel tools were streamlined, with patching/configuration overhead
   reduced or eliminated in most cases.
 - kernel configuration audit was improved and runs as a standalone tool
 - kernel configuration audit provides symbol resolution and dependency
   information to allow troubleshooting of missing/incorrect/invalid 
symbols

 - kernel tools use upstream utilities directly, without local patches or
   wrappers.

Bruce



* Known issues that are worth calling out

Note that I haven't included all of the bugfixes in this release since we
haven't been recently and there are a lot of them. I do have a list of them if
we want to include them but not only is it very long, it's not guaranteed to
be devoid of fixes for regressions within the release and I also haven't
tweaked any of the items to be more understandable out of context as I have
with the features/enhancements.

Let me know if I've missed or misrepresented anything.

Cheers,
Paul



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [yocto-kernel-cache][PATCH 0/2] Fix kernel_configcheck warnings in Intel BSPs

2016-10-19 Thread Bruce Ashfield 

On 2016-10-19 7:24 PM, Cal Sullivan wrote:

Hi Bruce,

It looks like we need these in the yocto-4.4 branch as well.



Cherry picked to 4.4 as well.

Bruce


Thanks,
Cal Sullivan

On 10/12/2016 03:55 PM, California Sullivan wrote:

These patches fix most of the configcheck warnings we see with the 4.8
kenel.
There are still a couple that I haven't decided how to solve yet, but
it gets
most of them.

With intel-quark we get:

Config: CONFIG_INV_MPU6050_I2C
Requested value:  CONFIG_INV_MPU6050_I2C=m
Actual value:

Due to a missing I2C_MUX dependency on a driver enabled in iio.cfg. In
other
BSPs this dependency is satisfied automatically through a select, and
I just
haven't decided the appropriate place for this yet.

Config: CONFIG_BMP280
Requested value:  # CONFIG_BMP280 is not set
Actual value:

Because BMP280 depends on !BMP085 which is used in in
bosch-pressure-sensor-i2c
and BMP280 is enabled in iio.cfg. Previously this warning complained
about
BMP280 not getting enabled, so I added "# CONFIG_BMP280 is not set" to
the
bosch settings, giving us a less scary warning message.

With intel-core2-32 or intel-corei7-64 preempt-rt builds we get:

Config: CONFIG_LEDS_TRIGGER_CPU
Requested value:  CONFIG_LEDS_TRIGGER_CPU=y
Actual value:

 From leds.cfg, included in intel-common-drivers (and thus all intel-*
BSPs),
trying to enable LEDS_TRIGGER_CPU when it depends on !PREEMPT_RT_BASE.
Fixing
this one could be uglier.

With intel-corei7-64 and intel-core2-32 standard builds, we get no
warnings!

Let me know if you have any feedback or need to make changes to this
patch set.

Thanks,
Cal

California Sullivan (2):
   features: Fix configcheck warnings in features used by intel-core*
 BSPs
   features: Fix configcheck warnings in features used by intel-quark
 BSPs

  features/iio/iio.cfg| 4 
  features/mei/mei-me.cfg | 2 +-
  features/misc/bosch-pressure-sensor-i2c.cfg | 3 ++-
  features/nfc/nfc-vendor.cfg | 2 ++
  features/soc/x1000/x1000.cfg| 7 ---
  features/thermal/coretemp.cfg   | 2 +-
  6 files changed, 10 insertions(+), 10 deletions(-)





--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Recipe for Turbo.lua ?

2016-10-19 Thread Khem Raj 
On Wed, Oct 19, 2016 at 6:56 PM, Dinh Nguyen (dinhn)  wrote:
>
> Hi Yocto Gurus,
>
> I am trying to use the Turbo Lua as a framework for building Lua JIT.
> https://github.com/kernelsauce/turbo.git
>
> Is there any existing recipe for “turbo lua” ?

I checked at layers.openembedded.org and it seems there is no recipe for this.

>
> Many thanks in advance,
>   —Dinh
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.2 release note material

2016-10-19 Thread Khem Raj 
On Wed, Oct 19, 2016 at 7:25 PM, Paul Eggleton  wrote:
> Hi all,
>
> I've been gathering material for the 2.2 release notes, here is what I have at
> the moment. Things missing:
>
> * Any new features/enhancements for the kernel tools - Bruce, is there
> anything worth noting?

it does not cover the deprecated/removed packages. Eg uclibc has been
removed from oe-core
gcc 4.x is also out.

musl can build world for all primary architectures. ppc64 is now supported.

>
> * Known issues that are worth calling out
>
> Note that I haven't included all of the bugfixes in this release since we
> haven't been recently and there are a lot of them. I do have a list of them if
> we want to include them but not only is it very long, it's not guaranteed to
> be devoid of fixes for regressions within the release and I also haven't
> tweaked any of the items to be more understandable out of context as I have
> with the features/enhancements.
>
> Let me know if I've missed or misrepresented anything.
>
> Cheers,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] 2.2 release note material

2016-10-19 Thread Paul Eggleton 
Hi all,

I've been gathering material for the 2.2 release notes, here is what I have at 
the moment. Things missing:

* Any new features/enhancements for the kernel tools - Bruce, is there 
anything worth noting?

* Known issues that are worth calling out

Note that I haven't included all of the bugfixes in this release since we 
haven't been recently and there are a lot of them. I do have a list of them if 
we want to include them but not only is it very long, it's not guaranteed to 
be devoid of fixes for regressions within the release and I also haven't 
tweaked any of the items to be more understandable out of context as I have 
with the features/enhancements.

Let me know if I've missed or misrepresented anything.

Cheers,
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre
New Features / Enhancements


* Linux kernel 4.8 (and 4.4/4.1 LTS/LTSI)
* glibc 2.24
* gcc 6.2.0
* Migrated BitBake and python functions in the OE metadata to Python 3
* runqemu script has rewritten in Python and refactored to move 
machine-specific knowledge to the machine configuration, making it possible to 
extend it easily in each BSP layer
* Created pre-configured Docker containers for the build system, Toaster and 
the extensible SDK
* Add cve-check class to catch missing known CVE fixes for recipes
* Sato example UI moved to GTK+3 and refreshed with updated/replaced 
applications and Adwaita icon set
* Put deploy directory (including images, SDKs and other files) under shared 
state control. This effectively makes removal of old images and SDKs the 
default behaviour, and provides a way to trace files in that directory back to 
their originating recipes which is useful for scripts and UIs such as Toaster.
* BitBake improvements:
* Basic support for multi-configuration builds. For example, this enables 
building for more than one MACHINE at a time, which may be useful if you have a 
board with two separate SoCs on it, each with their own OS, but you want to 
target both in the same build.
* Show more progress during operation - added real-time task progress 
reporting for do_fetch, image creation, cmake-based do_compile; also show 
progress for "Preparing RunQueue" and sstate object availability check.
* Show task elapsed time
* Added a -q/--quiet output mode switch that only shows basic progress
* Added an "unset VARNAME" syntax to clear a variable
* Implemented support for per-task variable exports
* Create a symlink to the latest console log
* Added BB_SETSCENE_ENFORCE to enable enforcing that tasks are restored 
from sstate
* Added LAYERRECOMMENDS to allow declaring recommended but not required 
layer dependencies in conf/layer.conf
* Ported depexp UI to GTK+3
* Output errors and warnings to stderr
* Implement server autostart feature to avoid constantly holding a lock on 
the metadata when resident
* Rework perforce fetcher to support SRCREV and P4CONFIG
* Add BBPRECONF and BBPOSTCONF environment variables
* Toaster web UI improvements:
* Improved image customisation
* Improved BitBake to Toaster process communication
* Upgraded Bootstrap UI framework to version 3 which provides a new look 
and more responsive design
* Improved performance and consistency of table views in build analysis
* Added visual feedback to the layerindex data fetcher
* Improved the ability to download artifacts created by builds such as SDK 
artifacts
* Added the ability to import a layer from a local directory and switch 
between local and git sources
* Added ability to configure and customise Toaster using fixtures at setup 
time
* Added layers to the backend admin interface
* Added the ability to delete objects from Toaster's database such as 
builds, layers, customised images and projects.
* Improved build progress reporting
* Improved help and notification messages
* Image construction improvements:
* Add variable FORCE_RO_REMOVE to force removal of unneeded packages 
specified by ROOTFS_RO_UNNEEDED even if rootfs is not read-only
* Add variable VM_ROOTFS_TYPE to allow filesystems other than ext4 to be 
used for VM images (vmdk, vdi, qcow2, hdddirect)
* Make the INITRD optional for "live" image type
* Add bmap generation option to produce files that can be used with 
bmap-tools for sparse images
* Add support for zip compression
* wic improvements:
* Produce wic images by default for beaglebone, edgerouter and 
genericx86/genericx86-64
* image_types.bbclass: support template .wks.in files for wic
* directdisk*.wks: add serial console support
* Use GPT partition table for all EFI kickstart files
* Add --system-id wks option to set partition system id
* Add --bmap wks option to produce files that can be used with 
bmap-tools for sparse images
* isoimage-isohybrid: add grubefi configfile support

[yocto] Recipe for Turbo.lua ?

2016-10-19 Thread Dinh Nguyen (dinhn) 

Hi Yocto Gurus,

I am trying to use the Turbo Lua as a framework for building Lua JIT.
https://github.com/kernelsauce/turbo.git

Is there any existing recipe for “turbo lua” ?

Many thanks in advance,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libtomcrypt libtomfastmath recipe

2016-10-19 Thread Burton, Ross 
Please considering posting these recipe into meta-oe or similar, tomcrypt
etc comes up every few months.  And posting a recipe to the list implies
you want review, right? :)

On 19 October 2016 at 10:12, Markus Volk  wrote:

> DESCRIPTION = "tomcrypt"
> HOMEPAGE = " http://www.libtom.net; 
> LICENSE = "DWTFYW"
>
Second worst license known to man.  :(

> LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=71baacc459522324ef3e2b9e052e81
> 80"
>
These URLs are relative to ${S} so just file://LICENSE works.

> SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
> "
>
> SRCREV = "${AUTOREV}"
>
In general it's recommended to use a fixed SHA and then override SRVREV if
you need to for testing/CI/whatever.

> PV = "${SRCPV}"
> PR = "1"
>
No need for PR in general.

> S = "${WORKDIR}/git"
>
> inherit autotools-brokensep
>
Boo.  Is upstream fixable or is it beyond help?

> SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
> SRC_URI[sha256sum] = "d0ff89397f9a5fd1d13b1cbc419d5d
> 426e14473135515d72bfcb58e5babf5032"
>
> No need for SRC_URI if you're using git fetcher.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Install mozroot-certdata package on a read only root file system

2016-10-19 Thread Burton, Ross 
On 18 October 2016 at 23:26, Nick Wareing 
wrote:

> However I'm running into an issue with a recipe in the meta-mono layer:
> mozroot-certdata. I see the culprit is the pkg_postint script (
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/
> recipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb) which needs to
> modify the root file system on first boot which the build system is
> correctly flagging as impossible with a read only root file system:
>
>
You'll have to extend the recipe to run mono inside a qemu, there are
plenty of other recipes that demonstrate how to do this (fontcache and
gio-module-cache classes come to mind, although they also use intercept
scripts to avoid running qemu more than once).  Basically, use the qemu
class.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Install mozroot-certdata package on a read only root file system

2016-10-19 Thread Nick Wareing 
I have an established yocto build which I'm now trying to switch over to having 
a root file system (eg. EXTRA_IMAGE_FEATURES += "read-only-rootfs").


However I'm running into an issue with a recipe in the meta-mono layer: 
mozroot-certdata. I see the culprit is the pkg_postint script 
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb)
 which needs to modify the root file system on first boot which the build 
system is correctly flagging as impossible with a read only root file system:


ERROR: The following packages could not be configured offline and rootfs is 
read-only: ['mozroot-certdata']


My question is: is their a way to get these mozroot certs installed and 
configured with mono during the build process, such that the root file system 
does not need to be modified at boot/run time?


Cheers,

Nick

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] General policies for CVE fixes

2016-10-19 Thread akuster 



On 10/19/2016 03:42 AM, Sona Sarmadi wrote:

 From https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance:

General policies:

Fixes must go into master first unless they are applicable only to the
stable branch; if back-porting to an older stable branch, the fix
should first be applied to the newer stable branches before being
back-ported to the older branch

Does anyone know the reason for the policy above i.e. why fixes have
to go to master first?

1)  It makes more sense at least for users  to get CVE fixes as soon as
possible in the maintenance branches.

this is to ensure, that we do not regress next time when we release next
version from master. So its important to ensure that the fix has been
applied to master sometimes you can assert that the fix has gone into new
version of a package that is due to be uprevved in master and will be
done soonish. Such information is helpful when making security patches
for release branches.

Actually there was a suggestion at OEDEM on informing CVE ml that we
have as the CVE fixes get applied to metadata. Thats a good suggestion to
have implemented.


Thanks everyone for your explanation.

Yes regressions (forgetting to fix bugs in master) are bad.  I believe there
are other ways to avoid this, Yocto project has a bug reporting system to
have track of such things, right?
The issue there is if Jethro gets a fix and Krogoth, morty and mater  
need it as well, the bug system implies someone else is going to have to 
do the work.
That is the problem. Not too many people are stepping up to do the work 
in the other branches.




Maintenance branches are likely deployed in production systems, I think
Fixing security problems here should have higher priority.
You are more than welcome to submit patches for the stable branch you 
are concerned about knowing the patches wont be applied until the parent 
branches are addressed first.



  Don't you agree?

Perhaps we should discuss this at next OEDEM :)
We have and until more people step up to help, this will be a constant 
issue.


-armin


Cheers //Sona


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] General policies for CVE fixes

2016-10-19 Thread Bruce Ashfield 

On 2016-10-19 06:42 AM, Sona Sarmadi wrote:



From https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance:

General policies:

Fixes must go into master first unless they are applicable only to the
stable branch; if back-porting to an older stable branch, the fix
should first be applied to the newer stable branches before being
back-ported to the older branch

Does anyone know the reason for the policy above i.e. why fixes have
to go to master first?

1)  It makes more sense at least for users  to get CVE fixes as soon as
possible in the maintenance branches.


this is to ensure, that we do not regress next time when we release next
version from master. So its important to ensure that the fix has been
applied to master sometimes you can assert that the fix has gone into new
version of a package that is due to be uprevved in master and will be
done soonish. Such information is helpful when making security patches
for release branches.

Actually there was a suggestion at OEDEM on informing CVE ml that we
have as the CVE fixes get applied to metadata. Thats a good suggestion to
have implemented.



Thanks everyone for your explanation.

Yes regressions (forgetting to fix bugs in master) are bad.  I believe there
are other ways to avoid this, Yocto project has a bug reporting system to
have track of such things, right?


Unfortunately, code talks. Unless you strictly follow a procedure like
'master first', you end up with an ever growing list of bugs and
backports. Doing some sort of bulk backport increases the chance of
instability .. not to mention when someone is actively working on an
issue, they have all the context to asses the issue, understand the
change and then fix it in the appropriate branches. If you delay the
backporting by months, you lose that context and the job becomes much
harder.



Maintenance branches are likely deployed in production systems, I think
Fixing security problems here should have higher priority. Don't you agree?


I wouldn't agree that maintenance branches are any more important for
this than the current tip.

Bruce



Perhaps we should discuss this at next OEDEM :)

Cheers //Sona



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] General policies for CVE fixes

2016-10-19 Thread Sona Sarmadi 

> > From https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance:
> >
> > General policies:
> >
> > Fixes must go into master first unless they are applicable only to the
> > stable branch; if back-porting to an older stable branch, the fix
> > should first be applied to the newer stable branches before being
> > back-ported to the older branch
> >
> > Does anyone know the reason for the policy above i.e. why fixes have
> > to go to master first?
> >
> > 1)  It makes more sense at least for users  to get CVE fixes as soon as
> > possible in the maintenance branches.
> 
> this is to ensure, that we do not regress next time when we release next
> version from master. So its important to ensure that the fix has been
> applied to master sometimes you can assert that the fix has gone into new
> version of a package that is due to be uprevved in master and will be
> done soonish. Such information is helpful when making security patches
> for release branches.
> 
> Actually there was a suggestion at OEDEM on informing CVE ml that we
> have as the CVE fixes get applied to metadata. Thats a good suggestion to
> have implemented.


Thanks everyone for your explanation.

Yes regressions (forgetting to fix bugs in master) are bad.  I believe there
are other ways to avoid this, Yocto project has a bug reporting system to 
have track of such things, right?

Maintenance branches are likely deployed in production systems, I think
Fixing security problems here should have higher priority. Don't you agree?

Perhaps we should discuss this at next OEDEM :)

Cheers //Sona
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Migration info - runqemu

2016-10-19 Thread Robert Yang 

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[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 > 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
-.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  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

Re: [yocto] Migration info - runqemu

2016-10-19 Thread Lock, Joshua G 
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 
> 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
-.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  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

Re: [yocto] libtomcrypt libtomfastmath recipe

2016-10-19 Thread Markus Volk 

tomcrypt builds like this for me:


DESCRIPTION = "tomcrypt"
HOMEPAGE = " http://www.libtom.net;
LICENSE = "DWTFYW"
LIC_FILES_CHKSUM = 
"file://${S}/LICENSE;md5=71baacc459522324ef3e2b9e052e8180"


SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
"

SRCREV = "${AUTOREV}"
PV = "${SRCPV}"
PR = "1"

S = "${WORKDIR}/git"

inherit autotools-brokensep

SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
SRC_URI[sha256sum] = 
"d0ff89397f9a5fd1d13b1cbc419d5d426e14473135515d72bfcb58e5babf5032"



note, that tomcrypt wants latex installed for creating doc. You proably 
want to edit the makefile or define NODOC



Am 19.10.2016 um 09:19 schrieb Vivek Per:

Hi,

I am trying to build tomfastmath and tomcrypt shared libraries using 
yocto, I couldn't get recipes for libtomcrypt and tomfastmath in web. 
So started to write one but i am failing to write correct recipe every 
time.


the skeleton   i used is both the recipes

S = "${WORKDIR}/git"
inherit autotools
EXTRA_OEMAKE = " 'CFLAGS=${CFLAGS} "-I${S}/src/headers" -DTFM_ARM ' 
 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'LD={LD}'   'BUILDDIR=${S}' 
'D=${DEST_DIR}' "

do_compile() {
make -f ${S}/makefile  libtfm.a DESTDIR=${D} SBINDIR=${sbindir} 
MANDIR=${mandir}

}

Can any one help  please help me in creating tomcrypt and tomfastmath 
recipes. or any point our if recipes already exist.



Thanks and Regards,
  Vivek





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Problems with image creation

2016-10-19 Thread Markus Volk 

Hi,

I am building an image for development in the morty branch. It is quite 
large and therefore I only create iso images with the variable NOHDD = 
"1". At task do_image_wic the following is applied:


| Error: exec_cmd: cp 
/home/flk/yocto-pc/poky/build-pc/tmp/work/genericx86-poky-linux/neutrino-image/1.0-r0/neutrino-image-1.0/hddimg/EFI/BOOT/* 
/home/flk/yocto-pc/poky/build-pc/tmp/work/genericx86-poky-linux/neutrino-image/1.0-r0/deploy-neutrino-image-image-complete/neutrino-image-genericx86-20161018191251/build/hdd/boot/EFI/BOOT 
returned '1' instead of 0



It should be ok if this is "1" , respectively the command shouldn`t be 
called at all


I can avoid the error quick and dirty like this:


# workaround: NOHDD varibale isn`t respected in do_wic_image

IMAGE_PREPROCESS_COMMAND += "do_fix_image_gen;"

do_fix_image_gen() {

mkdir -p ${S}/hddimg/EFI/BOOT/

touch ${S}/hddimg/EFI/BOOT/bla

}


Regards,

Markus

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] libtomcrypt libtomfastmath recipe

2016-10-19 Thread Vivek Per 
Hi,

I am trying to build tomfastmath and tomcrypt shared libraries using yocto,
I couldn't get recipes for libtomcrypt and tomfastmath in web. So started
to write one but i am failing to write correct recipe every time.

the skeleton   i used is both the recipes

S = "${WORKDIR}/git"
inherit autotools
EXTRA_OEMAKE = " 'CFLAGS=${CFLAGS} "-I${S}/src/headers" -DTFM_ARM '
 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'LD={LD}'   'BUILDDIR=${S}'
'D=${DEST_DIR}' "
do_compile() {
make -f ${S}/makefile  libtfm.a DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir}
}

Can any one help  please help me in creating tomcrypt and tomfastmath
recipes. or any point our if recipes already exist.


Thanks and Regards,
  Vivek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto