Writing a BSP from downstream kernel sources

Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

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
<https://github.com/parrot-opensource/skycontroller3-opensource>.

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.
<https://github.com/JonasVautherin/meta-skycontroller3>

I created it getting inspiration from meta-raspberrypi and meta-qti-bsp
<https://github.com/mcharleb/meta-qti-bsp/blob/yocto.lnx.1.0.r10-rel/conf/machine/apq8009.conf>,
which seems to have the same CPU: apq8009. According to the Parrot sources
<https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/atom.mk#L1>,
my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a
defconfig file the linux.config
<https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/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
<https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/atom.mk#L12>
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
<https://github.com/JonasVautherin/meta-skycontroller3/blob/main/recipes-kernel/linux/files/Kconfig.patch>
.

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
<https://github.com/JonasVautherin/meta-skycontroller3/tree/main/conf/machine>
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.

Best,

[-- Attachment #2: Type: text/html, Size: 3313 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Paul Barker]

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

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

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.:

```
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```

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]:

> 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 <pbarker@konsulko.com> 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
>

[-- Attachment #2: Type: text/html, Size: 5411 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 5164 bytes --]

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 :-).

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org
<jonas.vautherin=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.:
>
> ```
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> ```
>
> 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]:
>
> > 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 <pbarker@konsulko.com> 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
>>
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 6756 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Diego Santa Cruz]

