Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest
On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote:
> > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> > haven't tried that.
> >
> > Do you have a kirkstone patch that I can try on the autobuilder?
> >
>
> I'd still rather not go the ubuntu patch route. It is my last choice in the
> options.
>
> If this is caused by upstream commits, there should also be upstream
> commits that fix the issues. I need to identify those commits and
> document why they aren't appropriate for our 5.15 kernel before I pick
> up someone's else patch .. since at that point, I have no idea about their
> logic and other issues it may introduce.
Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and
the tweak in order to port to v5.15 also seems pretty reasonable. I generated
a patch based on the latest kirkstone branch. Steve, could you give the
attachment
a try?
Thanks,
Kevin
From dca6a0cec06a1688881d697bd255eff05b474c3e Mon Sep 17 00:00:00 2001
From: Kevin Hao
Date: Fri, 8 Mar 2024 22:31:26 +0800
Subject: [PATCH] linux-yocto: Don't merge: Fix the parted ptest failues
Signed-off-by: Kevin Hao
---
...-support-partitions-without-scanning.patch | 104 ++
meta/recipes-kernel/linux/linux-yocto_5.15.bb | 3 +-
2 files changed, 106 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
diff --git
a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
new file mode 100644
index ..f77b0e9eb00a
--- /dev/null
+++
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
@@ -0,0 +1,104 @@
+From 82fad6e9334f1239fe090def17ca947c89fc4308 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig
+Date: Fri, 27 May 2022 07:58:06 +0200
+Subject: [PATCH] block, loop: support partitions without scanning
+
+BugLink: https://bugs.launchpad.net/bugs/2056143
+
+Historically we did distinguish between a flag that surpressed partition
+scanning, and a combinations of the minors variable and another flag if
+any partitions were supported. This was generally confusing and doesn't
+make much sense, but some corner case uses of the loop driver actually
+do want to support manually added partitions on a device that does not
+actively scan for partitions. To make things worsee the loop driver
+also wants to dynamically toggle the scanning for partitions on a live
+gendisk, which makes the disk->flags updates non-atomic.
+
+Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
+just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
+in the loop driver.
+
+Upstream-Status: Backport [c3032b60ff7b3948325b8f2bd688b9a74be3cfb9]
+
+Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
+Reported-by: Ming Lei
+Signed-off-by: Christoph Hellwig
+Reviewed-by: Ming Lei
+Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
+Signed-off-by: Jens Axboe
+
+(backported from commit b9684a71fca793213378dd410cd11675d973eaa1)
+[smb: Flag and test for partition scan in genhd.h instead]
+Signed-off-by: Stefan Bader
+Acked-by: Roxana Nicolescu
+Acked-by: Manuel Diewald
+Signed-off-by: Stefan Bader
+---
+ drivers/block/loop.c | 8
+ include/linux/genhd.h | 3 +++
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/block/loop.c b/drivers/block/loop.c
+index 4769caab9ff9..a76302450c46 100644
+--- a/drivers/block/loop.c
b/drivers/block/loop.c
+@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo,
fmode_t mode,
+ lo->lo_flags |= LO_FLAGS_PARTSCAN;
+ partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
+ if (partscan)
+- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++ clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+
+ /* enable and uncork uevent now that we are done */
+ dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
+@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool
release)
+ mutex_lock(>lo_mutex);
+ lo->lo_flags = 0;
+ if (!part_shift)
+- lo->lo_disk->flags |= GENHD_FL_NO_PART;
++ set_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+ lo->lo_state = Lo_unbound;
+ mutex_unlock(>lo_mutex);
+
+@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct
loop_info64 *info)
+
+ if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) &&
+!(prev_lo_flags & LO_FLAGS_PARTSCAN)) {
+- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++ clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+
Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest
On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote: > Adding Kevin, > > I'm not going to be able to debug this more for a week or so. > > The alternate ways to fix it would be to try that ubuntu patch (fixed > for our tree), and / or see what else needs > to be cherry picked to -stable to fix util-linux. It is likely just a > return code difference to userspace when > resizing is being done. > > Kevin: I'm not sure if Wind River is seeing this, but you might want to look > into those ptests and see if they pass on your end. A silly question, which branch are these three patches supposed to apply to? I have tried the kirkstone branch, but it seems that they can't apply cleanly. I also tried to manually apply the two kernel patches to the latest linux-yocto/v5.15/standard/base branch, but they also can't be applied cleanly. Am I miss something? On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest does have three failures. Then I have tried the ubuntu kernel patch [1] which is mentioned in the previous discussion about this issue. This patch can apply to the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted failures, and I also don't find util-linux ptest failure after applying this patch. I attached my logs. [1] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9 Thanks, Kevin START: ptest-runner 2024-03-08T13:02 BEGIN: /usr/lib/parted/ptest make: Entering directory '/usr/lib/parted/ptest/tests' PASS: help-version.sh PASS: t-basic.sh PASS: t0001-tiny.sh PASS: t0010-script-no-ctrl-chars.sh PASS: t0100-print.sh PASS: t0101-print-empty.sh PASS: t0200-gpt.sh PASS: t0201-gpt.sh PASS: t0202-gpt-pmbr.sh PASS: t0203-gpt-tiny-device-abort.sh PASS: t0203-gpt-shortened-device-primary-valid.sh PASS: t0203-gpt-create-on-min-sized-device.sh PASS: t0205-gpt-list-clobbers-pmbr.sh PASS: t0206-gpt-print-with-corrupt-primary-clobbers-pmbr.sh PASS: t0207-IEC-binary-notation.sh PASS: t0208-mkpart-end-in-IEC.sh PASS: t0209-gpt-pmbr_boot.sh t0210-gpt-resized-partition-entry-array.sh: skipped test: this test requires Perl's Digest::CRC module SKIP: t0210-gpt-resized-partition-entry-array.sh t0211-gpt-rewrite-header.sh: skipped test: this test requires Perl's Digest::CRC module SKIP: t0211-gpt-rewrite-header.sh PASS: t0212-gpt-many-partitions.sh PASS: t0213-mkpart-start-negative.sh PASS: t0220-gpt-msftres.sh PASS: t0250-gpt.sh PASS: t0251-gpt-unicode.sh PASS: t0280-gpt-corrupt.sh PASS: t0281-gpt-grow.sh PASS: t0282-gpt-move-backup.sh PASS: t0283-overlap-partitions.sh PASS: t0300-dos-on-gpt.sh PASS: t0301-overwrite-gpt-pmbr.sh PASS: t0350-mac-PT-increases-sector-size.sh PASS: t0400-loop-clobber-infloop.sh PASS: t0500-dup-clobber.sh PASS: t0501-duplicate.sh t1100-busy-label.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1100-busy-label.sh t1101-busy-partition.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1101-busy-partition.sh t1102-loop-label.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1102-loop-label.sh PASS: t1104-remove-and-add-partition.sh : no xfs support : no nilfs2 support : no ntfs support : no hfsplus support : no udf support : no f2fs support PASS: t1700-probe-fs.sh t1701-rescue-fs.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1701-rescue-fs.sh PASS: t2200-dos-label-recog.sh PASS: t2201-pc98-label-recog.sh PASS: t2300-dos-label-extended-bootcode.sh t2310-dos-extended-2-sector-min-offset.sh: skipped test: you lack the scsi_debug kernel module SKIP: t2310-dos-extended-2-sector-min-offset.sh t2320-dos-extended-noclobber.sh: skipped test: you lack the scsi_debug kernel module SKIP: t2320-dos-extended-noclobber.sh PASS: t2400-dos-hfs-partition-type.sh PASS: t2410-dos-udf-partition-type.sh PASS: t2500-probe-corrupt-hfs.sh t3000-resize-fs.sh: skipped test: mkfs.hfs: command not found SKIP: t3000-resize-fs.sh t3200-resize-partition.sh: skipped test: you lack the scsi_debug kernel module SKIP: t3200-resize-partition.sh t3200-type-change.sh: skipped test: you lack the scsi_debug kernel module SKIP: t3200-type-change.sh PASS: t3300-palo-prep.sh PASS: t3310-flags.sh PASS: t3400-whole-disk-FAT-partition.sh PASS: t4000-sun-raid-type.sh PASS: t4001-sun-vtoc.sh t4100-msdos-partition-limits.sh: skipped test: this test requires XFS support SKIP: t4100-msdos-partition-limits.sh t4100-dvh-partition-limits.sh: skipped test: this test requires XFS support SKIP: t4100-dvh-partition-limits.sh PASS: t4100-msdos-starting-sector.sh t4200-partprobe.sh: skipped test: This test requires an erasable device and you have not properly set the $DEVICE_TO_ERASE and $DEVICE_TO_ERASE_SIZE envvars. SKIP: t4200-partprobe.sh PASS: t4300-nilfs2-tiny.sh PASS: t4301-nilfs2-badsb2.sh PASS: t4302-nilfs2-lessbadsb2.sh PASS: t5000-tags.sh t6000-dm.sh: skipped test: no device-mapper support SKIP: t6000-dm.sh t6001-psep.sh: skipped test:
[OE-core] [PATCH v2] image-live.bbclass: Adjust the default value for INITRD_LIVE
From: Kevin Hao
The ${INITRAMFS_FSTYPES} may contains multi filesystem types,
such as "cpio.gz cpio.xz". So it can't be used directly in setting
of the default INITRD_LIVE. We choose the first filesystem type
in ${INITRAMFS_FSTYPES} for the default INITRD_LIVE.
Signed-off-by: Kevin Hao
---
v2: Drop the adding of ${IMAGE_NAME_SUFFIX}.
meta/classes-recipe/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/image-live.bbclass
b/meta/classes-recipe/image-live.bbclass
index da919d52f983..d2e95ef51c3a 100644
--- a/meta/classes-recipe/image-live.bbclass
+++ b/meta/classes-recipe/image-live.bbclass
@@ -38,7 +38,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot
\
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}${IMAGE_MACHINE_SUFFIX}.${INITRAMFS_FSTYPES}"
+INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}${IMAGE_MACHINE_SUFFIX}.${@d.getVar('INITRAMFS_FSTYPES').split()[0]}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196622):
https://lists.openembedded.org/g/openembedded-core/message/196622
Mute This Topic: https://lists.openembedded.org/mt/104739998/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] image-live.bbclass: Adjust the default value for INITRD_LIVE
On Tue, Mar 05, 2024 at 12:11:51AM +, Richard Purdie wrote:
> On Sun, 2024-03-03 at 14:54 +0800, Kevin Hao wrote:
> > From: Kevin Hao
> >
> > - After the commit 26d97acc7137 ("image-artifact-names: include
> > ${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
> > ${IMAGE_LINK_NAME}"), the image names have changed from
> > core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
> > core-image-minimal-qemux86-64.ext4
> > to
> > core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
> > core-image-minimal-qemux86-64.rootfs.ext4
> > So we also need to add ${IMAGE_NAME_SUFFIX} to the default INITRD_LIVE.
> >
> > - The ${INITRAMFS_FSTYPES} may contains multi filesystem types,
> > such as "cpio.gz cpio.xz". So it can't be used directly in setting
> > of the default INITRD_LIVE. We choose the first filesystem type
> > in ${INITRAMFS_FSTYPES} for the default INITRD_LIVE.
> >
> > Signed-off-by: Kevin Hao
> > ---
> > meta/classes-recipe/image-live.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I think this causes:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/58/builds/8468/steps/11/logs/stdio
>
> unfortunately.
Sorry, my default. ${IMAGE_NAME_SUFFIX} shouldn't be added to INITRD_LIVE. V2
is coming.
Thanks,
Kevin
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196621):
https://lists.openembedded.org/g/openembedded-core/message/196621
Mute This Topic: https://lists.openembedded.org/mt/104699273/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] image-live.bbclass: Adjust the default value for INITRD_LIVE
From: Kevin Hao
- After the commit 26d97acc7137 ("image-artifact-names: include
${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
${IMAGE_LINK_NAME}"), the image names have changed from
core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
core-image-minimal-qemux86-64.ext4
to
core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
core-image-minimal-qemux86-64.rootfs.ext4
So we also need to add ${IMAGE_NAME_SUFFIX} to the default INITRD_LIVE.
- The ${INITRAMFS_FSTYPES} may contains multi filesystem types,
such as "cpio.gz cpio.xz". So it can't be used directly in setting
of the default INITRD_LIVE. We choose the first filesystem type
in ${INITRAMFS_FSTYPES} for the default INITRD_LIVE.
Signed-off-by: Kevin Hao
---
meta/classes-recipe/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/image-live.bbclass
b/meta/classes-recipe/image-live.bbclass
index da919d52f983..2029807d2d2e 100644
--- a/meta/classes-recipe/image-live.bbclass
+++ b/meta/classes-recipe/image-live.bbclass
@@ -38,7 +38,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot
\
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}${IMAGE_MACHINE_SUFFIX}.${INITRAMFS_FSTYPES}"
+INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}${IMAGE_MACHINE_SUFFIX}${IMAGE_NAME_SUFFIX}.${@d.getVar('INITRAMFS_FSTYPES').split()[0]}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196555):
https://lists.openembedded.org/g/openembedded-core/message/196555
Mute This Topic: https://lists.openembedded.org/mt/104699273/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] uboot-config.bbclass: Don't bail out early in multi configs
Previously we had the support to build multiple u-boot configs for a
machine, but after the change in the commit 801a27d73b10
("uboot-config.bbclass: Raise error for bad key"), this anonymous
function would bail out after handling the first config in UBOOT_CONFIG.
This is definitely not what we want. Fix it by making sure all the
configs are handled.
Fixed: 801a27d73b10 ("uboot-config.bbclass: Raise error for bad key")
Signed-off-by: Kevin Hao
---
meta/classes/uboot-config.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
index e8da8c7452ac..1fbd49824f9d 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -109,8 +109,10 @@ python () {
if len(ubootconfig) > 0:
for config in ubootconfig:
+found = False
for f, v in ubootconfigflags.items():
if config == f:
+found = True
items = v.split(',')
if items[0] and len(items) > 3:
raise bb.parse.SkipRecipe('Only config,images,binary
can be specified!')
@@ -125,6 +127,8 @@ python () {
else:
bb.debug(1, "Appending '%s' to UBOOT_BINARIES." %
ubootbinary)
d.appendVar('UBOOT_BINARIES', ' ' + ubootbinary)
-return
-raise bb.parse.SkipRecipe("The selected UBOOT_CONFIG key %s has no
match in %s." % (ubootconfig, ubootconfigflags.keys()))
+break
+
+if not found:
+raise bb.parse.SkipRecipe("The selected UBOOT_CONFIG key %s
has no match in %s." % (ubootconfig, ubootconfigflags.keys()))
}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169145):
https://lists.openembedded.org/g/openembedded-core/message/169145
Mute This Topic: https://lists.openembedded.org/mt/92911897/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kernel.bbclass: Fix the do_strip() malfunction
The BB variable can't be referenced directly in a python function,
this misusage of the variable reference causes strip function to be
always skipped.
Fixed: b9c3db4953e4 ("kernel.bbclass: Use KERNEL_IMAGEDEST instead of hardcoded
boot path")
Signed-off-by: Kevin Hao
---
meta/classes/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7ca847f0a341..bc52419e0945 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -711,7 +711,7 @@ python do_strip() {
extra_sections = d.getVar('KERNEL_IMAGE_STRIP_EXTRA_SECTIONS')
kernel_image = d.getVar('B') + "/" + d.getVar('KERNEL_OUTPUT_DIR') +
"/vmlinux"
-if (extra_sections and kernel_image.find('${KERNEL_IMAGEDEST}/vmlinux') !=
-1):
+if (extra_sections and kernel_image.find(d.getVar('KERNEL_IMAGEDEST') +
'/vmlinux') != -1):
kernel_image_stripped = kernel_image + ".stripped"
shutil.copy2(kernel_image, kernel_image_stripped)
oe.package.runstrip((kernel_image_stripped, 8, strip, extra_sections))
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164184):
https://lists.openembedded.org/g/openembedded-core/message/164184
Mute This Topic: https://lists.openembedded.org/mt/90351858/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott v2 0/3] tune-cortexa72: Drop the crypto extension from the cortexa72 tune
Hi, v2: Include the patch 3 as suggest by Richard. v1: This patch series backport two patches from the master branch to fix the crash issue on some cortexa72 boards due to the crypto intructions are used. Jagadeesh Krishnanjanappa (1): tune-cortexa72: remove crypto for the default cortex-a72 Kevin Hao (2): tune-cortexa72: Enable the crc extension by default for cortexa72 tune-cortexa72: Drop the redundant cortexa72-crc tune meta/conf/machine/include/tune-cortexa72.inc | 12 1 file changed, 8 insertions(+), 4 deletions(-) -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160609): https://lists.openembedded.org/g/openembedded-core/message/160609 Mute This Topic: https://lists.openembedded.org/mt/88463220/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott v2 3/3] tune-cortexa72: Drop the redundant cortexa72-crc tune
We have enabled the crc extension by default for cortexa72 in patch
("tune-cortexa72: Enable the crc extension by default for cortexa72"),
then the cortexa72-crc seems redundant. So drop it. We also rename the
cortexa72-crc-crypto to cortexa72-crypto. With these changes, it will
break the BSPs which used these two tunes, but it should be easy to fix.
(From OE-Core rev: 03cebdd7ef923a8ac5c8b7c12c7cefe7ca0158db)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
v2: A new patch in v2.
meta/conf/machine/include/tune-cortexa72.inc | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
index 30480efd8328..efb71ee0a1f3 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -6,16 +6,12 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
+AVAILTUNES += "cortexa72 cortexa72-crypto"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
-ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
-ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
+ARMPKGARCH_tune-cortexa72-crypto = "cortexa72"
TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa72"
-TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72}"
-TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crypto"
+TUNE_FEATURES_tune-cortexa72-crypto = "${TUNE_FEATURES_tune-cortexa72}
crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crypto"
BASE_LIB_tune-cortexa72= "lib64"
-BASE_LIB_tune-cortexa72-crc= "lib64"
-BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
+BASE_LIB_tune-cortexa72-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160611):
https://lists.openembedded.org/g/openembedded-core/message/160611
Mute This Topic: https://lists.openembedded.org/mt/88463223/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott v2 1/3] tune-cortexa72: remove crypto for the default cortex-a72
From: Jagadeesh Krishnanjanappa
The cryptographic unit is optional for the Cortex-A72, but it was
included by default previously. This breaks building systems that
lack this functionality when using tune-cortexa72.inc.
To correct this, add a crypto entry in the tune file. Since CRC is
optional for ARMv8.0, do the same thing while we're at it.
For platforms that had been happily using tune-cortexa72.inc, a slight
degradation of performance will occur using the default. To correct
this, simply add:
DEFAULTTUNE = "cortexa72-crc-crypto"
(From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)
Signed-off-by: Jagadeesh Krishnanjanappa
Signed-off-by: Jon Mason (rewording commit message)
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
v2: No change.
meta/conf/machine/include/tune-cortexa72.inc | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
index b3f68ab6e3be..7608a20c43f4 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -6,8 +6,16 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
-TUNE_FEATURES_tune-cortexa72 =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
-BASE_LIB_tune-cortexa72 = "lib64"
+ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
+ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
+TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a}
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72} crc"
+TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8}
cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc
cortexa72-crc-crypto"
+BASE_LIB_tune-cortexa72= "lib64"
+BASE_LIB_tune-cortexa72-crc= "lib64"
+BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160608):
https://lists.openembedded.org/g/openembedded-core/message/160608
Mute This Topic: https://lists.openembedded.org/mt/88463219/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott v2 2/3] tune-cortexa72: Enable the crc extension by default for cortexa72
The crc extension is optional for the ARMv8.0 but is mandatory for the
cortexa72, so there is no reason not to enable it for the cortexa72
tune. With this change, the cortexa72-crc seems redundant. But we
had better to keep it to be compatible with the BSP which already used
that tune.
(From OE-Core rev: ca50267ab568d2f688844cb7c6cd867ed34168db)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
v2: No change.
meta/conf/machine/include/tune-cortexa72.inc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
index 7608a20c43f4..30480efd8328 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -10,12 +10,12 @@ AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
-TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a}
cortexa72"
-TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72} crc"
-TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crc crypto"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8}
cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc
cortexa72-crc-crypto"
+TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72}"
+TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
BASE_LIB_tune-cortexa72= "lib64"
BASE_LIB_tune-cortexa72-crc= "lib64"
BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160610):
https://lists.openembedded.org/g/openembedded-core/message/160610
Mute This Topic: https://lists.openembedded.org/mt/88463222/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72
On Sun, Jan 16, 2022 at 12:01:16PM +, Richard Purdie wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > On Sat, 2022-01-15 at 02:53 +, Anuj Mittal wrote: > > On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote: > > > From: Jagadeesh Krishnanjanappa > > > > > > The cryptographic unit is optional for the Cortex-A72, but it was > > > included by default previously. This breaks building systems that > > > lack this functionality when using tune-cortexa72.inc. > > > > > > To correct this, add a crypto entry in the tune file. Since CRC is > > > optional for ARMv8.0, do the same thing while we're at it. > > > > > > For platforms that had been happily using tune-cortexa72.inc, a > > > slight > > > degradation of performance will occur using the default. To correct > > > this, simply add: > > > DEFAULTTUNE = "cortexa72-crc-crypto" > > > > > > > I am not very familiar with ARM tunes but it sounds like you are > > changing behaviour for people who might already be using these tunes > > with these two patches ... That might not be suitable for stable > > branches. > > > > Perhaps Ross, Jon or others can comment if this is something that > > should be merged in stable branches. > > You're right to be nervous of the change, I was with master. Having looked > into > the issue, it is a serious one and probably should be fixed. > > That said, I think there is perhaps a patch missing from this series, the one > which removes the cortexa72-crc tune. I dropped that patch intentionally since it doesn't fix any real issue and may be not suitable for the stable branch. > I think this is fine even for a stable > series since the patch adding it is also in this series. The patches do make > more sense once looked at as a whole, Faire enough, I will send a v2 to include that patch. Thanks, Kevin > we just didn't get this quite right for > master at first. > > Cheers, > > Richard > signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160605): https://lists.openembedded.org/g/openembedded-core/message/160605 Mute This Topic: https://lists.openembedded.org/mt/88436676/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72
On Sat, Jan 15, 2022 at 02:53:09AM +, Mittal, Anuj wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote:
> > From: Jagadeesh Krishnanjanappa
> >
> > The cryptographic unit is optional for the Cortex-A72, but it was
> > included by default previously. This breaks building systems that
> > lack this functionality when using tune-cortexa72.inc.
> >
> > To correct this, add a crypto entry in the tune file. Since CRC is
> > optional for ARMv8.0, do the same thing while we're at it.
> >
> > For platforms that had been happily using tune-cortexa72.inc, a
> > slight
> > degradation of performance will occur using the default. To correct
> > this, simply add:
> > DEFAULTTUNE = "cortexa72-crc-crypto"
> >
>
> I am not very familiar with ARM tunes but it sounds like you are
> changing behaviour for people who might already be using these tunes
> with these two patches ... That might not be suitable for stable
> branches.
These two patches fix the application crash bug on the boards which
have a cortexa72 core but don't have a crypto unit. IMHO they are definitely
suitable for the stable branch. Yes, for the boards which do have a crypto
unit, they would have to update their default tune to avoid the slight
the degradation of performance.
Thanks,
Kevin
>
> Perhaps Ross, Jon or others can comment if this is something that
> should be merged in stable branches.
>
> Thanks,
>
> Anuj
>
> > (From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)
> >
> > Signed-off-by: Jagadeesh Krishnanjanappa
> > Signed-off-by: Jon Mason (rewording commit
> > message)
> > Signed-off-by: Richard Purdie
> > [Kevin: Convert to the old style override syntax]
> > Signed-off-by: Kevin Hao
> > ---
> > meta/conf/machine/include/tune-cortexa72.inc | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/tune-cortexa72.inc
> > b/meta/conf/machine/include/tune-cortexa72.inc
> > index b3f68ab6e3be..7608a20c43f4 100644
> > --- a/meta/conf/machine/include/tune-cortexa72.inc
> > +++ b/meta/conf/machine/include/tune-cortexa72.inc
> > @@ -6,8 +6,16 @@ TUNE_CCARGS .=
> > "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
> > require conf/machine/include/arm/arch-armv8a.inc
> >
> > # Little Endian base configs
> > -AVAILTUNES += "cortexa72"
> > +AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
> > ARMPKGARCH_tune-cortexa72 = "cortexa72"
> > -TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-
> > armv8a-crc-crypto} cortexa72"
> > -PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-
> > armv8a-crc-crypto} cortexa72"
> > -BASE_LIB_tune-cortexa72 = "lib64"
> > +ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
> > +ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
> > +TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-
> > armv8a} cortexa72"
> > +TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-
> > cortexa72} crc"
> > +TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-
> > cortexa72} crc crypto"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8} cortexa72"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-
> > crc cortexa72-crc-crypto"
> > +BASE_LIB_tune-cortexa72= "lib64"
> > +BASE_LIB_tune-cortexa72-crc= "lib64"
> > +BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
>
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160601):
https://lists.openembedded.org/g/openembedded-core/message/160601
Mute This Topic: https://lists.openembedded.org/mt/88436676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72
From: Jagadeesh Krishnanjanappa
The cryptographic unit is optional for the Cortex-A72, but it was
included by default previously. This breaks building systems that
lack this functionality when using tune-cortexa72.inc.
To correct this, add a crypto entry in the tune file. Since CRC is
optional for ARMv8.0, do the same thing while we're at it.
For platforms that had been happily using tune-cortexa72.inc, a slight
degradation of performance will occur using the default. To correct
this, simply add:
DEFAULTTUNE = "cortexa72-crc-crypto"
(From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)
Signed-off-by: Jagadeesh Krishnanjanappa
Signed-off-by: Jon Mason (rewording commit message)
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
meta/conf/machine/include/tune-cortexa72.inc | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
index b3f68ab6e3be..7608a20c43f4 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -6,8 +6,16 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
-TUNE_FEATURES_tune-cortexa72 =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
-BASE_LIB_tune-cortexa72 = "lib64"
+ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
+ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
+TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a}
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72} crc"
+TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8}
cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc
cortexa72-crc-crypto"
+BASE_LIB_tune-cortexa72= "lib64"
+BASE_LIB_tune-cortexa72-crc= "lib64"
+BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160596):
https://lists.openembedded.org/g/openembedded-core/message/160596
Mute This Topic: https://lists.openembedded.org/mt/88436676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 0/2] tune-cortexa72: Drop the crypto extension from the cortexa72 tune
Hi, This patch series backport two patches from the master branch to fix the crash issue on some cortexa72 boards due to the crypto intructions are used. Jagadeesh Krishnanjanappa (1): tune-cortexa72: remove crypto for the default cortex-a72 Kevin Hao (1): tune-cortexa72: Enable the crc extension by default for cortexa72 meta/conf/machine/include/tune-cortexa72.inc | 16 1 file changed, 12 insertions(+), 4 deletions(-) -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160597): https://lists.openembedded.org/g/openembedded-core/message/160597 Mute This Topic: https://lists.openembedded.org/mt/88436677/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 2/2] tune-cortexa72: Enable the crc extension by default for cortexa72
The crc extension is optional for the ARMv8.0 but is mandatory for the
cortexa72, so there is no reason not to enable it for the cortexa72
tune. With this change, the cortexa72-crc seems redundant. But we
had better to keep it to be compatible with the BSP which already used
that tune.
(From OE-Core rev: ca50267ab568d2f688844cb7c6cd867ed34168db)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
meta/conf/machine/include/tune-cortexa72.inc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
index 7608a20c43f4..30480efd8328 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -10,12 +10,12 @@ AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
ARMPKGARCH_tune-cortexa72-crc-crypto = "cortexa72"
-TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a}
cortexa72"
-TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72} crc"
-TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crc crypto"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8}
cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc
cortexa72-crc-crypto"
+TUNE_FEATURES_tune-cortexa72 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc = "${TUNE_FEATURES_tune-cortexa72}"
+TUNE_FEATURES_tune-cortexa72-crc-crypto = "${TUNE_FEATURES_tune-cortexa72}
crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
BASE_LIB_tune-cortexa72= "lib64"
BASE_LIB_tune-cortexa72-crc= "lib64"
BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160598):
https://lists.openembedded.org/g/openembedded-core/message/160598
Mute This Topic: https://lists.openembedded.org/mt/88436678/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 0/2] Add tune for Neoverse N2 core
Hi, The gcc patches for the Neoverse N2 core have been merged into hardknott branch, this patch series backport two patches from the master branch to add the corresponding tune files. Kevin Hao (2): arch-armv8-5a.inc: Add tune include for armv8.5a armv9a/tune: Add the support for the Neoverse N2 core .../machine/include/arm/arch-armv8-5a.inc | 19 .../include/arm/armv9a/tune-neoversen2.inc| 22 +++ 2 files changed, 41 insertions(+) create mode 100644 meta/conf/machine/include/arm/arch-armv8-5a.inc create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160593): https://lists.openembedded.org/g/openembedded-core/message/160593 Mute This Topic: https://lists.openembedded.org/mt/88436041/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 1/2] arch-armv8-5a.inc: Add tune include for armv8.5a
This adds support for the armv8.5a architecture and the crypto
extension.
(From OE-Core rev: 0cb1a6d9cb4c32526d79dad93c8053b3793053f8)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
.../machine/include/arm/arch-armv8-5a.inc | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 meta/conf/machine/include/arm/arch-armv8-5a.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8-5a.inc
b/meta/conf/machine/include/arm/arch-armv8-5a.inc
new file mode 100644
index ..44c3b5bd2275
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8-5a.inc
@@ -0,0 +1,19 @@
+DEFAULTTUNE ?= "armv8-5a"
+
+TUNEVALID[armv8-5a] = "Enable instructions for ARMv8.5-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a', '
-march=armv8.5-a', '', d)}"
+# TUNE crypto will be handled by arch-armv8a.inc below
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a',
'armv8-5a:', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8-5a armv8-5a-crypto"
+ARMPKGARCH_tune-armv8-5a?= "armv8-5a"
+ARMPKGARCH_tune-armv8-5a-crypto ?= "armv8-5a"
+TUNE_FEATURES_tune-armv8-5a = "aarch64 armv8-5a"
+TUNE_FEATURES_tune-armv8-5a-crypto = "${TUNE_FEATURES_tune-armv8-5a}
crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8-5a=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8-5a"
+PACKAGE_EXTRA_ARCHS_tune-armv8-5a-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a} armv8-5a-crypto"
+BASE_LIB_tune-armv8-5a = "lib64"
+BASE_LIB_tune-armv8-5a-crypto= "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160594):
https://lists.openembedded.org/g/openembedded-core/message/160594
Mute This Topic: https://lists.openembedded.org/mt/88436042/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott 2/2] armv9a/tune: Add the support for the Neoverse N2 core
This adds the support for the Neoverse N2 core, even though the
Neoverse N2 core implements the Arm v9.0-A architecture, but the support
of it in GCC is based on the Arm v8.5-A architecture. Please see the
commit 50d9db203bc3 ("aarch64: Add support for Neoverse N2 CPU") in GCC
for more detail.
(From OE-Core rev: 37597397f03b6b0082a702147dc536ff8b2fa7a3)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
.../include/arm/armv9a/tune-neoversen2.inc| 22 +++
1 file changed, 22 insertions(+)
create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
diff --git a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
new file mode 100644
index ..dedabcf46e23
--- /dev/null
+++ b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
@@ -0,0 +1,22 @@
+#
+# Tune Settings for Neoverse-N2
+#
+DEFAULTTUNE ?= "neoversen2"
+
+TUNEVALID[neoversen2] = "Enable Neoverse-N2 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neoversen2', '
-mcpu=neoverse-n2', '', d)}"
+
+# Even though the Neoverse N2 core implemnts the Arm v9.0-A architecture,
+# but the support of it in GCC is based on the Arm v8.5-A architecture.
+require conf/machine/include/arm/arch-armv8-5a.inc
+
+# Little Endian base configs
+AVAILTUNES += "neoversen2
neoversen2-crypto"
+ARMPKGARCH_tune-neoversen2 = "neoversen2"
+ARMPKGARCH_tune-neoversen2-crypto = "neoversen2-crypto"
+TUNE_FEATURES_tune-neoversen2 =
"${TUNE_FEATURES_tune-armv8-5a} neoversen2"
+TUNE_FEATURES_tune-neoversen2-crypto=
"${TUNE_FEATURES_tune-neoversen2} crypto"
+PACKAGE_EXTRA_ARCHS_tune-neoversen2 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a} neoversen2"
+PACKAGE_EXTRA_ARCHS_tune-neoversen2-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a-crypto} neoversen2 neoversen2-crypto"
+BASE_LIB_tune-neoversen2= "lib64"
+BASE_LIB_tune-neoversen2-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160595):
https://lists.openembedded.org/g/openembedded-core/message/160595
Mute This Topic: https://lists.openembedded.org/mt/88436043/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] tune-cortexa73: Introduce cortexa73-crypto tune
The crypto extension is optional for the Cortex-A73 processor, so we
shouldn't enable the crypto by default for the cortexa73 tune.
Introduce the cortexa73-crypto for the processors which do have
the cryptography unit.
Signed-off-by: Kevin Hao
---
.../conf/machine/include/arm/armv8a/tune-cortexa73.inc | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa73.inc
b/meta/conf/machine/include/arm/armv8a/tune-cortexa73.inc
index fc91dafb1d85..13876e72459e 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa73.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa73.inc
@@ -9,8 +9,12 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa73', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES+= "cortexa73"
+AVAILTUNES+= "cortexa73 cortexa73-crypto"
ARMPKGARCH:tune-cortexa73 = "cortexa73"
-TUNE_FEATURES:tune-cortexa73 =
"${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa73"
-PACKAGE_EXTRA_ARCHS:tune-cortexa73 =
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa73"
+ARMPKGARCH:tune-cortexa73-crypto = "cortexa73"
+TUNE_FEATURES:tune-cortexa73 = "${TUNE_FEATURES:tune-armv8a-crc}
cortexa73"
+TUNE_FEATURES:tune-cortexa73-crypto= "${TUNE_FEATURES:tune-cortexa73}
crypto"
+PACKAGE_EXTRA_ARCHS:tune-cortexa73 =
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa73"
+PACKAGE_EXTRA_ARCHS:tune-cortexa73-crypto =
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa73 cortexa73-crypto"
BASE_LIB:tune-cortexa73= "lib64"
+BASE_LIB:tune-cortexa73-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160556):
https://lists.openembedded.org/g/openembedded-core/message/160556
Mute This Topic: https://lists.openembedded.org/mt/88415102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] tune-cortexa72: Drop the redundant cortexa72-crc tune
We have enabled the crc extension by default for cortexa72 in patch
("tune-cortexa72: Enable the crc extension by default for cortexa72"),
then the cortexa72-crc seems redundant. So drop it. We also rename the
cortexa72-crc-crypto to cortexa72-crypto. With these changes, it will
break the BSPs which used these two tunes, but it should be easy to fix.
Signed-off-by: Kevin Hao
---
.../machine/include/arm/armv8a/tune-cortexa72.inc | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 4c9add32f5f5..1a20b04483d9 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -6,16 +6,12 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
+AVAILTUNES += "cortexa72 cortexa72-crypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
-ARMPKGARCH:tune-cortexa72-crc = "cortexa72"
-ARMPKGARCH:tune-cortexa72-crc-crypto = "cortexa72"
+ARMPKGARCH:tune-cortexa72-crypto = "cortexa72"
TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a-crc}
cortexa72"
-TUNE_FEATURES:tune-cortexa72-crc = "${TUNE_FEATURES:tune-cortexa72}"
-TUNE_FEATURES:tune-cortexa72-crc-crypto = "${TUNE_FEATURES:tune-cortexa72}
crypto"
+TUNE_FEATURES:tune-cortexa72-crypto = "${TUNE_FEATURES:tune-cortexa72}
crypto"
PACKAGE_EXTRA_ARCHS:tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS:tune-armv8-crc} cortexa72"
-PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
-PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-crypto =
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72 cortexa72-crypto"
BASE_LIB:tune-cortexa72= "lib64"
-BASE_LIB:tune-cortexa72-crc= "lib64"
-BASE_LIB:tune-cortexa72-crc-crypto = "lib64"
+BASE_LIB:tune-cortexa72-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160510):
https://lists.openembedded.org/g/openembedded-core/message/160510
Mute This Topic: https://lists.openembedded.org/mt/88396631/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] tune-cortexa72: Enable the crc extension by default for cortexa72
On Wed, Jan 12, 2022 at 04:14:36PM -0800, Khem Raj wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Wed, Jan 12, 2022 at 1:58 PM Richard Purdie < > richard.pur...@linuxfoundation.org> wrote: > > On Wed, 2022-01-12 at 14:23 -0500, Jon Mason wrote: > > On Wed, Jan 12, 2022 at 4:11 AM Kevin Hao > wrote: > > > > > > The crc extension is optional for the ARMv8.0 but is mandatory for the > > > cortexa72, so there is no reason not to enable it for the cortexa72 > > > tune. With this change, the cortexa72-crc seems redundant. But we > > > had better to keep it to be compatible with the BSP which already used > > > that tune. > > > > > > Signed-off-by: Kevin Hao > > > > Acked-by: Jon Mason > > > > From the GCC sources, it's hard coded for A34, A35, A53, A57, A72, > > A73, and almost all of the others listed. I can patch the rest. > > I did wonder if we should just drop the duplicate tune too. It will cause > an > error but it is an error that should be quickly/easily fixed... > > > I am good with that problem is only for bsp layers which support multiple > releases with a single branch but I guess that’s something less of a concern > for me OK, I will send a add-on patch to drop the cortexa72-crc tune. Thanks, Kevin > > > > Cheers, > > Richard > > > > > signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160509): https://lists.openembedded.org/g/openembedded-core/message/160509 Mute This Topic: https://lists.openembedded.org/mt/88369540/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] tune-cortexa72: Enable the crc extension by default for cortexa72
The crc extension is optional for the ARMv8.0 but is mandatory for the
cortexa72, so there is no reason not to enable it for the cortexa72
tune. With this change, the cortexa72-crc seems redundant. But we
had better to keep it to be compatible with the BSP which already used
that tune.
Signed-off-by: Kevin Hao
---
.../machine/include/arm/armv8a/tune-cortexa72.inc| 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 3651cf6e802b..4c9add32f5f5 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -10,12 +10,12 @@ AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
ARMPKGARCH:tune-cortexa72-crc = "cortexa72"
ARMPKGARCH:tune-cortexa72-crc-crypto = "cortexa72"
-TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a}
cortexa72"
-TUNE_FEATURES:tune-cortexa72-crc = "${TUNE_FEATURES:tune-cortexa72} crc"
-TUNE_FEATURES:tune-cortexa72-crc-crypto = "${TUNE_FEATURES:tune-cortexa72}
crc crypto"
-PACKAGE_EXTRA_ARCHS:tune-cortexa72= "${PACKAGE_EXTRA_ARCHS:tune-armv8}
cortexa72"
-PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72 cortexa72-crc"
-PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72 cortexa72-crc
cortexa72-crc-crypto"
+TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a-crc}
cortexa72"
+TUNE_FEATURES:tune-cortexa72-crc = "${TUNE_FEATURES:tune-cortexa72}"
+TUNE_FEATURES:tune-cortexa72-crc-crypto = "${TUNE_FEATURES:tune-cortexa72}
crypto"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS:tune-armv8-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-crc-crypto=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
BASE_LIB:tune-cortexa72= "lib64"
BASE_LIB:tune-cortexa72-crc= "lib64"
BASE_LIB:tune-cortexa72-crc-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160480):
https://lists.openembedded.org/g/openembedded-core/message/160480
Mute This Topic: https://lists.openembedded.org/mt/88369540/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/2] armv9a/tune: Add the support for the Neoverse N2 core
On Fri, Dec 24, 2021 at 06:05:18PM +0800, Kevin Hao wrote:
> This adds the support for the Neoverse N2 core, even though the
> Neoverse N2 core implements the Arm v9.0-A architecture, but the support
> of it in GCC is based on the Arm v8.5-A architecture. Please see the
> commit 50d9db203bc3 ("aarch64: Add support for Neoverse N2 CPU") in GCC
> for more detail.
Ping.
Thanks,
Kevin
>
> Signed-off-by: Kevin Hao
> ---
> .../include/arm/armv9a/tune-neoversen2.inc| 22 +++
> 1 file changed, 22 insertions(+)
> create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
>
> diff --git a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
> b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
> new file mode 100644
> index ..36355f7bedb0
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
> @@ -0,0 +1,22 @@
> +#
> +# Tune Settings for Neoverse-N2
> +#
> +DEFAULTTUNE ?= "neoversen2"
> +
> +TUNEVALID[neoversen2] = "Enable Neoverse-N2 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neoversen2', '
> -mcpu=neoverse-n2', '', d)}"
> +
> +# Even though the Neoverse N2 core implemnts the Arm v9.0-A architecture,
> +# but the support of it in GCC is based on the Arm v8.5-A architecture.
> +require conf/machine/include/arm/arch-armv8-5a.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "neoversen2
> neoversen2-crypto"
> +ARMPKGARCH:tune-neoversen2 = "neoversen2"
> +ARMPKGARCH:tune-neoversen2-crypto = "neoversen2-crypto"
> +TUNE_FEATURES:tune-neoversen2 =
> "${TUNE_FEATURES:tune-armv8-5a} neoversen2"
> +TUNE_FEATURES:tune-neoversen2-crypto=
> "${TUNE_FEATURES:tune-neoversen2} crypto"
> +PACKAGE_EXTRA_ARCHS:tune-neoversen2 =
> "${PACKAGE_EXTRA_ARCHS:tune-armv8-5a} neoversen2"
> +PACKAGE_EXTRA_ARCHS:tune-neoversen2-crypto =
> "${PACKAGE_EXTRA_ARCHS:tune-armv8-5a-crypto} neoversen2 neoversen2-crypto"
> +BASE_LIB:tune-neoversen2= "lib64"
> +BASE_LIB:tune-neoversen2-crypto = "lib64"
> --
> 2.31.1
>
>
>
>
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160478):
https://lists.openembedded.org/g/openembedded-core/message/160478
Mute This Topic: https://lists.openembedded.org/mt/88365666/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] arch-armv8-5a.inc: Add tune include for armv8.5a
This adds support for the armv8.5a architecture and the crypto
extension.
Signed-off-by: Kevin Hao
---
.../machine/include/arm/arch-armv8-5a.inc | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 meta/conf/machine/include/arm/arch-armv8-5a.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8-5a.inc
b/meta/conf/machine/include/arm/arch-armv8-5a.inc
new file mode 100644
index ..a1bcb7fb9a16
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8-5a.inc
@@ -0,0 +1,19 @@
+DEFAULTTUNE ?= "armv8-5a"
+
+TUNEVALID[armv8-5a] = "Enable instructions for ARMv8.5-a"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a', '
-march=armv8.5-a', '', d)}"
+# TUNE crypto will be handled by arch-armv8a.inc below
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a',
'armv8-5a:', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8-5a armv8-5a-crypto"
+ARMPKGARCH:tune-armv8-5a?= "armv8-5a"
+ARMPKGARCH:tune-armv8-5a-crypto ?= "armv8-5a"
+TUNE_FEATURES:tune-armv8-5a = "aarch64 armv8-5a"
+TUNE_FEATURES:tune-armv8-5a-crypto = "${TUNE_FEATURES:tune-armv8-5a}
crypto"
+PACKAGE_EXTRA_ARCHS:tune-armv8-5a=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a} armv8-5a"
+PACKAGE_EXTRA_ARCHS:tune-armv8-5a-crypto =
"${PACKAGE_EXTRA_ARCHS:tune-armv8-5a} armv8-5a-crypto"
+BASE_LIB:tune-armv8-5a = "lib64"
+BASE_LIB:tune-armv8-5a-crypto= "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159997):
https://lists.openembedded.org/g/openembedded-core/message/159997
Mute This Topic: https://lists.openembedded.org/mt/87934487/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] armv9a/tune: Add the support for the Neoverse N2 core
This adds the support for the Neoverse N2 core, even though the
Neoverse N2 core implements the Arm v9.0-A architecture, but the support
of it in GCC is based on the Arm v8.5-A architecture. Please see the
commit 50d9db203bc3 ("aarch64: Add support for Neoverse N2 CPU") in GCC
for more detail.
Signed-off-by: Kevin Hao
---
.../include/arm/armv9a/tune-neoversen2.inc| 22 +++
1 file changed, 22 insertions(+)
create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
diff --git a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
new file mode 100644
index ..36355f7bedb0
--- /dev/null
+++ b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
@@ -0,0 +1,22 @@
+#
+# Tune Settings for Neoverse-N2
+#
+DEFAULTTUNE ?= "neoversen2"
+
+TUNEVALID[neoversen2] = "Enable Neoverse-N2 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neoversen2', '
-mcpu=neoverse-n2', '', d)}"
+
+# Even though the Neoverse N2 core implemnts the Arm v9.0-A architecture,
+# but the support of it in GCC is based on the Arm v8.5-A architecture.
+require conf/machine/include/arm/arch-armv8-5a.inc
+
+# Little Endian base configs
+AVAILTUNES += "neoversen2
neoversen2-crypto"
+ARMPKGARCH:tune-neoversen2 = "neoversen2"
+ARMPKGARCH:tune-neoversen2-crypto = "neoversen2-crypto"
+TUNE_FEATURES:tune-neoversen2 =
"${TUNE_FEATURES:tune-armv8-5a} neoversen2"
+TUNE_FEATURES:tune-neoversen2-crypto=
"${TUNE_FEATURES:tune-neoversen2} crypto"
+PACKAGE_EXTRA_ARCHS:tune-neoversen2 =
"${PACKAGE_EXTRA_ARCHS:tune-armv8-5a} neoversen2"
+PACKAGE_EXTRA_ARCHS:tune-neoversen2-crypto =
"${PACKAGE_EXTRA_ARCHS:tune-armv8-5a-crypto} neoversen2 neoversen2-crypto"
+BASE_LIB:tune-neoversen2= "lib64"
+BASE_LIB:tune-neoversen2-crypto = "lib64"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159998):
https://lists.openembedded.org/g/openembedded-core/message/159998
Mute This Topic: https://lists.openembedded.org/mt/87934488/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision
On Thu, Dec 02, 2021 at 07:31:52AM -0500, Bruce Ashfield wrote: > > That would be great if you can do so. > > ok. Let's solve this with an explicit KBRANCH with your pinned SRCREVs > for now, and I'll update -dev to use versioned branches for the current > 5.16 cycle and all new versions that follow. Thanks Bruce. Kevin signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159088): https://lists.openembedded.org/g/openembedded-core/message/159088 Mute This Topic: https://lists.openembedded.org/mt/87421079/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision
On Wed, Dec 01, 2021 at 04:27:44PM -0500, Bruce Ashfield wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie
> wrote:
> >
> > On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote:
> > > By default the -dev kernel uses the "AUTOREV" to pull in the branch
> > > head as the revision. Some of our BSPs are based on the -dev kernel and
> > > we choose to nail down the kernel to a specific revision when releasing
> > > our product by using some setting like below:
> > > PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> > > SRCREV_machine:pn-linux-yocto-dev =
> > > "6fb48ae18a10770702266dd1f1aa500149e361ec"
> > > KBRANCH:pn-linux-yocto-dev = "standard/x86"
> > > LINUX_VERSION = "5.15"
> > >
> > > Since all the standard/* branches will be rebased after each kernel
> > > version bump, we would get bitbake fetch failure due to that specific
> > > commit is not reachable in the new version branch. This kind of issue
> > > can be fixed by setting the "nobranch" parameter in the SRC_URI because
> > > it will cause the fetcher to skip the SHA validation for the branch.
> > > And this also won't cause other side effect because all the branches
> > > will be created in the do_kernel_checkout() and the current branch will
> > > be reset to the reversion we want in do_validate_branches().
> > >
> > > Signed-off-by: Kevin Hao
> > > ---
> > > meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > index 6b6ea9a7e864..7204c3eddc11 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > @@ -19,7 +19,8 @@ include
> > > recipes-kernel/linux/linux-yocto-dev-revisions.inc
> > > KBRANCH = "standard/base"
> > > KMETA = "kernel-meta"
> > >
> > > -SRC_URI =
> > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine
> > > \
> > > +# Set nobranch to skip the SHA validation for branch if a fixed revesion
> > > is used
> > > +SRC_URI =
> > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
> > > \
> > >
> > > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
> > >
> > > # Set default SRCREVs. Both the machine and meta SRCREVs are statically
> > > set
> >
> > I'm afraid this looks to be a bit of a horrible workaround/hack. It happens
> > that
> > if you specify a branch and set nobranch it might do what you want but that
> > certainly isn't by design.
> >
> > Either the revision is in the branch or it isn't. The error is telling you
> > the
> > configuration you set isn't valid and you really need to set a valid
> > configuration, i.e. a revision and a branch or a revision and set nobranch
> > but
> > not both.
> >
> > I'm not sure I understand why the kernel would be rebasing after each kernel
> > release? Is this because it is one of the unversioned branches?
>
> Yah, it is exactly that. The -dev kernel has always been a rebase
> tree, like linux-next upstream.
>
> Since the BSP work started against it (the -dev tree), when I move on
> from a -dev version, I've been saving all work into versioned branches
> ... versus removing them (and storing the history in the
> kernel-cache).
>
> That being said, we merged some code some time ago that allows the
> -dev kernel to automatically switch to the versioned branches, versus
> the rebased "standard/*" branches. (that supports existing releases
> with the -dev kernel as I move the one in master to new versions).
> Have a look at do_validate_branches(), but unfortunately the fetcher
> error will have already been thrown and we can't adjust to the fixed
> SRCREV.
>
> The issue here is the attempt to pin the revision (like Richard is
> saying), since if you use AUTOREV the code I just mentioned code kicks
> in to make sure a versioned branch is used. Nothing should be released
> against -dev, so any issues with pinned SRCREVs and branches should be
> transient.
>
> I've floated the idea a few times that now that
[OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision
By default the -dev kernel uses the "AUTOREV" to pull in the branch
head as the revision. Some of our BSPs are based on the -dev kernel and
we choose to nail down the kernel to a specific revision when releasing
our product by using some setting like below:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
SRCREV_machine:pn-linux-yocto-dev = "6fb48ae18a10770702266dd1f1aa500149e361ec"
KBRANCH:pn-linux-yocto-dev = "standard/x86"
LINUX_VERSION = "5.15"
Since all the standard/* branches will be rebased after each kernel
version bump, we would get bitbake fetch failure due to that specific
commit is not reachable in the new version branch. This kind of issue
can be fixed by setting the "nobranch" parameter in the SRC_URI because
it will cause the fetcher to skip the SHA validation for the branch.
And this also won't cause other side effect because all the branches
will be created in the do_kernel_checkout() and the current branch will
be reset to the reversion we want in do_validate_branches().
Signed-off-by: Kevin Hao
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 6b6ea9a7e864..7204c3eddc11 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -19,7 +19,8 @@ include recipes-kernel/linux/linux-yocto-dev-revisions.inc
KBRANCH = "standard/base"
KMETA = "kernel-meta"
-SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine \
+# Set nobranch to skip the SHA validation for branch if a fixed revesion is
used
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
# Set default SRCREVs. Both the machine and meta SRCREVs are statically set
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159002):
https://lists.openembedded.org/g/openembedded-core/message/159002
Mute This Topic: https://lists.openembedded.org/mt/87421079/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features
On Tue, Apr 27, 2021 at 12:09:51PM -0400, Randy MacLeod wrote:
> Cross-posting to yocto since this is of general interest.
>
> On 2021-04-23 2:02 p.m., Alexander Kanavin wrote:
> > This puts them on equal terms with x11 distro feature
> > (which I think is due).
> >
> > Signed-off-by: Alexander Kanavin
> > ---
> > meta/conf/distro/include/default-distrovars.inc | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/distro/include/default-distrovars.inc
> > b/meta/conf/distro/include/default-distrovars.inc
> > index 9fcc10f83a..384ee7fc98 100644
> > --- a/meta/conf/distro/include/default-distrovars.inc
> > +++ b/meta/conf/distro/include/default-distrovars.inc
> > @@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
> > LOCALE_UTF8_IS_DEFAULT ?= "1"
> > LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
> > -DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4
> > ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc
> > x11 vfat"
> > +DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4
> > ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc
> > x11 vfat wayland opengl"
> > DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
> > IMAGE_FEATURES ?= ""
> >
>
> We (Wind River) already drop the x11 DF from some of our distros and
> we'd likely do the same for wayland and opengl so while this seems
> like the wrong change for headless systems it is one we could deal with.
>
> There was some discussion about this topic on the tech call today and
> people were concerned about BSP support for opengl since the software
> rendering in mesa is horridly slow.
>
> Kevin, Bryan,
> Can you comment if you think we'd have any show-stopper problems
> with opengl support for BSPs?
Thanks for the notice. Hmm, it seems that we have done little validation
for the weston image on the Yocto BSPs, I got a boot failure with the
weston image on my beaglebone black board. I will try to figure out what is
wrong there. But I don't think it should block the change in this patch.
Thanks,
Kevin
>
> Joshua said that weston has a usable RDP (remote desktop backend) but
> I'm not sure how usable it is especially for single application sharing.
> This contrasts with x11 where you can use X11 forwarding over
> ssh trivially for whole desktops or an application.
>
> In conclusion, I see the value in pushing yocto forward but we may need
> to wait for agreement from BSP folks so let's see what they say.
>
> ../Randy
>
>
> >
> >
> >
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151050):
https://lists.openembedded.org/g/openembedded-core/message/151050
Mute This Topic: https://lists.openembedded.org/mt/82317826/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] sysvinit-inittab/start_getty: Check /sys for the tty device existence
The hvc tty driver doesn't populate a file like /proc/tty/driver/serial,
so the current implementation of start_getty doesn't work for the hvc
console. By checking the /sys/class/tty/ for the tty device existence,
it should support more console types and also make the codes more simple.
Signed-off-by: Kevin Hao
---
.../sysvinit/sysvinit-inittab/start_getty | 44 ++-
1 file changed, 3 insertions(+), 41 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
b/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
index dfa799adac2e..699a1ead1a40 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
@@ -1,17 +1,4 @@
#!/bin/sh
-###
-# This script is used to automatically set up the serial console(s) on startup.
-# The variable SERIAL_CONSOLES can be set in meta/conf/machine/*.conf.
-# Script enhancement has been done based on Bug YOCTO #10844.
-# Most of the information is retrieved from /proc virtual filesystem containing
-# all the runtime system information (eg. system memory, device mount, etc).
-###
-
-# Get active serial filename.
-active_serial=$(grep "serial" /proc/tty/drivers | cut -d/ -f1 | sed "s/ *$//")
-
-# Rephrase input parameter from ttyS target index (ttyS1, ttyS2, ttyAMA0, etc).
-runtime_tty=$(echo $2 | grep -oh '[0-9]\+')
# busybox' getty does this itself, util-linux' agetty needs extra help
getty="/sbin/getty"
@@ -25,31 +12,6 @@ case $(readlink -f "${getty}") in
;;
esac
-# Backup $IFS.
-DEFAULT_IFS=$IFS
-# Customize Internal Field Separator.
-IFS="$(printf '\n\t')"
-
-for line in $active_serial; do
- # Check we have the file containing current active serial target index.
- if [ -e "/proc/tty/driver/$line" ]
-then
- # Remove all unknown entries and discard the first line (desc).
- activetty=$(grep -v "unknown" "/proc/tty/driver/$line" \
- | tail -n +2 | grep -oh "^\s*\S*[0-9]\+")
- for active in $activetty; do
- # If indexes do match then enable the serial console.
- if [ $active -eq $runtime_tty ]
- then
- if [ -c /dev/$2 ]
- then
- ${setsid:-} ${getty} -L $1 $2 $3
- fi
- break
- fi
- done
- fi
-done
-
-# Restore $IFS.
-IFS=$DEFAULT_IFS
+if [ -e /sys/class/tty/$2 -a -c /dev/$2 ]; then
+ ${setsid:-} ${getty} -L $1 $2 $3
+fi
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150266):
https://lists.openembedded.org/g/openembedded-core/message/150266
Mute This Topic: https://lists.openembedded.org/mt/81913955/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] modutils-initscripts: Bail out when no module is installed
Fix the following warning when boot with a core-image-minimal rootfs: depmod: can't change directory to 'lib/modules/5.10.25-yocto-standard': No such file or directory Signed-off-by: Kevin Hao --- meta/recipes-kernel/modutils-initscripts/files/modutils.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-kernel/modutils-initscripts/files/modutils.sh b/meta/recipes-kernel/modutils-initscripts/files/modutils.sh index 28fe6f92d77f..67e1dcd9907e 100755 --- a/meta/recipes-kernel/modutils-initscripts/files/modutils.sh +++ b/meta/recipes-kernel/modutils-initscripts/files/modutils.sh @@ -13,6 +13,7 @@ LOAD_MODULE=modprobe [ -f /proc/modules ] || exit 0 +[ -d /lib/modules/`uname -r` ] || exit 0 # Test if modules.dep exists and has a size greater than zero if [ ! -s /lib/modules/`uname -r`/modules.dep ]; then -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150265): https://lists.openembedded.org/g/openembedded-core/message/150265 Mute This Topic: https://lists.openembedded.org/mt/81913954/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] Revert "inittab: Add getty launch on hvc0 for qemuppc64"
This reverts commit ed69ef20167da0986bc9363d1a91e62001995af4.
The console entry has already been added into /etc/inittab based
on the SERIAL_CONSOLES. So drop this redundant entry.
Signed-off-by: Kevin Hao
---
meta/recipes-core/busybox/busybox-inittab_1.33.0.bb| 3 ---
meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 4
2 files changed, 7 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox-inittab_1.33.0.bb
b/meta/recipes-core/busybox/busybox-inittab_1.33.0.bb
index 0021e45511d7..3804f4f7b2d0 100644
--- a/meta/recipes-core/busybox/busybox-inittab_1.33.0.bb
+++ b/meta/recipes-core/busybox/busybox-inittab_1.33.0.bb
@@ -44,9 +44,6 @@ EOF
fi
}
-do_install_append_qemuppc64 () {
-echo "9:12345:respawn:${base_sbindir}/getty 38400 hvc0" >>
${D}${sysconfdir}/inittab
-}
pkg_postinst_${PN} () {
# run this on host and on target
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 0af116f35cbd..d95d1a63f5c4 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -53,10 +53,6 @@ EOF
fi
}
-do_install_append_qemuppc64 () {
-echo "9:12345:respawn:${base_sbindir}/getty 38400 hvc0" >>
${D}${sysconfdir}/inittab
-}
-
pkg_postinst_${PN} () {
# run this on host and on target
if [ "${SERIAL_CONSOLES_CHECK}" = "" ]; then
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150267):
https://lists.openembedded.org/g/openembedded-core/message/150267
Mute This Topic: https://lists.openembedded.org/mt/81913956/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 0/3] Fixes two warnings when boot with qemuppc64
Fixes two following warnings: depmod: can't change directory to 'lib/modules/5.10.25-yocto-standard': No such file or directory INIT: Id "hvc0" respawning too fast: disabled for 5 minutes Kevin Hao (3): modutils-initscripts: Bail out when no module is installed sysvinit-inittab/start_getty: Check /sys for the tty device existence Revert "inittab: Add getty launch on hvc0 for qemuppc64" .../busybox/busybox-inittab_1.33.0.bb | 3 -- .../sysvinit/sysvinit-inittab/start_getty | 44 ++- .../sysvinit/sysvinit-inittab_2.88dsf.bb | 4 -- .../modutils-initscripts/files/modutils.sh| 1 + 4 files changed, 4 insertions(+), 48 deletions(-) -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150264): https://lists.openembedded.org/g/openembedded-core/message/150264 Mute This Topic: https://lists.openembedded.org/mt/81913952/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
The OCTEON TX2 core is custom designed by Marvell and is compliant
with Arm V8.2 architecture.
Signed-off-by: Kevin Hao
---
.../machine/include/arm/armv8-2a/tune-octeontx2.inc | 13 +
1 file changed, 13 insertions(+)
create mode 100644 meta/conf/machine/include/arm/armv8-2a/tune-octeontx2.inc
diff --git a/meta/conf/machine/include/arm/armv8-2a/tune-octeontx2.inc
b/meta/conf/machine/include/arm/armv8-2a/tune-octeontx2.inc
new file mode 100644
index ..f873b9517e23
--- /dev/null
+++ b/meta/conf/machine/include/arm/armv8-2a/tune-octeontx2.inc
@@ -0,0 +1,13 @@
+DEFAULTTUNE ?= "octeontx2"
+
+TUNEVALID[octeontx2] = "Enable Marvell octeontx2 specific processor
optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'octeontx2', '
-mcpu=octeontx2', '', d)}"
+
+require conf/machine/include/arm/arch-armv8-2a.inc
+
+# Little Endian base configs
+AVAILTUNES += "octeontx2"
+ARMPKGARCH_tune-octeontx2 = "octeontx2"
+TUNE_FEATURES_tune-octeontx2 = "${TUNE_FEATURES_tune-armv8-2a-crypto}
octeontx2"
+PACKAGE_EXTRA_ARCHS_tune-octeontx2=
"${PACKAGE_EXTRA_ARCHS_tune-armv8-2a-crypto} octeontx2"
+BASE_LIB_tune-octeontx2 = "lib64"
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145340):
https://lists.openembedded.org/g/openembedded-core/message/145340
Mute This Topic: https://lists.openembedded.org/mt/78774556/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] wic/filemap: Drop the unused get_unmapped_ranges()
This method is not used by any code, so drop it.
Signed-off-by: Kevin Hao
---
scripts/lib/wic/filemap.py | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index 8cfed5afa80d..f8c6e09d017f 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -155,15 +155,6 @@ class _FilemapBase(object):
raise Error("the method is not implemented")
-def get_unmapped_ranges(self, start, count): # pylint: disable=W0613,R0201
-"""
-This method has has to be implemented by child classes. Just like
-'get_mapped_ranges()', but yields unmapped block ranges instead
-(holes).
-"""
-
-raise Error("the method is not implemented")
-
# The 'SEEK_HOLE' and 'SEEK_DATA' options of the file seek system call
_SEEK_DATA = 3
@@ -258,9 +249,8 @@ class FilemapSeek(_FilemapBase):
def _get_ranges(self, start, count, whence1, whence2):
"""
-This function implements 'get_mapped_ranges()' and
-'get_unmapped_ranges()' depending on what is passed in the 'whence1'
-and 'whence2' arguments.
+This function implements 'get_mapped_ranges()' depending
+on what is passed in the 'whence1' and 'whence2' arguments.
"""
assert whence1 != whence2
@@ -290,12 +280,6 @@ class FilemapSeek(_FilemapBase):
% (start, count, start + count - 1))
return self._get_ranges(start, count, _SEEK_DATA, _SEEK_HOLE)
-def get_unmapped_ranges(self, start, count):
-"""Refer the '_FilemapBase' class for the documentation."""
-self._log.debug("FilemapSeek: get_unmapped_ranges(%d, %d(%d))"
-% (start, count, start + count - 1))
-return self._get_ranges(start, count, _SEEK_HOLE, _SEEK_DATA)
-
# Below goes the FIEMAP ioctl implementation, which is not very readable
# because it deals with the rather complex FIEMAP ioctl. To understand the
@@ -485,24 +469,6 @@ class FilemapFiemap(_FilemapBase):
% (first_prev, last_prev))
yield (first_prev, last_prev)
-def get_unmapped_ranges(self, start, count):
-"""Refer the '_FilemapBase' class for the documentation."""
-self._log.debug("FilemapFiemap: get_unmapped_ranges(%d, %d(%d))"
-% (start, count, start + count - 1))
-hole_first = start
-for first, last in self._do_get_mapped_ranges(start, count):
-if first > hole_first:
-self._log.debug("FilemapFiemap: yielding range (%d, %d)"
-% (hole_first, first - 1))
-yield (hole_first, first - 1)
-
-hole_first = last + 1
-
-if hole_first < start + count:
-self._log.debug("FilemapFiemap: yielding range (%d, %d)"
-% (hole_first, start + count - 1))
-yield (hole_first, start + count - 1)
-
def filemap(image, log=None):
"""
Create and return an instance of a Filemap class - 'FilemapFiemap' or
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140605):
https://lists.openembedded.org/g/openembedded-core/message/140605
Mute This Topic: https://lists.openembedded.org/mt/75490255/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] wic/filemap: Fall back to standard copy when no way to get the block map
For some filesystems, such as aufs which may be used by docker container,
don't support either the SEEK_DATA/HOLE or FIEMAP to get the block
map. So add a FileNobmap class to fall back to standard copy when there
is no way to get the block map.
[Yocto #12988]
Signed-off-by: Kevin Hao
---
scripts/lib/wic/filemap.py | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index f8c6e09d017f..4d9da281720c 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -469,6 +469,29 @@ class FilemapFiemap(_FilemapBase):
% (first_prev, last_prev))
yield (first_prev, last_prev)
+class FilemapNobmap(_FilemapBase):
+"""
+This class is used when both the 'SEEK_DATA/HOLE' and FIEMAP are not
+supported by the filesystem or kernel.
+"""
+
+def __init__(self, image, log=None):
+"""Refer the '_FilemapBase' class for the documentation."""
+
+# Call the base class constructor first
+_FilemapBase.__init__(self, image, log)
+self._log.debug("FilemapNobmap: initializing")
+
+def block_is_mapped(self, block):
+"""Refer the '_FilemapBase' class for the documentation."""
+return True
+
+def get_mapped_ranges(self, start, count):
+"""Refer the '_FilemapBase' class for the documentation."""
+self._log.debug("FilemapNobmap: get_mapped_ranges(%d, %d(%d))"
+% (start, count, start + count - 1))
+yield (start, start + count -1)
+
def filemap(image, log=None):
"""
Create and return an instance of a Filemap class - 'FilemapFiemap' or
@@ -482,7 +505,10 @@ def filemap(image, log=None):
try:
return FilemapFiemap(image, log)
except ErrorNotSupp:
-return FilemapSeek(image, log)
+try:
+return FilemapSeek(image, log)
+except ErrorNotSupp:
+return FilemapNobmap(image, log)
def sparse_copy(src_fname, dst_fname, skip=0, seek=0,
length=0, api=None):
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140606):
https://lists.openembedded.org/g/openembedded-core/message/140606
Mute This Topic: https://lists.openembedded.org/mt/75490256/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 0/3] wic: Fix a bug when running "wic rm" on an aufs filesystem
When running "wic rm" on a docker container which use the aufs as a storage driver, the wic would raise a exception since both SEEK_DATA/HOLE and FIEMAP are not supported on aufs filesystem. This patch series fixes this problem by introducing a new class to fall back to the standard copy in this case. Kevin Hao (3): wic/filemap: Drop the unused block_is_unmapped() wic/filemap: Drop the unused get_unmapped_ranges() wic/filemap: Fall back to standard copy when no way to get the block map scripts/lib/wic/filemap.py | 75 +- 1 file changed, 25 insertions(+), 50 deletions(-) -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140603): https://lists.openembedded.org/g/openembedded-core/message/140603 Mute This Topic: https://lists.openembedded.org/mt/75490253/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] wic/filemap: Drop the unused block_is_unmapped()
This method is not used by any code, so drop it.
Signed-off-by: Kevin Hao
---
scripts/lib/wic/filemap.py | 17 -
1 file changed, 17 deletions(-)
diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index c53147c2f18e..8cfed5afa80d 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -142,15 +142,6 @@ class _FilemapBase(object):
raise Error("the method is not implemented")
-def block_is_unmapped(self, block): # pylint: disable=W0613,R0201
-"""
-This method has has to be implemented by child classes. It returns
-'True' if block number 'block' of the image file is not mapped (hole)
-and 'False' otherwise.
-"""
-
-raise Error("the method is not implemented")
-
def get_mapped_ranges(self, start, count): # pylint: disable=W0613,R0201
"""
This method has has to be implemented by child classes. This is a
@@ -265,10 +256,6 @@ class FilemapSeek(_FilemapBase):
% (block, result))
return result
-def block_is_unmapped(self, block):
-"""Refer the '_FilemapBase' class for the documentation."""
-return not self.block_is_mapped(block)
-
def _get_ranges(self, start, count, whence1, whence2):
"""
This function implements 'get_mapped_ranges()' and
@@ -422,10 +409,6 @@ class FilemapFiemap(_FilemapBase):
% (block, result))
return result
-def block_is_unmapped(self, block):
-"""Refer the '_FilemapBase' class for the documentation."""
-return not self.block_is_mapped(block)
-
def _unpack_fiemap_extent(self, index):
"""
Unpack a 'struct fiemap_extent' structure object number 'index' from
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140604):
https://lists.openembedded.org/g/openembedded-core/message/140604
Mute This Topic: https://lists.openembedded.org/mt/75490254/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] linux-yocto-dev: Bump to 5.6-rcx
The -dev kernel has been upgraded to v5.6-rcx and the COPYING file in
the kernel source was updated by kernel commit 74835c7db032 ("COPYING:
state that all contributions really are covered by this file"). So we
should also update the md5 checksum of the COPYING file in the
linux-yocto-dev.bb in order to make the -dev kernel buildable.
Also update the LINUX_VERSION at the same time.
Signed-off-by: Kevin Hao
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index c364a97cba4b..06a9108fab49 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -30,11 +30,11 @@ SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
SRCREV_machine ?=
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e",
d)}'
SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e",
d)}'
-LINUX_VERSION ?= "5.5-rc+"
+LINUX_VERSION ?= "5.6-rc+"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git${SRCPV}"
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
DEPENDS += "openssl-native util-linux-native"
--
2.25.1.377.g2d2118b814c1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136575):
https://lists.openembedded.org/g/Openembedded-core/message/136575
Mute This Topic: https://lists.openembedded.org/mt/72439942/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/Openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] selftest: wic: Add APPEND to the optional variables list
The APPEND is an optional variable, so add it to the optional variables
list to make the wic selftest happy.
Signed-off-by: Kevin Hao
---
meta/lib/oeqa/selftest/cases/wic.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/wic.py
b/meta/lib/oeqa/selftest/cases/wic.py
index 46cd98b1934d..626a217e69fa 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -537,7 +537,8 @@ class Wic2(WicTestCase):
# filter out optional variables
wicvars = wicvars.difference(('DEPLOY_DIR_IMAGE', 'IMAGE_BOOT_FILES',
'INITRD', 'INITRD_LIVE',
'ISODIR','INITRAMFS_IMAGE',
- 'INITRAMFS_IMAGE_BUNDLE',
'INITRAMFS_LINK_NAME'))
+ 'INITRAMFS_IMAGE_BUNDLE',
'INITRAMFS_LINK_NAME',
+ 'APPEND'))
with open(path) as envfile:
content = dict(line.split("=", 1) for line in envfile)
# test if variables used by wic present in the .env file
--
2.25.0.389.gbfdd66e72fff
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic: Honor APPEND
On Sat, Feb 15, 2020 at 08:07:34AM +, Richard Purdie wrote:
> On Thu, 2020-02-13 at 10:31 +0800, Kevin Hao wrote:
> > APPEND is used to add additional parameters to kernel by features,
> > such
> > as read-only-rootfs. So we should honor this variable when we compose
> > the kernel parameter in wic. I know we also can resolve this kind of
> > issue by using the .wks.in template introduced by commit 42e870c5ed4b
> > ("image_types.bbclass: support template .wks.in files for wic"), but
> > the
> > APPEND is needed by all the wks, it would seems pretty ridiculous to
> > me
> > to change all the .wks to .wks.in and then foist the APPEND into
> > them.
> > So the APPEND is definitely deserved to export to the wic directly.
> >
> > [Yocto #12809]
> >
> > Signed-off-by: Kevin Hao
> > ---
> > meta/classes/image_types_wic.bbclass | 2 +-
> > scripts/lib/wic/ksparser.py | 5 +
> > 2 files changed, 6 insertions(+), 1 deletion(-)
>
> This seems to cause a selftest failure:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/688
>
> oe-selftest -r wic.Wic2.test_image_env
The APPEND is optional, so I should add it in the optional variables list
in wic.Wic2.test_image_env. The fix is coming soon.
Thanks,
Kevin
>
> Cheers,
>
> Richard
>
signature.asc
Description: PGP signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: Honor APPEND
APPEND is used to add additional parameters to kernel by features, such
as read-only-rootfs. So we should honor this variable when we compose
the kernel parameter in wic. I know we also can resolve this kind of
issue by using the .wks.in template introduced by commit 42e870c5ed4b
("image_types.bbclass: support template .wks.in files for wic"), but the
APPEND is needed by all the wks, it would seems pretty ridiculous to me
to change all the .wks to .wks.in and then foist the APPEND into them.
So the APPEND is definitely deserved to export to the wic directly.
[Yocto #12809]
Signed-off-by: Kevin Hao
---
meta/classes/image_types_wic.bbclass | 2 +-
scripts/lib/wic/ksparser.py | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index fc9b106a9a81..b83308b45cb5 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -4,7 +4,7 @@ WICVARS ?= "\
BBLAYERS IMGDEPLOYDIR DEPLOY_DIR_IMAGE FAKEROOTCMD IMAGE_BASENAME
IMAGE_BOOT_FILES \
IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES INITRD INITRD_LIVE
ISODIR RECIPE_SYSROOT_NATIVE \
ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS \
- KERNEL_IMAGETYPE MACHINE INITRAMFS_IMAGE INITRAMFS_IMAGE_BUNDLE
INITRAMFS_LINK_NAME"
+ KERNEL_IMAGETYPE MACHINE INITRAMFS_IMAGE INITRAMFS_IMAGE_BUNDLE
INITRAMFS_LINK_NAME APPEND"
inherit ${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1',
'kernel-artifact-names', '', d)}
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 707a2e801962..650b976223e0 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -246,6 +246,11 @@ class KickStart():
elif line.startswith('bootloader'):
if not self.bootloader:
self.bootloader = parsed
+# Concatenate the strings set in APPEND
+append_var = get_bitbake_var("APPEND")
+if append_var:
+self.bootloader.append = ' '.join(filter(None,
\
+
(self.bootloader.append, append_var)))
else:
err = "%s:%d: more than one bootloader specified" \
% (confpath, lineno)
--
2.25.0.191.gde93cc14ab7e
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xserver-nodm-init: Fix the start failure for non-root user
In order to start the xserver, a non-root user should have the
cap_sys_admin capability to set the drm master. We try to get
the cap_sys_admin capability by setting it in both the thread
and file inheritable set. The side effect of this is that we
would have to add the "pam" to the distro features if we want
use the xserver-nodm-init for a non-root user.
[Yocto #11526]
Signed-off-by: Kevin Hao
---
.../x11-common/xserver-nodm-init/capability.conf | 2 ++
.../x11-common/xserver-nodm-init/xserver-nodm | 8
meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb | 7 +--
3 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
b/meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
new file mode 100644
index ..7ab7460816a8
--- /dev/null
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
@@ -0,0 +1,2 @@
+cap_sys_admin @USER@
+none *
diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
index 6c548551b870..116bb278bc9b 100755
--- a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
@@ -38,6 +38,14 @@ case "$1" in
if [ -e /dev/hidraw0 ]; then
chmod o+rw /dev/hidraw*
fi
+ # Make sure that the Xorg has the cap_sys_admin capability which is
+ # needed for setting the drm master
+ if ! grep -q "^auth.*pam_cap\.so" /etc/pam.d/su; then
+ echo "auth optionalpam_cap.so" >>/etc/pam.d/su
+ fi
+ if ! /usr/sbin/getcap $XSERVER | grep -q cap_sys_admin; then
+ /usr/sbin/setcap cap_sys_admin+eip $XSERVER
+ fi
fi
# Using su rather than sudo as latest 1.8.1 cause failure [YOCTO #1211]
diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb
b/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb
index 385fea5e8399..c2995f99ffe1 100644
--- a/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb
@@ -10,6 +10,7 @@ SRC_URI = "file://xserver-nodm \
file://gplv2-license.patch \
file://xserver-nodm.service.in \
file://xserver-nodm.conf.in \
+ file://capability.conf \
"
S = "${WORKDIR}"
@@ -19,7 +20,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
inherit update-rc.d systemd features_check
-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 ${@oe.utils.conditional('ROOTLESS_X', '1',
'pam', '', d)}"
PACKAGECONFIG ??= "blank"
# dpms and screen saver will be on only if 'blank' is in PACKAGECONFIG
@@ -40,6 +41,8 @@ do_install() {
if [ "${ROOTLESS_X}" = "1" ] ; then
XUSER_HOME="/home/xuser"
XUSER="xuser"
+install -D capability.conf ${D}${sysconfdir}/security/capability.conf
+sed -i "s:@USER@:${XUSER}:" ${D}${sysconfdir}/security/capability.conf
else
XUSER_HOME=${ROOT_HOME}
XUSER="root"
@@ -60,7 +63,7 @@ do_install() {
fi
}
-RDEPENDS_${PN} = "xinit ${@oe.utils.conditional('ROOTLESS_X', '1',
'xuser-account', '', d)}"
+RDEPENDS_${PN} = "xinit ${@oe.utils.conditional('ROOTLESS_X', '1',
'xuser-account libcap libcap-bin', '', d)}"
INITSCRIPT_NAME = "xserver-nodm"
INITSCRIPT_PARAMS = "start 9 5 . stop 20 0 1 2 3 6 ."
--
2.21.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] psplash: Avoid mount the psplash tmpfs twice
The /etc/init.d/psplash.sh will be invoked both in boot and shutdown/reboot. And the psplash tmpfs will be mounted twice. This will trigger a bug in umount and let the system hang when shutdown/reboot. I already made a patch [1] to fix the issue in umount, but there is no reason for the psplash to do the twice mount. So also fix it. [Yocto 13461] [1] https://lore.kernel.org/util-linux/20190819083022.12289-1-kexin@windriver.com/T/#u Signed-off-by: Kevin Hao --- meta/recipes-core/psplash/files/psplash-init | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/psplash/files/psplash-init b/meta/recipes-core/psplash/files/psplash-init index fee23e681cfb..dcb751907f41 100755 --- a/meta/recipes-core/psplash/files/psplash-init +++ b/meta/recipes-core/psplash/files/psplash-init @@ -25,7 +25,9 @@ done export TMPDIR=/mnt/.psplash [ -d $TMPDIR ] || mkdir -p $TMPDIR -mount tmpfs -t tmpfs $TMPDIR -o,size=40k +if [ ! mountpoint -q $TMPDIR ]; then + mount tmpfs -t tmpfs $TMPDIR -o,size=40k +fi rotation=0 if [ -e /etc/rotation ]; then -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tune-thunderx: Set the correct PACKAGE_EXTRA_ARCHS_tune-thunderx
The value of PACKAGE_EXTRA_ARCHS_tune-thunderx should be based on
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto instead of armv8a-crc-crypto.
Otherwise we would get some sanity check error like this:
OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker
(see sanity.conf).
Following is the list of potential problems / advisories:
Error, the PACKAGE_ARCHS variable (all any noarch armv8a-crc-crypto
thunderx qemuarm64) for DEFAULTTUNE (thunderx) does not contain TUNE_PKGARCH
(aarch64)
Signed-off-by: Kevin Hao
---
meta/conf/machine/include/tune-thunderx.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-thunderx.inc
b/meta/conf/machine/include/tune-thunderx.inc
index 92adf2df1fce..aa4d0501d400 100644
--- a/meta/conf/machine/include/tune-thunderx.inc
+++ b/meta/conf/machine/include/tune-thunderx.inc
@@ -15,5 +15,5 @@ TUNE_FEATURES_tune-thunderx_be =
"${TUNE_FEATURES_tune-thunderx} bigendian"
BASE_LIB_tune-thunderx = "lib64"
BASE_LIB_tune-thunderx_be = "lib64"
-PACKAGE_EXTRA_ARCHS_tune-thunderx = "armv8a-crc-crypto thunderx"
+PACKAGE_EXTRA_ARCHS_tune-thunderx =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} thunderx"
PACKAGE_EXTRA_ARCHS_tune-thunderx_be = "aarch64_be thunderx_be"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] runqemu: Add the support to pass multi ports to tcpserial parameter
In some cases(such as the oeqa's qemurunner), we need to setup multi
serial devices via the '-serial 127.0.0.1:xx" and the order of them
is significant. The mixing use of "tcpserial" and "-serial 127.0.0.1:xx"
cause ambiguous issues and we can't fix it by only adjusting the order
of them. So add the support to pass multi ports to the tcpserial
parameter, this will make sure that the order of setting up the serial
is really what we want.
[YOCTO Bug 13309]
Signed-off-by: Kevin Hao
---
scripts/runqemu | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 5752ecda731c..af90c010da28 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -438,7 +438,7 @@ class BaseConfig(object):
elif arg == 'publicvnc':
self.qemu_opt_script += ' -vnc :0'
elif arg.startswith('tcpserial='):
-self.tcpserial_portnum = arg[len('tcpserial='):]
+self.tcpserial_portnum = '%s' % arg[len('tcpserial='):]
elif arg.startswith('biosdir='):
self.custombiosdir = arg[len('biosdir='):]
elif arg.startswith('biosfilename='):
@@ -682,10 +682,16 @@ class BaseConfig(object):
def check_tcpserial(self):
if self.tcpserial_portnum:
+ports = self.tcpserial_portnum.split(':')
+port = ports[0]
if self.get('QB_TCPSERIAL_OPT'):
-self.qemu_opt_script += ' ' +
self.get('QB_TCPSERIAL_OPT').replace('@PORT@', self.tcpserial_portnum)
+self.qemu_opt_script += ' ' +
self.get('QB_TCPSERIAL_OPT').replace('@PORT@', port)
else:
-self.qemu_opt_script += ' -serial tcp:127.0.0.1:%s' %
self.tcpserial_portnum
+self.qemu_opt_script += ' -serial tcp:127.0.0.1:%s' % port
+
+if len(ports) > 1:
+for port in ports[1:]:
+self.qemu_opt_script += ' -serial tcp:127.0.0.1:%s' % port
def check_and_set(self):
"""Check configs sanity and set when needed"""
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] oeqa/utils/qemurunner: Set both the threadport with tcpserial parameter
After the commit ad522ea6a64e ("runqemu: Let qemuparams override default
settings"), the order of the two "-serial" parameters when running the
qemu have been switched. The effect of this is that the logging thread
will use ttyS1 (of course can't capture the kernel boot message anymore),
and the test command will run on the ttyS0. So the output of the test
command may be mangled by the kernel message (such as call trace), and
let the test command produce a fake timeout error message. We can't fix
it by just adjusting the order of the threadport and serverport, since
it will break some machines such as qemuarm64 which use the virtio
serial. So using the tcpserial to setup both the threadport and
serverport.
[YOCTO Bug 13309]
Signed-off-by: Kevin Hao
---
meta/lib/oeqa/utils/qemurunner.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index fd386ef5a20a..6d2860c1061a 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -155,11 +155,11 @@ class QemuRunner:
# and analyze descendents in order to determine it.
if os.path.exists(self.qemu_pidfile):
os.remove(self.qemu_pidfile)
-self.qemuparams = 'bootparams="{0}" qemuparams="-serial
tcp:127.0.0.1:{1} -pidfile {2}"'.format(bootparams, threadport,
self.qemu_pidfile)
+self.qemuparams = 'bootparams="{0}" qemuparams="-pidfile
{1}"'.format(bootparams, self.qemu_pidfile)
if qemuparams:
self.qemuparams = self.qemuparams[:-1] + " " + qemuparams + " " +
'\"'
-launch_cmd += ' tcpserial=%s %s' % (self.serverport, self.qemuparams)
+launch_cmd += ' tcpserial=%s:%s %s' % (threadport, self.serverport,
self.qemuparams)
self.origchldhandler = signal.getsignal(signal.SIGCHLD)
signal.signal(signal.SIGCHLD, self.handleSIGCHLD)
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-modules: upgrade 2.10.8 -> 2.10.9
On Wed, May 08, 2019 at 09:38:50PM +0100, richard.pur...@linuxfoundation.org wrote: > On Wed, 2019-05-08 at 23:30 +0300, Adrian Bunk wrote: > > On Wed, May 08, 2019 at 09:06:19PM +0100, Richard Purdie wrote: > > > On Tue, 2019-05-07 at 16:11 +0300, Adrian Bunk wrote: > > > > Remove the backported patches. > > > > > > > > Signed-off-by: Adrian Bunk > > > > > > Unfortunately this seemed to cause: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/574 > > > > ... > > recipe linux-yocto-4.19.14+gitAUTOINC+9bda6190bf_eebb51300a-r0: task > > do_compile: Succeeded > > ... > > In file included from > > /home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/lttng-kprobes.c:31: > > > /home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/../blacklist/kprobes.h:19:4: > > > error: #error "Your kernel is known to have buggy optimized kprobes > > > implementation. Fixed by commit 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c > > > \"ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction\" in > > > Linux. Disable CONFIG_OPTPROBES or upgrade your kernel." > > > # error "Your kernel is known to have buggy optimized kprobes > > > implementation. Fixed by commit 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c > > > \"ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction\" in > > > Linux. Disable CONFIG_OPTPROBES or upgrade your kernel." > > > ^ > > > make[4]: *** > > [/home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/lttng-kprobes.o] > > Error 1 > > ... > > > > > > Upstream turned a runtime breakage into a build failure: > > http://git.lttng.org/?p=lttng-modules.git;a=commit;h=2d16de12b197aed57212826187bcb0ab24ad071e > > > > IOW, this needs an update of beaglebone-yocto in > > meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend > > (4.19.34 already seems to be in the git tree). > > Right, sorry, I hadn't actually read the error :/. > > CCing Kevin/Bruce. I just sent out a patch to bump the kernel version for these BSPs. Thanks, Kevin > > Cheers, > > Richard > > > signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] udev-extraconf: Skip the entry in /etc/fstab when using the systemd-mount
When using systemd, the systemd-fstab-generator would parse the
/etc/fstab and create the corresponding unit dynamically. So we don't
need to handle the ADD action for the partitions in /etc/fstab.
Signed-off-by: Kevin Hao
---
meta/recipes-core/udev/udev-extraconf/mount.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index afb368dd6737..3ee67b13183a 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -38,6 +38,15 @@ done
automount_systemd() {
name="`basename "$DEVNAME"`"
+# Skip the partition which are already in /etc/fstab
+grep "^[[:space:]]*$DEVNAME" /etc/fstab && return
+for n in LABEL PARTLABEL UUID PARTUUID; do
+tmp="$(lsblk -o $n $DEVNAME | sed -e '1d')"
+test -z "$tmp" && continue
+tmp="$n=$tmp"
+grep "^[[:space:]]*$tmp" /etc/fstab && return
+done
+
[ -d "/run/media/$name" ] || mkdir -p "/run/media/$name"
MOUNT="$MOUNT -o silent"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] udev-extraconf: Use the canonical file name of systemd
The new version of systemd has changed the symbolic link between /sbin/init and /lib/systemd/systemd to relative. So the output of the command 'readlink /sbin/init' become: ../lib/systemd/systemd Then it causes the following check of "/lib/systemd/systemd" to return false. Fix this issue by using the canonical file name of the systemd. Signed-off-by: Kevin Hao --- meta/recipes-core/udev/udev-extraconf/mount.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh b/meta/recipes-core/udev/udev-extraconf/mount.sh index 067d4e2a16fb..34ef98a6a882 100644 --- a/meta/recipes-core/udev/udev-extraconf/mount.sh +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh @@ -4,7 +4,7 @@ # # Attempt to mount any added block devices and umount any removed devices -BASE_INIT="`readlink "@base_sbindir@/init"`" +BASE_INIT="`readlink -f "@base_sbindir@/init"`" INIT_SYSTEMD="@systemd_unitdir@/systemd" if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] udev-extraconf: Fix the recursively dependency for the systemd-mount
The commit 4ca9402c3720 ("udev-extraconf: Add systemd-mount to
udev-extraconf/mount.sh") uses the systemd-mount to mount the new added
disk partitions if systemd is used. But it forgot to move the codes
which tries to mount the partition by using the configuration in
/etc/fstab to the non-systemd function. And it will cause the
systemd-mount try to mount the partition synchronously and trigger a
recursively dependency like the following:
dev-sda1.device -> run-media-sda1.mount -> dev-sda1.device
Signed-off-by: Kevin Hao
---
meta/recipes-core/udev/udev-extraconf/mount.sh | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index 34ef98a6a882..afb368dd6737 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -66,6 +66,16 @@ automount_systemd() {
automount() {
name="`basename "$DEVNAME"`"
+ if [ -x "$PMOUNT" ]; then
+ $PMOUNT $DEVNAME 2> /dev/null
+ elif [ -x $MOUNT ]; then
+ $MOUNT $DEVNAME 2> /dev/null
+ fi
+
+ # If the device isn't mounted at this point, it isn't
+ # configured in fstab
+ grep -q "^$DEVNAME " /proc/mounts && return
+
! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
# Silent util-linux's version of mounting auto
if [ "x`readlink $MOUNT`" = "x/bin/mount.util-linux" ] ;
@@ -109,20 +119,13 @@ name="`basename "$DEVNAME"`"
[ -e /sys/block/$name/device/media ] && media_type=`cat
/sys/block/$name/device/media`
if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o
"$media_type" = "cdrom" ]; then
- if [ -x "$PMOUNT" ]; then
- $PMOUNT $DEVNAME 2> /dev/null
- elif [ -x $MOUNT ]; then
- $MOUNT $DEVNAME 2> /dev/null
- fi
-
- # If the device isn't mounted at this point, it isn't
- # configured in fstab (note the root filesystem can show up as
- # /dev/root in /proc/mounts, so check the device number too)
+# Note the root filesystem can show up as /dev/root in /proc/mounts,
+# so check the device number too
if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
if [ "`basename $MOUNT`" = "systemd-mount" ];then
-grep -q "^$DEVNAME " /proc/mounts || automount_systemd
+automount_systemd
else
-grep -q "^$DEVNAME " /proc/mounts || automount
+automount
fi
fi
fi
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] udev-extraconf: Fix the automount malfunction when the systemd is used
When we use the systemd as the init manager, the automount function doesn't work at all. This patch series fixes this issue. The patch 2&3 have been posted by Hongzhi one month ago [1], but they aren't merged yet. I have rebased them on the latest oe-core and also fix the author info since it is me to scratch these patches originally. :-) Kevin Hao (3): udev-extraconf: Use the canonical file name of systemd udev-extraconf: Fix the recursively dependency for the systemd-mount udev-extraconf: Skip the entry in /etc/fstab when using the systemd-mount meta/recipes-core/udev/udev-extraconf/mount.sh | 36 +- 1 file changed, 24 insertions(+), 12 deletions(-) [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-September/155724.html Thanks, Kevin -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] Fix the build failure when creating a multilib wic
We have observed the following build failure when building lib32-core-image-minimal for a qemux86-64 machine. DEBUG: | ERROR: Couldn't find correct bootimg_dir, exiting | ERROR: Couldn't find correct bootimg_dir, exiting DEBUG: | This patch series tries to fix this issue. You can use the following steps to reproduce this issue: 1. source .../git/poky/oe-init-build-env and set the MACHINE to "qemux86-64" 2. Add the following to conf/local.conf: IMAGE_FSTYPES = "wic" MULTILIBS = "multilib:lib32" require conf/multilib.conf DEFAULTTUNE_virtclass-multilib-lib32 = "x86" 3. bitbake lib32-core-image-minimal Kevin Hao (4): wic: bootimg-pcbios: Drop the unnecessary reference of STAGING_DATADIR wic: isoimage-isohybrid: Drop the unnecessary reference of STAGING_DATADIR bitbake.conf: Introduce variables used to access the other recipe specific sysroot directory in multilib case wic: Set the right bootimg_dir when building a multilib image meta/classes/image_types_wic.bbclass | 2 +- meta/conf/bitbake.conf | 4 meta/conf/multilib.conf | 1 + scripts/lib/wic/plugins/source/bootimg-pcbios.py | 7 +++ scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 13 - scripts/wic | 2 +- 6 files changed, 14 insertions(+), 15 deletions(-) -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] bitbake.conf: Introduce variables used to access the other recipe specific sysroot directory in multilib case
When multilib is enabled, there would be two different recipe specific
sysroot directories:
libxx-recipe-sysroot
recipe-sysroot
We do need to access the files under the "recipe-sysroot" directory in
some cases. So introduces these variables for this purpose.
Signed-off-by: Kevin Hao
---
meta/conf/bitbake.conf | 4
meta/conf/multilib.conf | 1 +
2 files changed, 5 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 93aee1ae4628..b7e3e5ca26df 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -370,6 +370,7 @@ STAGING_DIR = "${TMPDIR}/sysroots"
COMPONENTS_DIR = "${STAGING_DIR}-components"
RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
RECIPE_SYSROOT_NATIVE = "${WORKDIR}/recipe-sysroot-native"
+RECIPE_ALT_SYSROOT = "${RECIPE_SYSROOT}"
STAGING_DIR_NATIVE = "${RECIPE_SYSROOT_NATIVE}"
STAGING_BINDIR_NATIVE = "${STAGING_DIR_NATIVE}${bindir_native}"
@@ -394,6 +395,9 @@ STAGING_EXECPREFIXDIR = "${STAGING_DIR_HOST}${exec_prefix}"
STAGING_LOADER_DIR = "${STAGING_DIR_HOST}/loader"
STAGING_FIRMWARE_DIR = "${STAGING_DIR_HOST}/firmware"
+STAGING_ALT_DIR_HOST = "${RECIPE_ALT_SYSROOT}"
+STAGING_ALT_DATADIR = "${STAGING_ALT_DIR_HOST}${datadir}"
+
STAGING_DIR_TARGET = "${RECIPE_SYSROOT}"
# Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index e74dec81a897..4dd824fdb273 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -9,6 +9,7 @@ MULTILIBS ??= "multilib:lib32"
STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
+RECIPE_ALT_SYSROOT = "${WORKDIR}/recipe-sysroot"
INHERIT += "multilib_global"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] wic: Set the right bootimg_dir when building a multilib image
When building a multilib image (such as lib32-xxx), we do want the
bootloader to be build in the 64bit mode. So it will be installed into
a directory like:
.../lib32-core-image-minimal/1.0-r0/recipe-sysroot/usr/share/
In this case, we need to set the bootimg_dir to use the value of
STAGING_ALT_DATADIR.
Signed-off-by: Kevin Hao
---
meta/classes/image_types_wic.bbclass | 2 +-
scripts/wic | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index 5b40a9e919f2..241e52b3e9f2 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -3,7 +3,7 @@
WICVARS ?= "\
BBLAYERS IMGDEPLOYDIR DEPLOY_DIR_IMAGE FAKEROOTCMD IMAGE_BASENAME
IMAGE_BOOT_FILES \
IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES INITRD INITRD_LIVE
ISODIR RECIPE_SYSROOT_NATIVE \
- ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS"
+ ROOTFS_SIZE STAGING_ALT_DATADIR STAGING_DIR STAGING_LIBDIR
TARGET_SYS"
WKS_FILE ??= "${IMAGE_BASENAME}.${MACHINE}.wks"
WKS_FILES ?= "${WKS_FILE} ${IMAGE_BASENAME}.wks"
diff --git a/scripts/wic b/scripts/wic
index 7392bc4e7f49..067acaabf030 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -166,7 +166,7 @@ def wic_create_subcommand(options, usage_str):
rootfs_dir = get_bitbake_var("IMAGE_ROOTFS", options.image_name)
kernel_dir = get_bitbake_var("DEPLOY_DIR_IMAGE", options.image_name)
-bootimg_dir = get_bitbake_var("STAGING_DATADIR", options.image_name)
+bootimg_dir = get_bitbake_var("STAGING_ALT_DATADIR",
options.image_name)
native_sysroot = options.native_sysroot
if options.vars_dir and not native_sysroot:
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] wic: bootimg-pcbios: Drop the unnecessary reference of STAGING_DATADIR
Actually the bootimg_dir is the value of STAGING_DATADIR, so we don't
need to check this directory twice times.
Signed-off-by: Kevin Hao
---
scripts/lib/wic/plugins/source/bootimg-pcbios.py | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
index d599112dd759..dc7b76cf22a7 100644
--- a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
+++ b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
@@ -45,11 +45,10 @@ class BootimgPcbiosPlugin(SourcePlugin):
@classmethod
def _get_bootimg_dir(cls, bootimg_dir, dirname):
"""
-Check if dirname exists in default bootimg_dir or in STAGING_DIR.
+Check if dirname exists in default bootimg_dir
"""
-for result in (bootimg_dir, get_bitbake_var("STAGING_DATADIR")):
-if os.path.exists("%s/%s" % (result, dirname)):
-return result
+if os.path.exists("%s/%s" % (bootimg_dir, dirname)):
+return bootimg_dir
raise WicError("Couldn't find correct bootimg_dir, exiting")
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] wic: isoimage-isohybrid: Drop the unnecessary reference of STAGING_DATADIR
Actually the bootimg_dir is the value of the STAGING_DATADIR, so we
can use it directly.
Signed-off-by: Kevin Hao
---
scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 170077c22c21..d9c7b55f03c5 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -360,11 +360,6 @@ class IsoImagePlugin(SourcePlugin):
chmod_cmd = "chmod 644 %s" % bootimg
exec_cmd(chmod_cmd)
-# Prepare files for legacy boot
-syslinux_dir = get_bitbake_var("STAGING_DATADIR")
-if not syslinux_dir:
-raise WicError("Couldn't find STAGING_DATADIR, exiting.")
-
if os.path.exists("%s/isolinux" % isodir):
shutil.rmtree("%s/isolinux" % isodir)
@@ -373,19 +368,19 @@ class IsoImagePlugin(SourcePlugin):
cls.do_configure_syslinux(creator, cr_workdir)
-install_cmd = "install -m 444 %s/syslinux/ldlinux.sys " % syslinux_dir
+install_cmd = "install -m 444 %s/syslinux/ldlinux.sys " % bootimg_dir
install_cmd += "%s/isolinux/ldlinux.sys" % isodir
exec_cmd(install_cmd)
-install_cmd = "install -m 444 %s/syslinux/isohdpfx.bin " % syslinux_dir
+install_cmd = "install -m 444 %s/syslinux/isohdpfx.bin " % bootimg_dir
install_cmd += "%s/isolinux/isohdpfx.bin" % isodir
exec_cmd(install_cmd)
-install_cmd = "install -m 644 %s/syslinux/isolinux.bin " % syslinux_dir
+install_cmd = "install -m 644 %s/syslinux/isolinux.bin " % bootimg_dir
install_cmd += "%s/isolinux/isolinux.bin" % isodir
exec_cmd(install_cmd)
-install_cmd = "install -m 644 %s/syslinux/ldlinux.c32 " % syslinux_dir
+install_cmd = "install -m 644 %s/syslinux/ldlinux.c32 " % bootimg_dir
install_cmd += "%s/isolinux/ldlinux.c32" % isodir
exec_cmd(install_cmd)
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] wic: Introduce the --use-label partition parameter
On Thu, Sep 13, 2018 at 10:38:09AM +0800, Anuj Mittal wrote: > On 09/12/2018 08:44 AM, Kevin Hao wrote: > > + --use-label: This option is specific to wic. It makes wic to use > > the > > + label in /etc/fstab to specify a partition. If the > > + --use-label and --use-uuid are used at the same time, > > + we prefer the uuid because it is less likely to cause > > + name confliction. We don't support using this > > parameter > > + on the root partition since it requires an initramfs > > to > > + parse this value and we do not currently support > > that. > > + > > --active: Marks the partition as active. > > Would this also need a corresponding patch for yocto-docs as well? Sure. Thanks for reminding me. I will compose a patch to update the docs. Thanks, Kevin > > Thanks, > > Anuj signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] wic: Introduce the --use-label partition parameter
We can use this parameter to make the wic use the label to name a
partition in /etc/fstab.
Signed-off-by: Kevin Hao
Reviewed-by: Tom Rini
---
v3: No change since v2, just rebase on the master branch.
scripts/lib/wic/help.py | 18 +-
scripts/lib/wic/ksparser.py | 14 --
scripts/lib/wic/partition.py | 1 +
scripts/lib/wic/plugins/imager/direct.py | 2 ++
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 842b868a575a..64f08052c7a7 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -866,11 +866,11 @@ DESCRIPTION
Partitions with a specified will be automatically mounted.
This is achieved by wic adding entries to the fstab during image
generation. In order for a valid fstab to be generated one of the
- --ondrive, --ondisk or --use-uuid partition options must be used for
- each partition that specifies a mountpoint. Note that with --use-uuid
- and non-root , including swap, the mount program must
- understand the PARTUUID syntax. This currently excludes the busybox
- versions of these applications.
+ --ondrive, --ondisk, --use-uuid or --use-label partition options must
+ be used for each partition that specifies a mountpoint. Note that with
+ --use-{uuid,label} and non-root , including swap, the mount
+ program must understand the PARTUUID or LABEL syntax. This currently
+ excludes the busybox versions of these applications.
The following are supported 'part' options:
@@ -945,6 +945,14 @@ DESCRIPTION
label is already in use by another filesystem,
a new label is created for the partition.
+ --use-label: This option is specific to wic. It makes wic to use the
+ label in /etc/fstab to specify a partition. If the
+ --use-label and --use-uuid are used at the same time,
+ we prefer the uuid because it is less likely to cause
+ name confliction. We don't support using this parameter
+ on the root partition since it requires an initramfs to
+ parse this value and we do not currently support that.
+
--active: Marks the partition as active.
--align (in KBytes): This option is specific to wic and says
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index a5d29189b9b5..7e5a9c5092b0 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -141,6 +141,7 @@ class KickStart():
'squashfs', 'vfat', 'msdos', 'swap'))
part.add_argument('--mkfs-extraopts', default='')
part.add_argument('--label')
+part.add_argument('--use-label', action='store_true')
part.add_argument('--no-table', action='store_true')
part.add_argument('--ondisk', '--ondrive', dest='disk', default='sda')
part.add_argument("--overhead-factor", type=overheadtype)
@@ -197,8 +198,17 @@ class KickStart():
(confpath, lineno, err))
if line.startswith('part'):
# SquashFS does not support filesystem UUID
-if parsed.fstype == 'squashfs' and parsed.fsuuid:
-err = "%s:%d: SquashFS does not support UUID" \
+if parsed.fstype == 'squashfs':
+if parsed.fsuuid:
+err = "%s:%d: SquashFS does not support UUID" \
+ % (confpath, lineno)
+raise KickStartError(err)
+if parsed.label:
+err = "%s:%d: SquashFS does not support LABEL"
\
+ % (confpath, lineno)
+raise KickStartError(err)
+if parsed.use_label and not parsed.label:
+err = "%s:%d: Must set the label with --label" \
% (confpath, lineno)
raise KickStartError(err)
# using ArgumentParser one cannot easily tell if option
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 5054779b1b6b..3da7e23e617e 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -47,6 +47,7 @@ class Partition():
self.fsopts = args.fsopts
self.fstype = args.fstype
self.label = args.label
+self.use_label = args.use_label
self.mkfs_extraopts = args.mkfs_extraopts
self.mountpoint = args.mountpoint
self.no_table = args.no_table
diff --git a/scripts/l
[OE-core] [PATCH v2] wic: Introduce the --use-label partition parameter
We can use this parameter to make the wic use the label to name a
partition in /etc/fstab.
Signed-off-by: Kevin Hao
Reviewed-by: Tom Rini
---
v2:
- Rephrase the help info
- Rebase on the Emmanuel's patch
http://lists.openembedded.org/pipermail/openembedded-core/2018-September/155414.html
scripts/lib/wic/help.py | 18 +-
scripts/lib/wic/ksparser.py | 14 --
scripts/lib/wic/partition.py | 1 +
scripts/lib/wic/plugins/imager/direct.py | 2 ++
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 842b868a575a..64f08052c7a7 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -866,11 +866,11 @@ DESCRIPTION
Partitions with a specified will be automatically mounted.
This is achieved by wic adding entries to the fstab during image
generation. In order for a valid fstab to be generated one of the
- --ondrive, --ondisk or --use-uuid partition options must be used for
- each partition that specifies a mountpoint. Note that with --use-uuid
- and non-root , including swap, the mount program must
- understand the PARTUUID syntax. This currently excludes the busybox
- versions of these applications.
+ --ondrive, --ondisk, --use-uuid or --use-label partition options must
+ be used for each partition that specifies a mountpoint. Note that with
+ --use-{uuid,label} and non-root , including swap, the mount
+ program must understand the PARTUUID or LABEL syntax. This currently
+ excludes the busybox versions of these applications.
The following are supported 'part' options:
@@ -945,6 +945,14 @@ DESCRIPTION
label is already in use by another filesystem,
a new label is created for the partition.
+ --use-label: This option is specific to wic. It makes wic to use the
+ label in /etc/fstab to specify a partition. If the
+ --use-label and --use-uuid are used at the same time,
+ we prefer the uuid because it is less likely to cause
+ name confliction. We don't support using this parameter
+ on the root partition since it requires an initramfs to
+ parse this value and we do not currently support that.
+
--active: Marks the partition as active.
--align (in KBytes): This option is specific to wic and says
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index a5d29189b9b5..7e5a9c5092b0 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -141,6 +141,7 @@ class KickStart():
'squashfs', 'vfat', 'msdos', 'swap'))
part.add_argument('--mkfs-extraopts', default='')
part.add_argument('--label')
+part.add_argument('--use-label', action='store_true')
part.add_argument('--no-table', action='store_true')
part.add_argument('--ondisk', '--ondrive', dest='disk', default='sda')
part.add_argument("--overhead-factor", type=overheadtype)
@@ -197,8 +198,17 @@ class KickStart():
(confpath, lineno, err))
if line.startswith('part'):
# SquashFS does not support filesystem UUID
-if parsed.fstype == 'squashfs' and parsed.fsuuid:
-err = "%s:%d: SquashFS does not support UUID" \
+if parsed.fstype == 'squashfs':
+if parsed.fsuuid:
+err = "%s:%d: SquashFS does not support UUID" \
+ % (confpath, lineno)
+raise KickStartError(err)
+if parsed.label:
+err = "%s:%d: SquashFS does not support LABEL"
\
+ % (confpath, lineno)
+raise KickStartError(err)
+if parsed.use_label and not parsed.label:
+err = "%s:%d: Must set the label with --label" \
% (confpath, lineno)
raise KickStartError(err)
# using ArgumentParser one cannot easily tell if option
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 5054779b1b6b..3da7e23e617e 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -47,6 +47,7 @@ class Partition():
self.fsopts = args.fsopts
self.fstype = args.fstype
self.label = args.label
+self.use_label = args.use_label
self.mkfs_extraopts = args.mkfs_ex
Re: [OE-core] [PATCH] wic: Introduce the --use-label partition parameter
On Thu, Sep 06, 2018 at 09:27:39AM -0400, Tom Rini wrote:
> On Thu, Sep 06, 2018 at 09:11:20PM +0800, Kevin Hao wrote:
>
> > We can use this parameter to make the wic use the label to name a
> > partition in /etc/fstab.
> >
> > Signed-off-by: Kevin Hao
>
> Reviewed-by: Tom Rini
>
> A few minor things below:
>
> [snip]
> > @@ -945,6 +945,14 @@ DESCRIPTION
> > label is already in use by another filesystem,
> > a new label is created for the partition.
> >
> > + --use-label: This option is specific to wic. It makes wic to use
> > the
> > + label in /etc/fstab to specify a partition. If the
> > + --use-label and --use-uuid are used at the same time,
> > + we prefer the uuid because it is less likely to cause
> > + name confliction. We don't support to use this
> > parameter
> > + on a root partition since the kernel can't
> > understand the
> > + LABEL syntax.
>
> I think we should have the last sentence read more like:
> We don't support using this parameter on the root partition since it
> requires an initramfs to parse this value and we do not currently
> support that.
>
> Only because while what you said is correct, this makes it clear what
> would be needed to support it.
Absolutely. I will rephrase it as what you suggested.
>
> > @@ -197,10 +198,14 @@ class KickStart():
> > (confpath, lineno, err))
> > if line.startswith('part'):
> > # SquashFS does not support UUID
> > -if parsed.fstype == 'squashfs' and parsed.use_uuid:
> > +if parsed.fstype == 'squashfs' and
> > (parsed.use_uuid or parsed.use_label):
> > err = "%s:%d: SquashFS does not support UUID" \
> >% (confpath, lineno)
> > raise KickStartError(err)
>
> This hunk is going to conflict with Emmanuel's patch. Further I think
> it should be a separate check on fstype == squashfs and (label &&
> use_label) with a label-specific error message. Thanks!
Thanks for the notice. I will rebase on the Emmanuel's new version patch.
Thanks,
Kevin
>
> --
> Tom
signature.asc
Description: PGP signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: Introduce the --use-label partition parameter
We can use this parameter to make the wic use the label to name a
partition in /etc/fstab.
Signed-off-by: Kevin Hao
---
scripts/lib/wic/help.py | 18 +-
scripts/lib/wic/ksparser.py | 7 ++-
scripts/lib/wic/partition.py | 1 +
scripts/lib/wic/plugins/imager/direct.py | 2 ++
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 842b868a575a..e250e130ef46 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -866,11 +866,11 @@ DESCRIPTION
Partitions with a specified will be automatically mounted.
This is achieved by wic adding entries to the fstab during image
generation. In order for a valid fstab to be generated one of the
- --ondrive, --ondisk or --use-uuid partition options must be used for
- each partition that specifies a mountpoint. Note that with --use-uuid
- and non-root , including swap, the mount program must
- understand the PARTUUID syntax. This currently excludes the busybox
- versions of these applications.
+ --ondrive, --ondisk, --use-uuid or --use-label partition options must
+ be used for each partition that specifies a mountpoint. Note that with
+ --use-{uuid,label} and non-root , including swap, the mount
+ program must understand the PARTUUID or LABEL syntax. This currently
+ excludes the busybox versions of these applications.
The following are supported 'part' options:
@@ -945,6 +945,14 @@ DESCRIPTION
label is already in use by another filesystem,
a new label is created for the partition.
+ --use-label: This option is specific to wic. It makes wic to use the
+ label in /etc/fstab to specify a partition. If the
+ --use-label and --use-uuid are used at the same time,
+ we prefer the uuid because it is less likely to cause
+ name confliction. We don't support to use this parameter
+ on a root partition since the kernel can't understand the
+ LABEL syntax.
+
--active: Marks the partition as active.
--align (in KBytes): This option is specific to wic and says
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index e590b2fe3c0d..220495b76654 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -141,6 +141,7 @@ class KickStart():
'squashfs', 'vfat', 'msdos', 'swap'))
part.add_argument('--mkfs-extraopts', default='')
part.add_argument('--label')
+part.add_argument('--use-label', action='store_true')
part.add_argument('--no-table', action='store_true')
part.add_argument('--ondisk', '--ondrive', dest='disk', default='sda')
part.add_argument("--overhead-factor", type=overheadtype)
@@ -197,10 +198,14 @@ class KickStart():
(confpath, lineno, err))
if line.startswith('part'):
# SquashFS does not support UUID
-if parsed.fstype == 'squashfs' and parsed.use_uuid:
+if parsed.fstype == 'squashfs' and (parsed.use_uuid or
parsed.use_label):
err = "%s:%d: SquashFS does not support UUID" \
% (confpath, lineno)
raise KickStartError(err)
+if parsed.use_label and not parsed.label:
+err = "%s:%d: Must set the label with --label" \
+ % (confpath, lineno)
+raise KickStartError(err)
# using ArgumentParser one cannot easily tell if option
# was passed as argument, if said option has a default
# value; --overhead-factor/--extra-space cannot be used
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 5054779b1b6b..3da7e23e617e 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -47,6 +47,7 @@ class Partition():
self.fsopts = args.fsopts
self.fstype = args.fstype
self.label = args.label
+self.use_label = args.use_label
self.mkfs_extraopts = args.mkfs_extraopts
self.mountpoint = args.mountpoint
self.no_table = args.no_table
diff --git a/scripts/lib/wic/plugins/imager/direct.py
b/scripts/lib/wic/plugins/imager/direct.py
index 81583e97b9f7..bb14a334b2ce 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -155,6 +155,8 @@ class DirectPlugin(ImagerPlugin):
device_name = "UUID=%s&q
[OE-core] [PATCH 2/2] wic: bootimg-partition: Select a preferred type if multi kernel images are installed
Automatically select one kernel type image based on a predefined
precedence list if there are multi kernel images installed.
Signed-off-by: Kevin Hao
---
.../lib/wic/plugins/source/bootimg-partition.py| 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 2e9b9f5ed657..ddc880be366f 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -130,24 +130,28 @@ class BootimgPartitionPlugin(SourcePlugin):
if not custom_cfg:
# The kernel types supported by the sysboot of u-boot
-kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
+kernel_types = ["zImage", "Image", "fitImage", "uImage", "vmlinux"]
has_dtb = False
fdt_dir = '/'
kernel_name = None
-for task in cls.install_task:
-src, dst = task
-# Find the kernel image name
-for image in kernel_types:
+
+# Find the kernel image name, from the highest precedence to lowest
+for image in kernel_types:
+for task in cls.install_task:
+src, dst = task
if re.match(image, src):
-if not kernel_name:
-kernel_name = os.path.join('/', dst)
-else:
-raise WicError('Multi kernel file founded')
+kernel_name = os.path.join('/', dst)
+break
+if kernel_name:
+break
+for task in cls.install_task:
+src, dst = task
# We suppose that all the dtb are in the same directory
if re.search(r'\.dtb', src) and fdt_dir == '/':
has_dtb = True
fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
+break
if not kernel_name:
raise WicError('No kernel file founded')
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] wic: bootimg-partition: Add support to specify a custom extlinux.conf
Add support to specify a custom extlinux.conf via something like:
bootloader --configfile="extlinux.conf"
Signed-off-by: Kevin Hao
---
.../lib/wic/plugins/source/bootimg-partition.py| 79 +-
1 file changed, 47 insertions(+), 32 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 7d61595d0414..2e9b9f5ed657 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -30,6 +30,7 @@ import re
from glob import glob
from wic import WicError
+from wic.engine import get_custom_config
from wic.pluginbase import SourcePlugin
from wic.misc import exec_cmd, get_bitbake_var
@@ -114,38 +115,52 @@ class BootimgPartitionPlugin(SourcePlugin):
if source_params.get('loader') != "u-boot":
return
-# The kernel types supported by the sysboot of u-boot
-kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
-has_dtb = False
-fdt_dir = '/'
-kernel_name = None
-for task in cls.install_task:
-src, dst = task
-# Find the kernel image name
-for image in kernel_types:
-if re.match(image, src):
-if not kernel_name:
-kernel_name = os.path.join('/', dst)
-else:
-raise WicError('Multi kernel file founded')
-
-# We suppose that all the dtb are in the same directory
-if re.search(r'\.dtb', src) and fdt_dir == '/':
-has_dtb = True
-fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
-
-if not kernel_name:
-raise WicError('No kernel file founded')
-
-# Compose the extlinux.conf
-extlinux_conf = "default Yocto\n"
-extlinux_conf += "label Yocto\n"
-extlinux_conf += " kernel %s\n" % kernel_name
-if has_dtb:
-extlinux_conf += " fdtdir %s\n" % fdt_dir
-bootloader = cr.ks.bootloader
-extlinux_conf += "append root=%s rootwait %s\n" \
- % (cr.rootdev, bootloader.append if bootloader.append
else '')
+configfile = cr.ks.bootloader.configfile
+custom_cfg = None
+if configfile:
+custom_cfg = get_custom_config(configfile)
+if custom_cfg:
+# Use a custom configuration for extlinux.conf
+extlinux_conf = custom_cfg
+logger.debug("Using custom configuration file "
+ "%s for extlinux.cfg", configfile)
+else:
+raise WicError("configfile is specified but failed to "
+ "get it from %s." % configfile)
+
+if not custom_cfg:
+# The kernel types supported by the sysboot of u-boot
+kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
+has_dtb = False
+fdt_dir = '/'
+kernel_name = None
+for task in cls.install_task:
+src, dst = task
+# Find the kernel image name
+for image in kernel_types:
+if re.match(image, src):
+if not kernel_name:
+kernel_name = os.path.join('/', dst)
+else:
+raise WicError('Multi kernel file founded')
+
+# We suppose that all the dtb are in the same directory
+if re.search(r'\.dtb', src) and fdt_dir == '/':
+has_dtb = True
+fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
+
+if not kernel_name:
+raise WicError('No kernel file founded')
+
+# Compose the extlinux.conf
+extlinux_conf = "default Yocto\n"
+extlinux_conf += "label Yocto\n"
+extlinux_conf += " kernel %s\n" % kernel_name
+if has_dtb:
+extlinux_conf += " fdtdir %s\n" % fdt_dir
+bootloader = cr.ks.bootloader
+extlinux_conf += "append root=%s rootwait %s\n" \
+ % (cr.rootdev, bootloader.append if
bootloader.append else '')
install_cmd = "install -d %s/extlinux/" % hdddir
exec_cmd(install_cmd)
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 00/12] Add GCC 8 recipes
On Thu, Jun 07, 2018 at 11:42:08AM +0100, Richard Purdie wrote: > On Wed, 2018-06-06 at 20:45 -0400, Bruce Ashfield wrote: > > > > > > On Wed, Jun 6, 2018 at 5:37 PM, Khem Raj wrote: > > > This changeset is including the review feedback from last patchset > > > > > > - Fixes ppc such that we dont have to change machine options so it > > > remains backward compatible and folks can still use gcc7 > > > - Tweaks arm tunes to set -mtune instead of -mcpu, this avoids > > > conflicts between -march/-mcpu > > > - Removes workarounds to avoid these conflicts in valgrind > > > - Add mips 74kc tune files > > > - Linux yocto changes are also part of Bruce's kernel updates but > > > this makes it complete until those changes are pulled in > > > > Correct. I have all of the gcc8 patches in linux-yocto 4.12/4.14/4.15 > > and linux-yocto-dev. > > > > They should have been covered by my last set of SRCREV updates, and I > > noticed that > > some are in, and some not. > > > > I'll resubmit my SRCREV queue tomorrow, and that will cover the gcc8 > > angle. > > Thanks. Khem's series failed since it doesn't cover 4.14, Bruce's > patchset helped a lot. > > It looks like we have kernel failures with: > > MACHINE="mpc8315e-rdb" DISTRO="poky-lsb" in linux-yocto 4.14 > https://autobuilder.yocto.io/builders/nightly-ppc-lsb/builds/1051/steps/BuildImages_1/logs/stdio > > MACHINE="mpc8315e-rdb" DISTRO="poky" in linux-yocto 4.15 > https://autobuilder.yocto.io/builders/nightly-ppc/builds/1066/steps/BuildImages_1/logs/stdio > > MACHINE="edgerouter" DISTRO="poky-lsb" in linux-yocto 4.14: > https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/1040/steps/BuildImages_1/logs/stdio > > MACHINE="edgerouter" DISTRO="poky" in linux-yocto 4.15: > https://autobuilder.yocto.io/builders/nightly-mips/builds/1044/steps/BuildImages_1/logs/stdio > > I realised the above may be due to missing BSP SRCREV updates (cc Kevin)? I will update the SRCREV for these boards ASAP. Thanks, Kevin > > With gcc 8, it seems we have a problem with meta-mingw: > > https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/1062/steps/BuildImages_3/logs/stdio > > The build isn't finished but I'm hoping these are the main remaining > issues. > > Cheers, > > Richard > > > > > > > > signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] wic: plugins: rawcopy: Add support to download the raw image from a http server
On Sun, Dec 10, 2017 at 10:53:43PM -0200, Otavio Salvador wrote: > On Sat, Dec 9, 2017 at 12:45 AM, Kevin Hao <kexin@windriver.com> wrote: > > Some firmwares are critical for the basic functions of the board, and may > > be used by the bootloader. Due to the license issue, we can't integrate > > it. But we do need it when creating a booting image by using WIC. > > So add the support for the WIC to download a raw file from http > > server and write it to a specific part. In order to restrict the > > downloading behaviour, we introduce a "WKS_ALLOW_DOWNLOAD" variable and > > only do the downloading when this variable is set. > > > > Signed-off-by: Kevin Hao <kexin@windriver.com> > > This does not make much sense. > > It does not allow to be downloaded? so build system can download it > and use it as a normal artifact. In some cases, it doesn't make sense to do so. Because: a) These firmwares are just raw binary files, they don't need any build or process. They are only useful when we try to create a bootable image. b) There firmwares may be licensed under a proprietary license. We may not integrate them to a fully open source build system. But we do want to provide an easy way for the customer to build a bootable image. Thanks, Kevin >Adding another source way seems > controversial. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] wic: plugins: rawcopy: support to add offset when writing the raw image
In some cases we need to skip some reserved sectors when writing a raw image. So add support to set an offset for writing. Signed-off-by: Kevin Hao <kexin@windriver.com> --- scripts/lib/wic/plugins/source/rawcopy.py | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/scripts/lib/wic/plugins/source/rawcopy.py b/scripts/lib/wic/plugins/source/rawcopy.py index 424ed26ed6ba..baf991fe8d5d 100644 --- a/scripts/lib/wic/plugins/source/rawcopy.py +++ b/scripts/lib/wic/plugins/source/rawcopy.py @@ -53,10 +53,9 @@ class RawCopyPlugin(SourcePlugin): src = os.path.join(kernel_dir, source_params['file']) dst = os.path.join(cr_workdir, "%s.%s" % (source_params['file'], part.lineno)) -if 'skip' in source_params: -sparse_copy(src, dst, skip=int(source_params['skip'])) -else: -sparse_copy(src, dst) +skip = 0 if 'skip' not in source_params else int(source_params['skip']) +seek = 0 if 'seek' not in source_params else int(source_params['seek']) +sparse_copy(src, dst, skip, seek) # get the size in the right units for kickstart (kB) du_cmd = "du -Lbks %s" % dst -- 2.9.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] wic: plugins: rawcopy: Add support to download the raw image from a http server
Some firmwares are critical for the basic functions of the board, and may
be used by the bootloader. Due to the license issue, we can't integrate
it. But we do need it when creating a booting image by using WIC.
So add the support for the WIC to download a raw file from http
server and write it to a specific part. In order to restrict the
downloading behaviour, we introduce a "WKS_ALLOW_DOWNLOAD" variable and
only do the downloading when this variable is set.
Signed-off-by: Kevin Hao <kexin@windriver.com>
---
meta/classes/image_types_wic.bbclass | 2 +-
scripts/lib/wic/plugins/source/rawcopy.py | 13 +++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index 222ae004338d..70858ad5d7a1 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -3,7 +3,7 @@
WICVARS ?= "\
BBLAYERS IMGDEPLOYDIR DEPLOY_DIR_IMAGE FAKEROOTCMD IMAGE_BASENAME
IMAGE_BOOT_FILES \
IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES INITRD INITRD_LIVE
ISODIR RECIPE_SYSROOT_NATIVE \
- ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS"
+ ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS
WKS_ALLOW_DOWNLOAD"
WKS_FILE ??= "${IMAGE_BASENAME}.${MACHINE}.wks"
WKS_FILES ?= "${WKS_FILE} ${IMAGE_BASENAME}.wks"
diff --git a/scripts/lib/wic/plugins/source/rawcopy.py
b/scripts/lib/wic/plugins/source/rawcopy.py
index baf991fe8d5d..808c279aed4c 100644
--- a/scripts/lib/wic/plugins/source/rawcopy.py
+++ b/scripts/lib/wic/plugins/source/rawcopy.py
@@ -50,8 +50,17 @@ class RawCopyPlugin(SourcePlugin):
if 'file' not in source_params:
raise WicError("No file specified")
-src = os.path.join(kernel_dir, source_params['file'])
-dst = os.path.join(cr_workdir, "%s.%s" % (source_params['file'],
part.lineno))
+if source_params['file'].startswith('http://') or
source_params['file'].startswith('https://'):
+# Only download the image from remote site when explicilty
requesting so
+if get_bitbake_var("WKS_ALLOW_DOWNLOAD") != "1":
+return
+src = os.path.join(cr_workdir, "%s" %
source_params['file'].rsplit('/',1)[-1])
+dst = "%s.dst" % src
+download_cmd = "wget -r -O %s %s" %(src, source_params['file'])
+exec_cmd(download_cmd)
+else:
+src = os.path.join(kernel_dir, source_params['file'])
+dst = os.path.join(cr_workdir, "%s.%s" % (source_params['file'],
part.lineno))
skip = 0 if 'skip' not in source_params else int(source_params['skip'])
seek = 0 if 'seek' not in source_params else int(source_params['seek'])
--
2.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/7] linux-yocto/4.10: fix aufs build
On Thu, Aug 31, 2017 at 03:30:58PM -0400, Bruce Ashfield wrote:
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.10.bb
> b/meta/recipes-kernel/linux/linux-yocto_4.10.bb
> index 4107891f6e8a..10b56cda77e7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.10.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.10.bb
> @@ -11,15 +11,15 @@ KBRANCH_qemux86 ?= "standard/base"
> KBRANCH_qemux86-64 ?= "standard/base"
> KBRANCH_qemumips64 ?= "standard/mti-malta64"
>
> -SRCREV_machine_qemuarm ?= "4c652d50c67050422da4621cc6421ecb86b31c31"
> -SRCREV_machine_qemuarm64 ?= "65370fa249e282e4ce69cf927c01898b4c16f261"
> -SRCREV_machine_qemumips ?= "0a632fa7f9615ad1b2488a300846a7e925e6591a"
> -SRCREV_machine_qemuppc ?= "65370fa249e282e4ce69cf927c01898b4c16f261"
> -SRCREV_machine_qemux86 ?= "65370fa249e282e4ce69cf927c01898b4c16f261"
> -SRCREV_machine_qemux86-64 ?= "65370fa249e282e4ce69cf927c01898b4c16f261"
> -SRCREV_machine_qemumips64 ?= "75c22c1be83bf7894af78a36b3e3c5af08ce4d7b"
> -SRCREV_machine ?= "65370fa249e282e4ce69cf927c01898b4c16f261"
> -SRCREV_meta ?= "6ac2680ca4316fe111cddec37def7757843bbe86"
> +SRCREV_machine_qemuarm ?= "97253eca8592c9cba7c7665277e1118b048b9639"
> +SRCREV_machine_qemuarm64 ?= "f4ba3db6e599ed41d1c676f9086ad8b97fd55046"
> +SRCREV_machine_qemumips ?= "52e935b59800868731e7620caf49cc257f1b9946"
> +SRCREV_machine_qemuppc ?= "f4ba3db6e599ed41d1c676f9086ad8b97fd55046"
> +SRCREV_machine_qemux86 ?= "f4ba3db6e599ed41d1c676f9086ad8b97fd55046"
> +SRCREV_machine_qemux86-64 ?= "f4ba3db6e599ed41d1c676f9086ad8b97fd55046"
> +SRCREV_machine_qemumips64 ?= "7b6d7feb4b0143d6f9146784f6072ffd171dd7ba"
> +SRCREV_machine ?= "f4ba3db6e599ed41d1c676f9086ad8b97fd55046"
Hi Bruce,
I didn't get these commits in linux-yocto-4.10 git tee? Did you forget to push
or I missed something?
Thanks,
Kevin
> +SRCREV_meta ?= "416a2862c3bac3ecb641bf14e14c1d2c9c23ed96"
>
> SRC_URI =
> "git://git.yoctoproject.org/linux-yocto-4.10.git;name=machine;branch=${KBRANCH};
> \
>
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
> --
> 2.5.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
signature.asc
Description: PGP signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel.bbclass: add the runtime dependency on kernel-vmlinux for kernel-image
When a BSP uses vmlinux for boot, the kernel-image package is just
empty. But by default the kernel-vmlinux is not installed. Then the
pkg_postinst_kernel-image() would create a symlink to a non-existent
file. Fix this by adding the runtime dependency on kernel-vmlinux for
kernel-image if the KERNEL_IMAGETYPE is vmlinux.
Signed-off-by: Kevin Hao kexin@windriver.com
---
meta/classes/kernel.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5318b5febef6..919293e43dba 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -361,6 +361,7 @@ RDEPENDS_kernel = kernel-base
# not wanted in images as standard
RDEPENDS_kernel-base ?= kernel-image
PKG_kernel-image =
kernel-image-${@legitimize_package_name('${KERNEL_VERSION}')}
+RDEPENDS_kernel-image += ${@base_conditional('KERNEL_IMAGETYPE', 'vmlinux',
'kernel-vmlinux', '', d)}
PKG_kernel-base = kernel-${@legitimize_package_name('${KERNEL_VERSION}')}
RPROVIDES_kernel-base += kernel-${KERNEL_VERSION}
ALLOW_EMPTY_kernel = 1
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] u-boot: fix extern inline build errors for gcc 5
The gcc 5 change its default standard from gnu89 to gnu11. These two
standards do have different semantics for inline functions. And the
gcc 5 will emit the following errors on the extern inline functions:
arch/powerpc/cpu/mpc8xxx/fsl_lbc.o: In function `ld_le16':
./arch/powerpc/include/asm/byteorder.h:12: multiple definition of `ld_le16'
arch/powerpc/cpu/mpc8xxx/fdt.o:./arch/powerpc/include/asm/byteorder.h:12:
first defined here
Fix these build errors by using -fgnu89-inline to enforce the gnu89
inline semantics as suggested in [1].
[1] https://gcc.gnu.org/gcc-5/porting_to.html
Signed-off-by: Kevin Hao kexin@windriver.com
---
meta/recipes-bsp/u-boot/u-boot_2015.07.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot_2015.07.bb
b/meta/recipes-bsp/u-boot/u-boot_2015.07.bb
index 3ba2f44eaa20..4746c33ec25e 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2015.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2015.07.bb
@@ -10,3 +10,5 @@ SRCREV = 33711bdd4a4dce942fb5ae85a68899a8357bdd94
SRC_URI +=
file://0001-u-boot-mpc85xx-u-boot-.lds-remove-_GLOBAL_OFFSET_TAB.patch
PV = v2015.07+git${SRCPV}
+
+EXTRA_OEMAKE_append = KCFLAGS=-fgnu89-inline
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] PCMCIA: remove the support for PCMCIA
PCMCIA is so uncommon in now days and was also removed by other distro
such as Debian [1]. So remove it from oe-core. Will move it to
meta-openembedded/meta-oe.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698105
Signed-off-by: Kevin Hao kexin@windriver.com
---
v2: Rebase on the latest codes.
meta/conf/distro/include/default-distrovars.inc| 2 +-
meta/conf/local.conf.sample.extended | 4 +-
.../0001-fix-a-parallel-building-issue.patch | 45 -
.../pcmciautils/pcmciautils-018/makefile_fix.patch | 101 -
meta/recipes-bsp/pcmciautils/pcmciautils.inc | 32 ---
meta/recipes-bsp/pcmciautils/pcmciautils_018.bb| 13 ---
.../packagegroups/packagegroup-base.bb | 31 +--
7 files changed, 7 insertions(+), 221 deletions(-)
delete mode 100644
meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
delete mode 100644
meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch
delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils.inc
delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
diff --git a/meta/conf/distro/include/default-distrovars.inc
b/meta/conf/distro/include/default-distrovars.inc
index 29b762b22733..2ad27a74c1c4 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -8,7 +8,7 @@ IMAGE_LINGUAS ?= en-us en-gb
ENABLE_BINARY_LOCALE_GENERATION ?= 1
LOCALE_UTF8_ONLY ?= 0
-DISTRO_FEATURES_DEFAULT ?= alsa argp bluetooth ext2 irda largefile pcmcia
usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11
+DISTRO_FEATURES_DEFAULT ?= alsa argp bluetooth ext2 irda largefile usbgadget
usbhost wifi xattr nfs zeroconf pci 3g nfc x11
DISTRO_FEATURES_LIBC_DEFAULT ?= ipv4 ipv6 libc-backtrace libc-big-macros
libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
libc-crypt-ufc libc-db-aliases
libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
libc-getlogin libc-idn libc-inet-anl
libc-libm libc-locales libc-locale-code \
diff --git a/meta/conf/local.conf.sample.extended
b/meta/conf/local.conf.sample.extended
index ccdd32682723..5e3521a9629f 100644
--- a/meta/conf/local.conf.sample.extended
+++ b/meta/conf/local.conf.sample.extended
@@ -36,10 +36,10 @@
# libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar
libc-posix-regexp libc-posix-regexp-glibc \
# libc-posix-wchar-io
-#DISTRO_FEATURES = alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs
zeroconf pci ${DISTRO_FEATURES_LIBC}
+#DISTRO_FEATURES = alsa bluetooth ext2 irda usbgadget usbhost wifi nfs
zeroconf pci ${DISTRO_FEATURES_LIBC}
# If you want to get an image based on directfb without x11, Please copy this
variable to build/conf/local.conf
-#DISTRO_FEATURES = alsa argp bluetooth ext2 irda largefile pcmcia usbgadget
usbhost wifi xattr nfs zeroconf pci 3g directfb ${DISTRO_FEATURES_LIBC}
+#DISTRO_FEATURES = alsa argp bluetooth ext2 irda largefile usbgadget usbhost
wifi xattr nfs zeroconf pci 3g directfb ${DISTRO_FEATURES_LIBC}
# ENABLE_BINARY_LOCALE_GENERATION controls the generation of binary locale
# packages at build time using qemu-native. Disabling it (by setting it to 0)
diff --git
a/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
b/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
deleted file mode 100644
index 7b010400f792..
---
a/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 5a793a1a9fb3477719aabf7e27ff22ed1acdf559 Mon Sep 17 00:00:00 2001
-From: Roy Li rongqing...@windriver.com
-Date: Tue, 19 May 2015 15:54:24 +0800
-Subject: [PATCH] fix a parallel building issue
-
-Fixed:
-| src/lex_config.c:34:25: fatal error: yacc_config.h: No such file or
directory
-|
-|#include yacc_config.h
-|^
-| compilation terminated.
-
-And:
-Compiling lex_config.c.
- src/lex_config.l:34:25: fatal error: yacc_config.h: No such file or directory
-
-Upstream-Status: Pending
-
-there are two Makefile rules to generate lex_config.o, one is to generate
-lex_config.o other is to generate src/lex_config.o, so we can remove one.
-and add the needed dependence for lex_config.o
-
-
-Signed-off-by: Roy Li rongqing...@windriver.com
- Makefile | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/Makefile b/Makefile
-index d45fdc3..4c53bc2 100644
a/Makefile
-+++ b/Makefile
-@@ -246,8 +246,7 @@ $(PCMCIA_SOCKET_STARTUP): $(LIBC) src/startup.o
src/yacc_config.o src/lex_config
- $(QUIET) $(LD) $(LDFLAGS) -o $@ $(CRT0) src/startup.o src/yacc_config.o
src/lex_config.o $(LIB_OBJS) $(ARCH_LIB_OBJS)
- $(QUIET) $(STRIPCMD) $@
-
--yacc_config.o lex_config.o: %.o: %.c
-- $(CC
[OE-core] [PATCH] PCMCIA: remove the support for PCMCIA
PCMCIA is so uncommon in now days and was also removed by other distro
such as Debian [1]. So remove it from oe-core. Will move it to
meta-openembedded/meta-oe.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698105
Signed-off-by: Kevin Hao kexin@windriver.com
---
meta/conf/bitbake.conf | 1 -
meta/conf/distro/include/default-distrovars.inc| 2 +-
meta/conf/local.conf.sample.extended | 4 +-
.../0001-fix-a-parallel-building-issue.patch | 45 -
.../pcmciautils/pcmciautils-018/makefile_fix.patch | 101 -
meta/recipes-bsp/pcmciautils/pcmciautils.inc | 32 ---
meta/recipes-bsp/pcmciautils/pcmciautils_018.bb| 13 ---
.../packagegroups/packagegroup-base.bb | 31 +--
8 files changed, 7 insertions(+), 222 deletions(-)
delete mode 100644
meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
delete mode 100644
meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch
delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils.inc
delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 8653a7f3a943..8194a475015b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -741,7 +741,6 @@ COMBINED_FEATURES = \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, ext2, d)} \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, vfat, d)} \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, irda, d)} \
-${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, pcmcia, d)} \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, pci, d)} \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, usbgadget,
d)} \
${@base_both_contain(DISTRO_FEATURES, MACHINE_FEATURES, usbhost, d)}
\
diff --git a/meta/conf/distro/include/default-distrovars.inc
b/meta/conf/distro/include/default-distrovars.inc
index 29b762b22733..2ad27a74c1c4 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -8,7 +8,7 @@ IMAGE_LINGUAS ?= en-us en-gb
ENABLE_BINARY_LOCALE_GENERATION ?= 1
LOCALE_UTF8_ONLY ?= 0
-DISTRO_FEATURES_DEFAULT ?= alsa argp bluetooth ext2 irda largefile pcmcia
usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11
+DISTRO_FEATURES_DEFAULT ?= alsa argp bluetooth ext2 irda largefile usbgadget
usbhost wifi xattr nfs zeroconf pci 3g nfc x11
DISTRO_FEATURES_LIBC_DEFAULT ?= ipv4 ipv6 libc-backtrace libc-big-macros
libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
libc-crypt-ufc libc-db-aliases
libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
libc-getlogin libc-idn libc-inet-anl
libc-libm libc-locales libc-locale-code \
diff --git a/meta/conf/local.conf.sample.extended
b/meta/conf/local.conf.sample.extended
index ccdd32682723..5e3521a9629f 100644
--- a/meta/conf/local.conf.sample.extended
+++ b/meta/conf/local.conf.sample.extended
@@ -36,10 +36,10 @@
# libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar
libc-posix-regexp libc-posix-regexp-glibc \
# libc-posix-wchar-io
-#DISTRO_FEATURES = alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs
zeroconf pci ${DISTRO_FEATURES_LIBC}
+#DISTRO_FEATURES = alsa bluetooth ext2 irda usbgadget usbhost wifi nfs
zeroconf pci ${DISTRO_FEATURES_LIBC}
# If you want to get an image based on directfb without x11, Please copy this
variable to build/conf/local.conf
-#DISTRO_FEATURES = alsa argp bluetooth ext2 irda largefile pcmcia usbgadget
usbhost wifi xattr nfs zeroconf pci 3g directfb ${DISTRO_FEATURES_LIBC}
+#DISTRO_FEATURES = alsa argp bluetooth ext2 irda largefile usbgadget usbhost
wifi xattr nfs zeroconf pci 3g directfb ${DISTRO_FEATURES_LIBC}
# ENABLE_BINARY_LOCALE_GENERATION controls the generation of binary locale
# packages at build time using qemu-native. Disabling it (by setting it to 0)
diff --git
a/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
b/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
deleted file mode 100644
index 7b010400f792..
---
a/meta/recipes-bsp/pcmciautils/pcmciautils-018/0001-fix-a-parallel-building-issue.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 5a793a1a9fb3477719aabf7e27ff22ed1acdf559 Mon Sep 17 00:00:00 2001
-From: Roy Li rongqing...@windriver.com
-Date: Tue, 19 May 2015 15:54:24 +0800
-Subject: [PATCH] fix a parallel building issue
-
-Fixed:
-| src/lex_config.c:34:25: fatal error: yacc_config.h: No such file or
directory
-|
-|#include yacc_config.h
-|^
-| compilation terminated.
-
-And:
-Compiling lex_config.c.
- src/lex_config.l:34:25: fatal error: yacc_config.h: No such file or directory
-
-Upstream-Status
