Date   

Re: [meta-tensorflow][PATCH 8/25] tensorflow-estimator: 1.13 -> 2.4

Marek Belisko
 

Hi Randy,

On Thu, Jan 7, 2021 at 9:47 PM Randy MacLeod
<randy.macleod@...> wrote:

On 2021-01-07 1:47 p.m., Belisko Marek wrote:
Marek,
Does this happen if you use the master branch?
Yes this comes from master branch.
Hi Marek,

Is it:
A) Comes from master and is a problem on dunfell or
B) it is reproducible on the master branch?

Given that you said:
> I'm getting issue when building tensorflow-estimator (I add small
> changes to be able to build this patches on top of dunfell) ...

I suspect it's A only. Right?

What are your small changes.

Hongxu may take a quick look but we generally can't afford to
investigate all combinations of recipe/branchs as I'm sure you
can appreciate.
I have done some small changes and now have tensorflow from master
working on top of dunfell. Would you be interested in sharing changes
back and integrate to repo?

If you can reproduce the error on master without or even with your
changes then that's a different story.

Good luck and Happy New Year!

--
# Randy MacLeod
# Wind River Linux
Thanks and BR,

marek


#yocto #armv6 #raspberrypi #neon #raspberrypi #neon #yocto #armv6

safouane maaloul
 

Hello folks, i am trying to compile my image but we could see that i am missing neon fpu in my image. I can't use this feature because i have a raspberry pi zero w and i have armv6 on this raspberrypi. I noticed that we don't the neon feature on armv6 so i wish that you can help me to find a work around this problem. Thanks in advance.

Best regards,

Safouane

this is an exemple of the error i get when i run the build :

| In file included from /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/git/av1/encoder/arm/neon/quantize_neon.c:12:
| /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/recipe-sysroot-native/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/10.2.0/include/arm_neon.h:10373:1: error: inlining failed in call to 'always_inline' 'vld1q_s32': target specific option mismatch
| 10373 | vld1q_s32 (const int32_t * __a)
|       | ^~~~~~~~~
| In file included from /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/git/av1/encoder/arm/neon/quantize_neon.c:20:
| /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/git/av1/common/arm/mem_neon.h:525:24: note: called from here
|   525 |   const int32x4_t v0 = vld1q_s32(buf);
|       |                        ^~~~~~~~~~~~~~
| ninja: build stopped: subcommand failed.
| WARNING: /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/temp/run.do_compile.11087:155 exit 1 from 'eval ${DESTDIR:+DESTDIR=${DESTDIR} }VERBOSE=1 cmake --build '/workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/build' "$@" -- ${EXTRA_OECMAKE_BUILD}'
| WARNING: Backtrace (BB generated script):
|       #1: cmake_runcmake_build, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/temp/run.do_compile.11087, line 155
|       #2: cmake_do_compile, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/temp/run.do_compile.11087, line 149
|       #3: do_compile, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/temp/run.do_compile.11087, line 144
|       #4: main, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/aom/2.0.0-r0/temp/run.do_compile.11087, line 168
|
| Backtrace (metadata-relative locations):
|       #1: cmake_runcmake_build, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/../../poky/meta/classes/cmake.bbclass, line 205
|       #2: cmake_do_compile, /workdir/tep-cam-rpi-yocto/rpi-build-gatesgarth/../../poky/meta/classes/cmake.bbclass, line 209
|       #3: do_compile, autogenerated, line 2


Re: insmod - huawei E3372h kernel module

Zoltan Kerenyi Nagy
 

Hi,

If I intentionally typo in the defconfig file:

USB_NET_HUAWEI_CDC_NCM_cat=y
USB_NET_DRIVERS=y
USB_USBNET=y

The bitbake -f linux command doesn't recognize the change. It means to me that any change in this will not have an effect.

--
Zolee


Re: Points to consider while moving to new yocto versions

Robert Berger
 

Hi,

My comments are in-line

