date:20170217

Re: [yocto] [meta-raspberrypi] WiFi on rpi3?

2017-02-17 Thread Gary Thomas


On 2017-02-17 03:09, Khem Raj wrote:



On 1/20/17 3:52 AM, Gary Thomas wrote:

On 2017-01-20 12:30, Gary Thomas wrote:

Can someone give me pointers to get the onboard WiFi on the
RaspberryPi3 going?  What kernel settings/hoops I need to do,
what packages I might need, etc?

Thanks



Actually, I've found that with an older kernel (4.1.21) the WiFi
device is discovered, but with the newer kernels (4.4.x and 4.9.x)
it's not.

Any clues?



Please try out the patch I posted to ml

https://lists.yoctoproject.org/pipermail/yocto/2017-February/034624.html

or from my gh fork.

https://github.com/kraj/meta-raspberrypi/commit/6ce6e57782c23fd21ad47286ac8b809ce989ea78

and let us know.


This works great on my rpi3, thanks!

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [meta-raspberrypi][PATCH] xserver-xf86-config: remove evdev configuration

2017-02-17 Thread Gary Thomas


On 2017-02-16 12:49, Andreas Müller wrote:

xorg-xserver recommends xf86-input-libinput since oe-core's commit

| commit 2d005faff6341a81a2afae28860101ba9db51ae8
| Author: Jussi Kukkonen 
| Date:   Wed Oct 26 11:37:38 2016 +0300
|
|conf: Use xf86-input-libinput by default
| ...

As nice side effect warnings for missing evdev in Xorg.0.log are gone.

Signed-off-by: Andreas Müller 


Indeed, this lets the X server work again without the need for xf86-input-evdev

Thanks


---
 .../rpi/xorg.conf.d/10-evdev.conf  | 40 --
 .../xorg-xserver/xserver-xf86-config_0.1.bbappend  | 22 ++--
 2 files changed, 10 insertions(+), 52 deletions(-)
 delete mode 100644 
recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf

diff --git 
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
 
b/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
deleted file mode 100644
index cc83ab2..000
--- 
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
+++ /dev/null
@@ -1,40 +0,0 @@
-#
-# Catch-all evdev loader for udev-based systems
-# We don't simply match on any device since that also adds accelerometers
-# and other devices that we don't really want to use. The list below
-# matches everything but joysticks.
-
-Section "InputClass"
-Identifier "evdev pointer catchall"
-MatchIsPointer "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev keyboard catchall"
-MatchIsKeyboard "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchpad catchall"
-MatchIsTouchpad "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev tablet catchall"
-MatchIsTablet "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchscreen catchall"
-MatchIsTouchscreen "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend 
b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
index 062de2d..b361eef 100644
--- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -1,19 +1,17 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

