Re: [yocto] [PATCH 3/3] recipes-bsp/u-boot: update to the latest version

[Trevor Woerner]

a previous patch of yours did a:
require recipes-bsp/u-boot/u-boot-common.inc
which defines this SRCREV

my subtle point being: I don't get the impression you're testing your
patches, or at least not testing them correctly.

the fact you're CCing Romain suggests your either using a very old branch
of https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ or that you're
submitting patches to me for https://github.com/rockchip-linux/meta-rockchip
?
Unfortunately for me, when https://github.com/rockchip-linux/meta-rockchip
did a clone of https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/,
they left my and Romain's names as maintainers in the README (along with
instructions for github)

On Wed, May 8, 2019 at 12:19 PM ayaka  wrote:

>
> On 5/6/19 9:31 PM, Trevor Woerner wrote:
> > On Sat 2019-05-04 @ 06:43:34 PM, ayaka wrote:
> >> On 5/4/19 11:06 AM, Trevor Woerner wrote:
> >>> On Wed 2019-04-24 @ 10:59:18 PM, Randy 'ayaka' Li wrote:
> >>>> From: Randy Li 
> >>>>
> >>>> Signed-off-by: Randy Li 
> >>>> ---
> >>>>recipes-bsp/u-boot/u-boot-rockchip_git.bb | 18 ++
> >>>>1 file changed, 18 insertions(+)
> >>>>create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb
> >>>>
> >>>> diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> >>>> new file mode 100644
> >>>> index 000..aa4b84d
> >>>> --- /dev/null
> >>>> +++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> >>>> @@ -0,0 +1,18 @@
> >>>> +# Copyright (C) 2019 SUMOMO Computer Assocation
> >>>> +# Released under the MIT license (see COPYING.MIT for the terms)
> >>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >>>> +
> >>>> +include u-boot-rockchip.inc
> >>>> +
> >>>> +DESCRIPTION = "Rockchip U-Boot"
> >>>> +
> >>>> +LIC_FILES_CHKSUM =
> "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
> >>>> +
> >>>> +SRC_URI = " \
> >>>> +  git://github.com/rockchip-linux/u-boot.git;branch=release; \
> >>>> +  file://binutils-2.28-ld-fix.patch \
> >>>> +  file://gcc7_fixup.patch \
> >>>> +  "
> >>>> +
> >>>> +S = "${WORKDIR}/git"
> >>>> +PV = "v2019.01"
> >>> This doesn't even get past the fetching stage:
> >> I am sorry, I forget that ssh git protocol only work for those users who
> >> uploaded their key to the github, I would change it back to https.
> >>> WARNING: u-boot-rockchip-1_v2019.01-r0 do_fetch: Failed to fetch
> URL git://github.com/rockchip-linux/u-boot.git;branch=release;,
> attempting MIRRORS if available
> >>> ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure:
> Unable to find revision 3c99166441bf3ea325af2da83cfe65430b49c066 in branch
> release even from upstream
> >>> ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure for
> URL: 'git://github.com/rockchip-linux/u-boot.git;branch=release;'. Unable
> to fetch URL from any source.
> >>> ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch:
> >>> ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Function failed:
> base_do_fetch
> >>> ERROR: Task
> (/opt/oe/configs/z/build-master/meta-rockchip/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:do_fetch)
> failed with exit code '1'
> > The problem is that it's trying to fetch commit 3c9916 which doesn't
> exist on
> > github.com/rockchip-linux/u-boot.git. That revision is on upstream
> U-Boot.
> How comes? I didn't write any commit id there, it is based on the branch
> at all.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 3/3] recipes-bsp/u-boot: update to the latest version

[Trevor Woerner]

On Sat 2019-05-04 @ 06:43:34 PM, ayaka wrote:
> 
> On 5/4/19 11:06 AM, Trevor Woerner wrote:
> > On Wed 2019-04-24 @ 10:59:18 PM, Randy 'ayaka' Li wrote:
> > > From: Randy Li 
> > > 
> > > Signed-off-by: Randy Li 
> > > ---
> > >   recipes-bsp/u-boot/u-boot-rockchip_git.bb | 18 ++
> > >   1 file changed, 18 insertions(+)
> > >   create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb
> > > 
> > > diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb 
> > > b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> > > new file mode 100644
> > > index 000..aa4b84d
> > > --- /dev/null
> > > +++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> > > @@ -0,0 +1,18 @@
> > > +# Copyright (C) 2019 SUMOMO Computer Assocation
> > > +# Released under the MIT license (see COPYING.MIT for the terms)
> > > +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > > +
> > > +include u-boot-rockchip.inc
> > > +
> > > +DESCRIPTION = "Rockchip U-Boot"
> > > +
> > > +LIC_FILES_CHKSUM = 
> > > "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
> > > +
> > > +SRC_URI = " \
> > > + git://github.com/rockchip-linux/u-boot.git;branch=release; \
> > > + file://binutils-2.28-ld-fix.patch \
> > > + file://gcc7_fixup.patch \
> > > + "
> > > +
> > > +S = "${WORKDIR}/git"
> > > +PV = "v2019.01"
> > This doesn't even get past the fetching stage:
> I am sorry, I forget that ssh git protocol only work for those users who
> uploaded their key to the github, I would change it back to https.
> > 
> > WARNING: u-boot-rockchip-1_v2019.01-r0 do_fetch: Failed to fetch URL 
> > git://github.com/rockchip-linux/u-boot.git;branch=release;, attempting 
> > MIRRORS if available
> > ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure: Unable 
> > to find revision 3c99166441bf3ea325af2da83cfe65430b49c066 in branch release 
> > even from upstream
> > ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure for URL: 
> > 'git://github.com/rockchip-linux/u-boot.git;branch=release;'. Unable to 
> > fetch URL from any source.
> > ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch:
> > ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Function failed: 
> > base_do_fetch
> > ERROR: Task 
> > (/opt/oe/configs/z/build-master/meta-rockchip/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:do_fetch)
> >  failed with exit code '1'

The problem is that it's trying to fetch commit 3c9916 which doesn't exist on
github.com/rockchip-linux/u-boot.git. That revision is on upstream U-Boot.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 3/3] recipes-bsp/u-boot: update to the latest version

[Trevor Woerner]

On Wed 2019-04-24 @ 10:59:18 PM, Randy 'ayaka' Li wrote:
> From: Randy Li 
> 
> Signed-off-by: Randy Li 
> ---
>  recipes-bsp/u-boot/u-boot-rockchip_git.bb | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb
> 
> diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb 
> b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> new file mode 100644
> index 000..aa4b84d
> --- /dev/null
> +++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
> @@ -0,0 +1,18 @@
> +# Copyright (C) 2019 SUMOMO Computer Assocation
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +include u-boot-rockchip.inc
> +
> +DESCRIPTION = "Rockchip U-Boot"
> +
> +LIC_FILES_CHKSUM = 
> "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
> +
> +SRC_URI = " \
> + git://github.com/rockchip-linux/u-boot.git;branch=release; \
> + file://binutils-2.28-ld-fix.patch \
> + file://gcc7_fixup.patch \
> + "
> +
> +S = "${WORKDIR}/git"
> +PV = "v2019.01"

This doesn't even get past the fetching stage:

WARNING: u-boot-rockchip-1_v2019.01-r0 do_fetch: Failed to fetch URL 
git://github.com/rockchip-linux/u-boot.git;branch=release;, attempting MIRRORS 
if available
ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure: Unable 
to find revision 3c99166441bf3ea325af2da83cfe65430b49c066 in branch release 
even from upstream
ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher failure for URL: 
'git://github.com/rockchip-linux/u-boot.git;branch=release;'. Unable to fetch 
URL from any source.
ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch:
ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Function failed: 
base_do_fetch
ERROR: Task 
(/opt/oe/configs/z/build-master/meta-rockchip/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:do_fetch)
 failed with exit code '1'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 1/3] recipes-bsp/u-boot: fixup build for gcc7

[Trevor Woerner]

On Wed 2019-04-24 @ 10:59:16 PM, Randy 'ayaka' Li wrote:
> Signed-off-by: Randy Li 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  .../u-boot/u-boot-rockchip/gcc7_fixup.patch   | 38 +++

Why do we care about gcc7 on master? Master only has support for gcc8.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH v2 01/10] conf/machine: add support for rk3399

[Trevor Woerner]

On Tue 2019-04-23 @ 09:25:05 PM, Randy 'ayaka' Li wrote:
> RK3399 is a new generation powerful SoC from Rockchip, which has
> Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU.
> 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/excavator-rk3399.conf | 12 
>  conf/machine/firefly-rk3399.conf   | 14 ++
>  conf/machine/include/rk3399.inc| 17 +
>  3 files changed, 43 insertions(+)
>  create mode 100644 conf/machine/excavator-rk3399.conf
>  create mode 100644 conf/machine/firefly-rk3399.conf
>  create mode 100644 conf/machine/include/rk3399.inc
> 
> diff --git a/conf/machine/excavator-rk3399.conf 
> b/conf/machine/excavator-rk3399.conf
> new file mode 100644
> index 000..8506a50
> --- /dev/null
> +++ b/conf/machine/excavator-rk3399.conf
> @@ -0,0 +1,12 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EXCAVATOR 3399
> +
> +include conf/machine/include/rk3399.inc
> +
> +KERNEL_DEVICETREE = "rockchip/rk3399-sapphire-excavator.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"
> +
> +GPTIMG_APPEND = "console=ttyS2,150n8 rw root=PARTUUID=B921B045-1DF0 
> rootfstype=ext4 init=/sbin/init"
> diff --git a/conf/machine/firefly-rk3399.conf 
> b/conf/machine/firefly-rk3399.conf
> new file mode 100644
> index 000..4e35c3d
> --- /dev/null
> +++ b/conf/machine/firefly-rk3399.conf
> @@ -0,0 +1,14 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: Firefly RK3399
> +#@DESCRIPTION: Firefly-RK3399 is a Six-Core 64-bit High-Performance Platform.
> +#http://www.t-firefly.com/en/
> +
> +include conf/machine/include/rk3399.inc
> +
> +KERNEL_DEVICETREE = "rockchip/rk3399-firefly.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"
> +
> +GPTIMG_APPEND = "console=ttyS2,150n8 rw root=PARTUUID=B921B045-1DF0 
> rootfstype=ext4 init=/sbin/init"
> diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
> new file mode 100644
> index 000..9237616
> --- /dev/null
> +++ b/conf/machine/include/rk3399.inc
> @@ -0,0 +1,17 @@
> +# Copyright (C) 2019 SUMOMO Computer Association
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SOC_FAMILY = "rk3399"
> +
> +require conf/machine/include/tune-cortexa72.inc
> +require conf/machine/include/soc-family.inc
> +require conf/machine/include/rockchip-defaults.inc
> +
> +SERIAL_CONSOLES = "150;ttyS2"
> +KERNEL_IMAGETYPE = "Image"
> +KBUILD_DEFCONFIG = "defconfig"
> +
> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"

Using u-boot-rockchip causes build failures. In both cases (excavator-rk3399
and firefly-rk3399) I get:

| #
| # configuration written to .config
| #
| make[1]: Leaving directory 
'/z/build-master/meta-rockchip/build/tmp-glibc/work/firefly_rk3399-oe-linux/u-boot-rockchip/20171218-r0/build'
| make: Leaving directory 
'/z/build-master/meta-rockchip/build/tmp-glibc/work/firefly_rk3399-oe-linux/u-boot-rockchip/20171218-r0/git'
| 
/z/build-master/meta-rockchip/build/tmp-glibc/work/firefly_rk3399-oe-linux/u-boot-rockchip/20171218-r0/temp/run.do_configure.27647:
 line 113: merge_config.sh: command not found
| WARNING: 
/z/build-master/meta-rockchip/build/tmp-glibc/work/firefly_rk3399-oe-linux/u-boot-rockchip/20171218-r0/temp/run.do_configure.27647:1
 exit 127 from 'merge_config.sh -m .config'
| ERROR: Function failed: do_configure (log file is located at 
/z/build-master/meta-rockchip/build/tmp-glibc/work/firefly_rk3399-oe-linux/u-boot-rockchip/20171218-r0/temp/log.do_configure.27647)

Do you have an updated recipe for u-boot-rockchip?

> +
> +IMAGE_FSTYPES = "rockchip-gpt-img"
> +IMAGE_CLASSES = "rockchip-gpt-img"
> -- 
> 2.20.1
> 
> -- 
> ___
> 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] [PATCH 1/5] conf/machine: rk3288: Add some machine files

[Trevor Woerner]

On Sun 2019-04-21 @ 11:53:35 PM, Randy 'ayaka' Li wrote:
> Evb-rk3288 is the offical evaluate board.
> Fennec-rk3288 and Tinker-rk3288 is rk3288 based SBCs.
> Tinker Boards is a RPi compatible board made by ASUS.

I would rather these were separated out as individual commits. meta-rockchip
already has working support for the tinker-rk3288 board, so it's not being
added here.

> 
> Signed-off-by: Jacob Chen 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/evb-rk3288.conf| 10 ++
>  conf/machine/fennec-rk3288.conf | 10 ++
>  conf/machine/include/rk3288.inc |  5 +
>  conf/machine/tinker-rk3288.conf |  2 ++
>  4 files changed, 27 insertions(+)
>  create mode 100644 conf/machine/evb-rk3288.conf
>  create mode 100644 conf/machine/fennec-rk3288.conf
> 
> diff --git a/conf/machine/evb-rk3288.conf b/conf/machine/evb-rk3288.conf
> new file mode 100644
> index 000..e6c1f1e
> --- /dev/null
> +++ b/conf/machine/evb-rk3288.conf
> @@ -0,0 +1,10 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EVB 3288
> +
> +include conf/machine/include/rk3288.inc
> +
> +KERNEL_DEVICETREE = "rk3288-evb-act8846.dtb"
> +UBOOT_MACHINE = "evb-rk3288_defconfig"


> diff --git a/conf/machine/fennec-rk3288.conf b/conf/machine/fennec-rk3288.conf
> new file mode 100644
> index 000..23e3ee7
> --- /dev/null
> +++ b/conf/machine/fennec-rk3288.conf
> @@ -0,0 +1,10 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: FENNEC RK3288
> +
> +include conf/machine/include/rk3288.inc
> +
> +KERNEL_DEVICETREE = "rk3288-fennec.dtb"
> +UBOOT_MACHINE = "fennec-rk3288_defconfig"


> diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
> index 0528e8a..73b39fb 100644
> --- a/conf/machine/include/rk3288.inc
> +++ b/conf/machine/include/rk3288.inc
> @@ -8,9 +8,14 @@ require conf/machine/include/soc-family.inc
>  require conf/machine/include/rockchip-defaults.inc
>  
>  SERIAL_CONSOLES = "115200;ttyS2"
> +SPL_BINARY = "u-boot-spl-dtb.bin"

You've put a U-Boot variable in the middle of a Linux block. This variable is
already defined in this file just a couple lines down (in the U-Boot section)
and uses a ?= to set it to the exact same thing you're setting it to.

> +KERNEL_IMAGETYPE = "zImage"
> +KBUILD_DEFCONFIG = "multi_v7_defconfig"

These two things are defined exactly the same in
conf/machine/include/rockchip-defaults.inc, which is already included above
with the "require ..." line.

>  
>  PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
>  SPL_BINARY ?= "u-boot-spl-dtb.bin"
>  
>  IMAGE_FSTYPES = "rockchip-gpt-img"
>  IMAGE_CLASSES += "rockchip-gpt-img"
> +
> +APPEND = "console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 rootfstype=ext4 
> init=/sbin/init"

