-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kirkstone mitigations #52
base: kirkstone-next
Are you sure you want to change the base?
Kirkstone mitigations #52
Conversation
@@ -5,10 +5,12 @@ REPO ??= "git://github.com/Xilinx/embeddedsw.git;protocol=https" | |||
|
|||
ESW_BRANCH[2022.1] = "xlnx_rel_v2022.1_update" | |||
ESW_BRANCH[2022.2] = "xlnx_rel_v2022.2" | |||
ESW_BRANCH[git] = "master-next" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct? Shouldn't this be just "master"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I merely restore the line verbatim which was removed in 1243552 causing breakage described in the commit message. I did not want to introduce further modifications as my motivation was to just mitigate the bitbake parse error.
--- a/lib/sw_apps/zynqmp_pmufw/src/Makefile | ||
+++ b/lib/sw_apps/zynqmp_pmufw/src/Makefile | ||
@@ -28,8 +28,8 @@ $(EXEC): $(LIBS) $(OBJS) $(INCLUDES) | ||
diff --git a/lib/sw_apps/versal_plm/src/versal/Makefile b/lib/sw_apps/versal_plm/src/versal/Makefile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO this sould be a new patch instead of repairing the old one. v2022.1 still contains the old file path and this will probably break builds for v2022.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, changed to selecting patch file according to ESW_VER which hopefully alleviates the situation for 2022.1 users.
@@ -0,0 +1,32 @@ | |||
# Override do_configure defined in poky/meta/recipes-devtools/gcc/gcc-runtime.inc in order to work around |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit also repairs the -shared
issue. It's probably a better idea to backport it to kirkstone:
https://git.yoctoproject.org/poky/commit/meta/recipes-devtools/gcc/gcc-runtime.inc?id=591f14c698f43ca4ae6431c8cd96225d1ed5dbf5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I triaged locally by removing this override and cherry-picking said commit on top of yocto-4.0.9 and according to my test it fixes the issue, so I sent a kirkstone backport request to oe-core mailing list: https://lists.openembedded.org/g/openembedded-core/message/181484
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest Kirkstone 4.0.11 now contains backported fix https://git.yoctoproject.org/poky/commit/?h=yocto-4.0.11&id=645fd39e4bf5616e887a865e69984a68defafaba so dropped override which is no longer needed from this PR
b62f081
to
e58f1c5
Compare
Commit 1243552 ("xlnx-embeddedsw: Cleanup and remove old versions, no longer supported") removed also 'git' varFlag lines which causes following parsing error with _git.bb recipes that inherit this bbclass: ERROR: ExpansionError during parsing .../poky/meta-xilinx/meta-xilinx-standalone/recipes-bsp/embeddedsw/pmu-firmware_git.bb Traceback (most recent call last): File ".../poky/bitbake/lib/bb/fetch2/git.py", line 250, in Git.urldata_init(ud=<bb.fetch2.FetchData object at 0x7fc5db2b5610>, d=<bb.data_smart.DataSmart object at 0x7fc5de3e5310>): > ud.setup_revisions(d) File ".../poky/bitbake/lib/bb/fetch2/__init__.py", line 1349, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart object at 0x7fc5de3e5310>): for name in self.names: > self.revisions[name] = srcrev_internal_helper(self, d, name) File ".../poky/bitbake/lib/bb/fetch2/__init__.py", line 1214, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at 0x7fc5db2b5610>, d=<bb.data_smart.DataSmart object at 0x7fc5de3e5310>, name='default'): if srcrev == "AUTOINC": > srcrev = ud.method.latest_revision(ud, d, name) File ".../poky/bitbake/lib/bb/fetch2/__init__.py", line 1626, in Git.latest_revision(ud=<bb.fetch2.FetchData object at 0x7fc5db2b5610>, d=<bb.data_smart.DataSmart object at 0x7fc5de3e5310>, name='default'): except KeyError: > revs[key] = rev = self._latest_revision(ud, d, name) return rev File ".../poky/bitbake/lib/bb/fetch2/git.py", line 757, in Git._latest_revision(ud=<bb.fetch2.FetchData object at 0x7fc5db2b5610>, d=<bb.data_smart.DataSmart object at 0x7fc5de3e5310>, name='default'): return sha1 > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git repository in git ls-remote output for %s" % \ (ud.unresolvedrev[name], ud.host+ud.path)) bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve 'git' in upstream git repository in git ls-remote output for github.com/Xilinx/embeddedsw.git The variable dependency chain for the failure is: SRCPV -> PV -> WORKDIR -> T ERROR: Parsing halted due to errors, see error messages above Restore those lines as they were before the commit that removed them to be able to use this layer. Signed-off-by: Niko Mauno <[email protected]>
Signed-off-by: Mark Hatle <[email protected]>
The existing version of makefile-skip-copy_bsp.sh.patch fails to apply against embeddedsw repo 'xlnx_rel_v2022.2' branch, so use an updated version of the patch file instead when ESW_VER is 2022.2. Signed-off-by: Niko Mauno <[email protected]>
e58f1c5
to
4269a8e
Compare
@nikomauno Maybe you can send the patches to the meta-xilinx mailing list? It would be good if this could be merged. |
Thanks - unfortunately there was a remarkable (390 commit) deviation between YP's and Github's meta-xilinx/kirkstone-next branches, which is why I originally chose to proceed with the latter which supported also 2022.2 in addition to 2022.1. From Mark's answer I assume the YP's kirkstone-next branch is not going to get updated: https://lists.yoctoproject.org/g/meta-xilinx/topic/94568772#5241 |
Limit number of concurrent jobs to one in order to mitigate the non-propagation of -j1 option from PARALLEL_MAKE directive which helps us to avoid the following kind of build failure: | .../pmu-firmware/2022.2+gitAUTOINC+5330a64c8e-r0/recipe-sysroot-native/usr/bin/microblazeel-xilinx-elf/../../libexec/microblazeel-xilinx-elf/gcc/microblazeel-xilinx-elf/11.3.0/ar: xdppsu_edid.o: No such file or directory | make[3]: *** [Makefile:31: dppsu_libs] Error 1 | make[2]: *** [Makefile:48: psu_pmu_0/libsrc/dppsu/src/make.libs] Error 2 Signed-off-by: Niko Mauno <[email protected]>
By doing so we avoid seeing following bitbake nags when machine-xilinx-qemu.inc is not included in build configuration: NOTE: Multiple providers are available for qemu-native (qemu-native, qemu-xilinx-native) Consider defining a PREFERRED_PROVIDER entry to match qemu-native NOTE: Multiple providers are available for qemu-helper-native (qemu-helper-native, qemu-xilinx-helper-native) Consider defining a PREFERRED_PROVIDER entry to match qemu-helper-native NOTE: Multiple providers are available for runtime nativesdk-qemu (nativesdk-qemu, nativesdk-qemu-xilinx) Consider defining a PREFERRED_RPROVIDER entry to match nativesdk-qemu NOTE: Multiple providers are available for qemu-system-native (qemu-system-native, qemu-xilinx-system-native) Consider defining a PREFERRED_PROVIDER entry to match qemu-system-native Signed-off-by: Niko Mauno <[email protected]>
4269a8e
to
ce98e8f
Compare
This is a proposal for Yocto kirkstone improvements to https://github.com/Xilinx/meta-xilinx/tree/kirkstone-next which should make the branch better compatible with Yocto Project's kirkstone (LTS) release.
Although Xilinx recommends using the Yocto Project meta-xilinx mailing list for submitting patches, the https://git.yoctoproject.org/meta-xilinx/log/?h=kirkstone-next is lagging the Xilinx Github version of meta-xilinx repository, namely the latter contains Xilinx release 2022.2 whereas the former 2022.1. Therefore I have opted to open this pull request against the GitHub repository instead.