On 25/01/2021 10:07, amaya jindal wrote:
Hi All,
We are planning to move to New yocto from current one that is krogoth yocto to some updated one.
I would consider it "best practice" to somewhat try to stay up to date with recent yocto versions and plan for this from the beginning of your project.

What I mean is to have a "stable release" and a "next release" which is being used in your nightly builds and tests.

This will make it significantly easier to make version upgrades.

We are not thinking to move to gates-garth or some other major release but the releases than can have easily support for arm.
I am not sure what you mean by that?

Which versions make it easier/more difficult to support arm?

It's more a question of which chip/kernel/boot loader,...

Please support and help.
Points need to take care to port to new yocto version.
Ssince you use a completely outdated and end of life version[1] it might require quite some effort to update, but through pain we learn ;)

[1] https://wiki.yoctoproject.org/wiki/Releases

Which chip do you use?

Is it supported by an upstream kernel/boot loader?

Which (additional) layers do you use?

Are these layers supported by the same version as the Yocto version you want to move to?

How about your own recipes?

Are they compatible with upstream yocto?

Regards,
Rohit
Regards,

Robert


Re: NPM Fetcher & License collection in Yocto Zeus

Oliver Westermann
 

Hey,

 

I figured to squeeze in a test and it seems that this is solved in Dunfell, at least I can’t trigger it even when trying and the folder structure used in the work directory has changed -> No issues there I guess.

 

For Zeus: I’ve checked https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=zeus and it seems that there are no new commits. From https://wiki.yoctoproject.org/wiki/Releases zeus is in the Community phase.
Does this mean no new commits -> Add it to some kind of “known issues” page? Or does it make sense to provide a patch for the zeus branch?

 

Best regards, Olli

 

Von: Jean-Marie Lemetayer <jeanmarie.lemetayer@...>
Gesendet: Freitag, 22. Januar 2021 11:31
An: Westermann, Oliver <Oliver.Westermann@...>
Cc: yocto@...
Betreff: [EXTERNAL] Re: [yocto] NPM Fetcher & License collection in Yocto Zeus

 

Hi Olivier,

 

Thanks for your implication :)

 

I think the modification you want to make resides in the npm class file:

 

But, starting with dunfell, the npm related mechanism have been reworked and also the npm class:

 

Is it possible to test if you have the same issue with dunfell ?

 

Best Regards,

Jean-Marie

 

On Fri, Jan 22, 2021 at 10:00 AM Oliver Westermann <oliver.westermann@...> wrote:

Hey,

We’ve upgraded to zeus some time ago and also updated some of our recipes around node-red and it’s nodes. Before I created my own class to easily fetch several nodes, now we used devtool to create those recipes. In zeus, this happens using the npm:// fetcher.

This worked fine, but we sometimes had QA errors, hard to reproduce. Sometimes on some peoples PC, the license files were missing when do_populate_lic was running.

ERROR: node-red-contrib-socketio-1.0.7-r0 do_populate_lic: QA Issue: node-red-contrib-socketio: LIC_FILES_CHKSUM points to an invalid file: /data/workspace/yocto-build/build/cognex-myna/tmp/work/aarch64-poky-linux/node-red-contrib-socketio/1.0.7-r0/npmpkg/node_modules/
socket.io/node_modules/@types/cookie/LICENSE [license-checksum]

Turned out that do_unpack would download the dependencies of the node-red-module (so in the example above, node-red-contrib-socketio depends on
socket.io), but do_install would package those away/clean them up.
Since they go into the resulting package, we still have to list those licenses, so I fixed it by adding

do_install[depends] += "${PN}:do_populate_lic"

to my packages to fix the order.

However I would like to fix this upstream, but couldn't find the correct source location to add this dependency. Can sb help me figure this out as I would like to contribute
😉

Best regards, Olli


Re: Points to consider while moving to new yocto versions

Erik Boto
 

Hi,

I'd start by looking at the relevant documentation section,
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#general-migration-considerations.
There you can also find a per-release summary of changes that are
worth knowing when moving to that release.

Moving from krogoth to e.g. gatesgarth is quite a jump, so I'd expect
that it might require some effort. If you don't intend to follow along
new version, you might want to consider using dunfell which is the
current LTS version.