-SRC_URI_append_rpi = " file://xorg.conf.d/10-evdev.conf \
-   file://xorg.conf.d/98-pitft.conf \
-   file://xorg.conf.d/99-calibration.conf \
- "
+SRC_URI_append_rpi = " \
+file://xorg.conf.d/98-pitft.conf \
+file://xorg.conf.d/99-calibration.conf \
+"

 do_install_append_rpi () {
-   install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
-   install -m 0644 ${WORKDIR}/xorg.conf.d/10-evdev.conf 
${D}/${sysconfdir}/X11/xorg.conf.d/
-
-   PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
-   if [ "${PITFT}" = "1" ]; then
-   install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf 
${D}/${sysconfdir}/X11/xorg.conf.d/
-   install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf 
${D}/${sysconfdir}/X11/xorg.conf.d/
-   fi
+PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
+if [ "${PITFT}" = "1" ]; then
+install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf 
${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf 
${D}/${sysconfdir}/X11/xorg.conf.d/
+fi
 }

 FILES_${PN}_rpi += "${sysconfdir}/X11/xorg.conf 
${sysconfdir}/X11/xorg.conf.d/*"




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [PATCH] yocto-compat-layer.py: Add script to YP Compatible Layer validation

2017-02-17 Thread Christopher Larson

On Fri, Feb 17, 2017 at 3:39 PM, Christopher Larson 
wrote:

> On Fri, Feb 17, 2017 at 2:26 PM, Aníbal Limón <
> anibal.li...@linux.intel.com> wrote:
>
>> +parser.add_argument('-l', '--layer', metavar='LAYER_DIR',
>> +help='Layer to test compatibility with Yocto Project',
>> +action='store', required=True)
>>
>
> The behavior of this argument is quite unintuitive. First, this path isn’t
> actually used as the layer directory, detect_layers searches down from that
> path to *find* layers in that subdirectory, so the argument isn’t what it
> says it is. Second, why are you making an option mandatory rather than just
> using arguments?
>
> That is, why `layer-compat-layer.py -l layerpath` rather than
> `layer-compat-layer.py layerpath`. If you change the call to
> `parser.add_argument(‘layer’, …)` it’d change to the latter behavior.
>

Worth noting that you could, and probably should, also use nargs=‘+’ to let
the user specify multiple layers to check, rather than a single path, if
you go the latter route, and if not, you could change it to an append style
(for the ‘action’) argument to accomplish the same.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [[RFC][PATCH]] yocto-compat-layer.py: Add script to YP Compatible Layer validation

2017-02-17 Thread Aníbal Limón



On 02/13/2017 10:27 AM, Aníbal Limón wrote:
> 
> 
> On 02/11/2017 08:04 PM, Christopher Larson wrote:
>> On Sat, Feb 11, 2017 at 10:55 AM, Aníbal Limón >> wrote:
>>
>>> During the development of this script based on OEQA framework i found a
>>> bug causing don't display stack traces, i sent a fix to the ML [1] also
>>> is on my branch at [2].
>>>
>>> I attached and example of how a log file looks, the example log results
>>> are based on meta-yocto-bsp.
>>>
>>> Cheers,
>>> alimon
>>>
>>> [1]
>>> http://lists.openembedded.org/pipermail/openembedded-core/
>>> 2017-February/132494.html
>>> [2]
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
>>> log/?h=alimon/yp_compatible
>>>
>>
>> This seems like a good start, but this isn’t useful:
>>
>> AssertionError: True is not false : Layer meta-yocto-bsp changed
>> signatures.
>>
>> Presumably this is telling the user it’s modifying things without using the
>> appropriate overrides for machine or distro, but it doesn’t actually tell
>> them that, and displaying the changed checksums isn’t of a great deal of
>> use on its own either, I’d suggest at least capturing the changed variables
>> via bitbake-diffsigs or bitbake -S printdiff.
> 
> Ok i can add another tests using bitbake -S printdiff.

Hi Christopher,

Currently the printdiff is broke, i agree with the idea to show what
actually changes in the signature but there are some work to be done in
printdiff.

alimon

> 
> I have a question, did you see the changed signatures like the attached
> results log ones?
> 
> Example,
> 
> AssertionError: True is not false : Layer meta-yocto-bsp changed signatures.
> packagegroup-core-lsb:do_build changed 3a1b91e693c766befca17e00ca69cfe9
> -> 1153f4c44d409486e10a19449981aef7
> packagegroup-core-lsb:do_package_write_rpm changed
> 7fafda279503fb441f957fe88981cbc9 -> 45845055584bad62e1b6d67b12e668bd
> packagegroup-core-lsb:do_package changed
> c312cfe0956cecd9af010de2de09dc89 -> 3d00ea36ae703c99c2e8be57ad309a04
> meta-world-pkgdata:do_build changed d62a25aedc0adc4ed0832ea20141c4b7 ->
> e8ee6e0e34122c095bc62a26e90be51f
> packagegroup-core-lsb:do_packagedata changed
> 9a63506a1764a11a5177c206839ce8ba -> 919b5c641cc779e59bd8df94b50a3d07
> packagegroup-core-lsb:do_package_qa changed
> 53a4bafbdea1fc41098ae48aef584b12 -> babec54733e94d0df008e237927552e7
> 
> 
> If not please apply this patch [1]
> 
> Best regards,
>   alimon
> 
> [1]
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=alimon/yp_compatible=f35f9b2bc068ee4e50acdc163464da4aaadda956
> 
>>
> 
> 
> 



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

[yocto] [meta-rockchip][PATCH 3/3] rockchip-next-img: add image for rockchip next-dev u-boot

2017-02-17 Thread Trevor Woerner

From: Jacob Chen 

Being different from the previous rk-boot which use parameter, next-dev u-boot
use gpt partition, so it needs to generate a different image.

Reviewed-by: Trevor Woerner 
Signed-off-by: Jacob Chen 
---
 classes/rockchip-next-img.bbclass | 130 ++
 conf/machine/include/rk3288.inc   |   4 ++
 2 files changed, 134 insertions(+)
 create mode 100644 classes/rockchip-next-img.bbclass

diff --git a/classes/rockchip-next-img.bbclass 
b/classes/rockchip-next-img.bbclass
new file mode 100644
index 000..cd87dee
--- /dev/null
+++ b/classes/rockchip-next-img.bbclass
@@ -0,0 +1,130 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+inherit image_types
+
+# Use an uncompressed ext4 by default as rootfs
+IMG_ROOTFS_TYPE = "ext4"
+IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}"
+
+# This image depends on the rootfs image
+IMAGE_TYPEDEP_rockchip-next-img = "${IMG_ROOTFS_TYPE}"
+
+NEXT_IMG   = "${IMAGE_NAME}.next.img"
+BOOT_IMG   = "boot.img"
+MINILOADER = "loader.bin"
+UBOOT  = "u-boot.out"
+TRUST  = "trust.out"
+
+# Target image total size [in MiB]
+NEXT_IMG_SIZE ?= "4096"
+
+# default partitions [in Sectors]
+# More info at http://rockchip.wikidot.com/partitions
+LOADER1_SIZE = "8000"
+RESERVED1_SIZE = "128"
+RESERVED2_SIZE = "8192"
+LOADER2_SIZE = "8192"
+ATF_SIZE = "8192"
+BOOT_SIZE = "229376"
+
+IMAGE_DEPENDS_rockchip-next-img = "parted-native \
+   u-boot-mkimage-native \
+   mtools-native \
+   dosfstools-native \
+   virtual/kernel:do_deploy \
+   virtual/bootloader:do_deploy"
+
+PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_image"
+
+IMAGE_CMD_rockchip-next-img () {
+   # Change to image directory
+   cd ${DEPLOY_DIR_IMAGE}
+
+   create_rk_image
+
+   ${PER_CHIP_IMG_GENERATION_COMMAND}
+}
+
+create_rk_image () {
+
+   echo "Creating filesystem with total size ${NEXT_IMG_SIZE} MiB"
+
+   # Remove the exist image
+   rm -rf *.next.img
+
+   # Initialize sdcard image file
+   dd if=/dev/zero of=${NEXT_IMG} bs=1M count=0 seek=${NEXT_IMG_SIZE}
+
+   # Create partition table
+   parted -s ${NEXT_IMG} mklabel gpt
+
+   # Create vendor defined partitions
+   LOADER1_START=64
+   RESERVED1_START=`expr ${LOADER1_START}  + ${LOADER1_SIZE}`
+   RESERVED2_START=`expr ${RESERVED1_START}  + ${RESERVED1_SIZE}`
+   LOADER2_START=`expr ${RESERVED2_START}  + ${RESERVED2_SIZE}`
+   ATF_START=`expr ${LOADER2_START}  + ${LOADER2_SIZE}`
+   BOOT_START=`expr ${ATF_START}  + ${ATF_SIZE}`
+   ROOTFS_START=`expr ${BOOT_START}  + ${BOOT_SIZE}`
+
+   parted -s ${NEXT_IMG} unit s mkpart loader1 ${LOADER1_START} `expr 
${RESERVED1_START} - 1`
+   parted -s ${NEXT_IMG} unit s mkpart reserved1 ${RESERVED1_START} `expr 
${RESERVED2_START} - 1`
+   parted -s ${NEXT_IMG} unit s mkpart reserved2 ${RESERVED2_START} `expr 
${LOADER2_START} - 1`
+   parted -s ${NEXT_IMG} unit s mkpart loader2 ${LOADER2_START} `expr 
${ATF_START} - 1`
+   parted -s ${NEXT_IMG} unit s mkpart atf ${ATF_START} `expr 
${BOOT_START} - 1`
+
+   # Create boot partition and mark it as bootable
+   parted -s ${NEXT_IMG} unit s mkpart boot ${BOOT_START} `expr 
${ROOTFS_START} - 1`
+   parted -s ${NEXT_IMG} set 6 boot on
+
+   # Create rootfs partition
+   parted -s ${NEXT_IMG} unit s mkpart root ${ROOTFS_START} 100%
+
+   parted ${NEXT_IMG} print
+
+   # Delete the boot image to avoid trouble with the build cache
+   rm -f ${WORKDIR}/${BOOT_IMG}
+
+   # Create boot partition image
+   BOOT_BLOCKS=$(LC_ALL=C parted -s ${NEXT_IMG} unit b print | awk '/ 6 / 
{ print substr($4, 1, length($4 -1)) / 512 /2 }')
+   BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63`
+
+   mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS
+   mcopy -i ${WORKDIR}/${BOOT_IMG} -s 
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin ::${KERNEL_IMAGETYPE}
+
+   DEVICETREE_DEFAULT=""
+   for DTS_FILE in ${KERNEL_DEVICETREE}; do
+   [ -n "${DEVICETREE_DEFAULT}"] && 
DEVICETREE_DEFAULT="${DTS_FILE}"
+   mcopy -i ${WORKDIR}/${BOOT_IMG} -s 
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTS_FILE} ::${DTS_FILE}
+   done
+
+   # Create extlinux config file
+   cat > ${WORKDIR}/extlinux.conf <>  ${WORKDIR}/${UBOOT}
+   dd if=${WORKDIR}/${UBOOT} of=${NEXT_IMG} conv=notrunc,fsync seek=64
+
+}
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index f067ad5..68936bf 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -9,7 +9,11 @@ require conf/machine/include/soc-family.inc
 PREFERRED_PROVIDER_virtual/kernel = "linux"
 KERNEL_IMAGETYPE = "zImage"
 KBUILD_DEFCONFIG =

[yocto] [meta-rockchip][PATCH 2/3] u-boot-rockchip: add

2017-02-17 Thread Trevor Woerner

From: Jacob Chen 

Rockchip next-dev U-boot is the next generation of rockchip u-boot, will also
be an upstream tracking branch At present, this branch is just a rebased
upstream u-boot.

Reviewed-by: Trevor Woerner 
Signed-off-by: Jacob Chen 
---
 conf/machine/firefly-rk3288.conf   |  1 +
 conf/machine/include/rk3288.inc|  8 +++-
 recipes-bsp/u-boot/u-boot-rockchip_next.bb | 18 ++
 3 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_next.bb

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 8fa005d..58d752b 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -8,3 +8,4 @@
 
 include conf/machine/include/rk3288.inc
 KERNEL_DEVICETREE = "rk3288-firefly.dtb"
+UBOOT_MACHINE = "firefly-rk3288_defconfig"
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 86fc567..f067ad5 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -1,9 +1,15 @@
 # Copyright (C) 2015 Romain Perier
 # Released under the MIT license (see COPYING.MIT for the terms)
 
+SOC_FAMILY = "rk3288"
+
 require conf/machine/include/tune-cortexa17.inc
+require conf/machine/include/soc-family.inc
 
 PREFERRED_PROVIDER_virtual/kernel = "linux"
-SERIAL_CONSOLES = "115200;ttyS2"
 KERNEL_IMAGETYPE = "zImage"
 KBUILD_DEFCONFIG = "multi_v7_defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader = "u-boot-rockchip"
+SERIAL_CONSOLES = "115200;ttyS2"
+SPL_BINARY = "u-boot-spl-dtb.bin"
diff --git a/recipes-bsp/u-boot/u-boot-rockchip_next.bb 
b/recipes-bsp/u-boot/u-boot-rockchip_next.bb
new file mode 100644
index 000..845f9da
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip_next.bb
@@ -0,0 +1,18 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+require recipes-bsp/u-boot/u-boot.inc
+
+DESCRIPTION = "Rockchip next-dev U-Boot"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = 
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
+COMPATIBLE_MACHINE = "(rk3288)"
+
+SRC_URI = "git://github.com/rockchip-linux/u-boot.git;branch=release;"
+SRCREV = "${AUTOREV}"
+S = "${WORKDIR}/git"
+
+do_deploy_prepend () {
+   # copy to default search path
+   cp ${B}/spl/${SPL_BINARY} ${B}/
+}
-- 
2.11.0.258.ge05806d

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

[yocto] [meta-rockchip][PATCH 0/3] firefly gpt emmc update

2017-02-17 Thread Trevor Woerner

This set of patches adds to meta-rockchip the ability to create an update
image using the latest GPT-style image for flashing to a firefly-rk3288's
eMMC.

Jacob Chen (2):
  u-boot-rockchip: add
  rockchip-next-img: add image for rockchip next-dev u-boot

Trevor Woerner (1):
  remove DEFAULTTUNEs

 README |  15 
 classes/rockchip-next-img.bbclass  | 130 +
 conf/machine/firefly-rk3288.conf   |   1 +
 conf/machine/include/rk3066.inc|   1 -
 conf/machine/include/rk3288.inc|  13 ++-
 recipes-bsp/u-boot/u-boot-rockchip_next.bb |  18 
 6 files changed, 175 insertions(+), 3 deletions(-)
 create mode 100644 classes/rockchip-next-img.bbclass
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_next.bb

-- 
2.11.0.258.ge05806d

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

[yocto] Yocto Project Status WW08’17

2017-02-17 Thread Jolley, Stephen K

Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017


*** FEATURE FREEZE for 2.3 in one week ***


SWAT team rotation: Juro -> Anibal on Feb. 17, 2017.

SWAT team rotation: Anibal -> Todor on Feb. 24, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·M2-rc3 was released and we’re now focusing on M3 which is due at the 
end of next week.

·This week appears to be the calm before the storm, there are a number 
of key changes pending for M3 which is our feature freeze date for 2.3. In 
particular we need to make a decision about rpm 4 verses 5 and the smart/dnf 
change. Beyond this point, only bugfixes are accepted as we stabilize for 
release.

·YP 2.2.1 is now in QA after a successful build.  Current status is at: 
https://wiki.yoctoproject.org/wiki/2.2_QA_Status#Summary_Report

·Next week is ELC (bad timing for M3) and various people are travelling 
and/or distracted so this may impact patch merging and how quickly we can 
stabilize and get M3 into QA.


Proposed upcoming dot releases:

YP 2.2.1 Release by Feb. 24, 2017

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017


Key YP 2.3 Dates:

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017


Tracking Metrics:

WDD 2683 (last week 2667)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support

2017-02-17 Thread Trevor Woerner

Hi Eddie,

On Fri 2017-02-17 @ 04:56:28 PM, Eddie Cai wrote:
> 2017-02-17 11:33 GMT+08:00 Trevor Woerner :
> > You've put "morty" in the subject lines which to me means you're hoping 
> > these
> > patches will be applied against the morty branch of meta-rockchip. Morty was
> > released in October of 2016 which, at this point, is almost 5 months ago. At
> > this point patches should only go against morty to fix critical issues. 
> > These
> > patches look more like they're adding functionality, so I'll apply them to
> > master instead. The next release is Pyro which is expected around April 
> > 2017.
> I will remove branch next time i send patches.

You're welcome to add a branch name to any patch you send :-) But ideally a
patch that adds new functionality would be applied to master and a patch that
fixes a serious bug, a security issue, or makes a broken build succeed again
could be branch-specific.

> > On Tue 2017-02-14 @ 01:54:20 PM, Eddie Cai wrote:
> >> This patch set add main line kernel support for meta-rockchip
> >>
> >> Eddie Cai (6):
> >>   machine: Use cortexa17hf-neon-vfpv4 as default tune for rk3288.inc
> >
> > As I've mentioned before, Yocto/OE is a _distribution_ builder, not just an
> > image builder. As such most people in the community consider DEFAULTTUNES to
> > be a DISTRO-level policy. In other words, this is not something that should 
> > be
> > set by the BSP. One distro might want to use softfloat, while another wants
> > hard-float. It will be easier for people who make distributions using 
> > Yocto/OE
> > to use this layer when these types of things are not set at this level. 
> > Users
> > are free to use these distributions (by adding their layers) or they can 
> > set a
> > DEFAULTTUNE in their conf/local.conf file.
> >
> > I'll add a note to the README pointing this out so people can be aware of 
> > this
> > configuration tweak, but I won't take this patch into the BSP. I've been 
> > able
> > to build and run images where the DEFAULTTUNE is not set and they run just
> > fine. Another patch (which I'll be happy to create) will need to look for 
> > this
> > tune in recipes that provide things like mali support.
> I found there are many meta using hardfloat. see below for example.

I wouldn't say there are many, there are some but that doesn't mean they're
correct in doing this :-) The Yocto/OE community is very lax; nobody's going
to take down a layer that doesn't play nicely with other layers, but that
doesn't mean they're correct :-)

> So
> i think what meta-xxx(could be rockchip, freescale, allwinner etc)
> means building optimized distribution for xxx.

I disagree (please see my next response)

> If people come to
> meta-rockchip.  They must want to build a image/distribuition run on
> rockchip platform. If not, They should go to meta-debian or other
> generic meta rather than meta-rockchip.  ie. we won't expect a image
> built by meta-amd can run on rockchip platform. right?

If you wanted to run debian on your rockchip device then you would include
meta-debian in your bblayers. But while bitbake is building your debian image
for your rockchip device it will need to know what kernel to use, what kernel
configuration to use (device tree, .config, etc) and it will need to know what
bootloader to use (e.g. maybe u-boot, and if so, which version? and from where
do you clone the repository? denx? or vendor-specific github?) Who is going
to answer these questions? Who is going to tell bitbake which bootloader to
use for your rockchip device? That's what meta-rockchip is for, and that's why
people add it to their bblayers.

When people add meta-rockchip to their build it's because their build needs to
know which kernel and bootloader to use (and various other bits).

But the decision whether the user wants to build an image that will run on as
many boards as possible, or whether they want a build that will run as fast as
possible on only one board is actually a distro-level decision.

If you download an x86, 64-bit version of Fedora, openSUSE, or debian to
install on your desktop machine, you won't find different installs that are
tweaked for i7, Xeon, or AMD processors. You'll find one generic x86-64
download that works on as many desktop computers as possible. But if you
want a Linux distribution that is as tweaked out as possible for exactly the
processor you're running, you would look at Arch or Gentoo. The distribution
decides whether your code is as generic as possible, or tweaked for exactly
your hardware.

For many years I too believed exactly the same things you're saying, and I too
argued exactly the same arguments you're now making. I hope it doesn't take
you as long as it took me to realize that a BSP layer is for informing the
build where to find board-specific code (such as vendor kernels and
bootloaders) and tuning the build is for distro layers to decide ;-)

[yocto] Placing xxxx.pc in nativesdk?

2017-02-17 Thread Takashi Matsuzawa

Hello, Yocto.

Maybe a basic question but I am being puzzled.


i) Recipe A builds module, and the module expects that xkbcommon.pc is 
available (checked in autotool by calling pkg-config)

ii) module A build fails, since it cannot find xkbcommon.pc, according to the 
config.log.


(in TEMPDIR/work)
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/image/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/sysroot-destdir/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/build/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/packages-split/libxkbcommon-dev/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/package/usr/lib/pkgconfig/xkbcommon.pc

I can find it above, but I do not seem to find it in x86_64-nativesdk-x 
tree, so it may be the cause of the problem.
The recipe A has DEPENDS that include "libxkbcommon"

My question is, in general, what is lacking here that prevent xkbcommon.pc to 
be found from other recipe / configure?

.pc is in the target image /isr/lib/pkgconfig successfully, so I believe I 
need something to make it available in cross SDK?


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

Re: [yocto] Changing UID GID (thaks)

2017-02-17 Thread Dominig ar Foll (Intel Open Source)



Le 15/02/2017 à 15:57, Patrick Ohly a écrit :
>
> Is that for partial updates with OSTree or something else?
Yes we use OSTree in AGL but the issue is very similar to the one faced
by Ostro.
Thanks to Joshua and Patrick for the pointers.

-- 
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre

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

Re: [yocto] [meta-raspberrypi] WiFi on rpi3?

Re: [yocto] [meta-raspberrypi][PATCH] xserver-xf86-config: remove evdev configuration

Re: [yocto] [PATCH] yocto-compat-layer.py: Add script to YP Compatible Layer validation

Re: [yocto] [[RFC][PATCH]] yocto-compat-layer.py: Add script to YP Compatible Layer validation

[yocto] [meta-rockchip][PATCH 3/3] rockchip-next-img: add image for rockchip next-dev u-boot

[yocto] [meta-rockchip][PATCH 2/3] u-boot-rockchip: add

[yocto] [meta-rockchip][PATCH 0/3] firefly gpt emmc update

[yocto] Yocto Project Status WW08’17

Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support

[yocto] Placing xxxx.pc in nativesdk?

Re: [yocto] Changing UID GID (thaks)

11 matches

Site Navigation

Mail list logo

Footer information