Date   

[meta-swupdate][PATCH] mtd-utils: Remove patchs

zhengruoqin
 

files/0001-libubigen-remove-unnecessary-include.patch
files/0002-libubi-remove-private-kernel-header-from-includes.patch
Removed since these are included in 2.1.2.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@cn.fujitsu.com>/
---
...libubigen-remove-unnecessary-include.patch | 29 ----------
...-private-kernel-header-from-includes.patch | 58 -------------------
recipes-devtools/mtd/mtd-utils_%.bbappend | 5 --
3 files changed, 92 deletions(-)
delete mode 100644 recipes-devtools/mtd/files/0001-libubigen-remove-unnecessary-include.patch
delete mode 100644 recipes-devtools/mtd/files/0002-libubi-remove-private-kernel-header-from-includes.patch

diff --git a/recipes-devtools/mtd/files/0001-libubigen-remove-unnecessary-include.patch b/recipes-devtools/mtd/files/0001-libubigen-remove-unnecessary-include.patch
deleted file mode 100644
index 61e1380..0000000
--- a/recipes-devtools/mtd/files/0001-libubigen-remove-unnecessary-include.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 87809c4804d3355ecd2fd0bd3362526fa27bf953 Mon Sep 17 00:00:00 2001
-From: Bastian Germann <bastiangermann@fishpost.de>
-Date: Wed, 29 Jan 2020 19:50:12 +0100
-Subject: [PATCH 1/2] libubigen: remove unnecessary include
-
-libubigen.h does not use any symbol from mtd/ubi-media.h,
-so remove it from includes.
-
-Signed-off-by: Bastian Germann <bastiangermann@fishpost.de>
-Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
----
- include/libubigen.h | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/include/libubigen.h b/include/libubigen.h
-index c25ac20..48d2fad 100644
---- a/include/libubigen.h
-+++ b/include/libubigen.h
-@@ -26,7 +26,6 @@
- #define __LIBUBIGEN_H__
-
- #include <stdint.h>
--#include <mtd/ubi-media.h>
-
- #ifdef __cplusplus
- extern "C" {
---
-2.25.1
-
diff --git a/recipes-devtools/mtd/files/0002-libubi-remove-private-kernel-header-from-includes.patch b/recipes-devtools/mtd/files/0002-libubi-remove-private-kernel-header-from-includes.patch
deleted file mode 100644
index 7ca79b2..0000000
--- a/recipes-devtools/mtd/files/0002-libubi-remove-private-kernel-header-from-includes.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 42e051acd32c28c2f93c946d0c4bf6f9eada2aa4 Mon Sep 17 00:00:00 2001
-From: Bastian Germann <bastiangermann@fishpost.de>
-Date: Wed, 29 Jan 2020 19:50:13 +0100
-Subject: [PATCH 2/2] libubi: remove private kernel header from includes
-
-libubi.h includes ubi-media.h which was made private in the kernel a
-long time ago. There are users of libubi.h, e.g. swupdate, which have to
-have ubi-media.h available at build time with this inclusion.
-
-However, libubi.h uses only one symbol from ubi-media.h. Define that symbol
-in the header to enable using libubi.h without installing ubi-media.h.
-
-Make up for the transitive symbol use in ubiformat.c by including ubi-media.h.
-
-Signed-off-by: Bastian Germann <bastiangermann@fishpost.de>
-Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
----
- include/libubi.h | 4 +++-
- ubi-utils/ubiformat.c | 1 +
- 2 files changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/include/libubi.h b/include/libubi.h
-index 46596a3..46c732a 100644
---- a/include/libubi.h
-+++ b/include/libubi.h
-@@ -26,7 +26,6 @@
- #include <ctype.h>
- #include <stdint.h>
- #include <mtd/ubi-user.h>
--#include <mtd/ubi-media.h>
-
- #ifdef __cplusplus
- extern "C" {
-@@ -38,6 +37,9 @@ extern "C" {
- /* Maximum physical eraseblock size in bytes */
- #define UBI_MAX_PEB_SZ (2*1024*1024)
-
-+/* The maximum volume name length (from Linux's ubi-media.h) */
-+#define UBI_VOL_NAME_MAX 127
-+
- /* UBI library descriptor */
- typedef void * libubi_t;
-
-diff --git a/ubi-utils/ubiformat.c b/ubi-utils/ubiformat.c
-index be40e52..d1b12e4 100644
---- a/ubi-utils/ubiformat.c
-+++ b/ubi-utils/ubiformat.c
-@@ -38,6 +38,7 @@
- #include <getopt.h>
- #include <fcntl.h>
-
-+#include <mtd/ubi-media.h>
- #include <libubi.h>
- #include <libmtd.h>
- #include <libscan.h>
---
-2.25.1
-
diff --git a/recipes-devtools/mtd/mtd-utils_%.bbappend b/recipes-devtools/mtd/mtd-utils_%.bbappend
index 72cc858..471c8ad 100644
--- a/recipes-devtools/mtd/mtd-utils_%.bbappend
+++ b/recipes-devtools/mtd/mtd-utils_%.bbappend
@@ -2,11 +2,6 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

FILES_${PN}-staticdev += "ubi-utils/libubi.a ${libdir}/*.a"

-SRC_URI += " \
- file://0001-libubigen-remove-unnecessary-include.patch \
- file://0002-libubi-remove-private-kernel-header-from-includes.patch \
-"
-
do_install_append () {
install -d ${D}${includedir}/mtd/
install -d ${D}${libdir}/
--
2.25.1


Re: QA notification for completed autobuilder build (yocto-3.1.2.rc1)

Armin Kuster
 

On 7/28/20 11:22 PM, Jain, Sangeeta wrote:
Hi All,

This is the QA report for yocto-3.1.2.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
Is QA still having to perform the Manual test remotely?

-armin

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Friday, 24 July, 2020 3:58 PM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>;
steve@sakoman.com
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1.2.rc1)


A build flagged for QA (yocto-3.1.2.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.2.rc1


Build hash information:

bitbake: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57
meta-arm: 4812a66527e88ebdc5351d5dbd63765abe4abf62
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 77831443738885d33bfa3a738fe6c4f0361e4892
meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ea886d57db917a41a0d106a15e1e96c72d6407b0
poky: 569b1f5d67c57de957e243997c53ec2f81dc8dfe



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



[meta-security] Clamav libclammspack.so missing from image

yoc
 

Hi,

I am adding clamav to my custom image.

I have added the target clamav-libclamav to my image and libclamav.so is added, as expected, to /usr/lib but libclammspack.so is not added to /usr/lib

How to I make sure that libclammspack.so is include in the image?

I am using the meta-security layer on the dunfell branch.

Many Thanks,

Charlie


Re: QA notification for completed autobuilder build (yocto-3.1.2.rc1)

Sangeeta Jain
 

Hi All,

This is the QA report for yocto-3.1.2.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Friday, 24 July, 2020 3:58 PM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>;
steve@sakoman.com
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1.2.rc1)


A build flagged for QA (yocto-3.1.2.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.2.rc1


Build hash information:

bitbake: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57
meta-arm: 4812a66527e88ebdc5351d5dbd63765abe4abf62
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 77831443738885d33bfa3a738fe6c4f0361e4892
meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ea886d57db917a41a0d106a15e1e96c72d6407b0
poky: 569b1f5d67c57de957e243997c53ec2f81dc8dfe



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



dependencies packages on connman. #sdk

NIKHIL PATIL
 

Hi,
          1) How to find Dependencies packages on connman (connection manager) in yocto sdk ?
          2) If we uninstall connman then dependencies packages also need to install ?
          


OpenEmbedded Happy Hour July 29 9pm/2100 UTC

Denys Dmytriyenko
 

Just a reminder about our upcoming OpenEmbedded Happy Hour on July 29 for
Oceania/Asia timezones @ 2100/9pm UTC (5pm EDT):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+July+29&iso=20200729T21

--
Denys


Yocto Technical Team Minutes, Engineering Sync, for July 28 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for July 28 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Armin Kuster, Josef Holzmayr, Richard
Purdie, Trevor Gamblin, Joshua Watt, Mark Morton, Ross Burton, Bruce
Ashfield, Steve Sakoman, (phone-in ??), Jon Mason, Randy MacLeod, Scott
Murray, Denys Dmytriyenko

== notes ==
- fixed a race on AB wrt perl
- 3.1.2 into QA
- 3.2-m2 to QA once they’re done with 3.1.2

== general ==
RP: load of perl issues over the weekend, believe to have found issue
RP: lots of qemumips issues, not sure why, perhaps a timeouts issue? (no ping
within 30 seconds)
RP: some infrastructure issues (one worker has become corrupted)

RP: curious to know what people think about 3.1.2: there is a bitbake issue
with toaster, should we release then fix or wait for fix before release?
SS: maybe we should get feedback from people using toaster
RP: the fix is simple, maybe release 3.1.2 (with release note) then fix

RP: merged re-arrangement of package manager code, this puts more of our code
into python libraries instead of bbclass files, which is the direction i
want to take going forward
RP: i need to start a conversation on oe-architecture for future directions
RP: e.g. binary package feeds, we want to capture these use-cases into the
wiki

[NB: done! see https://wiki.yoctoproject.org/wiki/Future_Directions]

RP: we also posted the current agreement on “inclusive language” as agreed
on by various groups (oe board, oe-tsc, yp-tsc)

TW: what’s the thinking behind moving code to libraries vs bbclass?
RP: pro: parsing speed con: variable dependency tracking is lost
RP: lots of python code gets written to logs etc, which slows it down
JPEW: does bitbake automatically detect variable dependencies in library code?
RP: no. maybe we just need to do the scan once?
TW: do we lose flexibility? (e.g. it’s easy to copy+paste+modify a bbclass,
will that be possible?)
RP: there will still be all the same entry points, so it should be possible
RP: i’m worried about the size of the datastore in memory and it is a
bottleneck

RP: i wonder why qemumips is so slow?
Randy: i think Cisco are the only ones caring about mips
RP: yes, and Comcast too i think

MM: have been wrapped up in $WORK stuff, but will be working on docs
conversion soon
RP: MH has been putting infrastructure in place and Nico is looking forward to
getting this going
MM: do we want to try to reproduce our current colours/formatting or try
something new
RP: i like what we have, the project does have an existing scheme, but we can
change if something else makes sense

TW: i do lots of builds, never seen issues, why are there so many failures on
AB?
RP: do you do oe-selftest or testsdk builds?
TW: no
RP: do you do mips builds?
TW: no
RP: so these are the areas where we see these failures, “regular” builds
are okay
SS: i don’t see issues on my builds but that’s probably because of working
these issues out on the AB
RP: infrastructure issues are low, it’s mostly race issues that come out of
the extreme load of the AB or intermittent architecture issues that are
rarely tested


Re: [prelink-cross] prelink-cross: Add SPDX-License-Identifier: GPL-2.0-or-later to source files

Randy MacLeod
 

On 2020-07-21 10:14 a.m., Sathish V wrote:
Signed-off-by: Sathish V <sathish25071992@gmail.com>
---
gelf/gelf.c | 4 +++-
gelf/gelf.h | 4 +++-
gelfx/gelfx.h | 4 +++-n
...

Thanks Sathish!

Mark, did you miss this email?



--
# Randy MacLeod
# Wind River Linux


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Zoran
 

Hello Scott,

What I wanted to say here is that you do not change anything while
building a YOCTO load. You'll get all the components in:
.../tmp/deploy/images/$(PLATFORM) , namely:
XYZ,rootfs.cpio.zx
U-Boot
zImage
modules

But you can build a rt-kernel very conventionally, using out of YOCTO
classical kernel build.
[1] Download from the provider the normal kernel;
[2] Apply rt-patches to it (usually there is a script for it);
[3] make imx8_defconfig or whatever *_defconfig which suits to your platform;
[4] make menuconfig (for checking which CONFIG_ options are included,
and if you need something more/less, to adjust it;
[5] make
[6] sudo make modules_install

This is in nutshell, you might need to use cross compiling options,
like I do for BBB:
https://github.com/ZoranStojsavljevic/MikroE_BeagleBone-Black_BSP-Integration/blob/master/README.md

(please, find U-Boot and kernel classical building procedures in there)

The same for U-Boot, or even you can use YOCTO's U-Boot.

Then, if the whole system suits your requirements, you might go by
Bruce's advices (from his very last email).

Just an idea how to ease your initial pain...

Zoran
_______

On Tue, Jul 28, 2020 at 4:18 PM Scott Whitney <sdw@inea.com> wrote:

Hi Zoran,

Thank you for responding. I confess I am still new to building Linux with Yocto, so some of your steps may seem obvious, but are a bit confusing to a 'newbie'.

I am using normal Yocto instruction provided by Variscite to build our rootfs, U-Boot, and kernel. However, I am not doing anything special to build an rt-kernel, and that is what I am trying to find out how to do.

For example, after downloading and installing prerequisite executables, I initialize our repo (example is for Yocto Warrior, but similar for Yocto Zeus):

$ repo init -u https://github.com/varigit/variscite-bsp-platform.git -b fsl-warrior -m imx-4.19.35-1.1.0-var01.xml
$ repo sync -j4

Then I configure our machine, distro, and build directory:

$ cd ~/var-fsl-yocto
$ MACHINE=imx8mm-var-dart DISTRO=fsl-imx-xwayland . var-setup-release.sh -b build_xwayland

Then I am in the build_xwayland directory, and create our SD card image using:

$ bitbake fsl-image-qt5

The SD card image ends up in the build_xwayland/tmp/deploy/images directory, and I use the following to flash the SD card:

# For fsl-image-qt5 image (Qt5-XWAYLAND & Qt5-WAYLAND)
$ zcat tmp/deploy/images/imx8mm-var-dart/fsl-image-qt5-imx8mm-var-dart.sdcard.gz | sudo dd of=/dev/sdX bs=1M conv=fsync

What steps are you suggesting to configure rt-linux? I would appreciate it if you could be specific, since some of the steps involved are new to me.

I have already added a .bbappend file to modify the device tree for our application, and have run bitbake -c menuconfig virtual/kernel to update the kernel configuration.

Thanks for your assistance and tolerance for my inexperienced questions.

Scott D. Whitney

sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com

-----Original Message-----
From: Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com>
Sent: Tuesday, July 28, 2020 10:05 AM
To: Scott Whitney <sdw@inea.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>; yocto@yoctoproject.org
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

Hello Scott,

I have a bit of a different idea about the whole YOCTO process.

Let me suggest something else, actually a hybrid combination of the YOCTO build system.

You can do the whole process of YOCTO, but why do you not use components out of the YOCTO building process?

For example, you can use rootfs built by YOCTO, and U-Boot and rt-kernel built out of the YOCTO, for the beginning?

Then, as an option, if you are satisfied with the reached architecture, you can write your own recipe for the rt-kernel (you need to incorporate a bunch of patches into the rt-kernel proprietary recipe).

Zoran
_______


On Tue, Jul 28, 2020 at 2:45 PM Scott Whitney <sdw@inea.com> wrote:

Hi Bruce,



Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?



Thanks for your help



Scott D. Whitney

sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com



From: Bruce Ashfield <bruce.ashfield@gmail.com>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@inea.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?







On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@inea.com> wrote:

Hi Yocto group,



I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior.



I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”. Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?



Is there a specific configuration file that needs to be modified, or a new recipe in a layer? I am confused and hoping that you can help.



If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.



If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt and building.



Bruce







Best regards,



Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA 02090
sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com






--

- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Yocto Project Status WW30'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

 

Key Status/Updates:

  • This week a build race in perl was tracked down, the other issue of concern are the qemumips systemd (poky-altcfg) image testing failures (reasons unknown). You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated.

  • YP 3.1.2 has been built and is in QA. An issue with toaster and recent bitake changes may potentially impact the release.
  • YP 3.2 M2 will be built this week to follow YP 3.1.2 in QA.
  • One way to help the project is to help us with bugs that are currently unassigned but ideally needed during YP 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
  • Help with any of the recent failed AUH recipe upgrades would also be appreciated.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 is in QA
  • YP 3.1.3 build date 2020/9/14
  • YP 3.1.3 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Bruce Ashfield
 



On Tue, Jul 28, 2020 at 10:26 AM Scott Whitney <sdw@...> wrote:

Hi Bruce,

 

I believe the recipe for building Variscite’s kernel is in meta-variscite-imx/recipes-kernel/linux/linux-variscite_4.19.35.bb, which does produce a booting U-Boot and Linux image.  What would need to be modified to enable the rt-linux kernel?  The recipe is provided below.


At a high level, you need to get the appropriate preempt-rt patch from the -rt project, add it to the SRC_URI (via bbappend), fix the patch so that it applies to that kernel, build, and then debug and boot failures.

That's the trivialized version of the steps.

As for how to get the patch and apply it, it is just like any other package for patching, so you can lookup the details in the reference manuals and/or find other kernel recipe examples that are doing something similar. They will do a better job than I ever would explaining the steps here.

Cheers,

Bruce

 

 

# Copyright (C) 2013-2016 Freescale Semiconductor

# Copyright 2017 NXP

# Copyright 2018-2019 Variscite Ltd.

# Released under the MIT license (see COPYING.MIT for the terms)

 

SUMMARY = "Linux kernel provided and supported by Variscite"

DESCRIPTION = "Linux kernel provided and supported by Variscite (based on the kernel provided by NXP) \

with focus on i.MX Family SOMs. It includes support for many IPs such as GPU, VPU and IPU."

 

require recipes-kernel/linux/linux-imx.inc

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"

 

DEPENDS += "lzop-native bc-native"

 

DEFAULT_PREFERENCE = "1"

 

SRCBRANCH = "imx_4.19.35_1.1.0_var01"

 

LOCALVERSION_imx8mq-var-dart = "-imx8mq"

LOCALVERSION_imx8mm-var-dart = "-imx8mm"

LOCALVERSION_imx8mn-var-som = "-imx8mn"

LOCALVERSION_imx8qxp-var-som = "-imx8x"

LOCALVERSION_imx8qm-var-som = "-imx8qm"

 

KERNEL_DEFCONFIG = "${S}/arch/arm64/configs/imx8_var_defconfig"

DEFAULT_DTB_imx8mq-var-dart = "sd-lvds"

DEFAULT_DTB_imx8qxp-var-som = "sd"

DEFAULT_DTB_imx8qm-var-som = "lvds"

DEFAULT_DTB_PREFIX_imx8mq-var-dart = "fsl-imx8mq-var-dart"

DEFAULT_DTB_PREFIX_imx8qxp-var-som = "fsl-imx8qxp-var-som"

DEFAULT_DTB_PREFIX_imx8qm-var-som = "fsl-imx8qm-var-som"

 

KERNEL_SRC ?= "git://github.com/varigit/linux-imx;protocol=git"

SRC_URI = "${KERNEL_SRC};branch=${SRCBRANCH}"

SRCREV = "e6d3e3fefe4e85b5ee45beb7609b3c02bfe23efb"

 

S = "${WORKDIR}/git"

 

addtask copy_defconfig after do_patch before do_preconfigure

do_copy_defconfig () {

    cp ${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig

}

 

pkg_postinst_kernel-devicetree_append () {

   rm -f $D/boot/devicetree-*

}

 

pkg_postinst_kernel-devicetree_append_imx8mq-var-dart () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}-cb12.dtb ${DEFAULT_DTB_PREFIX}-cb12.dtb

}

 

pkg_postinst_kernel-devicetree_append_imx8qxp-var-som () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

}

 

pkg_postinst_kernel-devicetree_append_imx8qm-var-som () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

    ln -s fsl-imx8qm-var-spear-${DEFAULT_DTB}.dtb fsl-imx8qm-var-spear.dtb

}

 

COMPATIBLE_MACHINE = "(mx8)"

EXTRA_OEMAKE_append_mx8 = " ARCH=arm64"

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Tuesday, July 28, 2020 10:18 AM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Tue, Jul 28, 2020 at 8:45 AM Scott Whitney <sdw@...> wrote:

Hi Bruce,

 

Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?

 

 

This is one of the nuances about OE/Yocto, it isn't about building the kernel with yocto, I was wondering about the kernel recipe you are using.

 

If you have a booting kernel built from linux-yocto (the recipe), then the switch to -rt is easy. If it isn't using linux-yocto, then using -rt is specific to the kernel provider that you have (and it may be just as easy as the linux-yocto switch ... just without the details of that recipe/provider, I can't say).

 

