Thanks a lot everybody, I managed to go further with Diego's idea! I removed the `const` in two other places, though I'm not sure if it was necessary (I'll check that later). But the `.err encountered` errors disappeared!
@Herman: checking your sources, too :-) Best Regards, On Mon, Feb 1, 2021 at 9:21 AM Herman van Hazendonk <[email protected]> wrote: > Hi, > > We've been using 3.18 (Android) kernels on our LuneOS project with Yocto, > so we carry the various patches to get it to build with newer GCC's. > > See: > https://github.com/shr-distribution/linux/commits/tissot/3.18/halium-7.1 > for some inspiration :) > > For older 3.4 kernels you would need more patches obviously: > > https://github.com/shr-distribution/linux/commits/hammerhead/3.4/halium-5.1 > > > Best regards, > Herman > > On 2021-02-01 08:04, Diego Santa Cruz via lists.yoctoproject.org wrote: > > *From:* Jonas Vautherin <[email protected]> > *Sent:* 31 January 2021 22:23 > *To:* Aaron Cohen <[email protected]> > *Cc:* Diego Santa Cruz <[email protected]>; Paul Barker < > [email protected]>; Yocto-mailing-list <[email protected]> > *Subject:* Re: [yocto] Writing a BSP from downstream kernel sources > > > > 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... > > *[Diego Santa Cruz] It may be easier to build the SDK with a dummy kernel > (i.e. no kernel, setting PREFERRED_PROVIDER_virtual/kernel ?= "linux-dummy" > in conf/local.conf) and use that SDK to get the kernel building outside of > Yocto. If you run the make with V=1 you will see the full compiler command > and you can re-run it manually. The use the -S (and eventually -E) line and > you can inspect the faulty assembly file or source and track the original > location. At least that is the route I took and worked well for me.* > > *I think you are using kernel 3.18.31, in that version it is the > __put_user_check macro you need to fix, > https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219 > <https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219>* > > > > *A hand written patch (not tested at all!) that should solve your problem > is* > > --- arch/arm/include/asm/uaccess.h > > +++ arch/arm/include/asm/uaccess.h > > #define > __put_user_check(x,p) > \ > > > ({ > \ > > unsigned long __limit = > current_thread_info()->addr_limit - 1; \ > > const typeof(*(p)) __user *__tmp_p = > (p); \ > > - register const typeof(*(p)) __r2 asm("r2") = > (x); \ > > + register typeof(*(p)) __r2 asm("r2") = > (x); \ > > register const typeof(*(p)) __user *__p > asm("r0") = __tmp_p; \ > > register unsigned long __l asm("r1") = > __limit; \ > > register int __e > asm("r0"); \ > > switch (sizeof(*(__p))) > { \ > > > > On Sat, Jan 30, 2021 at 8:29 AM Aaron Cohen <[email protected]> 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 > <[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 > > > > > -- > > *Diego Santa Cruz, PhD *Technology Architect > spinetix.com > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52209): https://lists.yoctoproject.org/g/yocto/message/52209 Mute This Topic: https://lists.yoctoproject.org/mt/80047657/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