I'm guessing this was supposed to be 'GPTIMG_APPEND = "..."'? In any case, I'm
curious why you're switching from mmcblk0 to mmcblk2 here,
classes/rockchip-gpt-img.bbclass already contains this logic.


> diff --git a/conf/machine/tinker-rk3288.conf b/conf/machine/tinker-rk3288.conf
> index 294bdc7..cf793cd 100644
> --- a/conf/machine/tinker-rk3288.conf
> +++ b/conf/machine/tinker-rk3288.conf
> @@ -9,3 +9,5 @@ require conf/machine/include/rk3288.inc
>  
>  KERNEL_DEVICETREE = "rk3288-tinker.dtb"
>  UBOOT_MACHINE = "tinker-rk3288_defconfig"
> +
> +GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 
> rootfstype=ext4 init=/sbin/init"
> -- 
> 2.20.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 3/5] conf/machine: add support for rk3328

[Trevor Woerner]

On Sun 2019-04-21 @ 11:53:37 PM, Randy 'ayaka' Li wrote:
> The RK3328 is a SoC with Quad-core Cortex-A53 for Smart OTT/IPTV.
> 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/evb-rk3328.conf| 12 
>  conf/machine/include/rk3328.inc | 18 ++
>  2 files changed, 30 insertions(+)
>  create mode 100644 conf/machine/evb-rk3328.conf
>  create mode 100644 conf/machine/include/rk3328.inc
> 
> diff --git a/conf/machine/evb-rk3328.conf b/conf/machine/evb-rk3328.conf
> new file mode 100644
> index 000..67d2083
> --- /dev/null
> +++ b/conf/machine/evb-rk3328.conf
> @@ -0,0 +1,12 @@
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EVB 3388
> +
> +include conf/machine/include/rk3328.inc
> +
> +KERNEL_DEVICETREE = "rockchip/rk3328-evb.dtb"
> +UBOOT_MACHINE = "evb-rk3328_defconfig"
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"

There is no "linux-rockchip"

> +GPTIMG_APPEND = "console=ttyS20,150n8 rw root=/dev/mmcblk2p5 
> rootfstype=ext4 init=/sbin/init"


> diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
> new file mode 100644
> index 000..8dc018e
> --- /dev/null
> +++ b/conf/machine/include/rk3328.inc
> @@ -0,0 +1,18 @@
> +# Copyright (C) 2017 Randy Li 
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +# RK3228H is the same SoC as rk3328.
> +SOC_FAMILY = "rk3328"
> +
> +require conf/machine/include/tune-cortexa53.inc
> +require conf/machine/include/soc-family.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux"

This conflicts with what you've just specified above. In any case, neither
"linux" nor "linux-rockchip" exist.

> +SERIAL_CONSOLES = "150;ttyS2"
> +KERNEL_IMAGETYPE = "Image"
> +KBUILD_DEFCONFIG = "multi_v8_defconfig"
> +
> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
> +
> +IMAGE_FSTYPES = "rockchip-gpt-img"
> +IMAGE_CLASSES = "rockchip-gpt-img"
> -- 
> 2.20.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 4/5] conf/machine: add support for rk3036

[Trevor Woerner]

On Sun 2019-04-21 @ 11:53:38 PM, Randy 'ayaka' Li wrote:
> RK3036 is a SoC from Rockchip which has Dual-Core
> ARM Cortex-A7 CPU, for low-end OTT TV Box.
> 
> Supporting video acceleration for the HEVC and AVC
> up to 1080P video. With a HDMI sink.
> 
> Signed-off-by: Randy 'ayaka' Li 
> Signed-off-by: Randy Li 
> ---
>  conf/machine/include/rk3036.inc | 19 +++
>  conf/machine/kylin-rk3036.conf  | 12 
>  2 files changed, 31 insertions(+)
>  create mode 100644 conf/machine/include/rk3036.inc
>  create mode 100644 conf/machine/kylin-rk3036.conf
> 
> diff --git a/conf/machine/include/rk3036.inc b/conf/machine/include/rk3036.inc
> new file mode 100644
> index 000..5a9c55e
> --- /dev/null
> +++ b/conf/machine/include/rk3036.inc
> @@ -0,0 +1,19 @@
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SOC_FAMILY = "rk3036"
> +
> +require conf/machine/include/tune-cortexa7.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"
> +SPL_BINARY ?= "u-boot-spl-nodtb.bin"
> +
> +IMAGE_FSTYPES = "rockchip-gpt-img"
> +IMAGE_CLASSES = "rockchip-gpt-img"
> +
> +GPTIMG_APPEND = "console=ttyS2,115200n8 rw root=/dev/mmcblk1p7 
> rootfstype=ext4 init=/sbin/init rootwait"
> diff --git a/conf/machine/kylin-rk3036.conf b/conf/machine/kylin-rk3036.conf
> new file mode 100644
> index 000..9e42e87
> --- /dev/null
> +++ b/conf/machine/kylin-rk3036.conf
> @@ -0,0 +1,12 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: Kylin rk3036
> +
> +include conf/machine/include/rk3036.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"

There is no "linux-rockchip", maybe you meant "linux-stable"?

> +
> +KERNEL_DEVICETREE = "rk3036-kylin.dtb"
> +UBOOT_MACHINE = "kylin-rk3036_defconfig"
> -- 
> 2.20.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 5/5] conf/machine: add support for rv1108

[Trevor Woerner]

On Sun 2019-04-21 @ 11:53:39 PM, Randy 'ayaka' Li wrote:
> RV1108 is a SoC specific for video enhanced and
> recording. It is embedded with a DSP for digital
> process and an ARM Cortex-A7 single core processor
> for system and application.
> 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/evb-rv1108.conf| 10 ++
>  conf/machine/include/rv1108.inc | 12 
>  2 files changed, 22 insertions(+)
>  create mode 100644 conf/machine/evb-rv1108.conf
>  create mode 100644 conf/machine/include/rv1108.inc
> 
> diff --git a/conf/machine/evb-rv1108.conf b/conf/machine/evb-rv1108.conf
> new file mode 100644
> index 000..3e85d80
> --- /dev/null
> +++ b/conf/machine/evb-rv1108.conf
> @@ -0,0 +1,10 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EVB rv1108
> +
> +include conf/machine/include/rv1108.inc
> +
> +KERNEL_DEVICETREE = "rv1108-evb.dtb"
> +UBOOT_MACHINE = "evb-rk3288_defconfig"
> diff --git a/conf/machine/include/rv1108.inc b/conf/machine/include/rv1108.inc
> new file mode 100644
> index 000..1c70ef7
> --- /dev/null
> +++ b/conf/machine/include/rv1108.inc
> @@ -0,0 +1,12 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SOC_FAMILY = "rv1108"
> +
> +require conf/machine/include/tune-cortexa7.inc
> +require conf/machine/include/soc-family.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux"

There is no "linux", maybe you meant "linux-stable"?

> +SERIAL_CONSOLES = "150;ttyS2"
> +KERNEL_IMAGETYPE = "zImage"
> +KBUILD_DEFCONFIG = "multi_v7_defconfig"
> -- 
> 2.20.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/5] conf/machine: add rk3399 support

[Trevor Woerner]

On Sun 2019-04-21 @ 11:53:36 PM, Randy 'ayaka' Li wrote:
> RK3399 is a new generation powerful SoC from Rockchip, which has
> Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU.
> 
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/excavator-rk3399.conf | 10 ++
>  conf/machine/firefly-rk3399.conf   | 15 +++
>  conf/machine/include/rk3399.inc| 17 +
>  3 files changed, 42 insertions(+)
>  create mode 100644 conf/machine/excavator-rk3399.conf
>  create mode 100644 conf/machine/firefly-rk3399.conf
>  create mode 100644 conf/machine/include/rk3399.inc
> 
> diff --git a/conf/machine/excavator-rk3399.conf 
> b/conf/machine/excavator-rk3399.conf
> new file mode 100644
> index 000..c7134d2
> --- /dev/null
> +++ b/conf/machine/excavator-rk3399.conf
> @@ -0,0 +1,10 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EXCAVATOR 3399
> +
> +include conf/machine/include/rk3399.inc
> +
> +KERNEL_DEVICETREE = "rk3399-sapphire-excavator-linux.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"


> diff --git a/conf/machine/firefly-rk3399.conf 
> b/conf/machine/firefly-rk3399.conf
> new file mode 100644
> index 000..fefafed
> --- /dev/null
> +++ b/conf/machine/firefly-rk3399.conf
> @@ -0,0 +1,15 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: Firefly RK3399
> +#@DESCRIPTION: Firefly-RK3399 is a Six-Core 64-bit High-Performance Platform.
> +#http://www.t-firefly.com/en/
> +
> +include conf/machine/include/rk3399.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"

linux-rockchip doesn't exist in git.yoctoproject.org/meta-rockchip. Has
support for this MACHINE been added upstream (i.e. kernel.org)?

> +KERNEL_DEVICETREE = "rockchip/rk3399-firefly-linux.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"
> +
> +GPTIMG_APPEND = "console=ttyS2,150n8 rw root=PARTUUID=614e- 
> rootfstype=ext4 init=/sbin/init"


> diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
> new file mode 100644
> index 000..6e2af57
> --- /dev/null
> +++ b/conf/machine/include/rk3399.inc
> @@ -0,0 +1,17 @@
> +# Copyright (C) 2019 SUMOMO Computer Association
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SOC_FAMILY = "rk3399"
> +
> +require conf/machine/include/tune-cortexa72.inc
> +require conf/machine/include/soc-family.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux"

This setting conflicts with what you set in firefly-rk3399.conf above. Ideally
include files should probably use a weaker assignment? In any case, there is
no "linux" kernel defined, maybe you want "linux-stable" instead?

> +SERIAL_CONSOLES = "150;ttyS2"
> +KERNEL_IMAGETYPE = "Image"
> +#KBUILD_DEFCONFIG = "multi_v8_defconfig"
> +
> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"

vendor-u-boot? Does upstream U-Boot support these MACHINEs?

> +
> +IMAGE_FSTYPES = "rockchip-gpt-img"
> +IMAGE_CLASSES = "rockchip-gpt-img"
> -- 
> 2.20.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip] [PATCH 0/5] add new SoCs support

[Trevor Woerner]

Hi Randy,

On Sun 2019-04-21 @ 11:53:34 PM, Randy 'ayaka' Li wrote:
> After the FOSDEM, my patches for ARMv8 cortex tuning
> are finally merged. So I think it is complete the
> lose piece at meta-rockchip.
> 
> Since the big-litte is not supported by OE now,
> I make all the chips' configure to use the big core
> tuning.

Thank you very much for your patches; I'm happy to see rk3399 support! I've
queued them up for https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu segmentation fault on gobject-introspection

[Trevor Woerner]

On Wed 2019-02-20 @ 11:50:45 PM, João Gonçalves wrote:
> Hello,
> when trying to migrate my build to master branch of oe layers I got this
> qemu segmentation fault during gobject-introspection.
> Does anyone have any clue on this?
> 
> Thank you,
> João Gonçalves
> 
> | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> | Segmentation fault (core dumped)
> | If the above error message is about missing .so libraries, then setting
> up GIR_EXTRA_LIBS_PATH in the recipe should help.
> | (typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" )
> | Command
> '['/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/g-ir-scanner-qemuwrapper',
> '/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/GLib-2.0',
> '--introspect-dump=/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/functions.txt,/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/dump.xml']'
> returned non-zero exit status 1.
> | ninja: build stopped: subcommand failed.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/temp/log.do_compile.20894)
> ERROR: Task
> (/home/joao/poky_imx6/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:do_compile)
> failed with exit code '1'

Is it possible you're building your image with the gold linker? I.e.

DISTRO_FEATURES_append = " ld-is-gold"

It looks like there's a problem using the gold linker with 32-bit ARM targets.
Everything seems to work with the regular/default bfd linker is used instead.

Please see:

http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280537.html
https://patchwork.openembedded.org/patch/159874/

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OE Summit report from SCaLE17x

[Trevor Woerner]

Hi,

Earlier this week I got back from SCaLE17x during which I taught an E-ALE
class on Buildroot, was a TA for the other E-ALE classes, organized and ran
the first ever (hopefully of more to come) OE Summit, and gave a general intro
talk on OE. I wasn't planning on giving an OE talk at SCaLE, but the person
who was supposed to talk wasn't able to make it. I had travelled to SCaLE with
a backup talk prepared as a "plan B", and it was good that I did.

I'm quite happy with how the inaugural OpenEmbedded Summit went. Everything
went off without a hitch, and there was a lot of interaction and feedback
between the speakers and the audience.

We had 4 speakers:

myself (Togan Labs): Using OE
Drew Moseley (mender.io): Mechanisms for Enabling and Configuring WiFi 
in OE
Alistair Francis (Western Digital): RISC-V and OE
Jon Mason (ARM): Kernel Development Workflows Using OE

Counting attendance is a bit tricky because people sometimes wander in and
out. Do we count someone who wanders in partway through but leaves before the
end? My talk was the least attended. I forgot to count the audience members
(since I was giving the talk), but I did notice that a couple people wandered
in during the talk. Behan counted 12; like I said, I didn't think to get a
specific number myself. In any case, my talk wasn't in the programme, since I
was filling in for someone who didn't make it to the conference. Drew's and
Jon's talks had roughly 20 audience members each, and Alistair's talk was
about 30.

It's too bad the OE Summit was pitted against SCaLE's "Embedded Track". I
think we ended up "competing" for audience members between the two of us. The
OE Summit was put in a rather large room. Between teaching and helping out
with E-ALE and running the OE Summit, I didn't attend a single talk at the
conference nor spend time in any other part of the conference except for
these two rooms (which were beside each other). I have been told anecdotally,
however, that the attendance numbers we saw for the OE Summit were in-line
with the numbers of attendees for several of the other talks, but I can't
comment personally.

As we were still setting up for my OE talk, the very first talk of the OE
Summit, one of the audience members put up his hand and asked what the
difference is between "Yocto" and "OE". We weren't specifically prepared to
comment off-the-cuff about the relationship between the two projects; it's not
as if we had a prepared statement to read on the topic. We tried to fumble
through a satisfactory answer while remaining as neutral as possible on the
topic. But it sure would be great if the two projects could get together and
put out an official statement on the matter to which we could point all such
curious people. Interestingly enough, this person was sure that The Yocto
Project pre-dated OE, which we had to correct. Then he assumed these were
two projects that had simply forked from each other at some point in the
past. It was probably actually more confusing to him that OE and YP are
two separate projects, but with almost all the same developers, working on
almost all the same code. In any case, The Yocto Project's Community Manager
was on-hand, thankfully, and I don't think he had any objections to any of
the things we said in answering this question.

My talk was a general introduction talk about OE, but all the other talks
assumed the audience knew something about OE. This turned out to not be the
case. Pretty much all the speakers had to field questions along the lines of
"so what is OE anyway?". Sadly, in many cases, saying "it's like Buildroot" is
often what would help the person asking the question the most. I think it's
noteworthy that more people seem to know what Buildroot is, but not OE/YP.
Although I realize this is just one conference, and a very small sample set,
so it wouldn't be fair to generalize from these numbers. But it is true that
these are the sorts of questions we were frequently asked, so it's noteworthy
in that respect.

Oddly enough, when I was finished the slides portion of the Buildroot class,
the very first statement a student made was to complain about how terribly
difficult Yocto is to learn and use. Why this came up in a class about
Buildroot is confusing to me too, maybe he looked me up online and found my
affiliation with OE? I don't know. I was careful to not mention the words "OE"
or "Yocto" at all in my Buildroot talk. In any case, in his opinion, using
Yocto requires a masters degree. Obviously he's exaggerating for effect.