The preferred provider is likely set in the vendor's BSP layer, and it likely points at whatever vendor kernel they are currently shipping.

 

Cheers,

 

Bruce

 

 

Thanks for your help

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@...> wrote:

Hi Yocto group,

 

I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior. 

 

I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”.  Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?

 

Is there a specific configuration file that needs to be modified, or a new recipe in a layer?  I am confused and hoping that you can help.

 

If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.

 

If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt  and building.

 

Bruce

 

 

 

Best regards,

 

Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA  02090
sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Scott Whitney <sdw@...>
 

Hi Bruce,

 

I believe the recipe for building Variscite’s kernel is in meta-variscite-imx/recipes-kernel/linux/linux-variscite_4.19.35.bb, which does produce a booting U-Boot and Linux image.  What would need to be modified to enable the rt-linux kernel?  The recipe is provided below.

 

# Copyright (C) 2013-2016 Freescale Semiconductor

# Copyright 2017 NXP

# Copyright 2018-2019 Variscite Ltd.

# Released under the MIT license (see COPYING.MIT for the terms)

 

SUMMARY = "Linux kernel provided and supported by Variscite"

DESCRIPTION = "Linux kernel provided and supported by Variscite (based on the kernel provided by NXP) \

with focus on i.MX Family SOMs. It includes support for many IPs such as GPU, VPU and IPU."

 