[-- Attachment #1: Type: text/plain, Size: 8067 bytes --]

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.vautherin@gmail.com>
Cc: Paul Barker <pbarker@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.com@lists.yoctoproject.org<mailto: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 <pbarker@konsulko.com<mailto:pbarker@konsulko.com>> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@gmail.com<mailto: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

[-- Attachment #2: Type: text/html, Size: 17010 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 11700 bytes --]

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 <yocto@lists.yoctoproject.org> *On
> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
> *Sent:* 24 January 2021 14:30
> *To:* Jonas Vautherin <jonas.vautherin@gmail.com>
> *Cc:* Paul Barker <pbarker@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
> <jonas.vautherin=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
> <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 <pbarker@konsulko.com> 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
>

[-- Attachment #2: Type: text/html, Size: 18291 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Joel A Cohen]

[-- Attachment #1.1: Type: text/plain, Size: 12327 bytes --]

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 <yocto@lists.yoctoproject.org> *On
>> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
>> *Sent:* 24 January 2021 14:30
>> *To:* Jonas Vautherin <jonas.vautherin@gmail.com>
>> *Cc:* Paul Barker <pbarker@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 <jonas.vautherin=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
>> <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 <pbarker@konsulko.com>
>> 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
>>
>
> 
>
>

[-- Attachment #1.2: Type: text/html, Size: 19060 bytes --]

[-- Attachment #2: 0010-Backport-ilog2-kernel-compile-fix.patch --]
[-- Type: text/x-patch, Size: 1424 bytes --]

From ea95e4bccc65546a28c8ac05f900d0482623043b Mon Sep 17 00:00:00 2001
From: Joel 'Aaron' Cohen <aaron.cohen@assonance.org>
Date: Wed, 29 Apr 2020 16:12:22 -0400
Subject: [PATCH] Backport ilog2 kernel compile fix

---
 include/linux/log2.h | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/include/linux/log2.h b/include/linux/log2.h
index fd7ff3d91e6a..f38fae23bdac 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -15,12 +15,6 @@
 #include <linux/types.h>
 #include <linux/bitops.h>
 
-/*
- * deal with unrepresentable constant logarithms
- */
-extern __attribute__((const, noreturn))
-int ____ilog2_NaN(void);
-
 /*
  * non-constant log of base 2 calculators
  * - the arch may override these in asm/bitops.h if they can be implemented
@@ -85,7 +79,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 #define ilog2(n)				\
 (						\
 	__builtin_constant_p(n) ? (		\
-		(n) < 1 ? ____ilog2_NaN() :	\
+		(n) < 2 ? 0 :			\
 		(n) & (1ULL << 63) ? 63 :	\
 		(n) & (1ULL << 62) ? 62 :	\
 		(n) & (1ULL << 61) ? 61 :	\
@@ -148,10 +142,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 		(n) & (1ULL <<  4) ?  4 :	\
 		(n) & (1ULL <<  3) ?  3 :	\
 		(n) & (1ULL <<  2) ?  2 :	\
-		(n) & (1ULL <<  1) ?  1 :	\
-		(n) & (1ULL <<  0) ?  0 :	\
-		____ilog2_NaN()			\
-				   ) :		\
+		1 ) :				\
 	(sizeof(n) <= 4) ?			\
 	__ilog2_u32(n) :			\
 	__ilog2_u64(n)				\

Re: [yocto] Writing a BSP from downstream kernel sources

[Joel A Cohen]

[-- Attachment #1: Type: text/plain, Size: 12967 bytes --]

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
<aaron=assonance.org@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 <yocto@lists.yoctoproject.org> *On
>>> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
>>> *Sent:* 24 January 2021 14:30
>>> *To:* Jonas Vautherin <jonas.vautherin@gmail.com>
>>> *Cc:* Paul Barker <pbarker@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 <jonas.vautherin=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
>>> <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 <pbarker@konsulko.com>
>>> 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
>>>
>>
>>
>>
>>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 19820 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 13749 bytes --]

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 <aaron@assonance.org> 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
> <aaron=assonance.org@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 <yocto@lists.yoctoproject.org> *On
>>>> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
>>>> *Sent:* 24 January 2021 14:30
>>>> *To:* Jonas Vautherin <jonas.vautherin@gmail.com>
>>>> *Cc:* Paul Barker <pbarker@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 <jonas.vautherin=
>>>> 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
>>>> <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 <pbarker@konsulko.com>
>>>> 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
>>>>
>>>
>>>
>>>
>>>
>> 
>>
>>

[-- Attachment #2: Type: text/html, Size: 20670 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Diego Santa Cruz]

[-- Attachment #1: Type: text/plain, Size: 14950 bytes --]

From: Jonas Vautherin <jonas.vautherin@gmail.com>
Sent: 31 January 2021 22:23
To: Aaron Cohen <aaron@assonance.org>
Cc: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>; Paul Barker <pbarker@konsulko.com>; Yocto-mailing-list <yocto@lists.yoctoproject.org>
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

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 <aaron@assonance.org<mailto:aaron@assonance.org>> 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<http://lists.yoctoproject.org> <aaron=assonance.org@lists.yoctoproject.org<mailto:assonance.org@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<mailto: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<mailto:Diego.SantaCruz@spinetix.com>> wrote:
From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Jonas Vautherin via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@gmail.com<mailto:jonas.vautherin@gmail.com>>
Cc: Paul Barker <pbarker@konsulko.com<mailto:pbarker@konsulko.com>>; Yocto-mailing-list <yocto@lists.yoctoproject.org<mailto: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.com@lists.yoctoproject.org<mailto: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 <pbarker@konsulko.com<mailto:pbarker@konsulko.com>> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@gmail.com<mailto: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<http://spinetix.com>



--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com



[-- Attachment #2: Type: text/html, Size: 36144 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Herman van Hazendonk (Herrie)]

[-- Attachment #1: Type: text/plain, Size: 15599 bytes --]

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 <jonas.vautherin@gmail.com> 
> SENT: 31 January 2021 22:23
> TO: Aaron Cohen <aaron@assonance.org>
> CC: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>; Paul Barker <pbarker@konsulko.com>; Yocto-mailing-list <yocto@lists.yoctoproject.org>
> 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 [1]_ 
> 
> _ _ 
> 
> _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 <aaron@assonance.org> 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 [2] <aaron=assonance.org@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 <yocto@lists.yoctoproject.org> ON BEHALF OF Jonas Vautherin via lists.yoctoproject.org [2]
> SENT: 24 January 2021 14:30
> TO: Jonas Vautherin <jonas.vautherin@gmail.com>
> CC: Paul Barker <pbarker@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 [2] <jonas.vautherin=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 [3] 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 <pbarker@konsulko.com> 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 [4] 

-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com 

>> 



 

Links:
------
[1]
https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219
[2] http://lists.yoctoproject.org
[3]
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html
[4] http://spinetix.com

[-- Attachment #2: Type: text/html, Size: 37130 bytes --]

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

[-- Attachment #1: Type: text/plain, Size: 16166 bytes --]

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 <me@herrie.org> 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 <jonas.vautherin@gmail.com>
> *Sent:* 31 January 2021 22:23
> *To:* Aaron Cohen <aaron@assonance.org>
> *Cc:* Diego Santa Cruz <Diego.SantaCruz@spinetix.com>; Paul Barker <
> pbarker@konsulko.com>; Yocto-mailing-list <yocto@lists.yoctoproject.org>
> *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 <aaron@assonance.org> 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
> <aaron=assonance.org@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 <yocto@lists.yoctoproject.org> *On
> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
> *Sent:* 24 January 2021 14:30
> *To:* Jonas Vautherin <jonas.vautherin@gmail.com>
> *Cc:* Paul Barker <pbarker@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
> <jonas.vautherin=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
> <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 <pbarker@konsulko.com> 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
>
>
>
>
> --
>
> *Diego Santa Cruz, PhD *Technology Architect
> spinetix.com
>
>
>
>
>
>
>
> 
>
>
>

[-- Attachment #2: Type: text/html, Size: 28133 bytes --]