On Tue, 2021-02-23 at 01:01 -0800, Paul D. DeRocco wrote:

Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom
Ordinary USB 2.0 flash drive

I followed the instructions in the meta-intel README, and had no
problems
building the intel-core2-32 and intel-corei7-64 machines, as well as
the
latter with an x32 tune. But whenever I try to boot any of them, I
get the
following stuff from the kernel:

usb 1-6: new high-speed USB device number 4 using ehci-pci
usb-storage 1-6:1.0: USB Mass Storage device detected
usb-storage 1-6:1.0:  Quirks match for vid 090c pid 1000: 400
scsi host4: usb-storage 1-6:1.0
scsi 4:0:0:0: Direct-Access     FLASH    Drive SM_USB20   1100 PQ: 0
ANSI: 4
sd 4:0:0:0: Attached scsi generic sg0 type 0
sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB)
sd 4:0:0:0: [sda] Write Protect is off
sd 4:0:0:0: [sda] No Caching mode page found
sd 4:0:0:0: [sda] Assume drive cache: write through
 sda:
sd 4:0:0:0: [sda] Attached SCSI removable disk
(countdown from 27 to 0)
Mounted filesystems
Available block devices
major minor  #blocks  name
   1        0       4096 ram0
    ... (others edited out)
   1       15       4096 ram15
   8        0    1966080 sda