require recipes-kernel/linux/linux-imx.inc

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"

 

DEPENDS += "lzop-native bc-native"

 

DEFAULT_PREFERENCE = "1"

 

SRCBRANCH = "imx_4.19.35_1.1.0_var01"

 

LOCALVERSION_imx8mq-var-dart = "-imx8mq"

LOCALVERSION_imx8mm-var-dart = "-imx8mm"

LOCALVERSION_imx8mn-var-som = "-imx8mn"

LOCALVERSION_imx8qxp-var-som = "-imx8x"

LOCALVERSION_imx8qm-var-som = "-imx8qm"

 

KERNEL_DEFCONFIG = "${S}/arch/arm64/configs/imx8_var_defconfig"

DEFAULT_DTB_imx8mq-var-dart = "sd-lvds"

DEFAULT_DTB_imx8qxp-var-som = "sd"

DEFAULT_DTB_imx8qm-var-som = "lvds"

DEFAULT_DTB_PREFIX_imx8mq-var-dart = "fsl-imx8mq-var-dart"

DEFAULT_DTB_PREFIX_imx8qxp-var-som = "fsl-imx8qxp-var-som"

DEFAULT_DTB_PREFIX_imx8qm-var-som = "fsl-imx8qm-var-som"

 

KERNEL_SRC ?= "git://github.com/varigit/linux-imx;protocol=git"

