[yocto] [meta-raspberrypi][PATCH 1/2] rpi-base.inc: add xserver-xorg-extension-glx to XSERVER for vc4 enabled
make glxinfo/glggears/.. work
Signed-off-by: Andreas Müller
---
conf/machine/include/rpi-base.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index 497dd29..9ce647d 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -9,6 +9,7 @@ IMAGE_FSTYPES ?= "tar.bz2 ext3 rpi-sdimg"
XSERVER = " \
xserver-xorg \
+${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xserver-xorg-extension-glx", "", d)} \
xf86-input-evdev \
xf86-input-mouse \
xf86-input-keyboard \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/2] rpi-base.inc: remove input modules form XSERVER
This is nothing a BSP has to decide
Signed-off-by: Andreas Müller
---
conf/machine/include/rpi-base.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index 9ce647d..9f20663 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -10,9 +10,6 @@ IMAGE_FSTYPES ?= "tar.bz2 ext3 rpi-sdimg"
XSERVER = " \
xserver-xorg \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xserver-xorg-extension-glx", "", d)} \
-xf86-input-evdev \
-xf86-input-mouse \
-xf86-input-keyboard \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xf86-video-modesetting", "xf86-video-fbdev", d)} \
"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2] ref-manual: New WKS_FILE variable glossary entry.
Signed-off-by: Ed Bartosh
---
documentation/ref-manual/ref-variables.xml | 14 ++
1 file changed, 14 insertions(+)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index 4e003cd..9c03364 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -15548,6 +15548,20 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
+WKS_FILE
+
+ WKS_FILE[doc] = "Specifies the name of the wic kickstart file."
+
+
+
+Specifies the location of the wic kickstart file that is
+used to create wic partitioned image
by the OpenEmbedded build system.
+For details on kickstart file format, see
+OpenEmbedded
Kickstart (.wks) Reference.
+
+
+
+
WORKDIR
WORKDIR[doc] = "The pathname of the working directory in which
the OpenEmbedded build system builds a recipe. This directory is located within
the TMPDIR directory structure and changes as different packages are built."
--
2.6.6
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config incremental modification not working.
On 2016-12-11 02:33 PM, Paul Eggleton wrote:
On Fri, 09 Dec 2016 11:19:56 Bruce Ashfield wrote:
On 2016-12-09 11:17 AM, Andrea Galbusera wrote:
Hi Bruce,
On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>>
wrote:
On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:
Hi list
I am working on a project based on the iMX6UL-EVK using the
meta-fsl-arm
layer for the kernel.
In a local layer I have a bbappend recipe containing a patch for
an
extra kernel feature (a framebuffer device) in that kernel as
well as a
.cfg enabling said feature.
The bbappend recipe is located in
recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like
this:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += " \
file://0001-mxc-4.1.patch \
file://ST7789S.cfg \
"
KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"
The .cfg is located in
recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
and looks like:
CONFIG_FB_MXS_ST7789S_QVGA=y
The 0001-mxc-4.1.patch patch is correctly applied but the .cfg
is either
ignored or overwritten by some later buyild step since the
resulting
.config after kernel compilation contains:
# CONFIG_FB_MXS_ST7789S_QVGA is not set
I have tried finding the script in the build/.../temp folder
that takes
care of the .cfg file patching but have not been able to find
anything
useful.
Any hints as to where I should start looking for a solution?
Fragment processing using the kernel tools + auditing is only
currently
available to kernel recipes that use the kernel-yocto bbclass. That
opt-in requirement was to ensure that existing recipes and workflows
weren't broken by the new features.
Last time I checked, the meta-fsl* kernel recipes don't use the
kernel-yocto bbclass, so the fragment would be ignored.
I'm taking the processing of fragments and making it universally
available in the upcoming 2.3 release, so what I just described
won't be an issue for much longer.
In the mean time, you have a few options:
- in your bbappend, add "inherit kernel-yocto" and the processing
of fragments will be enabled (I can't say that I've tested
it against that recipe .. but the entire point of the new tasks
is that they are transparent/don't break existing worflows)
- carry a defconfig in your layer, and add it to the SRC_URI. That
defconfig would be the existing kernel recipe's defconfig + your
options
I was just testing one of my layers against your recent patchset on
kernel-yocto when I noticed this thread. My build is broken by commit
476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d on oe-core
(e38775a1d82e6dc60fc96cf243ecb94be964d9b2 on the poky repo side).
WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: GIZERO: before 'cmp'
ERROR: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: Function failed: do_kernel_metadata (log file is
located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274) ERROR: Logfile of failure stored in:
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274>
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| WARNING: GIZERO: before 'cmp'
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/defconfig
/scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cyclone5/kernel
-source/arch/arm/configs/socfpga_defconfig differ: byte 1525, line 72
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_metadata (log file is located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274) ERROR: Task
(/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/li
nux/linux-altera-ltsi_4.1.22.bb:do_kernel_metadata) failed with exit code
'1'
The commit in the patch remove the 'set +e' bits, but the following
legit code path expects the cmp command to have a non-zero return value.
Aha. Indeed that is true. Clearly there aren't many people going
through that path.
Can we please have some automated tests covering all of this? Perhaps it would
be worth talking to Francisco Pedraza who is looking at adding tests under bug
6359:
We are already meeting to talk about this :D
Bruce
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6359
Cheers,
Paul
--
Re: [yocto] update mechanisms
>> I >> tried to summarize the key aspects of each mechanism in the table >> itself. That's something that I haven't seen elsewhere and something >> that the page can I tried to be as fair and objective as possible, >> please shout if I messed something up or you don't agree with my >> summary. >> >> In particular the "complexity" column is a bit subjective. Stefano, I >> hope you don't mind that I did not quite buy the "easy to use" >> characterization of swupdate ;-) > No worry...and I have not written myself. It was inserted by Mariano, so > it looks like that swupdate at least for Mariano is "easy to use". > I think it is correct to point out that customization is required. Compared to other update mechanism that I tested it was the easier to implement. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't enable reverse debugging
Khem, > -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Saturday, December 10, 2016 4:26 PM > To: Bryan Evenson > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Can't enable reverse debugging > > On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson > wrote: > > I tried a few other things, see below. > > > >> -Original Message- > >> From: yocto-boun...@yoctoproject.org [mailto:yocto- > >> boun...@yoctoproject.org] On Behalf Of Bryan Evenson > >> Sent: Thursday, December 08, 2016 2:50 PM > >> To: yocto@yoctoproject.org > >> Subject: [yocto] Can't enable reverse debugging > >> > >> I'm on poky/dizzy and I'm getting a segementation fault in my application > >> that I think may be related to a buffer overflow. I'm using the Eclipse > plug-in > >> (on Eclipse Kepler) to debug on the hardware with GDB. I'm trying to > enable > >> reverse debugging but I have not had any success and I'm looking for > some > >> help. > >> > >> My target processor is an SAM9G25 (ARM926EJ-S core). I have been able > to > >> debug through Eclipse on the target hardware without issue. I tried > enabling > >> Reverse Debugging by going to Window->Customize Perspective...- > >> >Command Groups Availability and selecting "Reverse Debugging". Now > >> there is a "Reverse Toggle" button on my toolbar, but it is always grayed > out > >> whether I have a debug session running or not. I have also tried entering > the > >> command "record" from the GDB console after my program breaks at > main. > >> When I run the program, I get the error message "Process record: failed > to > >> record execution log". > > > > I tried first running my application, pausing the debugger and then sending > the "record" command. When I continued debugging, I got the following > GDB error: > > > > x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/gdb- > 7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > > > I did some looking around and I couldn't see any reasonable answer to why > this would happen. I also just noticed that for the Debug Configurations > under Eclipse, the debugger settings tab doesn't have "Enable Reverse > Debugging at startup" option listed for the C/C++ Remote Application > debugging type. Is this option just not available to me with my environment? > > This could mean many things but one area I know is troublesome is > python support. Sometimes there are issues between > fundamental types, can you check if the error happens when gdb is > running some pythonic stuff. Could you explain how to do this? I don't use Python so I'm not sure if I'm doing a valid test. I tried to debug a Python script with GDB through Eclipse and I wasn't successful. I then went through the command line and was able to remotely run a simple Python script (print "Hello, Python" once per second) through GDB. If I issued a "record" command through GDB first, then when I tried to debug the Python script I'd immediately get a segmentation fault. Is there something specific you'd like me to try? If you think the Python support may be the issue, is there something I should be verifying is present or is at a certain version? Thanks, Bryan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
Hi, On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote: > On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote: > > Hi Patrick, > > > > On 30/11/2016 15:59, Patrick Ohly wrote: > > > I've started a Wiki page > > > https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the > > > moment, but might as well be mentioned already now. > > > > I have seen Mariano added an entry for SWUpdate, too, thanks - I would > > like to edit for better explanation on some parts. Should I try to edit > > directly the page or is it better to discuss it here ? > > Use your own judgment. If its uncontroversial, the feel free to edit the > page directly, otherwise let's discuss it here. > > If feel that putting information directly into the table is too limiting > (it should be brief), then feel free to start a complete section about > SWUpdate. > > I'll do the same for swupd. Editing the sections should be possible > without conflicts, we just have to be more careful about editing the > table concurrently. It looks as if some highlights about swupdate can equally be said about swupd: - dual copy is supported - my minimal swupd-based rescue initramfs is around 4MB Cheers, Andre' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] suggestions for version controlling multi-layer reproducible builds?
(if there's already a doc section for this somewhere, a pointer to it would be just ducky.) if one is building an image for a releasable, commercial product, and that image involves pulling in numerous layers, then dumping all sorts of proprietary apps on top of it, what are the possibilities for how to version number the released images such that, if a client has an issue, they can identify precisely the state of components that went into the system they're working with? in addition to all of the layers involved in the build, one has to take into account that, when critical bugs are identified, an updated RPM might be sent out and applied, whereupon that system's version number is no longer perfectly accurate. in the end, the state of someone's running system will be determined by a possibly huge combination of selected packages, preferred package versions, build config options, additional user space apps, hot fixes that have been applied and so on. what sort of meaningful "version number" can be applied to something like that? i'm sure at least a few other people have to be doing something like that, so i'm open to suggestions. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
On Mon, Dec 12, 2016 at 8:20 AM, Robert P. J. Day wrote: > if one is building an image for a releasable, commercial product, > and that image involves pulling in numerous layers, then dumping all > sorts of proprietary apps on top of it, what are the possibilities for > how to version number the released images such that, if a client has > an issue, they can identify precisely the state of components that > went into the system they're working with? > > in addition to all of the layers involved in the build, one has to > take into account that, when critical bugs are identified, an updated > RPM might be sent out and applied, whereupon that system's version > number is no longer perfectly accurate. in the end, the state of > someone's running system will be determined by a possibly huge > combination of selected packages, preferred package versions, build > config options, additional user space apps, hot fixes that have been > applied and so on. > > what sort of meaningful "version number" can be applied to something > like that? i'm sure at least a few other people have to be doing > something like that, so i'm open to suggestions. > I don’t think it’s possible for a version number to capture this at all. Better to use a script to capture the state of the system as needed. I.e. write build info to a file on target, and then combine that with a query of the package manager if you use packages for update distribution (though I wouldn’t advise use of packages for update distribution at all, that’s a different discussion :). -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On Mon, 2016-12-12 at 15:13 +, André Draszik wrote: > Hi, > > On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote: > > I'll do the same for swupd. Editing the sections should be possible > > without conflicts, we just have to be more careful about editing the > > table concurrently. > > It looks as if some highlights about swupdate can equally be said about > swupd: > > - dual copy is supported > - my minimal swupd-based rescue initramfs is around 4MB swupdate has support for a "dual copy strategy" (http://sbabic.github.io/swupdate/swupdate.html#software-collections) while out-of-the-box (i.e. with what is currently available) meta-swupd and swupd itself don't. So I think it is correct to say that swupdate has some (implementation) advantage here. The "could be extended to do updates without that risk" in the "swupd/Failure resilience" section was meant to include a dual-copy approach. Should that be rephrased to be more explicit? I was thinking of several possible scenarios: * single partition: stage files, stop services, update, restart services or reboot * dual partition: update inactive partition, swap partitions, reboot -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote: > >> In particular the "complexity" column is a bit subjective. Stefano, I > >> hope you don't mind that I did not quite buy the "easy to use" > >> characterization of swupdate ;-) > > No worry...and I have not written myself. It was inserted by Mariano, so > > it looks like that swupdate at least for Mariano is "easy to use". > > I think it is correct to point out that customization is required. > > Compared to other update mechanism that I tested it was the easier to > implement. Which "getting started" document or presentation were you using? The documentation for mender (https://docs.mender.io/) is very straight-forward (partly of course because it doesn't need to cover many variations), while for swupdate (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear how to begin. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On 12/12/16 09:41, Patrick Ohly wrote: > On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote: In particular the "complexity" column is a bit subjective. Stefano, I hope you don't mind that I did not quite buy the "easy to use" characterization of swupdate ;-) >>> No worry...and I have not written myself. It was inserted by Mariano, so >>> it looks like that swupdate at least for Mariano is "easy to use". >>> I think it is correct to point out that customization is required. >> Compared to other update mechanism that I tested it was the easier to >> implement. > Which "getting started" document or presentation were you using? The > documentation for mender (https://docs.mender.io/) is very > straight-forward (partly of course because it doesn't need to cover many > variations), while for swupdate > (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear > how to begin. > When I did a research in update mechanism, mender wasn't yet available, and indeed it seems very straight forward (need to test it before final veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is by far less complex than the other two -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW51
Current Dev Position: YP 2.3 M1 -> M2 Next Deadline: YP 2.3 M1 by Dec. 12, 2016 (TODAY!!) YP 2.3 M2 by Jan 23, 2017 SWAT team rotation: Tracy -> Alejandro https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * Today is the M1 feature freeze deadline. Patches are being processed with a view to merging. We believe all patchsets targeting M1 have been posted apart from tinfoil2 which is imminent and we’re planning to try and include that in M1. * We’re continuing to struggle to identify which patches are causing which failures which may delay M1 slightly as it is going to take time to figure this out and ensure builds are stable. * We’re considering the best way to handle containers and the current build appliance in the project going forwards. If anyone had input they wish to contribute on that subject, Brian has started a thread on the architecture mailing list. Proposed upcoming dot releases: YP 2.0.3 Release by Dec. 9, 2016 YP 2.2.1 Release by Jan. 20, 2017 YP 2.1.3 Release by May. 19, 2017 Key YP 2.3 Dates: YP 2.3 M1 Cutoff is Dec. 12, 2016 YP 2.3 M1 Release is Dec. 23, 2016 YP 2.3 M2 Cutoff is Jan. 23, 2017 YP 2.3 M2 Release is Feb. 3, 2017 YP 2.3 M3 Cutoff is Feb 27, 2017 YP 2.3 M3 Release is Mar. 10, 2017 YP 2.3 M4 Cutoff is April 3, 2017 YP 2.3 M4 Release is April 28, 2017 Tracking Metrics: WDD 2437 (last week 2507) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
Robert, > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Robert P. J. Day > Sent: Monday, December 12, 2016 10:20 AM > To: Yocto discussion list > Subject: [yocto] suggestions for version controlling multi-layer reproducible > builds? > > > (if there's already a doc section for this somewhere, a pointer to it would > be > just ducky.) > > if one is building an image for a releasable, commercial product, and that > image involves pulling in numerous layers, then dumping all sorts of > proprietary apps on top of it, what are the possibilities for how to version > number the released images such that, if a client has an issue, they can > identify precisely the state of components that went into the system they're > working with? > For my setup I have a separate package that is the distribution version number. Whenever we release an update, the distribution version number is updated. We then tag all our layers with the distribution version number for proper record keeping. The Angstrom distribution was (or maybe still is?) doing something similar and was the inspiration for our setup. > in addition to all of the layers involved in the build, one has to take into > account that, when critical bugs are identified, an updated RPM might be > sent out and applied, whereupon that system's version number is no longer > perfectly accurate. in the end, the state of someone's running system will be > determined by a possibly huge combination of selected packages, preferred > package versions, build config options, additional user space apps, hot fixes > that have been applied and so on. > > what sort of meaningful "version number" can be applied to something like > that? i'm sure at least a few other people have to be doing something like > that, so i'm open to suggestions. > > rday Any time we release an update, no matter how minor, we update the distribution version package. Otherwise, as you state, you could have an update that you can't reproduce. We also archive the package repository and generated image files for each release so we can flash a board with a previous release and test from there. It can be a pain to get the process down the first time, but after that a simple Bash script can take care of all the hard work for you and ensure you don't skip a step. Bryan > > -- > > == > == > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > == > == > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
Hi, On 12/12/2016 05:03 PM, Bryan Evenson wrote: > > For my setup I have a separate package that is the distribution > version number. Whenever we release an update, the distribution > version number is updated. We then tag all our layers with the > distribution version number for proper record keeping. The Angstrom > distribution was (or maybe still is?) doing something similar and was > the inspiration for our setup. > > ... > > > Any time we release an update, no matter how minor, we update the > distribution version package. Otherwise, as you state, you could > have an update that you can't reproduce. We also archive the package > repository and generated image files for each release so we can flash > a board with a previous release and test from there. It can be a > pain to get the process down the first time, but after that a simple > Bash script can take care of all the hard work for you and ensure you > don't skip a step. > I'm using a similar approach, but instead of using a separate "version package" I'm using the "BUILDNAME" and "DISTRO_VERSION" variables in my distro.conf. Then depending on how "large" the release is and which changes it includes the Major, Minor or Patchlevel of the version is increased. Furthermore (like Bryan already mentioned) for every release a tag in every layer containing the DISTRO_VERSION is created. The layer setup/checkout and build then is automated by a shellscript. This shellscript takes the version as an argument and produces the images, source archives, update packages and everything else needed for a (nearly) reproducible builds. Hope that helps. regards, Richard L -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't enable reverse debugging
> On Dec 12, 2016, at 6:59 AM, Bryan Evenson wrote: > > Khem, > >> -Original Message- >> From: Khem Raj [mailto:raj.k...@gmail.com] >> Sent: Saturday, December 10, 2016 4:26 PM >> To: Bryan Evenson >> Cc: yocto@yoctoproject.org >> Subject: Re: [yocto] Can't enable reverse debugging >> >> On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson >> wrote: >>> I tried a few other things, see below. >>> -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Bryan Evenson Sent: Thursday, December 08, 2016 2:50 PM To: yocto@yoctoproject.org Subject: [yocto] Can't enable reverse debugging I'm on poky/dizzy and I'm getting a segementation fault in my application that I think may be related to a buffer overflow. I'm using the Eclipse >> plug-in (on Eclipse Kepler) to debug on the hardware with GDB. I'm trying to >> enable reverse debugging but I have not had any success and I'm looking for >> some help. My target processor is an SAM9G25 (ARM926EJ-S core). I have been able >> to debug through Eclipse on the target hardware without issue. I tried >> enabling Reverse Debugging by going to Window->Customize Perspective...- > Command Groups Availability and selecting "Reverse Debugging". Now there is a "Reverse Toggle" button on my toolbar, but it is always grayed >> out whether I have a debug session running or not. I have also tried entering >> the command "record" from the GDB console after my program breaks at >> main. When I run the program, I get the error message "Process record: failed >> to record execution log". >>> >>> I tried first running my application, pausing the debugger and then sending >> the "record" command. When I continued debugging, I got the following >> GDB error: >>> >>> x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/gdb- >> 7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> >>> I did some looking around and I couldn't see any reasonable answer to why >> this would happen. I also just noticed that for the Debug Configurations >> under Eclipse, the debugger settings tab doesn't have "Enable Reverse >> Debugging at startup" option listed for the C/C++ Remote Application >> debugging type. Is this option just not available to me with my environment? >> >> This could mean many things but one area I know is troublesome is >> python support. Sometimes there are issues between >> fundamental types, can you check if the error happens when gdb is >> running some pythonic stuff. > > Could you explain how to do this? I don't use Python so I'm not sure if I'm > doing a valid test. I tried to debug a Python script with GDB through > Eclipse and I wasn't successful. I then went through the command line and > was able to remotely run a simple Python script (print "Hello, Python" once > per second) through GDB. If I issued a "record" command through GDB first, > then when I tried to debug the Python script I'd immediately get a > segmentation fault. > > Is there something specific you'd like me to try? If you think the Python > support may be the issue, is there something I should be verifying is present > or is at a certain version? > Disable python support in gdb and compile it e.g. > Thanks, > Bryan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote: > > On 12/12/16 09:41, Patrick Ohly wrote: > > On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote: > In particular the "complexity" column is a bit subjective. Stefano, I > hope you don't mind that I did not quite buy the "easy to use" > characterization of swupdate ;-) > >>> No worry...and I have not written myself. It was inserted by Mariano, so > >>> it looks like that swupdate at least for Mariano is "easy to use". > >>> I think it is correct to point out that customization is required. > >> Compared to other update mechanism that I tested it was the easier to > >> implement. > > Which "getting started" document or presentation were you using? The > > documentation for mender (https://docs.mender.io/) is very > > straight-forward (partly of course because it doesn't need to cover many > > variations), while for swupdate > > (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear > > how to begin. > > > > When I did a research in update mechanism, mender wasn't yet available, > and indeed it seems very straight forward (need to test it before final > veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is > by far less complex than the other two Ease-of-use is not necessarily determined by the complexity. Good integration and documentation can go a long way towards making a complex solution easy to use - when sticking to the pre-defined usage patterns. The opposite is also true: a simple solution may be hard to use if all one gets is the source code and one first has to reverse-engineer the usage model. I agree that the complexity is roughly swupdate < ostree < swupd and there's also no doubt that the latter two aren't easy to use (mostly due to lacking documentation and integration), but I'm still not sure what documentation the "easy to use" verdict for swupdate is based on. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't enable reverse debugging
Khem, > -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Monday, December 12, 2016 12:48 PM > To: Bryan Evenson > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Can't enable reverse debugging > > > > On Dec 12, 2016, at 6:59 AM, Bryan Evenson > wrote: > > > > Khem, > > > >> -Original Message- > >> From: Khem Raj [mailto:raj.k...@gmail.com] > >> Sent: Saturday, December 10, 2016 4:26 PM > >> To: Bryan Evenson > >> Cc: yocto@yoctoproject.org > >> Subject: Re: [yocto] Can't enable reverse debugging > >> > >> On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson > >> > >> wrote: > >>> I tried a few other things, see below. > >>> > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Bryan Evenson > Sent: Thursday, December 08, 2016 2:50 PM > To: yocto@yoctoproject.org > Subject: [yocto] Can't enable reverse debugging > > I'm on poky/dizzy and I'm getting a segementation fault in my > application that I think may be related to a buffer overflow. I'm > using the Eclipse > >> plug-in > (on Eclipse Kepler) to debug on the hardware with GDB. I'm trying > to > >> enable > reverse debugging but I have not had any success and I'm looking > for > >> some > help. > > My target processor is an SAM9G25 (ARM926EJ-S core). I have been > able > >> to > debug through Eclipse on the target hardware without issue. I > tried > >> enabling > Reverse Debugging by going to Window->Customize Perspective...- > > Command Groups Availability and selecting "Reverse Debugging". > > Now > there is a "Reverse Toggle" button on my toolbar, but it is always > grayed > >> out > whether I have a debug session running or not. I have also tried > entering > >> the > command "record" from the GDB console after my program breaks at > >> main. > When I run the program, I get the error message "Process record: > failed > >> to > record execution log". > >>> > >>> I tried first running my application, pausing the debugger and then > >>> sending > >> the "record" command. When I continued debugging, I got the > >> following GDB error: > >>> > >>> x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/g > >>> db- > >> 7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted. > >>> A problem internal to GDB has been detected, further debugging may > >>> prove unreliable. > >>> > >>> I did some looking around and I couldn't see any reasonable answer > >>> to why > >> this would happen. I also just noticed that for the Debug > >> Configurations under Eclipse, the debugger settings tab doesn't have > >> "Enable Reverse Debugging at startup" option listed for the C/C++ > >> Remote Application debugging type. Is this option just not available to me > with my environment? > >> > >> This could mean many things but one area I know is troublesome is > >> python support. Sometimes there are issues between fundamental > types, > >> can you check if the error happens when gdb is running some pythonic > >> stuff. > > > > Could you explain how to do this? I don't use Python so I'm not sure if I'm > doing a valid test. I tried to debug a Python script with GDB through Eclipse > and I wasn't successful. I then went through the command line and was able > to remotely run a simple Python script (print "Hello, Python" once per > second) through GDB. If I issued a "record" command through GDB first, > then when I tried to debug the Python script I'd immediately get a > segmentation fault. > > > > Is there something specific you'd like me to try? If you think the Python > support may be the issue, is there something I should be verifying is present > or is at a certain version? > > > > Disable python support in gdb and compile it e.g. I rebuilt gdb. I used the --configure option to verify that my previous gdb did have the "--with-python" option present and that my newly built gdb did not have that option anymore. I no longer can produce the " internal-error: virtual memory exhausted" error, but whenever I try to record I still get the "Process record: failed to record execution log" when I run the application. If it helps, here's the configuration output from GDB: This GDB was configured as follows: configure --host=x86_64-linux --target=arm-poky-linux-gnueabi --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --with-expat --with-gdb-datadir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/share/gdb-arm926ejste-poky-linux-gnueabi/gdb (relocatable) --with-jit-reader-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gdb (relocatable) --without-libunwind-ia64 --without-lzma --with-sep
Re: [yocto] Can't enable reverse debugging
> On Dec 12, 2016, at 11:12 AM, Bryan Evenson wrote: > > Khem, > >> -Original Message- >> From: Khem Raj [mailto:raj.k...@gmail.com] >> Sent: Monday, December 12, 2016 12:48 PM >> To: Bryan Evenson >> Cc: yocto@yoctoproject.org >> Subject: Re: [yocto] Can't enable reverse debugging >> >> >>> On Dec 12, 2016, at 6:59 AM, Bryan Evenson >> wrote: >>> >>> Khem, >>> -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Saturday, December 10, 2016 4:26 PM To: Bryan Evenson Cc: yocto@yoctoproject.org Subject: Re: [yocto] Can't enable reverse debugging On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson wrote: > I tried a few other things, see below. > >> -Original Message- >> From: yocto-boun...@yoctoproject.org [mailto:yocto- >> boun...@yoctoproject.org] On Behalf Of Bryan Evenson >> Sent: Thursday, December 08, 2016 2:50 PM >> To: yocto@yoctoproject.org >> Subject: [yocto] Can't enable reverse debugging >> >> I'm on poky/dizzy and I'm getting a segementation fault in my >> application that I think may be related to a buffer overflow. I'm >> using the Eclipse plug-in >> (on Eclipse Kepler) to debug on the hardware with GDB. I'm trying >> to enable >> reverse debugging but I have not had any success and I'm looking >> for some >> help. >> >> My target processor is an SAM9G25 (ARM926EJ-S core). I have been >> able to >> debug through Eclipse on the target hardware without issue. I >> tried enabling >> Reverse Debugging by going to Window->Customize Perspective...- >>> Command Groups Availability and selecting "Reverse Debugging". >>> Now >> there is a "Reverse Toggle" button on my toolbar, but it is always >> grayed out >> whether I have a debug session running or not. I have also tried >> entering the >> command "record" from the GDB console after my program breaks at main. >> When I run the program, I get the error message "Process record: >> failed to >> record execution log". > > I tried first running my application, pausing the debugger and then > sending the "record" command. When I continued debugging, I got the following GDB error: > > x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/g > db- 7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted. > A problem internal to GDB has been detected, further debugging may > prove unreliable. > > I did some looking around and I couldn't see any reasonable answer > to why this would happen. I also just noticed that for the Debug Configurations under Eclipse, the debugger settings tab doesn't have "Enable Reverse Debugging at startup" option listed for the C/C++ Remote Application debugging type. Is this option just not available to me >> with my environment? This could mean many things but one area I know is troublesome is python support. Sometimes there are issues between fundamental >> types, can you check if the error happens when gdb is running some pythonic stuff. >>> >>> Could you explain how to do this? I don't use Python so I'm not sure if I'm >> doing a valid test. I tried to debug a Python script with GDB through >> Eclipse >> and I wasn't successful. I then went through the command line and was able >> to remotely run a simple Python script (print "Hello, Python" once per >> second) through GDB. If I issued a "record" command through GDB first, >> then when I tried to debug the Python script I'd immediately get a >> segmentation fault. >>> >>> Is there something specific you'd like me to try? If you think the Python >> support may be the issue, is there something I should be verifying is present >> or is at a certain version? >>> >> >> Disable python support in gdb and compile it e.g. > > I rebuilt gdb. I used the --configure option to verify that my previous gdb > did have the "--with-python" option present and that my newly built gdb did > not have that option anymore. I no longer can produce the " internal-error: > virtual memory exhausted" error, but whenever I try to record I still get the > "Process record: failed to record execution log" when I run the application. > If it helps, here's the configuration output from GDB: > > This GDB was configured as follows: > configure --host=x86_64-linux --target=arm-poky-linux-gnueabi > --with-auto-load-dir=$debugdir:$datadir/auto-load > --with-auto-load-safe-path=$debugdir:$datadir/auto-load > --with-expat > > --with-gdb-datadir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/share/gdb-arm926ejste-poky-linux-gnueabi/gdb > (relocatable) > > --with-jit-reader-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/ar
Re: [yocto] Can't enable reverse debugging
> -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Monday, December 12, 2016 2:54 PM > To: Bryan Evenson > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Can't enable reverse debugging > > > > On Dec 12, 2016, at 11:12 AM, Bryan Evenson > wrote: > > > > Khem, > > > >> -Original Message- > >> From: Khem Raj [mailto:raj.k...@gmail.com] > >> Sent: Monday, December 12, 2016 12:48 PM > >> To: Bryan Evenson > >> Cc: yocto@yoctoproject.org > >> Subject: Re: [yocto] Can't enable reverse debugging > >> > >> > >>> On Dec 12, 2016, at 6:59 AM, Bryan Evenson > > >> wrote: > >>> > >>> Khem, > >>> > -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Saturday, December 10, 2016 4:26 PM > To: Bryan Evenson > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Can't enable reverse debugging > > On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson > > wrote: > > I tried a few other things, see below. > > > >> -Original Message- > >> From: yocto-boun...@yoctoproject.org [mailto:yocto- > >> boun...@yoctoproject.org] On Behalf Of Bryan Evenson > >> Sent: Thursday, December 08, 2016 2:50 PM > >> To: yocto@yoctoproject.org > >> Subject: [yocto] Can't enable reverse debugging > >> > >> I'm on poky/dizzy and I'm getting a segementation fault in my > >> application that I think may be related to a buffer overflow. > >> I'm using the Eclipse > plug-in > >> (on Eclipse Kepler) to debug on the hardware with GDB. I'm > >> trying to > enable > >> reverse debugging but I have not had any success and I'm looking > >> for > some > >> help. > >> > >> My target processor is an SAM9G25 (ARM926EJ-S core). I have been > >> able > to > >> debug through Eclipse on the target hardware without issue. I > >> tried > enabling > >> Reverse Debugging by going to Window->Customize Perspective...- > >>> Command Groups Availability and selecting "Reverse Debugging". > >>> Now > >> there is a "Reverse Toggle" button on my toolbar, but it is > >> always grayed > out > >> whether I have a debug session running or not. I have also tried > >> entering > the > >> command "record" from the GDB console after my program breaks > at > main. > >> When I run the program, I get the error message "Process record: > >> failed > to > >> record execution log". > > > > I tried first running my application, pausing the debugger and > > then sending > the "record" command. When I continued debugging, I got the > following GDB error: > > > > x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0 > > /g > > db- > 7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted. > > A problem internal to GDB has been detected, further debugging may > > prove unreliable. > > > > I did some looking around and I couldn't see any reasonable answer > > to why > this would happen. I also just noticed that for the Debug > Configurations under Eclipse, the debugger settings tab doesn't > have "Enable Reverse Debugging at startup" option listed for the > C/C++ Remote Application debugging type. Is this option just not > available to me > >> with my environment? > > This could mean many things but one area I know is troublesome is > python support. Sometimes there are issues between fundamental > >> types, > can you check if the error happens when gdb is running some > pythonic stuff. > >>> > >>> Could you explain how to do this? I don't use Python so I'm not > >>> sure if I'm > >> doing a valid test. I tried to debug a Python script with GDB > >> through Eclipse and I wasn't successful. I then went through the > >> command line and was able to remotely run a simple Python script > >> (print "Hello, Python" once per > >> second) through GDB. If I issued a "record" command through GDB > >> first, then when I tried to debug the Python script I'd immediately > >> get a segmentation fault. > >>> > >>> Is there something specific you'd like me to try? If you think the > >>> Python > >> support may be the issue, is there something I should be verifying is > >> present or is at a certain version? > >>> > >> > >> Disable python support in gdb and compile it e.g. > > > > I rebuilt gdb. I used the --configure option to verify that my previous gdb > did have the "--with-python" option present and that my newly built gdb did > not have that option anymore. I no longer can produce the " internal-error: > virtual memory exhausted" error, but whenever I try to record I still get the > "Process record: failed to record execution log" when I run the application. > If > it helps, here's the configuration output from GDB: > > > > This GDB was configured as follows: >
Re: [yocto] Kernel config incremental modification not working.
On Mon, 12 Dec 2016 08:41:36 Bruce Ashfield wrote: > On 2016-12-11 02:33 PM, Paul Eggleton wrote: > > Can we please have some automated tests covering all of this? Perhaps it > > would be worth talking to Francisco Pedraza who is looking at adding > > tests under bug > > 6359: > > We are already meeting to talk about this :D Superb, thanks! Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-zephyr layer
There is interest in the community to support building Zephyr images ( https://www.zephyrproject.org/ )in Yocto via bitbake recipes. AFAIK the only way thus far to build Zephyr images is based on command line/Kconfig, similar to building Linux kernel images. Building of Zephyr images in Yocto can now be done fairly unobtrusively via a new layer "meta-zephyr" and specifying a new distro in local.conf: DISTRO="zephyr" The repository for the meta-zephyr is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr. The new meta-zephyr layer contains several recipes to build (and run in QEMUs) various Zephyr tests. There is also a sample recipe to build Zephyr sample "philosophers" with instructions how to run it in QEMU. This is the first kick at the can. At present, only x86 and ARM CortexM3 toolchains are supported, with more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU, and Xtensa and RISC-V coming in the next release) The new meta-zephyr is work based on previous original work by Randy Witt and Richard Purdie, so it is actually a second kick at the can. This is a work in progress, any feedback is appreciated. Juro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Does that work without poky? Philip On 12/12/2016 02:15 PM, Bystricky, Juro wrote: > There is interest in the community to support building Zephyr images > ( https://www.zephyrproject.org/ )in Yocto via bitbake recipes. > AFAIK the only way thus far to build Zephyr images is based on command > line/Kconfig, similar to building Linux kernel images. > > Building of Zephyr images in Yocto can now be done fairly unobtrusively > via a new layer "meta-zephyr" and specifying a new distro in local.conf: > DISTRO="zephyr" > > The repository for the meta-zephyr is here: > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr. > > The new meta-zephyr layer contains several recipes to build (and run > in QEMUs) various Zephyr tests. There is also a sample recipe to build > Zephyr sample "philosophers" with instructions how to run it in QEMU. > > This is the first kick at the can. > At present, only x86 and ARM CortexM3 toolchains are supported, with > more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU, > and Xtensa and RISC-V coming in the next release) > > The new meta-zephyr is work based on previous original work by > Randy Witt and Richard Purdie, so it is actually a second kick at the can. > > This is a work in progress, any feedback is appreciated. > > Juro > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: remove version hack
2016-12-12 06:21 skrev Khem Raj:
> On Thu, Dec 8, 2016 at 2:40 AM,
Andreas Müller
> wrote:
>
>> * no more
required (version > 3.17 | > 4.3.x | > 4.4.5) * causes error with rt
kernel
>
> I think this is ok to apply now.
>
>> Signed-off-by:
Andreas Müller ---
classes/linux-raspberrypi-base.bbclass | 15 --- 1 file
changed, 15 deletions(-) diff --git
a/classes/linux-raspberrypi-base.bbclass
b/classes/linux-raspberrypi-base.bbclass index 3a6e33d..dc2330a 100644
--- a/classes/linux-raspberrypi-base.bbclass +++
b/classes/linux-raspberrypi-base.bbclass @@ -14,21 +14,6 @@ def
get_dts(d, ver=None): from the kernel staging ''' ver =
get_kernelversion_file(staging_dir) - if ver is not None: - min_ver =
ver.split('.', 3) - else: - return dts - - # Always turn off device tree
support for kernel's < 3.18 - try: - if int(min_ver[0]) >= 4: - if
(int(min_ver[1]) < 4) or (int(min_ver[1]) == 4 and int(min_ver[2]) < 6):
- dts = ' '.join([(re.sub(r'(.*).dtbo$', r'1-overlay.dtb', x)) for x in
dts.split()]) - elif int(min_ver[1]) < 18: - dts = "" - except
IndexError: - min_ver = None - return dts -- 2.7.4 --
___ yocto mailing list
yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[1]
I think you should go even one step further and revert the entire
commit merging this obsolete functionality: "git revert
4a4373c02d3d8355a2e5faa10af61450e5b093d8" .
BR Petter
Links:
--
[1] https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
you need poky to build QEMUs and toolchains > -Original Message- > From: Philip Balister [mailto:phi...@balister.org] > Sent: Monday, December 12, 2016 2:19 PM > To: Bystricky, Juro ; yocto@yoctoproject.org > Subject: Re: [yocto] meta-zephyr layer > > Does that work without poky? > > Philip > > On 12/12/2016 02:15 PM, Bystricky, Juro wrote: > > There is interest in the community to support building Zephyr images > > ( https://www.zephyrproject.org/ )in Yocto via bitbake recipes. > > AFAIK the only way thus far to build Zephyr images is based on command > > line/Kconfig, similar to building Linux kernel images. > > > > Building of Zephyr images in Yocto can now be done fairly unobtrusively > > via a new layer "meta-zephyr" and specifying a new distro in local.conf: > > DISTRO="zephyr" > > > > The repository for the meta-zephyr is here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta- > zephyr. > > > > The new meta-zephyr layer contains several recipes to build (and run > > in QEMUs) various Zephyr tests. There is also a sample recipe to build > > Zephyr sample "philosophers" with instructions how to run it in QEMU. > > > > This is the first kick at the can. > > At present, only x86 and ARM CortexM3 toolchains are supported, with > > more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU, > > and Xtensa and RISC-V coming in the next release) > > > > The new meta-zephyr is work based on previous original work by > > Randy Witt and Richard Purdie, so it is actually a second kick at the > can. > > > > This is a work in progress, any feedback is appreciated. > > > > Juro > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: remove version hack
On Mon, Dec 12, 2016 at 11:33 PM, Petter Mabäcker wrote:
> 2016-12-12 06:21 skrev Khem Raj:
>
> On Thu, Dec 8, 2016 at 2:40 AM, Andreas Müller
> wrote:
>
> * no more required (version > 3.17 | > 4.3.x | > 4.4.5) * causes error with
> rt kernel
>
> I think this is ok to apply now.
>
> Signed-off-by: Andreas Müller ---
> classes/linux-raspberrypi-base.bbclass | 15 --- 1 file changed,
> 15 deletions(-) diff --git a/classes/linux-raspberrypi-base.bbclass
> b/classes/linux-raspberrypi-base.bbclass index 3a6e33d..dc2330a 100644 ---
> a/classes/linux-raspberrypi-base.bbclass +++
> b/classes/linux-raspberrypi-base.bbclass @@ -14,21 +14,6 @@ def get_dts(d,
> ver=None): from the kernel staging ''' ver =
> get_kernelversion_file(staging_dir) - if ver is not None: - min_ver =
> ver.split('.', 3) - else: - return dts - - # Always turn off device tree
> support for kernel's < 3.18 - try: - if int(min_ver[0]) >= 4: - if
> (int(min_ver[1]) < 4) or (int(min_ver[1]) == 4 and int(min_ver[2]) < 6): -
> dts = ' '.join([(re.sub(r'(.*)\.dtbo$', r'\1-overlay.dtb', x)) for x in
> dts.split()]) - elif int(min_ver[1]) < 18: - dts = "" - except IndexError: -
> min_ver = None - return dts -- 2.7.4 --
> ___ yocto mailing list
> yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
>
> I think you should go even one step further and revert the entire commit
> merging this obsolete functionality: "git revert
> 4a4373c02d3d8355a2e5faa10af61450e5b093d8" .
>
> BR Petter
To be honest: I have forked meta-raspberrypi and don't use it any
more. Just wanted to be a good boy. So maybe you want to send the
revert here?
Andreas
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
On 12 December 2016 at 22:52, Bystricky, Juro wrote: > you need poky to build QEMUs and toolchains > You should just need *OpenEmbedded* to build the qemus and toolchains. Why does zephyr.conf include poky.conf? I'd say that any variables that are useful - such as using the Yocto source mirrors - should just be copied into zephyr.conf (or even better, moved into oe-core). Ross Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: remove version hack
2016-12-13 00:55 skrev Andreas Müller:
> On Mon, Dec 12, 2016 at
11:33 PM, Petter Mabäcker wrote:
>
>> 2016-12-12
06:21 skrev Khem Raj: On Thu, Dec 8, 2016 at 2:40 AM, Andreas Müller
wrote: * no more required (version > 3.17
| > 4.3.x | > 4.4.5) * causes error with rt kernel I think this is ok to
apply now. Signed-off-by: Andreas Müller
--- classes/linux-raspberrypi-base.bbclass | 15 --- 1 file
changed, 15 deletions(-) diff --git
a/classes/linux-raspberrypi-base.bbclass
b/classes/linux-raspberrypi-base.bbclass index 3a6e33d..dc2330a 100644
--- a/classes/linux-raspberrypi-base.bbclass +++
b/classes/linux-raspberrypi-base.bbclass @@ -14,21 +14,6 @@ def
get_dts(d, ver=None): from the kernel staging ''' ver =
get_kernelversion_file(staging_dir) - if ver is not None: - min_ver =
ver.split('.', 3) - else: - return dts - - # Always turn off device tree
support for kernel's < 3.18 - try: - if int(min_ver[0]) >= 4: - if
(int(min_ver[1]) < 4) or (int(min_ver[1]) == 4 and int(min_ver[2]) < 6):
- dts = ' '.join([(re.sub(r'(.*).dtbo$', r'1-overlay.dtb', x)) for x in
dts.split()]) - elif int(min_ver[1]) < 18: - dts = "" - except
IndexError: - min_ver = None - return dts -- 2.7.4 --
___ yocto mailing list
yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[1]
>
>> I think you should go even one step further and revert the
entire commit merging this obsolete functionality: "git revert
4a4373c02d3d8355a2e5faa10af61450e5b093d8" .
> BR Petter
>
> To be
honest: I have forked meta-raspberrypi and don't use it any
> more. Just
wanted to be a good boy. So maybe you want to send the
> revert here?
>
> Andreas
>
>>
Oh I see. Sure, I can send something up.
Petter
Mabäcker
Technux
www.technux.se
Links:
--
[1] https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
