[yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 2.2 now available.

2016-07-22 Thread Graydon, Tracy 
The first milestone release for Yocto Project 2.2 is available for
download now.

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.2_M1/

Thank you to everyone for your contributions.

eclipse-poky/kepler-master f357cc3f8981ae3f4401cb24435ef40ab095cb33.tar.bz2
eclipse-poky/luna-master 8315d3ec845f37a710bc42e01dd32058e4da7d01.tar.bz2
eclipse-poky/mars-master 06fa262d309628e31648994c55324bc70f5d7dc8.tar.bz2
meta-qt3 7d958b928a4a38a186746fabbc0d8169dd8bb3a6.tar.bz2
meta-qt4 8b346c465a5efb280f8d0d23f8660f68bf9af59f.tar.bz2
poky 6f0c5537e02c59e1c8f3b08f598dc049ff8ee098.tar.bz2


Test report:


https://wiki.yoctoproject.org/wiki/WW26_-_2016-06-21_-_Full_Test_Cycle_2.2_
M1.rc2



Tracy Graydon
Yocto Project
Build and Release



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

Re: [linux-yocto] [ PULL ] Sound Patches for BXT

2016-07-22 Thread Bruce Ashfield 

On 2016-07-19 1:50 PM, Ernst, Eric wrote:

Bruce, can you consider this for merge into bxt-rebase?



This has now been merged.

If anything is missing, send along new pull requests.

Bruce


On Fri, Jul 15, 2016 at 10:09:08PM -0700, Weight, Russell H wrote:

These patches apply, and I'm able to build an yocto image that boots
on Grosse Tete, however, I do not have the hardware to verify the audio
patches. I am able to successfully insmod the snd-soc-sst-bxt-florida.ko.

I'm providing this pull request to enable others to test the patch-set.

- Russ

-

The following changes since commit
40f97efe70b8b17405846f62c3909da973e795f6:

  Merge branch 'forklift' into yocto (2016-06-21 15:01:07 -0700)

are available in the git repository at:


  https://github.com/rweight/linux-yocto-4.4.git  github/bxt-rebase-sound

for you to fetch changes up to a8b72f8710df1881f3917c8795d10889b6cd1a41:

  UPSTREAM: ASoC: rt5514: Fix the issue that the variable dereferenced before 
checking (2016-07-15 17:03:37 -0700)


Adam Thomson (10):
  UPSTREAM: ASoC: da7219: Fix Sidetone to work regardless of DAI capture
  UPSTREAM: ASoC: da7219: Disable regulators on probe() failure
  UPSTREAM: ASoC: da7219: Update REFERENCES reg default, in-line with HW
  UPSTREAM: ASoC: da7219: Remove internal LDO features of codec
  UPSTREAM: ASoC: da7219: Add support for 1.6V micbias level
  UPSTREAM: ASoC: da7219: Remove support for 32KHz PLL mode
  UPSTREAM: ASoC: da7219: Add regmap patch to support old silicon
  UPSTREAM: ASoC: da7219: Correct BCLK inversion for DSP DAI format mode
  UPSTREAM: ASoC: da7219: Update PLL ranges and dividers to improve locking
  UPSTREAM: ASoC: da7219: Disallow unsupported 32KHz clock setting in 
set_dai_sysclk()

Anatol Pomazau (2):
  CHROMIUM: ASoC: nau8825: Unground HPL/HPR before playback
  CHROMIUM: ASoC: nau8825: Use TESTDAC to reduce start/stop playback plop

Antonio Ospite (1):
  UPSTREAM: ASoC: rk3036: fix missing dependency on REGMAP_MMIO

Arnd Bergmann (2):
  UPSTREAM: ASoC: rockchip: use __maybe_unused to hide st_irq_syscfg_resume
  UPSTREAM: ASoC: hdmi-codec: select CONFIG_HDMI

Axel Lin (2):
  UPSTREAM: ASoC: rt5616: Return error if device ID mismatch
  UPSTREAM: ASoC: da7219: Use logical instead of bitwise OR for boolean 
expression

Bard Liao (4):
  UPSTREAM: ASoC: rt5616: add rt5616 codec driver
  UPSTREAM: ASoC: rt5616: rename some alsa control names
  UPSTREAM: ASoC: rt298: fix remove unnedded clk setting
  UPSTREAM: ASoC: rt286: fix capture doesn't work at some cases

Caesar Wang (8):
  UPSTREAM: ASoC: rockchip: i2s: change bclk and lrck according to sample 
rates
  UPSTREAM: ASoC: rockchip-max98090: Allow more sample rates
  UPSTREAM: ASoC: rockchip-rt5645: Allow more sample rates
  UPSTREAM: ASoC: rt5616: add an of_match table
  UPSTREAM: ASoC: rt5616: add devicetree document for rt5616
  UPSTREAM: ASoC: rt5616: add mclk property for rt5616 document
  UPSTREAM: ASoC: rt5616: trivial: fix the typo
  UPSTREAM: ASoC: rt5616: add the mclk for the codec driver

Charles Keepax (2):
  UPSTREAM: ASoC: dapm: Make enable/disable_pin work with always on widgets
  mfd: arizona: Disable IRQ whilst we unbind driver

Fang, Yang A (1):
  CHROMIUM: ASoC: ts3a227e: add acpi table

Jianqun Xu (1):
  UPSTREAM: ASoC: rockchip: add bindings for rk3399 i2s

John Lin (1):
  UPSTREAM: ASoC: rt5616: add missing mute control for HPVOL

Jyri Sarha (3):
  UPSTREAM: ALSA: pcm: add IEC958 channel status helper for hw_params
  UPSTREAM: ALSA: pcm: Allow 32 bit sample format in IEC958 channel status 
helper
  UPSTREAM: ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

Kangjie Lu (2):
  UPSTREAM: ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS
  UPSTREAM: ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt

Koro Chen (1):
  UPSTREAM: ASoC: dpcm: Make BE prepare possible in suspend state

Lars-Peter Clausen (1):
  UPSTREAM: ASoC: dapm: Don't prefix autodisable widgets twice

Linus Walleij (2):
  UPSTREAM: ASoC: ac97: fix parent assignment
  UPSTREAM: ASoC: ac97: Be sure to clamp return value

Mark Brown (1):
  BACKPORT: ASoC: hdac: Fix Makefile and Kconfig sorting

Mengdong Lin (1):
  UPSTREAM: ASoC: Vendor drivers get a link's runtime by 
snd_soc_get_pcm_runtime()

Michael Trimarchi (1):
  UPSTREAM: ASoC: rockchip: i2s: Add SNDRV_PCM_FMTBIT_S32_LE support

Oder Chiou (3):
  UPSTREAM: ASoC: rt5514: add rt5514 codec driver
  UPSTREAM: ASoC: rt5514: add rt5514 SPI driver
  UPSTREAM: ASoC: rt5514: Fix the issue that the variable dereferenced 
before checking

PC Liao (1):
  UPSTREAM: ASoC: dpcm: Apply symmetry for DPCM

Philipp Zabel (2):
  UPSTREAM: ASoC: hdmi-codec: Add ELD control
  UPSTREAM: ASoC: hdmi-codec: Add ELD control

Ramesh

[yocto] [yocto-autobuilder][PATCH] nightly-wic.conf: build genericx86 wic images

2016-07-22 Thread Bill Randle 
QA requested wic images for genericx86, as well as x86-64 so include
config and build for them.

[YOCTO #10006]

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-wic.conf | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/buildset-config.controller/nightly-wic.conf 
b/buildset-config.controller/nightly-wic.conf
index 27584cb..47565ba 100644
--- a/buildset-config.controller/nightly-wic.conf
+++ b/buildset-config.controller/nightly-wic.conf
@@ -9,6 +9,12 @@ steps: [{'SetDest':{}},
 {'RunPreamble':{}},
 {'GetDistroVersion':{'distro': 'poky'}},
 {'CreateBBLayersConf':{'buildprovider':'yocto'}},
+{'CreateAutoConf':{'machine':'genericx86'}},
+{'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
+{'BuildImages':{'images':'core-image-sato'}},
+{'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
+{'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
+{'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}},
 {'CreateAutoConf':{'machine':'qemux86-64'}},
 {'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
 {'BuildImages':{'images':'core-image-sato'}},
@@ -20,5 +26,5 @@ steps: [{'SetDest':{}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}},
-{'PublishArtifacts': {'artifacts': ['qemux86-64', 'genericx86-64']}}]
+{'PublishArtifacts': {'artifacts': ['qemux86-64', 'genericx86', 
'genericx86-64']}}]
 
-- 
2.5.5

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

Re: [yocto] [meta-raspberrypi][PATCH v4 00/12] Support for VC4 graphics driver

2016-07-22 Thread Carlos Alberto Lopez Perez 
On 21/07/16 14:32, Herve Jourdain wrote:
> v4 series:
> a. rebased
> b. Upstream-Status added to the patch to the VC4 driver (needed only for 
> kernel 4.4, accepted upstream in 4.7)
> 
> v3 series:
> a. patch rebased
> b. new revision of kernel, to get a version of the VC4 graphics driver that 
> handles render nodes
> c. patch to the VC4 driver to enable proper working of the render nodes (need 
> to add authorization for IOCTLs)
> 
> v2 series:
> a. Fix the 4.4.10 kernel revision
> b. Effectively add vc4-kms-v3d overlay to the list of overlays to build 
> (forgotten previously)
> c. Make the parameter to the v4c-kms-v3d overlay configurable
> d. Add default values for the cma parameter to the v4c-kms-v3d overlay, 
> depending on the board (and the memory it has)
> 
> This patch series enables the support for the VC4 graphics driver from Eric 
> Anholt.
> There was a previous patch series by Javier Martinez Canillas, but it 
> required use of a different kernel.
> VC4 is now supported in the raspberrypi official kernel, at least for 4.4.9+.
> The support in 4.1 exists, but it is NOT STABLE, so it has been deemed 
> unreasonable to support VC4 with 4.1 kernels.
> 
> THEREFORE, VC4 graphics is supported ONLY for kernel versions 4.4.9 and later.
> 
> This patch series proposes to support VC4 by only adding 'vc4graphics' to 
> MACHINE_FEATURES, for raspberrypi. If this is set, it will trigger all the 
> necessary configuration/changes to use the VC4 driver, including 
> mesa/wayland/weston currently, and adding the overlay required.
> In order for this series to work, some previous patches are needed (support 
> for .dtbo, and fix of the mesa packaging when there is no DRI driver).
> The memory reserved for the VC4 driver has default values depending on the 
> version of the board used, but it can be configured by setting VC4_CMA_SIZE 
> to a value supported by the overlay ('cma-256', 'cma-192', 'cma-128', 
> 'cma-96', 'cma-64').
> 'cma-256' is the recommended value, but it might not be possible on boards 
> with 512MB or DRAM, or less...
> 'cma-64' is known to not being able to support FHD/1080p.
> 
> It was tested with wayland/weston, without the support for X11.
> 


I have a follow-up patch adding support for X11 that I will send once
this is merged.


> This patch series depends on two other patch series previously posted, that 
> enable the support for .dtbo overlay files.
> 
> Herve Jourdain (12):
>   rpi-default-providers.inc: change default providers to support
> vc4graphics
>   rpi-base.inc: add vc4-kms-v3d to the overlays to support vc4graphics
>   raspberrypi.conf: set the default value of VC4_CMA_SIZE to support
> vc4graphics
>   raspberrypi0.conf: set the default value of VC4_CMA_SIZE to support
> vc4graphics
>   raspberrypi2.conf: set the default value of VC4_CMA_SIZE to support
> vc4graphics
>   raspberrypi3.conf: set the default value of VC4_CMA_SIZE to support
> vc4graphics
>   rpi-config_git.bb: add v4c overlay to config.txt to support
> vc4graphics
>   wayland/weston_%.bbappend: modify configuration options to support
> vc4graphics
>   weston/weston_%.bbappend: modify configuration options to support
> vc4graphics
>   mesa_%.bbappend: new file to add the correct configuration options to
> support vc4graphics
>   linux-rpi.inc: add the configuration options required to support
> vc4graphics
>   linux-raspberrypi-4.4: add patch to enable proper operation of
> renderD128 device
> 
>  conf/machine/include/rpi-base.inc  |  1 +
>  conf/machine/include/rpi-default-providers.inc |  8 +++---
>  conf/machine/raspberrypi.conf  |  2 ++
>  conf/machine/raspberrypi0.conf |  2 ++
>  conf/machine/raspberrypi2.conf |  2 ++
>  conf/machine/raspberrypi3.conf |  2 ++
>  recipes-bsp/bootfiles/rpi-config_git.bb| 10 +++-
>  recipes-graphics/mesa/mesa_%.bbappend  |  4 +++
>  recipes-graphics/wayland/weston_%.bbappend |  6 ++---
>  recipes-graphics/weston/weston_%.bbappend  | 13 +-
>  .../0002-vc4-ioctl-rendering-allow.patch   | 29 
> ++
>  recipes-kernel/linux/linux-raspberrypi_4.4.bb  |  1 +
>  recipes-kernel/linux/linux-rpi.inc | 10 
>  13 files changed, 75 insertions(+), 15 deletions(-)
>  create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
>  create mode 100644 
> recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
> 

Tested-by: Carlos Alberto Lopez Perez 




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] bsp/axxiaarm64: Enable Axxia NCR and PEI drivers

2016-07-22 Thread Daniel Dragomir 
Signed-off-by: Daniel Dragomir 
---
 bsp/axxiaarm64/axxiaarm64.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bsp/axxiaarm64/axxiaarm64.cfg b/bsp/axxiaarm64/axxiaarm64.cfg
index ed2abd7..d08fe71 100644
--- a/bsp/axxiaarm64/axxiaarm64.cfg
+++ b/bsp/axxiaarm64/axxiaarm64.cfg
@@ -100,6 +100,8 @@ CONFIG_BLK_DEV_RAM_SIZE=35000
 #
 CONFIG_LSI_MTC=y
 CONFIG_ATA=y
+CONFIG_LSI_NCR=y
+CONFIG_AXXIA_PEI=y
 
 #
 # SCSI device support
-- 
1.9.1

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

[linux-yocto] [PATCH] Intel Axxia updates to yocto-kernel-cache yocto-4.1

2016-07-22 Thread Daniel Dragomir 
Hello Bruce!

Please apply this path on the 'yocto-4.1' branch from
git.yoctoproject.org/yocto-kernel-cache

This patch enable NCR driver and the PEI Controller for
axxiaarm64 bsp.

Thank you,
Daniel Dragomir (1):
  bsp/axxiaarm64: Enable Axxia NCR and PEI drivers

 bsp/axxiaarm64/axxiaarm64.cfg | 2 ++
 1 file changed, 2 insertions(+)

-- 
1.9.1

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

[yocto] Image partition with boot0 blob

2016-07-22 Thread Mont3z Claros 
Hello all,

I'm trying to create an image with the following partition:

boot0_position=8  # KiB
uboot_position=19096  # KiB

boot0 is a blob and it loads u_boot. Please can some one help me on
this matter?

Thanks a lot,
Montez
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] linux-raspberrypi versions

2016-07-22 Thread Khem Raj 
On Fri, Jul 22, 2016 at 12:03 AM, piotr.lewicki  wrote:
> Hi all,
>
> I also think that's a good idea. In my opinion we should at least make
> latest LTS (4.4) the default kernel and try to add latest mainline.
>
> Probably the "proper way" of dealing with the issue is using branches. This
> way (as it is in oe-core): jethro would have kernel 3.18 and 4.1, krogoth
> would have 4.4 and 4.1 and master would only have 4.4 and latest mainline.

4.1 is also LTS, So it should be kept along with 4.4 until next LTS

>
> Don't you think that it would be a good idea to create some "quasi" krogoth
> branch out of what is on master and then cleaning the master (e.g. removing
> kernel 3.18 and 4.1) ?
>
>
> BR,
>
> Piotr
>
>
>
> On 21.07.2016 17:39, Herve Jourdain wrote:
>>
>> Hi Paul,
>>
>> I had the same line of thoughts...
>> I believe 3.18 should be dropped, maybe even 4.1, default to 4.4, and
>> maybe
>> add 4.7 to the mix, since 4.7 seems to be where the bulk of the work is
>> done
>> now.
>>
>> Herve
>>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org]
>> On Behalf Of Paul Barker
>> Sent: jeudi 21 juillet 2016 09:03
>> To: yocto@yoctoproject.org
>> Subject: [yocto] [meta-raspberrypi] linux-raspberrypi versions
>>
>> Hi all,
>>
>> I'm planning to look at the linux-raspberypi recipes once I've had time to
>> send V2 of my u-boot patches. I'd like to know people's thoughts on the
>> available kernel versions in the meta-raspberrypi layer:
>>
>> Is anyone still using the linux-raspberrypi 3.18 recipe? The commit
>> referenced in SRCREV is from June 2015. I think it's probably time to
>> retire
>> this unless anyone has a reason to keep it around.
>>
>> Is there any reason to keep linux-raspberrypi 4.1 as the default recipe?
>> The
>> last commit to the 4.1 branch was in April and the default branch on the
>> linux-raspberrypi GitHub repository has been
>> 4.4 since then. I think we should change the default version to 4.4 unless
>> there's a good reason not to.
>>
>> If there's no objections I'll send a couple of patches to drop 3.18 and
>> change the default to 4.4.
>>
>> Thanks,
>> Paul Barker
>> --
>> ___
>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error during adding a new recipe.

2016-07-22 Thread Khem Raj 
On Fri, Jul 22, 2016 at 12:09 AM, Andre McCurdy  wrote:
> On Thu, Jul 21, 2016 at 8:20 PM, Khem Raj  wrote:
>>
>>> On Jul 21, 2016, at 6:45 PM, Paul Eggleton  
>>> wrote:
>>>
>>> On Thu, 21 Jul 2016 18:35:25 Khem Raj wrote:
 On Thu, Jul 21, 2016 at 6:32 PM, Paul Eggleton

  wrote:
> On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
>>> On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger
>>> 
>>> wrote:
>>>
>>> The sync driver is already ported in the kernel.  I just need to get
>>> this
>>> compilation error fixed. I tried adding below change to kernel bb file
>>> but still I get that same error.
>>>
>>> PACKAGES =+ "kernel-headers"
>>> FILES_kernel-headers = "${KDIR}/usr/include”
>>
>> there is a different recipe for headers linux-libc-headers that also
>> needs
>> to be patched and then hopefully kernel build system is exporting this
>> header for userspace automatically and you will be set.
>
> I thought we weren't supposed to be encouraging modifying
> linux-libc-headers - especially as this isn't for the libc - it's for
> other userspace code...?

 Yes thats correct thats why
 I am not asking for submitting this patch upstream.
>>>
>>> Sure, but this question comes up a lot. We ought to be telling people the
>>> correct mechanism for introducing extra headers such as this if it isn't to
>>> modify linux-libc-headers.
>>
>> Thats possible for external kernel modules. This is a kernel patch. There is 
>> no other elegant way
>> of solving this. They could write another recipe just to stage this header. 
>> but thats equally ugly.
>
> A new recipe isn't needed. You can add something like the following to
> the existing kernel recipe:
>
>   sysroot_stage_all_append () {
> mkdir -p ${SYSROOT_DESTDIR}/${includedir}/linux
> install -m644 ${S}/include/linux/sync.h
> ${SYSROOT_DESTDIR}/${includedir}/linux/
>   }

I wonder if this will this work with sstate

>
> and then add a dependency on the kernel to the recipe which needs the headers.
>
>
>>>
>>> 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

Re: [yocto] [meta-raspberrypi] linux-raspberrypi versions

2016-07-22 Thread Martin Bergek 
Paul,

I am having stability issues with the USB subsystem on Raspberry Pi 3 under 4.4 
that I can’t reproduce under 4.1. I assume 4.1 will still remain in the recipe 
when 4.4 is made the default option. How long would the 4.1 version stay so 
that those that want to can keep the old kernel version?

For more information about my issue please see: 
https://www.mail-archive.com/yocto@yoctoproject.org/msg30362.html

Thanks,
Martin Bergek



> On 21 Jul 2016, at 09:02, Paul Barker  wrote:
> 
> Hi all,
> 
> I'm planning to look at the linux-raspberypi recipes once I've had time
> to send V2 of my u-boot patches. I'd like to know people's thoughts on
> the available kernel versions in the meta-raspberrypi layer:
> 
> Is anyone still using the linux-raspberrypi 3.18 recipe? The commit
> referenced in SRCREV is from June 2015. I think it's probably time to
> retire this unless anyone has a reason to keep it around.
> 
> Is there any reason to keep linux-raspberrypi 4.1 as the default
> recipe? The last commit to the 4.1 branch was in April and the
> default branch on the linux-raspberrypi GitHub repository has been
> 4.4 since then. I think we should change the default version to 4.4
> unless there's a good reason not to.
> 
> If there's no objections I'll send a couple of patches to drop 3.18 and
> change the default to 4.4.
> 
> Thanks,
> Paul Barker
> -- 
> ___
> 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] [genericx86-jethro] core-image-sato HDDIMG 'install' - no hard drive selected - /etc/fstab no such file or directory

2016-07-22 Thread Simon Bolek 
Hi,
It did not help either. For some reason, hard disk is not
mounted/recognized.
After the message:
"Please append a correct "root=" boot option"
i can only see a list with ram partitions, like
ram0 (driver?)
ram1 (driver?)
...
ram15 (driver?)

There is nothing else in the list.
How can i debug/log boot process? Or force udev to reaload and trigger
"add"?

HELP!
thank you and kind regards
Simon :-)

On Thu, Jul 21, 2016 at 3:27 PM, Khem Raj  wrote:

> On Thu, Jul 21, 2016 at 2:15 AM, Simon Bolek 
> wrote:
> > Hi Raj,
> > Thank you.
> > I have already tried this.
> >
> > I managed to start the USB installation by addding
> > kernel-modules
> > to core-image-minimal-initramfs.bb
> >
> > However after the installation, system will not boot up due to kernel
> panic:
> > VFS: Cannot open root device "sda2" or unknown block (0,0) Please append
> a
> > correct "root=" boot option;
>
> can you add
>
> SYSLINUX_ROOT = "root=/dev/hda2"
>
> to local.conf and rebuild ?
>
> >
> > It seems, the SDD hard drive is found on installation time, but not on
> boot
> > time.
> > How is that possible? It did work with FIDO, but is not working with
> JETHRO.
> > Any hint what I have to look for now? Is it the drivers missing? Or maybe
> > some scripts not running at boot?
> > What will run at boot prior to mounting what is stated in root= in
> grub.cfg?
> >
> > kind regards
> > Simon :-)
> >
> >
> > On Sat, Jul 16, 2016 at 2:02 AM, Khem Raj  wrote:
> >>
> >> On Fri, Jul 15, 2016 at 3:17 PM, Simon Bolek <
> simon.bo...@googlemail.com>
> >> wrote:
> >> > Hi Raj,
> >> >
> >> > Maybe you could help me with this.
> >> > I found out that during rootfs (meta/lib/oe/rootfs.py), depmodwrapper
> >> > script
> >> > is beeing called.
> >> > I noticed, that it does generate /lib/modules/.. directory
> >> > structure
> >> > under:
> >> > poky/build/tmp/work/genericx86-poky-linux/core-image-sato
> >> > However, at the end of the bitbake process, there is no /lib/modules
> >> > direcotry in
> >> > core-image-minimal-initramfs-genericx86-20160715210400.rootfs.cpio.gz
> >> >
> >> > Where are the steps, where this .cpio.gz file is beeing generated.
> There
> >> > must be a place where all the files, that are inside, are beeing put
> >> > together.
> >>
> >> initramfs image is a separate image. What you are seeing is the final
> >> image.
> >> you might have to add the kernel module to you machine conf
> >>
> >> MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> >>
> >> >
> >> > HELP!
> >> > kind regards
> >> > Simon :-)
> >> >
> >> >
> >> >
> >> > On Fri, Jul 15, 2016 at 10:59 AM, Simon Bolek
> >> > 
> >> > wrote:
> >> >>
> >> >> Thanks, but neither:
> >> >> pkg_postinst_kernel-base ()
> >> >> nor:
> >> >> pkg_postinst_kernel-image ()
> >> >> from /meta/classes/kernel.bbclass gets called when running:
> >> >> - bitbake core-image-sato or
> >> >> - bitbake linux-yocto
> >> >>
> >> >> I put some commands in there, which are definitely wrong (like
> foobar)
> >> >> and
> >> >> bitbake run successfully.
> >> >> Whereas, in other funtions it caused problems.
> >> >> Any ideas how can fix this?
> >> >>
> >> >> thanks and best regards
> >> >> Simon :-)
> >> >>
> >> >>
> >> >> On Fri, Jul 15, 2016 at 1:30 AM, Khem Raj 
> wrote:
> >> >>>
> >> >>> On Thu, Jul 14, 2016 at 4:16 PM, Simon Bolek
> >> >>> 
> >> >>> wrote:
> >> >>> > Hi Raj,
> >> >>> >
> >> >>> > About depmod again.
> >> >>> > Should it be run from meta/classes/kernel.bbclass  ?
> >> >>> > ...
> >> >>> > pkg_postinst_kernel-base () {
> >> >>> > if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> >> >>> > mkdir -p $D/lib/modules/${KERNEL_VERSION}
> >> >>> > fi
> >> >>> > if [ -n "$D" ]; then
> >> >>> > depmodwrapper -a -b $D ${KERNEL_VERSION}
> >> >>> > else
> >> >>> > depmod -a ${KERNEL_VERSION}
> >> >>> > fi
> >> >>> > }
> >> >>> > ...
> >> >>> >
> >> >>> > Where is this function beeing called?
> >> >>>
> >> >>> It should be called during rootfs and image creation time. as well
> as
> >> >>> when you update the package using online package manager.
> >> >>>
> >> >>> > I did not find it anywhere.
> >> >>> > thanks and kind regards
> >> >>> > Simon :-)
> >> >>> >
> >> >>> > On Thu, Jul 14, 2016 at 8:32 AM, Simon Bolek
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >>
> >> >>> >> On Wed, Jul 13, 2016 at 4:56 PM, Khem Raj 
> >> >>> >> wrote:
> >> >>> >>>
> >> >>> >>> On Wed, Jul 13, 2016 at 4:57 AM, Simon Bolek
> >> >>> >>> 
> >> >>> >>> wrote:
> >> >>> >>> > Hi Raj,
> >> >>> >>> >
> >> >>> >>> > So i tried to do manually, what init script does and udev
> >> >>> >>> > definitely
> >> >>> >>> > does
> >> >>> >>> > not recognize the SSD drive.
> >> >>> >>> > I ran
> >> >>> >>> >  /lib/udev/udevd --daemon --debug > udev.debug 2>&1 &
> >>

