Actually, I found the upstream patch I backported, which you're probably better off using (same diff though).
https://lore.kernel.org/patchwork/patch/773330/ On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <[email protected]> wrote: > I'm not sure if this is your issue, but I had a similar issue ilog2 and > the disassembler and fixed it by backporting this patch. > > No guarantees, but perhaps it will help. > > --Aaron > > > On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <[email protected]> > wrote: > >> Thanks a lot for the advice! However, I can't seem to find a `const` that >> I can simply remove. To give more context, here is the log output around >> such an error (it seems like it is often surrounded by this log2.h warning, >> by the way): >> >> | In file included from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18: >>> | >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: >>> warning: ignoring attribute 'noreturn' because it conflicts with attribute >>> 'const' [-Wattributes] >>> | 22 | int ____ilog2_NaN(void); >>> | | ^~~ >>> | CC fs/fat/dir.o >>> | In file included from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16: >>> | >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: >>> warning: ignoring attribute 'noreturn' because it conflicts with attribute >>> 'const' [-Wattributes] >>> | 22 | int ____ilog2_NaN(void); >>> | | ^~~ >>> | CC block/deadline-iosched.o >>> | In file included from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11, >>> | from >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6: >>> | >>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: >>> warning: ignoring attribute 'noreturn' because it conflicts with attribute >>> 'const' [-Wattributes] >>> | 22 | int ____ilog2_NaN(void); >>> | | ^~~ >>> | /tmp/cc52vFrQ.s: Assembler messages: >>> | /tmp/cc52vFrQ.s:2683: Error: .err encountered >>> | /tmp/cc52vFrQ.s:2927: Error: .err encountered >>> | LD sound/sparc/built-in.o >>> | LD sound/spi/built-in.o >>> | make[3]: *** >>> [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: >>> block/scsi_ioctl.o] Error 1 >>> >> >> I pasted the full output here, if that can help: >> https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the >> log2 warning are: >> >> ``` >> extern __attribute__((const, noreturn)) >> int ____ilog2_NaN(void); >> ``` >> >> So there is a const there, but well... not sure what to do with it :-). >> >> Best, >> >> On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz < >> [email protected]> wrote: >> >>> *From:* [email protected] <[email protected]> *On >>> Behalf Of *Jonas Vautherin via lists.yoctoproject.org >>> *Sent:* 24 January 2021 14:30 >>> *To:* Jonas Vautherin <[email protected]> >>> *Cc:* Paul Barker <[email protected]>; Yocto-mailing-list < >>> [email protected]> >>> *Subject:* Re: [yocto] Writing a BSP from downstream kernel sources >>> >>> >>> >>> Just to close this: it seems like the gcc-cross-arm used by yocto >>> gatesgarth is too new for that specific downstream kernel (3.18.31). >>> >>> >>> >>> The goal was to get a proper BSP package for this device for a modern >>> yocto, so I don't think I will try with an older version of Yocto. If I >>> compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am >>> guessing that I will have issues creating a distro that runs both on RPi >>> and on that older device (because RPi will have a newer kernel and gcc, and >>> the skycontroller will use older ones). I also guess that the downstream >>> dts won't work with a modern kernel, and I would not know how to write one >>> myself for that apq8009 chip. >>> >>> >>> >>> Hence, I'm giving up. Thanks a lot for the help :-). >>> >>> *[Diego Santa Cruz] Wait! **You may be able to get it working, see >>> below.* >>> >>> >>> >>> On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via >>> lists.yoctoproject.org <[email protected]> >>> wrote: >>> >>> Thanks a lot for the answer! >>> >>> >>> >>> It seems like using `KCONFIG_MODE = "--alldefconfig"` with >>> `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of >>> errors as when I use the defconfig from the downstream kernel [1], i.e.: >>> >>> >>> >>> *[Diego Santa Cruz] I happen to be doing a similar kind of work, getting >>> an even older (2.6.37+) downstream kernel for an ARM machine to compile >>> with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few >>> fixes and backports necessary to make it happen and boot. I’m not done with >>> the work yet, so I do not know how stable it is, but I have it booting.* >>> >>> ``` >>> >>> | /tmp/ccz8jKgm.s: Assembler messages: >>> | /tmp/ccz8jKgm.s:985: Error: .err encountered >>> >>> ``` >>> >>> *[Diego Santa Cruz] The fix here is rather simple once you understand >>> what’s going on, the problem is abusive use of const for register >>> variables, see >>> https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html >>> <https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html> >>> so when put_user() is used for a literal constant value it gets assigned >>> the wrong register, so just remove the const qualifier from the put_user() >>> register variable assignment for the value argument. For my older kernel >>> the patch is like this.* >>> >>> --- arch/arm/include/asm/uaccess.h >>> >>> +++ arch/arm/include/asm/uaccess.h >>> >>> @@ -145,7 +145,7 @@ >>> >>> #define >>> put_user(x,p) >>> \ >>> >>> >>> ({ >>> \ >>> >>> - register const typeof(*(p)) __r2 >>> asm("r2") = (x); \ >>> >>> + register typeof(*(p)) __r2 asm("r2") = >>> (x); \ >>> >>> register const typeof(*(p)) __user *__p >>> asm("r0") = (p);\ >>> >>> register int __e >>> asm("r0"); \ >>> >>> switch (sizeof(*(__p))) >>> { \ >>> >>> >>> >>> Could it be related to the tuning, e.g. I'm somehow defining a wrong >>> toolchain in my machine configuration [2] and it fails to build? I was >>> thinking about the tune-cortexa7.inc include, though it seems to me that >>> the apq8009 is a cortexa7 [3]: >>> >>> >>> >>> *[Diego Santa Cruz] Other commits from post 3.18 that you may need to >>> backport are the following (start from bottom of list) * >>> >>> 474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant >>> optimizations >>> >>> cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the >>> various compiler-gcc[345].h files >>> >>> f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening >>> >>> 7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more >>> robust against dead store elimination >>> >>> cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce >>> __alias(symbol) shortcut >>> >>> 0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use >>> barrier instead of OPTIMIZER_HIDE_VAR >>> >>> ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of >>> buffer head flag operations >>> >>> cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool >>> compilation warning >>> >>> >>> >>> >>> >>> > The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android >>> based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores >>> (quad core) >>> >>> >>> >>> [1]: >>> https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/linux.config >>> >>> [2]: >>> https://github.com/JonasVautherin/meta-skycontroller3/blob/main/conf/machine/skycontroller3.conf#L32 >>> >>> [3]: >>> https://www.notebookcheck.net/Qualcomm-Snapdragon-212-APQ8009-SoC-Benchmarks-and-Specs.169859.0.html >>> >>> >>> >>> Best, >>> >>> >>> >>> On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <[email protected]> >>> wrote: >>> >>> On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <[email protected]> >>> wrote: >>> > >>> > As a learning experience, I am trying to create a BSP for a device I >>> own and whose downstream kernel is published. The device in question is the >>> Parrot Skycontroller3, and the sources are available here. >>> > >>> > Let me start by sharing my issue. When I build the kernel with >>> `bitbake virtual/kernel`, it fails with errors like: >>> > >>> > ``` >>> > | AS arch/arm/lib/backtrace.o >>> > | AS arch/arm/lib/bswapsdi2.o >>> > | AS arch/arm/lib/call_with_stack.o >>> > | /tmp/ccz8jKgm.s: Assembler messages: >>> > | /tmp/ccz8jKgm.s:985: Error: .err encountered >>> > | /tmp/ccz8jKgm.s:1033: Error: .err encountered >>> > | /tmp/ccz8jKgm.s:6812: Error: .err encountered >>> > ``` >>> > >>> > My layer is available here. >>> > >>> > I created it getting inspiration from meta-raspberrypi and >>> meta-qti-bsp, which seems to have the same CPU: apq8009. According to the >>> Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, >>> I use as a defconfig file the linux.config that is available in the Parrot >>> sources (I copied it in my kernel recipe under `files/defconfig` and added >>> it to SRC_URI). >>> > >>> > The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := >>> msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = >>> "msm8909_defconfig"`, but that is failing with different errors, such as: >>> > >>> > ``` >>> > error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this >>> function); did you mean 'DMA_ATTR_NON_CONSISTENT'? >>> > ``` >>> > >>> > or >>> > >>> > ``` >>> > error: 'L_PTE_YOUNG' undeclared >>> > ``` >>> > >>> > As a side note, their `drivers/Kconfig` seemed invalid, so I patched >>> it. >>> > >>> > I am a bit lost now, not completely sure where my issues come from. I >>> realize that changing the defconfig has quite some impact (I get different >>> errors), and also that my machine configuration may be completely wrong (I >>> am essentially guessing from the fact that it is an apq8009/msm8909, but >>> for instance the tuning I just copied from meta-qti-bsp, which may be >>> invalid). >>> > >>> > I would be glad if I could get hints about debugging this. Again, it >>> is really a learning project: I would like to learn how to create a BSP >>> from a downstream kernel. >>> >>> I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the >>> correct approach here. What you may be missing though is the correct >>> value for KCONFIG_MODE. By default, the supplied defconfig file is >>> copied to .config but dependencies between config options aren't >>> resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the >>> equivalent of `make msm8909_defconfig` to occur. See >>> >>> https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19 >>> for an idea of how this is done for Raspberry Pi. >>> >>> Thanks, >>> >>> -- >>> Paul Barker >>> Konsulko Group >>> >>> >>> -- >>> >>> *Diego Santa Cruz, PhD *Technology Architect >>> spinetix.com >>> >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52165): https://lists.yoctoproject.org/g/yocto/message/52165 Mute This Topic: https://lists.yoctoproject.org/mt/80047657/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
