[yocto] [PATCH] iucode-tool: add a service file (systemd)
From: Changqing Li
Add a service file (systemd), so that the microcode can be uploaded
automatically
Signed-off-by: Changqing Li
---
recipes-core/microcode/iucode-tool/iucode-tool.service | 11 +++
recipes-core/microcode/iucode-tool_2.3.1.bb| 17 +++--
2 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 recipes-core/microcode/iucode-tool/iucode-tool.service
diff --git a/recipes-core/microcode/iucode-tool/iucode-tool.service
b/recipes-core/microcode/iucode-tool/iucode-tool.service
new file mode 100644
index 000..6b134c3
--- /dev/null
+++ b/recipes-core/microcode/iucode-tool/iucode-tool.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=Apply Cpu Microcode
+
+[Service]
+Type=oneshot
+KillMode=process
+RemainAfterExit=yes
+ExecStart=@SBINDIR@/iucode_tool -k @LIB@/firmware/intel-ucode/microcode.bin
+
+[Install]
+WantedBy=multi-user.target
diff --git a/recipes-core/microcode/iucode-tool_2.3.1.bb
b/recipes-core/microcode/iucode-tool_2.3.1.bb
index df74a8e..1762468 100644
--- a/recipes-core/microcode/iucode-tool_2.3.1.bb
+++ b/recipes-core/microcode/iucode-tool_2.3.1.bb
@@ -18,16 +18,29 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
DEPENDS_append_libc-musl = " argp-standalone"
-SRC_URI =
"https://gitlab.com/iucode-tool/releases/raw/master/iucode-tool_${PV}.tar.xz;
+SRC_URI =
"https://gitlab.com/iucode-tool/releases/raw/master/iucode-tool_${PV}.tar.xz \
+ file://iucode-tool.service \
+ "
SRC_URI_append_libc-musl = "
file://0001-Makefile.am-Add-arg-parse-library-for-MUSL-support.patch"
SRC_URI[md5sum] = "63b33cc0ea1f8c73b443412abbf39d6f"
SRC_URI[sha256sum] =
"12b88efa4d0d95af08db05a50b3dcb217c0eb2bfc67b483779e33d498ddb2f95"
-inherit autotools
+inherit autotools systemd
BBCLASSEXTEND = "native"
COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
UPSTREAM_CHECK_URI = "https://gitlab.com/iucode-tool/releases;
+
+
+SYSTEMD_SERVICE_${PN} = "iucode-tool.service"
+SYSTEMD_AUTO_ENABLE_${PN} = "enable"
+
+do_install_append() {
+ install -d ${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/iucode-tool.service
${D}${systemd_unitdir}/system
+ sed -i -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_unitdir}/system/iucode-tool.service
+ sed -i -e 's,@LIB@,${base_libdir},g'
${D}${systemd_unitdir}/system/iucode-tool.service
+}
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Recipe reporting system] Upgradable recipe name list
This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade at this time, they can fill RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable" You can check the detail information at: http://recipes.yoctoproject.org/ Package Version Upstream version Maintainer NoUpgradeReason --- --- -- libgloss 3.0.03.0.0.20180226Alejandro Hernandez newlib3.0.03.0.0.20180226Alejandro Hernandez usbutils 009 010 Alexander Kanavin librepo 1.8.11.9.0 Alexander Kanavin gdbm 1.14.1 1.16 Alexander Kanavin vala 0.40.4 0.40.7Alexander Kanavin createrepo-c 0.10.0+gitX 0.11.0Alexander Kanavin dnf 2.7.53.0.3 Alexander Kanavin libyaml 0.1.70.2.1 Alexander Kanavin meson 0.46.1 0.47.1Alexander Kanavin ffmpeg4.0 4.0.1 Alexander Kanavin icu 61.1 62.1 Alexander Kanavin gptfdisk 1.0.31.0.4 Alexander Kanavin btrfs-tools 4.16.1 4.17 Alexander Kanavin babeltrace1.5.51.5.6 Alexander Kanavin sysprof 3.26.1 3.28.1Alexander Kanavin Waiting for resolution of h... cantarell-fonts 0.0.24 0.0.25Alexander Kanavin libdnf0.11.1 0.15.2Alexander Kanavin epiphany 3.28.1.1 3.28.3.1 Alexander Kanavin ca-certificates 20170717 20180409 Alexander Kanavin busybox 1.27.2 1.29.1Andrej Valek apt 1.2.24 1.6.3 Aníbal Limón apt-native1.2.24 1.6.3 Aníbal Limón dpkg 1.18.24 1.19.0.5 Aníbal Limón libva-utils 2.1.02.2.0 Anuj Mittal libva 2.1.02.2.0 Anuj Mittal gst-examples 0.0.1+gitX 0.0.1-new-commits... Anuj Mittal bind 9.11.3 9.13.2Armin Kuster xf86-video-fbdev 0.4.40.5.0 Armin Kuster curl 7.60.0 7.61.0Armin Kuster xf86-input-libinput 0.27.1 0.28.0Armin Kuster xserver-xorg 1.19.6 1.20.0Armin Kuster linux-libc-headers4.15.7 4.17.6Bruce Ashfield connman 1.35 1.36 Changhyeok Bae iptables 1.6.21.8.0 Changhyeok Bae iputils s20161105s20180629 Changhyeok Bae pciutils 3.5.63.6.1 Chen Qi acl 2.2.52 2.2.53Chen Qi attr 2.4.47 2.4.48Chen Qi systemd-boot 237 239 Chen Qi cups 2.2.62.2.8 Chen Qi systemd 237 239 Chen Qi bison 3.0.43.0.5 Chen Qi sed 4.2.24.5 Chen Qi shadow4.2.14.6 Chen Qi sysstat 11.7.3 11.7.4Chen Qi flex 2.6.02.6.4 Chen Qi coreutils 8.29 8.30 Chen Qi weston4.0.04.0.91Denys Dmytriyenko wayland 1.15.0 1.15.91 Denys Dmytriyenko lzop 1.03 1.04 Denys Dmytriyenko xz5.2.35.2.4 Denys Dmytriyenko python3 3.5.53.7.0 Derek Straka python3-git 2.1.10 2.1.11Derek Straka python3-gitdb 2.0.32.0.4 Derek Straka python3-pycairo 1.15.6 1.17.1Derek Straka python3-native3.5.53.7.0 Derek Straka acpica
[yocto] openssl
Hello, I’m looking to change to openssl version 1.1. I’m using the rocko branch. I have set PREFERRED_VERSION_openssl to 1.1%… but it doesn’t seem to work. Anyone? NOTE: Resolving any missing task queue dependencies NOTE: preferred version 1.1.% of openssl not available (for item openssl10) NOTE: versions of openssl available: 1.0.2m NOTE: preferred version 1.1.% of openssl not available (for item openssl-misc) NOTE: versions of openssl available: 1.0.2m NOTE: preferred version 1.1.% of openssl not available (for item openssl-conf) NOTE: versions of openssl available: 1.0.2m NOTE: preferred version 1.1.% of openssl not available (for item libcrypto) NOTE: versions of openssl available: 1.0.2m-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to debug unbuildable module error?
Is there a way to get bitbake to provide more information about why a module is unbuildable? I am trying to build this example: poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb However, bitbake always reports: "Runtime target 'hello-mod' is unbuildable, removing..." The makefile and source file are trivial with no dependencies and the -v verbose option adds no information at all. Thanks, Clay <>-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Regarding build Yocto offline
Greetings, Initially I was able to built with github access, but our requirement is to build offline(without Internet), I followed the steps given in https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F I added following lines in conf/local.conf (Git enabled machine) SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" and copied download directory to network disabled system and added following in conf/local.conf(network disabled system). SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" BB_NO_NETWORK = "1" It was throwing error, saying that "Network is disabled through BB_NO_NETWORK=1" and build was failed. Please share me the exact procedure to build yocto offline. Thanks & Regards, Karthik S The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to split rootfs image?
Dear All, Because of some formal reasons, we would like to split our rootfs image into 2 parts: 1. base system - to be reused between different project variants, typical rootfs content. 2. application/data - less critical application, configuration, data, logs. How to generate in Yocto application/data image(2)? It is about generation of empty image containing only requested packages, like Package-A, Package-B... We tried following: inherit image IMAGE_FEATURES = "" DISTRO_FEATURES = "" IMAGE_INSTALL = " \ Package-A \ Package-B \ " IMAGE_FSTYPES = "ubi tar.gz" But it produces classical rootfs image with (unwanted): bin, boot, etc, lib... We'd prefer to have it built in an efficient way, so we'd like to avoid generating full image and then removing files by hand in postprocess command. Thank you in advance, Lukasz *** The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information. *** -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] runtime: Add support to manual BSP test cases
TestID was determined from testopia,
https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=9635.
Regards,
Alim Hussin
-Original Message-
From: akuster808 [mailto:akuster...@gmail.com]
Sent: Friday, July 13, 2018 10:52 PM
To: Hussin, Mohamad Noor Alim ;
yocto@yoctoproject.org; richard.pur...@linuxfoundation.org
Subject: Re: [yocto] [PATCH] runtime: Add support to manual BSP test cases
On 07/13/2018 05:08 AM, mohamad.noor.alim.hus...@intel.com wrote:
> From: Mohamad Noor Alim Hussin
>
> This is manual BSP test cases that have converted to auto test cases
> for QA release. Manualbsp.py has dependency on file bsphardware that
> run on hardware.
How do the TestID get determined?
Also, I think this patch needs to be cc'd to
"openembedded-c...@lists.openembedded.org"
>
> Signed-off-by: Mohamad Noor Alim Hussin
>
> ---
> meta/lib/oeqa/runtime/cases/manualbsp.py | 122
> meta/lib/oeqa/runtime/files/bsphardware
> | 132 +++
> 2 files changed, 254 insertions(+)
> create mode 100644 meta/lib/oeqa/runtime/cases/manualbsp.py
> create mode 100755 meta/lib/oeqa/runtime/files/bsphardware
>
> diff --git a/meta/lib/oeqa/runtime/cases/manualbsp.py
> b/meta/lib/oeqa/runtime/cases/manualbsp.py
> new file mode 100644
> index 000..22d0d33
> --- /dev/null
> +++ b/meta/lib/oeqa/runtime/cases/manualbsp.py
> @@ -0,0 +1,122 @@
> +from oeqa.runtime.case import OERuntimeTestCase from
> +oeqa.core.decorator.depends import OETestDepends from
> +oeqa.core.decorator.oeid import OETestID import subprocess import
> +time
> +
> +class BspRuntimeTest(OERuntimeTestCase):
> +
> +@OETestID(240)
> +def test_check_bash(self):
> +status, output = self.target.run('which bash')
> +msg = ('bash shell not working as expected. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(228)
> +def test_runlevel_5(self):
> +status, output = self.target.run('init 5')
> +msg = ('System unable to init 5 '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 255, msg = msg)
> +time.sleep(2)
> +command = 'bsphardware -r 5'
> +status, output = self.target.run(command)
> +msg = ('System did not start from runlevel 5. '
> +'Status:%s.' % (status))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(198)
> +def test_runlevel_3(self):
> +status, output = self.target.run('init 3')
> +msg = ('System unable to start with runlevel 3. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 255, msg = msg)
> +time.sleep(2)
> +command = 'bsphardware -r 3'
> +status, output = self.target.run(command)
> +msg = ('Unable to change from runlevel 5 to 3. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +class BspHardwareTest(OERuntimeTestCase):
> +
> +@classmethod
> +def setUpClass(cls):
> +src = os.path.join(cls.tc.runtime_files_dir, 'bsphardware')
> +cls.tc.target.run('mkdir ~/test')
> +cls.tc.target.copyTo(src, '/usr/bin')
> +
> +@classmethod
> +def tearDownClass(cls):
> +cls.tc.target.run('rm -rf ~/test')
> +
> +@OETestID(216)
> +def test_USB_mount(self):
> +command = 'bsphardware -d sd -sp 1 -m ~/test/stick'
> +status, output = self.target.run(command)
> +msg = ('Unable to mount USB stick. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(217)
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_write_file'])
> +def test_USB_read_file(self):
> +command = 'cat ~/test/stick/hello_stick'
> +status, output = self.target.run(command)
> +msg = ('Unable to read file from USB stick. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_mount'])
> +@OETestID(219)
> +def test_USB_write_file(self):
> +command = 'touch ~/test/stick/hello_stick'
> +status, output = self.target.run(command)
> +msg = ('Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_mount'])
> +@OETestID(218)
> +def test_USB_unmount(self):
> +command = 'bsphardware -u ~/test/stick'
> +status, output = self.target.run(command)
> +msg = ('Unable to unmount USB stick. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +
Re: [yocto] Why can diffsigs take sometimes really looooong?
On Fri, 2018-07-13 at 19:18 +0300, Uwe Geuder wrote: > At times I find the diffsigs command useful/educational to understand > what is going on in my build. > > $ bitbake-diffsigs -t myimage do_image > > Often the result is shown in no time. However, recently I got some > cases were it takes 150 (!) minutes to show a simple difference (1 > line > changed in do_install of systemd). > > In comparision building after that change (with sstate) takes some 10 > minutes. And building everything from scratch (no sstate) takes just > a > bit over 50 minutes on the same machine. > > Of course the build can make good use of my 8 cores / 16 threads, > whereas diffsigs seems to run in only 1 core. Still, shouldn't every > build calculate all the dependencies, so running diffsigs should only > be > a small fraction of that work? > > Is there a natural explanation why diffsigs can sometimes be so slow? > Just curious to understand what is going on there. > > I am on Rocko 2.4.3 if that makes a difference. Is your sstate directory on something slow like NFS? Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
