Date   

[meta-zephyr][PATCH v2 2/2] zephyr-peripheral-esp: fix compilation

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@huawei.com>

Bluetooth peripheral ESP sample application does not compile
because of:
- broken source directory path passing to cmake,
- broken paths in do_deploy,
- unnecessary call for do_install,
- missing tinycrypt.

The first issue caused the following error:

<...>/gcc/arm-yocto-eabi/9.3.0/ld: <...>/recipe-sysroot/usr/lib/libc.a(lib_a-exit.o): in function `exit':
/usr/src/debug/newlib/3.2.0-r0/newlib-3.2.0/newlib/libc/stdlib/exit.c:64: undefined reference to `_exit'
collect2: error: ld returned 1 exit status

Fix the issue by providing Zephyr source directory to cmake
via OECMAKE_SOURCEPATH variable. On the do_configure step cmake
now gets the full path to the sample source code instead of
Zephyr root directory.

The second and third issue caused errors because of missing files.
Don't execute do_install and use the same paths in deploy as the
other sample apps do.

Inspecting meta-zephyr commits history shows that similar approach
was used in bb files of other sample application when updating
them to work with Zephyr 2.0.

For the missing Tinycrypt, append its location to cmake.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
index 2ffe5ae..192c76d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
@@ -5,15 +5,12 @@ inherit deploy
ZEPHYR_SAMPLE_NAME="samples/bluetooth/peripheral_esp"
ZEPHYR_SRC_DIR = "${S}/${ZEPHYR_SAMPLE_NAME}"
ZEPHYR_BASE = "${S}"
-
-do_compile () {
- cd ${ZEPHYR_SRC_DIR}
- oe_runmake ${ZEPHYR_MAKE_ARGS}
-}
+OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
+EXTRA_OECMAKE_append = "\;${S}/modules/crypto/tinycrypt"

do_deploy () {
- install -D ${ZEPHYR_SAMPLE_NAME}/outdir/${BOARD}/zephyr.elf ${DEPLOYDIR}/${PN}.elf
- install -D ${ZEPHYR_SAMPLE_NAME}/outdir/${BOARD}/zephyr.bin ${DEPLOYDIR}/${PN}.bin
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
}

addtask deploy after do_compile
+do_install[noexec] = "1"
--
2.25.1


[meta-zephyr][PATCH v2 1/2] zephyr-kernel: clone Tinycrypt

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@huawei.com>

Tinycrypt is a library used in some sample applications,
i.e. in zephyr-peripheral-esp. Add it to kernel bbclass,
so it can be referenced in applications recipes that
use it.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
classes/zephyr-kernel-src.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index b7fb81d..c6c8d61 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -9,6 +9,7 @@ SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.4-branch;name=default \
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
@@ -16,6 +17,7 @@ SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
+ git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
file://0001-cmake-add-yocto-toolchain.patch \
"

--
2.25.1


[meta-zephyr][PATCH v2 0/2] Fix Bluetooth Peripheral ESP sample compilation

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@huawei.com>

v1 -> v2:
- Addedd missing [meta-zephyr] tag
- Re-sending with slightly different git-send-email
configuration, so the authorship is pointed to my @huawei.com email
instead of the one I'm sending it from.

Wojciech Zmuda (2):
zephyr-kernel: clone Tinycrypt
zephyr-peripheral-esp: fix compilation

classes/zephyr-kernel-src.bbclass | 2 ++
recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb | 11 ++++-------
2 files changed, 6 insertions(+), 7 deletions(-)

--
2.25.1


[PATCH 2/2] zephyr-peripheral-esp: fix compilation

Wojciech Zmuda
 

Bluetooth peripheral ESP sample application does not compile
because of:
- broken source directory path passing to cmake,
- broken paths in do_deploy,
- unnecessary call for do_install,
- missing tinycrypt.

The first issue caused the following error:

<...>/gcc/arm-yocto-eabi/9.3.0/ld: <...>/recipe-sysroot/usr/lib/libc.a(lib_a-exit.o): in function `exit':
/usr/src/debug/newlib/3.2.0-r0/newlib-3.2.0/newlib/libc/stdlib/exit.c:64: undefined reference to `_exit'
collect2: error: ld returned 1 exit status