I'd like to personally thank the speakers who agreed to give a talk at a
conference that didn't exist prior to last weekend, who worked hard on their
talks, and who put together some very interesting presentations. I think we
all walked away having learned a bit more about OE. I'd like to thank Behan
and Tom King who helped organize. Behan who setup his recording equipment to
record the talks (just in case there's an issue with 

Re: [yocto] OE Summit report from SCaLE17x

[Trevor Woerner]

On Fri, Mar 15, 2019 at 10:27 AM Trevor Woerner  wrote:

> I'd like to thank the OE Board of Directors who
> gave me permission to create and run a mini-conference on their behalf.
>

... and provided funding!! (without which this event would never have been
able to happen) So thanks to the Board for the funding, and to everyone who
has contributed financially to OE who provide this funding.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA

[Trevor Woerner]

On Thu, Jan 31, 2019 at 5:40 AM Andrea Galbusera  wrote:

> On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner  wrote:
> > The schedule for the OE Summit has been posted:
> > https://www.socallinuxexpo.org/scale/17x/schedule/sunday
> > https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0
>
> To whoever can double check and fix the schedule... it looks like
> there's a typo at the second link, where Alistair's talk is listed
> twice. From the first link "Lokesh Kumar Goel
> OpenEmbedded in LG Products" should be at 11.30am instead.
>

Thanks.

There are a bunch of other snafus with the webpages (i.e. the title of
Alistair's talk is actually "RISC-V and OpenEmbedded", and some of the
links to the speakers' bios doesn't seem to work properly). I had notified
the organizers even before I sent out this email, but didn't want to wait
even longer to let everyone know about this event. Hopefully the organizers
can get around to fixing them soon-ish.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA

[Trevor Woerner]

We're excited to announce the inaugural "OpenEmbedded Summit" taking place
Sunday March 10th 2019 as part of the Southern California Linux Expo
(SCaLE) 17x at the Pasadena Convention Center.

For the past few years there's been an ever-growing OpenEmbedded event as
part of SCaLE. This year, with the missing Spring ELC, we felt it was time
to do something more "formally" so OE enthusiasts could get together
without having to wait until August.

The initial suggestion for this summit came at last year's OEDEM in
Edinburgh. At that time an idea was also floated to hold this year's OEDAM
at the same time. Just to be absolutely clear: this suggestion was
rejected; there will be no OEDAM at the OE Summit at SCaLE 17x. However,
this summit is taking place with the full approval of the OpenEmbedded
Board of Directors, many of whom have also been helping out with its
organization.

The schedule for the OE Summit has been posted:
https://www.socallinuxexpo.org/scale/17x/schedule/sunday
https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0

So if you're in the Southern California area, or are generally interested
in hanging out with some OpenEmbedded people, please join us in Pasadena on
March 10th!

Your OE Summit organizing committee:
  Tom King
  Behan Webster
  Trevor Woerner
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Dropping armv5 and armv5e tunes in 2.7

[Trevor Woerner]

Hello Khem,

Thanks for pointing this out.

On Thu, Jan 3, 2019 at 5:02 PM Khem Raj  wrote:

> Secondly, I would also like to drop armv4t, and keep armv5te as lowest
> supported tune
>

Fortunately I don't have any ARMv4 boards.

But, just for informational purposes, I wanted to point out that I do have
a couple ARM926EJ-S boards (i.MX233, LPC32xx) which are ARMv5TE which I am
actively working with and maintaining. Therefore, thank you for keeping
this one around.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] OEDAM @ SCaLE 2019

[Trevor Woerner]

Hi Jon,

On Thu, Nov 1, 2018 at 3:56 PM Jon Mason  wrote:

> I am planning on being at SCaLE (assuming the OEDEM happens there).
>
> Many corporate travel budgets are tied to presenting at conferences.
> So, if we could somehow get a track there (which might be too late in
> the game to do now), then we might be able to get enough people
> present to make it happen and pull in others whose budget is more
> flexible.
>

As it turns out, I'll be organising the YP/OE Miniconf that will most
likely be run on the Sunday. I was going to send out a separate email
discussing the Miniconf, but I guess now is as good a time as any :-)

While it's true that the CFP has closed for SCaLE, I plan to open my own
CFP specifically for the Miniconf, and I don't plan to close it until
closer to the conference itself. I want to encourage people to give talks
about current things, as such, having a CFP close this early wouldn't do.

We haven't decided on a format for the Miniconf, exactly, if we have
traditional talks, we'll have 6 sessions (2 before lunch, 4 after). But
depending on interest and what sort of proposals we get, we might do some
longer, some shorter talks.

 I hope this helps. Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] OEDAM @ SCaLE 2019

[Trevor Woerner]

On Thu, Nov 1, 2018 at 3:32 PM akuster808  wrote:

> Trevor,
>
>
> On 11/1/18 7:04 AM, Trevor Woerner wrote:
> > Please see time indices: 12:13 and 16:45
> >
> https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk
>
> Could you please give us a day's notice the next time so we can properly
> set the perms for our minutes.
>
>
Will do, sorry!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OEDAM @ SCaLE 2019

[Trevor Woerner]

Hello Fellow YP/OE Enthusiasts!

There were discussions at our recent OEDEM regarding:
- our next developers meeting
- SCaLE 2019
- expanding/adding to the YP/OE presence at conferences (i.e. our own
  miniconf?)

Please see time indices: 12:13 and 16:45
https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk

Unfortunately, although lots of opinions were expressed, nothing concrete was
decided. Many people pointed out that their travel budgets are already
strained or maxed out, so adding another conference would be difficult if not
impossible. It's unclear how many "core" YP/OE people might show up at next
year's SCaLE. Also, given that this year's ELC scheduling hiccup is a one-off,
maybe it doesn't make as much sense to put in all the work required to run an
OEDAM at SCaLE if it's only ever going to happen once. Therefore I think I can
safely say the organizing committee for YP/OE Things at SCaLE 2019 is leaning
towards not running an OEDAM.

It's not too late to change our plans. If a large number of core people reply
to this email saying they want and OEDAM in March and will be available in
Pasadena, then we could accommodate it. It's just that we didn't leave
Edinburgh with the feeling that an OEDAM at SCaLE was feasible. Also, at this
point SCaLE isn't on the radars of many of the core YP/OE people, and
currently the conference tends to attract users rather than developers (or so
is my impression).

Thoughts?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Using a pre-build kernel

[Trevor Woerner]

Maybe bin_package.bbclass can help?
http://cgit.openembedded.org/openembedded-core/tree/meta/classes/bin_package.bbclass
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [meta-rockchip] conf: machine: Add support for vyasa-rk3288

[Trevor Woerner]

Hello Shyam,

Thank you for your contribution!

I just have 3 small nits with your patch, which I am happy to fix myself
without you needing to send a v2 (if that's okay with you):

1. I see that there's a mistake in meta-rockchip's README file which I will
   fix, the email subject should be prefixed with "[meta-rockchip][PATCH]".
   Sorry! I will fix this in the README.

On Wed 2018-09-12 @ 07:40:04 PM, Shyam Saini wrote:
> This patch adds initial support for the Amarula Vyasa Board.

2. I'm going to remove the following second sentence from the commit message.
   In 2 years, reading the commit logs regarding future promises/TODOs will
   seem funny. The sentence above fully explains this patch.

> With this patch, we would have working images for vyasa,
> single gpt and wic image support would be added later on.


> 
> Signed-off-by: Shyam Saini 
> ---
>  conf/machine/vyasa-rk3288.conf | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 conf/machine/vyasa-rk3288.conf
> 
> diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
> new file mode 100644
> index ..9c634325451e
> --- /dev/null
> +++ b/conf/machine/vyasa-rk3288.conf
> @@ -0,0 +1,14 @@
> +# Copyright (C) 2018 Amarula Solutions
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: Amarula Vyasa RK3288
> +#@DESCRIPTION: Amarula Vyasa is Rockchip RK3288 SOC based Single board 
> computer with fully supported opensource software.
> +
> +require conf/machine/include/rk3288.inc
> +
> +KERNEL_IMAGETYPE = "uImage"
> +KERNEL_DEVICETREE = "rk3288-vyasa.dtb"

3. I'm going to add a space after += for consistency.

> +KERNEL_EXTRA_ARGS +="LOADADDR=0x0200"
> +
> +UBOOT_MACHINE = "vyasa-rk3288_defconfig"
> -- 
> 2.11.0
> 

Once again, thank you for your contribution!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] TPM2-TSS-1.1.0.bb does not use local files when BB_NO_NETWORK = "1"

[Trevor Woerner]

which layer?

meta-secure-core includes a fix for this, but in master
https://github.com/jiazhang0/meta-secure-core/pull/63

there's also:
https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_do_an_offline_build_with_recipes_that_have_SRCREV_.3D_.22.24.7BAUTOREV.7D.22_set.3F

On Tue, Aug 14, 2018 at 9:37 AM, Mark T  wrote:

> Hi,
>
> We have an issue doing an off-line build for TPM2-TSS-1.1.0.bb and
> related packages.
>
> Its fine when BB_NO_NETWORK is not set, build/downloads has the package
> files and the .done. We then hold the .done and associated package files
> locally and place them into downloads prior to building with BB_NO_NETWORK
> = "1" - but the fetch fails as it will not accept the local files.
>
> Any ideas on how to resolve this ?
>
> We're using Morty. All other packages we use work fine with the local
> files.
>
> Cheers,
> Mark
>
>
>
> --
> ___
> 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] - X11 EGLSV2 Chromium

[Trevor Woerner]

Hi Karim,

Can you please also include the "Build Configuration" block that's printed
at the start of the build? That way we know what layers you're using, and
which branches/commits of those layers.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto dev day 2018 eurpoe

[Trevor Woerner]

Has a date/location been set?

(Is it too presumptuous of me to assume there will be a Yocto Dev Day in
Scotland this year?)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Waveshare touchscreen

[Trevor Woerner]

On Tue, Jul 3, 2018 at 4:40 AM, Michele Tirinzoni 
wrote:

> Anyway, the config.txt is just enough to be able to use the screen with
> touch functionality ? No need to have any driver installed ?
>

These panels have two cables that must be connected to the board: HDMI and
USB.

The HDMI handles all the video. The USB handles power and all the touch
stuff; touch "just works" magically.

In my builds I tend to add:

RDEPENDS_packagegroup-core-x11-utils_remove_pn-packagegroup-core-x11 =
"xinput-calibrator"
PACKAGECONFIG_pn-xserver-nodm-init = "nocursor"

The first line removes the package that keeps popping up the touch
calibrator software on boot. The second line removes the pointer (which
isn't relevant if you're using touch). Both of these assume you're using
x11, I have no idea how to setup wayland similarly.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Waveshare touchscreen

[Trevor Woerner]

On Wed, Jun 27, 2018 at 7:38 AM, Michele Tirinzoni 
wrote:
>
> I saw in the documentation page that the Waveshare touchscreen is
> supported.
> Before buying one of those I'd like to know if anyone tried it recently
> with a rpi zero w or if there's any known issue.
>

I added the support for the waveshare screen and use it regularly with a
Raspberry Pi 3 (B and B+) 32-bit. My _latest_ build and test from master
for RPi3B+-32 was just last week. Check the commit message for the specific
one I'm using:

https://github.com/agherzan/meta-raspberrypi/commit/da32aac453da278e254d37b816602410af85d162#diff-a8b738ce971c646d8c30f0d75c6c45b9

I haven't tried it with the Zero, in fact, I haven't tried a Zero at all.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

[Trevor Woerner]

Hi Iván,

On Thu 2018-06-07 @ 04:39:11 PM, Iván Castell wrote:
> When setting the "build" directory with a bblayers.conf customized for a
> single platform, each platform builds the image recipe properly.
> 
> However, when I have integrated all bsp-layers in a single bblayers.conf,
> the compilation of some platforms has been broken.

This is a problem that comes up fairly often, and is a bug with the BSP layer
itself. All BSP layers are supposed to be created so that they work well when
intermixed with other BSP layers, but often they don't. See Angstrom:

http://www.angstrom-distribution.org/

> The specific problem is this: one bsp layer (meta-rockchip +
> meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with
> this content inside:

I am the maintainer of the non-vendor meta-rockchip layer:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/

The fact you mention this problem and meta-rockchip-extra implies to me that
you're using the vendor-provided meta-rockchip and meta-rockchip-extra:

https://github.com/rockchip-linux/meta-rockchip
https://github.com/rockchip-linux/meta-rockchip-extra

The problem is, the vendor is only interested in their own hardware, so to
them there's no reason to ever mix their BSP layer with any other BSP layer.
There's no interest on their part to "play well" with others or to check
whether their layers comply with community guidelines.

As a person who likes OpenEmbedded as a whole, I try my best to make sure any
layer I'm interested in plays well within the entire OpenEmbedded ecosystem.
However, because mali graphics are currently all binary blobs and projects
like Lima and Panfrost aren't yet ready for prime-time, there isn't much
support yet for _accelerated_ graphics in the non-vendor layer.

> - Can you suggest a fix to solve this issue?

Fix the problem in the layer by using MACHINE-specific OVERRIDES and submit
a pull request to the owners. However, I've noticed there haven't been any
updates to their OE layers in the past 4 months or more, so I can't help
wonder if they've abandoned them.

Out of curiosity, which MACHINE(s) are you interested in?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Call to Action] Yocto Project Bug Triage

[Trevor Woerner]

On Tue, May 29, 2018 at 12:25 PM, Osier-mixon, Jeffrey <
jeffrey.osier-mi...@intel.com> wrote:

> Here are links for shared google calendars for
>
>
>
> Public meetings: https://calendar.google.com/calendar/b/2?cid=
> dGhleW9jdG9wcm9qZWN0QGdtYWlsLmNvbQ
>
>
>
> Release schedule: https://calendar.google.com/calendar/b/2?cid=
> M2EwOTI3Y3RwczUxdThyczJqdjF1bGlnZGNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>
>
>
> I’ll add these links to the web page. Please let me know if you have any
> trouble with them.
>

Works fine for me.
Thanks!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Call to Action] Yocto Project Bug Triage

[Trevor Woerner]

On Tue, May 29, 2018 at 11:52 AM, Michael Halstead <
mhalst...@linuxfoundation.org> wrote:

> The meeting page is https://www.yoctoproject.org/public-virtual-meetings/
> for anyone interested.
>

Would it be possible to get event planners interested in
https://www.timeanddate.com/worldclock/fixedform.html ?

It makes is so easy for participants to determine when the event will occur
in their own timezone.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] interacting with patchwork / unmerged development work

[Trevor Woerner]

Hello,

One of the minor inconveniences with submitting patches to this project, is to
work on a patch against master (for example), submit it, then find that
yesterday someone submitted a patch against the same file you're editing
causing your patch to not apply with what the maintainer is going to test.

Do people have tricks or workflows for syncing their repositories with, say,
master PLUS any patches which have been sent to the list since the last time
(in this case) master was updated?

OR: is there an easy way to retrieve what is going to be tested in the next
test cycle?

OR: would it be possible to tweak patchwork such that all received patches
could be automatically applied to a given branch? Developers could then work
off that branch and have a better chance of being in-sync? Maintainers could
then prune that branch, removing any patches that have been rejected or need
more work.

I dug around and found two command-line utilities for interacting with
patchwork:
- pwclient
- git-pw

I can't seem to get either to work.

