From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Jonas Vautherin via lists.yoctoproject.org Sent: 24 January 2021 14:30 To: Jonas Vautherin <jonas.vauthe...@gmail.com> Cc: Paul Barker <pbar...@konsulko.com>; 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<http://lists.yoctoproject.org> <jonas.vautherin=gmail....@lists.yoctoproject.org<mailto:gmail....@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 <pbar...@konsulko.com<mailto:pbar...@konsulko.com>> wrote: On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vauthe...@gmail.com<mailto:jonas.vauthe...@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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52079): https://lists.yoctoproject.org/g/yocto/message/52079 Mute This Topic: https://lists.yoctoproject.org/mt/80047657/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