Fix the issue by providing Zephyr source directory to cmake
via OECMAKE_SOURCEPATH variable. On the do_configure step cmake
now gets the full path to the sample source code instead of
Zephyr root directory.

The second and third issue caused errors because of missing files.
Don't execute do_install and use the same paths in deploy as the
other sample apps do.

Inspecting meta-zephyr commits history shows that similar approach
was used in bb files of other sample application when updating
them to work with Zephyr 2.0.

For the missing Tinycrypt, append its location to cmake.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
index 2ffe5ae..192c76d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
@@ -5,15 +5,12 @@ inherit deploy
ZEPHYR_SAMPLE_NAME="samples/bluetooth/peripheral_esp"
ZEPHYR_SRC_DIR = "${S}/${ZEPHYR_SAMPLE_NAME}"
ZEPHYR_BASE = "${S}"
-
-do_compile () {
- cd ${ZEPHYR_SRC_DIR}
- oe_runmake ${ZEPHYR_MAKE_ARGS}
-}
+OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
+EXTRA_OECMAKE_append = "\;${S}/modules/crypto/tinycrypt"

do_deploy () {
- install -D ${ZEPHYR_SAMPLE_NAME}/outdir/${BOARD}/zephyr.elf ${DEPLOYDIR}/${PN}.elf
- install -D ${ZEPHYR_SAMPLE_NAME}/outdir/${BOARD}/zephyr.bin ${DEPLOYDIR}/${PN}.bin
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
}

addtask deploy after do_compile
+do_install[noexec] = "1"
--
2.25.1


[PATCH 1/2] zephyr-kernel: clone Tinycrypt

Wojciech Zmuda
 

Tinycrypt is a library used in some sample applications,
i.e. in zephyr-peripheral-esp. Add it to kernel bbclass,
so it can be referenced in applications recipes that
use it.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
classes/zephyr-kernel-src.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index b7fb81d..c6c8d61 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -9,6 +9,7 @@ SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.4-branch;name=default \
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
@@ -16,6 +17,7 @@ SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
+ git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
file://0001-cmake-add-yocto-toolchain.patch \
"

--
2.25.1


[PATCH 0/2] Fix Bluetooth Peripheral ESP sample compilation

Wojciech Zmuda
 

The zephyr-peripheral-esp target cannot be built due to multiple of reasons,
mostly missing tinycript and the recipe being not aligned to changes that
happened during upudating this meta-layer to Zephyr v2.4.0.

This patch set applies necessary fixes and clones Tinycrypt so it can be used
in other recipes that need it.

Tested on 96Boards Nitrogen.


Wojciech Zmuda (2):
zephyr-kernel: clone Tinycrypt
zephyr-peripheral-esp: fix compilation

classes/zephyr-kernel-src.bbclass | 2 ++
recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb | 11 ++++-------
2 files changed, 6 insertions(+), 7 deletions(-)

--
2.25.1


Re: #yocto CORE_IMAGE_EXTRA_INSTALL Where can I find a list of valid package names? #yocto

Quentin Schulz
 

Hi David,

On Thu, Feb 04, 2021 at 01:24:35AM -0700, David Babich wrote:
Thanks for that reply. I actually deleted my message from the forum post
because I thought maybe I hadn't dug through things enough and perhaps I
was wasting people's time. But I think you provided some validation to my
question. I'm more used to the typical ncurses method of configuration of
the old days with a kernel config a rootfs config etc. I will try your
suggested command. But I'm wondering are the names typical of what I might
expect if I were to do something like "sudo apt-get install <whatever>"
Not always. E.g. debian packages are renamed if they only have a library
in it to be the name of said library. This does not happen for rpm and
opkg. Note: this is a vague memory, I don't use de packages in Yocto so
to be taken with a grain of salt.

(which is somewhat of an experience thing) or do I just simply need to dig
around on web searches to find out what the actual name is. I've found
Not web searches. Basically, one would need to identify the recipe
building the software in the package you want to find.
From there, you can read the list of packages in PACKAGES (sometimes,
like for gstreamer plugins for example, it is dynamically set so you
won't be able to find them by just reading the recipe (though you can
more or less guess them)).

To know what's inside one of the packages without baking the recipe, one
would need to have a look at the FILES_${PN}<-xxx> variables.