Using the following ~/.pwclientrc (which is obtained from the OE patchwork
server itself: https://patchwork.openembedded.org/project/oe/ and
https://patchwork.openembedded.org/project/oe/pwclientrc/)

[options]
default=oe

[oe]
url= https://patchwork.openembedded.org/xmlrpc/

I get a timeout error:

$ pwclient list
Traceback (most recent call last):
  File "/home/trevor/local/bin/pwclient", line 10, in 
sys.exit(main())
  File 
"/home/trevor/local/lib/python2.7/site-packages/pwclient/shell.py", line 190, 
in main
action_list(rpc, filt, submitter_str, delegate_str, format_str)
  File 
"/home/trevor/local/lib/python2.7/site-packages/pwclient/patches.py", line 114, 
in action_list
patches = rpc.patch_list(filter.d)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request
return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1331, in single_request
response.msg,
xmlrpclib.ProtocolError: 

For git-pw, it always seems to want a username/password, regardless of the
operation, even though listing or retrieving patches shouldn't need a login:

$ git config pw.server https://patchwork.openembedded.org
$ git config pw.project oe
$ git pw patch list
Authentication information missing
You must configure authentication via git-config or via --token or 
--username, --password

In any case, even if one of these were working, I'd still need to be able to
generate a list of patch IDs since the last test. I have no idea how I'd go
about doing that since I don't think the last accepted patch ID is known.
Also, a list of currently-accepted patches isn't given anywhere either (that
I'm aware).

Any thoughts?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Call to Action] Yocto Project Bug Triage

[Trevor Woerner]

Is someone working on putting together a (google?) calendar of the various
project (OE Yocto) meetings?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Minites: Yocto Project Bug Triage

[Trevor Woerner]

On Thu, May 24, 2018 at 11:01 AM, Jolley, Stephen K <
stephen.k.jol...@intel.com> wrote:

> AR: Stephen – Mention IRC channel and links on IRC and meeting invite.
>

Also: create calendar of Yocto meetings (google calendar?)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Canceled: Yocto Project Technical Team Meeting

[Trevor Woerner]

Did the updated invite go out? I don't think I've seen it.
Is the meeting scheduled for May 15th?

On Thu, May 10, 2018 at 1:41 PM, Cetola, Stephano  wrote:

> Stephen will be sending an updated Technical Meeting invite shortly.
>
>
> Cheers,
> Stephano
>
> --
> ___
> 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] Help with Bitbake: (bitbake-layers show-recipes)

[Trevor Woerner]

*$ git clone git://git.linaro.org/openembedded/jenkins-setup.git
*

Since the repository from which you're working comes from Linaro, maybe
you'll have better luck getting support from their mailing list?
openembedded-c...@lists.openembedded.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Trevor Woerner]

On Wed, May 2, 2018 at 5:19 PM, Paul Eggleton  wrote:

> 1) If you want the cppzmq development files to be available *within* the
> eSDK
> (so you can write code to use them using the eSDK), even if they are not
> brought in by way of the image containing a package from the cppzmq
> recipe,
> you can install them into the eSDK by running this within the eSDK
> environment:
>
> devtool sdk-install -s cppzmq
>

Is sdk-install new? It doesn't show up when I run "devtool help"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] typo in tzdata_2018c.bb

[Trevor Woerner]

Hi Kévin,

On Wed 2018-04-25 @ 10:46:28 AM, Kévin Carli wrote:
> Hi,
> 
> I would like to signal a typo in the
> meta/recipes-extended/tzdata/tzdata/tzdata_2018c.bb
> (https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/
> tzdata/tzdata_2018c.bb?h=morty) file.
>
> At this line: "${datadir}/zoneinfo/Asia/Bankok  \"
> 
> I think that Bankok should be written Bangkok instead.

Yes, that appears to be true. Also this error persists in master as well. The
best thing to do would be to prepare and submit a patch for this fix against
master. Guidelines for submitting a patch are here:

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

Since this recipe is in openembedded-core, this patch will need to be sent to:

openembedded-c...@lists.openembedded.org

At this point, it looks like morty is still under maintenance:

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

Ideally this patch would be applied to all branches from morty onward.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 05/25] FogBugz #532583-1: hwmon: Update A10SR HWMON register calls

[Trevor Woerner]

On Thu, Apr 5, 2018 at 11:09 AM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 04/04/2018 07:48 AM, Trevor Woerner wrote:
>
>> What's a FogBugz?
>>
>
> The bug tracker for the upstream repo that was used for the
> patches. While not useful for us (and I hate it when tracking
> info is put into git commits), since it is in the patch itself
> .. I have to live with it :(
>

Okay, thanks for the clarification. I remember a while back there was some
brouhaha raised about foreign bug tracking info. Just wanted to make sure.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 05/25] FogBugz #532583-1: hwmon: Update A10SR HWMON register calls

[Trevor Woerner]

What's a FogBugz?

On Tue, Apr 3, 2018 at 10:37 PM,  wrote:

