Re: [yocto] uboot.bin and rootfs but not uImage
Hi Rudy,
Thank you for the basic file... I have a question here... The git directory
is already saved on my work pc. What is the necessity to download it again?
The reason behind my asking this question is, it is secured and so password
is required. So, in order to avoid confusion I already downloaded it to a
directory called /home/damarla/linux-skidata.git. So can I just write
SRC_URI = dir://home/damarla/linux-skidata.git
I think in the above way I can just simply remove the KSRC and KBRANCH
variables from the linux-skidata.bb file. The revision tag is also not
required in this cases as we are using the kernel provided by the company
itself, I mean for the first basic build.
One more thing is the skidata-carrier_defconfig is already in the directory
git I mentioned above at
/home/damarla/linux-skidata.git/arch/arm/configs/skidata-carrier_defconfig
... When compiling the kernel how can we tell the build system to build the
kernel using that specific defconfig file?
Thanks Rudy in advance,
Satya
On Thu, Feb 28, 2013 at 9:31 PM, Rudolf Streif
rstr...@linuxfoundation.orgwrote:
Hi Satya,
You will first need a kernel recipe, let's call it linux-skidata.bb. It
can look like this:
DESCRIPTION = Skidata Linux Kernel
SECTION = kernel
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7
PV = 3.2
inherit kernel
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:${THISDIR}/${PN}/patches:
# GIT repository location
KSRC ?= path to/linux-skidata.git
# Branch to check out
KBRANCH ?= branch
# Revision tag or AUTOREV
SRCREV ?= ${AUTOREV}
SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
file://defconfig \
S = ${WORKDIR}/git
You will need to provide a defconfig file next to your recipe containing
the kernel configuration settings. Your kernel GIT repo may contain a
.config that is good for your hardware. In that case you do not need a
defconfig but is still a good practice and will allow you to easily change
the settings.
Then you need to adjust your machine configuration file:
PREFERRED_PROVIDER_virtual/kernel ?= linux-skidata
PREFERRED_VERSION_skidata ?= 3.2%
That should do it.
:rjs
On Thu, Feb 28, 2013 at 11:21 AM, Satya Swaroop Damarla
swaroop.dama...@gmail.com wrote:
Yes I got an error message when I was building the kernel... Actuallly I
have a kernel git given by the company I downloaded it and is in my
work pc.. How can I tell the build system to use that kernel?
On Thu, Feb 28, 2013 at 8:17 PM, Rudolf Streif
rstr...@linuxfoundation.org wrote:
Satya,
your machine configuration file looks ok as far as I can tell. Did you
get an error message when building the kernel? Did you try to build just
the kernel e.g. bitbake linux-yocto?
:rjs
On Mon, Feb 25, 2013 at 11:31 PM, Satya Swaroop Damarla
swaroop.dama...@gmail.com wrote:
Hello Guys... I think uImage is important but it is not being generated
by the yocto project. It only generated the rootfs and uboot.bin. Is there
any variable that has to be introduced in the machine.conf (in my case it
is skidata-tamonten.conf)
Here is the configuration file
#@TYPE: Machine
#@NAME: skidata-tamonten machine
#@DESCRIPTION: Machine configuration for the Tamonten board
PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
IMAGE_FEATURES += package-management
EXTRA_IMAGEDEPENDS += u-boot
# Uncomment the following line to enable the hard floating point abi.
Note that
# this breaks some binary libraries and 3D (neither of which ship with
# meta-yocto). For maximum compatibility, leave this disabled.
DEFAULTTUNE ?= cortexa9t
include conf/machine/include/tune-cortexa9.inc
IMAGE_FSTYPES += tar.bz2 ext2
SERIAL_CONSOLE = 115200 ttyS0
PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto
PREFERRED_VERSION_linux-yocto ?= 3.2%
KERNEL_IMAGETYPE = uImage
PREFERRED_VERSION_u-boot ?= v2013.01.01%
UBOOT_MACHINE = tec_config
UBOOT_ENTRYPOINT = 0x1700
UBOOT_LOADADDRESS = 0x1700
MACHINE_FEATURES = usbgadget usbhost vfat screen touchscreen keyboard
Greets,
Satya
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
--
*Rudolf J. Streif*
Director of Embedded Solutions
The Linux Foundation
rudolf.str...@linux.com
Phone: +1.619.631.5383
Skype: rudolfstreif
PGP: RSA 2048/2048 D6E7D28B
Linux Foundation Events Schedule: events.linuxfoundation.org
Linux Foundation Training Schedule: training.linuxfoundation.org
--
--
*Rudolf J. Streif*
Director of Embedded Solutions
The Linux Foundation
rudolf.str...@linux.com
Phone: +1.619.631.5383
Skype: rudolfstreif
PGP: RSA 2048/2048 D6E7D28B
Linux Foundation Events Schedule: events.linuxfoundation.org
Linux Foundation Training Schedule: training.linuxfoundation.org
___
yocto mailing list
yocto@yoctoproject.org
Re: [yocto] [PATCH 0/5][eclipse-poky] Refactor handling of SDK check errors
Hi Jessica, Zhang, Jessica wrote, On 27.02.2013 23:04: Hi Timo, Thanks for initiating the cleanup in this area that I agree definitely need some work. There're couple issues I'm seeing with your patch set that probably need some refinements: 1. After seeing the error message, if I go into the field correct the error, I have to explicit click on Apply to make it revalidate, probably we should track the fields change and do automatic re-validation Yes, I agree it can be confusing. I already played around with enabling Listeners on the YoctoUISetting element but stopped because I thought that rechecking the SDK everytime you type in a new character will slow down the ui to much. One idea I have in mind is, if the settings are changed (on type) we delete the error message and show a message telling the user that the new settings have to be revalidated again. Do you think that would be sufficient? Nevertheless I will extend the YoctoUISetting to be able to notify registered listeners on change. Then we can decide on how we want to react to this change. 2. For a scenario that I have 2 toolchains (for different arch, e.g. arm and x86) installed under same directory, which means there're 2 environment setup scripts under the same directory. In this case, the Target Architecture drop down list will contain 2 entries for the arches. In this case, I'm getting an error message for missing environment script file which is not true. By looking at the code, the logic basically checking the elem's target architecture setting, if there's none, report missing environment script. I think for this case, we do need to check the size of the target arch option list to see whether it's empty or not. True, this calls for a separate error message. 3. For the case of Poky.Env.Script.Nonexist, there's Poky.Env.ScriptNoexist.Advise which is more meaningful to user what to do if running into the error. But I don't see that Advice is posted and by looking at code, it seems it's not being used as well? I'll try to rephrase the error message. Regarding the advice I'm not quite sure if I follow correctly. If you choose Build system derived toolchain and the location doesn't contain a toolchain (so the drop-down is empty) the SDK check fails with ENV_SETUP_SCRIPT_NONEXIST. If a dialog pops up showing the error, the advice will also be used and added to the message. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Timo Mueller Sent: Wednesday, February 27, 2013 6:37 AM To: yocto@yoctoproject.org Cc: Timo Mueller Subject: [yocto] [PATCH 0/5][eclipse-poky] Refactor handling of SDK check errors From: Timo Mueller timo.muel...@bmw-carit.de Hi, I tried to display the messages resulting from validating the YoctoUISettings in the message area of the properties/preference pages instead of showing a dialog. This led to some refactoring of the validation functionality and also the messages. If for example the user entered a SDK toolchain directory that doesn't exist in the global preferences a dialog will show up showing the error and telling him how he can do IDE-wide settings. As he is currently trying to do IDE-wide settings this advice is not really necessary and the dialog can be really annoying. I split up the messages into a one line error message and an advice. This message can be shown in the page's message area instead of opening a dialog with every configuration error. The advice can still be used when we want to show a dialog to help the user, e.g. when creating a new project. On a side note I reactivated the YoctoSDKChecker class and moved all the validation code from the utils, getting rid of some duplicated and inconsistent code. Best regards, Timo PS: This patch set is based on plugins/sdk.ide: Remove profile edit buttons from property page Best regards Timo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] uboot.bin and rootfs but not uImage
On 13-03-01 03:53 AM, Satya Swaroop Damarla wrote:
Hi Rudy,
Thank you for the basic file... I have a question here... The git
directory is already saved on my work pc. What is the necessity to
download it again? The reason behind my asking this question is, it is
secured and so password is required. So, in order to avoid confusion I
already downloaded it to a directory called
/home/damarla/linux-skidata.git. So can I just write
SRC_URI = dir://home/damarla/linux-skidata.git
I think in the above way I can just simply remove the KSRC and KBRANCH
variables from the linux-skidata.bb http://linux-skidata.bb file. The
revision tag is also not required in this cases as we are using the
kernel provided by the company itself, I mean for the first basic build.
The example code that was posted, already does this. KSRC points to
a git repository on your local machine:
KSRC ?= path to/linux-skidata.git
And the protocol is set to file in the SRC_URI
SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
file://defconfig
There's nothing more that you need to do.
One more thing is the skidata-carrier_defconfig is already in the
directory git I mentioned above at
/home/damarla/linux-skidata.git/arch/arm/configs/skidata-carrier_defconfig
... When compiling the kernel how can we tell the build system to build
the kernel using that specific defconfig file?
Putting the defconfig on the SRC_URI is all that you have to do.
This information is also covered in the quickstart and development
guides .. have you had a look at them ? If you have a look, you'll
see that more options are available with linux-yocto based recipes
(custom or the ones part of oe-core), which will allow you some more
flexibility in handling modifications to the kernel.
Cheers,
Bruce
Thanks Rudy in advance,
Satya
On Thu, Feb 28, 2013 at 9:31 PM, Rudolf Streif
rstr...@linuxfoundation.org mailto:rstr...@linuxfoundation.org wrote:
Hi Satya,
You will first need a kernel recipe, let's call it linux-skidata.bb
http://linux-skidata.bb. It can look like this:
DESCRIPTION = Skidata Linux Kernel
SECTION = kernel
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7
PV = 3.2
inherit kernel
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:${THISDIR}/${PN}/patches:
# GIT repository location
KSRC ?= path to/linux-skidata.git
# Branch to check out
KBRANCH ?= branch
# Revision tag or AUTOREV
SRCREV ?= ${AUTOREV}
SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
file://defconfig \
S = ${WORKDIR}/git
You will need to provide a defconfig file next to your recipe
containing the kernel configuration settings. Your kernel GIT repo
may contain a .config that is good for your hardware. In that case
you do not need a defconfig but is still a good practice and will
allow you to easily change the settings.
Then you need to adjust your machine configuration file:
PREFERRED_PROVIDER_virtual/kernel ?= linux-skidata
PREFERRED_VERSION_skidata ?= 3.2%
That should do it.
:rjs
On Thu, Feb 28, 2013 at 11:21 AM, Satya Swaroop Damarla
swaroop.dama...@gmail.com mailto:swaroop.dama...@gmail.com wrote:
Yes I got an error message when I was building the kernel...
Actuallly I have a kernel git given by the company I
downloaded it and is in my work pc.. How can I tell the build
system to use that kernel?
On Thu, Feb 28, 2013 at 8:17 PM, Rudolf Streif
rstr...@linuxfoundation.org
mailto:rstr...@linuxfoundation.org wrote:
Satya,
your machine configuration file looks ok as far as I can
tell. Did you get an error message when building the kernel?
Did you try to build just the kernel e.g. bitbake linux-yocto?
:rjs
On Mon, Feb 25, 2013 at 11:31 PM, Satya Swaroop Damarla
swaroop.dama...@gmail.com
mailto:swaroop.dama...@gmail.com wrote:
Hello Guys... I think uImage is important but it is not
being generated by the yocto project. It only generated
the rootfs and uboot.bin. Is there any variable that has
to be introduced in the machine.conf (in my case it is
skidata-tamonten.conf)
Here is the configuration file
#@TYPE: Machine
#@NAME: skidata-tamonten machine
#@DESCRIPTION: Machine configuration for the Tamonten board
PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
IMAGE_FEATURES += package-management
EXTRA_IMAGEDEPENDS += u-boot
# Uncomment the following line to enable the hard
floating point abi. Note that
# this breaks some binary
[yocto] linux 3.8
Given that Greg KH has publicly stated linux-3.8 is not a long term stable kernel, is it worth the effort to support it in Yocto? http://www.kroah.com/log/linux/3.8-is_not_longterm_stable.html ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Newbie trying to get started
Hi Paul, I saw your email on the gumstix list but forgot to star it, and therefore didn't get back to it as I would have liked, sorry about that. I too play around with a gumstix from time to time, as well as other boards. In my (still learning) opinion, the gumstix stable build is based on really old stuff (i.e. from last... September? October?) So in my case I tend to have two completely separate yocto areas: one for gumstix, and another for everything else, and I don't mix anything between the two except the download location. For example, the gumstix build is sort of based on Danny, but not really, if you check, the repositories are checked out at random points in time (detached HEAD state) instead of actually using or tracking Danny. Working with a gumstix is sort of like having to work with a vendor branch: for best results you have to use their stuff, but their stuff isn't really upstream or tracking upstream very closely. So it's best not to confuse the real Yocto, for gumstix's Yocto-based build. For example their instructions have you use the repo utility (instead of just using git) and start your project with: $ TEMPLATECONF=meta-gumstix/conf source ./poky/oe-init-build-env instead of the regular template file and a regular git checkout of the yocto project. For best results I would recommend that you be sure to use a separate, new terminal when you start your Intel work. That way various environment variables (PATH, etc) don't interfere with each other. As I mentioned above, you might get some savings if you open the conf/local.conf of both projects and point the DL_DIR variable to the same directory. But how much savings you'll get from that isn't obvious (you might not get any). Best regards, Trevor ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux 3.8
On 13-03-01 11:42 AM, Trevor Woerner wrote: Given that Greg KH has publicly stated linux-3.8 is not a long term stable kernel, is it worth the effort to support it in Yocto? We don't need LTSI to make a kernel worth supporting. We pick our kernels based on the timing of the Yocto release schedule (the time and criteria are documented on the yoctoproject wiki IIRC). But note, Greg is talking specifically about LTSI, we don't expect more than one LTSI per year, and we are already locked into the LTSI 3.4. We've known Greg's strategy and plans for a while, so this isn't a surprise. He'll do his normal -stable releases for 3.8 and drop them once 3.9 arrives, which is also expected. Cheers, Bruce http://www.kroah.com/log/linux/3.8-is_not_longterm_stable.html ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Autobuilder downtime.
All, I'm going to be switching, temporarily, the autobuilder off so I can test the new software stack, starting later today, after we get a build of master. This switch will continue through til Saturday 10pm Pacific. This is needed in order to reduce load on the cluster so I can get some decent test results. The current plan is to do a compare of the results of the new autobuilder with the old autobuilder, fix any bugs found, and then switch the new software over on March 8th. As people have referenced autobuilder logs in bugzilla, we've a minor issue of maintaining those logs. That log move will occur on March 8th. Please plan for an all day autobuilder outage on that day. -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux 3.8
Bruce, On Fri, Mar 1, 2013 at 9:29 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: But note, Greg is talking specifically about LTSI, we don't expect more than one LTSI per year, and we are already locked into the LTSI 3.4. However, as far as I understand it the 3.4 snapshot in git.yoctoproject.org is from kernel.org and not from http://git.linuxfoundation.org/ltsi-kernel.git. GregKH has been merging patches into the LTSI kernel, such as AF_BUS, that have not been accepted by upstream. I do not think that those patches are being merged into the YP kernel tree. But please correct me if I am wrong. Cheers, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux 3.8
On 13-03-01 02:15 PM, Rudolf Streif wrote: Bruce, On Fri, Mar 1, 2013 at 9:29 AM, Bruce Ashfield bruce.ashfi...@windriver.com mailto:bruce.ashfi...@windriver.com wrote: But note, Greg is talking specifically about LTSI, we don't expect more than one LTSI per year, and we are already locked into the LTSI 3.4. However, as far as I understand it the 3.4 snapshot in git.yoctoproject.org http://git.yoctoproject.org is from kernel.org http://kernel.org and not from http://git.linuxfoundation.org/ltsi-kernel.git. GregKH has been merging patches into the LTSI kernel, such as AF_BUS, that have not been accepted by upstream. I do not think that those patches are being merged into the YP kernel tree. But please correct me if I am wrong. The 3.4 LTSI patches are all present on the 3.4 kernel tree, directly from Greg's patch queue. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/log/?h=ltsi And that branch is merged into each and every other branch in the linux-yocto tree. We've been involved with Greg and LTSI for quite a while now, and are tracking it via our tree as we discussed with the interested parties. Cheers, Bruce Cheers, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
Attendees: AlexG, ThaddeusL, Cristian, Dave, Richard, Jessica, Nitin, Song Release criteria review: Please see the wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_4https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status 1. All release criteria has been reviewed. M4 met all the criteria. 2. Highlights: a. 12% performance increase on overall build time. Cut the rootfs build time with sstate on by half. 3. Issues: a. The # of bugs seems high. Plan: Bug triage team is doing a round of triage for all medium+ and medium bugs to focus the team on fixing the right set of bugs. The team will focus more on bugs for the rest of the release. b. Dave: not enough CCB members present in this meeting. Cannot approve the release. Decision: Song will follow up with Dave and the CCB to get approval for the release. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beaglebone build no uImage on DOS partition.
Edward,
Yes, you do need of course a uImage which is the Linux kernel image with
the necessary wrapper for u-boot. If you do not have one after your build
finishes in path-to-build-env/tmp/deploy/images then building the Linux
kernel failed and you should look for error messages.
To build just the kernel you can run
MACHINE=beaglebone bitbake virtual/kernel -vDD
It seems that inside your build environment you are mixing builds for
BeagleBone and PandaBoard. You need to pay attention to that since the
BeagleBone uses a TI Sitara AM335x SoC and the PandaBoard a TI OMAP4430
SoC. They are both ARM but substantially different.
Rudi
On Fri, Mar 1, 2013 at 8:12 AM, Edward Vidal vidal.devel...@gmail.comwrote:
Hello,
Any and all help will be appreciated.
yocto beaglebone build no uImage to DOS partition.
My questions are do you need the a uImage on DOS partition and should you
use core-image-sato-sdk with the beaglebone since it has no display on
board, but you want the SDK? My beaglebone booted okay but I did see that
the xserver failed. My pandaboard build is failing currently but I have
had successful builds in the past in early Jan with same process outlined
below.
Downloaded both poky and meta-ti
cd /home/vidal/POKY/build022813_panda
git clone git://git.yoctoproject.org/poky.git
cd /home/vidal/POKY/build022813_panda/poky
git log
commit d7b248e715d99766bf8602ff9f038f8b0afa5e78
Author: Constantin Musca constantinx.mu...@intel.com
Date: Mon Feb 25 17:29:15 2013 +0200
cd /home/vidal/POKY/build022813_panda/poky
git clone git://git.yoctoproject.org/meta-ti
git log
commit 4d99e63181c6f58b5bb41eb830c7af75b097e10e
Author: Franklin S. Cooper Jr fcoo...@ti.com
Date: Mon Feb 18 22:45:16 2013 -0600
Modifications to file
/home/vidal/POKY/build022813/poky/build/conf/local.conf
Added the following three lines at the beginning of the file.
MACHINE ?= beaglebone
MACHINE ?= pandaboard
BBMASK ?= .*/meta-ti/recipes-(misc|bsp/formfactor|graphics/mesa)/
Mofified the following 3 lines as shown below.
#BB_NUMBER_THREADS = 4 -- BB_NUMBER_THREADS = 8
#PARALLEL_MAKE = -j 4 -- PARALLEL_MAKE = -j 8
#DL_DIR ?= ${TOPDIR}/downloads -- DL_DIR ?=
/home/vidal/POKY/linux_src_dnloads_panda/downloads
Modification done to
/home/vidal/POKY/build022813/poky/build/conf/bblayers.conf
Added the line
/home/vidal/POKY/build022813_panda/poky/meta-ti \
After the line
/home/vidal/POKY/build022813_panda/poky/meta-yocto \
Built on Fedora 18 x86_64 system.
MACHINE=beaglebone bitbake core-image-sato-sdk -vDD
NOTE: recipe core-image-sato-sdk-1.0-r0: task do_rootfs: Succeeded
DEBUG: Marking task 12
(/home/vidal/POKY/build022813_panda/poky/meta/recipes-sato/images/
core-image-sato-sdk.bb, do_build) as buildable
DEBUG: Stampfile
/home/vidal/POKY/build022813_panda/poky/build/tmp/stamps/beaglebone-poky-linux-gnueabi/core-image-sato-sdk/1.0-r0.do_build.43a176d7b0f28fabd0275a4afba65cd3
not available
NOTE: Running noexec task 6534 of 6534 (ID: 12,
/home/vidal/POKY/build022813_panda/poky/meta/recipes-sato/images/
core-image-sato-sdk.bb, do_build)
NOTE: Tasks Summary: Attempted 6534 tasks of which 543 didn't need to be
rerun and all succeeded.
Build Configuration:
BB_VERSION= 1.17.1
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Unknown
TARGET_SYS= arm-poky-linux-gnueabi
MACHINE = beaglebone
DISTRO= poky
DISTRO_VERSION= 1.3+snapshot-20130228
TUNE_FEATURES = armv7a vfp neon
TARGET_FPU= vfp-neon
meta
meta-yocto= master:d7b248e715d99766bf8602ff9f038f8b0afa5e78
meta-ti = master:4d99e63181c6f58b5bb41eb830c7af75b097e10e
meta-yocto-bsp= master:d7b248e715d99766bf8602ff9f038f8b0afa5e78
Transferred the following files to boot partition from
/home/vidal/POKY/build022813_panda/poky/build/tmp/deploy/images/
MLO-beaglebone-2011.09+git* -- MLO
u-boot.img - u-boot-beaglebone-2011.09+git-r30.img* -- u-boot.img
Untarred the file
/home/vidal/POKY/build022813_panda/poky/build/tmp/deploy/images/core-image-sato-sdk-beaglebone-20130228230414.rootfs.tar.bz2
to /run/media/vidal/Angstrom
If anyone wants any additional information feel free to ask at
vidal.devel...@gmail.com or devel...@sbcglobal.net.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
--
*Rudolf J. Streif*
Director of Embedded Solutions
The Linux Foundation
rudolf.str...@linux.com
Phone: +1.619.631.5383
Skype: rudolfstreif
PGP: RSA 2048/2048 D6E7D28B
Linux Foundation Events Schedule: events.linuxfoundation.org
Linux Foundation Training Schedule: training.linuxfoundation.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 08:01:17PM +, Liu, Song wrote: Attendees: AlexG, ThaddeusL, Cristian, Dave, Richard, Jessica, Nitin, Song Release criteria review: Please see the wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_4https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status 1. All release criteria has been reviewed. M4 met all the criteria. 2. Highlights: a. 12% performance increase on overall build time. Cut the rootfs build time with sstate on by half. 3. Issues: a. The # of bugs seems high. Plan: Bug triage team is doing a round of triage for all medium+ and medium bugs to focus the team on fixing the right set of bugs. The team will focus more on bugs for the rest of the release. b. Dave: not enough CCB members present in this meeting. Cannot approve the release. Decision: Song will follow up with Dave and the CCB to get approval for the release. I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. meta-systemd is broken for month so people cannot even test it with current master and couple of important meta-oe developers are against changing meta-systemd so it gets compatible with current oe-core but breaks their use-case and also there is no plan for upgrade path from danny+meta-systemd to Yocto-Project_v1.4 release. Stalling that discussion till milestone 5 or 6 won't help resolving it to work for everybody. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Missing GDB thread debugging?
I'm trying to run GDB on my target. When I run my program (actually the Python interpreter) I get this error: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. I seem to have that library installed: # ls /lib/libthread_db* -l -rwxr-xr-x 1 root root 26356 Feb 14 01:42 /lib/libthread_db-1.0.so lrwxrwxrwx 1 root root19 Feb 28 17:53 /lib/libthread_db.so.1 - libthread_db-1.0.so Which came from: # opkg search /lib/libthread_db.so.1 libthread-db1 - 2.16-r20 How can I get thread debugging to work on my target? n.b. my target is a clone of the OMAP44xx PandaBoard. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On 1 March 2013 21:53, Martin Jansa martin.ja...@gmail.com wrote: I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. I'm working on a series that implements roughly what I proposed (systemd and sysvinit features not mutually exclusive, but no separate -sysv or -systemd packages) and hope to have it on the list next week - this week has been slow going as we've had a family cold do the rounds. Any contributions of coding are always welcome, obviously. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 11:08:30PM +, Burton, Ross wrote: On 1 March 2013 21:53, Martin Jansa martin.ja...@gmail.com wrote: I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. I'm working on a series that implements roughly what I proposed (systemd and sysvinit features not mutually exclusive, but no separate -sysv or -systemd packages) and hope to have it on the list next week - this week has been slow going as we've had a family cold do the rounds. Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Any contributions of coding are always welcome, obviously. Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On 1 March 2013 23:32, Martin Jansa martin.ja...@gmail.com wrote: Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Having split packages can break the upgrade path - say your distro goes from sysvinit to sysvinit rescue + systemd main. How does your foo-daemon package get the right init script package on upgrade? I proposed a solution for distributions that care - inject the migration path dependencies though meta-systemd. I still maintain that oe-core shouldn't have to bend over backwards to maintain compatibility with every recipe that migrates. Obviously we don't want to deliberately break where we have a choice but equally so Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. The advantage of having init scripts in the daemon package is simplicity. For the cost of two init scripts (what, 1K between them?) you remove lots of complexity, including the upgrade path breakage I described above. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 11:56:32PM +, Burton, Ross wrote: On 1 March 2013 23:32, Martin Jansa martin.ja...@gmail.com wrote: Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Having split packages can break the upgrade path - say your distro goes from sysvinit to sysvinit rescue + systemd main. How does your foo-daemon package get the right init script package on upgrade? By right RRECOMMENDS like meta-systemd did. Plus simple way to exclude some at image creation time with BAD_RECOMMENDATION or explicit entries pulled with packagegroup for each type of image. I proposed a solution for distributions that care - inject the migration path dependencies though meta-systemd. I still maintain that oe-core shouldn't have to bend over backwards to maintain compatibility with every recipe that migrates. Obviously we don't want to deliberately break where we have a choice but equally so http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036222.html Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. The advantage of having init scripts in the daemon package is simplicity. For the cost of two init scripts (what, 1K between them?) you remove lots of complexity, including the upgrade path breakage I described above. There is no upgrade path breakage and complexity is in postinst scripts which need to support both update-rc.d and systemctl calls. Lets discuss this in that oe-core thread so that other people not subscribed to yocto ML can also comment. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 0/2] NTB IOATDMA features for v3.8 kernel repo
From: Nitin A Kamble nitin.a.kam...@intel.com Hi Bruce, I have prepared commits for enabling non-transparent-bridge and Crystal-Beach-DMA/DCA drivers in the kernel. This is needed to implement features in this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2465 I have created a new ntb git branch for the ntb feature. The branch is pushed here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ntb As it is a new branch for kernel repo, I am not sending individual commits over ML. You can directly fetch the ntb branch in the v3.8 repo. And new features for ioatdma (aka Crystal Beach DMA/DCA) ntb (non transparent bridge) are created in the meta branch over here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta Thanks, Nitin The following changes since commit c2ed0f16fdec628242a682897d5d86df4547cf24: checkpoint dir: meta (2013-02-24 22:43:59 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta Nitin A Kamble (2): new feature for non-transparent-bridge driver new feature for I/OAT DMA driver meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg |1 + meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc |1 + meta/cfg/kernel-cache/features/ntb/ntb.cfg |1 + meta/cfg/kernel-cache/features/ntb/ntb.scc |2 ++ 4 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.cfg create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.scc -- 1.7.3.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] new feature for I/OAT DMA driver
From: Nitin A Kamble nitin.a.kam...@intel.com This commit implements a new ioatdma feature by providing a config fragment to enable Crystal Forest DMA/DCA (ioatdma) driver configuration for BSP kernels. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg |1 + meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc |1 + 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc diff --git a/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg new file mode 100644 index 000..b62aab2 --- /dev/null +++ b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg @@ -0,0 +1 @@ +CONFIG_INTEL_IOATDMA=y diff --git a/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc new file mode 100644 index 000..f1951a6 --- /dev/null +++ b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc @@ -0,0 +1 @@ +kconf hardware ioatdma.cfg -- 1.7.3.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/2] NTB IOATDMA features for v3.8 kernel repo
On 13-03-01 8:05 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com Hi Bruce, I have prepared commits for enabling non-transparent-bridge and Crystal-Beach-DMA/DCA drivers in the kernel. This is needed to implement features in this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2465 I have created a new ntb git branch for the ntb feature. The branch is pushed here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ntb As it is a new branch for kernel repo, I am not sending individual commits over ML. You can directly fetch the ntb branch in the v3.8 repo. And new features for ioatdma (aka Crystal Beach DMA/DCA) ntb (non transparent bridge) are created in the meta branch over here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta Nitin, In general this looks pretty good. I've been tracking NTB development for quite some time, so luckily I'm aware of the challenges working with the feature. Just a few questions. - I assume this has passed build tests ? - Who's doing the NTB runtime testing ? I've seen this code in the past, and while it builds relatively easily .. getting it tested is more of a challenge. And a request .. I realize that this wouldn't have been obvious when you were working on this, but that's what the mailing list review is for! This feature in particular shouldn't be staged as a branch and merged, so just set it up as a .scc file (as you have it) without the patches. If you want the patches to be applied whenever ntb-common.scc is included, let me know and that's where I'll place them. I'll then merge these changes to the standard/base branch to make them available to all BSPs. You are probably wondering why it shouldn't be a topic branch and merged. The reason comes down to the fact that it will conflict with both mainline development and BSP work. This is an active area of development (and hence bug fixing as well), so the chances of a topic branch conflicting and failing to merge are high. I'll need to resolve those conflicts in tree while stacking patches, I can't do that with a topic branch. Features that usually get a topic branch are: - features that are largely developed out of tree - features that are orthogonal to other code in the tree, and don't touch many common files - features that may have active development, where we want to track the history separately (versus patch based history) or we want to track a significant amount of commits. - features that will update/upgrade and migrate over time. - just because :) With that set of criteria, things like graphics drivers (emgd, or schedulers (EDF)) get topic branches. But other features like preempt-rt (it will always conflict) or lttng-1.x don't get topic branches. And that's why ntb really shouldn't have one either. IF we have to many topic branches, we'll end up with patch time merge failures of the topic branches .. which are difficult to resolve. It should be a simple thing to re-order (since the content is all largely the same) .. and will take less time that I did typing all this up :) Cheers, Bruce Thanks, Nitin The following changes since commit c2ed0f16fdec628242a682897d5d86df4547cf24: checkpoint dir: meta (2013-02-24 22:43:59 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta Nitin A Kamble (2): new feature for non-transparent-bridge driver new feature for I/OAT DMA driver meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg |1 + meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc |1 + meta/cfg/kernel-cache/features/ntb/ntb.cfg |1 + meta/cfg/kernel-cache/features/ntb/ntb.scc |2 ++ 4 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.cfg create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.scc ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