SRC_URI = "${KERNEL_SRC};branch=${SRCBRANCH}"

SRCREV = "e6d3e3fefe4e85b5ee45beb7609b3c02bfe23efb"

 

S = "${WORKDIR}/git"

 

addtask copy_defconfig after do_patch before do_preconfigure

do_copy_defconfig () {

    cp ${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig

}

 

pkg_postinst_kernel-devicetree_append () {

   rm -f $D/boot/devicetree-*

}

 

pkg_postinst_kernel-devicetree_append_imx8mq-var-dart () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}-cb12.dtb ${DEFAULT_DTB_PREFIX}-cb12.dtb

}

 

pkg_postinst_kernel-devicetree_append_imx8qxp-var-som () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

}

 

pkg_postinst_kernel-devicetree_append_imx8qm-var-som () {

    cd $D/boot

    ln -s ${DEFAULT_DTB_PREFIX}-${DEFAULT_DTB}.dtb ${DEFAULT_DTB_PREFIX}.dtb

    ln -s fsl-imx8qm-var-spear-${DEFAULT_DTB}.dtb fsl-imx8qm-var-spear.dtb

}

 

COMPATIBLE_MACHINE = "(mx8)"

EXTRA_OEMAKE_append_mx8 = " ARCH=arm64"

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Tuesday, July 28, 2020 10:18 AM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Tue, Jul 28, 2020 at 8:45 AM Scott Whitney <sdw@...> wrote:

