Thanks Aaron! That seems to remove the log2 warnings, but it seems like they were not related to those "Assembler" errors, e.g.: ``` | /tmp/ccbtfgo7.s: Assembler messages: | /tmp/ccbtfgo7.s:2011: Error: .err encountered ``` I think I need to fix them like Diego was suggesting, but I have trouble relating the error to a source file... On Sat, Jan 30, 2021 at 8:29 AM Aaron Cohen wrote: > 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 > 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 < >> jonas.vautherin@gmail.com> 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 < >>> Diego.SantaCruz@spinetix.com> wrote: >>> >>>> *From:* yocto@lists.yoctoproject.org *On >>>> Behalf Of *Jonas Vautherin via lists.yoctoproject.org >>>> *Sent:* 24 January 2021 14:30 >>>> *To:* Jonas Vautherin >>>> *Cc:* Paul Barker ; Yocto-mailing-list < >>>> yocto@lists.yoctoproject.org> >>>> *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 >>> gmail.com@lists.yoctoproject.org> 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 >>>> >>>> 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 >>>> wrote: >>>> >>>> On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin < >>>> jonas.vautherin@gmail.com> 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 >>>> >>> >>> >>> >>> >> >> >>