> From: Thor Thayer 
>
> commit  c3d8a24d4cae45f0240e82f007de2286bb4e8071 from
> https://github.com/altera-opensource/linux-socfpga.git
>
> The A10 System Resource HWMON needs to be updated to fit the
> newer hwmon register calls. Update the copyright and date
> as part of this update.
>
> Signed-off-by: Thor Thayer 
> Signed-off-by: Meng Li 
> ---
>  drivers/hwmon/altera-a10sr-hwmon.c |   53 ++
> --
>  1 file changed, 8 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/hwmon/altera-a10sr-hwmon.c
> b/drivers/hwmon/altera-a10sr-hwmon.c
> index 6fb5e7f..dac39a7 100644
> --- a/drivers/hwmon/altera-a10sr-hwmon.c
> +++ b/drivers/hwmon/altera-a10sr-hwmon.c
> @@ -1,4 +1,5 @@
>  /*
> + *  Copyright Intel Corporation (C) 2017-2018. All Rights Reserved
>   *  Copyright Altera Corporation (C) 2014-2016. All Rights Reserved
>   *
>   * This program is free software; you can redistribute it and/or modify it
> @@ -97,7 +98,6 @@
>   * @regmap: the regmap from the parent device.
>   */
>  struct altr_a10sr_hwmon {
> -   struct device   *class_device;
> struct regmap   *regmap;
>  };
>
> @@ -129,13 +129,6 @@ static ssize_t altr_a10sr_read_status(struct device
> *dev,
> return sprintf(buf, "%d\n", val);
>  }
>
> -static ssize_t altr_a10sr_hwmon_show_name(struct device *dev,
> - struct device_attribute *devattr,
> - char *buf)
> -{
> -   return sprintf(buf, "altr_a10sr\n");
> -}
> -
>  static ssize_t set_enable(struct device *dev,
>   struct device_attribute *dev_attr,
>   const char *buf, size_t count)
> @@ -305,10 +298,7 @@ static SENSOR_DEVICE_ATTR(max5_pmbus, S_IRUGO |
> S_IWUSR,
>   altr_a10sr_read_status, set_enable,
>   ALTR_A10SR_PMBUS);
>
> -static DEVICE_ATTR(name, S_IRUGO, altr_a10sr_hwmon_show_name, NULL);
> -
> -static struct attribute *altr_a10sr_attr[] = {
> -   _attr_name.attr,
> +static struct attribute *altr_a10sr_attrs[] = {
> /* First Power Good Register */
> _dev_attr_opflag_alarm.dev_attr.attr,
> _dev_attr_1v8_alarm.dev_attr.attr,
> @@ -375,14 +365,12 @@ static SENSOR_DEVICE_ATTR(max5_pmbus, S_IRUGO |
> S_IWUSR,
> NULL
>  };
>
> -static const struct attribute_group altr_a10sr_attr_group = {
> -   .attrs = altr_a10sr_attr
> -};
> +ATTRIBUTE_GROUPS(altr_a10sr);
>
>  static int altr_a10sr_hwmon_probe(struct platform_device *pdev)
>  {
> struct altr_a10sr_hwmon *hwmon;
> -   int ret;
> +   struct device *hwmon_dev;
> struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
>
> hwmon = devm_kzalloc(>dev, sizeof(*hwmon), GFP_KERNEL);
> @@ -391,34 +379,10 @@ static int altr_a10sr_hwmon_probe(struct
> platform_device *pdev)
>
> hwmon->regmap = a10sr->regmap;
>
> -   platform_set_drvdata(pdev, hwmon);
> -
> -   ret = sysfs_create_group(>dev.kobj, _a10sr_attr_group);
> -   if (ret)
> -   goto err_mem;
> -
> -   hwmon->class_device = hwmon_device_register(>dev);
> -   if (IS_ERR(hwmon->class_device)) {
> -   ret = PTR_ERR(hwmon->class_device);
> -   goto err_sysfs;
> -   }
> -
> -   return 0;
> -
> -err_sysfs:
> -   sysfs_remove_group(>dev.kobj, _a10sr_attr_group);
> -err_mem:
> -   return ret;
> -}
> -
> -static int altr_a10sr_hwmon_remove(struct platform_device *pdev)
> -{
> -   struct altr_a10sr_hwmon *hwmon = platform_get_drvdata(pdev);
> -
> -   hwmon_device_unregister(hwmon->class_device);
> -   sysfs_remove_group(>dev.kobj, _a10sr_attr_group);
> -
> -   return 0;
> +   hwmon_dev = devm_hwmon_device_register_with_groups(>dev,
> +  "a10sr_hwmon",
> hwmon,
> +
> altr_a10sr_groups);
> +   return PTR_ERR_OR_ZERO(hwmon_dev);
>  }
>
>  static const struct of_device_id altr_a10sr_hwmon_of_match[] = {
> @@ -429,7 +393,6 @@ static int altr_a10sr_hwmon_remove(struct
> platform_device *pdev)
>
>  static struct platform_driver altr_a10sr_hwmon_driver = {
> .probe = altr_a10sr_hwmon_probe,
> -   .remove = altr_a10sr_hwmon_remove,
> .driver = {
> .name = "altr_a10sr_hwmon",
> .of_match_table = of_match_ptr(altr_a10sr_hwmon_of_match),
> --
> 1.7.9.5
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Trevor Woerner]

On Mon 2018-04-02 @ 11:46:39 PM, Andreas Müller wrote:
> On Mon, Apr 2, 2018 at 11:12 PM, Trevor Woerner <twoer...@gmail.com> wrote:
> > I'm re-building my rpi3-64 image to see if things are better there too under
> > vc4.
> You'll let me know I guess...

Everything's working :-) This is the first time I've seen graphics (x11)
working with rpi3-64.

mesa-demos, directfb-examples, chromium (accelerated!), qt5...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Trevor Woerner]

On Mon 2018-04-02 @ 11:46:39 PM, Andreas Müller wrote:
> > to my conf/local.conf has glmark2-es2 running, and chromium-x11 is running
> > accelerated out-of-the-box (i.e. I don't have to install the egl/gles
> > libraries it builds itself).
> Cool - have not seen it running without issues for very long time...

Yes, this is a very nice side effect of your digging into this apparently
un-related issue! :-)

In my own layers I had a .bbappend that was copying the chromium-built
egl/gles libraries to the target, but it doesn't look like this is needed
anymore. I posted complete information here (as part of an issue you had
originally opened):

https://github.com/OSSystems/meta-browser/pull/82#issuecomment-353528110

> >
> > I'm re-building my rpi3-64 image to see if things are better there too under
> > vc4.
> You'll let me know I guess...

Absolutely! But, you know chromium... I'll need an hour or two... ;-)
(my image has chromium, glmark2, mesa-demos, directfb, directfb-examples, Qt,
and a bunch of Qt demos. sadly, the directfb examples always work, it's
everything else that's a coin-toss!! haha)

> > I guess the patch is to address some of the other things you were seeing?
> No - after enabling dri3 all I tested so far was perfectly fine. But
> maybe other graphic drivers are affected.

Now I'm confused: is the patch needed?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Trevor Woerner]

Even without the patch, simply adding:

PACKAGECONFIG_append_pn-mesa = "dri3"

to my conf/local.conf has glmark2-es2 running, and chromium-x11 is running
accelerated out-of-the-box (i.e. I don't have to install the egl/gles
libraries it builds itself).

I'm re-building my rpi3-64 image to see if things are better there too under
vc4.

I guess the patch is to address some of the other things you were seeing?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Has anybody run VC4 + X + recent meta/masters lately

[Trevor Woerner]

On Thu 2018-03-29 @ 11:34:08 PM, Andreas Müller wrote:
> On Thu, Mar 29, 2018 at 11:23 PM, Andreas Müller
> <schnitzelt...@gmail.com> wrote:
> > On Thu, Mar 29, 2018 at 11:05 PM, Trevor Woerner <twoer...@gmail.com> wrote:
> >> I've seen the 'Modifier 0x0 vs. tiling(0x7001) mismatch' error
> >> and blank screen hundreds of times while working on getting chromium-x11
> >> accelerated. It would happen if chromium was trying to use the system
> >> gl/gles libraries instead of the ones it builds.
> > Then you should give that patch a try - change is in mesa-megadriver
> > package (building images after mesa changes takes LONG...)

The solution was to let the two gl libraries install without interfering with
each other (i.e. to separate locations). If I didn't install the ones chromium
built, it would try to use the system ones and fail. If I installed both and
it found its own, it would succeed. So I found a solution and didn't need to
dig into this 'modifier vs tiling' issue.

Having said that, I'm curious to try your patch on rpi3-64. I have never been
able to get vc4 working on x11 with a 64-bit build (it also gives a 'modifier
vs tiling' error).

> > Some appetizer: glmark on mesa 17.1.7 reports 110 / glmark on mesa
> > 17.1.7 reports 145!

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

Re: [yocto] [meta-raspberrypi] Has anybody run VC4 + X + recent meta/masters lately

[Trevor Woerner]

I've seen the 'Modifier 0x0 vs. tiling(0x7001) mismatch' error
and blank screen hundreds of times while working on getting chromium-x11
accelerated. It would happen if chromium was trying to use the system
gl/gles libraries instead of the ones it builds.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Has anybody run VC4 + X + recent meta/masters lately

[Trevor Woerner]

64bit RPi or 32?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documentation error report

[Trevor Woerner]

Hi Daryl,


On Sat 2018-03-10 @ 07:10:02 PM, da...@daryllee.com wrote:
> I'm not sure who to send this to, so maybe someone can redirect me...

Scott Rifenbark is responsible for all YP documentation:
srifenbark AT gmail DOT com

Ideally, if you're comfortable with git, you could generate a patch and send
it via email to this list (CCing Scott). You can find the YP sources here:

http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs

> I'm going through the Yocto Project Quick Start at 
> https://www.yoctoproject.org/docs/2.4.1/yocto-project-qs/yocto-project-qs.html,
> and I encountered a minor error that might be worth fixing.  There are two
> consecutive commands given for cloning Poky and checking out the current
> version:
> 
> $ git clone git://git.yoctoproject.org/poky
> $ git checkout tags/yocto-2.4.1 -b poky_2.4.1
> 
> For myself, I had to insert a
> 
> $ cd poky
> 
> between them to succeed.

Specifically I think you're referring to:


http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/yocto-project-qs/qs.xml#n330


I think the "-b " option (which also takes tags) could be used to
combine the above into one step, thus obviating the need for the "cd ..." or
the "checkout ..."

$ git clone -b yocto-2.4.1 git://git.yoctoproject.org/poky

But maybe it's simpler as multiple steps?

> And, as always, my sincere thanks to everyone who has ever contributed to
> this endeavor; it's a big help to me.  I've been using it for several months
> now via Xilinx's Petalinux wrapper and now I'm trying to get "under the
> covers" to understand better what kind of magic is going on.

Welcome, and good luck!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Here is my BSP for the adzs-sc589-ezlite eval board.

[Trevor Woerner]

On Thu, Feb 8, 2018 at 8:43 AM, Peter Spierenburg <
peter.spierenb...@nautel.com> wrote:

> I've created a board support package for the adzs-sc589-ezlite evaluation
> board from Analog Devices.
>

Would you consider adding it to the layer index?
http://layers.openembedded.org/layerindex/submit/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto uses UTC time for DATETIME instead of localtime

[Trevor Woerner]

On Sun, Feb 11, 2018 at 7:30 PM, Davis Roman 
wrote:

> I'm using the DATETIME variable to generate timestamps for my final images
> however I see that yocto is using UTC time.
>
> I'd much prefer if yocto used localtime.
>
> Any suggestions on how to change this?
>
>
You asked this same question almost exactly a month ago, and it was
answered then. Was there something wrong with that answer?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Eclipse plugin plans

[Trevor Woerner]

Just to clarify... will non-IDE non-Linux development be explicitly
supported?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] linux kernel rt

[Trevor Woerner]

On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll <
martin.hundeb...@prevas.dk> wrote:

>
>
> On 2018-01-26 04:51, Khem Raj wrote:
>
>>
>> Secondly, I wonder how good is upstream mainline kernel for rpi now a
>> days, we could always have a mainline recipe as an option and use it as
>> base for things like rt.
>>
>
> Apart from runtime device tree overlay support for RPi hats/extension
> boards, mainline linux fully supports each RPi revision.
>
> I guess linux-yocto-rt would be just fine...
>
>
Does anyone know if the FIQ bug has been fixed upstream? The last time I
looked into PREEMPT_RT on the RPi, the only way to make it work/stable was
to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch
was outside both the kernel and the PREEMPT_RT patch.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Trevor Woerner]

On Mon 2018-01-22 @ 10:12:27 AM, Andrea Galbusera wrote:
> I'll try to follow up with a patch to meta-raspberrypi and
> possibly upstream to userland. In the end, I don't think libepoxy is
> the right place to explicitly put the change. What's your opinion
> here?

If I write C code, and in one of my C source files I use the function
XOpenDisplay(), then I'm of the opinion that (to be correct) this source file
should also #include  directly, and not depend on X11/Xlib.h being
included as a by-product of some other #include somewhere randomly up the
chain.

On the other hand, if I call function xyz() (and therefore #include )
and xyz() calls XOpenDisplay(), then I would expect xyz.h to #include
 and not expect me to track down the header file for
XOpenDisplay() myself.

In my opinion the libepoxy code would be the right place to correct the
missing header file if it is calling XOpenDisplay() directly.

> Once more, looking at Khronos registry [3], which I learned being the
> right upstream reference for such an header, expected X11 includes are
> there, while, as said, they are missing in userland eglplatform.h.
> Unfortunately userland community does not seem to be very keen to
> update their includes even though Khronos published more up to date
> versions.
> 
> [3] https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

If you follow that link, the Xlib #includes in that very file are marked
"tentative"! Therefore I think the userland people can be excused from not
jumping on a request to add them.

Besides, let's say we don't add the #include to libepoxy and get the userland
people to add it in their header, then, 6 months later, Khronos votes on this
"tentative" issue and decides not to include them. userland would then remove
them from its headers, and we'd be right back where we are now: with C code
that uses a function but doesn't also include its relevant header directly.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Trevor Woerner]

On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff  wrote:

> I can confirm adding #include  to test/egl_common.c gets past
> the original error, but then fails with:
>
>
thank you for checking :-)


>
>
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | [1/2] Compiling c object 'test/glx_beginend@exe/glx_beginend.c.o'
> | [2/2] Linking target test/glx_beginend
> | FAILED: test/glx_beginend
> | arm-poky-linux-gnueabi-gcc  -o test/glx_beginend 'test/glx_beginend@exe
> /glx_beginend.c.o' '-Wl,--no-undefined' '-Wl,--as-needed' '-O2' '-pipe'
> '-g' '-feliminate-unused-debug-types' '-fdebug-prefix-map=/home/
> michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-
> vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0'
> '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/
> tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/
> libepoxy/1.4.3-r0/recipe-sysroot-native=' '-fdebug-prefix-map=/home/
> michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-
> vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot=' '-Wl,-O1'
> '-Wl,--hash-style=gnu' '-Wl,--as-needed' 'test/libglx_common.a'
> 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0'
> '-ldl' '-lX11' '-ldl' '-Wl,-rpath,/home/michael/oe/
> recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-
> linux-gnueabi/libepoxy/1.4.3-r0/build/src' -march=armv7ve -marm
> -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/home/michael/oe/recipes/rpi-build/tmp/work/
> cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot
> -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
> | test/glx_beginend@exe/glx_beginend.c.o: In function
> `test_without_epoxy':
> | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:70:
> undefined reference to `glBegin'
> | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:85:
> undefined reference to `glEnd'
> | collect2: error: ld returned 1 exit status
> | ninja: build stopped: subcommand failed.
> | WARNING: /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-
> neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/run.do_compile.2610:1
> exit 1 from 'ninja -j 8'
> | ERROR: Function failed: do_compile (log file is located at
> /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-
> neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/log.do_compile.2610)
> ERROR: Task (/home/michael/oe/recipes/poky/meta/recipes-graphics/
> libepoxy/libepoxy_1.4.3.bb:do_compile) failed with exit code '1'
>
>
that suggests a missing #include 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Trevor Woerner]

On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Also CC-ing the patch author who might suggest further investigations.
>>
>>  libepoxy: convert to meson build
>>
>>
> There's probably a missing header include
>
>

The original error:


../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration
of function 'XOpenDisplay'; did you mean 'eglGetDisplay'?
[-Werror=implicit-function-declaration]
 Display *dpy = XOpenDisplay(NULL);

implies a missing #include 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] Fwd: How to make the os-release package work with local walltime instead of GMT?

[Trevor Woerner]

On Thu, Jan 11, 2018 at 12:26 AM, Robert Yang 
wrote:

> BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"
>

Brilliant! Why isn't this the default?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add kernel modules & dtbo's for Raspberry Pi3

[Trevor Woerner]

On Wed 2017-12-20 @ 11:40:50 PM, Greg Wilson-Lindberg wrote:
> I'm building an image for the Raspberry Pi 3 and I'm trying to add some
> modules to the kernel and I need to add some device tree overlays. The
> modules and overlays are part of the kernel, just not built by default.
> 
> For the kernel modules I've added a linux-raspberrypi_4.4.bbappend file in
> the path .../recipes-bsp/linux. The file consists of:
> 
> # Scribe additions to Kernel configuration
> 
> FILESEXTRAPATHS_prepend += "$(THISDIR)/files"
> SRC_URI += "file://Scribe.cfg"
> 
> Whether I use "+=" or ":=" as suggested in "Embedded Linux Systems withe
> the Yocto Project", I get an error that "file://0001-fix-dtbo-rules.patch"
> cannot be found. I don't get this error if my .bbappend file is not being
> used.

You're missing a colon at the end of the path definition, and you should use
the ':=' operator:

FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

The path you're introducing is getting added to a bunch of other paths, and
therefore needs the separator. The := operator causes your change to this
variable to be immediately expanded by bitbake, which is what you want.

> Also, if there are any quick tips on how to add dtbo's to the kernel build I
> would appreciate them.

If you look through the raspberry pi kernel sources

($TMPDIR/work/raspberrypi3-*/linux-raspberrypi/${VERSION}/linux-raspberrypi3-standard-build/source)
at
arch/arm/boot/dts/overlays

and find an overlay you like (e.g. spi1-3cs-overlay.dts) then to have it added
to your image and applied at boot time:

1. edit local.conf to add it to the kernel's device tree (but add it as a dtbo
without the "-overlay"):

KERNEL_DEVICETREE_append = " overlays/spi1-3cs.dtbo"

2. extend rpi-config to include it in the image's config.txt file:

rpi-config_%.bbappend:
do_deploy_append() {
echo "dtoverlay=spi1-3cs" 
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt"
}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip] The various rockchip layers

[Trevor Woerner]

On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak  wrote:
> As I started digging to check the current state of the different
> layers it was quite clear to me that there where two different sets.
> One is maintained by Rockchip [1] and the other one by the community
> [2].

Don't forget https://github.com/jackmitch/meta-tinker ;-)

> And it made sense to me initially. I do not know the full background
> story with the Rockchip layers (would be nice if someone could tell it
> :)) on what the intent was with "community" Rockchip layers.

Romain started meta-rockchip initially, then I joined, then people
from Rockchip joined later.

> But as I looked in to it further it was quite clear to me that the
> Rockchip maintained layers are more "up to date" then the community
> ones. And then I started thinking on why are not these merged and we
> could focus effort on maintaining one layer.

The main goal Romain and I have is to have a meta-rockchip that helps
users run upstream code on their rockchip devices. My guess is that
the main goal of the Rockchip meta-rockchip is to demonstrate the
performance of the rockchip SoC (usually via vendor kernels, vendor
bootloaders, binary blobs, etc.)

> There are a couple things that are interesting:
>
> - The Rockchip maintained layers state that they do accept
> contributions trough pull-requests on github. So nothing stopping us
> there?

They are quite friendly, but they have their goals.

> - The Rockchip maintained layers supports more "community" boards then
> the community layers does. Bit odd? :)

The rockchip people are paid to maintain meta-rockchip as part of
their day-jobs, Romain and I aren't. I buy my own boards, I haven't
received any hardware support, so my contributions tend to focus on
boards I actually have. I would rather have support for boards I can
actually test and therefore actually have rather than guessing whether
stuff will work. Not to mention I have to find time to work on this
after other "more important" things are done :-)

> - The community layers are a bit outdated on older Yocto branches,
> master branch seems active though.

Mostly a time issue. I build master with firefly-rk3288 every night
with all the latest master updates and try to fix any issues that come
up. I don't have the resources, unfortunately, to keep my finger on
various past releases.

> - Trevor and Romain (maintainers of the community layers) are listed
> as maintainers of the Rockchip layers? [4]

Initially the Rockchip people would send pull requests for the one
meta-rockchip layer. Many of those pull requests were to add recipes
pointing to vendor kernels/bootloaders and binary blobs. Also they
would send patches for boards that (at those times) weren't available
or sometimes weren't even announced! We pushed back on some of the
contributions, not just for philosophical reasons but sometimes for
technical reasons as well. They weren't happy with our slow response
times and push-back so they just forked and went on their own way.
When they forked they forgot to change some of the boilerplate stuff
that should have been changed (such as the maintainers). So yes,
Romain and I are listed as the maintainers of the Rockchip
meta-rockchip layer, but we're not :-)

It's on my TODO list to send them some patches for things like that :-)

> What I am really after is better understanding the workflow working
> with Rockchip SOC`s and Yocto and that is why I am raising questions
> to do so :).
>
> My plan was getting involved in one of the Rockchip layers as I have
> some improvements and I have some ideas for further improvements. And
> the goal with this email was to figure out where.

Every once in a while I try to carve out some time to try the Rockchip
meta-rockchip layer and see how things are going. Maybe it's just a
coincidence, but often they don't build for me. Looking through their
instructions they seem to want lots of control over a user's
setup/configuration (i.e. by using repo to pull specific versions of a
specific set of layers, then using their own setup tool). My goal is
to have a layer that works any way the user wants to work (e.g.
distroless with openembedded-core, or with poky, or with angstrom,
etc...). When I use their instructions I do have more success (but not
always), but I don't believe that's how BSP layers should work. I
don't think it's a good situation when a user must use a specific
distro, or specific layers at specific commit points, or a specific
setup tool in order to build for a MACHINE successfully.

I'm hoping that one day
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 will get
accepted. If/When that happens then it will be theoretically possible
to have both a set of upstream recipes and a set of vendor recipes
within the same BSP layer. Maybe at that point the two (three?) layers
can come together. Unfortunately there doesn't seem to be much
interest in BSP layers outside of the BSP community. I'll probably

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

[Trevor Woerner]

On Wed, Sep 27, 2017 at 3:22 PM, Otavio Salvador
 wrote:
>> This is very useful, can this concept be upstreamed to OE-Core?
>
> I think so; if people agree with this concept I can work in upstreaming it.
>
> There is also the machine-overrides-extender.bbclass[1] which allows
> for overrides to be added/removed based on other overrides.
>
> 1. 
> https://github.com/Freescale/meta-freescale/blob/master/classes/machine-overrides-extender.bbclass

I've been trying (begging) since the start of August to get the above
one added to OE-core
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bitbake memres usecase

[Trevor Woerner]

Hi,

I'm trying to understand if memres is right for me.

Every night my machine, via jenkins, grinds away doing about a dozen
builds. Each of these builds is for a separate MACHINE, in separate
directories, with separate layers, configurations, etc. My jenkins
instance has two executors (on the same machine). So if one build runs
long, two builds could be running at the same time.

Should I enable memres?

Also, sometimes I kick off a jenkins job or two during the day, while
at the same time doing manual builds somewhere else on the same
machine. Maybe all I want to do manually is to run "bitbake -e" and
investigate some packageconfig setting. Would having one
memres-bitbake running cause issues with multiple builds running at
the same time?

Is it possible to have one memres-bitbake running for the jenkins
jobs, but have my own bitbake running for my manual jobs?

Or maybe none of the above is the use-case for memres?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] u-boot-rockchip: update require path

[Trevor Woerner]

On Mon, Jul 24, 2017 at 4:46 AM, Jack Mitchell  wrote:
> I have a small layer I use for booting mainline components on the tinker, so
> i can confirm that works with current upstream.
>
> https://github.com/jackmitch/meta-tinker


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

Re: [yocto] [PATCH] u-boot-rockchip: update require path

[Trevor Woerner]

Hey Tom,

On Sat, Jul 22, 2017 at 7:45 PM, Tom Rini <tr...@konsulko.com> wrote:
> On Sat, Jul 22, 2017 at 06:40:32PM -0400, Trevor Woerner wrote:
>
>> The oe-core recipe was updated (2017.05 -> 2017.07), this recipe needed to
>> be updated to suit. However, this u-boot (from rockchip) is still at version
>> 2017.05.
>>
>> Signed-off-by: Trevor Woerner <twoer...@gmail.com>
>
> Not an objection, but, what's missing to move to just using upstream
> u-boot?

Excellent question! I was just thinking the same thing myself as I was
preparing this patch :-)

This patch is a maintenance patch that will allow builds to succeed,
but I admit it isn't ideal.

At this point I'm hoping
http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139974.html
goes in so I can make 2 sets of recipes: one for rockchip components
and one for upstream. At that point I'll evaluate all the upstream
things and all the rockchip things to make sure they work on the
boards I have. At that point I can clean all this up.

Hopefully I'll also be able to add the tinker board rk3288 and the firefly 3399.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] u-boot-rockchip: update require path

[Trevor Woerner]

The oe-core recipe was updated (2017.05 -> 2017.07), this recipe needed to
be updated to suit. However, this u-boot (from rockchip) is still at version
2017.05.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 recipes-bsp/u-boot/u-boot-rockchip_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb 
b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
index c0b1ff6..1f4a644 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip_git.bb
+++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
@@ -4,7 +4,7 @@
 # Released under the MIT license (see COPYING.MIT for the terms)
 
 require recipes-bsp/u-boot/u-boot.inc
-require recipes-bsp/u-boot/u-boot-common_2017.05.inc
+require recipes-bsp/u-boot/u-boot-common_2017.07.inc
 
 DESCRIPTION = "Rockchip next-dev U-Boot"
 COMPATIBLE_MACHINE = "(firefly-rk3288|rock2-square)"
-- 
2.13.0

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

[yocto] [meta-rockchip][PATCH] linux: 4.11 -> 4.12

[Trevor Woerner]