Hi Bruce,

 

Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?

 

 

This is one of the nuances about OE/Yocto, it isn't about building the kernel with yocto, I was wondering about the kernel recipe you are using.

 

If you have a booting kernel built from linux-yocto (the recipe), then the switch to -rt is easy. If it isn't using linux-yocto, then using -rt is specific to the kernel provider that you have (and it may be just as easy as the linux-yocto switch ... just without the details of that recipe/provider, I can't say).

 

The preferred provider is likely set in the vendor's BSP layer, and it likely points at whatever vendor kernel they are currently shipping.

 

Cheers,

 

Bruce

 

 

Thanks for your help

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@...> wrote:

Hi Yocto group,

 

I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior. 

 

I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”.  Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?

 

Is there a specific configuration file that needs to be modified, or a new recipe in a layer?  I am confused and hoping that you can help.

 

If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.

 

If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt  and building.

 

Bruce

 

 

 

Best regards,

 

Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA  02090
sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Scott Whitney <sdw@...>
 

Hi Zoran,

Thank you for responding. I confess I am still new to building Linux with Yocto, so some of your steps may seem obvious, but are a bit confusing to a 'newbie'.

I am using normal Yocto instruction provided by Variscite to build our rootfs, U-Boot, and kernel. However, I am not doing anything special to build an rt-kernel, and that is what I am trying to find out how to do.

For example, after downloading and installing prerequisite executables, I initialize our repo (example is for Yocto Warrior, but similar for Yocto Zeus):

$ repo init -u https://github.com/varigit/variscite-bsp-platform.git -b fsl-warrior -m imx-4.19.35-1.1.0-var01.xml
$ repo sync -j4

Then I configure our machine, distro, and build directory:

$ cd ~/var-fsl-yocto
$ MACHINE=imx8mm-var-dart DISTRO=fsl-imx-xwayland . var-setup-release.sh -b build_xwayland

Then I am in the build_xwayland directory, and create our SD card image using:

$ bitbake fsl-image-qt5

The SD card image ends up in the build_xwayland/tmp/deploy/images directory, and I use the following to flash the SD card:

# For fsl-image-qt5 image (Qt5-XWAYLAND & Qt5-WAYLAND)
$ zcat tmp/deploy/images/imx8mm-var-dart/fsl-image-qt5-imx8mm-var-dart.sdcard.gz | sudo dd of=/dev/sdX bs=1M conv=fsync

What steps are you suggesting to configure rt-linux? I would appreciate it if you could be specific, since some of the steps involved are new to me.

I have already added a .bbappend file to modify the device tree for our application, and have run bitbake -c menuconfig virtual/kernel to update the kernel configuration.

Thanks for your assistance and tolerance for my inexperienced questions.

Scott D. Whitney

sdw@inea.com    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

-----Original Message-----
From: Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com>
Sent: Tuesday, July 28, 2020 10:05 AM
To: Scott Whitney <sdw@inea.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>; yocto@yoctoproject.org
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

Hello Scott,

I have a bit of a different idea about the whole YOCTO process.

Let me suggest something else, actually a hybrid combination of the YOCTO build system.

You can do the whole process of YOCTO, but why do you not use components out of the YOCTO building process?

For example, you can use rootfs built by YOCTO, and U-Boot and rt-kernel built out of the YOCTO, for the beginning?

Then, as an option, if you are satisfied with the reached architecture, you can write your own recipe for the rt-kernel (you need to incorporate a bunch of patches into the rt-kernel proprietary recipe).

Zoran
_______


On Tue, Jul 28, 2020 at 2:45 PM Scott Whitney <sdw@inea.com> wrote:

Hi Bruce,



Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?



Thanks for your help



Scott D. Whitney

sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com



From: Bruce Ashfield <bruce.ashfield@gmail.com>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@inea.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?







On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@inea.com> wrote:

Hi Yocto group,



I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior.



I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”. Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?



Is there a specific configuration file that needs to be modified, or a new recipe in a layer? I am confused and hoping that you can help.



If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.



If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt and building.



Bruce







Best regards,



Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA 02090
sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com






--

- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Bruce Ashfield
 



On Tue, Jul 28, 2020 at 8:45 AM Scott Whitney <sdw@...> wrote:

Hi Bruce,

 

Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?

 


This is one of the nuances about OE/Yocto, it isn't about building the kernel with yocto, I was wondering about the kernel recipe you are using.

If you have a booting kernel built from linux-yocto (the recipe), then the switch to -rt is easy. If it isn't using linux-yocto, then using -rt is specific to the kernel provider that you have (and it may be just as easy as the linux-yocto switch ... just without the details of that recipe/provider, I can't say).

The preferred provider is likely set in the vendor's BSP layer, and it likely points at whatever vendor kernel they are currently shipping.

Cheers,

Bruce

 

Thanks for your help

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@...> wrote:

Hi Yocto group,

 

I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior. 

 

I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”.  Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?

 

Is there a specific configuration file that needs to be modified, or a new recipe in a layer?  I am confused and hoping that you can help.

 

If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.

 

If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt  and building.

 

Bruce

 

 

 

Best regards,

 

Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA  02090
sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Zoran
 

Hello Scott,

I have a bit of a different idea about the whole YOCTO process.

Let me suggest something else, actually a hybrid combination of the
YOCTO build system.

You can do the whole process of YOCTO, but why do you not use
components out of the YOCTO building process?

For example, you can use rootfs built by YOCTO, and U-Boot and
rt-kernel built out of the YOCTO, for the beginning?