It's therefore mostly knowledge and trial and errors as Josef said.

The difficulty for the Yocto project to compile a list of packages and
which recipe build them is that packages can depend on configuration
files (machines, distros, ...). Sometimes they do appear, sometimes not.
Sometimes a package for a distro contains more than a package for
another distro while having the same name.

Which is also a reason why ncurses/menuconfig would be hard for Yocto
Project, because content of packages are not guaranteed to be identical
between machines and distros, so it'd be hard to give descriptions of
options to select.

Hope this helps,
Quentin


Re: #yocto CORE_IMAGE_EXTRA_INSTALL Where can I find a list of valid package names? #yocto

David Babich
 

FYI I just tried your suggestion and it yielded great results.  Nice suggestion!


Re: #yocto CORE_IMAGE_EXTRA_INSTALL Where can I find a list of valid package names? #yocto

Josef Holzmayr
 

Howdy!

Am Mi., 3. Feb. 2021 um 23:26 Uhr schrieb <ddbabich@bootseeds.com>:
Hi, I've just started making use of the CORE_IMAGE_EXTRA_INSTALL variable in my local.conf. I'm really confused about where everyone is finding valid names for the packages? I though maybe it was the recipe names in meta but I've run into build errors if I add something like "dhcp" to the list for example. I looked it up in the yocto manual and it just basically restates what I already know but without telling me how to find package names. When I search around on google all I find are examples of people adding packages to it and having some issue, but I haven't seen any reference to where those names come from. Could someone please point me to the documentation, or point me where to look for a list of valid names?
Well for the most of us its pure experience and knowledge -most
package names actually match the recipe name, its a somewhat rough
best practise. However, to get a list of packages available in a
specific build, you can use

oe-pkgdata-util list-pkgs

... and pipe it trough your most loved pager/searcher :)

Greetz!


configure: error: C compiler cannot create executables #dunfell #toolchain #yocto

Vijay Rakesh Munganda
 

Hi, 

I'm running cmake to build shared libraries, but cmake gives me following error. Please suggest me.
 