[yocto] [PATCH] swabber: remove from documentation

2016-07-22 Thread Maxin B. John 
Remove documentation as swabber was removed from
oe-core with this commit:
commit a7ddbea345c90646e6b9ddb89f768865caffdf07
Author: Richard Purdie 
Date:   Mon Jun 6 12:08:56 2016 +0100

meta: Drop swabber

Signed-off-by: Maxin B. John 
---
 documentation/ref-manual/ref-classes.xml | 16 
 1 file changed, 16 deletions(-)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index e919bd7..9fdfcaf 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -1381,22 +1381,6 @@
 
 
 
-
-image-swab.bbclass
-
-
-The image-swab class enables the
-Swabber
-tool in order to detect and log accesses to the host system during
-the OpenEmbedded build process.
-
-This class is currently unmaintained.
-The strace package needs to be installed
-in the build host as a dependency for this tool.
-
-
-
-
 
 image-vm.bbclass
 
-- 
2.4.0

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

Re: [yocto] regarding bbappend file

2016-07-22 Thread Nicolas Dechesne 
On Fri, Jul 22, 2016 at 1:18 PM, jags gediya  wrote:
> Can i have 2 bbappend file for single recipe?
> I want to add something to the recipe whom bbappend file is already
> available but i don't want to modify that file directly. I want to add new
> bbappend file for that recipe in my custom layer, Is it possible?