Then, as an option, if you are satisfied with the reached
architecture, you can write your own recipe for the rt-kernel (you
need to incorporate a bunch of patches into the rt-kernel proprietary
recipe).

Zoran
_______

On Tue, Jul 28, 2020 at 2:45 PM Scott Whitney <sdw@inea.com> wrote:

Hi Bruce,



Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?



Thanks for your help



Scott D. Whitney

sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com



From: Bruce Ashfield <bruce.ashfield@gmail.com>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@inea.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?







On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@inea.com> wrote:

Hi Yocto group,



I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior.



I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”. Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?



Is there a specific configuration file that needs to be modified, or a new recipe in a layer? I am confused and hoping that you can help.



If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.



If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt and building.



Bruce







Best regards,



Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA 02090
sdw@inea.com | T: 781-801-1152 | F: 781-801-1108 | www.inea.com






--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: How to enable preempt-rt in Yocto Zeus or Warrior?

Scott Whitney <sdw@...>
 

Hi Bruce,

 

Yes, we are using Linux built by Yocto, but where is the preferred provider for the kernel set to linux-yocto-rt?

 

Thanks for your help

 

Scott D. Whitney

sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 

From: Bruce Ashfield <bruce.ashfield@...>
Sent: Monday, July 27, 2020 10:04 PM
To: Scott Whitney <sdw@...>
Cc: yocto@...
Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

 

 

 

On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney <sdw@...> wrote:

Hi Yocto group,

 

I’m working with a newly-released copy of Yocto Zeus from Variscite for the i.MX8MM Mini, although the same option seems to apply to the previous Yocto Warrior. 

 

I understand that a Linux real-time kernel can be enabled by setting LINUX_KERNEL_TYPE = “preempt-rt”.  Where does this option need to be set so that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel instead of the “standard” kernel?

 

Is there a specific configuration file that needs to be modified, or a new recipe in a layer?  I am confused and hoping that you can help.

 

If you aren't using linux-yocto, you'll need to arrange for the preempt-rt patch(es) to be applied to whatever kernel you are using. Which means you are creating a new recipe, bbappending an existing one, or if you are lucky the kernel provider already has a -rt recipe available.

 

If you are using linux-yocto, it's as simple as setting the preferred provider of the kernel as linux-yocto-rt  and building.

 

Bruce

 

 

 

Best regards,

 

Scott D. Whitney

Principal Software Engineer


Intertech Engineering Associates, Inc.
100 Lowder Brook Drive, Suite 2500
Westwood, MA  02090
sdw@...    |     T: 781-801-1152    |     F: 781-801-1108    |     www.inea.com

 


 

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Remove connman package from yocto sdk.

Josef Holzmayr
 

Howdy!

(re-adding the ML)

Am Di., 28. Juli 2020 um 12:10 Uhr schrieb NIKHIL PATIL <nikhilvp29@gmail.com>:

Hi
1) connman is default package, so by default it is coming with sato image.
Nope. It is not the default. Maybe the sato image pulls it in, but if
you don't like that then why do you use the sato image? Create your
own image recipe.

2) some packages are depends on connection manager.
Create your own image recipe and include the connection manager that
you like. If you install something that has an explicit dependency on
connman, then you probably have to remove that too.

3) In our own own image recipe how we can remove connection manager package ?
Why would one have to remove something that is not there? Again, now
really for the last time:

"Create your own image recipe and add only the things that you want".

There is even a neat demonstration on how to do that online:
https://youtu.be/nqHylLP2NmA

Greetz


Building extensible SDK

Kjeld Flarup
 

The eSDK looks interesting, but the documentation does not say anything about how to build it.
Am I missing something about how to obtain the eSDK?


Regards
Kjeld Flarup
DEIF R&D - Platform Software



________________________________________
From: Khem Raj <raj.khem@gmail.com>
Sent: Friday, July 10, 2020 02:38
To: Kjeld Flarup; yocto@lists.yoctoproject.org
Subject: Re: [yocto] Add application with library to target

On 7/8/20 2:37 AM, Kjeld Flarup via lists.yoctoproject.org wrote:
I have a functioning Yocto build today, but two of the recipes are
optional. An application and a library.
I would like to split my build in two.

One that contains the basic system with kernel rootfs etc.
A second that just contains the application and the library

If I just had the application, it would be simple just to use the SDK
and generate the application.
But when adding the library, things starts to be more complex.

I would also like to use my existing recipe with dependencies etc.

What is the best approach

* Can this be done with the ADT?
* Can a layer solve it
* Do I need to do it all manually with the SDK
I think eSDK might be good fit for your usecase.

https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-extensible

--
Regards
Kjeld Flarup
DEIF A/S



[meta-selinux][PATCH 1/2] selinux-*.bb: fix typos

Yi Zhao
 

Fixes:
${PN}_RDEPENDS -> RDEPENDS_${PN}

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/selinux/selinux-autorelabel_0.1.bb | 2 +-
recipes-security/selinux/selinux-init_0.1.bb | 2 +-
recipes-security/selinux/selinux-labeldev_0.1.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-security/selinux/selinux-autorelabel_0.1.bb b/recipes-security/selinux/selinux-autorelabel_0.1.bb
index b898c3b..85b0db9 100644
--- a/recipes-security/selinux/selinux-autorelabel_0.1.bb
+++ b/recipes-security/selinux/selinux-autorelabel_0.1.bb
@@ -7,7 +7,7 @@ file is present.\
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-${PN}_RDEPENDS = " \
+RDEPENDS_${PN} = " \
policycoreutils-setfiles \
"

diff --git a/recipes-security/selinux/selinux-init_0.1.bb b/recipes-security/selinux/selinux-init_0.1.bb
index 78f571c..ebe7399 100644
--- a/recipes-security/selinux/selinux-init_0.1.bb
+++ b/recipes-security/selinux/selinux-init_0.1.bb
@@ -7,7 +7,7 @@ boot time. \
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-${PN}_RDEPENDS = " \
+RDEPENDS_${PN} = " \
coreutils \
libselinux-bin \
policycoreutils-secon \
diff --git a/recipes-security/selinux/selinux-labeldev_0.1.bb b/recipes-security/selinux/selinux-labeldev_0.1.bb
index 8eb5db4..2a0bca9 100644
--- a/recipes-security/selinux/selinux-labeldev_0.1.bb
+++ b/recipes-security/selinux/selinux-labeldev_0.1.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "Set SELinux labels for /dev."
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-${PN}_RDEPENDS = " \
+RDEPENDS_${PN} = " \
coreutils \
libselinux-bin \
policycoreutils-setfiles \
--
2.17.1