Bump mainline kernel to latest release.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 recipes-kernel/linux/{linux_4.11.bb => linux_4.12.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename recipes-kernel/linux/{linux_4.11.bb => linux_4.12.bb} (88%)

diff --git a/recipes-kernel/linux/linux_4.11.bb 
b/recipes-kernel/linux/linux_4.12.bb
similarity index 88%
rename from recipes-kernel/linux/linux_4.11.bb
rename to recipes-kernel/linux/linux_4.12.bb
index 8f1d2a7..0eff49b 100644
--- a/recipes-kernel/linux/linux_4.11.bb
+++ b/recipes-kernel/linux/linux_4.12.bb
@@ -6,8 +6,8 @@ require recipes-kernel/linux/linux-yocto.inc
 
 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
 
-SRCREV = "a351e9b9fc24e982ec2f0e76379a49826036da12"
-LINUX_VERSION = "4.11"
+SRCREV = "6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c"
+LINUX_VERSION = "4.12"
 # Override local version in order to use the one generated by linux build 
system
 # And not "yocto-standard"
 LINUX_VERSION_EXTENSION = ""
-- 
2.13.0

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

[yocto] [meta-rockchip][PATCH] rockchip-gpt-img: fix deprecated notation

[Trevor Woerner]

The older "IMAGE_DEPENDS..." notation has been deprecated in favour of the
newer "do_image_...[depends]" notation.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 classes/rockchip-gpt-img.bbclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/classes/rockchip-gpt-img.bbclass b/classes/rockchip-gpt-img.bbclass
index 941bae3..aa8cbe7 100644
--- a/classes/rockchip-gpt-img.bbclass
+++ b/classes/rockchip-gpt-img.bbclass
@@ -30,10 +30,10 @@ LOADER2_SIZE = "8192"
 ATF_SIZE = "8192"
 BOOT_SIZE = "229376"
 
-IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \
-   u-boot-mkimage-native \
-   mtools-native \
-   dosfstools-native \
+do_image_rockchip_gpt_img[depends] = "parted-native:do_populate_sysroot \
+   u-boot-mkimage-native:do_populate_sysroot \
+   mtools-native:do_populate_sysroot \
+   dosfstools-native:do_populate_sysroot \
virtual/kernel:do_deploy \
virtual/bootloader:do_deploy"
 
-- 
2.13.0

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

Re: [yocto] Yocto Project Technical Team Meeting

[Trevor Woerner]

In other words it's being pushed back a week for the US holiday?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][PATCH V2 0/3] Initial attempt at flashing instructions.

[Trevor Woerner]

On Sun, Jun 25, 2017 at 3:55 PM,  <drew.mose...@mender.io> wrote:
> From: Drew Moseley <drew.mose...@mender.io>
>
> * V2:
>
> Updated README and layer dependencies.
>
> Added error checking to flashing script
>
> * V1:
>
> This set of patches adds the native tools and target components needed to
> reflash the CHIP boards.  Additionally a shell script is added to the deploy
> directory showing how to kick off a flash update. It's not ideal as I've
> hardcoded a max size for the UBI image into the script and didn't see much
> of an alternative. It does function though.


Looks and works great! Thanks for investigating and getting this working :-)

Tested-by: Trevor Woerner <twoer...@gmail.com>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip] Jenkins, reviews and mailing list

[Trevor Woerner]

On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan  wrote:
> We've been testing a setup with meta-raspberrypi which seems to work fine:
> PR to github integrated with a jenkins server and use mailing list for
> discussions.
>
> I propose to copy the same setup to meta-chip too.

That's all fine. As the maintainer (thank you!) you're welcome to use
whatever workflow with which you're the happiest... as long as you
update the "Contributing" section of the README :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Current state of linux-raspberrypi-rt?

[Trevor Woerner]

On Sun, Jun 25, 2017 at 10:32 PM, Paul D. DeRocco
<pdero...@ix.netcom.com> wrote:
> Google turns up a lot of stuff about this, but the latest I found was a
> thread from 1/5/17 that started with Trevor Woerner posting a 1MB patch,
> and that ended with him posting a message saying that it didn't actually
> work.

I posted a v1, which worked great, and continues to work great.

After posting the v1, lots of feedback was given. One of those pieces
of feedback was that I shouldn't include the entire defconfig, but
rather I should use some sort of "savedconfig" setting to generate the
full config. I had never heard of this before. I asked for more
clarification but received none. I went ahead with the v2 using this
"savedconfig" technique. It *appeared* to work (which is why I
submitted the update to the mailing list), but, after a lot of
testing, I discovered that this "savedconfig" thing didn't work. The
defconfig that was generated using this technique was useless and
nobody could provide any reason why or advice how to fix it.

So v2 didn't work, but v1 did and still does (we're using it internally).

But everyone considered v1 to not be acceptable for inclusion for a
number of reasons, so it never got merged. Besides, that work was for
a 4.4 kernel, which is now considered "old".

> Is there anything new on this? I'm trying to do some compute-intensive
> audio on an RPi3, and it really needs a real-time kernel.

Andreas Müller has a meta-raspberrypi fork in which he has an -rt
recipe for a 4.9 kernel:
https://github.com/schnitzeltony/meta-raspi-light
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using clang for one recipe

[Trevor Woerner]

On Fri 2017-06-23 @ 03:57:06 PM, Khem Raj wrote:
> On Fri, Jun 23, 2017 at 3:39 PM, Trevor Woerner <twoer...@gmail.com> wrote:
> > Adding that line, and adding meta-clang to bblayers.conf, did get the
> > llvm/clang compiler built and installed to recipe-sysroot-native. But
> > the moment it starts to build the package, it fails immediately with:
> >
> > | fatal error: 'string' file not found
> > | #include 
> > |  ^~~~
> >
> > Did I miss a step? That seems like a pretty basic thing that would be
> > needed for using a toolchain. If feels like I'm missing something;
> > like I need to add something else to my local.conf. Thoughts?
> > Suggestions?
> 
> which package is it ? it seems its missing proper -I paths.?

I'm investigating moving chromium to a newer version, specifically something
much closer to the current Linux stable (59.0.3071.109). My understanding is
the chromium developers use clang, which would explain why it's always so much
work to get it to compile with gcc. If I can get chromium to build with clang,
I think it would make future maintenance much easier. Switching from gyp to gn
was easy, but getting this newer version to build with gcc7 is a challenge.

When I go to the recipe-sysroot-native, I find clang in usr/bin. But from that
base location if I do a

$ find . -name "*string*" -print

I don't find any such include files. Should they not be installed to the
native sysroot alongside clang itself?

Here's one example of a failing compile:

| [16/25529] CXX obj/base/allocator/tcmalloc/sysinfo.o
| FAILED: obj/base/allocator/tcmalloc/sysinfo.o
| ../../../recipe-sysroot-native/usr/bin/clang++ -MMD -MF 
obj/base/allocator/tcmalloc/sysinfo.o.d -DNO_HEAP_CHECK 
-DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 
-DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DDISABLE_NACL -DFULL_SAFE_BROWSING 
-DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD 
-DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED 
-DCR_CLANG_REVISION=\"299960-1\" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -DCOMPONENT_BUILD -D_DEBUG 
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 
-DTCMALLOC_FOR_DEBUGALLOCATION -DTCMALLOC_DONT_REPLACE_SYSTEM_ALLOC 
-I../../base/allocator -I../../third_party/tcmalloc/chromium/src/base 
-I../../third_party/tcmalloc/chromium/src -I../.. -Igen -fno-strict-aliasing 
--param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined 
-D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe 
-fcolor-diagnostics --target=arm-linux-gnueabihf -march=ar
 mv7-a -mfloat-abi=hard -mtune=generic-armv7-a -pthread -mfpu=neon -O0 
-fno-omit-frame-pointer -g2 
--sysroot=../../build/linux/debian_jessie_arm-sysroot -fvisibility=hidden 
-Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wall 
-Wno-unused-variable -Wno-missing-field-initializers -Wno-unused-parameter 
-Wno-c++11-narrowing -Wno-covered-switch-default 
-Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override 
-Wno-undefined-var-template -Wno-nonportable-include-path 
-Wno-address-of-packed-member -Wno-unused-lambda-capture 
-Wno-user-defined-warnings -Wno-reorder -Wno-unused-function 
-Wno-unused-local-typedefs -Wno-unused-private-field -Wno-sign-compare 
-Wno-unused-result -fvisibility-inlines-hidden -Wno-undefined-bool-conversion 
-Wno-tautological-undefined-compare -std=gnu++11 -fno-rtti -fno-exceptions 
-Wno-deprecated -c ../../third_party/tcmalloc/chromium/src/base/sysinfo.cc -o 
obj/base/allocator/tcmalloc/sysinfo.o
| In file included from 
../../third_party/tcmalloc/chromium/src/base/sysinfo.cc:62:
| In file included from 
../../third_party/tcmalloc/chromium/src/base/sysinfo.h:49:
| In file included from 
../../third_party/tcmalloc/chromium/src/base/logging.h:49:
| ../../third_party/tcmalloc/chromium/src/base/commandlineflags.h:52:10: fatal 
error: 'string' file not found
| #include 
|  ^~~~
| 1 error generated.


I can send you the non-working, partial recipe if you're interested too.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] using clang for one recipe

[Trevor Woerner]

I want to have one recipe build with clang instead of gcc (gcc is
being used for the rest of the image). I thought this was as simple as
adding the following line to the recipe:

TOOLCHAIN = "clang"

Adding that line, and adding meta-clang to bblayers.conf, did get the
llvm/clang compiler built and installed to recipe-sysroot-native. But
the moment it starts to build the package, it fails immediately with:

| fatal error: 'string' file not found
| #include 
|  ^~~~

Did I miss a step? That seems like a pretty basic thing that would be
needed for using a toolchain. If feels like I'm missing something;
like I need to add something else to my local.conf. Thoughts?
Suggestions?

I went looking for examples of recipes using clang and found
meta-openembedded/meta-oe/recipes-support/tbb.bb which includes:

COMPILER ?= "gcc"
COMPILER_toolchain-clang = "clang"

Odd. Why "COMPILER" and not "TOOLCHAIN" like meta-clang's README mentions?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

[Trevor Woerner]

On Mon, Jun 19, 2017 at 7:22 AM, Drew Moseley <drew.mose...@mender.io> wrote:
>
>> On Jun 19, 2017, at 1:48 AM, Trevor Woerner <twoer...@gmail.com> wrote:
>>
>>> If you have a serial console connected to
>>> +your board, you will see the progress and a message on the console will 
>>> indicate when
>>> +the flashing is completed.
>>
>> hmmm, never saw this. I have a console connected, the moment the script
>> started, on the console I got:
>>
>>   U-Boot SPL 2016.01 (Jun 19 2017 - 00:32:19)
>>   DRAM: 512 MiB
>>   CPU: 100800Hz, AXI/AHB/APB: 3/2/2
>>   Trying to boot from
>>
>> which looks right, the date+time are good.
>
> Did you see the proper serial output after using a smaller image?

Yes. With a smaller image (~90MB) the flash update worked. Maybe
another improvement for a v2 would be for the script to look at the
size of /full/path/to/UBI_IMAGE and issue a warning/error if it's too
big?

I think the wording of what to expect on the host and over the serial
console could use some updating. Not to mention you say: "the status
LED on the CHIP board will flash 30 times per second..." which doesn't
seem to be the case, it looks more like the LED is toggled every 2
seconds (??), in any case, it's a lot slower than 30/sec.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

[Trevor Woerner]

On Mon, Jun 19, 2017 at 1:48 AM, Trevor Woerner <twoer...@gmail.com> wrote:
> On Fri 2017-06-16 @ 05:15:40 PM, drew.mose...@mender.io wrote:
> Any thoughts?

It appears my image was too large. Using a smaller image appears to
work as expected!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

[Trevor Woerner]

On Fri 2017-06-16 @ 05:15:40 PM, drew.mose...@mender.io wrote:
> +This script will take some time to execute.

true

> If you have a serial console connected to
> +your board, you will see the progress and a message on the console will 
> indicate when
> +the flashing is completed.

hmmm, never saw this. I have a console connected, the moment the script
started, on the console I got:

U-Boot SPL 2016.01 (Jun 19 2017 - 00:32:19)
DRAM: 512 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Trying to boot from

which looks right, the date+time are good.

Where I started the script I get:

# UBI_IMAGE=core-image-full-cmdline-chip.ubi
# tmp-glibc/deploy/images/chip/flash_CHIP_board.sh
100% []  3537 kB,  
557.5 kB/s 
100% []   616 kB,  
823.9 kB/s 
100% [] 2 kB,  
733.9 kB/s
100% [] 654311 kB,  
771.4 kB/s

> Additionally, once the image is properly flashed, the status
> +LED on the CHIP board will flash 30 times per second indicating that it is 
> safe to power
> +down your board and disable FEL mode.

I don't get any LED flashing, and nothing other than what I've pasted above on
the console.

Rebooting the board after flashing outside of FEL mode simply boots the
previous u-boot and image.

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

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

[Trevor Woerner]

On Fri 2017-06-16 @ 05:15:40 PM, drew.mose...@mender.io wrote:
> diff --git a/README b/README
> index cccf59e..cf52e05 100644
> --- a/README
> +++ b/README
> @@ -59,4 +59,28 @@ To build a machine supported by this BSP layer follow the 
> next steps:

Please wrap the additions to the README to 80 columns.

>  II. Flashing a C.H.I.P. board
>  
>  
> -
> +As part of the build including this BSP layer, a U-Boot script and a shell 
> script
> +are created to assist in flashing your images to the CHIP board.  Note that 
> this
> +script assumes a maximum size for your UBI image of 0x0A00 bytes.  If 
> your UBI
> +image exceeds that, then you will need to adapt this to your environment.
> +
> +To successfully run this script you will first need to set your board into 
> FEL mode.
> +chip. https://docs.getchip.com/chip.html#flash-chip-with-an-os
> +Insert a wire into the U14 header between pin 7 (FEL) and GND.  Then connect 
> the
> +board with a USB cable to your build system.
> +
> +You need to specify the base filename of your UBI image using the UBI_IMAGE 
> shell
> +variable before invoking the generated script as follows:
> +
> +$ UBI_IMAGE=core-image-full-cmdline-chip.ubi 
> ./tmp/deploy/images/chip/flash_CHIP_board.sh

Outside of a udev tweak, this script needs to be run as root. It's traditional
to indicate commands run as root by prefixing them with a PS1 of '#'.

> +
> +This script will take some time to execute.  If you have a serial console 
> connected to
> +your board, you will see the progress and a message on the console will 
> indicate when
> +the flashing is completed. Additionally, once the image is properly flashed, 
> the status
> +LED on the CHIP board will flash 30 times per second indicating that it is 
> safe to power
> +down your board and disable FEL mode.
> +
> +WARNING: This will erase the entire contents of your CHIP board.
> +
> +NOTE: This setup is still compatible with the CHIP flashing utility available
> +at http://flash.getchip.com if you choose to reinstall the stock images.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 2/3] chip: Build sunxi-tools-native.

[Trevor Woerner]

On Fri, Jun 16, 2017 at 5:15 PM,   wrote:
> Add LAYERDEPENDS on meta-sunxi and add the sunxi-tools-native
> pacakage to EXTRA_IMAGEDEPENDS.


meta-chip's README should also indicate this dependency.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 2/2] u-boot: Backport upstream fix for gmac_rockchip

[Trevor Woerner]

Hi Romain,

I assume this patch is meant to fix an ethernet issue in u-boot? How does
someone test that ethernet is working from u-boot?

Here is my firefly booting with these patches:


U-Boot SPL 2017.05 (Jun 17 2017 - 17:12:20)
Returning to boot ROM...