yes, you can have more than 1 .bbappend for a recipe. Note that the
files will be appended based on layer priority.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] regarding bbappend file

2016-07-22 Thread jags gediya 
Hi All,

Can i have 2 bbappend file for single recipe?
I want to add something to the recipe whom bbappend file is already
available but i don't want to modify that file directly. I want to add new
bbappend file for that recipe in my custom layer, Is it possible?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error during adding a new recipe.

2016-07-22 Thread Andre McCurdy 
On Thu, Jul 21, 2016 at 8:20 PM, Khem Raj  wrote:
>
>> On Jul 21, 2016, at 6:45 PM, Paul Eggleton  
>> wrote:
>>
>> On Thu, 21 Jul 2016 18:35:25 Khem Raj wrote:
>>> On Thu, Jul 21, 2016 at 6:32 PM, Paul Eggleton
>>>
>>>  wrote:
 On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
>> On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger
>> 
>> wrote:
>>
>> The sync driver is already ported in the kernel.  I just need to get
>> this
>> compilation error fixed. I tried adding below change to kernel bb file
>> but still I get that same error.
>>
>> PACKAGES =+ "kernel-headers"
>> FILES_kernel-headers = "${KDIR}/usr/include”
>
> there is a different recipe for headers linux-libc-headers that also
> needs
> to be patched and then hopefully kernel build system is exporting this
> header for userspace automatically and you will be set.

 I thought we weren't supposed to be encouraging modifying
 linux-libc-headers - especially as this isn't for the libc - it's for
 other userspace code...?