Cheers,
Erik

On Mon, Jan 25, 2021 at 9:07 AM amaya jindal <amayajindal786@...> wrote:

Hi All,

We are planning to move to New yocto from current one that is krogoth yocto to some updated one. We are not thinking to move to gates-garth or some other major release but the releases than can have easily support for arm.

Please support and help.

Points need to take care to port to new yocto version.

Regards,
Rohit



Re: QA notification for completed autobuilder build (yocto-3.3_M2.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3_M2.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Thursday, January 28.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Pokybuild User
Sent: Thursday, 21 January, 2021 1:05 PM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3_M2.rc1)


A build flagged for QA (yocto-3.3_M2.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3_M2.rc1


Build hash information:

bitbake: 01e901c44ab0f496606b1d45c8953dc54970204c
meta-arm: a8f32f990a0d9dc1db310892c70d5a994c698b32
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: b4e5d33affeaa223459c0935a853485137b4591d
meta-kernel: 8349870943ba44bbd688656897372e881f32c741
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: 79821d5a185e25384f5b6b5158b238bbee17c79e
poky: b5e634644b69a968a93aad0dd0502cf479d3973a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



Points to consider while moving to new yocto versions

amaya jindal
 

Hi All,

We are planning to move to New yocto from current one that is krogoth yocto to some updated one. We are not thinking to move to gates-garth or some other major release but the releases than can have easily support for arm.

Please support and help. 

Points need to take care to port to new yocto version.

Regards, 
Rohit


Re: Writing a BSP from downstream kernel sources

Diego Santa Cruz
 

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
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@...> 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)

 

 

Best,

 

On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:

On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> 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


FW: JFFS2 File system support

sharmila.d@...
 

 

Hi,

              I am using TI based processor for our custom project. We are using NAND as our Boot media. The type of the File system we opted is JFFS2.

              The following lines I have added in my machine configuration file for creating jffs2 root file system.

             

IMAGE_FSTYPES += "jffs2 tar.xz"

EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"

 

The system is hanging during the boot. It is actually getting stuck in below message

 

systemd-journald[75]: Received request to flush runtime journal from PID 1

 

I have attached my dmesg log FYR.

 

Thank you,

 

With Best Regards,

Sharmila D

 


Re: #yocto #kernel setting up PREMIRRORS under zeus #yocto #kernel

Robert Berger
 

Hi,

Please see my comments in-line.

On 24/01/2021 22:09, Robert P. J. Day wrote:
On Sun, 24 Jan 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

I added the following to my local.conf:

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = “file:///ede/tms/yocto/zeus/downloads/PATH”
I assume your sources are in /ede/tms/yocto/zeus/downloads/

Can you please try without the PATH at the end?

The manual does not mention anything like PATH at the end[1]

I do expose my per site premirror via a web server to all the machines like this:

SOURCE_MIRROR_URL = "http://mirror/source_mirror_gatesgarth"

[1] https://docs.yoctoproject.org/singleindex.html#term-SOURCE_MIRROR_URL


But this does not appear to retrieve the tar-balls from from my local repository…
not sure why that wouldn't work, it's what i've used for years.
rday
Regards,

Robert


Re: #yocto #kernel setting up PREMIRRORS under zeus #yocto #kernel

Robert P. J. Day
 

On Sun, 24 Jan 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

I added the following to my local.conf:

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = “file:///ede/tms/yocto/zeus/downloads/PATH”

But this does not appear to retrieve the tar-balls from from my local repository…
not sure why that wouldn't work, it's what i've used for years.

rday


#yocto #kernel setting up PREMIRRORS under zeus #yocto #kernel

Monsees, Steven C (US)
 

 

I am trying to setup PREMIRRORS to setup and point to the directory containing all the tar-balls for my build…

I was under the impression that the “SOURCE_MIRROR_URL” is a quick way to add a series of PREMIRROR entries for all supported protocols.

 

I added the following to my local.conf:

 

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = “file:///ede/tms/yocto/zeus/downloads/PATH

 