U-Boot 2017.05 (Jun 17 2017 - 17:12:20 -0400)

Model: Firefly-RK3288
DRAM:  1.7 GiB
MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@ff29 (eth0) using random MAC address - 
5a:40:1a:28:0e:43
eth0: ethernet@ff29
Hit any key to stop autoboot:  0 

Here is me configuring the networking stuff in u-boot:

=> setenv ipaddr 192.168.142.20
=> setenv netmask 255.255.255.0
=> setenv serverip 192.168.142.1

Then I try pinging my server:

=> ping 192.168.142.1
ethernet@ff29 Waiting for PHY auto negotiation to complete... done
Speed: 100, full duplex
Using ethernet@ff29 device

The next thing I know my firefly is rebooting:

data abort
pc : [<6ada703a>]  lr : [<6ada7dbb>]
reloc pc : [<0003303a>]lr : [<00033dbb>]
sp : 68d67e48  ip :  fp : 0002
r10: 68d77e60  r9 : 68d71ee8 r8 : 
r7 : 0001  r6 :  r5 : 002a  r4 : 6adfd04e
r3 : 1445  r2 : 148ea8c0 r1 : 018ea8c0  r0 : 6adfd04e
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


U-Boot SPL 2017.05 (Jun 17 2017 - 17:12:20)
Returning to boot ROM...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH] u-boot-rockchip: Switch to u-boot-common_2017.05.inc

[Trevor Woerner]

Hi Romain,

My nightly builds alerted me to the problem, so I fixed it and already
pushed a patch.
Thanks!

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] etnaviv image

[Trevor Woerner]

Hey Steve,

That's great to hear, and thanks for the followup :-)

Otavio has since pushed everything to master, so hopefully the kludges
aren't required anymore.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] etnaviv image

[Trevor Woerner]

Hey Stephen,

On Fri, May 26, 2017 at 7:23 PM, Stephen Arnold
 wrote:
> @Trevor what's your config/setup?  Did you wind up using the
> "use-mainline-bsp" thing?

Yes.

As I mentioned, I was working with a wandboard, on master, therefore
my layers are:
- openembedded-core
- meta-freescale-3rdparty
- meta-freescale

If I was working on some other board that didn't require
meta-freescale-3rdparty I wouldn't have needed that layer.
Additionally, I had started by using meta-etnaviv as well. That layer
hasn't seen any commits in roughly 10 months. Back then my guess is
that "upstream" didn't include very many of the bits required to get
this to work, therefore meta-etnaviv had to include recipes/bbappends
for mesa, libdrm, xorg-xserver, etc... in addition to the etnaviv drm
pieces themselves.

I created my own clone of meta-etnaviv
[https://github.com/twoerner/meta-etnaviv] and pushed all my
commits/updates there with the intention of, eventually, sending a
pull request to its author. But by the time I was done removing all
the things that are no longer needed (i.e. all the bbappends, since
upstream mesa, libdrm, etc... all include the necessary bits) and
updating the remaining stuff, I was left with very little. So little,
in fact, that I decided to simply fold what was left back into
meta-freescale itself, conditional on the "use-mainline-bsp"
MACHINEOVERRIDES, and sent those patches to the meta-fsl mailing list.

If the maintainers of meta-freescale accept the assumption that
use-mainline-bsp could be the flag that indicates interest between the
binary vivante drivers and etnaviv, then I hope they like the patches
and accept them into meta-freescale itself. Otherwise I could just
send that pull request to meta-etanviv's author (or re-work the
patches with whatever feedback I get). In any case, for wandboard
use-mainline-bsp is needed since the default kernel for wandboard is
linux-wandboard which is still stuck at 4.1.15 and is too old for this
etnaviv stuff. However using use-mainline-bsp with the wandboard is
broken, so I had to send some patches for that (u-boot and kernel) as
well (hopefully those patches are accepted as well).

Due to the fact so much of etnaviv is already upstream, getting
etanviv working doesn't take very much. It just took me a while to
reach that point, however :-)

> I pretty much had to hack up some of the meta-fsl/meta-boundary stuff and
> put everything else in local.conf.  It would be a little easier/cleaner if
> the former had some ?= in a few places...
>
> Anyway, I masked the browser stuff so I haven't tested that far yet, but all
> you really need for 3D under X is new kernel/libdrm/mesa for ~110 fps with
> glxgears.

I like to use mesa-demos and (especially) glmark2 as my programs of
choice for testing GL stuff.

> I added recipes for the x11-armada stuff, which seems to work for
> 2D but coughs an error in the xorg log.

I'm curious to know which x11-armada stuff you're using. I couldn't
get the stuff that came with meta-etnaviv to compile so I looked
around and found Russell King's code which seemed more up-to-date, and
compiled. Plus my xorg log doesn't have any errors (see attachment).

> I probably tested more with oe-core
> than poky but both should work.

I just tend to stick with oe-core.

I'm hoping to make a couple blog posts with my findings.
[20.498] 
X.Org X Server 1.19.1
Release Date: 2017-01-11
[20.502] X Protocol Version 11, Revision 0
[20.503] Build Operating System: Linux 4.4.62-18.6-default x86_64 
[20.505] Current Operating System: Linux wandboard 4.9.21-fslc+gb69ecd63c123 #1 SMP Fri May 26 14:57:41 EDT 2017 armv7l
[20.506] Kernel command line: root=PARTUUID=6ef67890-01 rootwait rw console=ttymxc0,115200
[20.509] Build Date: 27 May 2017  01:01:57AM
[20.511]  
[20.513] Current version of pixman: 0.34.0
[20.516] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[20.517] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[20.525] (==) Log file: "/var/log/Xorg.0.log", Time: Sat May 27 05:04:39 2017
[20.536] (==) Using config file: "/etc/X11/xorg.conf"
[20.537] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[20.548] (==) No Layout section.  Using the first Screen section.
[20.549] (==) No screen section available. Using defaults.
[20.549] (**) |-->Screen "Default Screen Section" (0)
[20.549] (**) |   |-->Monitor ""
[20.560] (==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
[20.560] (**) |   |-->Device "Driver0"
[20.560] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[20.560] (==) Automatically adding devices
[20.560] (==) Automatically 

Re: [yocto] etnaviv image

[Trevor Woerner]

On Thu, May 25, 2017 at 5:01 AM, Gary Thomas  wrote:
> Would you mind sharing your configuration (conf/local.conf,
> conf/bblayers.conf)?
> I'm mostly interested in trying this on my RaspberryPi3.

Absolutely!

I'm hoping to do a couple blog posts about it soon-ish showing
comparative results of glmark2-es2
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] etnaviv image

[Trevor Woerner]

w00t!!

It took a lot of hacking, but I was able to build and run an image for
the wandboard dual that uses etnaviv :-D

Patches to follow.

I now have 4 dev boards using open-source graphics:
1) rpi3-32 with vc4
2) dragonboard-410c with freedreno
3) minnow (turbot) with Intel's stuff
4) wandboard with etnaviv

glmark2-es2:

root@wandboard:~# glmark2-es2; cat /proc/loadavg
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
GL_VERSION:OpenGL ES 2.0 Mesa 17.0.4
===
[build] use-vbo=false: FPS: 69 FrameTime: 14.493 ms
[build] use-vbo=true: FPS: 80 FrameTime: 12.500 ms
[texture] texture-filter=nearest: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=linear: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=mipmap: FPS: 66 FrameTime: 15.152 ms
[shading] shading=gouraud: FPS: 70 FrameTime: 14.286 ms
[shading] shading=blinn-phong-inf: FPS: 61 FrameTime: 16.393 ms
[shading] shading=phong: FPS: 47 FrameTime: 21.277 ms
[shading] shading=cel: FPS: 39 FrameTime: 25.641 ms
[bump] bump-render=high-poly: FPS: 52 FrameTime: 19.231 ms
[bump] bump-render=normals: FPS: 67 FrameTime: 14.925 ms
[bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 32 FrameTime: 31.250 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 61 FrameTime: 16.393 ms
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 67 FrameTime: 14.925 ms
Error: RenderObject::init: glCheckFramebufferStatus failed (0x8cdd)
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] effect=shadow:windows=4: FPS: 68 FrameTime: 14.706 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 31 FrameTime: 32.258 ms
[ideas] speed=duration:[ 2797.051681] etnaviv-gpu 13.gpu:
hangcheck detected gpu lockup!
[ 2797.059575] etnaviv-gpu 13.gpu:  completed fence: 50513
[ 2797.065622] etnaviv-gpu 13.gpu:  active fence: 50514
[ 2797.072346] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2800.011603] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2800.017890] etnaviv-gpu 13.gpu:  completed fence: 50514
[ 2800.023895] etnaviv-gpu 13.gpu:  active fence: 50515
[ 2800.029752] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2803.051591] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2803.057899] etnaviv-gpu 13.gpu:  completed fence: 50516
[ 2803.063874] etnaviv-gpu 13.gpu:  active fence: 50518
[ 2803.069702] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2805.531626] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2805.537973] etnaviv-gpu 13.gpu:  completed fence: 50518
[ 2805.544052] etnaviv-gpu 13.gpu:  active fence: 50520
[ 2805.551826] etnaviv-gpu 13.gpu: hangcheck recover!
 FPS: 0 FrameTime: inf ms
[jellyfish] : FPS: 28 FrameTime: 35.714 ms
[terrain] : FPS: 2 FrameTime: 500.000 ms
[shadow] : FPS: 30 FrameTime: 33.333 ms
Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cdd)
Error: Failed to set up the render target for the depth pass
[refract] : Set up failed
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 61 FrameTime: 16.393 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 31 FrameTime: 32.258 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 62 FrameTime: 

Re: [yocto] webkitgtk2 progress bar

[Trevor Woerner]

On Wed, May 24, 2017 at 1:16 PM, Martin Jansa  wrote:
> My "bitbake world" builds have few components like this, webkitgtk (used to
> have webkit1, webkit2 and webkit2-efl as separate builds), 2 chromiums (x11
> and wayland), cef (luckily broken and whitelisted for a while), firefox,
> qtwebengine, qtwebkit. Each taking usually even more time than "simplest"
> webkitgtk2.

...speaking of which...

It's probably about time someone sends a patch to remove cef, it has
been a while since anyone cared for it.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can Yocto treat layers like an external package?

[Trevor Woerner]

Hi Yannick,

This is a feature many people have been wanting for a while, but
getting there has been slow. So slow, in fact, that many projects have
simply gone ahead and implemented their own solutions, all of which
are different from each other, making it all that much harder to get
everyone back together to support one idea :-(

As Gary mentions, "repo" is a popular solution. See, for example, how
the Linaro people have done it with their "rpb" distro and associated
setup tools/scripts:

https://github.com/96boards/oe-rpb-manifest

The freescale project was the first such instance I saw (but I can't
say whether they were the first or not):

https://github.com/Freescale/fsl-community-bsp-platform
http://freescale.github.io/#download

Mark Hatle (windriver) has been working on and releasing a tool
they've been using internally for a while:

https://www.openembedded.org/wiki/OEDEM_2016#Windriver_.E2.80.98setup.E2.80.99_Demo

I'm sure there are better links for Mark's work, but I can't find them
at the moment. Hopefully someone jumps in and fills in the blanks :-)

I'm sure there are other such examples.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

[Trevor Woerner]

On Wed, May 24, 2017 at 4:12 PM, Philip Balister  wrote:
> I'd check with Marex the u-boot maintainer also. He may have something
> queued up. It is entirely possible he isn't on this list.

Good point. Marek just posted a 2017.05 update to oecore :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

[Trevor Woerner]

Hi Romain,

On Wed, May 24, 2017 at 11:05 AM, Romain Perier
<romain.per...@collabora.com> wrote:
> Le 24/05/2017 à 16:55, Trevor Woerner a écrit :
>> On Wed, May 24, 2017 at 10:46 AM, Romain Perier
>> <romain.per...@collabora.com> wrote:
>>> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
>>>> u-boot 2017.05 was released May 10. Wouldn't it be better to update
>>>> oe-core's u-boot to 2017.05 then just add any differences in
>>>> meta-rockchip?
>>> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
>>> v2017.05 in poky (and then propose changes in meta-rockchip)
>> Changes to u-boot should be sent to openembedded-core; poky gets
>> updated from there (not vice versa).
> Even, if I Cc: the ML oe-core and yocto ? (so I have to do the changes
> in oe-core directly, I mean the repo. right ?)

Yes. The "home" of the u-boot recipe is in openembedded-core. Please
send any updates/changes to the u-boot recipe to the openembedded-core
mailing list [http://lists.openembedded.org/mailman/listinfo/openembedded-core].
CC'ing it to other lists would not be polite since most OE/Yocto lists
receive quite a lot of traffic already and this would be a
non-relevant email to them.

Poky is derived from a bunch of sources, primarily openembedded-core,
plus some small additions of its own. Only when you want to change one
of these small additions would you send a patch to the poky mailing
list directly (which isn't the case with u-boot).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

[Trevor Woerner]

On Wed, May 24, 2017 at 10:46 AM, Romain Perier
<romain.per...@collabora.com> wrote:
> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
>> u-boot 2017.05 was released May 10. Wouldn't it be better to update
>> oe-core's u-boot to 2017.05 then just add any differences in
>> meta-rockchip?
>
> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
> v2017.05 in poky (and then propose changes in meta-rockchip)

Changes to u-boot should be sent to openembedded-core; poky gets
updated from there (not vice versa).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

[Trevor Woerner]

u-boot 2017.05 was released May 10. Wouldn't it be better to update
oe-core's u-boot to 2017.05 then just add any differences in
meta-rockchip?

On Mon, May 22, 2017 at 11:17 AM, Romain Perier
 wrote:
> This set of patches add a new u-boot-common file for 2017.05, so
> it can be shared between u-boot-rockchip and a u-boot recipe for
> mainline. Then, it add a bbappend to bump u-boot to the last
> v2017.05.
>
> Romain Perier (3):
>   u-boot: Add u-boot-common_2017.05.inc
>   u-boot-rockchip: Use u-boot-common_2017.05.inc
>   u-boot: Add bbappend for u-boot mainline
>
>  recipes-bsp/u-boot/u-boot-common_2017.05.inc | 14 ++
>  recipes-bsp/u-boot/u-boot-rockchip_git.bb|  2 +-
>  recipes-bsp/u-boot/u-boot_%.bbappend |  5 +
>  3 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 recipes-bsp/u-boot/u-boot-common_2017.05.inc
>  create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend
>
> --
> 1.8.3.1
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH v3 1/3] recipes-multimedia: add Rockchip MPP library

[Trevor Woerner]

Randy,

Neither of the issues that were identified in your v2 of this patch were
addressed in this v3. Namely:

1) please use your real name (first, last) in your signed-off-by line
2) please don't create a package from this recipe whose name doesn't include
   the recipe name (i.e. please don't create "rockchip-vpu" from a recipe
   "rockchip-mpp"), suggestions were provided

Aside from the email headers and the version of git used, this patch is
identical to the v2 you submitted.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip] [PATCH v2 3/3] recipes-multimedia: images: rockchip media image

[Trevor Woerner]

On Sat 2017-05-13 @ 06:20:35 PM, Romain Perier wrote:
> Clearly a NAK here. I don't want yet another image for this, that's a
> bsp meta layer, it is supposed to contain the recipes and rules to
> propose support for Rockchip SocS in in yocto/oe and its reference
> distros. But it is also supposed to be minimal, I don't want "all the
> world"  in meta-rockchip, to be honest :)
> 
> I am not fan to have recipes or rules for development...
> 
> Trevor, as a co-maintainer, what is your point about this ? (always welcome)

