yocto@lists.yoctoproject.org

Home Messages Hashtags Subgroups

Expanded

Between

and

Re: libquadmath Konrad Weihmann <kweihmann@...> #55705 The following I just found in local.conf.sample.extended # Enabling FORTRAN # Note this is not officially supported and is just illustrated here to # show an example of how it can be done # You'll also need your fortran recipe to depend on libgfortran FORTRAN:forcevariable = ",fortran" guess that will solve your issue without the need for a bbappend. Just inject that line via distro or local.conf toggle quoted message Show quoted text On 02.01.22 18:31, staticd wrote: I think to clarify...what I need are these files: --- snipped from gcc-runtime.inc --- ``` FILES_libquadmath = "${libdir}/libquadmath.so." SUMMARY_libquadmath = "GNU quad-precision math library" FILES_libquadmath-dev = "\ ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \ ${libdir}/libquadmath*.so \ ${libdir}/libquadmath.la <http://libquadmath.la> \ " ``` --- to be in my $STAGING_LIBDIR So far, I have been unable to figure out how to do that, unfortunately. On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@... <mailto:staticd@...>> wrote: Thank you, Michael. I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"` However, libquadmath.so is still not present in `recipe-sysroot/lib` I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it. Many thanks. On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@... <mailto:michael.ho@...>> wrote: Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. See: https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot> Kind regards, Michael On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@... <mailto:staticd@...>> wrote: okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
Re: libquadmath Konrad Weihmann <kweihmann@...> #55704 I think the reason of that is that fortran support isn't enabled in default gcc-runtime recipe. from gcc-runtime.inc: RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \ " activates the configuration of libquadmath if either ',fortran' or ',f77' is set in 'FORTRAN' variable. Unfortunately this variable seems to be set to "" since gcc version 9 update By just adding FORTRAN = ",fortran" to a gcc-runtime_%.bbappend I could create the needed files in the sysroot-components directory gcc-runtime/usr/lib/libstdc++.so gcc-runtime/usr/lib/libitm.spec ->> gcc-runtime/usr/lib/libquadmath.so.0.0.0 gcc-runtime/usr/lib/libstdc++.so.6 gcc-runtime/usr/lib/libitm.so.1.0.0 gcc-runtime/usr/lib/libatomic.so.1 gcc-runtime/usr/lib/libgomp.spec gcc-runtime/usr/lib/libitm.a now as you already have set `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` it should automatically make the lib available to your recipe workspace. toggle quoted message Show quoted text On 02.01.22 18:31, staticd wrote: I think to clarify...what I need are these files: --- snipped from gcc-runtime.inc --- ``` FILES_libquadmath = "${libdir}/libquadmath.so." SUMMARY_libquadmath = "GNU quad-precision math library" FILES_libquadmath-dev = "\ ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \ ${libdir}/libquadmath*.so \ ${libdir}/libquadmath.la <http://libquadmath.la> \ " ``` --- to be in my $STAGING_LIBDIR So far, I have been unable to figure out how to do that, unfortunately. On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@... <mailto:staticd@...>> wrote: Thank you, Michael. I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"` However, libquadmath.so is still not present in `recipe-sysroot/lib` I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it. Many thanks. On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@... <mailto:michael.ho@...>> wrote: Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. See: https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot> Kind regards, Michael On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@... <mailto:staticd@...>> wrote: okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
Re: libquadmath staticd #55703 I think to clarify...what I need are these files: --- snipped from gcc-runtime.inc --- ``` FILES_libquadmath = "${libdir}/libquadmath.so." SUMMARY_libquadmath = "GNU quad-precision math library" FILES_libquadmath-dev = "\ ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \ ${libdir}/libquadmath*.so \ ${libdir}/libquadmath.la \ " ``` --- to be in my $STAGING_LIBDIR So far, I have been unable to figure out how to do that, unfortunately. toggle quoted message Show quoted text On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@...> wrote: Thank you, Michael. I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"` However, libquadmath.so is still not present in `recipe-sysroot/lib` I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it. Many thanks. On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...> wrote: Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. See: https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot Kind regards, Michael On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote: okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
Re: libquadmath staticd #55702 Thank you, Michael. I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"` However, libquadmath.so is still not present in `recipe-sysroot/lib` I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it. Many thanks. toggle quoted message Show quoted text On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...> wrote: Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. See: https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot Kind regards, Michael On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote: okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
Re: libquadmath Michael Ho #55701 Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. See: https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot Kind regards, Michael toggle quoted message Show quoted text On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote: okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
libquadmath staticd #55700 okay...I think I have a more interesting question now... In the package I am building I have some Fortran code that requires `libquadmath` I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs Is there a way for me to do that? My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile` This doesn't seem like the correct approach but I am not sure how else to do it at this point Any help would be greatly appreciated.
More All Messages By This Member
[auto-upgrade-helper][PATCH] devtool: return both stdout and stderr Alexander Kanavin #55699 At some point devtool started printing to stderr, which means patch rebase issues weren't anymore correctly caught, and bogus updates were being sent out. Signed-off-by: Alexander Kanavin <alex.kanavin@...> --- modules/utils/devtool.py \| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/utils/devtool.py b/modules/utils/devtool.py index 0d27bb0..c26061f 100644 --- a/modules/utils/devtool.py +++ b/modules/utils/devtool.py @@ -19,7 +19,7 @@ class Devtool(object): raise DevtoolError("The following devtool command failed: " + operation, e.stdout, e.stderr) - return stdout + return stdout + stderr def upgrade(self, recipe, version = None, revision = None): cmd = " upgrade " + recipe -- 2.33.1
More All Messages By This Member
How to add WIFI debug tool to custom image #raspberrypi #ubuntu #yocto #devtool #distro mihirdave36@... #55698 Hello, How can I add any generic WiFi debug tool to Yocto imgae? Thanks Mihir
More All Messages By This Member
How to add Alsa loopback / Alsa lib support to custom image #linux #raspberrypi #ubuntu #yocto #devtool mihirdave36@... #55697 Hello, Happy New Year I am trying to learn Yocto, & implement it on NXP & RPI 4 dev boards. so, could you please guide me how can i add, 1- Alsa loopback or Alsa library. to my custom Yocto image. Thanks Mihir
More All Messages By This Member
[meta-security][PATCH] google-authenticator-libpam: update to 1.09 Armin Kuster #55696 Signed-off-by: Armin Kuster <akuster808@...> --- ...cator-libpam_1.08.bb => google-authenticator-libpam_1.09.bb} \| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename recipes-security/google-authenticator-libpam/{google-authenticator-libpam_1.08.bb => google-authenticator-libpam_1.09.bb} (92%) diff --git a/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb b/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb similarity index 92% rename from recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb rename to recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb index e8ddf29..8a0b1ee 100644 --- a/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb +++ b/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57" LICENSE = "Apache-2.0" SRC_URI = "git://github.com/google/google-authenticator-libpam.git;branch=master;protocol=https" -SRCREV = "2c7415d950fb0b4a7f779f045910666447b100ef" +SRCREV = "962f353aac6cfc7b804547319db40f8b804f0b6c" DEPENDS = "libpam" -- 2.25.1
More All Messages By This Member
[meta-cgl][PATCH 3/3] cluster-glue: add UPSTREAM_CHECK_GITTAGREGEX Yi Zhao #55695 Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version. Before the patch: $ devtool latest-version cluster-glue INFO: Current version: 1.0.12 INFO: Latest version: 10 INFO: Latest version's commit: 62fac3c02affab05abe39c185dad3a91367d3f58 After the patch: $ devtool latest-version cluster-glue INFO: Current version: 1.0.12 INFO: Latest version: 1.0.12 INFO: Latest version's commit: 1bc77825c0cfb0c80f9c82a061af7ede68676cb4 Signed-off-by: Yi Zhao <yi.zhao@...> --- meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb \| 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb index acd3149..c9d1bac 100644 --- a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb +++ b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb @@ -22,6 +22,8 @@ SRC_URI:append_libc-uclibc = " file://kill-stack-protector.patch" SRCREV = "fd5a3befacd23d056a72cacd2b8ad6bba498e56b" +UPSTREAM_CHECK_GITTAGREGEX = "glue-(?P<pver>\d+(\.\d+)+)" + inherit autotools useradd pkgconfig systemd multilib_script multilib_header SYSTEMD_SERVICE:${PN} = "logd.service" -- 2.25.1
More All Messages By This Member
[meta-cgl][PATCH 2/3] ocfs2-tools: add UPSTREAM_CHECK_GITTAGREGEX Yi Zhao #55694 Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version. Before the patch: $ devtool latest-version ocfs2-tools INFO: Current version: 1.8.6 INFO: Latest version: 2 INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6 After the patch: $ devtool latest-version ocfs2-tools INFO: Current version: 1.8.6 INFO: Latest version: 1.8.7 INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6 Signed-off-by: Yi Zhao <yi.zhao@...> --- meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb \| 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb index 7c32c54..28ef4b0 100644 --- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb +++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb @@ -22,6 +22,9 @@ SRC_URI = "git://github.com/markfasheh/ocfs2-tools;branch=master;protocol=https file://0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch \ " SRCREV = "4d76ceb4aa7aaa1fd595368089e99575d708f719" + +UPSTREAM_CHECK_GITTAGREGEX = "ocfs2-tools-(?P<pver>\d+(\.\d+)+)" + S = "${WORKDIR}/git" inherit autotools-brokensep pkgconfig systemd -- 2.25.1
More All Messages By This Member
[meta-cgl][PATCH 1/3] resource-agents: add UPSTREAM_CHECK_GITTAGREGEX Yi Zhao #55693 Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version. Before the patch: $ devtool latest-version resource-agents INFO: Current version: 4.5.0 INFO: Latest version: 10 INFO: Latest version's commit: 5cf93783eafa22e8b82d50834bfb76b9e8434783 After the patch: $ devtool latest-version resource-agents INFO: Current version: 4.5.0 INFO: Latest version: 4.10.0 INFO: Latest version's commit: fd0720f73a06042ad0a5475a3398096b2912cf5f Signed-off-by: Yi Zhao <yi.zhao@...> --- .../cluster-resource-agents/resource-agents_4.5.0.bb \| 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb index 00ddd22..c8b2fbd 100644 --- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb +++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb @@ -24,6 +24,8 @@ SRC_URI = "git://github.com/ClusterLabs/resource-agents;branch=main;protocol=htt SRCREV = "fee181320547365d7f8c88cca2b32801412b933d" +UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)" + S="${WORKDIR}/git" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \ -- 2.25.1
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain davis roman <davis.roman84@...> #55692 On Wed, Dec 29, 2021 at 6:15 PM Davis Roman <davis.roman84@...> wrote: On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote: On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote: On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote: Hi, On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote: I generated an internal mips toolchain built against musl and I tried to compile u-boot but unfortunately, I'm getting "opcode not supported" error messages. https://pastebin.com/QdcLxy69 If instead I use the realtek provided prebuilt toolchain then u-boot compiles successfully. https://pastebin.com/zcQ5kc20 I'm thinking that Realtek's toolchain has patches specific to their SoC that have not been pushed upstream. Could this be the reason I'm unable to compile uboot? I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware. You're right. I didn't realize the RX5281 core on the RTS3916N only supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png). I happened to have a mips sourcery toolchain installed on my machine (https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2) so I pointed that to u-boot without modifying anything else and it was able to compile u-boot successfully. Woot! https://pastebin.com/ySPFae5u I suppose the next step would be to generate a mips1 yocto toolchain however according to the available tune values it appears only mips32 or mips64 is available Any suggestions on how to generate a mips1 yocto toolchain or if that's even supported? Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2 Sorry Khem, I'm not quite following you. I tried the following patch (https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you meant however my build configuration still shows the tune set to mips32r2 https://pastebin.com/izP9thVW What am I missing? Nevermind, I scraped the last patch, recreated my BUILD_DIR, set MACHINE = "qemumips" and added DEFAULTTUNE = "mips" in my local.conf. Now the build configuration correct https://pastebin.com/pkkRVL58 and I'm now waiting for the toolchain to finish so I can attempt to build realtek's u-boot. Regards, Anders Montonen
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain davis roman <davis.roman84@...> #55691 On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote: On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote: On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote: Hi, On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote: I generated an internal mips toolchain built against musl and I tried to compile u-boot but unfortunately, I'm getting "opcode not supported" error messages. https://pastebin.com/QdcLxy69 If instead I use the realtek provided prebuilt toolchain then u-boot compiles successfully. https://pastebin.com/zcQ5kc20 I'm thinking that Realtek's toolchain has patches specific to their SoC that have not been pushed upstream. Could this be the reason I'm unable to compile uboot? I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware. You're right. I didn't realize the RX5281 core on the RTS3916N only supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png). I happened to have a mips sourcery toolchain installed on my machine (https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2) so I pointed that to u-boot without modifying anything else and it was able to compile u-boot successfully. Woot! https://pastebin.com/ySPFae5u I suppose the next step would be to generate a mips1 yocto toolchain however according to the available tune values it appears only mips32 or mips64 is available Any suggestions on how to generate a mips1 yocto toolchain or if that's even supported? Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2 Sorry Khem, I'm not quite following you. I tried the following patch (https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you meant however my build configuration still shows the tune set to mips32r2 https://pastebin.com/izP9thVW What am I missing? Regards, Anders Montonen
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain Khem Raj #55690 On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote: On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote: > > Hi, > > > On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote: > > > > I generated an internal mips toolchain built against musl and I tried > > to compile u-boot but unfortunately, I'm getting "opcode not > > supported" error messages. https://pastebin.com/QdcLxy69 > > If instead I use the realtek provided prebuilt toolchain then u-boot > > compiles successfully. https://pastebin.com/zcQ5kc20 > > > > I'm thinking that Realtek's toolchain has patches specific to their > > SoC that have not been pushed upstream. Could this be the reason I'm > > unable to compile uboot? > > I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware. You're right. I didn't realize the RX5281 core on the RTS3916N only supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png). I happened to have a mips sourcery toolchain installed on my machine (https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2) so I pointed that to u-boot without modifying anything else and it was able to compile u-boot successfully. Woot! https://pastebin.com/ySPFae5u I suppose the next step would be to generate a mips1 yocto toolchain however according to the available tune values it appears only mips32 or mips64 is available Any suggestions on how to generate a mips1 yocto toolchain or if that's even supported? Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2 > > Regards, > Anders Montonen
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain davis roman <davis.roman84@...> #55689 On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote: Hi, On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote: I generated an internal mips toolchain built against musl and I tried to compile u-boot but unfortunately, I'm getting "opcode not supported" error messages. https://pastebin.com/QdcLxy69 If instead I use the realtek provided prebuilt toolchain then u-boot compiles successfully. https://pastebin.com/zcQ5kc20 I'm thinking that Realtek's toolchain has patches specific to their SoC that have not been pushed upstream. Could this be the reason I'm unable to compile uboot? I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware. You're right. I didn't realize the RX5281 core on the RTS3916N only supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png). I happened to have a mips sourcery toolchain installed on my machine (https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2) so I pointed that to u-boot without modifying anything else and it was able to compile u-boot successfully. Woot! https://pastebin.com/ySPFae5u I suppose the next step would be to generate a mips1 yocto toolchain however according to the available tune values it appears only mips32 or mips64 is available Any suggestions on how to generate a mips1 yocto toolchain or if that's even supported? Regards, Anders Montonen
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain Anders Montonen #55688 Hi, On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote: I generated an internal mips toolchain built against musl and I tried to compile u-boot but unfortunately, I'm getting "opcode not supported" error messages. https://pastebin.com/QdcLxy69 If instead I use the realtek provided prebuilt toolchain then u-boot compiles successfully. https://pastebin.com/zcQ5kc20 I'm thinking that Realtek's toolchain has patches specific to their SoC that have not been pushed upstream. Could this be the reason I'm unable to compile uboot? I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware. Regards, Anders Montonen
More All Messages By This Member
Re: [meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option Andreas Müller #55687 On Thu, Dec 9, 2021 at 6:37 AM Khem Raj <raj.khem@...> wrote: On Wed, Dec 8, 2021 at 7:03 PM Yu, Mingli <mingli.yu@...> wrote: From: Mingli Yu <mingli.yu@...> After the commit [1] introduced in openembedded-core layer, some configure options is't carried over include xshmfence option, so remove the xshmfence configure option to silence the below warning. WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue: xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig] That’s ok to remove it but more importantly does it work now without this option Looked into xserver's meson.build: As soon as dri3 is added - which we do - libxshmfence turns into a mandatory dependency. So this patch is correct. Somehow libxshmfence is added to sysroot - maybe we should add it explicitly to dri3 PACKAGECONFIG in oe-core to be more explicit. Slightly off-topic but we are on xserver on Raspi: Has anybody tested xserver recently? I see nasty issues on raspi4-64 / XFCE (haven't tried other desktops yet): * As soon as a window is opened, screen turns black for 1-2 seconds. Have not yet found helpful in logs yet. * There are two mouse devices detected with name 'vc4'. What? Cheers Andreas
More All Messages By This Member
Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain davis roman <davis.roman84@...> #55686 On Tue, Dec 28, 2021 at 10:09 PM Khem Raj <raj.khem@...> wrote: On 12/28/21 2:53 PM, davis roman wrote: Hi all, I'm working on a project utilizing a Realtek RTS3916N mips SoC and as part of Realtek's bsp offering, they provide their own fork of buildroot packaged with their prebuilt binary toolchain. I would much rather use yocto instead however Realtek made it clear that no yocto support is available from their end and they have no plans to provide it in the future. In theory, I have Realtek's u-boot and kernel source so it should be possible to build an image so long as poky is instructed to use an external toolchain. This is where I hit my first road block because Realtek only supports uClibc and I know the yocto community moved way from uClibc, in favor of musl, since the Morty release. As a result, I decided to use Krogoth-15.0.0 (knowing it's EOL) only because it supports uClibc. Now that I had picked a specific version of poky, I continued forward with the EXTERNAL_TOOLCHAIN feature. The documentation references the meta-sourcery layer as the typical use case. Using a sourcery toolchain tarball ( 2014.05) I was able to build qemuarm/glibc therefore as far as I can tell the EXTERNAL_TOOLCHAIN feature works as documented. Unfortunately, the issue I have now arises when I use the Realtek toolchain. meta-sourcery informs me that building against uClibc is not allowed as it has been blacklisted. Only glibc appears to be supported. I have looked around to see what other projects are similar and the closest I can find is the creator CI20 however due to the Realtek toolchain being based on uClibc, I haven't been able to find anything suitable for my usecase. I would greatly appreciate any suggestions regarding how to proceed forward with yocto integration, using a mips uClibc based toolchain. We have dropped uclibc support long time ago so any effort to support uClibc based system will be a bit of work and we have also dropped stale patches from metadata so even if you are able to get external toolchain bolted in, you will unfurl next set of problems for yourself So I don't have a better answer for you here, other than drop the idea of using uclibc if you want to use modern yocto baseline. We did support it long time ago so if you like you can use thise EOLed releases but there wont be much support for it here on community mailing lists. Thanks Khem for confirming my suspicions. Is there any other course of action that I can try? Since you have bootloader and kernel available to you, it might be less work to put together a BSP layer and machine definition for this SOC easily and it could be forward looking but there could be some portability issues w.r.t. toolchain etc. which are manageable here you will use internal mips toolchain to build your system and you can use musl instead of uclibc to build the system or glibc is other supported option. I generated an internal mips toolchain built against musl and I tried to compile u-boot but unfortunately, I'm getting "opcode not supported" error messages. https://pastebin.com/QdcLxy69 If instead I use the realtek provided prebuilt toolchain then u-boot compiles successfully. https://pastebin.com/zcQ5kc20 I'm thinking that Realtek's toolchain has patches specific to their SoC that have not been pushed upstream. Could this be the reason I'm unable to compile uboot? Thank you, Davis
More All Messages By This Member

4521 - 4540 of 60181

Home Hashtags Subgroups Terms