>>>
>>> Yes thats correct thats why
>>> I am not asking for submitting this patch upstream.
>>
>> Sure, but this question comes up a lot. We ought to be telling people the
>> correct mechanism for introducing extra headers such as this if it isn't to
>> modify linux-libc-headers.
>
> Thats possible for external kernel modules. This is a kernel patch. There is 
> no other elegant way
> of solving this. They could write another recipe just to stage this header. 
> but thats equally ugly.

A new recipe isn't needed. You can add something like the following to
the existing kernel recipe:

  sysroot_stage_all_append () {
mkdir -p ${SYSROOT_DESTDIR}/${includedir}/linux
install -m644 ${S}/include/linux/sync.h
${SYSROOT_DESTDIR}/${includedir}/linux/
  }

and then add a dependency on the kernel to the recipe which needs the headers.


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

Re: [yocto] [meta-raspberrypi] linux-raspberrypi versions

2016-07-22 Thread piotr.lewicki 

Hi all,

I also think that's a good idea. In my opinion we should at least make 
latest LTS (4.4) the default kernel and try to add latest mainline.


Probably the "proper way" of dealing with the issue is using branches. 
This way (as it is in oe-core): jethro would have kernel 3.18 and 4.1, 
krogoth would have 4.4 and 4.1 and master would only have 4.4 and latest 
mainline.


