Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Ha, yes, thanks Bruce, it's just right time. Have a good trip ~ And I did a quick check, it's OK as well :) zchen@pek-lpggp4:$ bitbake linux-yocto-dev WARNING: You have included the meta-openstack layer, but 'openstack' has not been enabled in your DISTRO_FEATURES. Some bbappend files and preferred version setting may not take effect. See the meta-openstack README for details on enabling openstack support. Parsing recipes: 100% |#| Time: 0:00:38 Parsing of 3648 .bb files complete (0 cached, 3648 parsed). 8552 targets, 5849 skipped, 0 masked, 0 errors. WARNING: No recipes available for: /buildarea1/zchen/build-19/wr19-06-14-arm64/layers/meta-cloud-services/meta-openstack/recipes-connectivity/openssh/openssh_7.%.bbappend /buildarea1/zchen/build-19/wr19-06-14-arm64/layers/meta-cgl/meta-cgl-common/recipes-extended/umip/umip_%.bbappend WARNING: No bb files matched BBFILE_PATTERN_overc '' WARNING: No bb files matched BBFILE_PATTERN_cube '' WARNING: No bb files matched BBFILE_PATTERN_wrlinux-overc '' NOTE: Resolving any missing task queue dependencies Build Configuration: WRLINUX_VERSION = "10.19.24.0" WRLINUX_BRANCH = "development" BB_VERSION = "1.43.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "ubuntu-16.04" DISTRO = "wrlinux-std-sato" DISTRO_VERSION = "10.19.24.0" MACHINE = "xilinx-zynqmp" DEFAULTTUNE = "cortexa53" TARGET_SYS = "aarch64-wrs-linux" TUNE_FEATURES = "aarch64 cortexa53 crc" TARGET_FPU = "" lib32: DEFAULTTUNE = "armv7athf-neon" lib32: TARGET_SYS = "arm-wrsmllib32-linux-gnueabi" lib32: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" lib32: TARGET_FPU = "hard" wrlinux wrlinux-distro = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta = "wr-10.19-20190610:50529a3a7b1d6867d9e4ec9d47b21f56578444b4" meta-initramfs meta-xfce meta-oe meta-filesystems meta-webserver meta-networking meta-python meta-perl meta-gnome meta-multimedia = "wr-10.19-20190528:9facfad2b487cdc1b335b1073b9182040de9676e" meta-security = "wr-10.19-20190529:b73416279b6b7f1735146911bb953e9bb13eb08f" meta-selinux = "wr-10.19-20190424:a8ed51181e5444c82f9702b6b5d12ca575472a58" intel-x86 = "master-wr:ad411c10245aeb78e8509e9e7b9e888e2fc8eb6c" xilinx-zynqmp = "master:fbb6d4f0affbaae78dbdf8cbdf43d1655b227843" meta-virtualization = "wr-10.19-20190603:e5d65550a5d532501ff245e7cd2a76cc415bf1bc" meta-realtime = "wr-10.19-20190408:9074810c117fdde9cec4058ac9c17c84f0f50420" meta-mingw = "wr-10.19-20190508:714437ac9ba52a4e022b3b199819dbb609d9952e" wr-template = "master-wr:4f4e06413262e09e9eadbad427860218485bb3c3" meta-yocto-bsp meta-poky = "wr-10.19-20190610:2826a58f6a0c103a3938ea5c797ea17923e10902" meta-gplv2 = "wr-10.19-20190610:168a5070bdf3bc45edb5bf2a1add9b7c081f5b64" meta-efi-secure-boot meta-encrypted-storage meta-integrity meta-signing-key = "wr-10.19-20190610:e3ee3d8c9bd7033ccde8d5ce1e23893f3b215ea0" meta-cloud-services = "wr-10.19-20190610:31dfe4207c05faead77514e36cd8af8dabd334e6" meta meta-ids meta-tpm meta-tpm2 = "wr-10.19-20190610:e3ee3d8c9bd7033ccde8d5ce1e23893f3b215ea0" meta-openstack meta-openstack-aio-deploy meta-openstack-compute-deploy meta-openstack-compute-test-config meta-openstack-controller-deploy meta-openstack-controller-test-config meta-openstack-qemu meta-openstack-swift-deploy = "wr-10.19-20190610:31dfe4207c05faead77514e36cd8af8dabd334e6" meta-intel = "wr-10.19-20190610:e51ad5e08182f164077ca6a56a9220857043ad8e" wrlinux-ovp = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta-cgl-common = "wr-10.19-20190508:bfd0554ad9734a210b636f9f5bdc307df19b1e79" wrlinux-cgl = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta-dpdk = "wr-10.19-20190528:95dea5817da2b59a8ce4fa20be4bdcaef03e4e8c" meta-intel-qat = "wr-10.19-20190408:7a49ca357fc1a130d5de2d6862168901f7229b14" meta-anaconda = "wr-10.19-20190610:f0b82870061f17176c5873515749251a2e4bd7b4" meta-overc meta-cube = "wr-10.19-20190520:4f7c0427acdf9ccab4e734840f1149840311a813" meta-iot-cloud = "wr-10.19-20190415:6e522eb46e35173eee5f9dd920bd32638aa00a11" wrlinux-overc = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" wrlinux-overc-cfg = "master-wr:639a999f5b83640b075c0306ea53b3da8913522d" meta-selinux-dl = "master-wr:0e044fd49b16872966bf1d3c8e99d12df4bc6831" meta-mingw-dl = "master-wr:8fc9becbb6f0d96b86b55969238e69fb9d8d3bb5" meta-security-dl = "master-wr:d43ef6844eee8734f943f23e3e1a983b3094ca9e" meta-efi-secure-boot-dl = "master-wr:b79180d67c83c0fdf317c0583fa9a8e5fdb21b86"
Re: [yocto] [ptest-runner][PATCH] utils: ensure child can be session leader
On 6/13/19 6:39 PM, Randy MacLeod wrote: From: Sakib Sajal Oops. Sakib started on this and then had to work on something else so I finished it up. If needed, I'll send a v2 with me as the author, since "finishing up" was most of the work. We're both down as SOBs so whatever works. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH] utils: ensure child can be session leader
From: Sakib Sajal
When running the run-execscript bash ptest as a user rather than root, a
warning:
bash: cannot set terminal process group (16036): Inappropriate ioctl for
device
bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!
The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.
Also add '-lutil' to Makefile. This lib is from libc and provides openpty.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy MacLeod
---
Makefile | 2 +-
utils.c | 100 +--
2 files changed, 91 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
diff --git a/utils.c b/utils.c
index ad737c2..d8977c6 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
/**
* Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -22,23 +23,29 @@
*/
#define _GNU_SOURCE
+
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+
+
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-#include
#include "ptest_list.h"
#include "utils.h"
@@ -346,6 +353,51 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
return status;
}
+/* get_slave_pty() returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) {
+ int pty_master = -1;
+ int pty_slave = -1;
+ char pty_name[256];
+ struct group *gptr;
+ gid_t gid;
+ int slave = -1;
+
+ if (openpty(_master, _slave, pty_name, NULL, NULL) < 0) {
+ fprintf(fp, "ERROR: openpty() failed with: %s.\n",
strerror(errno));
+ return -1;
+ }
+
+ if ((gptr = getgrnam(pty_name)) != 0) {
+ gid = gptr->gr_gid;
+ } else {
+ /* If the tty group does not exist, don't change the
+* group on the slave pty, only the owner
+*/
+ gid = -1;
+ }
+
+ /* chown/chmod the corresponding pty, if possible.
+* This will only work if the process has root permissions.
+*/
+ if (chown(pty_name, getuid(), gid) != 0) {
+ fprintf(fp, "ERROR; chown() failed with: %s.\n",
strerror(errno));
+ }
+
+ /* Makes the slave read/writeable for the user. */
+ if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+ fprintf(fp, "ERROR: chmod() failed with: %s.\n",
strerror(errno));
+ }
+
+ slave = open(pty_name, O_RDWR);
+ return (slave);
+}
+
+
int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
int timeouted;
time_t sttime, entime;
int duration;
+ int slave;
+ int pgid = -1;
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
close(pipefd_stdout[1]);
break;
}
-
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p);
char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
break;
}
dirname(ptest_dir);
+ if (ioctl(0, TIOCNOTTY) == -1) {
+ fprintf(fp, "ERROR: Unable to detach from
controlling tty, %s\n", strerror(errno));
+ }
+
+ if ((pgid = getpgid(0)) == -1) {
+ fprintf(fp, "ERROR: getpgid() failed, %s\n",
strerror(errno));
+ }
child = fork();
Re: [yocto] YP sstate example conf file
Good question. I've one related to this as well. It would be also good to document (if it isn't somewhere already) what builds populate this mirror. I assume it will be some autobuilder job with DISTRO = poky, but without file listing enabled over http I cannot even guess which MACHINEs were included. It would be useful to provide one tarball with all sigdata files, which could be manually downloaded to check what's available there and to debug why the sstate cache from this mirror wasn't reused in local build. Cheers, On Thu, Jun 13, 2019 at 4:32 PM William Mills wrote: > Hello, > > From poky warrior tip, file meta-poky/conf/local.conf.sample > """ > # > #SSTATE_MIRRORS ?= "file://.* > http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH; > """ > > Should that be 2.7?? Or are you relying on the intelligence of the user > to fix this up? > > If the former then it needs to go on a checklist. > If the later then perhaps it would be better to use X.Y or something > that does not appear to work. Some verbage to suggest the edit would > probably be good as well. > > (and no, I did not run it like that. I'm slightly smarted than that.) > > > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235 > > Thanks, > Bill > > > William A. Mills > Chief Technologist, Open Solutions, SDO > Texas Instruments, Inc. > 20450 Century Blvd > Germantown MD 20878 > 240-643-0836 > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] YP sstate example conf file
Hello, >From poky warrior tip, file meta-poky/conf/local.conf.sample """ # #SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH; """ Should that be 2.7?? Or are you relying on the intelligence of the user to fix this up? If the former then it needs to go on a checklist. If the later then perhaps it would be better to use X.Y or something that does not appear to work. Some verbage to suggest the edit would probably be good as well. (and no, I did not run it like that. I'm slightly smarted than that.) https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235 Thanks, Bill William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Sorry about that. I was traveling this week, and kept forgetting to create the branch. It should be in place now. Bruce On Thu, Jun 13, 2019 at 3:48 AM Zumeng Chen wrote: > > Ping > > On 6/11/19 9:40 AM, Zumeng Chen wrote: > > Hi Bruce, > > I just finished insane check to build xilinx-zynqmp machine with > core-image-sato, all passed with boot process. > > Could you please help me to create a branch like that standard/xilinx-zynqmp > in the following git repo. in convenient your time, just directly branch out > from origin/standard/base, thanks~ > > git://git.yoctoproject.org/linux-yocto-dev > > > Cheers, > > Zumeng > > On 6/11/19 7:37 AM, Zumeng Chen wrote: > > > On 6/10/19 9:37 PM, Bruce Ashfield wrote: > > On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen wrote: > > Sounds I like mean, no, I just talk the reality, Xilinx did like the > following: > > https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp > > I think they have a reason to share zynq-7000 series hardware, which > gears to the related hardware > > features, and the way to create dts(a relative complicated process) > corresponding to the hdl related > > features partly as well. And they just want to put zynqmp(arm64) into > recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, > > As you can see, they have almost little in common in hardware features. > > > The reality here I said is about yocto project has not these related > ecosystem to create these whole thing for > > xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, > BOOT.BIN etc. there really are a bunch > > of Xilinx things. > > > So do we still want to following their SDK? If yes, fine, just help me > to merge zynqmp part from meta-xilinx, I'll take care the rest. > > I'm actually fine with an approach like we are taking here. Come up > with something that works purely with linux-yocto, and then we can > start factoring and grouping the fragments with the help of people > closer to the h/w. > > In particular as more Xilinx proprietary parts are open sourced, we'll > have the opportunity to tweak the configuration fragments to support > them properly/fully. > > We do want the fragments in the centralized kernel-cache, just as long > as they are appropriated factored/grouped under a xilinx/ subdir where > it makes sense, and have more generic feature groupings available to > be shared in the more common directories. > > What we have is a good start to that goal, so I'll get it merged and > we can start iterating on it in tree. > > > > Thanks Bruce, highly appreciated :) > > > Cheers, > > Zumeng > > > Bruce > > > Cheers, > > Zumeng > > > On 6/6/19 2:55 PM, Zumeng Chen wrote: > > Yes, I checked it, it seems only for zynq 7000 and its special > interfaces. I bet > > the original author didn't mean to share something for both arm64 > and 32 :) > > When I created the structure I had intended for it to include the > zynqmp related configs. I even had some yocto-kernel-cache patches for > it at the time, but zynqmp has changed quite a bit since those initial > patches. Most of those configs still live in meta-xilinx though (some > are specific to the linux-xlnx kernel). > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta > > > I would highly recommend keeping the xilinx bsp configs together under > the bsp/xilinx/ directory. And try to reuse the existing configs where > possible or splitting some parts of them out to make common configs > since zynq and zynqmp share a number of common drivers. > > > Negative, try to see what had done in the past, a very little can > re-used. And I suspect > > did you even how many features they are sharing. > > I don't think it's worth. To be honestly, they have totally the > different app scenario. > > Cheers, > > Zumeng > > Regards, > Nathan > > And for those common things, I guess some of them might be included > by our > > rootfs build system. > > > sense to locate these fragments there, and to factor out some common > configs. I see some of the issues I'm pointing out here are in the > existing fragments as well, so there's an opportunity for some low > effort fixups. > > + > +CONFIG_PCI=y > +CONFIG_PCI_MSI=y > +CONFIG_PCI_MSI_IRQ_DOMAIN=y > +CONFIG_PCIE_XILINX_NWL=y > +CONFIG_PCIEPORTBUS=y > +CONFIG_PCIE_XDMA_PL=y > + > +#CPU ilde and freq > +CONFIG_CPU_IDLE=y > +CONFIG_ARM_CPUIDLE=y > +CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > +CONFIG_CPU_FREQ_GOV_USERSPACE=y > +CONFIG_CPUFREQ_DT=y > +CONFIG_CPUFREQ_DT_PLATDEV=y > > These are also not tied to h/w. We already have a > features/power/intel.cfg fragment. Can you relocate these to a zynqmp > or xilinx fragment and put it along side of the existing ones ? > > I'll try it with a nice way. > > + > +# CAN Device Drivers > +# > +CONFIG_CAN=y > +CONFIG_CAN_DEV=y > +CONFIG_CAN_XILINXCAN=y > + > +CONFIG_MTD=y > +CONFIG_MTD_OF_PARTS=y > +CONFIG_MTD_BLKDEVS=y >
Re: [yocto] Command to make zimage to ramdisk format
Here is what you need (my best guess): https://lists.yoctoproject.org/pipermail/yocto/2018-July/041680.html Please, read carefully this thread. Zoran ___ On Thu, Jun 13, 2019 at 1:35 PM JH wrote: > > Hi, > > I built the Yocto images: > > dev-image-20190528085324.rootfs.wic.gz > zImage--.bin > > I need to build zImage to ramdisk to run it on RAM in development. > What is the correct mkimage command can be used for add ramdisk to the > zimage? > > $ mkimage -A arm -T ramdisk -C none -n uInitrd -d /path/to/initrd.img > /path/to/uInitrd > > Thank you. > > Kind regards, > > - JH > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Command to make zimage to ramdisk format
Hi, I built the Yocto images: dev-image-20190528085324.rootfs.wic.gz zImage--.bin I need to build zImage to ramdisk to run it on RAM in development. What is the correct mkimage command can be used for add ramdisk to the zimage? $ mkimage -A arm -T ramdisk -C none -n uInitrd -d /path/to/initrd.img /path/to/uInitrd Thank you. Kind regards, - JH -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Download git source not the latest
I set up for my release version which is nothing to do with the git
source, how could I link the PV to autorev?
VERSION_MAJOR = "1"
VERSION_MINOR = "0"
VERSION_BUILD = "0"
PV = "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_BUILD}"
Thanks Richard,
- jupiter
On 6/12/19, Richard Purdie wrote:
> On Tue, 2019-06-11 at 20:38 +1000, JH wrote:
>> Hi,
>>
>> I set up SRCREV = "${AUTOREV}" in the recipe of my application, but
>> too often it downloaded the old revision. How can I force the bitbake
>> to download the latest git source?
>
> What did you set PV to?
>
> You need to have SRCPV in PV for autorev to work properly.
>
> Regards,
>
> Richard
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchtest][PATCH V2] patchtest: fix linux-yocto version
From: Changqing Li
4.9 is not avaiable currently, so remove version from bbappend
and remove PREFERRED_VERSION.
Signed-off-by: Changqing Li
---
.../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} | 0
scripts/create-guest-machine | 5 -
2 files changed, 5 deletions(-)
rename meta-patchtest/recipes-kernel/linux/{linux-yocto_4.%.bbappend =>
linux-yocto_%.bbappend} (100%)
diff --git a/meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
b/meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
diff --git a/scripts/create-guest-machine b/scripts/create-guest-machine
index 8dd6a2e..8381ef8 100755
--- a/scripts/create-guest-machine
+++ b/scripts/create-guest-machine
@@ -145,11 +145,6 @@ cat >> $POKY/build/conf/auto.conf << EOF
$PTSMARK
MACHINE = "$MACHINE"
-# The preferred kernel version in poky (4.10%, master) returns an error whilst
-# executing patchtest on guest. Changing the preferred version to 4.9% as it
-# is more suitable and does not present any errors.
-PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
-
PACKAGE_CLASSES = "package_ipk"
IMAGE_FSTYPES = "ext4"
SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/dev/PATH;
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto version
On 6/13/19 4:29 PM, Adrian Bunk wrote: On Thu, Jun 13, 2019 at 03:46:04PM +0800, changqing...@windriver.com wrote: From: Changqing Li 4.9 is not avaiable currently, preferred version changed to 5.0, also correct the bbappend name 5.0 is already EOL upstream and will be removed soon. ... --- a/scripts/create-guest-machine +++ b/scripts/create-guest-machine @@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF $PTSMARK MACHINE = "$MACHINE" -# The preferred kernel version in poky (4.10%, master) returns an error whilst -# executing patchtest on guest. Changing the preferred version to 4.9% as it -# is more suitable and does not present any errors. -PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%" +PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%" ... This looks as if it was a temporary workaround for some problem with kernel 4.10. If 5.0 works, then there is not really a reason for changing the preferred version here. Thanks, I will remove this line. cu Adrian -- BRs Sandy(Li Changqing) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto version
On Thu, Jun 13, 2019 at 03:46:04PM +0800, changqing...@windriver.com wrote: > From: Changqing Li > > 4.9 is not avaiable currently, preferred version changed > to 5.0, also correct the bbappend name 5.0 is already EOL upstream and will be removed soon. >... > --- a/scripts/create-guest-machine > +++ b/scripts/create-guest-machine > @@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF > $PTSMARK > MACHINE = "$MACHINE" > > -# The preferred kernel version in poky (4.10%, master) returns an error > whilst > -# executing patchtest on guest. Changing the preferred version to 4.9% as it > -# is more suitable and does not present any errors. > -PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%" > +PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%" >... This looks as if it was a temporary workaround for some problem with kernel 4.10. If 5.0 works, then there is not really a reason for changing the preferred version here. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] patchtest: fix virtio-9p-pci is not a valid device
Please ignore this one, I resend one. On 6/13/19 3:45 PM, changqing...@windriver.com wrote: From: Changqing Li fix error during runqemu: test_mount: 'virtio-9p-pci' is not a valid device model name recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native Signed-off-by: Changqing Li --- meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 + meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend new file mode 100644 index 000..a91ccb7 --- /dev/null +++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend @@ -0,0 +1 @@ +PACKAGECONFIG_append = " virtfs" diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend deleted file mode 100644 index 3ad9f03..000 --- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend +++ /dev/null @@ -1 +0,0 @@ -PACKAGECONFIG_append_pn-qemu-native = " virtfs" -- BRs Sandy(Li Changqing) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [autobuilder] Y-AB in a docker container?
Hi, I use the good old yocto autobuilder in a docker container and it still serves me well, but I would like to move to the shiny new yocto autobuilder. Before I start spending hours to do it myself I wonder if someone already did something like this and is willing to share the Dockerfile(s). Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Ping On 6/11/19 9:40 AM, Zumeng Chen wrote: Hi Bruce, I just finished insane check to build xilinx-zynqmp machine with core-image-sato, all passed with boot process. Could you please help me to create a branch like that standard/xilinx-zynqmp in the following git repo. in convenient your time, just directly branch out from origin/standard/base, thanks~ git://git.yoctoproject.org/linux-yocto-dev Cheers, Zumeng On 6/11/19 7:37 AM, Zumeng Chen wrote: On 6/10/19 9:37 PM, Bruce Ashfield wrote: On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen wrote: Sounds I like mean, no, I just talk the reality, Xilinx did like the following: https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp I think they have a reason to share zynq-7000 series hardware, which gears to the related hardware features, and the way to create dts(a relative complicated process) corresponding to the hdl related features partly as well. And they just want to put zynqmp(arm64) into recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, As you can see, they have almost little in common in hardware features. The reality here I said is about yocto project has not these related ecosystem to create these whole thing for xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, BOOT.BIN etc. there really are a bunch of Xilinx things. So do we still want to following their SDK? If yes, fine, just help me to merge zynqmp part from meta-xilinx, I'll take care the rest. I'm actually fine with an approach like we are taking here. Come up with something that works purely with linux-yocto, and then we can start factoring and grouping the fragments with the help of people closer to the h/w. In particular as more Xilinx proprietary parts are open sourced, we'll have the opportunity to tweak the configuration fragments to support them properly/fully. We do want the fragments in the centralized kernel-cache, just as long as they are appropriated factored/grouped under a xilinx/ subdir where it makes sense, and have more generic feature groupings available to be shared in the more common directories. What we have is a good start to that goal, so I'll get it merged and we can start iterating on it in tree. Thanks Bruce, highly appreciated :) Cheers, Zumeng Bruce Cheers, Zumeng On 6/6/19 2:55 PM, Zumeng Chen wrote: Yes, I checked it, it seems only for zynq 7000 and its special interfaces. I bet the original author didn't mean to share something for both arm64 and 32 :) When I created the structure I had intended for it to include the zynqmp related configs. I even had some yocto-kernel-cache patches for it at the time, but zynqmp has changed quite a bit since those initial patches. Most of those configs still live in meta-xilinx though (some are specific to the linux-xlnx kernel). http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta I would highly recommend keeping the xilinx bsp configs together under the bsp/xilinx/ directory. And try to reuse the existing configs where possible or splitting some parts of them out to make common configs since zynq and zynqmp share a number of common drivers. Negative, try to see what had done in the past, a very little can re-used. And I suspect did you even how many features they are sharing. I don't think it's worth. To be honestly, they have totally the different app scenario. Cheers, Zumeng Regards, Nathan And for those common things, I guess some of them might be included by our rootfs build system. sense to locate these fragments there, and to factor out some common configs. I see some of the issues I'm pointing out here are in the existing fragments as well, so there's an opportunity for some low effort fixups. + +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_PCI_MSI_IRQ_DOMAIN=y +CONFIG_PCIE_XILINX_NWL=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCIE_XDMA_PL=y + +#CPU ilde and freq +CONFIG_CPU_IDLE=y +CONFIG_ARM_CPUIDLE=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPUFREQ_DT=y +CONFIG_CPUFREQ_DT_PLATDEV=y These are also not tied to h/w. We already have a features/power/intel.cfg fragment. Can you relocate these to a zynqmp or xilinx fragment and put it along side of the existing ones ? I'll try it with a nice way. + +# CAN Device Drivers +# +CONFIG_CAN=y +CONFIG_CAN_DEV=y +CONFIG_CAN_XILINXCAN=y + +CONFIG_MTD=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_SPI_NOR=y +# CONFIG_JFFS2_FS_WRITEBUFFER is not set +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set + +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_AHCI_CEVA=y +CONFIG_NETDEVICES=y + +CONFIG_OF=y +CONFIG_OF_MDIO=y +CONFIG_ETHERNET=y +CONFIG_NET_CADENCE=y +CONFIG_MACB=y +CONFIG_MACB_EXT_BD=y + +CONFIG_PHYLIB=y +CONFIG_XILINX_PHY=y + +CONFIG_PHY_XILINX_ZYNQMP=y
[yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto version
From: Changqing Li
4.9 is not avaiable currently, preferred version changed
to 5.0, also correct the bbappend name
Signed-off-by: Changqing Li
---
.../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} | 0
scripts/create-guest-machine | 5 +
2 files changed, 1 insertion(+), 4 deletions(-)
rename meta-patchtest/recipes-kernel/linux/{linux-yocto_4.%.bbappend =>
linux-yocto_%.bbappend} (100%)
diff --git a/meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
b/meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
diff --git a/scripts/create-guest-machine b/scripts/create-guest-machine
index 8dd6a2e..151d5c2 100755
--- a/scripts/create-guest-machine
+++ b/scripts/create-guest-machine
@@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF
$PTSMARK
MACHINE = "$MACHINE"
-# The preferred kernel version in poky (4.10%, master) returns an error whilst
-# executing patchtest on guest. Changing the preferred version to 4.9% as it
-# is more suitable and does not present any errors.
-PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
+PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%"
PACKAGE_CLASSES = "package_ipk"
IMAGE_FSTYPES = "ext4"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchtest][PATCH 1/2] patchtest: fix virtio-9p-pci is not a valid device
From: Changqing Li fix error during runqemu: test_mount: 'virtio-9p-pci' is not a valid device model name recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native Signed-off-by: Changqing Li --- meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 + meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend new file mode 100644 index 000..a91ccb7 --- /dev/null +++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend @@ -0,0 +1 @@ +PACKAGECONFIG_append = " virtfs" diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend deleted file mode 100644 index 3ad9f03..000 --- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend +++ /dev/null @@ -1 +0,0 @@ -PACKAGECONFIG_append_pn-qemu-native = " virtfs" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] patchtest: fix virtio-9p-pci is not a valid device
From: Changqing Li fix error during runqemu: test_mount: 'virtio-9p-pci' is not a valid device model name recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native Signed-off-by: Changqing Li --- meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 + meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend new file mode 100644 index 000..a91ccb7 --- /dev/null +++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend @@ -0,0 +1 @@ +PACKAGECONFIG_append = " virtfs" diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend deleted file mode 100644 index 3ad9f03..000 --- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend +++ /dev/null @@ -1 +0,0 @@ -PACKAGECONFIG_append_pn-qemu-native = " virtfs" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
