Re: [yocto] gobject introspection needing pygobject (cross-compilation)
On 03/31/2017 09:06 AM, colin.helliw...@ln-systems.com wrote: I've got a few packages in my image which need gobject introspection. (x86-64 host, ARM target) One is building fine, but the other - NetworkManager - is failing to generate the introspection data because it can't analyse the cross-compiled library. Apparently it uses pygobject in doing this, and thus needs a version of that for the target architecture. Are there steps I can take to achieve this? I guess it needs some 'qemu' technique as with other the G-I support mechanisms? I guess you have read and understood the section in the Yocto manual dedicated to this? To provide useful help, I need to see specifics. What is the error message you are getting? Where are your recipes, and which one is failing? Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gobject introspection needing pygobject (cross-compilation)
On 31 March 2017 at 09:06, wrote: > I've got a few packages in my image which need gobject introspection. > (x86-64 host, ARM target) > One is building fine, but the other - NetworkManager - is failing to > generate the introspection data because it can't analyse the cross-compiled > library. Apparently it uses pygobject in doing this, and thus needs a > version of that for the target architecture. > Are there steps I can take to achieve this? I guess it needs some 'qemu' > technique as with other the G-I support mechanisms? > It's unlikely that python (or anything other than target versions of gi-ir-compiler/g-ir-scanner) is needed for generating introspection data. A quick look at configure.ac seems to imply it's actually trying to build some documentation with python using the generated GIR data... Maybe check if the pregenerated docs contain thes documentation bits and try to disable that docs generation as first solution? Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gobject introspection needing pygobject (cross-compilation)
> On 31 March 2017 at 08:26 Alexander Kanavin > wrote: > > On 03/31/2017 09:06 AM, colin.helliw...@ln-systems.com wrote: > > > I've got a few packages in my image which need gobject introspection. > > (x86-64 host, ARM target) > > One is building fine, but the other - NetworkManager - is failing to > > generate the introspection data because it can't analyse the cross-compiled > > library. Apparently it uses pygobject in doing this, and thus needs a > > version of that for the target architecture. > > Are there steps I can take to achieve this? I guess it needs some 'qemu' > > technique as with other the G-I support mechanisms? > > I guess you have read and understood the section in the Yocto manual > dedicated to this? > Project Dev Manual 5.7? Yep, have read that. In fact, I've been able to enable g-i on ModemManager, and on NetworkManager 1.4 - but there's something new about 1.6/1.8 that's throwing this problem. > To provide useful help, I need to see specifics. What is the error > message you are getting? Where are your recipes, and which one is failing? > Sure. I'll put together additional info. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] a couple bad(?) tags in poky checkout
just listed git tags for poky, and a couple that show up that screw up the ordering: ... yocot-1.4.2 <- yocto-1.4.1 yocto-1.4.2 ... yocto-2.1.2 yocto-2.2 yocto-2.2.1 yocto_1.5_M5.rc8 <- ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] busybox: make SYSLOGD optionnal
Some distros might choose another syslogd provider like rsyslogd.
update-alternative will update the link from syslogd to the right
provider. However the syslogd feature is still present and enabled
in busybox.
This commit adds a new configuration fragment to make syslogd
optionnal in busybox.
Signed-off-by: Romain Perier
---
meta/recipes-core/busybox/busybox.inc| 6 +++---
meta/recipes-core/busybox/busybox/defconfig | 20 +---
meta/recipes-core/busybox/busybox/syslog.cfg | 11 +++
meta/recipes-core/busybox/busybox_1.24.1.bb | 1 +
meta/recipes-core/busybox/busybox_git.bb | 1 +
5 files changed, 25 insertions(+), 14 deletions(-)
create mode 100644 meta/recipes-core/busybox/busybox/syslog.cfg
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index b2f1960..a60b7a9 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -40,7 +40,7 @@ INITSCRIPT_NAME_${PN}-syslog = "syslog"
INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd"
SYSTEMD_PACKAGES = "${PN}-syslog"
-SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
+SYSTEMD_SERVICE_${PN}-syslog = "${@bb.utils.contains('SRC_URI',
'file://syslog.cfg', 'busybox-syslog.service', '', d)}"
CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf.${BPN}"
CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
@@ -326,8 +326,8 @@ inherit update-alternatives
ALTERNATIVE_PRIORITY = "50"
-ALTERNATIVE_${PN}-syslog += "syslog-conf"
-ALTERNATIVE_LINK_NAME[syslog-conf] = "${sysconfdir}/syslog.conf"
+ALTERNATIVE_${PN}-syslog += "${@bb.utils.contains('SRC_URI',
'file://syslog.cfg', 'syslog-conf', '', d)}"
+ALTERNATIVE_LINK_NAME[syslog-conf] = "${@bb.utils.contains('SRC_URI',
'file://syslog.cfg', "${sysconfdir}/syslog.conf", '', d)}"
python () {
if bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
diff --git a/meta/recipes-core/busybox/busybox/defconfig
b/meta/recipes-core/busybox/busybox/defconfig
index c0459d5..387dcc0 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -1049,17 +1049,15 @@ CONFIG_FEATURE_SH_HISTFILESIZE=y
#
# 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=64
-CONFIG_LOGREAD=y
-CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
-CONFIG_FEATURE_KMSG_SYSLOG=y
+# CONFIG_SYSLOGD is not set
+# CONFIG_FEATURE_ROTATE_LOGFILE is not set
+# CONFIG_FEATURE_REMOTE_LOG is not set
+# CONFIG_FEATURE_SYSLOGD_DUP is not set
+# CONFIG_FEATURE_SYSLOGD_CFG is not set
+# CONFIG_FEATURE_IPC_SYSLOG is not set
+# CONFIG_LOGREAD is not set
+# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set
+# CONFIG_FEATURE_KMSG_SYSLOG is not set
CONFIG_KLOGD=y
#
diff --git a/meta/recipes-core/busybox/busybox/syslog.cfg
b/meta/recipes-core/busybox/busybox/syslog.cfg
new file mode 100644
index 000..e2425ed
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/syslog.cfg
@@ -0,0 +1,11 @@
+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=64
+CONFIG_LOGREAD=y
+CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
+CONFIG_FEATURE_KMSG_SYSLOG=y
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb
b/meta/recipes-core/busybox/busybox_1.24.1.bb
index df0e131..1b8a1a3 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -40,6 +40,7 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://resize.cfg \
${@["",
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager', True) ==
'busybox')]} \
${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager',
True) == 'busybox-mdev')]} \
+ file://syslog.cfg \
file://inittab \
file://rcS \
file://rcK \
diff --git a/meta/recipes-core/busybox/busybox_git.bb
b/meta/recipes-core/busybox/busybox_git.bb
index c29b894..f666517 100644
--- a/meta/recipes-core/busybox/busybox_git.bb
+++ b/meta/recipes-core/busybox/busybox_git.bb
@@ -42,6 +42,7 @@ SRC_URI = "git://busybox.net/busybox.git \
file://resize.cfg \
${@["",
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager', True) ==
'busybox')]} \
${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager',
True) == 'busybox-mdev')]} \
+ file://syslog.cfg \
file://inittab \
file://rcS \
file://rcK \
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https:/
[yocto] Missing dependencies on driver header
I have a niggly problem I keep running into, especially with fresh image
builds.
I have a custom driver, and a user-space library for controlling it;
therefore the library includes one of the driver's header files (IOCTL defs
etc).
However I can't get the dependencies correct in the library recipe so as to
get the driver's header installed and available to the library build step.
In other words 'bitbake MyDriverLib' gives a "MyDriver.h: no such file or
directory "
The lib's recipe includes
inherit autotools lib_package binconfig-disabled pkgconfig
DEPENDS_${PN} = "MyDriver"
RDEPENDS_${PN} = "MyDriver"
At 'some point later', the lib *will* build ok: I've done each MyDriver
step one by one, and it seems that once the 'install' has been done then
MyDriverLib will then compile. ('-c compile MyDriver' isn't sufficient). But
shouldn't the RDEPENDS above trigger the MyDriver install?
I'm obviously missing a dependency hook somewhere?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing dependencies on driver header
On Fri, 2017-03-31 at 14:42 +0100, colin.helliw...@ln-systems.com wrote:
> I have a niggly problem I keep running into, especially with fresh image
> builds.
> I have a custom driver, and a user-space library for controlling it;
> therefore the library includes one of the driver's header files (IOCTL defs
> etc).
> However I can't get the dependencies correct in the library recipe so as to
> get the driver's header installed and available to the library build step.
> In other words 'bitbake MyDriverLib' gives a "MyDriver.h: no such file or
> directory "
> The lib's recipe includes
> inherit autotools lib_package binconfig-disabled pkgconfig
> DEPENDS_${PN} = "MyDriver"
Usually I use "DEPENDS" and not "DEPENDS_${PN}".
Else does your kernel module recipe populate sysroot with the header?
> RDEPENDS_${PN} = "MyDriver"
>
> At 'some point later', the lib *will* build ok: I've done each MyDriver
> step one by one, and it seems that once the 'install' has been done then
> MyDriverLib will then compile. ('-c compile MyDriver' isn't sufficient). But
> shouldn't the RDEPENDS above trigger the MyDriver install?
> I'm obviously missing a dependency hook somewhere?
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GCC on ARM
On 3/30/17 10:33 PM, Gary Thomas wrote: > On 2017-03-31 07:07, Khem Raj wrote: >> >> >> On 3/30/17 9:07 PM, Gary Thomas wrote: >>> [slightly off-topic] >>> >>> I work with a number of embedded ARM devices, all with different >>> processors, hence somewhat different tuning and build directories: >>> Raspberry-Pi (1,2,3 - mostly 3): >>> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 >>> callconvention-hard cortexa7" >>> build dirs: >>> tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi >>> BeagleBoneBlack: >>> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" >>> build dirs: >>> tmp/work/armv7ahf-neon-poky-linux-gnueabi >>> i.MX6: >>> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard >>> cortexa9" >>> build dirs: >>> tmp/work/cortexa9hf-neon-poky-linux-gnueabi >>> tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi >>> tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi >>> >>> What I'm wondering is, except for the obvious programs that use SoC >>> specific >>> functions like the IPU/GPU on the i.MX6, how different are these >>> really? So >>> much so that they have to all have unique binaries? Surely I could >>> build >>> busybox or python and run the same binary on all three? >>> >> >> You can chose a least common denominator and use that as DEFAULTTUNE for >> all your machines. May be like armv7at2-neon > > That's good to know, thanks. > > What would I be giving up? Anything of substance/importance? > I doubt anything. Optimizations are oversell. signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH v3] parsemail.py: Improve find_series_for_mail
Patch Series that are sent as replies to other Series with
different patch quantity are not appropriately detected as
such, breaking the thread and causing missing revisions.
This change improves the find_series_for_mail function to
appropriately detect when a message is part of a thread
by performing an additional patch-query and detecting cover
letters that are replies to cover letters.
[YOCTO #10959]
Signed-off-by: Jose Lamego
---
Notes:
changes in v3: a couple of typos fixed
patchwork/bin/parsemail.py | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/patchwork/bin/parsemail.py b/patchwork/bin/parsemail.py
index 61c18b2..3c3046d 100755
--- a/patchwork/bin/parsemail.py
+++ b/patchwork/bin/parsemail.py
@@ -399,7 +399,7 @@ def find_content(project, mail):
(x, n) = parse_series_marker(prefixes)
refs = build_references_list(mail)
is_root = refs == []
-is_cover_letter = is_root and x == 0
+is_cover_letter = x == 0
patch_prefix = re.match('(\s*\[[^]]*\]\s*)*\[\s*PATCH',
mail.get('Subject'))
is_patch = patchbuf is not None and patch_prefix
@@ -441,7 +441,7 @@ def find_content(project, mail):
(ret.series, ret.revision, ret.patch_order, n) = \
find_series_for_mail(project, series_name, msgid, is_patch,
- ret.patch_order, n, refs)
+ ret.patch_order, n, refs, is_cover_letter)
ret.revision.n_patches = n or 1
date = mail_date(mail)
@@ -535,7 +535,7 @@ def find_patch_order(revisions, previous_patch, order,
n_patches):
# - we need to create new revisions when the mail is actually a new version
# of a previous patch
def find_series_for_mail(project, name, msgid, is_patch, order, n_patches,
- refs):
+ refs, is_cover_letter):
if refs == []:
root_msgid = msgid
else:
@@ -560,6 +560,20 @@ def find_series_for_mail(project, name, msgid, is_patch,
order, n_patches,
revision = revision.duplicate(exclude_patches=(order,))
# series has been updated, grab the new instance
series = revision.series
+else:
+try:
+prev_patch = SeriesRevisionPatch.objects.get(
+revision=revision, order=order).patch
+if prev_patch and not prev_patch.msgid == msgid:
+# this is a new patch in the thread
+revision = revision.duplicate(exclude_patches=(order,))
+series = revision.series
+except SeriesRevisionPatch.DoesNotExist:
+pass
+elif is_cover_letter and not refs == []:
+revision = revision.duplicate(
+exclude_patches=range(1, revision.n_patches+1),)
+series = revision.series
except IndexError:
if not name:
name = SERIES_DEFAULT_NAME
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/1] pitft: Add support for pitft35r
The support for the PiTFT 3.5 inch resistive touchscreen is optional.
It may be enabled by adding the following line in local.conf:
MACHINE_FEATURES += "pitft pitft35r"
Signed-off-by: Rob Woolley
---
README | 1 +
conf/machine/include/rpi-base.inc | 1 +
conf/machine/raspberrypi3-64.conf | 1 +
recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
4 files changed, 9 insertions(+)
diff --git a/README b/README
index 65a1e5f..a5c3d38 100644
--- a/README
+++ b/README
@@ -240,6 +240,7 @@ the modelname should be added as a MACHINE_FEATURES in
local.conf like below:
List of currently supported models:
- pitft22
- pitft28r
+- pitft35r
3.O. Enable UART
===
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index 092cbeb..9bcb91d 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -31,6 +31,7 @@ KERNEL_DEVICETREE ?= " \
overlays/lirc-rpi.dtbo \
overlays/pitft22.dtbo \
overlays/pitft28-resistive.dtbo \
+overlays/pitft35-resistive.dtbo \
overlays/pps-gpio.dtbo \
overlays/rpi-ft5406.dtbo \
overlays/w1-gpio.dtbo \
diff --git a/conf/machine/raspberrypi3-64.conf
b/conf/machine/raspberrypi3-64.conf
index ca10ed9..0efe3ff 100644
--- a/conf/machine/raspberrypi3-64.conf
+++ b/conf/machine/raspberrypi3-64.conf
@@ -23,6 +23,7 @@ KERNEL_DEVICETREE = " \
overlays/lirc-rpi.dtbo \
overlays/pitft22.dtbo \
overlays/pitft28-resistive.dtbo \
+overlays/pitft35-resistive.dtbo \
overlays/pps-gpio.dtbo \
overlays/rpi-ft5406.dtbo \
overlays/w1-gpio.dtbo \
diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 20ec343..0fd9cea 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -18,6 +18,7 @@ PR = "r5"
PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
PITFT22="${@bb.utils.contains("MACHINE_FEATURES", "pitft22", "1", "0", d)}"
PITFT28r="${@bb.utils.contains("MACHINE_FEATURES", "pitft28r", "1", "0", d)}"
+PITFT35r="${@bb.utils.contains("MACHINE_FEATURES", "pitft35r", "1", "0", d)}"
VC4GRAPHICS="${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "1", "0",
d)}"
@@ -99,6 +100,11 @@ do_deploy() {
echo
"dtoverlay=pitft28-resistive,rotate=90,speed=3200,txbuflen=32768"
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
fi
+if [ "${PITFT35r}" = "1" ]; then
+echo "# Enable PITFT35r display"
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "dtoverlay=pitft35-resistive,rotate=90,speed=4200,fps=20"
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+fi
+
# UART support
if [ "${ENABLE_UART}" = "1" ]; then
echo "# Enable UART" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GCC on ARM
On Thu, Mar 30, 2017 at 10:07 PM, Khem Raj wrote: > On 3/30/17 9:07 PM, Gary Thomas wrote: >> [slightly off-topic] >> >> I work with a number of embedded ARM devices, all with different >> processors, hence somewhat different tuning and build directories: >> Raspberry-Pi (1,2,3 - mostly 3): >> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 >> callconvention-hard cortexa7" >> build dirs: >> tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi >> BeagleBoneBlack: >> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" >> build dirs: >> tmp/work/armv7ahf-neon-poky-linux-gnueabi >> i.MX6: >> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard >> cortexa9" >> build dirs: >> tmp/work/cortexa9hf-neon-poky-linux-gnueabi >> tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi >> tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi >> >> What I'm wondering is, except for the obvious programs that use SoC >> specific >> functions like the IPU/GPU on the i.MX6, how different are these >> really? These tuning features refer to the CPU core only - not the rest of the SoC. Any differences in GPU etc are not relevant. >> So >> much so that they have to all have unique binaries? Surely I could build >> busybox or python and run the same binary on all three? CPU cores are generally backwards compatible. The Raspberry-Pi 3 (armv7ve) could run binaries created for the other two (armv7a), but not necessarily the other way around. e.g. armv7ve adds support for integer division in HW, which isn't supported by armv7a, so if busybox contains any integer division operations (which it almost certainly does) then a busybox binary built for Raspberry-Pi 3 would fail to run on the other two. > You can chose a least common denominator and use that as DEFAULTTUNE for > all your machines. May be like armv7at2-neon The common denominator for the examples above would include hardfloat, ie: DEFAULTTUNE = "armv7athf-neon" > > -- > ___ > 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/1] pitft: Add support for pitft35r
On 3/31/17 11:19 AM, Rob Woolley wrote:
> The support for the PiTFT 3.5 inch resistive touchscreen is optional.
> It may be enabled by adding the following line in local.conf:
>
> MACHINE_FEATURES += "pitft pitft35r"
>
Looks ok, I have staged it.
> Signed-off-by: Rob Woolley
> ---
> README | 1 +
> conf/machine/include/rpi-base.inc | 1 +
> conf/machine/raspberrypi3-64.conf | 1 +
> recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
> 4 files changed, 9 insertions(+)
>
> diff --git a/README b/README
> index 65a1e5f..a5c3d38 100644
> --- a/README
> +++ b/README
> @@ -240,6 +240,7 @@ the modelname should be added as a MACHINE_FEATURES in
> local.conf like below:
> List of currently supported models:
> - pitft22
> - pitft28r
> +- pitft35r
>
> 3.O. Enable UART
> ===
> diff --git a/conf/machine/include/rpi-base.inc
> b/conf/machine/include/rpi-base.inc
> index 092cbeb..9bcb91d 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -31,6 +31,7 @@ KERNEL_DEVICETREE ?= " \
> overlays/lirc-rpi.dtbo \
> overlays/pitft22.dtbo \
> overlays/pitft28-resistive.dtbo \
> +overlays/pitft35-resistive.dtbo \
> overlays/pps-gpio.dtbo \
> overlays/rpi-ft5406.dtbo \
> overlays/w1-gpio.dtbo \
> diff --git a/conf/machine/raspberrypi3-64.conf
> b/conf/machine/raspberrypi3-64.conf
> index ca10ed9..0efe3ff 100644
> --- a/conf/machine/raspberrypi3-64.conf
> +++ b/conf/machine/raspberrypi3-64.conf
> @@ -23,6 +23,7 @@ KERNEL_DEVICETREE = " \
> overlays/lirc-rpi.dtbo \
> overlays/pitft22.dtbo \
> overlays/pitft28-resistive.dtbo \
> +overlays/pitft35-resistive.dtbo \
> overlays/pps-gpio.dtbo \
> overlays/rpi-ft5406.dtbo \
> overlays/w1-gpio.dtbo \
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> index 20ec343..0fd9cea 100644
> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -18,6 +18,7 @@ PR = "r5"
> PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
> PITFT22="${@bb.utils.contains("MACHINE_FEATURES", "pitft22", "1", "0", d)}"
> PITFT28r="${@bb.utils.contains("MACHINE_FEATURES", "pitft28r", "1", "0", d)}"
> +PITFT35r="${@bb.utils.contains("MACHINE_FEATURES", "pitft35r", "1", "0", d)}"
>
> VC4GRAPHICS="${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "1",
> "0", d)}"
>
> @@ -99,6 +100,11 @@ do_deploy() {
> echo
> "dtoverlay=pitft28-resistive,rotate=90,speed=3200,txbuflen=32768"
> >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> fi
>
> +if [ "${PITFT35r}" = "1" ]; then
> +echo "# Enable PITFT35r display"
> >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +echo "dtoverlay=pitft35-resistive,rotate=90,speed=4200,fps=20"
> >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +fi
> +
> # UART support
> if [ "${ENABLE_UART}" = "1" ]; then
> echo "# Enable UART" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
>
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