But this does not appear to retrieve the tar-balls from from my local repository…

 

What is the proper syntax required to setup PREMIRRORS to point to and use my local repo ?

 

Thanks,

Steve


Re: Writing a BSP from downstream kernel sources

Jonas Vautherin
 

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


Best,

On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> 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




[meta-rockchip][PATCH] linux-yocto: Remove Rock Pi 4 patch for serial

Joshua Watt
 

Upstream OE Core has moved to Kernel 5.10 which fixed this problem, so
remove the patch for 5.8

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
...-resolve-supply-after-creating-regul.patch | 53 -------------------
recipes-kernel/linux/linux-yocto_5.8.bbappend | 4 --
2 files changed, 57 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
delete mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
deleted file mode 100644
index 3dd336b..0000000
--- a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
-From: Joshua Watt <JPEWhacker@...>
-Date: Thu, 10 Dec 2020 15:59:47 -0600
-Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
-
-This commit prevents the serial console from working on the Rock Pi 4
-for some reason. It *appears* to possibly be fixed by some other commit
-upstream, but after a lot of head scratching and bisecting, I was unable
-to find which one, so just revert it for now and we can deal with it
-later.
-
-This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
-
----
- drivers/regulator/core.c | 21 ++++++++-------------
- 1 file changed, 8 insertions(+), 13 deletions(-)
-
-diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
-index 25e601bf9383..be8c709a7488 100644
---- a/drivers/regulator/core.c
-+++ b/drivers/regulator/core.c
-@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc *regulator_desc,
- else if (regulator_desc->supply_name)
- rdev->supply_name = regulator_desc->supply_name;
-
-+ /*
-+ * Attempt to resolve the regulator supply, if specified,
-+ * but don't return an error if we fail because we will try
-+ * to resolve it again later as more regulators are added.
-+ */
-+ if (regulator_resolve_supply(rdev))
-+ rdev_dbg(rdev, "unable to resolve supply\n");
-+
- ret = set_machine_constraints(rdev, constraints);
-- if (ret == -EPROBE_DEFER) {
-- /* Regulator might be in bypass mode and so needs its supply
-- * to set the constraints */
-- /* FIXME: this currently triggers a chicken-and-egg problem
-- * when creating -SUPPLY symlink in sysfs to a regulator
-- * that is just being created */
-- ret = regulator_resolve_supply(rdev);
-- if (!ret)
-- ret = set_machine_constraints(rdev, constraints);
-- else
-- rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
-- ERR_PTR(ret));
-- }
- if (ret < 0)
- goto wash;
-
---
-2.29.2
-
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend b/recipes-kernel/linux/linux-yocto_5.8.bbappend
deleted file mode 100644
index 5a31842..0000000
--- a/recipes-kernel/linux/linux-yocto_5.8.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI_append_rock-pi-4 = " file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
-
--
2.30.0


[meta-rockchip][PATCH] rock-pi-4: Split our variant machines

Joshua Watt
 

Splits out the three variants of the rock-pi-4 (A, B & C) into their own
machines. Unfortunately, it is not possible to have a single machine
that works for all three, as there isn't any known ways for the
bootloader to distinguish them.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3399.inc | 2 +-
conf/machine/{rock-pi-4.conf => include/rock-pi-4.inc} | 8 ++------
conf/machine/rock-pi-4a.conf | 8 ++++++++
conf/machine/rock-pi-4b.conf | 8 ++++++++
conf/machine/rock-pi-4c.conf | 8 ++++++++
5 files changed, 27 insertions(+), 7 deletions(-)
rename conf/machine/{rock-pi-4.conf => include/rock-pi-4.inc} (68%)
create mode 100644 conf/machine/rock-pi-4a.conf
create mode 100644 conf/machine/rock-pi-4b.conf
create mode 100644 conf/machine/rock-pi-4c.conf

diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 4019988..f6b7826 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -5,8 +5,8 @@ SOC_FAMILY = "rk3399"

DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"

