[yocto] More new messages
Seems updating to the latest master has brought a lot of new messages. I'm seeing lots like these: WARNING: libsndfile1-1.0.27-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libass-0.13.2-r0 do_configure: QA Issue: libass: configure was passed unrecognised options: --enable-enca [unknown-configure-option] WARNING: imx-alsa-plugins-1.0.26-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? Any ideas? Perhaps this has something to do with having a very old (constantly updated, never removed since 2016-01-13) sstate-cache? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Ordering of anonymous Python functions and task signature calculations
On Tue, 2017-01-24 at 11:55 -0600, Matt Hoosier wrote: > In order to support a use-case that embeds information about the Git > revision of Yocto itself that was used to make a build, I would like to > run > some arbitrary Python code and dump the results (Git SHA1's, tag names, > etc) into a Bitbake variable. Have you looked at image-buildinfo.bbclass? From your description, it seems to do what you want. INHERIT += "image-buildinfo" works well for me... Cheers, Andre' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-kernel-tools][PATCH 0/1] Rework merge of feature branches
I've recently noticed that, on Morty, feature branches of a Yocto kernel are not merged anymore. This is due to the fact that the meta-series file does not process the git merge commands anymore. This commit creates a new merge command to be executed when processing the kernel metadata. To solve the issue, there is also a patch to send to oe-core for kernel-yocto.bbclass, but I wait for this patch to be included since there is no point without it. David Vincent (1): scc: Move merge command tools/kgit-meta | 14 ++ tools/scc| 13 - tools/scc-cmds/merge.cmd | 10 ++ 3 files changed, 24 insertions(+), 13 deletions(-) create mode 100644 tools/scc-cmds/merge.cmd -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-kernel-tools][PATCH 1/1] scc: Move merge command
Create a new command to merge a feature branch inside the current branch
when processing meta-series.
Signed-off-by: David Vincent
---
tools/kgit-meta | 14 ++
tools/scc| 13 -
tools/scc-cmds/merge.cmd | 10 ++
3 files changed, 24 insertions(+), 13 deletions(-)
create mode 100644 tools/scc-cmds/merge.cmd
diff --git a/tools/kgit-meta b/tools/kgit-meta
index 1c19ef5..aa5e210 100755
--- a/tools/kgit-meta
+++ b/tools/kgit-meta
@@ -254,6 +254,20 @@ for fline in `cat ${meta_series}`; do
fi
fi
;;
+merge:*)
+b=$(echo ${fline} | cut -d: -f2 | sed 's%^\ %%')
+check_branch ${b}
+if [ $? -ne 0 ]; then
+echo "ERROR. branch ${b} does not exist, can't merge"
+exit 1
+else
+echo "[INFO]: branch merge: ${b}"
+eval git merge -q --no-ff -m \"Merge branch ${b}\" ${b}
+if [ $? -ne 0 ]; then
+exit 1
+fi
+fi
+;;
*)
;;
esac
diff --git a/tools/scc b/tools/scc
index 3d17496..cee9e0d 100755
--- a/tools/scc
+++ b/tools/scc
@@ -286,19 +286,6 @@ set_kernel_version()
KERNEL_VERSION=$1
}
-# Used in feature scripts
-# - convenience wrapper for "git merge"
-# - arguments are git merge and are passed directly to git
-merge()
-{
-args="$@"
-
-# call the git wrapper function. Currently with no modification or
-# checking on the args, but the option of checking in the future is
-# trivial once users have converted.
-git merge $args
-}
-
# used in feature scripts
# - encodes a generic git command
git()
diff --git a/tools/scc-cmds/merge.cmd b/tools/scc-cmds/merge.cmd
new file mode 100644
index 000..02be6ca
--- /dev/null
+++ b/tools/scc-cmds/merge.cmd
@@ -0,0 +1,10 @@
+# used in feature scripts
+#arg1: the branch name
+merge()
+{
+local text
+local mbranch_name=$1
+
+text="merge: ${mbranch_name}"
+eval echo "\$text" $outfile_append
+}
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] More new messages
On 25 January 2017 at 08:53, Gary Thomas wrote: > WARNING: libsndfile1-1.0.27-r0 do_package: Manifest > /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot > not found? > FWIW I see these too, for intel-corei7-64. Note how its looking for allarch when they clearly are not, alsa-lib is TUNE_ARCH. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with building out-of-tree modules in morty
Hi, Thank you Raj. what was missing in linux-xlnx rev (tag xilinx-v2016.1.01) was --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -43,6 +43,7 @@ CHECKFLAGS+= -D__aarch64__ ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) KBUILD_CFLAGS_MODULE += -mcmodel=large +KBUILD_CFLAGS_MODULE += $(call cc-option, -mpc-relative-literal-loads) endif (summary) Linux kernel 4.4.x , aarch64 , gcc 6 , CONFIG_ARM64_ERRATUM_843419=y , out-of-tree kernel modules , modprobe error unsupported RELA relocation: 275 solution: https://github.com/torvalds/linux/commit/ 67dfa1751ce71e629aad7c438e1678ad41054677 Best regards, Bogusz Brodzinski On Tue, Jan 24, 2017 at 8:22 PM, Khem Raj wrote: > > > On 1/24/17 7:16 AM, Bogusz Brodziński wrote: > > Hi, > > > > TL;DR after migrating from jethro to morty my out-of-tree modules do not > > load. > > > > Long version: > > Im developing uio driver for a custom FPGA. The base is xilinx zu15 > > (note: as the explanation will go on I *think* it will be clear that > > this is not related to meta-xilinx). > > It's basically a debug interface that generates IRQ-like events on files > > (poll) for newly developed/tested features. The initial structure was > > poky jethro, meta-xilinx with linux-xlnx 4.4 for aarch64. The module is > > basically uio driver, but creates individual uio for each signal. The > > makefile is straight from > > https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html and the > > recipee inherits from module. > > When using jethro the module got built out-of-tree with no problem and I > > could load it. After migrating to morty (I also bumped meta-xilinx rev, > > but I use the same kernel SRCREV and project layer) I still can build > > the module, but when loading it I get: > > > > $ modprobe uio_pdrv_testirq > > [ 79.059558] module uio_pdrv_testirq: unsupported RELA relocation: 275 > > modprobe: can't load module uio_pdrv_testirq > > (testirq/uio_pdrv_testirq.ko): invalid module format > > > > $ modinfo uio_pdrv_testirq > > filename: testirq/uio_pdrv_testirq.ko > > license:GPL v2 > > author: BB > > description:Userspace I/O test driver irq handler > > depends: > > vermagic: 4.4.0-xilinx SMP preempt mod_unload modversions aarch64 > > > > I looked for a solution and found this > > http://lists.infradead.org/pipermail/linux-arm-kernel/ > 2015-October/375429.html > > thread > > I checked that I have all the ERRATUM enabled (with emphasys on > > ARM64_ERRATUM_843419): > > CONFIG_ARM64_ERRATUM_826319=y > > CONFIG_ARM64_ERRATUM_827319=y > > CONFIG_ARM64_ERRATUM_824069=y > > CONFIG_ARM64_ERRATUM_819472=y > > CONFIG_ARM64_ERRATUM_832075=y > > CONFIG_ARM64_ERRATUM_845719=y > > CONFIG_ARM64_ERRATUM_843419=y > > > > and I added > > CFLAGS_MODULE += -mcmodel=large > > > > Result: no change; testirq still fails to load. > > > > I would be grateful for any suggestions where to look or what to do next. > > > > Backport > > https://github.com/torvalds/linux/commit/df057cc7b4fa59e9b55f07ffdb6c62 > bf02e99a00 > > https://github.com/torvalds/linux/commit/67dfa1751ce71e629aad7c438e1678 > ad41054677 > > To your kernel. Additionally you also can have gcc fix > > https://github.com/kraj/gcc/commit/947be775c188312ff802d9f63dbdcc > d017cb4a29 > > hopefully these will help > > > Best regards, > > Bogusz Brodzinski > > > > > > > -- > ___ > 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][PATCH 1/5] raspberrypi-cm.conf: Add dummy machine for CM1 (alias for RPi1)
On Fri, Jan 20, 2017 at 7:16 PM, Andrei Gherzan wrote:
> Signed-off-by: Andrei Gherzan
> ---
> conf/machine/raspberrypi-cm.conf | 6 ++
> 1 file changed, 6 insertions(+)
> create mode 100644 conf/machine/raspberrypi-cm.conf
>
> diff --git a/conf/machine/raspberrypi-cm.conf
> b/conf/machine/raspberrypi-cm.conf
> new file mode 100644
> index 000..2da7d50
> --- /dev/null
> +++ b/conf/machine/raspberrypi-cm.conf
> @@ -0,0 +1,6 @@
> +#@TYPE: Machine
> +#@NAME: RaspberryPi Compute Module (CM1)
> +#@DESCRIPTION: Machine configuration for the RaspberryPi Compute Module (CM1)
> +
> +MACHINEOVERRIDES = "raspberrypi:${MACHINE}"
> +include conf/machine/raspberrypi.conf
> --
> 2.7.4
>
Merged the entire patch set in master.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] u-boot: drop backported patches
On Tue, Jan 24, 2017 at 07:32:04PM +0100, Mirza Krak wrote:
> From: Mirza Krak
>
> U-boot has been updated to 2017.01 in poky/oe-core which contains these
> patches.
>
> Signed-off-by: Mirza Krak
> ---
> ...0001-arm-add-save_boot_params-for-ARM1176.patch | 56
> ...through-of-the-firmware-provided-FDT-blob.patch | 156
> -
> recipes-bsp/u-boot/u-boot_%.bbappend | 5 -
> 3 files changed, 217 deletions(-)
> delete mode 100644
> recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
> delete mode 100644
> recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>
> diff --git
> a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
> b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
> deleted file mode 100644
> index a5ebff5..000
> --- a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
> +++ /dev/null
> @@ -1,56 +0,0 @@
> -From 3e10fcde3f3c24a488866dd33fa3f5d46ff3d7a3 Mon Sep 17 00:00:00 2001
> -From: =?UTF-8?q?C=C3=A9dric=20Schieli?=
> -Date: Fri, 11 Nov 2016 11:59:06 +0100
> -Subject: [PATCH] arm: add save_boot_params for ARM1176
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -Implement a hook to allow boards to save boot-time CPU state for later
> -use. When U-Boot is chain-loaded by another bootloader, CPU registers may
> -contain useful information such as system configuration information. This
> -feature mirrors the equivalent ARMv7 feature.
> -
> -Signed-off-by: Cédric Schieli
> -Acked-by: Stephen Warren
> -Signed-off-by: Paul Barker
> -Upstream-status: Backport
>
> - arch/arm/cpu/arm1176/start.S | 10 ++
> - 1 file changed, 10 insertions(+)
> -
> -diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
> -index a602d4e..7c00201 100644
> a/arch/arm/cpu/arm1176/start.S
> -+++ b/arch/arm/cpu/arm1176/start.S
> -@@ -16,6 +16,7 @@
> -
> - #include
> - #include
> -+#include
> -
> - #ifndef CONFIG_SYS_PHY_UBOOT_BASE
> - #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE
> -@@ -37,6 +38,11 @@
> - .globl reset
> -
> - reset:
> -+/* Allow the board to save important registers */
> -+b save_boot_params
> -+.globl save_boot_params_ret
> -+save_boot_params_ret:
> -+
> - /*
> - * set the cpu to SVC32 mode
> - */
> -@@ -110,3 +116,7 @@ mmu_disable_phys:
> - c_runtime_cpu_setup:
> -
> - mov pc, lr
> -+
> -+WEAK(save_boot_params)
> -+b save_boot_params_ret/* back to my caller */
> -+ENDPROC(save_boot_params)
> ---
> -2.1.4
> -
> diff --git
> a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>
> b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
> deleted file mode 100644
> index 323b7ab..000
> ---
> a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
> +++ /dev/null
> @@ -1,156 +0,0 @@
> -From ade243a211d62327e9ebadce27bbbff7981e37f0 Mon Sep 17 00:00:00 2001
> -From: =?UTF-8?q?C=C3=A9dric=20Schieli?=
> -Date: Fri, 11 Nov 2016 11:59:07 +0100
> -Subject: [PATCH] rpi: passthrough of the firmware provided FDT blob
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
> -but this is not true anymore. The address now depends on both the
> -memory size and the blob size [1].
> -
> -If one wants to passthrough this FDT blob to the kernel, the most
> -reliable way is to save its address from the r2/x0 register in the
> -U-Boot entry point and expose it in a environment variable for
> -further processing.
> -
> -This patch just does this:
> -- save the provided address in the global variable fw_dtb_pointer
> -- expose it in ${fdt_addr} if it points to a a valid FDT blob
> -
> -There are many different ways to use it. One can, for example, use
> -the following script which will extract from the tree the command
> -line built by the firmware, then hand over the blob to a previously
> -loaded kernel:
> -
> -fdt addr ${fdt_addr}
> -fdt get value bootargs /chosen bootargs
> -bootz ${kernel_addr_r} - ${fdt_addr}
> -
> -Alternatively, users relying on sysboot/pxe can simply omit any FDT
> -statement in their extlinux.conf file, U-Boot will automagically pick
> -${fdt_addr} and pass it to the kernel.
> -
> -[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
> -
> -Upstream-Status: Backport
> -
> -Signed-off-by: Cédric Schieli
> -Acked-by: Stephen Warren
> -Signed-off-by: Jonathan Liu
>
> - board/raspberrypi/rpi/Makefile| 1 +
> - board/raspberrypi/rpi/lowlevel_init.S | 36
> +++
> - board/raspberrypi/rpi/rpi.c | 29
> - 3 files changed, 66 insertions(+)
> - crea
[yocto] How to setup syslog by using an own filterfile and log policy configuration?
Hej I like to configure syslog. It seems that are more than one way to set up syslog. I am asking for the comon way/steps to do that. I have several use cases. To simplify I like to ask how to configure syslog to write an infinity long log file in /var/log/. Following steps: 1.) configure what messages 1.1) create own "syslog.conf" (define /var/log/myLog) 1.2) append it to "recipes-core/busybox" 2.) configure how to log ?? I found two possible places to do that: @meta-poky -> "meta-poky/recipes-core/busybox/busybox/poky-tiny/defconfig" ### # # System Logging Utilities # CONFIG_SYSLOGD=y CONFIG_FEATURE_ROTATE_LOGFILE=y CONFIG_FEATURE_REMOTE_LOG=y CONFIG_FEATURE_SYSLOGD_DUP=y CONFIG_FEATURE_SYSLOGD_CFG=y CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256 CONFIG_FEATURE_IPC_SYSLOG=y CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16 CONFIG_LOGREAD=y CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y CONFIG_KLOGD=y CONFIG_FEATURE_KLOGD_KLOGCTL=y CONFIG_LOGGER=y ### >> add/change "CONFIG_FEATURE_ROTATE_LOGFILE=n" by adding that line to meta-mylayer/conf/layer.conf" etc. ??? @ "/etc/syslog-startup.conf" ### # This configuration file is used by the busybox syslog init script, # /etc/init.d/syslog[.busybox] to set syslog configuration at start time. DESTINATION=file# log destinations (buffer file remote) LOGFILE=/var/log/messages # where to log (file) REMOTE=loghost:514 # where to log (syslog remote) REDUCE=no # reduce-size logging DROPDUPLICATES=no # whether to drop duplicate log entries #ROTATESIZE=0 # rotate log if grown beyond X [kByte] #ROTATEGENS=3 # keep X generations of rotated logs BUFFERSIZE=64 # size of circular buffer [kByte] FOREGROUND=no # run in foreground (don't use!) #LOGLEVEL=5 # local log level (between 1 and 8) ### In the systemV init script "/etc/init.d/syslog.bussybox" the file "/etc/syslog-startup.con" is read and used for configuration. System behaviour: When running my system, the log wraps when the logfile reaches 200kBytes. One logfile + one log-rotate file is generated. Any ideas how to archive that syslog writes an infinite long log-file? I am working on the Yocto krogoth branch + meta-atmel / meta_openembedded (@ krogoth too). Best regards, Stefan ESA Elektroschaltanlagen Grimma GmbH Broner Ring 30 04668 Grimma Telefon: +49 3437 9211 181 Telefax: +49 3437 9211 26 E-Mail: s.jar...@esa-grimma.de Internet: www.esa-grimma.de Geschäftsführer: Dipl.-Ing. Jörg Gaitzsch Jörg Reinker Sitz der Gesellschaft: Grimma Ust.-ID: DE 141784437 Amtsgericht: Leipzig, HRB 5159 Steuernummer: 238/108/00755 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][morty][PATCH V2] Revert "u-boot: drop patch to include lowlevel_init"
On Tue, Jan 24, 2017 at 07:16:38PM +0100, Mirza Krak wrote:
> From: Mirza Krak
>
> Not applicable on U-boot 2016.03 which is used in poky/morty and causes an
> build
> error when KERNEL_IMAGETYPE = "uImage".
>
> This reverts commit 031e26954b95d49a66ea4677b9e867d08441f450.
>
> [Issue #43]
>
> Signed-off-by: Mirza Krak
> ---
>
> Changes in V2:
> - Fixed spelling and improved commit message
>
> .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25
> ++
> recipes-bsp/u-boot/u-boot_%.bbappend | 1 +
> 2 files changed, 26 insertions(+)
> create mode 100644
> recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
>
> diff --git
> a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
> b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
> new file mode 100644
> index 000..ce0273f
> --- /dev/null
> +++ b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
> @@ -0,0 +1,25 @@
> +From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
> +From: Paul Barker
> +Date: Tue, 29 Nov 2016 19:47:49 +
> +Subject: [PATCH] Include lowlevel_init.o for rpi2
> +
> +Signed-off-by: Paul Barker
> +Upstream-status: Inappropriate
> +(not needed upstream as rpi_2 board directory is removed in latest
> +version)
> +---
> + board/raspberrypi/rpi_2/Makefile | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/board/raspberrypi/rpi_2/Makefile
> b/board/raspberrypi/rpi_2/Makefile
> +index d82cd21..9f865c5 100644
> +--- a/board/raspberrypi/rpi_2/Makefile
> b/board/raspberrypi/rpi_2/Makefile
> +@@ -5,3 +5,4 @@
> + #
> +
> + obj-y := ../rpi/rpi.o
> ++obj-y += ../rpi/lowlevel_init.o
> +--
> +2.1.4
> +
> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
> b/recipes-bsp/u-boot/u-boot_%.bbappend
> index 0edc8dc..a4545f0 100644
> --- a/recipes-bsp/u-boot/u-boot_%.bbappend
> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend
> @@ -3,4 +3,5 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
> SRC_URI_append_rpi = " \
> file://0001-arm-add-save_boot_params-for-ARM1176.patch \
> file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
> +file://0003-Include-lowlevel_init.o-for-rpi2.patch \
> "
> --
> 2.1.4
>
Merged to morty. Thank you.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Ordering of anonymous Python functions and task signature calculations
On Wed, Jan 25, 2017 at 3:03 AM, André Draszik wrote: > On Tue, 2017-01-24 at 11:55 -0600, Matt Hoosier wrote: > > In order to support a use-case that embeds information about the Git > > revision of Yocto itself that was used to make a build, I would like to > > run > > some arbitrary Python code and dump the results (Git SHA1's, tag names, > > etc) into a Bitbake variable. > > Have you looked at image-buildinfo.bbclass? From your description, it seems > to do what you want. > > INHERIT += "image-buildinfo" > > works well for me... > Yes, that's close. I have a few extra bits of information from Git that I'd like to include, but the basic approach you and Khem pointed out to do this during image construction works well enough. Thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Morty branch?
Hello Mark, the meta-mingw morty branch was created a few moments ago. Please have a look. Thanks Juro > -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: Wednesday, January 11, 2017 9:57 AM > To: Yocto Project > Cc: Bystricky, Juro > Subject: [meta-mingw] Morty branch? > > I don't see any specific Morty branch available for meta-mingw. Also many > of > the patches that were in progress have not been integrated to the master > branch > either. > > I've posted the Wind River version of meta-mingw for use with Morty based > products to: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ > > git://git.yoctoproject.org/meta-mingw-contrib > > The 'mgh/morty' branch. > > --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-kernel-tools][PATCH 0/1] Rework merge of feature branches
On Wed, Jan 25, 2017 at 5:37 AM, David Vincent wrote: > I've recently noticed that, on Morty, feature branches of a Yocto kernel > are not > merged anymore. This is due to the fact that the meta-series file does not > process the git merge commands anymore. > Indeed. I dropped that functionality on purpose when I did the simplification and streamlining of the processing .. since I wanted to see if anyone was using it. I now have my answer :D I need to have a closer look at the patch and run it through some tests here, but on my glance, you've done it correctly. > This commit creates a new merge command to be executed when processing the > kernel metadata. To solve the issue, there is also a patch to send to > oe-core > for kernel-yocto.bbclass, but I wait for this patch to be included since > there > is no point without it. > Send that patch to me, or I'll just do the patch myself .. since yes, we do need to add merge to the list of valid comments when processing the meta data. I'll submit all the changes in my next consolidated pull request for the kernels + tools. Bruce > > David Vincent (1): > scc: Move merge command > > tools/kgit-meta | 14 ++ > tools/scc| 13 - > tools/scc-cmds/merge.cmd | 10 ++ > 3 files changed, 24 insertions(+), 13 deletions(-) > create mode 100644 tools/scc-cmds/merge.cmd > > -- > 2.11.0 > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Morty branch?
On 1/25/17 9:29 AM, Bystricky, Juro wrote: > Hello Mark, > the meta-mingw morty branch was created a few moments ago. > Please have a look. Great. This seems to be the stuff that was working for me. One comment if anyone else comes on this in the future. The LTO commit. It's not completely clearly to me if this is actually needed or if there is a problem somewhere else (binutils perhaps). At some point, someone with a bit more knowledge of mingw/windows and gcc/binutils probably should take a look at it -- if the LTO stuff is desired. --Mark > Thanks > > Juro > > >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: Wednesday, January 11, 2017 9:57 AM >> To: Yocto Project >> Cc: Bystricky, Juro >> Subject: [meta-mingw] Morty branch? >> >> I don't see any specific Morty branch available for meta-mingw. Also many >> of >> the patches that were in progress have not been integrated to the master >> branch >> either. >> >> I've posted the Wind River version of meta-mingw for use with Morty based >> products to: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ >> >> git://git.yoctoproject.org/meta-mingw-contrib >> >> The 'mgh/morty' branch. >> >> --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Morty branch?
The LTO patch is needed, see for example: https://lists.yoctoproject.org/pipermail/yocto/2016-October/032490.html The SDK builds without it just fine, but the error pops up while running under Windows Juro From: Mark Hatle [mark.ha...@windriver.com] Sent: Wednesday, January 25, 2017 10:46 AM To: Bystricky, Juro; Yocto Project Subject: Re: [meta-mingw] Morty branch? On 1/25/17 9:29 AM, Bystricky, Juro wrote: > Hello Mark, > the meta-mingw morty branch was created a few moments ago. > Please have a look. Great. This seems to be the stuff that was working for me. One comment if anyone else comes on this in the future. The LTO commit. It's not completely clearly to me if this is actually needed or if there is a problem somewhere else (binutils perhaps). At some point, someone with a bit more knowledge of mingw/windows and gcc/binutils probably should take a look at it -- if the LTO stuff is desired. --Mark > Thanks > > Juro > > >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: Wednesday, January 11, 2017 9:57 AM >> To: Yocto Project >> Cc: Bystricky, Juro >> Subject: [meta-mingw] Morty branch? >> >> I don't see any specific Morty branch available for meta-mingw. Also many >> of >> the patches that were in progress have not been integrated to the master >> branch >> either. >> >> I've posted the Wind River version of meta-mingw for use with Morty based >> products to: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ >> >> git://git.yoctoproject.org/meta-mingw-contrib >> >> The 'mgh/morty' branch. >> >> --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Morty branch?
On 1/25/17 11:15 AM, Bystricky, Juro wrote: > The LTO patch is needed, see for example: > https://lists.yoctoproject.org/pipermail/yocto/2016-October/032490.html > > The SDK builds without it just fine, but the error pops up while running > under Windows My suspicion is that binutils is missing an --enable-lto or something like that on mingw. But I haven't had the time to investigate further, and I'm not sure if I have the knowledge one way or the other to verify it's really working... (beyond simple testing on a Windows machine.) --Mark > Juro > > From: Mark Hatle [mark.ha...@windriver.com] > Sent: Wednesday, January 25, 2017 10:46 AM > To: Bystricky, Juro; Yocto Project > Subject: Re: [meta-mingw] Morty branch? > > On 1/25/17 9:29 AM, Bystricky, Juro wrote: >> Hello Mark, >> the meta-mingw morty branch was created a few moments ago. >> Please have a look. > > Great. This seems to be the stuff that was working for me. > > One comment if anyone else comes on this in the future. The LTO commit. It's > not completely clearly to me if this is actually needed or if there is a > problem > somewhere else (binutils perhaps). > > At some point, someone with a bit more knowledge of mingw/windows and > gcc/binutils probably should take a look at it -- if the LTO stuff is desired. > > --Mark > >> Thanks >> >> Juro >> >> >>> -Original Message- >>> From: Mark Hatle [mailto:mark.ha...@windriver.com] >>> Sent: Wednesday, January 11, 2017 9:57 AM >>> To: Yocto Project >>> Cc: Bystricky, Juro >>> Subject: [meta-mingw] Morty branch? >>> >>> I don't see any specific Morty branch available for meta-mingw. Also many >>> of >>> the patches that were in progress have not been integrated to the master >>> branch >>> either. >>> >>> I've posted the Wind River version of meta-mingw for use with Morty based >>> products to: >>> >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ >>> >>> git://git.yoctoproject.org/meta-mingw-contrib >>> >>> The 'mgh/morty' branch. >>> >>> --Mark > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] DISTRO_FEATURES vs IMAGE_FEATURES
On 01/24/2017 06:40 PM, Takashi Matsuzawa wrote: Hello Yocto. Though it may feel to me matter of taste, is there suggestion on when which of these to use when you need to define your customized feature. DISTRO_FEATURES seems to be more relaxed, you can define things in your distro conf. IMAGE_FEATURE seems to be more strict, and you need to add your item also as one of the 'validitems', unless you use it through FEATURE_PACKAGES. (Or this is not needed when you use EXTRA_IMAGE_FEATURES?) I've always understood DISTRO_FEATURES to be policy related items about the distro you're creating (e.g. "my distro uses systemd for init", or "my distro uses sysvinit for init", or "my distro support openGL"). Because they are more about policy, DISTRO_FEATURES aren't as tied to a specific image. IMAGE_FEATURES are more about the attributes of a particular image (e.g. "include debugging tools like GDB and strace when you build this image"). The two have always been orthogonal in my mind. I suppose it would come down to what the features is. If you think your new feature is more of a policy based thing, it probably belongs in DISTRO_FEATURES. If it is more about controlling something about a specific image, than IMAGE_FEATURES is probably more appropriate. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
