Date   

Re: Device is unable to BOOT or INSTALL with generated .hddimg

Josef Holzmayr <holzmayr@...>
 

As the question was almost simultaneously cross-posted on stackoverflow,
see answer there:

https://stackoverflow.com/questions/58947276/device-is-unable-to-boot-or-install-with-generated-hddimg/58948913#58948913

Greetz

On Wed, Nov 20, 2019 at 06:40:35AM +0000, Oriya, Raxesh wrote:
All,

I have device which has following configuration:

- Chipset architecture - `Intel NM10 express`
- Processor - `Atom D2550 Dual Core`
- Display - `DVI`
- Volatile Memory - `2GB DDR3`
- Storage - `16GB`

**Objective**: Device should run yocto embededded OS successfully

What I have done,

- Downloaded three required yocto layers for warrior branch i.e. 1. poky 2. meta-openembedded 3. meta-intel
- Modified `local.conf` with `MACHINE ??= "intel-core2-32"`
- Ran `source poky/oe-init-build-env`
- Generated `.hddimg` by bitbake `core-image-minimal`
- Flashed `.hddimg` to thumb drive through `dd` command

Attached thumb drive to device and I could see BOOT and INSTALL option, upon clicking any of them nothing happens(not even logs) i.e. Blank screen

Troubleshooting I tried out are,

1. Tried to boot `lubuntu` and it was successful
2. Replaced kernel & initrd of `lubuntu` with yocto's one and booting was successful which indicates there is no issue with kernel or initrd in `.hddimg` generated by yocto
3. Tried some experiment with `syslinux` as well but didn't work out

Regards,
Raxesh
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Device is unable to BOOT or INSTALL with generated .hddimg

raxeshkumar.oriya@ncr.com
 

All,

 

I have device which has following configuration:

 

- Chipset architecture - `Intel NM10 express`

- Processor - `Atom D2550 Dual Core`

- Display - `DVI`

- Volatile Memory - `2GB DDR3`

- Storage - `16GB`

 

**Objective**: Device should run yocto embededded OS successfully

 

What I have done,

 

- Downloaded three required yocto layers for warrior branch i.e. 1. poky 2. meta-openembedded 3. meta-intel

- Modified `local.conf` with `MACHINE ??= "intel-core2-32"`

- Ran `source poky/oe-init-build-env`

- Generated `.hddimg` by bitbake `core-image-minimal`

- Flashed `.hddimg` to thumb drive through `dd` command

 

Attached thumb drive to device and I could see BOOT and INSTALL option, upon clicking any of them nothing happens(not even logs) i.e. Blank screen

 

Troubleshooting I tried out are,

 

1. Tried to boot `lubuntu` and it was successful

2. Replaced kernel & initrd of `lubuntu` with yocto's one and booting was successful which indicates there is no issue with kernel or initrd in `.hddimg` generated by yocto

3. Tried some experiment with `syslinux` as well but didn't work out

 

Regards,

Raxesh

 


Device is unable to BOOT or INSTALL with generated .hddimg

raxeshkumar.oriya@ncr.com
 

All,

 

I have device which has following configuration:

 

- Chipset architecture - `Intel NM10 express`

- Processor - `Atom D2550 Dual Core`

- Display - `DVI`

- Volatile Memory - `2GB DDR3`

- Storage - `16GB`

 

**Objective**: Device should run yocto embededded OS successfully

 

What I have done,

 

- Downloaded three required yocto layers for warrior branch i.e. 1. poky 2. meta-openembedded 3. meta-intel

- Modified `local.conf` with `MACHINE ??= "intel-core2-32"`

- Ran `source poky/oe-init-build-env`

- Generated `.hddimg` by bitbake `core-image-minimal`

- Flashed `.hddimg` to thumb drive through `dd` command

 

Attached thumb drive to device and I could see BOOT and INSTALL option, upon clicking any of them nothing happens(not even logs) i.e. Blank screen

 

Troubleshooting I tried out are,

 

1. Tried to boot `lubuntu` and it was successful