-require conf/machine/include/tune-cortexa72-cortexa53.inc
require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa72-cortexa53.inc
require conf/machine/include/rockchip-defaults.inc

KBUILD_DEFCONFIG ?= "defconfig"
diff --git a/conf/machine/rock-pi-4.conf b/conf/machine/include/rock-pi-4.inc
similarity index 68%
rename from conf/machine/rock-pi-4.conf
rename to conf/machine/include/rock-pi-4.inc
index 5231abf..7a98063 100644
--- a/conf/machine/rock-pi-4.conf
+++ b/conf/machine/include/rock-pi-4.inc
@@ -1,15 +1,11 @@
# Copyright (C) 2020 Garmin Ltd. or its subsidaries
# Released under the MIT license (see COPYING.MIT for the terms)

-#@TYPE: Machine
-#@NAME: Rock Pi 4 RK3399
-#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+# Add a common override for all Rock Pi 4 machines
+MACHINEOVERRIDES =. "rock-pi-4:"

require conf/machine/include/rk3399.inc

-KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4.dtb"
-UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
-
RK_BOOT_DEVICE = "mmcblk1"
WKS_FILE ?= "rock-pi-4.wks"
IMAGE_FSTYPES += "wic wic.bmap"
diff --git a/conf/machine/rock-pi-4a.conf b/conf/machine/rock-pi-4a.conf
new file mode 100644
index 0000000..9f3aa5a
--- /dev/null
+++ b/conf/machine/rock-pi-4a.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4A RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4a.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4b.conf b/conf/machine/rock-pi-4b.conf
new file mode 100644
index 0000000..033c063
--- /dev/null
+++ b/conf/machine/rock-pi-4b.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4B RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4b.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4c.conf b/conf/machine/rock-pi-4c.conf
new file mode 100644
index 0000000..9e9bbbb
--- /dev/null
+++ b/conf/machine/rock-pi-4c.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4C RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4c.dtb"
+UBOOT_MACHINE = "rock-pi-4c-rk3399_defconfig"
--
2.30.0


Re: Writing a BSP from downstream kernel sources

Jonas Vautherin
 

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)


Best,

On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> 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: Writing a BSP from downstream kernel sources

 

On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> 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


Writing a BSP from downstream kernel sources

Jonas Vautherin
 

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
```


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.

Best,


Re: OpenEmbedded Virtual Stand at FOSDEM 2021

 

On Thu, 14 Jan 2021 at 11:02, Robert Berger@...
<robert.berger.yocto.user@...> wrote:

Hi,

On 13/01/2021 23:33, Paul Barker wrote:
Hi folks,

* Any participants in the project who want to help host the Matrix
chat room between 09:00 and 18:00 each day of the event. This will
likely involve introducing the project to folks dropping in the chat
who aren't familiar with OpenEmbedded, answering basic questions and
chatting about example uses of the project. You don't need to be a
long-standing expert in the project to help out here! If you can do a
couple of hours or a half day please let us know.
Let's try to come up with some schedule when I should be there and just
let me know how the join the chat.


* Any contributions of video content to go along with the static web
pages. I'm planning to record some short introductory video content
but other contributions would also be welcome. Details on how to
upload videos is expected in the near future but for now it would be
good to just collect folks who are interested so we can discuss this
further.

If you're interested in any of the above please reply to me and/or the
list. I look forward to virtually seeing many of you at FOSDEM 2021!
What kind of video would you like? A small video which explains a
specific topic?

Something like this?[1]

[1] https://www.youtube.com/watch?v=kmpEN953pzs&feature=youtu.be
I'd say video content for FOSDEM should be around the level of the
things we'd show on the stand, short demos or introductions which can
be understood by people not too familiar with the details of the
project.

I'm going to record a short "Introducing OpenEmbedded" presentation
based around the way I usually pitch the project to folks who turn up
at our FOSDEM stand and ask what the project is about. I may also do a
quick build & boot demo with a Raspberry Pi if I have time to record
that.

Thanks,

--
Paul Barker
Konsulko Group

5721 - 5740 of 57780