| checking whether make supports the include directive... yes (GNU style)
| checking for gcc... /home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc
| checking whether the C compiler works... no
| configure: error: in `/home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/git/open-source/liblog4cplus/build/src/project_log4cplus':
| configure: error: C compiler cannot create executables

Regards,
Vijay


Re: 2038 time problem fix in yocto #kernel #linux #yocto #zeus

dhandhukiya.paresh@...
 

As you mentioned updating the kernel does not fix the other packages.
And we don't have know how about each linux package so its not that easy to fix it by ourself.
So, I am trying to know if there is any concrete plan in Yocto Community to fix this issue at yocto level and any timeline to do it?


Re: Writing a BSP from downstream kernel sources

Jonas Vautherin
 

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@...> 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@...>
Sent: 31 January 2021 22:23
To: Aaron Cohen <aaron@...>
Cc: Diego Santa Cruz <Diego.SantaCruz@...>; Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
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@...> wrote:

Actually, I found the upstream patch I backported, which you're probably better off using (same diff though).

 

 

On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <aaron=assonance.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@...> 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@...> wrote:

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




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

 

 






Re: [ptest-runner][PATCH] util.c: remove the usage of pipe for parent/child communication

Randy MacLeod
 

On 2021-02-03 6:47 p.m., Yi Fan Yu wrote:
i didn't spend too much time getting the patch to look nice.
It is just a proposal because this seems to be the root cause of a seemingly ...
unrelated bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14170
On 2/3/21 6:44 PM, Yi Fan Yu wrote:
If the output of the testing script is very large,
the fwrite called by the parent in
wait_child would start blocking. That would slow down
the parent speed in clearing the pipe buffer.

This is an issue because the pipe is Non-Blocking.
so the child(ex: a bash script)
who was designed to output to what he thinks is a
is stdout, might error out due to EAGAIN (pipe full).

The proposed fix is to remove pipes and just let the child
write directly to stdout (same his parent)

This would mean that the parent no longer control the output
of the child.
Thanks Yi Fan.

I'll have to look at this more closely later this week but
sharing file descriptors between parent and child seems like
a poor design. I have two main ideas and a work-around to mention.

First the work-around that we discussed for the failing
test in glib-2.0 codegen, is to limit the output until we fix
ptest-runner. I think you said that's a one line change and
it would give us more time to fix ptest-runner should we need it.

To fix ptest-runner I believe that it should be able to
handle arbitrary input or at least a few MB of input from
the child. I'll need to read the code more carefully but can't we:
1. add some internal buffering so that we can drain the
pipe before checking for timeouts, etc.
2. We could run ptest-runner as a higher priority task
than the code under test so that the parent has more
time to drain the pipe.
Neither of these will fix the problem completely but together
these changes may prevent all but the most verbose tests from
failing due to a full pipe.

Since we don't often see this problem, we could hide the issue
in the ptest-runner script for glib using some command line
buffer executable that already exists (*) as a linux utility.

I've CCed Anibal since he designed and wrote ptest-runner.

All for now,
../Randy

*
A quick search turned up:

https://unix.stackexchange.com/questions/188175/completely-buffer-command-output-before-piping-to-another-command

$ sudo apt install moreutils
$ file `which sponge`
/usr/bin/sponge: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f72063a4a10044e902905de1a8c1640f611394f9, for GNU/Linux 3.2.0, stripped

but maybe there's a better alternative since we don't want to buffer
the full input of the pipe.

There's also mbuffer but I'll leave it to you to investigate.



Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
  utils.c | 53 ++++++++---------------------------------------------
  1 file changed, 8 insertions(+), 45 deletions(-)

diff --git a/utils.c b/utils.c
index a4e190e..5d62ced 100644
--- a/utils.c
+++ b/utils.c
@@ -274,12 +274,14 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
      argv[0] = run_ptest;
      argv[1] = NULL;
+    /* since it isn't use by the child, close(fd_stderr) ? */
+    close(fd_stderr);
+
      dup2(fd_stdout, STDOUT_FILENO);
      // XXX: Redirect stderr to stdout to avoid buffer ordering problems.
      dup2(fd_stdout, STDERR_FILENO);
-    /* since it isn't use by the child, close(fd_stderr) ? */
-    close(fd_stderr); /* try using to see if this fixes bash run-read. rwm todo */
+
      close_fds();
      execv(run_ptest, argv);
@@ -290,20 +292,13 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
  static inline int
  wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
  {
-    struct pollfd pfds[2];
      struct timespec sentinel;
      clockid_t clock = CLOCK_MONOTONIC;
      int looping = 1;
-    int r;
      int status = -1;
      int waitflags;
-    pfds[0].fd = fds[0];
-    pfds[0].events = POLLIN;
-    pfds[1].fd = fds[1];
-    pfds[1].events = POLLIN;
-
      if (clock_gettime(clock, &sentinel) == -1) {
          clock = CLOCK_REALTIME;
          clock_gettime(clock, &sentinel);
@@ -328,29 +323,10 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
          if (waitpid(pid, &status, waitflags) == pid)
              looping = 0;
-        r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
-        if (r > 0) {
-            char buf[WAIT_CHILD_BUF_MAX_SIZE];
-            ssize_t n;
-
-            if (pfds[0].revents != 0) {
-                while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
-                    fwrite(buf, (size_t)n, 1, fps[0]);
-            }
-
-            if (pfds[1].revents != 0) {
-                while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
-                    fflush(fps[0]);
-                    fwrite(buf, (size_t)n, 1, fps[1]);
-                    fflush(fps[1]);
-                }
-            }
-
-            clock_gettime(clock, &sentinel);
-        }
-    }
+        }
      fflush(fps[0]);
+
      return status;
  }
@@ -412,8 +388,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
      char stime[GET_STIME_BUF_SIZE];
      pid_t child;
-    int pipefd_stdout[2];
-    int pipefd_stderr[2];
      int timeouted;
      time_t sttime, entime;
      time_t duration;
@@ -428,14 +402,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
      do
      {
-        if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
-            break;
-
-        if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
-            close(pipefd_stdout[0]);
-            close(pipefd_stdout[1]);
-            break;
-        }
          fprintf(fp, "START: %s\n", progname);
          if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
              fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
@@ -474,11 +440,10 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
                      fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
                  }
-                run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
+                run_child(p->run_ptest, STDOUT_FILENO, STDERR_FILENO);
              } else {
                  int status;
-                int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
                  FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;
                  if (setpgid(child, pgid) == -1) {
@@ -489,7 +454,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
                  fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
                  fprintf(fp, "BEGIN: %s\n", ptest_dir);
-                status = wait_child(child, opts.timeout, fds, fps, &timeouted);
+                status = wait_child(child, opts.timeout, NULL, fps, &timeouted);
                  entime = time(NULL);
                  duration = entime - sttime;
@@ -510,8 +475,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
          PTEST_LIST_ITERATE_END
          fprintf(fp, "STOP: %s\n", progname);
-        close(pipefd_stdout[0]); close(pipefd_stdout[1]);
-        close(pipefd_stderr[0]); close(pipefd_stderr[1]);
      } while (0);
      if (rc == -1)


--
# Randy MacLeod
# Wind River Linux


Re: [ptest-runner][PATCH] util.c: remove the usage of pipe for parent/child communication

Yi Fan Yu
 

i didn't spend too much time getting the patch to look nice.
It is just a proposal because this seems to be the root cause of a seemingly ...
unrelated bug.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14170

On 2/3/21 6:44 PM, Yi Fan Yu wrote:
If the output of the testing script is very large,
the fwrite called by the parent in
wait_child would start blocking. That would slow down
the parent speed in clearing the pipe buffer.

This is an issue because the pipe is Non-Blocking.
so the child(ex: a bash script)
who was designed to output to what he thinks is a
is stdout, might error out due to EAGAIN (pipe full).

The proposed fix is to remove pipes and just let the child
write directly to stdout (same his parent)

This would mean that the parent no longer control the output
of the child.

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
utils.c | 53 ++++++++---------------------------------------------
1 file changed, 8 insertions(+), 45 deletions(-)

diff --git a/utils.c b/utils.c
index a4e190e..5d62ced 100644
--- a/utils.c
+++ b/utils.c
@@ -274,12 +274,14 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
argv[0] = run_ptest;
argv[1] = NULL;
+ /* since it isn't use by the child, close(fd_stderr) ? */
+ close(fd_stderr);
+
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
- /* since it isn't use by the child, close(fd_stderr) ? */
- close(fd_stderr); /* try using to see if this fixes bash run-read. rwm todo */
+
close_fds();
execv(run_ptest, argv);
@@ -290,20 +292,13 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
static inline int
wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
{
- struct pollfd pfds[2];
struct timespec sentinel;
clockid_t clock = CLOCK_MONOTONIC;
int looping = 1;
- int r;
int status = -1;
int waitflags;
- pfds[0].fd = fds[0];
- pfds[0].events = POLLIN;
- pfds[1].fd = fds[1];
- pfds[1].events = POLLIN;
-
if (clock_gettime(clock, &sentinel) == -1) {
clock = CLOCK_REALTIME;
clock_gettime(clock, &sentinel);
@@ -328,29 +323,10 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
if (waitpid(pid, &status, waitflags) == pid)
looping = 0;
- r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
- if (r > 0) {
- char buf[WAIT_CHILD_BUF_MAX_SIZE];
- ssize_t n;
-
- if (pfds[0].revents != 0) {
- while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, (size_t)n, 1, fps[0]);
- }
-
- if (pfds[1].revents != 0) {
- while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
- fflush(fps[0]);
- fwrite(buf, (size_t)n, 1, fps[1]);
- fflush(fps[1]);
- }
- }
-
- clock_gettime(clock, &sentinel);
- }
- }
+ }
fflush(fps[0]);
+
return status;
}
@@ -412,8 +388,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
char stime[GET_STIME_BUF_SIZE];
pid_t child;
- int pipefd_stdout[2];
- int pipefd_stderr[2];
int timeouted;
time_t sttime, entime;
time_t duration;
@@ -428,14 +402,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
do
{
- if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
- break;
-
- if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
- close(pipefd_stdout[0]);
- close(pipefd_stdout[1]);
- break;
- }
fprintf(fp, "START: %s\n", progname);
if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
@@ -474,11 +440,10 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
}
- run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
+ run_child(p->run_ptest, STDOUT_FILENO, STDERR_FILENO);
} else {
int status;
- int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;
if (setpgid(child, pgid) == -1) {
@@ -489,7 +454,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);
- status = wait_child(child, opts.timeout, fds, fps, &timeouted);
+ status = wait_child(child, opts.timeout, NULL, fps, &timeouted);
entime = time(NULL);
duration = entime - sttime;
@@ -510,8 +475,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
PTEST_LIST_ITERATE_END
fprintf(fp, "STOP: %s\n", progname);
- close(pipefd_stdout[0]); close(pipefd_stdout[1]);
- close(pipefd_stderr[0]); close(pipefd_stderr[1]);
} while (0);
if (rc == -1)


[ptest-runner][PATCH] util.c: remove the usage of pipe for parent/child communication

Yi Fan Yu
 

If the output of the testing script is very large,
the fwrite called by the parent in
wait_child would start blocking. That would slow down
the parent speed in clearing the pipe buffer.

This is an issue because the pipe is Non-Blocking.
so the child(ex: a bash script)
who was designed to output to what he thinks is a
is stdout, might error out due to EAGAIN (pipe full).

The proposed fix is to remove pipes and just let the child
write directly to stdout (same his parent)

This would mean that the parent no longer control the output
of the child.

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
utils.c | 53 ++++++++---------------------------------------------
1 file changed, 8 insertions(+), 45 deletions(-)

diff --git a/utils.c b/utils.c
index a4e190e..5d62ced 100644
--- a/utils.c
+++ b/utils.c
@@ -274,12 +274,14 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
argv[0] = run_ptest;
argv[1] = NULL;

+ /* since it isn't use by the child, close(fd_stderr) ? */
+ close(fd_stderr);
+
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);

- /* since it isn't use by the child, close(fd_stderr) ? */
- close(fd_stderr); /* try using to see if this fixes bash run-read. rwm todo */
+
close_fds();

execv(run_ptest, argv);
@@ -290,20 +292,13 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
static inline int
wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
{
- struct pollfd pfds[2];
struct timespec sentinel;
clockid_t clock = CLOCK_MONOTONIC;
int looping = 1;
- int r;

int status = -1;
int waitflags;

- pfds[0].fd = fds[0];
- pfds[0].events = POLLIN;
- pfds[1].fd = fds[1];
- pfds[1].events = POLLIN;
-
if (clock_gettime(clock, &sentinel) == -1) {
clock = CLOCK_REALTIME;
clock_gettime(clock, &sentinel);
@@ -328,29 +323,10 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
if (waitpid(pid, &status, waitflags) == pid)
looping = 0;

- r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
- if (r > 0) {
- char buf[WAIT_CHILD_BUF_MAX_SIZE];
- ssize_t n;
-
- if (pfds[0].revents != 0) {
- while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, (size_t)n, 1, fps[0]);
- }
-
- if (pfds[1].revents != 0) {
- while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
- fflush(fps[0]);
- fwrite(buf, (size_t)n, 1, fps[1]);
- fflush(fps[1]);
- }
- }
-
- clock_gettime(clock, &sentinel);
- }
- }
+ }

fflush(fps[0]);
+
return status;
}

@@ -412,8 +388,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
char stime[GET_STIME_BUF_SIZE];

pid_t child;
- int pipefd_stdout[2];
- int pipefd_stderr[2];
int timeouted;
time_t sttime, entime;
time_t duration;
@@ -428,14 +402,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,

do
{
- if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
- break;
-
- if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
- close(pipefd_stdout[0]);
- close(pipefd_stdout[1]);
- break;
- }
fprintf(fp, "START: %s\n", progname);
if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
@@ -474,11 +440,10 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
}

- run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
+ run_child(p->run_ptest, STDOUT_FILENO, STDERR_FILENO);

} else {
int status;
- int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;

if (setpgid(child, pgid) == -1) {
@@ -489,7 +454,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);

- status = wait_child(child, opts.timeout, fds, fps, &timeouted);
+ status = wait_child(child, opts.timeout, NULL, fps, &timeouted);
entime = time(NULL);
duration = entime - sttime;

@@ -510,8 +475,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
PTEST_LIST_ITERATE_END
fprintf(fp, "STOP: %s\n", progname);

- close(pipefd_stdout[0]); close(pipefd_stdout[1]);
- close(pipefd_stderr[0]); close(pipefd_stderr[1]);
} while (0);

if (rc == -1)
--
2.25.1


Re: [meta-zephyr] bitbake zephyr-helloworld configure failure

Peter Smith <salerio@...>
 

Thx

On Tue, 2 Feb 2021 at 18:20, Khem Raj <raj.khem@...> wrote:
The mentioned patches are in master-next, please use it from there for
now until its applied to master which might be in couple of days.

On Tue, Feb 2, 2021 at 2:30 AM Ross Burton <ross@...> wrote:
>
> I sent a patch to meta-oe yesterday: there was a missing dependency in
> python3-kwalify and missing class extend in the ruamel recipe.
>
> Ross
>
> On Thu, 28 Jan 2021 at 05:49, Tim Orling <ticotimo@...> wrote:
> >
> >
> >
> > On Wed, Jan 27, 2021 at 12:51 AM Peter Smith <salerio@...> wrote:
> >>
> >> Using master branch
> >>
> >> MACHINE=96b_nitrogen bitbake zephyr-helloworld creates a configure error due to a failure for native python to import ruamel.
> >>
> >> I fixed this temporarily by creating a python3-ruamel-yaml_%.bbappend that includes the required BBEXTEND and adding python3-ruamel-yaml-native to zephyr-kernel-common.inc.
> >>
> >> I don't know (not enough experience) if this is actually a problem in the meta-openembedded recipe or meta-zephyr?
> >
> >
> >
> > BBEXTEND = “native” is a perfectly fine patch to submit to meta-python. We tend to only make those changes when needed (as in your use case) rather than universally. Please submit a patch :)
> >>
> >>
> >> Best Regards
> >> Peter
> >>
> >>
> >>
> >
> >
> >
>
>
>
--
Best Regards
Peter


Re: [meta-rockchip] Question about OVERRIDES in meta-rockchip

Markus Volk
 

Learned something new today :)

It could be done in local.conf like this:

OVERRIDES .= "${@bb.utils.contains_any('SOC_FAMILY', 'rk3066 rk3188 rk3288 rk3399', ':rockchip', '', d)}"
DISTRO_FEATURES_remove_rockchip = 


Re: 2038 time problem fix in yocto #kernel #linux #yocto #zeus

Robert Berger
 

Hi,

On 03/02/2021 09:13, dhandhukiya.paresh@gmail.com wrote:
Hi,
We need to have a fix for 2038 problem for out 32 bit based product which is running Yocto (Linux).
2038 time problem was fixed in Linux kernel recently https://www.theregister.com/2020/10/19/linux_5_10_y2k38_fixes/
How about switching to a more recent version of the YP then zeus?

A recent version uses the 5.10.x kernel.

... but it does not automatically fix everything.

Regards,

Robert


2038 time problem fix in yocto #kernel #linux #yocto #zeus

dhandhukiya.paresh@...
 

Hi,

We need to have a fix for 2038 problem for out 32 bit based product which is running Yocto (Linux).
2038 time problem was fixed in Linux kernel recently https://www.theregister.com/2020/10/19/linux_5_10_y2k38_fixes/

This issue is fixed and kernel and glibc, these version of kernel is not part of the yocto yet.
Does anyone know the timeline for this?

Also, There are other packages also affected by 2038 time problem in Linux.
Is there any timeline to fix these issues in other packages.
Its understandable that yocto project include these packages when new version of the package comes and doesnt maintain it.
But is there any central monitoring in yocto community about fixing this issue throughout yocto ?
Can any one please help me with above detail?

Thanks,
Paresh Dhandhukiya


[meta-rockchip] Question about OVERRIDES in meta-rockchip

Markus Volk
 

I'm building an image for rock-pi-4c using meta-rockchip layer and need to remove a DISTRO_FEATURE in local.conf. That would be needed for all rockchip based boards, but i only found overrides based on soc_family. I ended up adding a line for every soc_family:

DISTRO_FEATURES_remove_rk3066 =
DISTRO_FEATURES_remove_rk3188 =
DISTRO_FEATURES_remove_rk3288 =
DISTRO_FEATURES_remove_rk3399 =

So my question is: Is there any better way to achieve this or would it be thinkable to add an override for the complete rockchip family (maybe in rockchip-defaults.inc) like this?

MACHINEOVERRIDES .= ":rockchip"

Kind regards,
Markus Volk

2621 - 2640 of 54812