Cannot find rootfs.img file in /run/media/* , dropping to a shell

It looks like you are using the live option in hddimg image? Can you
try adding "rootwait" to kernel parameters and see if that works?

Not sure why it's not dropping to shell, but may be try adding explicit
call to /bin/sh in meta/recipes-core/initrdscripts/files/init-live.sh
before this point to make sure the media is actually mounted at that
point.

Also, have you tried wic image to see if that works?

Thanks,

Anuj

Hi,

On Tue, Feb 23, 2021 at 06:56:02AM -0800, Karthik Poduval wrote:

Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?

A kernel recipe will provide linux-libc-headers after a
"make headers_install" call...

So the SRC_URI of linux-libc-headers can be the same as from the
linux kernel recipe, or linux kernel recipe can provide (with some
tricks, possibly) the linux-libc-headers binary packages.

I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?

I guess the reason is to split userspace to BSP/board specific and common
parts. It's not good if whole userspace bootstrap depends on kernel
recipe and any kernel changes requires full bootstrap and recompilation
of all userspace.

But there are BSP/board specific recipes which do need the real effective
kernel headers to interface with kernel drivers, and there are SoC
architecture specific ones which just need enough to build gcc and glibc.

Both have their pross and cons, and to me there is no clear winner.

Cheers,

-Mikko

Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?
I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?

--
Regards,
Karthik Poduval

On Tue, Feb 23, 2021 at 09:24:47AM -0500, Claude Bing wrote:

I mentioned that we remove that directory, and it does indeed solve a
lot of problems. Not sure that it was clear from the original message,
but whenever we get a random error on the first build after the upgrade
we run a "bitbake -c cleanall" on that package, and everything works
great. The errors do not show up again.

Yes, we're talking about the same thing :)

A lot of yocto things don't work well if major changes happen and WORKDIR
isn't completely cleaned in between. With various BSP layers things
can be even worse and they may actively break both work directory and
sstate caches.

For any major changes in open source or other meta layers, I wipe build/tmp
completely to avoid random problems. In our CI this is the default.
Only download cache and sstate mirror are re-used between builds.
After this, I don't see many problems and build failures which are not
real bugs in either our changes or in upstream, e.g. race conditions
in build scripts.

Cheers,

-Mikko

On 2/23/21 7:58 AM, Mikko Rapeli wrote:

Hi,

On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote:

Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after
updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is
there an accepted process to merging in upstream changes? Here is a
distillation of our workflow:

* Yocto releases 3.1.0 / dunfell

* Create a local tracking branch for the Yocto release
"sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch.
This is necessary because some of our local tooling is located in the
top level directory and it is a pain to copy the files each time.

* Create firmware with Yocto

* Yocto releases 3.1.x

* Merge upstream yocto-3.1.x tag into local tracking branch

* Create firmware with Yocto

Sometimes, after this last step, we encounter problems where patches
cannot be applied, or files cannot be found when bitbake tries to build
the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we
merge upstream changes, but random errors still persist. For each of
these packages, if we run "bitbake -c cleanall", the error goes away.

When both yocto update and your own changes are modifying the same recipes,
then conflicts can occur.>

Most of the time, these recipes have not been extended in our project,
so they are purely meta-oe / meta packages.

If builds are failing, then your environment is breaking something.
It might even be the BSP layers that you use>

Are we doing something wrong, or is there a more acceptable way to
handle updates?

How tightly should meta-openembedded be tied to the core Yocto release?

I update all open source meta layers for every run of the update and also resolve
any issues by digging into details why the failure happened. I've done dunfell
updates with several BSP layers for multiple arm64 SoC's and have not seen
major issues.

What is useful and one of the best practices, is to clear the bitbake tmp
directory in between builds. Depending on details, there can be some cruft there
which fails when rebuilding.

I mentioned that we remove that directory, and it does indeed solve a
lot of problems. Not sure that it was clear from the original message,
but whenever we get a random error on the first build after the upgrade
we run a "bitbake -c cleanall" on that package, and everything works
great. The errors do not show up again.

Thanks for the reply.

Cheers,

-Mikko

Hi,

I know it's not the best or recommended approach, but I find it
hard to avoid merging linux-libc-headers recipe with the actual
kernel recipe that a distro is using. At least a static copy
of some version of uapi headers from that kernel can be used
instead of the poky side linux-libc-headers. This helps to get
the actual BSP SW delivery headers into userspace, SDK etc.

Cheers,

-Mikko

Hi,

On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote:

Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after
updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is
there an accepted process to merging in upstream changes? Here is a
distillation of our workflow:

* Yocto releases 3.1.0 / dunfell

* Create a local tracking branch for the Yocto release
"sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch.
This is necessary because some of our local tooling is located in the
top level directory and it is a pain to copy the files each time.

* Create firmware with Yocto

* Yocto releases 3.1.x

* Merge upstream yocto-3.1.x tag into local tracking branch

* Create firmware with Yocto

Sometimes, after this last step, we encounter problems where patches
cannot be applied, or files cannot be found when bitbake tries to build
the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we
merge upstream changes, but random errors still persist. For each of
these packages, if we run "bitbake -c cleanall", the error goes away.

When both yocto update and your own changes are modifying the same recipes,
then conflicts can occur.

Most of the time, these recipes have not been extended in our project,
so they are purely meta-oe / meta packages.

If builds are failing, then your environment is breaking something.
It might even be the BSP layers that you use.

Are we doing something wrong, or is there a more acceptable way to
handle updates?

How tightly should meta-openembedded be tied to the core Yocto release?

I update all open source meta layers for every run of the update and also resolve
any issues by digging into details why the failure happened. I've done dunfell
updates with several BSP layers for multiple arm64 SoC's and have not seen
major issues.

What is useful and one of the best practices, is to clear the bitbake tmp
directory in between builds. Depending on details, there can be some cruft there
which fails when rebuilding.

Cheers,

-Mikko

Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom
Ordinary USB 2.0 flash drive

I followed the instructions in the meta-intel README, and had no problems
building the intel-core2-32 and intel-corei7-64 machines, as well as the
latter with an x32 tune. But whenever I try to boot any of them, I get the
following stuff from the kernel:

usb 1-6: new high-speed USB device number 4 using ehci-pci
usb-storage 1-6:1.0: USB Mass Storage device detected
usb-storage 1-6:1.0: Quirks match for vid 090c pid 1000: 400
scsi host4: usb-storage 1-6:1.0
scsi 4:0:0:0: Direct-Access FLASH Drive SM_USB20 1100 PQ: 0 ANSI: 4
sd 4:0:0:0: Attached scsi generic sg0 type 0
sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB)
sd 4:0:0:0: [sda] Write Protect is off
sd 4:0:0:0: [sda] No Caching mode page found
sd 4:0:0:0: [sda] Assume drive cache: write through
sda:
sd 4:0:0:0: [sda] Attached SCSI removable disk
(countdown from 27 to 0)
Mounted filesystems
Available block devices
major minor #blocks name
1 0 4096 ram0
... (others edited out)
1 15 4096 ram15
8 0 1966080 sda
Cannot find rootfs.img file in /run/media/* , dropping to a shell

At this point, it doesn't drop to a shell, but just sits there, responding
to keys by echoing them, so I have no way of investigating. Ctrl-Alt-Del
reboots.

Since there is no kernel serial output on this board, even though the kernel
command requests it, I videoed the startup, but didn't anything that looked
suspicious. I didn't see any message, though, about mounting anything in
/run/media.

As I've said, I've tried three different builds, totally generic except for
using the Intel BSP layer. I've tried two different USB drives. I've tried
it with EFI enabled and disabled in the BIOS. I've looked at the drive on
the PC, and the contents look normal. So why can't it find the rootfs.img
file, which is right there on sda, large as life? Anyone have any ideas what
I could be doing wrong?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

Hi,

We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of our development team to develop Qt5-based application for our platform. I want to build an SDK installer that includes additional Qt5 components which aren't included in the default Ti SDK like QtConnectivity and QtVirtualKeyboard.


I've tried several methods to build the SDK including: 

• adding inherit populate_sdk populate_sdk_qt5 to my image recipe and running bitbake {image} -c populate_sdk
• creating a new image recipe for the SDK with IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug eclipse-debug debug-tweaks"
• building meta-toolchain-qt5

None of the resulting SDK installers appear to include the compiler, after sourcing the environment script I get the following:

I know that in the past I did manage to get a working SDK/Toolchain using one of the methods above though at the moment none seem to work for me.


Regards,
Evan

RP,

if you want to get this merged too that would be great.

yifan

mostly changed the way to access request.GET
also tested on python2.7 to be backward compatible

Signed-off-by: Yi Fan Yu <yifan.yu@...>
---
Post/parser.py | 2 +-
Post/views.py | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Post/parser.py b/Post/parser.py
index f54482a..f411e02 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -17,7 +17,7 @@ from django.core.urlresolvers import reverse
class Parser:

def __init__(self, data):
- self.data = data
+ self.data = data.decode('utf-8')

# returns true if the values contain '<' char
# Ignore the failures field (which is an array anyway)
diff --git a/Post/views.py b/Post/views.py
index cc6aed9..fe7100e 100644
--- a/Post/views.py
+++ b/Post/views.py
@@ -15,9 +15,9 @@ from django.shortcuts import HttpResponse, render
from django.views.decorators.csrf import csrf_exempt
from django.shortcuts import redirect
from Post.models import BuildFailure, Build, ErrorType
-from parser import Parser
+from Post.parser import Parser
from django.conf import settings
-from createStatistics import Statistics
+from Post.createStatistics import Statistics
from django.core.paginator import Paginator, EmptyPage
from django.core.exceptions import FieldError, ObjectDoesNotExist
from django.http import JsonResponse
@@ -65,12 +65,12 @@ def addData(request, return_json=False):
if return_json:
response = JsonResponse(result)
else:
- if not result.has_key('error'):
+ if not 'error' in result:
response = HttpResponse("Your entry can be found here: "+result['build_url'])
else:
response = HttpResponse(result['error'])

- if result.has_key('error'):
+ if 'error' in result:
response.status_code=500
else:
if return_json:
@@ -125,7 +125,7 @@ def search(request, mode=results_mode.LATEST, **kwargs):

items = BuildFailure.objects.all()

- if request.GET.has_key("limit"):
+ if "limit" in request.GET:
try:
n_limit = int(request.GET['limit'])
if n_limit > 0:
@@ -202,14 +202,14 @@ def search(request, mode=results_mode.LATEST, **kwargs):
],
}

- if request.GET.has_key("filter") and request.GET.has_key("type"):
+ if "filter" in request.GET and "type" in request.GET:
items = apply_filter(context, items, request.GET['type'], request.GET['filter'])
if mode == results_mode.SPECIAL_SUBMITTER and hasattr(settings,"SPECIAL_SUBMITTER"):
#Special submitter mode see settings.py to enable
name = settings.SPECIAL_SUBMITTER['name']
items = items.filter(BUILD__NAME__istartswith=name)

- elif mode == results_mode.SEARCH and request.GET.has_key("query"):
+ elif mode == results_mode.SEARCH and "query" in request.GET:
query = request.GET["query"]

items = items.filter(
--
2.25.1

Hi all,

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

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

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

ETA for completion is next Thursday, February 25.

Thanks,
Sangeeta

--

On Mon, Feb 22, 2021 at 7:52 PM Karthik Poduval
<karthik.poduval@...> wrote:

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include

That's coming from the linux-libc-headers, your new upi header is not
part of the libc-headers package, so it won't show up there. And no,
it shouldn't be part of that recipe and the libc-headers should not be
generated from the current state of whatever kernel is being built.

You need to arrange for it to be exported and staged separately (look
for examples of 'sysroot_stage' variants in the meta-data, you can
bbappend the behaviour to your kernel recipe), or your code can look
for the header in the kernel shared workdir (STAGING_KERNEL_BUILDDIR)
by adding that to your include paths in the recipe.

As khem also mentioned, you'll need to make sure that the uapi header
is not just patched in, but properly exported.

Bruce

and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?

--
Regards,
Karthik Poduval

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On Mon, Feb 22, 2021 at 4:52 PM Karthik Poduval
<karthik.poduval@...> wrote:

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include
and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?

What does patch look like? just adding the file is not enough, it
should be added to makefiles to be exported as UAPI header

--
Regards,
Karthik Poduval

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include
and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?

--
Regards,
Karthik Poduval

Signed-off-by: Michael Halstead <mhalstead@...>
---
scripts/send-qa-email | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index 6785df3..1b69307 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -145,6 +145,10 @@ Build hash information: \n

''' % (args.release, args.publish_dir.replace(web_root, web_url), buildhashes)

+# Store a copy of the email in case it doesn't reach the lists
+with open(os.path.join(args.publish_dir, "qa-email"), "wb") as qa_email:
+ qa_email.write(email.encode('utf-8'))
+
utils.printheader("Sending QA email")
env = os.environ.copy()
# Many distros have sendmail in */sbin
--
2.29.2

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.6.rc1


Build hash information:

bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd
meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63
poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7



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