2. Replaced kernel & initrd of `lubuntu` with yocto's one and booting was successful which indicates there is no issue with kernel or initrd in `.hddimg` generated by yocto

3. Tried some experiment with `syslinux` as well but didn't work out

 

Regards,

Raxesh


Re: Install native recipe into filesystem

Randy MacLeod
 

On 11/19/19 4:15 PM, Jeff Kaisner wrote:
We have several executables that can run on the target (ARM64) but also on the host system (x86).  I added the BBCLASSEXTEND = "native" and can build all the recipes in native mode.
What do you mean here by 'in native mode'? I'd expect that you mean:
$ bitbake somepackage-native
Right?

A few explanations related to your question are here:

https://wiki.yoctoproject.org/wiki/Technical_FAQ#What_does_.22native.22_mean.3F
and here:

https://wiki.yoctoproject.org/wiki/Technical_FAQ#Why_are_all_of_these_-native_items_being_built_when_my_host_distro_has_some_of_these_available.3F


Once done, I would like to be
able to install them on the host system, but don’t see a package for
them (or understand that part of the process).
You don't add -native package to the target system; they are for the
build (host) system to help build object files for the target machine.

You can either edit the conf/local.conf file then build a standard image
or define your own image. For the former:

https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image


Additional details are in the YP Mega Manual:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html

Good luck and welcome to the Yocto Project,

../Randy

Any help would be appreciated.
Regards,
Jeff

--
# Randy MacLeod
# Wind River Linux


Install native recipe into filesystem

Jeff Kaisner
 

We have several executables that can run on the target (ARM64) but also on the host system (x86).  I added the BBCLASSEXTEND = "native" and can build all the recipes in native mode.  Once done, I would like to be able to install them on the host system, but don’t see a package for them (or understand that part of the process).

 

Any help would be appreciated.

 

Regards,

Jeff


Zeus Call for patches

Armin Kuster
 

Hello,

We are planning on doing the first dot release for Zeus this coming
Monday. If you would like a get your changes into this Zeus update,
please have them on the list by this Friday for review.

regards,
Armin & Anuj


[warrior] [meta-qt4] recipes-qt4: qt4-embedded: fix build on GCC v8

Quentin Schulz
 

At least since gcc v8, source code with asm volatile won't compile
anymore.

The volatile qualifier anyway is a no-op since asm blocks are implicitly
volatile as written in the documentation[1].

Let's get rid of this redundant qualifier so we can build with newer
GCCs.