[meta-selinux][PATCH 2/2] net-tools: drop patch

Yi Zhao
 

The netstat-selinux-support.patch has been merged upstream. So drop it.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
.../files/netstat-selinux-support.patch | 244 ------------------
.../net-tools/net-tools_selinux.inc | 4 -
2 files changed, 248 deletions(-)
delete mode 100644 recipes-extended/net-tools/files/netstat-selinux-support.patch

diff --git a/recipes-extended/net-tools/files/netstat-selinux-support.patch b/recipes-extended/net-tools/files/netstat-selinux-support.patch
deleted file mode 100644
index f089041..0000000
--- a/recipes-extended/net-tools/files/netstat-selinux-support.patch
+++ /dev/null
@@ -1,244 +0,0 @@
-From: Xin Ouyang <Xin.Ouyang@windriver.com>
-Date: Wed, 13 Jun 2012 13:32:01 +0800
-Subject: [PATCH] net-tools: netstat add SELinux support.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Xin Ouyang <Xin.Ouyang@windriver.com>
-Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
----
- Makefile | 9 ++++++++-
- netstat.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
- 2 files changed, 74 insertions(+), 4 deletions(-)
-
-diff --git a/Makefile b/Makefile
-index 8fcc55c..0b5c395 100644
---- a/Makefile
-+++ b/Makefile
-@@ -116,6 +116,13 @@ NET_LIB = $(NET_LIB_PATH)/lib$(NET_LIB_NAME).a
- CFLAGS = $(COPTS) -I. -idirafter ./include/ -I$(NET_LIB_PATH)
- LDFLAGS = $(LOPTS) -L$(NET_LIB_PATH)
-
-+ifeq ($(HAVE_SELINUX),1)
-+SELINUX_LDFLAGS = -lselinux
-+CFLAGS += -DHAVE_SELINUX
-+else
-+SELINUX_LDFLAGS =
-+endif
-+
- SUBDIRS = man/ $(NET_LIB_PATH)/
-
- ifeq ($(origin CC), undefined)
-@@ -209,7 +216,7 @@ plipconfig: $(NET_LIB) plipconfig.o
- $(CC) $(LDFLAGS) -o plipconfig plipconfig.o $(NLIB)
-
- netstat: $(NET_LIB) netstat.o statistics.o
-- $(CC) $(LDFLAGS) -o netstat netstat.o statistics.o $(NLIB) $(RESLIB)
-+ $(CC) $(SELINUX_LDFLAGS) $(LDFLAGS) -o netstat netstat.o statistics.o $(NLIB) $(RESLIB)
-
- iptunnel: $(NET_LIB) iptunnel.o
- $(CC) $(LDFLAGS) -o iptunnel iptunnel.o $(NLIB) $(RESLIB)
-diff --git a/netstat.c b/netstat.c
-index fc10414..a773e81 100644
---- a/netstat.c
-+++ b/netstat.c
-@@ -90,6 +90,12 @@
- #include <sys/types.h>
- #include <asm-generic/param.h>
-
-+#if HAVE_SELINUX
-+#include <selinux/selinux.h>
-+#else
-+#define security_context_t char*
-+#endif
-+
- #include "net-support.h"
- #include "pathnames.h"
- #include "version.h"
-@@ -101,6 +107,7 @@
- #include "proc.h"
-
- #define PROGNAME_WIDTH 20
-+#define SELINUX_WIDTH 50
-
- #if !defined(s6_addr32) && defined(in6a_words)
- #define s6_addr32 in6a_words /* libinet6 */
-@@ -180,6 +187,7 @@ int flag_wide= 0;
- int flag_prg = 0;
- int flag_arg = 0;
- int flag_ver = 0;
-+int flag_selinux = 0;
-
- FILE *procinfo;
-
-@@ -243,12 +251,17 @@ FILE *procinfo;
- #define PROGNAME_WIDTH1(s) PROGNAME_WIDTH2(s)
- #define PROGNAME_WIDTH2(s) #s
-
-+#define SELINUX_WIDTHs SELINUX_WIDTH1(SELINUX_WIDTH)
-+#define SELINUX_WIDTH1(s) SELINUX_WIDTH2(s)
-+#define SELINUX_WIDTH2(s) #s
-+
- #define PRG_HASH_SIZE 211
-
- static struct prg_node {
- struct prg_node *next;
- unsigned long inode;
- char name[PROGNAME_WIDTH];
-+ char scon[SELINUX_WIDTH];
- } *prg_hash[PRG_HASH_SIZE];
-
- static char prg_cache_loaded = 0;
-@@ -256,9 +269,12 @@ static char prg_cache_loaded = 0;
- #define PRG_HASHIT(x) ((x) % PRG_HASH_SIZE)
-
- #define PROGNAME_BANNER "PID/Program name"
-+#define SELINUX_BANNER "Security Context"
-
- #define print_progname_banner() do { if (flag_prg) printf("%-" PROGNAME_WIDTHs "s"," " PROGNAME_BANNER); } while (0)
-
-+#define print_selinux_banner() do { if (flag_selinux) printf("%-" SELINUX_WIDTHs "s"," " SELINUX_BANNER); } while (0)
-+
- #define PRG_LOCAL_ADDRESS "local_address"
- #define PRG_INODE "inode"
- #define PRG_SOCKET_PFX "socket:["
-@@ -280,7 +296,7 @@ static char prg_cache_loaded = 0;
- /* NOT working as of glibc-2.0.7: */
- #undef DIRENT_HAVE_D_TYPE_WORKS
-
--static void prg_cache_add(unsigned long inode, char *name)
-+static void prg_cache_add(unsigned long inode, char *name, char *scon)
- {
- unsigned hi = PRG_HASHIT(inode);
- struct prg_node **pnp,*pn;
-@@ -301,6 +317,14 @@ static void prg_cache_add(unsigned long inode, char *name)
- if (strlen(name)>sizeof(pn->name)-1)
- name[sizeof(pn->name)-1]='\0';
- strcpy(pn->name,name);
-+
-+ {
-+ int len=(strlen(scon)-sizeof(pn->scon))+1;
-+ if (len > 0)
-+ strcpy(pn->scon,&scon[len+1]);
-+ else
-+ strcpy(pn->scon,scon);
-+ }
- }
-
- static const char *prg_cache_get(unsigned long inode)
-@@ -313,6 +337,16 @@ static const char *prg_cache_get(unsigned long inode)
- return("-");
- }
-
-+static const char *prg_cache_get_con(unsigned long inode)
-+{
-+ unsigned hi=PRG_HASHIT(inode);
-+ struct prg_node *pn;
-+
-+ for (pn=prg_hash[hi];pn;pn=pn->next)
-+ if (pn->inode==inode) return(pn->scon);
-+ return("-");
-+}
-+
- static void prg_cache_clear(void)
- {
- struct prg_node **pnp,*pn;
-@@ -384,6 +418,7 @@ static void prg_cache_load(void)
- const char *cs,*cmdlp;
- DIR *dirproc=NULL,*dirfd=NULL;
- struct dirent *direproc,*direfd;
-+ security_context_t scon=NULL;
-
- if (prg_cache_loaded || !flag_prg) return;
- prg_cache_loaded=1;
-@@ -453,7 +488,15 @@ static void prg_cache_load(void)
- }
-
- snprintf(finbuf, sizeof(finbuf), "%s/%s", direproc->d_name, cmdlp);
-- prg_cache_add(inode, finbuf);
-+#if HAVE_SELINUX
-+ if (getpidcon(atoi(direproc->d_name), &scon) == -1) {
-+ scon=strdup("-");
-+ }
-+ prg_cache_add(inode, finbuf, scon);
-+ freecon(scon);
-+#else
-+ prg_cache_add(inode, finbuf, "-");
-+#endif
- }
- closedir(dirfd);
- dirfd = NULL;
-@@ -573,6 +616,8 @@ static void finish_this_one(int uid, unsigned long inode, const char *timers)
- }
- if (flag_prg)
- printf(" %-16s",prg_cache_get(inode));
-+ if (flag_selinux)
-+ printf("%-" SELINUX_WIDTHs "s",prg_cache_get_con(inode));
- if (flag_opt)
- printf(" %s", timers);
- putchar('\n');
-@@ -1566,6 +1611,8 @@ static void unix_do_one(int nr, const char *line)
- printf("- ");
- if (flag_prg)
- printf("%-" PROGNAME_WIDTHs "s",(has & HAS_INODE?prg_cache_get(inode):"-"));
-+ if (flag_selinux)
-+ printf("%-" SELINUX_WIDTHs "s",(has & HAS_INODE?prg_cache_get_con(inode):"-"));
- puts(path);
- }
-
-@@ -1584,6 +1631,7 @@ static int unix_info(void)
-
- printf(_("\nProto RefCnt Flags Type State I-Node "));
- print_progname_banner();
-+ print_selinux_banner();
- printf(_(" Path\n")); /* xxx */
-
- {
-@@ -1874,6 +1922,7 @@ static void usage(void)
- fprintf(stderr, _(" -o, --timers display timers\n"));
- fprintf(stderr, _(" -F, --fib display Forwarding Information Base (default)\n"));
- fprintf(stderr, _(" -C, --cache display routing cache instead of FIB\n\n"));
-+ fprintf(stderr, _(" -Z, --context display SELinux security context for sockets\n\n"));
-
- fprintf(stderr, _(" <Socket>={-t|--tcp} {-u|--udp} {-S|--sctp} {-w|--raw} {-x|--unix} --ax25 --ipx --netrom\n"));
- fprintf(stderr, _(" <AF>=Use '-6|-4' or '-A <af>' or '--<af>'; default: %s\n"), DFLT_AF);
-@@ -1920,6 +1969,7 @@ int main
- {"cache", 0, 0, 'C'},
- {"fib", 0, 0, 'F'},
- {"groups", 0, 0, 'g'},
-+ {"context", 0, 0, 'Z'},
- {NULL, 0, 0, 0}
- };
-
-@@ -1931,7 +1981,7 @@ int main
- getroute_init(); /* Set up AF routing support */
-
- afname[0] = '\0';
-- while ((i = getopt_long(argc, argv, "MCFA:acdegphinNorstuSWVv?wxl64", longopts, &lop)) != EOF)
-+ while ((i = getopt_long(argc, argv, "MCFA:acdegphinNorstuSWVv?wxlZ64", longopts, &lop)) != EOF)
- switch (i) {
- case -1:
- break;
-@@ -2036,6 +2086,19 @@ int main
- if (aftrans_opt("unix"))
- exit(1);
- break;
-+ case 'Z':
-+#if HAVE_SELINUX
-+ if (is_selinux_enabled() <= 0) {
-+ fprintf(stderr, _("SELinux is not enabled on this machine.\n"));
-+ exit(1);
-+ }
-+ flag_prg++;
-+ flag_selinux++;
-+#else
-+ fprintf(stderr, _("SELinux is not enabled for this application.\n"));
-+ exit(1);
-+#endif
-+ break;
- case '?':
- case 'h':
- usage();
---
-1.9.1
-
diff --git a/recipes-extended/net-tools/net-tools_selinux.inc b/recipes-extended/net-tools/net-tools_selinux.inc
index cc3196f..1bcf7be 100644
--- a/recipes-extended/net-tools/net-tools_selinux.inc
+++ b/recipes-extended/net-tools/net-tools_selinux.inc
@@ -1,7 +1,3 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
-
-SRC_URI += "file://netstat-selinux-support.patch"
-
inherit selinux

DEPENDS += "${LIBSELINUX}"
--
2.17.1

4161 - 4180 of 54276