Don't you think that it would be a good idea to create some "quasi" 
krogoth branch out of what is on master and then cleaning the master 
(e.g. removing kernel 3.18 and 4.1) ?



BR,

Piotr


On 21.07.2016 17:39, Herve Jourdain wrote:

Hi Paul,

I had the same line of thoughts...
I believe 3.18 should be dropped, maybe even 4.1, default to 4.4, and maybe
add 4.7 to the mix, since 4.7 seems to be where the bulk of the work is done
now.

Herve

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Paul Barker
Sent: jeudi 21 juillet 2016 09:03
To: yocto@yoctoproject.org
Subject: [yocto] [meta-raspberrypi] linux-raspberrypi versions

Hi all,

I'm planning to look at the linux-raspberypi recipes once I've had time to
send V2 of my u-boot patches. I'd like to know people's thoughts on the
available kernel versions in the meta-raspberrypi layer:

Is anyone still using the linux-raspberrypi 3.18 recipe? The commit
referenced in SRCREV is from June 2015. I think it's probably time to retire
this unless anyone has a reason to keep it around.

Is there any reason to keep linux-raspberrypi 4.1 as the default recipe? The
last commit to the 4.1 branch was in April and the default branch on the
linux-raspberrypi GitHub repository has been
4.4 since then. I think we should change the default version to 4.4 unless
there's a good reason not to.

If there's no objections I'll send a couple of patches to drop 3.18 and
change the default to 4.4.

Thanks,
Paul Barker
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



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