The resulting error message when building for warrior is the following
(note that there is a bunch of them):
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error: expected '(' before 'volatile'
asm volatile (
^~~~~~~~
(
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error: expected unqualified-id before string constant
".text\n"
^~~~~~~~~
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error: expected ')' before string constant
asm volatile (
~^
)
".text\n"
~~~~~~~~~

[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm

Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
---

Please ignore previous mail, I only sent a patch for the sources of qt4-embedded
and not a patch for meta-qt4.

...iptcore-JITStubs.cpp-allow-builds-of.patch | 262 ++++++++++++++++++
recipes-qt4/qt4/qt4-embedded.inc | 1 +
2 files changed, 263 insertions(+)
create mode 100644 recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch

diff --git a/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch b/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
new file mode 100644
index 0000000..12f955f
--- /dev/null
+++ b/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
@@ -0,0 +1,262 @@
+From 6318ac5a0771fdf074bdfb929903c660fa1fa672 Mon Sep 17 00:00:00 2001
+From: Quentin Schulz <quentin.schulz@streamunlimited.com>
+Date: Fri, 15 Nov 2019 13:57:12 +0100
+Subject: [PATCH] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of
+ JavaScriptCore with gcc v8
+
+At least since gcc v8, source code with asm volatile won't compile
+anymore.
+
+The volatile qualifier anyway is a no-op since asm blocks are implicitly
+volatile as written in the documentation[1].
+
+Let's get rid of this redundant qualifier so we can build with newer
+GCCs.
+
+The resulting error message is the following (note that there is a
+bunch of them):
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error: expected '(' before 'volatile'
+asm volatile (
+ ^~~~~~~~
+ (
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error: expected unqualified-id before string constant
+".text\n"
+^~~~~~~~~
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error: expected ')' before string constant
+asm volatile (
+ ~^
+ )
+".text\n"
+~~~~~~~~~
+
+[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
+
+Upstream-Status: Inappropriate
+Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
+---
+ .../JavaScriptCore/jit/JITStubs.cpp | 48 +++++++++----------
+ 1 file changed, 24 insertions(+), 24 deletions(-)
+
+diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+index d8027ff2..dcead6d0 100644
+--- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
++++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+@@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_s
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".text\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+@@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+ HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
+ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+@@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_s
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+@@ -206,7 +206,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -222,7 +222,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+ HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
+ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+@@ -242,7 +242,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+ #error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
+ #endif
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+@@ -269,7 +269,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "bx lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+@@ -287,7 +287,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "bx lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+@@ -305,7 +305,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+
+ #elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+@@ -323,7 +323,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "mov pc, lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -418,7 +418,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x38, JITStackFrame_
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x30, JITStackFrame_code_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x1c, JITStackFrame_stub_argument_space_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".text\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+@@ -440,7 +440,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -456,7 +456,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+ HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
+ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+@@ -480,7 +480,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x48, JITStackFrame_code_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x78, JITStackFrame_stub_argument_space_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".text\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+@@ -515,7 +515,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -531,7 +531,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+ HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
+ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+@@ -551,7 +551,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+ #error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
+ #endif
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+@@ -578,7 +578,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "bx lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+@@ -596,7 +596,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "bx lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".text" "\n"
+ ".align 2" "\n"
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+@@ -614,7 +614,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+
+ #elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)
+
+-asm volatile (
++asm (
+ ".text\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+@@ -632,7 +632,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "mov pc, lr" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -1024,7 +1024,7 @@ static NEVER_INLINE void throwStackOverflowError(CallFrame* callFrame, JSGlobalD
+ extern "C" { \
+ rtype JITStubThunked_##op(STUB_ARGS_DECLARATION); \
+ }; \
+- asm volatile ( \
++ asm ( \
+ ".text" "\n" \
+ ".align 2" "\n" \
+ ".globl " SYMBOL_STRING(cti_##op) "\n" \
+@@ -1053,7 +1053,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, thunkReturnAddress) == THUNK_RETUR
+ extern "C" { \
+ rtype JITStubThunked_##op(STUB_ARGS_DECLARATION); \
+ }; \
+- asm volatile ( \
++ asm ( \
+ ".globl " SYMBOL_STRING(cti_##op) "\n" \
+ HIDE_SYMBOL(cti_##op) "\n" \
+ SYMBOL_STRING(cti_##op) ":" "\n" \
+--
+2.17.1
+
diff --git a/recipes-qt4/qt4/qt4-embedded.inc b/recipes-qt4/qt4/qt4-embedded.inc
index 9c2d9da..5d4a9b0 100644
--- a/recipes-qt4/qt4/qt4-embedded.inc
+++ b/recipes-qt4/qt4/qt4-embedded.inc
@@ -12,6 +12,7 @@ QT_BASE_LIB ?= "libqt-embedded"
# Set necessary variables in the profile
SRC_URI += "file://qte.sh \
file://0033-configure-support-c-0x-standard-for-directfd.patch \
+ file://0001-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch \
"

QT_EMBEDDED_FLAGS ?= " \
--
2.17.1


Installing a Kernel module.

Shravan Singh <shravan@...>
 

Hello All,

So I am having a little problem in understanding why I am unable to autoload a module in my image.

So I made modifications to
1. KCONFIG, MAKEFILE
2. Added a source and header file to driver/input/touchscreen
3. Added a file in /boot/arm/dts/overlays
4. Created a patch and added that patch in /meta-raspberrypi-warrior/recipes/kernel/linux/linux-raspberrypi_4.19.bb
5. Added the overlay file in rpi_base.inc
6. In my local.conf added it under KERNEL_MODULE_AUTOLOAD_append

created the image without any issues. But after I install that Image I do not see the module anymore?

Why Is that Am I missing something?


Regards,
Shravan Singh
(239) 243-0838

Blue Sparq, Inc.
928 NE 24th Lane unit 4 and 5.
Cape Coral, FL 33993

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.


Yocto Project Status WW47'19

Stephen Jolley
 

Current Dev Position: YP 3.1 M1 

Next Deadline: YP 3.1 M1 build Dec. 2, 2019

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 2.7.2 is under review by the TSC and likely to be released.
  • Tests were made on making reproducibility the default for poky. There were several issues found for which bugs were filed:
    • A double free issue in opkg (Alejandro looking into, thanks)
    • devtool failures (Paul sent a fix, thanks)
    • recipetool failures (Richard sent a fix)
  • Tests were made on making the hashserver default for poky. There were also several issues found and RP is trying to understand and work through those. At least one critical issue has been identified and due to be tested.
  • The SWAT team no longer has enough people on it to make it sustainable and has therefore been disbanded. This means build owners need to triage their own build failures. Richard will be responsible for failures in the scheduled master builds.
  • Intermittent build failures continue to hamper builds, particularly combined with the above issues and as few people are available to attempt to debug and resolve them.
  • The TSC is working on LTS plans, productive discussions have been had and a new policy on handling this and stable releases should be available in the next couple of weeks.
  • We are continuing to collect ideas for YP 3.1 in this document: https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjnABc/edit?usp=sharing
  • If anyone has any status items for the project they’d like to add to the weekly reports, please email Richard and Stephen.

 

Proposed YP 3.1 Milestone Dates:

  • YP 3.1 M1 Proposed build date 12/2/2019
  • YP 3.1 M1 Proposed release date 12/13/2019
  • YP 3.1 M2 Proposed build date 1/20/2020
  • YP 3.1 M2 Proposed release date 1/31/2020
  • YP 3.1 M3 Proposed build date 2/24/2020
  • YP 3.1 M3 Proposed release date 3/6/2020
  • YP 3.1 M4 Proposed build date  3/30/2020
  • YP 3.1 M4 Proposed release date  4/24/2020

 

Planned upcoming dot releases:

  • YP 2.7.2 Should release this week.
  • YP 3.0.1 Proposed build date  11/25/2019
  • YP 3.0.1 Proposed release date 12/06/2019
  • YP 2.7.3 Proposed build date  2/10/20
  • YP 2.7.3 Proposed release date 2/21/20
  • YP 3.0.2 Proposed build date  2/3/20
  • YP 3.0.2 Proposed release date 2/14/20

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


[meta-qt4] [BUG] qt4-embedded broken on warrior for qemux86-64

Quentin Schulz
 

Hi all,

Just to let you know that qt4-embedded on qemux86-64 in warrior is
broken with the following message during the do_compile task:

| make[1]: Leaving directory '/tmp/poky/build/workspace/sources/qt4-embedded/tools'
| cd translations/ && make -e -f Makefile
| make[1]: Entering directory '/tmp/poky/build/workspace/sources/qt4-embedded/translations'
| lrelease assistant_cs.ts
| /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found
| lrelease assistant_da.ts
| /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found
| Makefile:582: recipe for target 'assistant_cs.qm' failed
| make[1]: *** [assistant_cs.qm] Error 127
| make[1]: *** Waiting for unfinished jobs....
| Makefile:585: recipe for target 'assistant_da.qm' failed
| make[1]: *** [assistant_da.qm] Error 127
| lrelease assistant_de.ts
| /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found
| Makefile:588: recipe for target 'assistant_de.qm' failed
| make[1]: *** [assistant_de.qm] Error 127
| make[1]: Leaving directory '/tmp/poky/build/workspace/sources/qt4-embedded/translations'
| Makefile:892: recipe for target 'sub-translations-make_default-ordered' failed
| make: *** [sub-translations-make_default-ordered] Error 2

meta-qt4: 144ae1b3892ad38d212c69186e429c874357af4a
poky: d0f73121551dc98f6924cd77952bf9ebf5ef3dd7

Building on Ubuntu 18.04.3. Only those two layers, source
oe-init-buil-denv and change MACHINE to qemux86-64 in conf/local.conf.

I doubt it has any impact but I also have INHERIT += "rm_work" in
conf/local.conf.

usr/bin/lrelease4 is in recipe-sysroot-native for other machines and it
is provided by qt4-native.

There is no qt4-native WORKDIR available in BUILDDIR for qemux86-64
AFAICT.

This is kind of a bug report, I am not working with this machine or
any x86-64 machine.
I was just trying to see if basic different architectures for another
bug (asm volatile, patch sent earlier today) were impacted and would
build with the fix I was working on.

Thanks for maintaining meta-qt4, much appreciated that we still can use
it with warrior.

Best regards,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


[warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8

Quentin Schulz
 

At least since gcc v8, source code with asm volatile won't compile
anymore.

The volatile qualifier anyway is a no-op since asm blocks are implicitly
volatile as written in the documentation[1].

Let's get rid of this redundant qualifier so we can build with newer
GCCs.

The resulting error message is the following (note that there is a
bunch of them):
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error: expected '(' before 'volatile'
asm volatile (
^~~~~~~~
(
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error: expected unqualified-id before string constant
".text\n"
^~~~~~~~~
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error: expected ')' before string constant
asm volatile (
~^
)
".text\n"
~~~~~~~~~

[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm

Upstream-Status: Inappropriate
Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
---
.../JavaScriptCore/jit/JITStubs.cpp | 48 +++++++++----------
1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
index d8027ff2..dcead6d0 100644
--- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
@@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_s
COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline);

-asm volatile (
+asm (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
@@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_s
COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
SYMBOL_STRING(ctiTrampoline) ":" "\n"
@@ -206,7 +206,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -222,7 +222,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -242,7 +242,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
#error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
#endif

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
@@ -269,7 +269,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"bx lr" "\n"
);

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
@@ -287,7 +287,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"bx lr" "\n"
);

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
@@ -305,7 +305,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"

#elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
SYMBOL_STRING(ctiTrampoline) ":" "\n"
@@ -323,7 +323,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"mov pc, lr" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -418,7 +418,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x38, JITStackFrame_
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x30, JITStackFrame_code_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x1c, JITStackFrame_stub_argument_space_matches_ctiTrampoline);

-asm volatile (
+asm (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
@@ -440,7 +440,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -456,7 +456,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -480,7 +480,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x48, JITStackFrame_code_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x78, JITStackFrame_stub_argument_space_matches_ctiTrampoline);

-asm volatile (
+asm (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
@@ -515,7 +515,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -531,7 +531,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -551,7 +551,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
#error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
#endif

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
@@ -578,7 +578,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"bx lr" "\n"
);

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
@@ -596,7 +596,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"bx lr" "\n"
);

-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
@@ -614,7 +614,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"

#elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)

-asm volatile (
+asm (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
@@ -632,7 +632,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"mov pc, lr" "\n"
);

-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -1024,7 +1024,7 @@ static NEVER_INLINE void throwStackOverflowError(CallFrame* callFrame, JSGlobalD
extern "C" { \
rtype JITStubThunked_##op(STUB_ARGS_DECLARATION); \
}; \
- asm volatile ( \
+ asm ( \
".text" "\n" \
".align 2" "\n" \
".globl " SYMBOL_STRING(cti_##op) "\n" \
@@ -1053,7 +1053,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, thunkReturnAddress) == THUNK_RETUR
extern "C" { \
rtype JITStubThunked_##op(STUB_ARGS_DECLARATION); \
}; \
- asm volatile ( \
+ asm ( \
".globl " SYMBOL_STRING(cti_##op) "\n" \
HIDE_SYMBOL(cti_##op) "\n" \
SYMBOL_STRING(cti_##op) ":" "\n" \
--
2.17.1


Memory Tests in U-Boot

devendra.devadiga@...
 

Hi,

In U-Boot I found some generic memory tests commands like mtest and post tests. But I need complete DDR4 memory test with below algorithms:

* Checkerboard Test
* March C- Test
* Neighborhood Pattern Sensitive Fault

Can I get any reference code for these algorithms in U-Boot ?
Implementation for these algorithms available in any of U-Boot version ?

Thanks and Regards,
Devendra


Re: patches to upgrade meta-jupyter layer packages

Maciej Pijanowski
 

On 19.11.2019 01:15, Chandana Kalluri wrote:
Hello all,

I have upgraded python packages from meta-jupyter layer to work with the zeus branch.
I am planning to send out the patches to this yocto project mailing list yocto@yoctoproject.org Please let me know if this is alright or if I need to send them to a different mailing list.
May be a good idea to add maintainers on CC:
https://github.com/Xilinx/meta-jupyter#maintainers-patchessubmissions-community

Thanks,
Chandana
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: F1401D2E1CCB19EF
https://3mdeb.com | @3mdeb_com


Re: patches to upgrade meta-jupyter layer packages

Khem Raj
 

On Mon, Nov 18, 2019 at 4:30 PM Chandana Kalluri <ckalluri@xilinx.com> wrote:


-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, November 18, 2019 4:21 PM
To: Chandana Kalluri <ckalluri@xilinx.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] patches to upgrade meta-jupyter layer packages

On Mon, Nov 18, 2019 at 4:17 PM Chandana Kalluri <ckalluri@xilinx.com>
wrote:

Hello all,

I have upgraded python packages from meta-jupyter layer to work with the
zeus branch.
I am planning to send out the patches to this yocto project mailing list
yocto@yoctoproject.org Please let me know if this is alright or if I need to
send them to a different mailing list.

have you upgraded the recipes in meta-jupyter ? if so then it should be
reviewed as per that layers policy, if you are looking for migrating the recipes
from above layer into other layers which use yocto ml for patch submission
then its ok
[CKalluri] Ive upgraded recipes in meta-jupyter layer. There is no mailing list specific to meta-jupyter layer hence the question where to send the patches for upgrade.
perhaps you should contact the manitainers, and if its on github then
github pull requests are usually accepted but
its better to find out. Its good to look at README files e.g.

https://github.com/Xilinx/meta-jupyter/blob/master/README.md

Lists that it accepts github pulls


Thanks,
Chandana

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: patches to upgrade meta-jupyter layer packages

Chandana kalluri
 

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, November 18, 2019 4:21 PM
To: Chandana Kalluri <ckalluri@xilinx.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] patches to upgrade meta-jupyter layer packages

On Mon, Nov 18, 2019 at 4:17 PM Chandana Kalluri <ckalluri@xilinx.com>
wrote:

Hello all,

I have upgraded python packages from meta-jupyter layer to work with the
zeus branch.
I am planning to send out the patches to this yocto project mailing list
yocto@yoctoproject.org Please let me know if this is alright or if I need to
send them to a different mailing list.

have you upgraded the recipes in meta-jupyter ? if so then it should be
reviewed as per that layers policy, if you are looking for migrating the recipes
from above layer into other layers which use yocto ml for patch submission
then its ok
[CKalluri] Ive upgraded recipes in meta-jupyter layer. There is no mailing list specific to meta-jupyter layer hence the question where to send the patches for upgrade.

Thanks,
Chandana

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: patches to upgrade meta-jupyter layer packages

Khem Raj
 

On Mon, Nov 18, 2019 at 4:17 PM Chandana Kalluri <ckalluri@xilinx.com> wrote:

Hello all,

I have upgraded python packages from meta-jupyter layer to work with the zeus branch.
I am planning to send out the patches to this yocto project mailing list yocto@yoctoproject.org Please let me know if this is alright or if I need to send them to a different mailing list.
have you upgraded the recipes in meta-jupyter ? if so then it should
be reviewed as per that layers policy, if you are looking
for migrating the recipes from above layer into other layers which use
yocto ml for patch submission then its ok


Thanks,
Chandana

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [qemu] can't find qemu-native recipe

Khem Raj
 

On Mon, Nov 18, 2019 at 4:10 PM Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:

Hi Khem,

I found the BBCLASSEXTEND in the qemu.inc file, I also found a line in the .bb file:

SRC_URI_append_class-native = " \


so I changed my SRC_URI to that and I stopped getting the 'can't find file to patch' error, but the file (syscall.c) is not modified.


Here is my qemu_3.0.0.bbappend file, meta-sakura/recipes-devtools/qemu/qemu_3.0.0.bbappend:

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URII_append_class-native = "file://syscall.c-add_missing_sockios_header_include.patch"
^^
If you pasted exactly what you have then there is a typo above it
should be SRC_URI_append_class-native ...

And here is the patch file .../qemu/syscall.c-add_missing_sockios_header_include.patch:
--- a/linux-user/syscall.c 2019-11-18 09:42:39.000000000 -0800
+++ b/linux-user/syscall.c 2019-11-18 09:23:23.000000000 -0800
@@ -34,6 +34,7 @@
#include <sys/resource.h>
#include <sys/swap.h>
#include <linux/capability.h>
+#include <linux/sockios.h>
#include <sched.h>
#include <sys/timex.h>
#include <sys/socket.h>

I am not getting the:

...tmp/work/x86_64-linux/qemu-native/3.0.0-r0/qemu-3.0.0/linux-user/syscall.c

modified.


I'm obviously missing something. Any help would be greatly appreciated.


Regards,

Greg


________________________________
From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, November 18, 2019 3:30:27 PM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] [qemu] can't find qemu-native recipe

On Mon, Nov 18, 2019 at 3:27 PM Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:

I'm building thud for the raspberry pi3 for boot2qt on Ubuntu 18.04.
I've got a patch that I need to apply to to fix an include file problem and I can't find the qemu-native recipe. I can find a number of recipes that depend in one way or another on 'qemu-native', but I can't find a recipe, class for it or anything that provides it. I can see it being built, and I get an error that indicates that the patch that I have needs to be applied. I can find tmp/work/x86_64-linux/qemu-native/.

In the cooker log I see:
task qemu_3.0.0
recipe qemu-native-3.0.0

But I can't find a qemu-native.bb file,or bbclass.

I'm rather confused at this point, can someone shed a bit of light on what I'm missing?
there must be BBCLASSEXTEND = "native" in qemu recipe which
essentially automatically extends the recipe for native case

see
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBCLASSEXTEND

Regards,
Greg Wilson-Lindberg

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [qemu] can't find qemu-native recipe

Greg Wilson-Lindberg
 

Hi Khem,

And just after I hit send I realized that I changed 'SRC_URI' to 'SRC_URII_append_class-native' with the 'II'. I deleted the 'II' and now the file is changed like it should be.

Thanks fo all of your help,

Greg Wilson-Lindberg 


From: Greg Wilson-Lindberg
Sent: Monday, November 18, 2019 04:10 PM
To: Khem Raj <raj.khem@gmail.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] [qemu] can't find qemu-native recipe

Hi Khem,
I found the BBCLASSEXTEND in the qemu.inc file, I also found a line in the .bb file:
SRC_URI_append_class-native = " \

so I changed my SRC_URI to that and I stopped getting the 'can't find file to patch' error, but the file (syscall.c) is not modified.

Here is my qemu_3.0.0.bbappend file, meta-sakura/recipes-devtools/qemu/qemu_3.0.0.bbappend:
FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URII_append_class-native = "file://syscall.c-add_missing_sockios_header_include.patch"

And here is the patch file .../qemu/syscall.c-add_missing_sockios_header_include.patch:
--- a/linux-user/syscall.c    2019-11-18 09:42:39.000000000 -0800
+++ b/linux-user/syscall.c    2019-11-18 09:23:23.000000000 -0800
@@ -34,6 +34,7 @@
 #include <sys/resource.h>
 #include <sys/swap.h>
 #include <linux/capability.h>
+#include <linux/sockios.h>
 #include <sched.h>
 #include <sys/timex.h>
 #include <sys/socket.h>
I am not getting the:
...tmp/work/x86_64-linux/qemu-native/3.0.0-r0/qemu-3.0.0/linux-user/syscall.c
modified.

I'm obviously missing something. Any help would be greatly appreciated.

Regards,
Greg

________________________________________
From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, November 18, 2019 3:30:27 PM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] [qemu] can't find qemu-native recipe
 
On Mon, Nov 18, 2019 at 3:27 PM Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:

I'm building thud for the raspberry pi3 for boot2qt on Ubuntu 18.04.
I've got a patch that I need to apply to to fix an include file problem and I can't find the qemu-native recipe. I can find a number of recipes that depend in one way or another on 'qemu-native', but I can't find a recipe, class for it or anything that provides it. I can see it being built, and I get an error that indicates that the patch that I have needs to be applied. I can find tmp/work/x86_64-linux/qemu-native/.

In the cooker log I see:
task qemu_3.0.0
recipe qemu-native-3.0.0

But I can't find a qemu-native.bb file,or bbclass.

I'm rather confused at this point, can someone shed a bit of light on what I'm missing?
there must be BBCLASSEXTEND = "native" in qemu recipe which
essentially automatically extends the recipe for native case

see
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBCLASSEXTEND

Regards,
Greg Wilson-Lindberg

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


patches to upgrade meta-jupyter layer packages

Chandana kalluri
 

Hello all,

I have upgraded python packages from meta-jupyter layer to work with the zeus branch.
I am planning to send out the patches to this yocto project mailing list yocto@yoctoproject.org Please let me know if this is alright or if I need to send them to a different mailing list.

Thanks,
Chandana


Re: [qemu] can't find qemu-native recipe

Greg Wilson-Lindberg
 

Hi Khem,

I found the BBCLASSEXTEND in the qemu.inc file, I also found a line in the .bb file:

SRC_URI_append_class-native = " \


so I changed my SRC_URI to that and I stopped getting the 'can't find file to patch' error, but the file (syscall.c) is not modified.


Here is my qemu_3.0.0.bbappend file, meta-sakura/recipes-devtools/qemu/qemu_3.0.0.bbappend:

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URII_append_class-native = "file://syscall.c-add_missing_sockios_header_include.patch"

And here is the patch file .../qemu/syscall.c-add_missing_sockios_header_include.patch:
--- a/linux-user/syscall.c    2019-11-18 09:42:39.000000000 -0800
+++ b/linux-user/syscall.c    2019-11-18 09:23:23.000000000 -0800
@@ -34,6 +34,7 @@
 #include <sys/resource.h>
 #include <sys/swap.h>
 #include <linux/capability.h>
+#include <linux/sockios.h>
 #include <sched.h>
 #include <sys/timex.h>
 #include <sys/socket.h>

I am not getting the:

...tmp/work/x86_64-linux/qemu-native/3.0.0-r0/qemu-3.0.0/linux-user/syscall.c

modified.


I'm obviously missing something. Any help would be greatly appreciated.


Regards,

Greg



From: Khem Raj <raj.khem@...>
Sent: Monday, November 18, 2019 3:30:27 PM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] [qemu] can't find qemu-native recipe
 
On Mon, Nov 18, 2019 at 3:27 PM Greg Wilson-Lindberg
<GWilson@...> wrote:
>
> I'm building thud for the raspberry pi3 for boot2qt on Ubuntu 18.04.
> I've got a patch that I need to apply to to fix an include file problem and I can't find the qemu-native recipe. I can find a number of recipes that depend in one way or another on 'qemu-native', but I can't find a recipe, class for it or anything that provides it. I can see it being built, and I get an error that indicates that the patch that I have needs to be applied. I can find tmp/work/x86_64-linux/qemu-native/.
>
> In the cooker log I see:
> task qemu_3.0.0
> recipe qemu-native-3.0.0
>
> But I can't find a qemu-native.bb file,or bbclass.
>
> I'm rather confused at this point, can someone shed a bit of light on what I'm missing?
>

there must be BBCLASSEXTEND = "native" in qemu recipe which
essentially automatically extends the recipe for native case

see
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBCLASSEXTEND

> Regards,
> Greg Wilson-Lindberg
>
> --
> _______________________________________________
> yocto mailing list
> yocto@...
> https://lists.yoctoproject.org/listinfo/yocto

6121 - 6140 of 53454