It's not uncommon for BSP layers to include sample image recipes
(meta-raspberrypi, for example, includes rpi-test-image, rpi-basic-image, and
rpi-hwup-image). These sample images act as a sort of example, or
documentation for others to follow. They're a way to show off what can be
done.

This recipe could act as an example should anyone want to integrate gstreamer
support for a rockchip in their image (assuming this image builds and works).

I'm not opposed to it being there, as long as it's benign and works.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH] linux: version bump to 4.11

[Trevor Woerner]

Thanks!
Tested on the firefly-rk3288 and applied.

On Sat, May 13, 2017 at 11:58 AM, Romain Perier
 wrote:
> Linux v4.11 has been released, bump the version to 4.11.
>
> Signed-off-by: Romain Perier 
> ---
>  recipes-kernel/linux/linux_4.11.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux_4.11.bb 
> b/recipes-kernel/linux/linux_4.11.bb
> index 6058661..8f1d2a7 100644
> --- a/recipes-kernel/linux/linux_4.11.bb
> +++ b/recipes-kernel/linux/linux_4.11.bb
> @@ -6,13 +6,13 @@ require recipes-kernel/linux/linux-yocto.inc
>
>  SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
>
> -SRCREV = "5a7ad1146caa895ad718a534399e38bd2ba721b7"
> +SRCREV = "a351e9b9fc24e982ec2f0e76379a49826036da12"
>  LINUX_VERSION = "4.11"
>  # Override local version in order to use the one generated by linux build 
> system
>  # And not "yocto-standard"
>  LINUX_VERSION_EXTENSION = ""
>  PR = "r1"
> -PV = "${LINUX_VERSION}-rc8"
> +PV = "${LINUX_VERSION}"
>
>  # Include only supported boards for now
>  COMPATIBLE_MACHINE = 
> "(radxarock|marsboard-rk3066|firefly-rk3288|rock2-square)"
> --
> 1.8.3.1
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-announce] [ANNOUNCEMENT] Yocto Project 2.3 (pyro 17.0.0) Released

[Trevor Woerner]

On Fri, May 12, 2017 at 8:20 PM, Tracy Graydon  wrote:
> The latest release of the Yocto Project 2.3 (pyro-17.0.0) is now available 
> for download at:

w00t!! Congrats everyone! :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Raspberry pi build with QT5 creator...... failing to compile.

[Trevor Woerner]

Hi Steve,

It seems like there's a lot of stuff going on at the same time. So to
start I'd like to just focus on one thing at a time.

On Wed, May 10, 2017 at 9:40 AM, Steve Plant  wrote:
> I'm currently attempting to build a raspberry pi image, which I can use to
> develop QT5 code for a beaglebone black.

This statement is very confusing to me.

It sounds like you want to build an image for the raspi, boot that
image on a pi, hookup a keyboard, mouse, monitor to the pi, write qt5
code on the pi, and compile that code on the pi to run on a
beaglebone. Is that your goal?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Pull requests and jenkins

[Trevor Woerner]

On Fri, May 12, 2017 at 4:00 PM, Andrei Gherzan  wrote:
> On Fri, May 12, 2017 at 7:34 PM, Paul Barker  wrote:
>> On Fri, May 12, 2017 at 7:05 PM, Andrei Gherzan  wrote:
>>> Hi all,
>>>
>>> I know I promised long ago but finally I took a Friday to invest into
>>> github pull requests integrated with a jenkins server.

yay!
+1

(my inbox has been going nuts today!)

>> I'm doing nightly builds of my setup but that's a bit non-standard
>> (custom distro, musl libc, u-boot enabled, etc). For meta-raspberrypi
>> itself I think you've got it right - test against the appropriate
>> branch of poky without changing the default configuration too much.

I have a couple nightly builds too for the things that interest me.

>> For the readme, I think we should split off
>> "docs/optional-build-configuration.md", "docs/board-configuration.md"
>> and maybe "docs/contributing.md" files to shorten the top-level file.
>> Does that sound sensible?
>
> We did touch this subject a little bit in private but in summary this
> is a topic that I really want to address in the near future:
> documentation. We start to have a pretty big readme and on the long
> term that is not feasible.

Maybe (just throwing this out there) the README in the layer could be
very basic (maintainers, layer dependencies, ...) and then point users
to a more elaborate documentation wiki setup on github?

https://github.com/agherzan/meta-raspberrypi/wiki
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dhcp eth0 network

[Trevor Woerner]

Hi Peter,

There isn't enough information here for me to help you.

Could you please list the commands and steps you used to build the image?
- what repositories are you using?
- what branches of those repositories?
- if you changed any config files, what did you change?
- what command did you run to build your image?
- what did bitbake print as your build configuration?

Which i.mx board are you using? There are dozens of them.

Best regards,
Trevor


On Fri, May 12, 2017 at 3:34 PM, pe...@gmail.com
<balazovic.pe...@gmail.com> wrote:
> I build on i.mx (NXP) machine, I want to get configured as dhcp  (no
> static)...
>
>
> -- Original Message --
> From: "Trevor Woerner" <twoer...@gmail.com>
> To: "Peter Balazovic" <balazovic.pe...@gmail.com>
> Cc: "Yocto list discussion" <yocto@yoctoproject.org>
> Sent: 5/12/2017 9:32:17 PM
> Subject: Re: [yocto] dhcp eth0 network
>
>> Hi Peter,
>>
>> For what MACHINE are you building? What's your target hardware? Can
>> you summarize the steps you took to build your image?
>>
>> What do you want eth0 to do? dhcp or static ip?
>>
>> Best regards,
>> Trevor
>>
>>
>> On Fri, May 12, 2017 at 12:01 PM, Peter Balazovic
>> <balazovic.pe...@gmail.com> wrote:
>>>
>>>  Dears,
>>>
>>>  I got Yocto image and unfortunatelly network is not somehow enabled &
>>>  proprely configured. After "ifconfig" no eth0 configured.
>>>
>>>
>>>>  ifconfig
>>>
>>>  loLink encap:Local Loopback
>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>>   
>>>
>>>
>>>
>>>>  /etc/network
>>>>  ls
>>>
>>>  if-down.d if-post-down.d if-pre-up.d  if-up.d
>>>
>>>
>>>  How should I setup "eth0" to get network working properly?
>>>
>>>  Thanks.
>>>
>>>
>>>
>>>  --
>>>  ___
>>>  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] dhcp eth0 network

[Trevor Woerner]

Hi Peter,

For what MACHINE are you building? What's your target hardware? Can
you summarize the steps you took to build your image?

What do you want eth0 to do? dhcp or static ip?

Best regards,
Trevor


On Fri, May 12, 2017 at 12:01 PM, Peter Balazovic
 wrote:
> Dears,
>
> I got Yocto image and unfortunatelly network is not somehow enabled &
> proprely configured. After "ifconfig" no eth0 configured.
>
>
>> ifconfig
> loLink encap:Local Loopback
>inet addr:127.0.0.1 Mask:255.0.0.0
>  
>
>
>
>> /etc/network
>> ls
> if-down.d if-post-down.d if-pre-up.d  if-up.d
>
>
> How should I setup "eth0" to get network working properly?
>
> Thanks.
>
>
>
> --
> ___
> 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] Stable branch plans

[Trevor Woerner]

On Mon, May 8, 2017 at 4:36 AM, Paul Barker  wrote:
> On 3 May 2017 2:41 a.m., "Khem Raj"  wrote:
>
> On Tue, May 2, 2017 at 4:19 AM, Paul Barker  wrote:
>>
>> I'd like to propose the following for the pyro branch:
>>
>> * We should create the pyro branch within a week or two of the oe-core
>> pyro release.
>
> What do we get by branching early  ?
>
>
> I'd like to be able to say to users that all layers should be on the same
> branch, it's confusing if some need to be on pyro and others on master. It
> also makes our release much easier as we can point our scripts at the pyro
> branch early and not have to worry about future breakage.
>
> I don't mind as much if pyro tracks master for the first few weeks until
> things settle down, but I think it's really beneficial to have a pyro branch
> in each layer from around the time of the oe-core release.

+1

Initially we'll have to use meta-raspberrypi master to build with
pyro. But eventually one commit will come along that breaks. Then
we'll have to wait for someone to create the pyro branch then change
our builds. It would be easier if everything is on, and stays on, pyro
from the start.

Also, if, in the future, we wanted to go back in time to recreate an
early build, someone will have to remember that before a certain date
you'll need to use meta-raspberrypi master with oe-core pyro. Or if in
a year from now you wanted to checkout the repositories from June of
this year, it'll be confusing why meta-raspberrypi didn't have a pyro
branch by that point.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Stable branch plans

[Trevor Woerner]

It is very likely that I too will be trying to base an rpi-based
"product" off of pyro and hope that it will be as pain-free as
possible :-)

I don't have any past experience with this, so I can't speak to any past issues.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-rockchip][PATCH] README: remove irrelevant information

[Trevor Woerner]

As of openembedded-core commit 2b3ae58f5eaecc8474761c543ff5347aa0e3c4c8 hardfp
is enabled by default.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 README | 16 
 1 file changed, 16 deletions(-)

diff --git a/README b/README
index b2e89f3..7f4a499 100644
--- a/README
+++ b/README
@@ -49,7 +49,6 @@ Table of Contents
   I. Configure yocto/oe environment
  II. Building a second level bootloader based on kexec
 III. Booting your device
- IV. Performance
 
 I. Configure yocto/oe environment
 
@@ -127,18 +126,3 @@ linux-next from tftp='tftp://192.168.0.5/zImage 
dtb=tftp://192.168.0.5/
 Then, plug your SDCARD into your Rockchip device and power on the board. If
 everything worked fine, Petitboot should be started automatically and list all 
 entries found in the configuration file.
-
-IV. Performance
-===
-
-By default a BSP layer should not be tuning a build, this is a DISTRO-level
-decision. As such the default machine settings are meant to be the lowest
-common denominator in order to maximize generality. If you are interested in
-tweaking your build to maximize performance you can either use a DISTRO that
-has these same goals, or you can add settings in your configuration files
-(e.g. local.conf) as follows:
-
-   for rk3288:
-   DEFAULTTUNE = "cortexa17hf-neon-vfpv4"
-   for rk3066:
-   DEFAULTTUNE = "cortexa9-neon"
-- 
2.12.0.rc1.48.g076c053

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

Re: [yocto] [meta-rockchip][PATCH] linux: version bump to 4.11-rc8

[Trevor Woerner]

Applied, thanks!

It's nice to finally see those "mmc_host mmc2: Bus speed (slot 0) = 5000Hz
(slot req 5200Hz, actual 5000HZ div = 0)" messages gone :-)

On Fri 2017-04-28 @ 03:58:57 PM, Romain Perier wrote:
> Linux kernel 4.11 being released soon, bump recipe to 4.11-rc8.
> 
> Signed-off-by: Romain Perier 
> ---
>  recipes-kernel/linux/linux_4.10.bb | 19 ---
>  recipes-kernel/linux/linux_4.11.bb | 20 
>  2 files changed, 20 insertions(+), 19 deletions(-)
>  delete mode 100644 recipes-kernel/linux/linux_4.10.bb
>  create mode 100644 recipes-kernel/linux/linux_4.11.bb
> 
> diff --git a/recipes-kernel/linux/linux_4.10.bb 
> b/recipes-kernel/linux/linux_4.10.bb
> deleted file mode 100644
> index e1d0aa4..000
> --- a/recipes-kernel/linux/linux_4.10.bb
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -# Copyright (C) 2017 Romain Perier
> -# Copyright (C) 2017 Eddie Cai
> -# Released under the MIT license (see COPYING.MIT for the terms)
> -
> -require recipes-kernel/linux/linux-yocto.inc
> -
> -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> -
> -SRCREV = "7089db84e356562f8ba737c29e472cc42d530dbc"
> -LINUX_VERSION = "4.10"
> -# Override local version in order to use the one generated by linux build 
> system
> -# And not "yocto-standard"
> -LINUX_VERSION_EXTENSION = ""
> -PR = "r1"
> -PV = "${LINUX_VERSION}-rc8"
> -
> -# Include only supported boards for now
> -COMPATIBLE_MACHINE = 
> "(radxarock|marsboard-rk3066|firefly-rk3288|rock2-square)"
> -deltask kernel_configme
> diff --git a/recipes-kernel/linux/linux_4.11.bb 
> b/recipes-kernel/linux/linux_4.11.bb
> new file mode 100644
> index 000..6058661
> --- /dev/null
> +++ b/recipes-kernel/linux/linux_4.11.bb
> @@ -0,0 +1,20 @@
> +# Copyright (C) 2017 Romain Perier
> +# Copyright (C) 2017 Eddie Cai
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> +
> +SRCREV = "5a7ad1146caa895ad718a534399e38bd2ba721b7"
> +LINUX_VERSION = "4.11"
> +# Override local version in order to use the one generated by linux build 
> system
> +# And not "yocto-standard"
> +LINUX_VERSION_EXTENSION = ""
> +PR = "r1"
> +PV = "${LINUX_VERSION}-rc8"
> +
> +# Include only supported boards for now
> +COMPATIBLE_MACHINE = 
> "(radxarock|marsboard-rk3066|firefly-rk3288|rock2-square)"
> +deltask kernel_configme
> +
> -- 
> 1.8.3.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 4/5] u-boot-rockchip: remove duplicated variables

[Trevor Woerner]

This doesn't succeed for me:

ERROR: 
/opt/oe/configs/z/build-master/firefly-rk3288/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:
 This recipe does not have the LICENSE field set (u-boot-rockchip)
ERROR: Failed to parse recipe: 
/opt/oe/configs/z/build-master/firefly-rk3288/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb

But it does work if I add...

On Fri 2017-04-28 @ 04:01:25 PM, Romain Perier wrote:
>  # Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
>  # Copyright (C) 2017 Trevor Woerner <twoer...@gmail.com>
> +# Copyright (C) 2017 Romain Perier <romain.per...@collabora.com>
>  # Released under the MIT license (see COPYING.MIT for the terms)
>  
>  require recipes-bsp/u-boot/u-boot.inc
require recipes-bsp/u-boot/u-boot-common_2017.01.inc
>  
>  DESCRIPTION = "Rockchip next-dev U-Boot"
> -LICENSE = "GPLv2+"
> -LIC_FILES_CHKSUM = 
> "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
>  COMPATIBLE_MACHINE = "(firefly-rk3288)"
...

Does this make sense?

I'm building against openembedded-core
e584be78f92ee6f08f570c239698d56ac78d05f9

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE   = "firefly-rk3288"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU= "hard"
meta-rockchip = 
"devs/rperier/20170429:0d89dcc4a5a2827b68d920bbd32e4aece774b5eb"
meta  = "master:e584be78f92ee6f08f570c239698d56ac78d05f9"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Building rpi-test-image for Pi3 64 bit

[Trevor Woerner]

On Fri, Apr 28, 2017 at 12:01 PM, Luca Carlon  wrote:
> I'm trying to build rpi-test-image for Raspberry Pi 3 64 bit but I'm getting
> this error: https://pastebin.com/rYJ0PL7h. It seems it is looking for a file
> that is not there, and I don't see it in the linux repo either:


You could try adding the following to your local.conf:

KERNEL_DEVICETREE_remove = "bcm2708-rpi-0-w.dtb"

bcm2708-rpi-0-w.dtb is the device tree to add raspi0-wifi support.
This failure means the kernel you're using hasn't yet been updated to
include this device yet.

See commit 66e0e37ce3831e1a3511761dffb03c8000e9d7f7 of
meta-raspberrypi
https://github.com/agherzan/meta-raspberrypi/commit/66e0e37ce3831e1a3511761dffb03c8000e9d7f7
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto