Re: [yocto] Yocto newbie: Need help with recipe

[Rudolf Streif]

Hi Berthold,

Welcome to the Yocto Project.

This line is the problem with your recipe:

PACKAGES = "${PN}"

This tells the build system to only create one package, the default
package. Because this line FILES_${PN} = "${bindir}" tells the build system
to include everything in ${bindir} into that package the package also
includes the .debug directory which is then flagged by the QA checker. To
fix this:

PACKAGES = "${PN}-dbg ${PN}"

You have to specify the debug package before the default package as the
variable is processed from left to right and whatever is consumed by a
package will not be packaged anymore. However, even simpler is to remove
the PACKAGES line altogether as the default already does it correctly.

Best regards,
:rjs



On Thu, Nov 7, 2019 at 12:04 PM Berthold Höllmann <
berthold-yocto@höllmanns.de> wrote:

>
> Hello,
>
> I'm trying my way around yocto. I thought I try adding a small project
> of mine to a Raspberry Pi image as a first try in writing recipes. At
> least I managed to get the project compiling, but the generation of the
> packages is failing:
>
> $ bitbake  qtlissajous
> ...
> ERROR: qtlissajous-git-r0 do_package_qa: QA Issue: non debug package
> contains .debug directory: qtlissajous path
> /work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/qtlissajous/git-r0/packages-split/qtlissajous/usr/bin/.debug/lissajous_explorer
> [debug-files]
> ERROR: qtlissajous-git-r0 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
> ERROR: qtlissajous-git-r0 do_package_qa:
> ERROR: qtlissajous-git-r0 do_package_qa: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /home/build/shared/rpi/rpi2-build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/qtlissajous/git-r0/temp/log.do_package_qa.4823
> ERROR: Task
> (/home/build/shared/rpi/meta-qtlissajous/recipes-qtlissajous/qtlissajous/qtlissajous_git.bb:do_package_qa)
> failed with exit code '1'
> ...
>
> $ (cd
> /home/build/shared/rpi/rpi2-build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/qtlissajous/git-r0/packages-split/;find
> -type f)
>
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/build/moc_doubleslider.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/build/moc_phaselabel.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/doubleslider.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/doubleslider.h
>
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/lissajous_explorer.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/lissajous_explorer.h
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/lissajous_grid.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/lissajous_grid.h
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/main.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.cpp
> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.h
> ./qtlissajous-tools/usr/bin/lissajous_explorer
> ./qtlissajous/usr/bin/.debug/lissajous_explorer
> ./qtlissajous-tools.shlibdeps
>
> My qtlissajous_git.gg file is:
>
> ---
> DESCRIPTION = "Explore Lissajous figures for Raspberry Pi"
> SECTION = "games"
> DEPENDS += "qtbase"
>
> PACKAGES = "${PN}"
>
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://LICENSE;md5=7e26fc87b2c255632232dc535ed2700b;sha256=c8ea5a5ce0ef734ec1d0be3e214bed71673f1ffc628fe86bbd055d61abd52cc8"
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> SRCREV = "${AUTOREV}"
> SRC_URI = "git://gitlab.com/bhoel/qlissajousexplorer.git;protocol=https"
>
> S = "${WORKDIR}/git"
>
> require recipes-qt/qt5/qt5.inc
>
> FILES_${PN} = "${bindir}"
> FILES_${PN}-dbg += "${bindir}/.debug"
>
> do_install() {
>   install -d ${D}/usr/bin
>   install -m 0755 lissajous_explorer ${D}/usr/bin
> }
>
> RDEPENDS_${PN} = "qtbase-plugins"
> ---
>
> Why is the release executable ending up in the tools tree?
> Why is the debug executable ending up in the release tree?
> Is this the right place to ask this kind of questions?
>
> Thank you
> Berthold
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Rudolf J Streif
CEO/CTO
ibeeto, Streif Enterprises Inc.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running Yocto inside Docker

[Rudolf Streif]

That's more of a Gitlab than Yocto question. I am doing this all the time
with my GL server on AWS. You need to add deploy a key to the repo you want
to access and then push the key to your Docker instance from gitlab-ci.yaml
from the repo that you are using with GL CI.

:rjs

On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri 
wrote:

> Hi all,
>
> does anyone have a guide on how to setup Yocto to run inside docker? Right
> now I managed to trigger the build from GitLab, but I'm facing an issue
> related to ssh keys (some recipes from my meta layer are hosted on a
> privare repository). Probably this is not the best mailing list to ask this
> kind of question, but it may worth a try.
>
> Thank you,
> Gabriele
> --
> ___
> 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] problem adding a user

[Rudolf Streif]

Greg,

It eluded me earlier but in both instances the variable containing the
password does not seem to be expanded.

First version without the single quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:

NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p sakura]

and with the quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:
NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p '' sakura]

It looks as if the variable SAKURA_PASS is not set at all. I looked at
your scribe.bb recipe you attached earlier but I could not find any
reason why the variable is not set. Is there a chance that it is
overridden somewhere elase?

:rjs


On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
wrote:

> Rudolf,
>
> Here is the first half of the file,  the whole file is over the 500k limit
> of free pastebin:
>
> https://pastebin.com/UcnKebce
>
>
> And here is the 2nd half of the file:
>
> https://pastebin.com/9117tdUU
>
>
> Greg
> --
> *From:* Rudolf Streif 
> *Sent:* Wednesday, May 22, 2019 12:42:40 PM
> *To:* Greg Wilson-Lindberg
> *Cc:* Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
> Greg,
> Can you share the logfile via Pastebin?
> :rjs
>
> On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg <
> gwil...@sakuraus.com> wrote:
>
>> Rudolf,
>>
>> Something else is happening to me. I changed to this in the image recipe:
>>
>> SAKURA_USER = "sakura"
>>
>> SAKURA_PASSWD = "Distracted"
>> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>>
>> EXTRA_USERS_PARAMS = "\
>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
>> usermod -a -G sudo,dialout ${SAKURA_USER}; \
>> "
>>
>> deleting all of the commented out lines, and I get this in the log file:
>>
>>
>> /scribe/1.0-r0/rootfs -p '' sakura]
>>
>>
>> nothing between the single quotes. It's acting like SAKURA_PASS is not
>> defined.
>>
>> This is only happening when I'm trying the MD5 password.
>>
>>
>> Greg
>> --
>> *From:* Rudolf Streif 
>> *Sent:* Tuesday, May 21, 2019 5:37:23 AM
>> *To:* Greg Wilson-Lindberg
>> *Cc:* Yocto list discussion
>> *Subject:* Re: [yocto] problem adding a user
>>
>> Greg,
>>
>> usermod does not work for the MD5 algorithm with the explicit password
>> hash as it contains the $ field delimiters which are interpreted by the
>> shell executing the usermod command. Use single quotes around the password
>> hash:
>>
>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
>>
>> :rjs
>>
>> On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
>> wrote:
>>
>>> Hi Rudolf,
>>>
>>> I've had more time to work with this and I'm still having problems getting
>>> everything to work properly. I've attached the image recipe recipe that I'm
>>> using so I don't leave any thing out that may be relevant.
>>>
>>> When I build with a password that is no more more than 8 characters long
>>> and no non-alphabetic characters:
>>>
>>> SAKURA_PASSWD = "Distract"
>>> SAKURA_PASS = "WRsDFfg1BsrDM"
>>>
>>> everything works correctly.
>>>
>>> I first tried that using the `openssl ...` form, and then I tried the
>>> -1, MD5 BSD form and had problems, so I changed to doing the openssl
>>> on the command line and making sure that I don't have any characters
>>> that display as '.' or '/'. Again, if I don't do more than 8 characters
>>> and no special characters everything works.
>>>
>>> When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
>>> and the log file shows the usermod being exectued correctly:
>>>
>>> NOTE: scribe: Performing usermod with [-R 
>>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>>  -p kyNsrvS0elMWU sakura]
>>> NOTE: scribe: Performing usermod wi

Re: [yocto] problem adding a user

[Rudolf Streif]

Greg,
Can you share the logfile via Pastebin?
:rjs

On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg 
wrote:

> Rudolf,
>
> Something else is happening to me. I changed to this in the image recipe:
>
> SAKURA_USER = "sakura"
>
> SAKURA_PASSWD = "Distracted"
> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>
> EXTRA_USERS_PARAMS = "\
> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
> usermod -a -G sudo,dialout ${SAKURA_USER}; \
> "
>
> deleting all of the commented out lines, and I get this in the log file:
>
>
> /scribe/1.0-r0/rootfs -p '' sakura]
>
>
> nothing between the single quotes. It's acting like SAKURA_PASS is not
> defined.
>
> This is only happening when I'm trying the MD5 password.
>
>
> Greg
> --
> *From:* Rudolf Streif 
> *Sent:* Tuesday, May 21, 2019 5:37:23 AM
> *To:* Greg Wilson-Lindberg
> *Cc:* Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
> Greg,
>
> usermod does not work for the MD5 algorithm with the explicit password
> hash as it contains the $ field delimiters which are interpreted by the
> shell executing the usermod command. Use single quotes around the password
> hash:
>
> usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
>
> :rjs
>
> On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
> wrote:
>
>> Hi Rudolf,
>>
>> I've had more time to work with this and I'm still having problems getting
>> everything to work properly. I've attached the image recipe recipe that I'm
>> using so I don't leave any thing out that may be relevant.
>>
>> When I build with a password that is no more more than 8 characters long
>> and no non-alphabetic characters:
>>
>> SAKURA_PASSWD = "Distract"
>> SAKURA_PASS = "WRsDFfg1BsrDM"
>>
>> everything works correctly.
>>
>> I first tried that using the `openssl ...` form, and then I tried the
>> -1, MD5 BSD form and had problems, so I changed to doing the openssl
>> on the command line and making sure that I don't have any characters
>> that display as '.' or '/'. Again, if I don't do more than 8 characters
>> and no special characters everything works.
>>
>> When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
>> and the log file shows the usermod being exectued correctly:
>>
>> NOTE: scribe: Performing usermod with [-R 
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>  -p kyNsrvS0elMWU sakura]
>> NOTE: scribe: Performing usermod with [-R 
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>  -a -G sudo,dialout sakura]
>>
>> But when I try to sign in it doesn't work.
>>
>> I then tried the 10 character password 'Distracted', the build fails:
>>
>> NOTE: scribe: Performing usermod with [-R 
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>  -p sakura]
>> Usage: usermod [options] LOGIN
>>
>> Options:
>>   -c, --comment COMMENT new value of the GECOS field
>>   -d, --home HOME_DIR   new home directory for the user account
>>   -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
>>   -f, --inactive INACTIVE   set password inactive after expiration
>> to INACTIVE
>>   -g, --gid GROUP   force use GROUP as new primary group
>>   -G, --groups GROUPS   new list of supplementary GROUPS
>>   -a, --append  append the user to the supplemental GROUPS
>> mentioned by the -G option without removing
>> him/her from other groups
>>   -h, --helpdisplay this help message and exit
>>   -l, --login NEW_LOGIN new value of the login name
>>   -L, --locklock the user account
>>   -m, --move-home   move contents of the home directory to the
>> new location (use only with -d)
>>   -o, --non-unique  allow using duplicate (non-unique) UID
>>   -p, --password PASSWORD   use encrypted password for the new password
>>   -P, --clear-password PASSWORD use clear password for the new password
>>   -R, --root CHROOT_DIR directory to chroot into
>>   -s, --shell SHELL new login shell for the user account
>>

Re: [yocto] problem adding a user

[Rudolf Streif]

Greg,

usermod does not work for the MD5 algorithm with the explicit password hash
as it contains the $ field delimiters which are interpreted by the shell
executing the usermod command. Use single quotes around the password hash:

usermod -p '${SAKURA_PASS}' ${SAKURA_USER};

:rjs

On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
wrote:

> Hi Rudolf,
>
> I've had more time to work with this and I'm still having problems getting
> everything to work properly. I've attached the image recipe recipe that I'm
> using so I don't leave any thing out that may be relevant.
>
> When I build with a password that is no more more than 8 characters long
> and no non-alphabetic characters:
>
> SAKURA_PASSWD = "Distract"
> SAKURA_PASS = "WRsDFfg1BsrDM"
>
> everything works correctly.
>
> I first tried that using the `openssl ...` form, and then I tried the
> -1, MD5 BSD form and had problems, so I changed to doing the openssl
> on the command line and making sure that I don't have any characters
> that display as '.' or '/'. Again, if I don't do more than 8 characters
> and no special characters everything works.
>
> When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
> and the log file shows the usermod being exectued correctly:
>
> NOTE: scribe: Performing usermod with [-R 
> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>  -p kyNsrvS0elMWU sakura]
> NOTE: scribe: Performing usermod with [-R 
> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>  -a -G sudo,dialout sakura]
>
> But when I try to sign in it doesn't work.
>
> I then tried the 10 character password 'Distracted', the build fails:
>
> NOTE: scribe: Performing usermod with [-R 
> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>  -p sakura]
> Usage: usermod [options] LOGIN
>
> Options:
>   -c, --comment COMMENT new value of the GECOS field
>   -d, --home HOME_DIR   new home directory for the user account
>   -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
>   -f, --inactive INACTIVE   set password inactive after expiration
> to INACTIVE
>   -g, --gid GROUP   force use GROUP as new primary group
>   -G, --groups GROUPS   new list of supplementary GROUPS
>   -a, --append  append the user to the supplemental GROUPS
> mentioned by the -G option without removing
> him/her from other groups
>   -h, --helpdisplay this help message and exit
>   -l, --login NEW_LOGIN new value of the login name
>   -L, --locklock the user account
>   -m, --move-home   move contents of the home directory to the
> new location (use only with -d)
>   -o, --non-unique  allow using duplicate (non-unique) UID
>   -p, --password PASSWORD   use encrypted password for the new password
>   -P, --clear-password PASSWORD use clear password for the new password
>   -R, --root CHROOT_DIR directory to chroot into
>   -s, --shell SHELL new login shell for the user account
>   -u, --uid UID new UID for the user account
>   -U, --unlock  unlock the user account
>   -v, --add-subuids FIRST-LAST  add range of subordinate uids
>   -V, --del-subuids FIRST-LAST  remove range of subordinate uids
>   -w, --add-subgids FIRST-LAST  add range of subordinate gids
>   -W, --del-subgids FIRST-LAST  remove range of subordinate gids
>
> ERROR: scribe: usermod command did not succeed.
>
> So, even though I'm putting in the openssl output:
> openssl passwd -1 "Distracted"
> $1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0
>
> that I get back from what should be a valid run of openssl, I don't see 
> anything
> from the password on the usermod command line:
>  "...linux-gnueabi/scribe/1.0-r0/rootfs -p sakura]"
>
> I don't understand why the short passwords and passing along the proper hash 
> works,
> but not the longer password.
>
> It also doesn't make sense that I can't put in the '$' & '@' characters and
> have them work.
>
> Any suggestions would be greatly appreciated.
>
> Greg
>
> --
> *From:* Rudolf Streif 
> *Sent:* Wednesday, May 15, 2019 4:58:26 PM
> *To:* Greg Wilson-Lindberg
> *Cc:* Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
> Glad to hear that it work

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf Streif]

Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics.

On Sat, May 18, 2019, 22:13 Khem Raj  wrote:

>
>
> On 5/16/19 9:01 AM, Andrei Gherzan wrote:
> > HI,
> >
> > On 16/05/2019 16.31, Rudolf J Streif wrote:
> >> I am trying to use the "official" RPi 7" touch display
> >> (https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
> >> with meta-raspberrypi (most recent from master). However, I cannot get
> >> it to work. As a matter of fact the display does not even show the GPU
> >> rainbow screen making me think that the GPU firmware packaged with
> >> meta-raspberrypi does not support the DSI display. It works just fine
> >> with the latest Raspbian release (screen and touch).
> >>
> >> I searched the web up and down but could not find anything. Maybe
> >> somebody has an idea? Wrong firmware (maybe cannot be distributed
> >> because of licensing...)?
> > Sadly we don't actively test display and other related toys so they
> > might be broken. Even so, I would be surprised if the DSI port doesn't
> > work. What is you final config.txt (pastebin it please)?
> >
>
> are you building 64bit or 32bit images ?
> are you using vc4grpahics or userland graphics ?
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem adding a user

[Rudolf Streif]

Glad to hear that it works now. I am planning on attending the YP DevDay.

:rjs

On Wed, May 15, 2019, 13:53 Greg Wilson-Lindberg 
wrote:

> Thank you very much, that got me back on the right path.
>
> Maybe I'll see you at the Yocto day at the Embedded Linux Conference.
>
> Regards,
>
> [image: cid:image001.png@01D35D7D.179A7510]
>
> *Greg Wilson-Lindberg  *
>
> *Principal Firmware Engineer | Sakura Finetek USA, Inc.  *
>
>
>
> 1750 W 214th Street | Torrance, CA 90501 | U.S.A.
>
> T: +1 310 783 5075
>
> F: +1 310 618 6902 | E: gwil...@sakuraus.com
>
> www.sakuraus.com
>
>
>
> [image: cid:image002.png@01D35D7D.179A7510]
>
> [image: cid:image003.png@01D35D7D.179A7510]
> --
>
> Confidentiality Notice: This e-mail transmission may contain confidential
> or legally privileged information that is intended only for the individual
> or entity named in the e-mail address. If you are not the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution, or reliance upon the contents of this e-mail is strictly
> prohibited. If you have received this e-mail transmission in error, please
> reply to the sender, so that Sakura Finetek USA, Inc. can arrange for
> proper delivery, and then please delete the message from your inbox. Thank
> you.
>
>
>
>
>
> *From:* Rudolf J Streif [mailto:rudolf.str...@ibeeto.com]
> *Sent:* Wednesday, May 15, 2019 01:30 PM
> *To:* Greg Wilson-Lindberg ; Yocto list discussion <
> yocto@yoctoproject.org>
> *Subject:* Re: [yocto] problem adding a user
>
>
>
> Instead of
>
>
>
> useradd -p `openssl passwd test` sakura
>
>
>
> which attempts to add the user and set the password which fails if the
> user already exists, use
>
>
>
> usermod -p `openssl passwd test` sakura
>
>
>
> which sets the user's password.
>
>
>
> :rjs
>
>
>
> On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote:
>
> Ok, I had been using the useradd class in a couple of other recipes to
> allow me to copy files to the sakura user directory and another location,
> but owned by sakura. That seems to have been what was causing the problem.
>
>
>
> I had been using the extrausers class in my top level image recipe.
>
>
> So now how do I get all of this to work together? Do I need to put
> everything that touches the sakura user in the same recipe? It seems that I
> need to use only one of the useradd or extrausers classes?
>
>
>
> Greg
> --
>
> *From:* Rudolf J Streif 
> 
> *Sent:* Wednesday, May 15, 2019 12:31 PM
> *To:* Greg Wilson-Lindberg; Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
>
>
> The ! for the password in /etc/shadow indicates that the account is
> disabled:
>
> sakura:!:18031:0:9:7:::
>
>
>
> Either there is something wrong with the password generation or it gets
> disabled by something else. Maybe it's worth trying with a plain image
> without Boot2Qt or anything else.
>
>
>
> :rjs
>
>
>
>
>
> On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:
>
> Hi Rudolf,
>
> 1st, yes I inherit extrausers. Attached are the passwd & shadow files.
>
>
>
> It shouldn't make any difference, but I'm building this for an RPi3 using
> the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.
>
>
>
> Greg
> --
>
> *From:* Rudolf J Streif 
> 
> *Sent:* Wednesday, May 15, 2019 11:26 AM
> *To:* Greg Wilson-Lindberg; Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
>
>
> Hi Greg,
>
>
>
> > I've also tried both the back-quote and the single-quote, no difference.
>
>
>
> Help me to understand this. the back-quotes are the right ones. If you use
> the single ones your password in the /etc/shadow ends up being 'openssl
> passwd test' (without the quotes), unless the build fails because of a
> parsing error (I have not tried it). Silly question, you did inherit
> extrausers class?
>
>
>
> Can you post your /etc/passwd and /etc/shadow
>
>
>
> I am surprised that this does not work with your setup. I have been doing
> this a gazillion times always with success.
>
>
>
> :rjs
>
>
>
>
>
>
>
> On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:
>
> Hi Rudolf,
>
> Thanks for the reply, and the information on how openssl works.
>
>
>
> I'm trying to create a user with the same group name so the code that I'm
> using reduces to:
>
> EXTRA_USERS_PARAMS = "\
>
> useradd -p `openssl passwd test` sakura; \
>
> usermod -a -G sudo ${SAKURA_USER}; \
>
> "
>
> I also, as you can see, removed the macros to eliminate as much confusion
> as possible.
>
>
>
> I still can't login in using the password 'test'.
>
>
>
> I've also tried both the back-quote and the single-quote, no difference.
>
> Regards,
>
>
>
> Greg
> --
>
> *From:* Rudolf J Streif 
> 
> *Sent:* Wednesday, May 15, 2019 10:07:47 AM
> *To:* Greg Wilson-Lindberg; Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
>
>
> Hi Greg,
>
> Well, I suppose I wrote the book you are referring to...

Re: [yocto] Setting up a password for the root user

[Rudolf Streif]

For security it is best to disable console login for root and all users
altogether and use ssh with keys. If you are building many devices you
would want to provision each of them with unique keys.

:rjs


On Sat, Jan 12, 2019, 04:42 Stefano Cappa  From a security point of view, Is it better to use  "usermod -p `openssl
> passwd mypass` root; \" or with uppercase P "usermod -P mypass root; \" ?
>
>
> Il giorno sab 12 gen 2019 alle ore 04:38 Rudolf J Streif <
> rudolf.str...@ibeeto.com> ha scritto:
>
>> Alberto,
>>
>> The quotes around
>>
>> `openssl passwd ${ROOT_PASSWORD}`
>>
>> have to be backticks (`) not single quotes (').
>>
>> :rjs
>>
>> On 01/11/2019 07:41 AM, Alberto Spin wrote:
>>
>> Hello There,
>>
>>
>>
>> I’m trying to set a password for the root user of my distribution (based
>> rocko branch)
>>
>>
>>
>> I’ve added the following to my image recipe:
>>
>>
>>
>> inherit extrausers
>>
>>
>>
>> # set image root password
>>
>> ROOT_PASSWORD = "secret"
>>
>>
>>
>> EXTRA_USERS_PARAMS = "\
>>
>> usermod -p 'openssl passwd ${ROOT_PASSWORD}' root; \
>>
>> "
>>
>>
>>
>> Everything builds fine, but in my image I end up with a password in my
>> /etc/shadow file like this:
>>
>>
>>
>> openssl passwd secret
>>
>>
>>
>> so it seems like the openssl command has not been executed during the
>> build, but instead the literal command is now part of my password.
>>
>>
>>
>> Can anybody please explain what’s going on here, and how to fix this?
>>
>>
>>
>> Kind Regards,
>>
>>
>>
>> Alberto
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> ___
>> 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] Gratitude

[Rudolf Streif]

Jefro,

I am very sorry to see you go. I have very much enjoyed working with you
from the beginning while still at the Linux Foundation. I cannot express
enough gratitude for all the valuable work you have done for this community
and for me personally by diligently reviewing the book and giving me tips.

Thank you so much. You will be missed.

Rudi

On Tue, Jun 5, 2018 at 11:42 PM, Osier-mixon, Jeffrey <
jeffrey.osier-mi...@intel.com> wrote:

> I have been the Yocto Project community manager for over 7 years now, and
> have had the pleasure of knowing or conversing individually with several
> hundred of you. It is with mixed feelings that I must announce that I am
> stepping down from my position as the YP community manager and the Advisory
> Board chair after 7 years, as I am taking on a new role in my job.
>
> I am very proud of the progress that the project has made, growing from a
> small set of build tools into an industry standard for building and working
> with embedded Linux-based operating systems, supporting upstream projects
> including the Linux kernel, hosting projects like opkg, and inspiring many
> very successful downstream projects, including AGL and OpenBMC among many
> others, and also supporting countless configurations of hardware among
> seven different architectures. We have also seen the community of users
> grow from fewer than 1000 in 2010 to a large city-sized community,
> estimated in the tens of thousands of developers.
>
> Please continue to participate, collaborate, and come together as a
> community! The Yocto Project is a success because every one of you
> participates.
>
> Jeffrey "Jefro" Osier-Mixon, Intel Corporation
> Open Source Community Ecosystem Strategist
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
*Rudolf J. Streif*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compilation error

[Rudolf Streif]

What recipe? Ideally you want to fix the code and add the function
declaration.

Kind regards,
Rudolf J Streif

On Sep 12, 2016 6:26 PM, "Vijayakumar Badiger" 
wrote:

> Hello All,
>
> I am getting an compilation error like below. Can you pls let me know how
> to fix this one. Thanks in advance.
>
>
>
>  error: implicit declaration of function 'close'
> [-Werror=implicit-function-declaration]
> | close(fd);
>
> Cheers,
> Vijay
>
> --
> ___
> 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] [Devtool] RPM Source Package

[Rudolf Streif]

Devtool works reasonably well with repos and packaged source tarballs. We
did a test with a source RPM which resulted in a simple stub recipe
although the source rpm contained an autotooled package. devtool did not
even make an attempt to unpack the source RPM into the workspace and
analyze the code.

Are there any plans or a roadmap for devtool to support source RPMs? When
Tizen moved from OBS to YP the developers created a Python script [1] to
convert an OBS spec file to a YP recipe. A possible starting point.

Cheers,
:rjs



[1]
https://review.tizen.org/git/?p=scm/bb/tizen.git;a=blob;f=tools/spec2yocto.py;h=90ff2b064e8cabff25987c3c9a9fd59a04550495;hb=HEAD
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Customize login prompt text in Yocto

[Rudolf Streif]

>
> the information shown is from the file /etc/issue. You can for example do
> post-processing on this file and change the information. You can add this
> to your image recipe.
>
> update_issue() {
> echo "Your text" > ${IMAGE_ROOTFS}/etc/issue
> }
>
> ROOTFS_POSTPROCESS_COMMAND += " update issue; "
>


The more "yoctonic" way of setting this is to modify the DISTRO_NAME
variable, which is set in the distro configuration file e.g. poky.conf. If
you are building your own distro it you may want to derive your own distro
configuration file from the ones that Poky provides. There you can also set
other variables such as DISTRO_VERSION, MAINTAINER, etc.

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding Demo Utilities to /proc

[Rudolf Streif]

Hi Haleigh,

This is your clue

>/bin/sh: lzop: command not found

You need to install it on your dev box, e.g. for Ubuntu

sudo apt-get install lzop

Cheers,
Rudi

Hello All,


Firstly I would like to say that I am new here and fairly new to Yocto, so
I do apologize if this is the wrong board for this question. (And if it is
could someone direct me to the correct board?) Background on me: graduated
OSU before Fall 2015 started with a BA Computer Science Computer Systems
- minimal yocto ~2 months baby level stuff.


Some background on the issue: I am following these directions
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-11-adding-proc-files-your-modules-part-1
to create a jiffies utility  folder in /proc as a precursor to a larger
project. I have made the appropriate changes within the
/usr/src/kernel/fs/proc folder and now I am trying to compile and load the
module, to place a jiffies entry in /proc. Well when I run 'make' from
/usr/src/kernel/ I get most of the way through, way past building my
jiffies.o file in user/src/kernel/fs/proc, without errors but toward the
end I get the following error.


LZO arch/arm/boot/compressed/piggy.lzo
/bin/sh: lzop: command not found
/usr/src/kernel/arch/arm/boot/compressed/Makefile:193: recipe for target
'arch/arm/boot/compressed/piggy.lzo' failed
make[2]: *** [arch/arm/boot/compressed/piggy.lzo] Error 1
/usr/src/kernel/arch/arm/boot/Makefile:52: recipe for target
'arch/arm/boot/compressed/vmlinux' failed
make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
/usr/src/kernel/arch/arm/Makefile:305: recipe for target 'zImage' failed
make: *** [zImage] Error 2

I had not though to try to 'make' in this manner before I attempted this
project so I don't know if this worked originally. My yocto build is
located on one host machine and the actual implementation / working area is
on another with an arm processor. I ssh into my device that the yocto build
is for and from there I work with the code. If I try to 'make' on the host
machine I get an error that it can not find/access some generated files so
 hat option I think is out and googling only resulted in that type of
solution one to be done on my host machine.

Has anyone ever had this problem before or could point me in a better
direction?

Thank you.

H

--
___
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] Problems building live image

[Rudolf Streif]

Richard,

On Mon, Mar 14, 2016 at 1:55 PM, K Richard Pixley  wrote:

> If I add that line, (
>
> IMAGE_FSTYPES = "vmdk"
>
> ), to my local.conf, I get:
>
> rich@burgess> time bitbake core-image-minimal
> ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the
> checker (see sanity.conf).
> Following is the list of potential problems / advisories:
>
> Error, IMAGE_FSTYPES vmdk and live can't be built together
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> Building yocto-2.0 for genericx86-64.  What am I doing wrong?
>
> Nothing really. The issue is conflicting SYSLINUX_LABELS for the boot
options. For the live image the labels are boot and install while there is
only boot for the vmdk image. Prior to 2.0 Jethro you could specify both,
live and vmdk, in IMAGE_FSTYPES. It built both but the live image was
missing the install boot option (it had two boot options instead). This
function in syslinux.bbclass now flags the issue:

# Some of the vars for vm and live image are conflicted, this function
# is used for fixing the problem.
def syslinux_set_vars(d, suffix):
   vars = ['SYSLINUX_ROOT', 'SYSLINUX_CFG', 'LABELS', 'INITRD']
   for var in vars:
   var_with_suffix = var + '_' + suffix
   if d.getVar(var, True):
   bb.warn('Found potential conflicted var %s, please use %s rather
than %s' % \
   (var, var_with_suffix, var))
   elif d.getVar(var_with_suffix, True):
   d.setVar(var, d.getVar(var_with_suffix, True))


 Technically, in my opinion, you should be able to build both at the same
time. You may want to disable the sanity checker.

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bbappend a "required" bb file

[Rudolf Streif]

>
> What are the rules with appending included recipes?
>
File inclusions with include or require are literal: the content of the
referenced file is inserted at the very position of the statement. The file
extension is irrelevant, meaning any appends to a recipe do not get
included.

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

[yocto] Unexpected behavior with custom Linux kernel build

[Rudolf Streif]

I am using this recipe to build a very latest kernel from kernel.org:


DESCRIPTION = Linux Kernel from Tarball
SECTION = kernel
LICENSE = GPLv2

inherit kernel

LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7

LINUX_VERSION ?= 4.2
LINUX_VERSION_EXTENSION ?= -custom
PR = rc1
PV = ${LINUX_VERSION}

SRC_URI = 
https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-${LINUX_VERSION}-${PR}.tar.xz;name=kernel

SRC_URI += file://defconfig

SRC_URI[kernel.md5sum] = 3e8331759af56ddd621528b2c7015ae1
SRC_URI[kernel.sha256sum] =
3c524ee0446b4ea8288708fa30acd28647317b9724f2d336052130e164c83f29

S = ${WORKDIR}/linux-${LINUX_VERSION}-${PR}

COMPATIBLE_MACHINE = qemux86|qemux86-64


Yes, that is the somewhat traditional method of building the kernel. The
kernel builds and works fine.

Now I would like to enable Yocto tooling for the kernel so that I can use
configuration fragments by adding

require recipes-kernel/linux/linux-yocto.inc

to the recipe. That worked just fine in the past. The kernel builds and
boots but then in userspace some unexpected things happen: avahi does not
start and login does not work. Reason being:

setgid: Function not implemeted

Why would that change in tooling cause this error?

Build Configuration:
BB_VERSION= 1.27.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Fedora-21
TARGET_SYS= x86_64-poky-linux
MACHINE   = qemux86-64
DISTRO= poky
DISTRO_VERSION= 1.8+snapshot-20150710
TUNE_FEATURES = m64 core2
TARGET_FPU= 
meta
meta-yocto
meta-yocto-bsp= master:20a3a36547831349d5d8b429cb35f1415a856bda


The effect is the same when using this recipe to build from kernel.org git
repo:


DESCRIPTION = Linux Kernel from kernel.org Git Repository
SECTION = kernel
LICENSE = GPLv2

require recipes-kernel/linux/linux-yocto.inc

LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7

LINUX_VERSION ?= 4.2
LINUX_VERSION_EXTENSION ?= -custom
PR = rc1
PV = ${LINUX_VERSION}+git${SRCPV}

SRC_URI = git://
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=machine

SRC_URI += file://defconfig

SRCREV_machine=d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754

COMPATIBLE_MACHINE = qemux86|qemux86-64


Thanks,
Rudi
-- 
*Rudolf J. Streif*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hob and Toaster Languages.

[Rudolf Streif]

Hi John,

Both are written in Python. Toaster is built on the Django Python web
framework (https://www.djangoproject.com/).

Cheers,
Rudi

On Wed, Nov 12, 2014 at 1:18 PM, John Unland opensourcejohn2...@gmail.com
wrote:

 What is Hob and Toaster written in? Figured I would like to contribute
 maybe a deployment tool when you have created a image (I know there is
 the deployment tool for Hob but it only works for .iso and .hddimg FS)

 Thanks,
 John
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto




-- 
*Rudolf J. Streif*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Linux Headers question

[Rudolf Streif]

Hi Ashish,

Which Yocto package has stdio.h file (and other header files)?

 That depends on what C library you are using. The default for YP/OE is
eglibc. The headers would be in eglibc-dev.


 I tried linux-libc-headers-dev and linux-libc-headers-dbg and I did not
 get the stdio.h file.

 I see a packages-split directory for eglibc-dev but I don't see an RPM
 being built for that (I have RPMs being built for every other build). Also
 I cannot do bitbake eglibc-dev.


The RPM would be libc6-dev-version.architecture.rpm, for
instance libc6-dev-2.19-r0.cortexa8hf_vfp_neon.rpm for an ARM Cortex A8
using hard fp.

Best regards,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a list of yocto-supported dev kits somewhere?

[Rudolf Streif]

I think this is a great idea and I volunteer to help with the effort.


   that is kinda what i was after. i realize it's an open-ended
 request, but it would be great if there was a list of recommended
 dev kits representing various architectures/processors that people new
 to YP could purchase for experimentation, *knowing* that those dev
 kits had a YP build that would work out of the box. not necessarily
 technically complete, but that it would just boot and let them start
 playing.


The work out of the box part is the tricky one. Unfortunately, many YP
BSP layers do not include instructions on what to do after the build has
completed. If you don't know what to do with boot loader and kernel images,
flattened device tree files, root file system archives and images then you
are at a loss. Commonly the boards also require a special boot media
partitioning and the like.

While this type of info should be in the BSP readme files I think it would
be good to have step by step instructions that gets one from setting up the
build environment to building and creating bootable media for each board.

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] best bet for WiFi Yocto experience?

[Rudolf Streif]

Hi Pete,


Please provide a recommendation for a low cost, out of the box WiFi
 (802.11n) experience using Yocto.

 Are you looking for a board that has WiFi on board? The Wandboard (
http://www.wandboard.org/) or the Cubietruck (
http://www.cubietruck.com/products/cubietruck-cubieboard3-cortex-a7-dual-core-2gb-ram-8gb-flash-with-wifi-bt-1)
have that for example.



 AFAIK, Raspberry Pi doesn't come with WiFi built in.

 Correct, but you could use a WiFi/BT USB dongle for a couple of bucks.


 I would like to spend less than $100 but could stretch it.

 Wandboard and Cubietruck are both less than $100.


Cheers,
:rjs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] distro.conf and LOCALCONF_VERSION, LAYER_CONF_VERSION, OELAYOUT_ABI

[Rudolf Streif]

The Poky distro configuration distro.conf includes assignments to
LOCALCONF_VERSION, LAYER_CONF_VERSION, OELAYOUT_ABI to set the expected
version numbers for local.conf, bblayers.conf and the directory layout of
${TMPDIR}.

From a user perspective this is somewhat confusing as these variables
really have nothing to do with the distro policy but only with the
compatibility between the build system and a build environment. For Poky it
may somewhat make sense to put them there. However if I write my own
distro.conf and put it in a layer I would want to use this layer with
different version of the build system. I think it would make more sense to
assign these variables in poky-sanity.bbclass.

The second little gripe is about the inconsistent naming of these variables
and the ones they relate to:

LOCALCONF_VERSION (expected value) - CONF_VERSION (actual value)
LAYER_CONF_VERSION (expected value) - LCONF_VERSION (actual value)
OELAYOUT_ABI (expected value) - actual value retrieved from
tmp/abi_version

Adding to the confusion is LAYERVERSION which refers to the version of the
conf/layer.conf file of a layer. That is in contrast to LAYER_CONF_VERSION
/ LCONF_VERSION which are for conf/bblayers.conf in the build enviroment.

Changing stuff that has been established for years is of course a pain but
it has been done and can be done in a backward compatible way.

My suggestions:

   1. Rename LOCALCONF_VERSION to LOCAL_CONF_VERSION_SET
   2. Rename LAYER_CONF_VERSION to BBLAYERS_CONF_VERSION_SET
   3. Rename CONF_VERSION to LOCAL_CONF_VERSION
   4. Rename LCONF_VERSION to BBLAYERS_CONF_VERSION
   5. Rename OELAYOUT_ABI to OELAYOUT_VERSION_SET
   6. Provide values for LOCAL_CONF_VERSION_SET, BBLAYERS_CONF_VERSION_SET,
   OELAYOUT_VERSION_SET in poky-sanity.bbclass and remove the settings from
   the distro configuration.

You would also want to change LAYERVERSION to LAYER_CONF_VERSION to be
consistent. But that cannot be done backwards compatible as it conflicts
with the currently used version variable for bblayers.conf.

These are small things that increase usability and help people to
understand the Yocto Project better.

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] No network at startup using core-image-minimal

[Rudolf Streif]

Hi Markus,

Please try core-image-base instead of core-image-minimal. That should
provide you with the necessary network support.

Best regards,
Rudi
On Aug 8, 2014 6:46 AM, Dr. Markus Eich markus.e...@dfki.de wrote:

 Dear all,

 I am setting up my Odroid XU with yocto using the core-image-minimal
 receipe. Almost done and I am able to boot the system and log in via screen
 (UART), but..

 The network is not present at start-up. When I do lsmod I just see Not
 tainted and no modules are loaded.

 The module I need to load is the smsc95xx module. When I tried to load the
 driver with modpobe it could not find the driver (although it is in
 /lib/modules/3.4.98-custom/kernel/drivers/net/usb)
 I had to manually add it to /lib/modules/3.4.98-custom/modules.dep (which
 was empty after the bitbake process in rootfs)

 So I added
 kernel/drivers/net/usb/smsc95xx.ko:  to modules.dep.

 Then I could load it with modprobe. In order to load it at startup

 I created a /etc/modules with the content smsc95xx. Now my question:

 Is there an easier (bitbake) way to make the modules load at startup
 without editing configs on the target device? Am I missing something? Does
 core-image-minimal not include network?

 Cheers,

 Markus




 --
 Dr.-Ing. Markus Eich

  Senior Researcher
  Marine Inspection Robotics
  Space Robotics
   Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
   Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.: +49 421 178 45-4105
  Zentrale: +49 421 178 45-0
  Fax:  +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   markus.e...@dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  ---
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:DE 148646973
  Steuernummer:  19/673/0060/3
  ---

 --
 ___
 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] dev manual definition of Image is totally wrong

[Rudolf Streif]

   here:


 http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms

 the definition of Image refers to the generated artifacts of a
 build, whereas the standard usage (as typified by the link) more
 correctly refers to things like core-image-minimal.


The term image is somewhat overloaded and if not detailed context
dependent. Image at least could be a kernel image or a root file system
image. In the context of YP the term typically refers to a root file
system image of which core-image-minimal is an instance.

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

[yocto] core-image-weston: do_rootfs failure installing libcogl

[Rudolf Streif]

I am attempting to build core-image-weston with Poky from Master. It fails
creating the rootfs when smart tries to install libcogl (details at the
end):

error: libcogl20-1.18.0-r0@i586 conflicts with
libcogl-path20-1.18.0-r0@i586

I have searched for this issue in Bugzilla and across the web. No luck. Is
that something anyone here knows about?

Thanks,
Rudi







Build Configuration:
BB_VERSION= 1.23.1
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Fedora-18
TARGET_SYS= i586-poky-linux
MACHINE   = qemux86
DISTRO= poky
DISTRO_VERSION= 1.6+snapshot-20140708
TUNE_FEATURES = m32 i586
TARGET_FPU= 
meta
meta-yocto
meta-yocto-bsp= master:a5531a2b8983318b99c119a87b78a92cf84160b8

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Unable to install packages. Command
'/run/media/rudi/SanDisk-256G/develop/yocto/yocto-git/x86/tmp/sysroots/x86_64-linux/usr/bin/smart
--data-dir=/run/media/rudi/SanDisk-256G/develop/yocto/yocto-git/x86/tmp/work/qemux86-poky-linux/core-image-weston/1.0-r0/rootfs/var/lib/smart
install -y packagegroup-core-ssh-dropbear@all psplash@i586
libclutter-1.0-examples@i586 packagegroup-base-extended@qemux86 smartpm@i586
packagegroup-core-tools-debug@qemux86 packagegroup-core-eclipse-debug@all
weston@i586 weston-init@all gtk+3-demo@i586 weston-examples@i586
packagegroup-core-sdk@all packagegroup-core-standalone-sdk-target@all
rpm@i586 packagegroup-core-boot@qemux86 locale-base-en-us@i586
locale-base-en-gb@i586' returned 1:
Loading cache...
Updating cache...   
[100%]

Computing transaction...error: Can't install libcogl-path20-1.18.0-r0@i586:
unable to install provider for libcogl20 = 1.18.0:
error: libcogl20-1.18.0-r0@i586 conflicts with
libcogl-path20-1.18.0-r0@i586


ERROR: Function failed: do_rootfs
E
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] MIPI for Intel E3800 Bay Trail

[Rudolf Streif]

This question is lesser a matter of YP but probably of upstream support.
Nevertheless, the YP kernel experts would certainly know. Which, if any, of
the YP kernels provide MIPI drivers for the Intel E3800?

Thanks,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] MIPI for Intel E3800 Bay Trail

[Rudolf Streif]

Søren,

Thank you for your response. Yes, Bay Trail is essentially supported
however I do not know if there are any MIPI drivers available for that
platform.

MIPI stands for the Mobile Industry Processor Interface. The standard is
created by the MIPI Alliance (http://www.mipi.org). Intel Bay Trail E3800
chips support it and so do Freescale i.MX6. The standard defines multiple
interfaces. In this case it's mostly about the camera interface.

Thanks,
Rudi


On Tue, Jul 8, 2014 at 2:56 PM, Søren Holm s...@sgh.dk wrote:


 I don't know what MIPI is but the Baytrail platform is supported from
 v3.13 as
 far as I remember.

 Tirsdag den 8. juli 2014 12:14:10 skrev Rudolf Streif:
  This question is lesser a matter of YP but probably of upstream support.
  Nevertheless, the YP kernel experts would certainly know. Which, if any,
 of
  the YP kernels provide MIPI drivers for the Intel E3800?
 
  Thanks,
  Rudi

 --
 Søren Holm

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

Re: [yocto] IMAGE_INSTALL

[Rudolf Streif]

Hi Bharath,

IMAGE_INSTALL +=  \

 coreutils \
 


You may want to post your entire recipe.


 in my image file. But, I do not see any coreutils package in tmp folder.
 Let me know if my understanding is wrong.


It should be in tmp/work/i586-poky-linux/coreutils/ if you are building for
x86.

Did you check your image too?


Best regards,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] core-image-weston: do_rootfs failure installing libcogl

[Rudolf Streif]

 Can you file a bug?



Thanks, Ross. Done. 6514
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] IMAGE_INSTALL

[Rudolf Streif]

Hi Barath,

That alone won't work. You can either quick and dirty add

IMAGE_INSTALL_append =  coreutils

to your conf/local.conf file or you write your recipe but it will need to
include another image recipe:


 DESCRIPTION = A test image for Gumstix boards.
 LICENSE = CLOSED

  require recipes-core/images/core-image-base.bb


 IMAGE_INSTALL +=  \
   coreutils \
 


then you can build your image with bitbake -k myimage given that you named
you recipe above myimage.bb

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

Re: [yocto] Understanding Package groups

[Rudolf Streif]

Hi Stefan,

You probably have found the explanation on package groups in the reference
manual [1].

Package groups are recipes with the sole purpose to create dependencies to
simplify image creation. A package group recipe bundles multiple packages
together and then instead of having to explicitly specify each package in
the IMAGE_INSTALL variable you can simply specify the package group name.

Package group recipes look like this (from the manual):

DESCRIPTION = My Custom Package Groups

 inherit packagegroup

 PACKAGES = \
 packagegroup-custom-apps \
 packagegroup-custom-tools \
 

 RDEPENDS_packagegroup-custom-apps = \
 dropbear \
 portmap \
 psplash

 RDEPENDS_packagegroup-custom-tools = \
 oprofile \
 oprofileui-server \
 lttng-control \
 lttng-viewer

 RRECOMMENDS_packagegroup-custom-tools = \
 kernel-module-oprofile



Like any recipe they have a description. They inherit the
packagegroup.bbclass. A package group recipe can define multiple package
groups in the PACKAGES variable. For each package group listed in PACKAGES
you will then need to specify the packages that actually go into them with
conditional RDEPENDS_packagegroupname variables.

Package groups are only relevant for the YP build system. They do not
create package grouping for the package manager that you are using for your
target. However, if you select a package group from HOB then all of the
packages specified in that group should be installed in your target's
rootfs by YP.

Rudi



[1]
http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks


On Tue, Jul 1, 2014 at 10:05 AM, Stefan Hofmann stefan.hofm...@mobserve.de
wrote:

 Hi,

 I made my first steps with yocto and everything worked fine so far. But
 now I am struggling with package groups. What I basically want, is a
 image for a base system, which allows me to install additional packages
 over the air with opkg. In my imagination package groups are something like
 preselected packages, which need to be installed at once similar like it is
 handled in Debian for X11-support for example. Is this right ? I have built
 core-image-base for testing purposes and tried to figure out the
 dependencies by using the Hob tool. It says that bash will be installed and
 the group base/shell is responsible for that. However it is not
 installed, only ash and I cannot find a package group
 package-group-base-shell in the receipes. It does however exist in the
 work directory. So now I am somewhat confused.

 Regards,
 Stefan

 --



 --
 ___
 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] how to specify if multiple bb files are existing

[Rudolf Streif]

Hi Insop,

Technically u-boot-fw-utils_2013.01.01 should be used because it's the
newer version. However, you can explicitly specify

PREFERRED_VERSION_u-boot-fw-utils = 2013.01.01

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is anyone giving a yocto talk at linuxcon in chicago in august?

[Rudolf Streif]

   i think that's what i'm going to submit. tomorrow's the submission
 deadline so i have to get something in quick. i figure i'll submit
 something like Building an Embedded Linux System Using YoctoProject,
 using the BeagleBone Black as the platform example.


 I have done a POC generating very small specific appliances using OE and
 lxc, in previous life which you then launch in thousands on demands on a
 big server to do specific jobs like subscriber connections etc. I think
 such a topic would definitely interest linuxcon attendees, I don't plan to
 attend this one but if someone wants to take this and develop into a talk I
 can help.


+1, a presentation like that would be more relevant (and more likely to be
accepted by the program committee) for LinuxCon than one that evolves
around the BeagleBone. That has a better fit for ELC.

It would also be a good opportunity that YP is not limited to embedded
devices.

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

Re: [yocto] is anyone giving a yocto talk at linuxcon in chicago in august?

[Rudolf Streif]

   i would think *someone* would be doing a yocto talk at linuxcon in
 august. if not, i'll propose one since i need an excuse to go. if one
 is already on the schedule, i'll propose something else.

 The typical target for YP (and the YP Dev Day) were the Embedded Linux
Conferences not that much the more general LinuxCon. However, during a
conversation at LinuxCon NA last year in NOLA I learned from a company that
they are using YP to build custom stacks for their cloud servers. From that
perspective having a YP talk at LCNA would actually be a good idea. A talk
how one could use YP to build your own desktop or server distro may be
interesting and extend the reach of the YP.

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

Re: [yocto] Question about remote debugging via gdbserver

[Rudolf Streif]

Hi Frederico,

Sorry for the delayed response.

If you want to step into code for which the debugger does not have the
source info Eclipse should actually tell you. But as a prerequisite you
will need to install the dev and debug packages for gstreamer (and
eventually others) to the root file system you are using on your
development host. For that you need to tell YP to include them which you do
by adding dev-pkg and dbg-pkg to EXTRA_IMAGE_INSTALL in the conf/local.conf
file of your build environment.

Rudi


On Fri, Apr 18, 2014 at 1:28 AM, Federico Vitali fede.vit...@gmail.comwrote:

 Goodmorning Rudolf,

 thank you again for your time.

 I have not explained my goal very well, so I try to explain with a
 specific example.
 I'm working with gstreamer for a project I'm following for my company.
 Let's take
 the gstreamer hello world application, here is the source code:


 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-helloworld.html#section-helloworld

 I've succesfully built and deployed the application. I can debug and
 follow the code of the application line
 by line with eclipse. Now, if I want to enter into a function of gstreamer
 libs (e.g. gst_pipeline_new),
 what should I have to do?

 Federico





 2014-04-16 21:22 GMT+02:00 Rudolf Streif rstr...@linuxfoundation.org:

 Hi Federico,

 I knew that I can add source paths to the debugger.

 Ok, if that's not the issue what exactly is not working for you?


 I see in your debug profiles that you have some binaries eg ls. Did
 you import that binary from sysrootfs on your build machine? Can you please
 tell me the steps before adding the path?

 No, that's actually sample code of a simple ls application that I use for
 teaching a class on Linux APIs.

 Cheers,
 Rudi



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

Re: [yocto] Question about remote debugging via gdbserver

[Rudolf Streif]

Hi Federico,

I knew that I can add source paths to the debugger.

Ok, if that's not the issue what exactly is not working for you?


 I see in your debug profiles that you have some binaries eg ls. Did you
 import that binary from sysrootfs on your build machine? Can you please
 tell me the steps before adding the path?

No, that's actually sample code of a simple ls application that I use for
teaching a class on Linux APIs.

Cheers,
Rudi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dogfooding and usability testing Toaster

[Rudolf Streif]

Hi Belen,

That is exciting. I just ran with it and started a build with toaster in
the background. A couple of observations from the get-go:

   - South 0.8.4 is also needed in addition to Django. The Toaster Wiki [1]
   does not say that but the Contribute to Toaster page [2] does.
   - You need to run 'sudo pip install ...' for Django and South otherwise
   the installation fails with 'permission denied' for /usr/lib/python2.7
   - Clicking on Show me the manual in the Toaster UI directs to [3]
   which requires a log in
   - Is it possible to relocate/rename the toaster.sqlite database via
   configuration setting? If so, could I use the same database for different
   build environments?

Thanks,
Rudi




[1] https://wiki.yoctoproject.org/wiki/Toaster#Installation_and_Running
[2] https://wiki.yoctoproject.org/wiki/Contribute_to_Toaster
[3] https://www.yoctoproject.org/documentation/toaster-manual
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] fetcher from gitpod

[Rudolf Streif]

Hi Robert,

Did you try something like

SRC_URI = git://gp@gitpod:linux-stable.git

The git fetcher supports authentication with a username, if that is your
concern.

Regards,
Rudi


On Thu, Jan 23, 2014 at 2:19 PM, Robert Berger 
gm...@reliableembeddedsystems.com wrote:

 Hi,

 I would like to fetch some get repos (currently u-boot and kernel) from
 a local git caching server[1]. This means if something changed on
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 since the last invocations it updates the changes, if nothing changed it
 provides the repo locally.

 After setting up the right ssh keys not to ask for a password it works
 like this:

 git clone gp@gitpod:linux-stable.git
 Cloning into 'linux-stable'...
 fetching from
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 remote: Counting objects: 3572381, done.
 remote: Compressing objects: 100% (574164/574164), done.
 Receiving objects: 100% (3572381/3572381), 752.89 MiB | 11.53 MiB/s, done.
 remote: Total 3572381 (delta 3008721), reused 3531934 (delta 2968274)
 Resolving deltas: 100% (3008721/3008721), done.

 Should this somehow already work with existing fetchers, or do I need to
 hack together my own fetcher?

 Regards,

 Robert

 [1] https://github.com/sitaramc/gitpod...The problem is never how to
 get new, innovative thoughts into your mind, but how to get old ones
 out. -- Dee Hock

 My public pgp key is available,at:
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x90320BF1


 ___
 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] poky-tiny, boot and filesystems

[Rudolf Streif]

John,

What is your actual problem? You appended the tiny-init recipe and your
changes do or do not get put into the rootfs? If you could post your recipe
then folks can look at it.

As far as boot time is concerned, you need to distinguish boot loader and
kernel boot from user space. It looks as if you are trying to optimize your
user space boot time by using an image that starts less services. What
services you need of course depends on your application. To optimize user
space boot process you may also want to investigate systemd instead of SysV
init.

Rudi


On Wed, Dec 18, 2013 at 8:26 AM, r10kindsofpeople 
r10kindsofpeo...@gmail.com wrote:

 I've been beating my head for a few days now, and would love a little
 guidance.  Acknowledging that there are multiple ways to skin the cat, my
 immediate goal is to reduce the boot time, presumably using poky-tiny.

 I have poky-tiny building for my hardware under dora.
 I have it booting on crownbay hardware by copying the .ext2 image onto the
 sdcard, installing grub, copying the .cpio.gz file on to the card, and
 using grub to load the kernel image and initrd the filesystem.

 I'm wondering if that last bit about initrd is the 'best' option, or if I
 should be overlaying a write-able filesystem on top of the original .ext2
 file system?  How?

 And I'm pretty sure I've not got something right...I figured out how to
 .bbappend the tiny-init recipe and get my own edits into 'init' and
 'rc.local', but it appears those files and changes made it into both the
 ext2 file system and the .cpio.gz initrd file system.  On one hand, I'm
 grateful since it works, but 'both' seems to point at me getting something
 wrong.

 Any links to clear tutorials would be greatly appreciated.  There's a
 wealth of information available on this topic, but none that seems
 comprehensive (that I've found), and as I've said, each seems to take a
 different approach, leaving out a step or two along the way.

 John



 ___
 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] FW: curious about ref manual, sec 6.1.11, oe-init-build-env-memres

[Rudolf Streif]

I am picking up this thread since I have been mocking around with the
bitbake server.

The use of the oe-init-build-env-memresscript is

source oe-init-build-env-memres portnumber buildenv

The documentation suggests that you can omit the portnumber in which case
the script would use 12345. According to my tests with master [1] that is
apparently not the case. If you omit the portnumber such as

source oe-init-build-env-memres mybuildenv

 the script will create a build environment with the name build and then
tries to convert mybuildenv into a portnumber wich will most likely fail
unless you used an integer number for the name of your build environment.

This behavior is expected since how would the script for a simple variable
list that does not use any option names be able to reliably detect if the
first parameter is a portnumber or a build environment name?

There are two possible fixes for that:

   1. Reverse the order of the two arguments in which case you can omit
   either the portnumber or both arguments. It would also make the command
   line of the script more consistent with oe-init-build-env.
   2. Check if the first argument is an integer (since portnumbers are
   always integers).

I would prefer 1. but then Scott would have to change the documentation. I
can submit a patch if that is any interest.

BTW, is the protocol that the bitbake server expects on that port
documented somewhere (other than the source code that is)?

Cheers,
Rudi




[1] master:c9b2e30988a9eb514d42a4cf4266b032ffc36f98


On Thu, Nov 7, 2013 at 8:37 AM, Rifenbark, Scott M 
scott.m.rifenb...@intel.com wrote:

 I updated the section.  See if that is better.

 Thanks
 Scott

 -Original Message-
 From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
 Sent: Wednesday, November 06, 2013 12:41 PM
 To: Saul Wold
 Cc: Rifenbark, Scott M; Yocto discussion list
 Subject: Re: [yocto] FW: curious about ref manual, sec 6.1.11,
 oe-init-build-
 env-memres
 
 On Wed, 6 Nov 2013, Saul Wold wrote:
 
  On 11/06/2013 11:11 AM, Rifenbark, Scott M wrote:
   Anyone know this?
  
-Original Message-
From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
Sent: Wednesday, November 06, 2013 10:48 AM
To: Rifenbark, Scott M
Subject: curious about ref manual, sec 6.1.11,
oe-init-build-env-memres
   
   
  i've never used that memory-resident version of bitbake -- it's
not clear from that section whether you need to start bitbake
running before you run that script.
   
  Running that scripts will start the server at the default port of
  12345 and setup the default build directory.
 
   i suspected as much, but the way that section is worded, that isn't
 clear.
 thanks.
 
 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

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

Re: [yocto] uimage instead of zImage

[Rudolf Streif]

Hi Edward,


This is what I have in the uEnv.txt file


 bootcmd=
 bootfile=zImage
 ethact=
 loadaddr=
 nandboot=
 nandroot=
 nandrootfstype=
 nandargs=
 loaduimage=
 loaduimagefat=
 nandboot=
 mpurate=auto
 bootcmd=mmc rescan ; fatload mmc 0:1 0x8030 zImage; bootz 0x8030

 Why are you setting all the variables to . You really only have to
overwrite the ones you need to change.



 dvimode=hd720 omapfb.vram=0:8M,1:4M,2:4M
 optargs=consoleblank=0
 console=ttyO2 console=tty0,115200n8
 vram=16M
 saveenv
 printenv

 It appears that some of variable get written with other data ie vram I am
 setting to 16M but sometimes I see it set to 12M see at the end
 I have tried setting the variables manually and executing saveenv
 All the ones I don't want set setenv name and then saveenv
 still see the same values
 when I was using uImage and no
 this is what I used for my uEnv.txt

 mpurate=auto

 Are you still trying to solve the problem with the rootfs or is that
another problem?



 mmcroot=/dev/mmcblk0p2 rw
 mmcrootfstype=ext3 rootwait


According to these settings your kernel is passed information to look for
an ext3 root file system on the second partition of the an SD card on
/dev/mmcblk0. Are you booting from an SD card? However, in your first boot
it seems to look for an ubifs.

I am not sure what you are looking for. Maybe you can attach an new boot
log.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] uimage instead of zImage

[Rudolf Streif]

Edward,

Your zImage is booting fine. The kernel starts and then tries to mount the
root file system. But it cannot find it. It's looking for a UBIFS but
cannot find it:


.
 VFS: Cannot open root device ubi0:rootfs or unknown-block(0,0): error -19
 Please append a correct root= boot option; here are the available
 partitions:
 VFS: Unable to mount root fs on unknown-block(0,0)
 User configuration error - no valid root filesystem found
 Kernel panic - not syncing: Invalid configuration from end user prevents
 continu
 ing


 You may have had additional error messages before the ones above that you
copied into your e-mail such as:

UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0xdfca80ed, read
0x7b7c0f6b
UBIFS error (pid 1): ubifs_check_node: bad node at LEB 0:0
UBIFS error (pid 1): ubifs_read_node: expected node type 6

That would be an indicator that the UBIFS root file system was not created
correctly on your flash device. How did you create it?

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Rudolf Streif]

Diego,

You are appending a kernel recipe that uses the Linux Yocto tooling. The
defconfig is essentially comprised of many different pieces from the meta
branch of the Yocto kernel repository and optional configuration fragments
that you provide. This tooling will not recognize a defconfig file you
provide but it does recognize configuration fragments to be added to
.config.

You need to put

CONFIG_WATCHDOG_NOWAYOUT=y

into a file that ends with .cfg eg. watchdog.cfg and then modify your
bbappend to

FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI +=  file://0019-mine.patch \
 file://watchdog.cfg \
 

Rudi



On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro diego.sue...@gmail.comwrote:

 Folks,

 I created the following bbapend recipe for linux-mainline_3.8.bb (from
 meta-beagleboard on dylan branch) for beaglebone.
 meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:

 FILESEXTRAPATHS_prepend := ${THISDIR}/files:
 SRC_URI +=  file://0019-mine.patch \
  file://defconfig \
  

 But the defconfig and .config files on ${S} and ${WORKDIR} used are from
 meta-beagleboad, not from my bbappend.

 I tried to follow the instructions to add config fragments on the page
 below but it did not worked too.

 http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration

 The strange thing is: My patch is applied but my defconfig, or config
 fragment is not used.
 I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.

 I already did a cleasstate but no success.

 Any hints?


 Regards,

 --
 *dS
 Diego Sueiro

 /*long live rock 'n roll*/

 ___
 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] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan

[Rudolf Streif]

I am looking to build for MPC8572 with Dylan and checked out the
meta-fsl-ppc BSP layer. Seems like support for that machine was removed in
May [1]. The reason given was  *u-boot code base can not support mpc85xx
for sdk 1.3.2. Howerver, that was contested in a follow-up e-mail.
Interestingly, the QorIQ-SDK-V1.3.2-20130325-yocto does contain
meta-fsl-ppc with support for that machine.

I grepped through the git log but could not even find the commit that
removed it.

Could someone please comment on the status? Is the BSP layer contained in
QorIQ-SDK-V1.3.2-20130325-yocto compatible with Dylan?


Thanks,
Rudi


[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2013-May/002679.html
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan

[Rudolf Streif]

Thank you, Zhenhua. I ended up using meta-fsl-ppc from [1] which has
support for mpc8572 and Dylan. It built the kernel, dtb and rootfs image.
It does not boot right now though stopping after Uncompressing Kernel
Image ... OK. I guess I have to do more debugging.

Thanks,
Rudi

[1]
http://git.freescale.com/git/cgit.cgi/ppc/sdk/meta-fsl-ppc.git/tree/?h=dylan

On Wed, Aug 28, 2013 at 7:33 PM, Luo Zhenhua-B19537 b19...@freescale.comwrote:

  Hi Rudi, 

 ** **

 Mpc85xx series is not supported and removed since FSL QorIQ SDK
 1.4(QorIQ-SDK-V1.4-20130625-yocto) which is based on Yocto 1.4(dylan), the
 machine configure files are removed from dylan/master of meta-fsl-ppc layer
 to avoid unexpected issues.
 http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/commit/?h=dylanid=ee9e6378f4f2651b78bb5ccc804f7dda627569d6
 

 ** **

 QorIQ SDK 1.3.2 uses denzil of Poky, you can use danny/denzil/edison for
 image build of mpc85xx series. 

 ** **

 ** **

 Best Regards,

 ** **

 Zhenhua

 ** **

 *From:* yocto-boun...@yoctoproject.org [mailto:
 yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif
 *Sent:* Thursday, August 29, 2013 12:34 AM
 *To:* Yocto Discussion Mailing List
 *Subject:* [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with
 Dylan

 ** **

 I am looking to build for MPC8572 with Dylan and checked out the
 meta-fsl-ppc BSP layer. Seems like support for that machine was removed in
 May [1]. The reason given was  *u-boot code base can not support mpc85xx
 for sdk 1.3.2. Howerver, that was contested in a follow-up e-mail.
 Interestingly, the QorIQ-SDK-V1.3.2-20130325-yocto does contain
 meta-fsl-ppc with support for that machine.

 ** **

 I grepped through the git log but could not even find the commit that
 removed it.

 ** **

 Could someone please comment on the status? Is the BSP layer contained in
 QorIQ-SDK-V1.3.2-20130325-yocto compatible with Dylan?

 ** **

 ** **

 Thanks,

 Rudi

 ** **

 ** **

 [1]
 https://lists.yoctoproject.org/pipermail/meta-freescale/2013-May/002679.html
 

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

Re: [yocto] Network booting

[Rudolf Streif]

 Is there an easy way to have a system boot and load the rootfs from a
 network server?

 The classic way is to serve the root file system from an NFS server. You
will have to pass the root=/dev/nfs and
nfsroot=[server-ip:]root-dir[,nfs-options]
to your kernel via boot loader.

Every system you want to boot this way will need to have its own root file
system on the NFS server. However, there is the nfsroot project [1] that
reportedly allows booting entire clusters sharing one root file system. I
have not used that though.



 I'm using an x86 system and can have the kernel and an initrd on it. I
 would use bootp, but a lot of end users either don't have this or will not
 allow it to be used. I think it needs to go something like:

 1) Kernel loads the initrd and bring the network up (static or DHCP);
 2) The rootfs image can then be download;
 3) Some magic then makes this run...

 This looks like you want to start up the system, download a root file
system tarball, extract it to somewhere and then use that as the root file
system by chroot'ing to it.




 ___
 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] possible variations on building bootable SD card for BBB?

[Rudolf Streif]

   so -- short form of the question -- how many ways are there to build
 a bootable SD card for the BBB using different layers?



There are many ways to skin a cat. I created my own BeagleBone BSP layer
that builds u-boot and a 3.2 kernel. The idea being to demonstrate how to
create a BSP layer. The recipes pull the sources from the Arago Project git
repository and apply some patches. That may not be necessary anymore
because patches for the am33x may be upstreamed to respective projects by
now.

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting YP Development Environment in more detail

[Rudolf Streif]

Hi Trevor,


On Mon, Jun 24, 2013 at 5:56 AM, Trevor Woerner
trevor.woer...@linaro.orgwrote:

 Awesome! That's great news! I was hoping someone would beat me to it
 :-) I look forward to reading it once it's done. Do you have a
 publisher or an expected release date?

 Yes, I do. Pearson and the release date is early next year (Embedded Linux
Conference is my target).


 An appendix on Android's repo tool might make for an excellent
 addition; it seems some Yocto projects are showing lots of interest in
 using it.

 The idea is to integrate/use it with YP? I know what repo does and that it
is built on top of git but I have not looked behind the scenes to figure
out how it does its job and how it can be used with something else like YP
instead of with the Android repositories and review system.

Cheers,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting YP Development Environment in more detail

[Rudolf Streif]

Hi Trever et al:



 If I were writing a book about Yocto/OE,


This is a project I am currently working on, a book about the Yocto
Project. The goal is to enable readers to do practical projects with YP. As
the subject matter for the project described in the book I have chosen a
home automation project. Reason being, it interests me personally and it
uses different devices such as a UI-less controller, remotes with touch
screens etc.

I have gotten a lot of feedback from the YP training class I have developed
and been teaching for the Linux Foundation. I am putting this out here to
solicit more feedback from the community on what you think a book on YP
should include. For instance as an advanced topic I included a chapter on
how to run YP on AWS EC2 and I will be adding Autobuilder to it too.


 in the first chapter I would
 have the readers build their own filesystem/kernel from scratch (I
 can't decide if I would also have them build their own cross-compiler
 from scratch or if I'd cheat and let them use crosstool-NG).


I thought about that too but I found it distracting. It's like let me show
you the hard way with crosstool-ng and buildroot and then I show you a
better way with YP. What I am doing though is an intro into Bitbake: how
to use just Bitbake to build something. That proved valuable during the
training classes. It's like a HelloWorld (and I published that before on
this mailing list) introducing the concepts of Bitbake with it's layers,
recipes, syntax etc.


Cheers,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ADT Install Issues

[Rudolf Streif]

What root file system are you using with your Eclipse ADT setup? If you are
using one of the default ones that you can specify in adt_installer.conf or
your own?

In any case it looks as if your root file system image is not suitable for
development work. You would need to use image targets that end in *-dev or
*-sdk such as core-image-minimal-dev.

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] building the BitBake manual

[Rudolf Streif]

And I hit the send button too early: on FC18 you also have to install
texlive-multirow.

:rjs

On Wed, May 15, 2013 at 10:16 PM, Rudolf Streif rstr...@linuxfoundation.org
 wrote:

 Scott,

 On FC18 these packages are also called xmlto and dblatex.

 xmlto has a dependency on flex which the package manager should install
 automatically.
 dblatex has dependencies on texlive-*.

 :rjs



 On Wed, May 15, 2013 at 9:07 PM, Rifenbark, Scott M 
 scott.m.rifenb...@intel.com wrote:

 When running make on the BB docs, my Ubuntu system was missing two
 packages: dblatex, xmlto.  Currently, the Required Packages for the Host
 Development System section in the YP Reference Manual does not list these
 packages as part of the Documentation packages.  I am thinking we should
 add these in for Ubuntu.  Can anyone tell me what the packages would be for
 Fedora, OpenSUSE, and CentOS?  Are they named the same?

 Thanks,
 Scott

 Scott Rifenbark
 Intel Corporation
 Yocto Project Documentation
 503.712.2702
 503.341.0418 (cell)

 ___
 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] Patching from .bbappend

[Rudolf Streif]

You got it figured out?

Simply add

FILESEXTRAPATHS_prepend := ${THISDIR}/${P}:
SRC_URI += mypatch.patch
PRINC := ${@int(PRINC) + 1}

to your bbappend and put your patch in a subdirectory
packagename-packageversion relative to the recipe.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] runqemu: Could not initialize SDL(No available video device) - exiting

[Rudolf Streif]

 Should YP be trying to build its own copy of libSDL (with the -devel)
 if it finds some part of libSDL (i.e. the header files) is missing
 from the host? This is almost like a host contamination issue, no?


You are raising an interesting point to which I have no answer. YP has a
recipe to build libsdl and it specifies BBCLASSEXTEND = nativesdk only,
not BBCLASSEXTEND = native nativesdk as one would expect if were to build
it for Qemu.

The qemu.inc recipe also does not list libsdl in DEPENDS_class-native but
it does so in DEPENDS_class-nativesdk and in DEPENDS. I cannot tell you why
that is but it may be worthwhile trying to add libsdl to
DEPENDS_class-native of qemu.inc and native to BBCLASSEXTEND in
libsdl_1.2.15.bb.

I wonder if bitbake qemu-nativesdk would build even if you don't have
libsdl installed on your host.

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] potentially confusing explanation of defconfig in kernel dev manual

[Rudolf Streif]

That's how I interpret it:

Wholesale = defconfig
Incremental = configuration fragments

Following kernel practices my defconfig files always have a working
configuration and then I use configuration fragments to make adjustments.

But of course you can have an incomplete configuration in defconfig and
make it complete with configuration fragments.

:rjs
 On Apr 13, 2013 1:46 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:


   here:


 http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration

 one reads:

 If you have a complete Linux kernel .config file you want to use,
 copy it to the ${FILES} directory within your layer and name it
 defconfig.

   that pretty clearly suggests that the defconfig file *must*
 represent a *complete* .config file. but just above that, you read:

 You can make wholesale or incremental changes to the Linux kernel
 .config file by including a defconfig or by specifying configuration
 fragments in the SRC_URI.

   so it's confusing -- must defconfig represent a complete .config
 file, or can it represent a fragment?

 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

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

Re: [yocto] i think the list of required software needs to be clarified

[Rudolf Streif]

In a sense yes. From how I understand it, anything that is listed as a
required utility in SANITY_REQUIRED_UTILITIES does not even have to be
listed in ASSUME_PROVIDED. The required native utilites should fail the
sanity test right away if they are not there.

For any dependency listed in ASSUME_PROVIDED BitBake will not attempt to
build it. But for instance, even if you do not list tar-native in
ASSUME_PROVIDED there is no way for BitBake to build tar since the recipe's
SRC_URI points to a tarball. Catch22.

However, I would expect that all the build essentials (awk make wget tar
bzip2 gzip python unzip perl patch diffutils diffstat git cpp gcc gcc-c++
eglibc-devel texinfo chrpath ccache) are listed in
SANITY_REQUIRED_UTILITIES.

A reason I could see to list all of the required native utilities in
ASSUME_PROVIDED could be the dependency graphs. It does not really add any
value to show the native stuff in the graphs.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: Post build configuration

[Rudolf Streif]

Ramana,

Maybe I do not understand what exactly you are looking for. Maybe you have
some concrete examples.

Anything that somehow changes the configuration of the target has to go
into the root file system one way or the other. You can easily include
packages into the root file system by adding them to the IMAGE_INSTALL
variable. But no matter what BitBake will have to re-run the tasks building
the root file system.

That works fine for a small number of devices but it does not scale. If you
need to scale it you need to do configuration management after you have
brought up the device for the first time during test. Then you can use the
package manager to install new packages.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: Post build configuration

[Rudolf Streif]

The process that you are describing is commonly called device
provisioning. I have experienced this process from different angles:
working for a company making functional test equipment for electronics
production lines and working for a company providing software for set-top
boxes.

From this experience provisioning is frequently done during production at
the end of the process when the automated functional test is performed.
During these tests the devices are fired up, get their device image
installed, receive their individual programming and are tested.

Dependent on the device there are many methods on how to do it. I have used
serial ports, networked provisioning servers, direct programming of OTP or
flash using the tester, etc.

It may be a cool thing to have for YP but it may also somewhat out of the
scope of YP. In one way or another you will always have to put your data
onto the root file system. Unfortunately, creating a root file system is
always somewhat expensive and time consuming. Many times when I am making
changes to my YP build environment just rebuilding a single package
creating the root file system is the most time consuming part of the
process.

My preferred way of provisioning is a networked provisioning server. In
most cases, you will have to store the configuration data anyway, so I
store it in a database on the provisioning server. I have not done this
with YP but if had to do it I would look into using TCF. When the device
boots it starts up TCF. The provisioning server connects to the TCF server
on the  device, pushes the files it needs, etc.

It's a fun project but if you look at it from that angle it's not that much
related to YP as a build system. It's like any other application package.
You build it with YP and add it to the root file system.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hob and bitbake problem!

[Rudolf Streif]

Hi Florin,

You will need to look in the log file of the compile task for Qt4 to find
out what's going on: see /home/user/poky-danny-8.0/
build/tmp/work/core2-poky-linux/qt4-x11-free-4.8.1-r47.
1/temp/log.do_compile.28027

In the log file you will see the output of qmake and the compiler.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] FW: Is there a guide for adding a board to the yocto system?

[Rudolf Streif]

On Tue, Mar 5, 2013 at 5:19 PM, Rifenbark, Scott M 
scott.m.rifenb...@intel.com wrote:

  Isn’t this a matter of creating a BSP layer for the desired board?  If
 so, doesn’t one try to find a similar board from one of the
 supported/released yocto BSPs and then modify that to create the custom
 layer?

 ** **

 Scott

 **

Yes, it is. At least IMHO. Technically, you have three ways of creating a
YP BSP layer:

   - Build it manually from scratch by creating the directory tree and
   populate it with the configuration files, recipes, readme files, etc. that
   you need.
   - Copy an existing BSP layer that supports a machine that is similar to
   the one you are trying to support.
   - Use the yocto-bsp script to create one and then eventually the
   yocto-kernel script to modify the kernel configuration if you are
   leveraging the YP kernel.

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about file systems

[Rudolf Streif]

There is a major difference between ext3 and ext4 which is called delayed
(block) allocation. Delayed allocation of blocks increases the risk of
data loss in certain circumstances. While ext3 typically syncs cache to
disk every 5s, it can take 2min with ext4.





On Wed, Mar 6, 2013 at 10:20 AM, Trevor Woerner twoer...@gmail.com wrote:

 On Tue, Mar 5, 2013 at 9:20 PM, Paul D. DeRocco pdero...@ix.netcom.com
 wrote:
  So I guess the questions are these: Are ext2, ext3 and ext4 all equally
  likely to need to do an fsck after a disorderly shutdown? Do they
  typically take different amounts of time to do an fsck? Or is the
  journaling of ext3 and ext4 something that should be avoided on a flash
  drive at all costs, even though my app won't be doing much file access?

 With the embedded project I work on, I had started (roughly 7 years
 ago) by using ext2 on our flash drive. I too found that my users
 always yanked the cable instead of trying to perform any sort of
 orderly shutdown. Technically this device is meant to run 24/7, but I
 found that several of our field reps were convinced they had to
 power-cycle after every configuration change (which I still don't
 understand... do they do that on their own computers?).

 Anyway, with ext2 we would get irrecoverable disk corruption, or at
 least enough corruption that the bootup would halt, waiting (forever)
 for the user to run fsck manually (our device has a total of 4 LEDs
 on the front panel as the only feedback, and they don't come alive
 until user-space starts). So I switched to ext3 around (roughly) 5
 years ago and have not once seen an incident of a failed bootup due to
 disk corruption/fsck problems.

 Yes, it does make the duration of the bootup non-deterministic, but
 for our product bootup time is not a priority.

 I can't say as to whether ext4 should be used instead of ext3 or which
 is better or faster. All I can say is if your users are yanking the
 cable you may want to stay away from ext2. Also some sort of fsck is
 always run on the next bootup when power is cut off unexpectedly.
 ___
 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] uboot.bin and rootfs but not uImage

[Rudolf Streif]

You are missing .config because you called your defconfig
skidata-carrier_defconfig.
Just rename skidata-carrier_defconfig do defconfig in

SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
   file://defconfig \
  

Alternatively you could do

do_fetch_append () {
   mv ${S}/skidata-carrier_defconfig ${S}/defconfig
}

:rjs


On Sat, Mar 2, 2013 at 7:37 AM, Satya Swaroop DAMARLA swar...@weisser.atwrote:

 Hi Bruce and Hi Rudy,

 You are right and it works until it failes at the do_configure.
 Suggestions please. Here is the file for linux-skidata.bb

 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 ?= /home/damarla/linux-nvidia.git

 # Branch to check out
 KBRANCH ?= remotes/origin/tamonten/l4t

 # Revision tag or AUTOREV
 SRCREV ?= ${AUTOREV}

 SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
file://skidata-carrier_defconfig \


 COMPATIBLE_MACHINE = skidata-carrier

 S = ${WORKDIR}/linux-nvidia-skidata

 The following is the error. I just need some suggestions. and other thing
 is there are several device tree compilers. Please tell me the variable and
 where to place it for the specific dts file to be used..

 ERROR: Function failed: do_configure (see
 /home/damarla/yocto/poky/buildSkidata/tmp/work/skidata_carrier-poky-linux-gnueabi/linux-skidata/3.2-r0/temp/log.do_configure.29911
 for further information)
 ERROR: Logfile of failure stored in:
 /home/damarla/yocto/poky/buildSkidata/tmp/work/skidata_carrier-poky-linux-gnueabi/linux-skidata/3.2-r0/temp/log.do_configure.29911
 Log data follows:
 | DEBUG: Executing python function sysroot_cleansstate
 | DEBUG: Python function sysroot_cleansstate finished
 | DEBUG: Executing shell function do_configure
 | NOTE: make oldconfig
 | make: *** No rule to make target `oldconfig'.  Stop.
 | ERROR: oe_runmake failed
 | ERROR: Function failed: do_configure (see
 /home/damarla/yocto/poky/buildSkidata/tmp/work/skidata_carrier-poky-linux-gnueabi/linux-skidata/3.2-r0/temp/log.do_configure.29911
 for further information)
 ERROR: Task 766 (/home/damarla/yocto/poky/meta/recipes-kernel/linux/
 linux-skidata.bb, do_configure) failed with exit code '1'


 Thanks a million



 On Fri, Mar 1, 2013 at 2:49 PM, Bruce Ashfield 
 bruce.ashfi...@windriver.com wrote:

 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:rstreif@**linuxfoundation.orgrstr...@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=**
 d7810fab7487fb0aad327b76f1be7c**d7

 PV = 3.2

 inherit kernel

 FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:${THISDIR

Re: [yocto] linux 3.8

[Rudolf Streif]

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] yocto beaglebone build no uImage on DOS partition.

[Rudolf Streif]

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] Updating uboot to v2013.01

[Rudolf Streif]

Hey Satya,

Sorry for the delayed response.

Well, it should create the kernel image and wrap it for u-boot. At least
that is my experience and what I just did during a YP class on the weekend
for the BeagleBone.

What is linux-dummy? Is that a kernel recipe that you created?

I second what Khem said that you may be missing the BSP or have incorrect
entries in your machine configuration file. That file ties machine-specific
stuff such as kernel, bootloader etc. together.

I am not sure about the device tree compiler. YP builds dtc as a native
package. The only reason I can imagine is that it was not built when you
are trying to build u-boot.

The SRCREV tags for u-boot I got from git.denx.de:

2013.01.01:
http://git.denx.de/?p=u-boot.git;a=tag;h=8512592e47cc968d2d6eb788acde761ebc3acbf6

2013.01:
http://git.denx.de/?p=u-boot.git;a=tag;h=35c192cf449860aec8766e20a51bf2052a1dc968

They are the git commit tags.

Cheers,
Rudi


On Tue, Feb 26, 2013 at 11:44 PM, Satya Swaroop Damarla 
swaroop.dama...@gmail.com wrote:

 Hey Rudy,

 I think, it doesnot automatically take a kernel but we have to choose the
 kernel and I chose it v3.2 but seems it doesnot support my board and so I
 should take a kernel from the original and configure it to my need Here
 is the only error message I see about linux kernel

 WARNING: linux-dummy: No generic license file exists for: GPL in any
 provider

 my board is Avionic Tamonten Carrier, based on NVIDIA harmony board.
 Suggestions are very much appreciated but I am also currently trying to
 solve it.. I just downloaded a git kernel from the avionic site and can you
 please tell me how to configure it to so that the build system takes this
 as kernel and build it

 Greets,
 Satya


 On Tue, Feb 26, 2013 at 6:21 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 So what exactly do you get when building the kernel? No image at all in
 tmp/deploy/images? What do the logs for the kernel recipes say?

 Rudi


 On Mon, Feb 25, 2013 at 11:36 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 hey hans,

 I think you are right about the kernel device tree.. I think it should
 come with the kernel but I have no idea why it works.. Only an expert
 should say why it works.. I think my work is not complete. I can generate
 the rootfs and the uboot.bin file but not the uImage... I have no idea...
 Diid you complete generating the image for the board?

 Greets,
 Satya


 On Mon, Feb 25, 2013 at 5:05 PM, Hans Beckérus 
 hans.becke...@gmail.comwrote:



 25 feb 2013 kl. 15:58 skrev Satya Swaroop DAMARLA swar...@weisser.at:

 Guys. I found the solution to this problem

 I think if you already install uboot-tools or uboot-mkimage packes from
 Ubuntu repository then it is used instead of the one that is downloaded and
 we should uninstall the packages and then rerun the build,,... Then IT
 WORKS... So, thank you for the time and enegry... I assume this thread is
 closed and this is the solution and if this doesnot work for some then
 please post it and we may discuss the situation depending on the problem,

 Greetings  Regards,
 Satya

 Same comment here as for the device tree compiler. You should use the
 uboot tools/version as they come with the package. Not the one used by the
 host distro. To me this is not a proper solution.



 On Thu, Feb 21, 2013 at 5:28 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 I will look into it later today. I am currently at the Linux
 Foundation's Embedded Linux Conference.

 Rudi


 On Thu, Feb 21, 2013 at 2:10 AM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 Hello Guys,

 I have not received any reply from you. If you can help me to figure
 out what the errors mean when adding a new .bb or recipe file then I can
 learn the mistake and take care in the new recipes I request your 
 time


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 6:46 PM, Hans Beckérus 
 hans.becke...@gmail.com wrote:

 On Wed, Feb 20, 2013 at 6:12 PM, Satya Swaroop Damarla
 swaroop.dama...@gmail.com wrote:
  Hey hans, this is what he meant,
 
  In the machine config file add the following
 
  PREFERRED_VERSION_u-boot ?= v2013.01%  or
 PREFERRED_VERSION_u-boot ?=
  v2013.01.01%
 
  By the way did you already complete the first part... There is
 also other
  file called u-boot-fw-utils_2012.04.01.bb ... I think we
 should do the
  same...
 
  Hans bytheway,  are you also working on the same board or
 diffferent board
  with same problem?
 

 Different board, same core, similar problem ;)
 Now I get it. Thanks. But still question

Re: [yocto] uboot.bin and rootfs but not uImage

[Rudolf Streif]

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
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Updating uboot to v2013.01

[Rudolf Streif]

As Hans said, you should not need to install any of these host packages
since Yocto is for most part all self-contained. If you think that you need
to install host packages then there may be something wrong with building a
particular tool for the development host. That is typically done with
BBCLASSEXTENDS = native or BBCLASSETENDS = native native-sdk.

Rudi


On Mon, Feb 25, 2013 at 7:56 AM, Satya Swaroop Damarla 
swaroop.dama...@gmail.com wrote:

 Another important package that has to be installed in  the apt-get
 install device-tree-compiler package. This was adviced by the Thierry
 Reding, wh wrote the uboot config for Tamonten board.. Rudolf, may I ask
 you how did you find the SRCREV values for the uboot packages ... It would
 be great to know as there is not sufficient literature avilable to explain
 this on the internet...


 On Mon, Feb 25, 2013 at 3:58 PM, Satya Swaroop DAMARLA swar...@weisser.at
  wrote:

 Guys. I found the solution to this problem

 I think if you already install uboot-tools or uboot-mkimage packes from
 Ubuntu repository then it is used instead of the one that is downloaded and
 we should uninstall the packages and then rerun the build,,... Then IT
 WORKS... So, thank you for the time and enegry... I assume this thread is
 closed and this is the solution and if this doesnot work for some then
 please post it and we may discuss the situation depending on the problem,

 Greetings  Regards,
 Satya


 On Thu, Feb 21, 2013 at 5:28 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 I will look into it later today. I am currently at the Linux
 Foundation's Embedded Linux Conference.

 Rudi


 On Thu, Feb 21, 2013 at 2:10 AM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 Hello Guys,

 I have not received any reply from you. If you can help me to figure
 out what the errors mean when adding a new .bb or recipe file then I can
 learn the mistake and take care in the new recipes I request your time


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 6:46 PM, Hans Beckérus 
 hans.becke...@gmail.com wrote:

 On Wed, Feb 20, 2013 at 6:12 PM, Satya Swaroop Damarla
 swaroop.dama...@gmail.com wrote:
  Hey hans, this is what he meant,
 
  In the machine config file add the following
 
  PREFERRED_VERSION_u-boot ?= v2013.01%  or
 PREFERRED_VERSION_u-boot ?=
  v2013.01.01%
 
  By the way did you already complete the first part... There is
 also other
  file called u-boot-fw-utils_2012.04.01.bb ... I think we should
 do the
  same...
 
  Hans bytheway,  are you also working on the same board or
 diffferent board
  with same problem?
 

 Different board, same core, similar problem ;)
 Now I get it. Thanks. But still question remains how in earth I
 managed to build the kernel if not also having copied/renamed the
 mkimage .bb?
 Is the PREFERRED_VERSION_u-boot used to determine what mkimage and fw
 utils it picks up?
 Then it might be that since I/we build u-boot as a separate package,
 but kernel lifts in the mkimage stuff, it works but the wrong package
 was used.
 In my case obviously compatible, but not recommended I guess. Also, I
 agree that the fw utils should probably be in sync similar to
 mkimage.

 Hans

 
 
 
 
 
  On Wed, Feb 20, 2013 at 6:01 PM, Hans Beckérus 
 hans.becke...@gmail.com
  wrote:
 
  On Wed, Feb 20, 2013 at 5:16 PM, Rudolf Streif
  rstr...@linuxfoundation.org wrote:
   Satya,
  
   Simply look at the u-boot recipes in meta/recipes-bsp/u-boot
 such as
   u-boot_2012.04.01.bb. You can simply copy it and name it
   u-boot_2013.01.bb
   and then modify SRCREV to the revision that corresponds to the
 tag
   2013.01
   or 2013.01.01 in git.denx.de:
  
   for 2013.01: 3a9d879f6f64585b819af728b53be0a05037fe0d
   for 2013.01.01: e8ae0fa5edd152b2b29c470b88429be4cdcd2c46
  
   Do the same for u-boot-mkimage and include the u-boot version
 with your
   bsp.
  
   Rudi
  
  
  Hi Rudi, sorry to chime in , but I have a similar problem but do
 not
  really get the last thing you said.
  What do you mean by including the u-boot version in the bsp? Also
 is
  it a must to also copy the mkimage .bb or will the system find a
  suitable one automatically?
  The thing is that I only copied/edited the u-boot .bb but never
 the
  mkimage. Still my kernel successfully builds the kernel uImage!?
  Some magic that I have missed :)
 
  Hans
 
 
   On Wed, Feb 20, 2013 at 5:17 AM, Satya Swaroop Damarla
   swaroop.dama...@gmail.com wrote:
  
   Hi Guys,
  
   I need support for uboot on Tamonten board but the version on
 it is
   v2012.04 but I came to know that v2012.10

Re: [yocto] Updating uboot to v2013.01

[Rudolf Streif]

Satya,

Simply look at the u-boot recipes in meta/recipes-bsp/u-boot such as
u-boot_2012.04.01.bb. You can simply copy it and name it
u-boot_2013.01.bband then modify SRCREV to the revision that
corresponds to the tag 2013.01
or 2013.01.01 in git.denx.de:

for 2013.01: 
3a9d879f6f64585b819af728b53be0a05037fe0dhttp://git.denx.de/?p=u-boot.git;a=commit;h=3a9d879f6f64585b819af728b53be0a05037fe0d
for 2013.01.01:
e8ae0fa5edd152b2b29c470b88429be4cdcd2c46http://git.denx.de/?p=u-boot.git;a=commit;h=e8ae0fa5edd152b2b29c470b88429be4cdcd2c46

Do the same for u-boot-mkimage and include the u-boot version with your bsp.

Rudi


On Wed, Feb 20, 2013 at 5:17 AM, Satya Swaroop Damarla 
swaroop.dama...@gmail.com wrote:

 Hi Guys,

 I need support for uboot on Tamonten board but the version on it is
 v2012.04 but I came to know that v2012.10 or v2013.01 supports the
 Tamontenboard through some guys here..

 It would be great if you can tell me how can I accomplish v2013.01 or
 v2012.10 into the build system and make it available so that I can compile
 the and get uImage

 (Tamonten board is a derivative of harmony board with some changes and has
 arm cortexa9 processor without neon extentions )

 I am kind of new to add new .bb files and help is really appreciated as I
 am not able to figure out how to add

 Greetings  Regards,
 Swaroop

 ___
 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] select installation packages

[Rudolf Streif]

Hi Andre,

There actually is no recipe for building the nano editor in YP by default.
Unless you added one,

bitbake -b nano

would result in this output

ERROR: Unable to find any recipe file matching 'nano'

I have attached a recipe for you to build nano and a patch to handle a
configuration mistake configure.ac causing do_configure to fail.

If you add that recipe you can run bitbake nano. You can also include into
your image by adding

IMAGE_INSTALL_append =  nano

to your conf/local.conf file.

:rjs



On Thu, Feb 14, 2013 at 8:02 AM, Andre Bella scanc...@yahoo.com wrote:

 Hello
  I had used buildroot in the pass and I like it cause is very easy to use,
 but I'm moving to yocto cause it has more applications than buildroot, in
 buildroot you can select the packages you want to add by going to
 menuconfig, how do I select the packages I wan to add in yocto, for example
 if I wan to add nano or gstreamer, from the guide I seen you just type
 bitbake -b nano, but is there a menuconfig on yocto where you can select
 the package you want to add before you build the image?
 thanks,

 ___
 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


nano_2.3.1.bb
Description: Binary data


ncursesw.patch
Description: Binary data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The Yocto Project at upcoming conferences

[Rudolf Streif]

Thanks, Sean. And I improved it since. :)


On Thu, Feb 14, 2013 at 9:07 AM, Sean Liming sean.lim...@annabooks.comwrote:

 ** **

 I went last year. It is a very good class. Rudi did a great job.

 ** **

 Regards,

 ** **

 Sean Liming

 ** **

 *From:* yocto-boun...@yoctoproject.org [mailto:
 yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif
 *Sent:* Thursday, February 14, 2013 8:39 AM
 *To:* John Mehaffey
 *Cc:* Yocto Project
 *Subject:* Re: [yocto] The Yocto Project at upcoming conferences

 ** **

 ** **

 It appears that there will be a 2-day training session following the
 conference as well (Sat-Sun):

 See
 http://events.linuxfoundation.org/events/embedded-linux-conference/schedule
 :
 [Add-On] Building Embedded Linux with the Yocto Project Crash Course
 (LF404)http://embeddedlinuxconference2013.sched.org/event/e537dca881b6ba52f103be1e10f3bbc6?iframe=yesw=900sidebar=yesbg=no
 

 ** **

 Yes, that is right. It's a Linux Foundation offering. It is a condensed
 version of our 5-day class in 2-days of action. That's why it's called a
 crash course. :) The class covers pretty much everything from the Yocto
 Project basics to ADT and Eclipse. And you will get a Beaglebone (yours to
 keep) and learn how to make a YP BSP for it.

 ** **

 How would I know? I developed the class material and will teaching the
 class.

 ** **

 Cheers,

 Rudi




-- 
-- 
*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] hob error

[Rudolf Streif]

Hi Andre,

You may want to send the content for layer.conf and bblayers.conf.

However, you may have a typo if you copied and pasted the error message:

${BBPATH}:/home/andre/fsl-community-bsp/soucers/meta-fsl-arm which
triggered exception Exception: variable BBPATH reference itself!

It says soucers where it should be sources, I suppose.

Rudi


On Wed, Feb 13, 2013 at 10:55 AM, Andre Bella scanc...@yahoo.com wrote:

 Hello,
 I'm getting this error when I run hob,

 Error
 Unable to parse
 /home/andre/fsl-community-bsd/sources/meta-fsl-arm-extra/conf/layer.conf:Failture
 expanding variable BBPATH, expression was
 ${BBPATH}:/home/andre/fsl-community-bsp/soucers/meta-fsl-arm which
 triggered exception Exception: variable BBPATH reference itself!

 what I'm trying to do is is add nano, vlc and gstreamer to the rootfs.


 ___
 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] [danny] core-image-minimal-dev is missing dev packages

[Rudolf Streif]

Thanks, Paul. Not sure however. I should have included that I used plain
old i586 architecture. There should be no dashes/underscore issues there.

:rjs
On Feb 9, 2013 6:30 AM, Paul Eggleton paul.eggle...@linux.intel.com
wrote:

 On Friday 08 February 2013 19:17:35 Rudolf Streif wrote:
  This is weird and I do not have an explanation for it. For Danny:
 
  core-image-minimal-dev is missing the dev packages (pkg-dev)
 
  I build it but the packages are not there. The cause does not seem to be
 my
  setup because the core-image-minimal on the ADT download site is missing
  them too.

 I can't tell but it could be this bug, for which I have sent a patch:

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

 (Although this doesn't prevent *all* dev packages from being included, just
 some.)

 Cheers,
 Paul

 --

 Paul Eggleton
 Intel Open Source Technology Centre

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

Re: [yocto] [danny] core-image-minimal-dev is missing dev packages

[Rudolf Streif]

I have not verified every single dev package but the linker files in
/usr/lib/arch and related are missing. You cannot link against a dev
image sysroot. That used to work.

:rjs
On Feb 9, 2013 9:19 AM, Rudolf Streif rstr...@linuxfoundation.org wrote:

 Thanks, Paul. Not sure however. I should have included that I used plain
 old i586 architecture. There should be no dashes/underscore issues there.

 :rjs
 On Feb 9, 2013 6:30 AM, Paul Eggleton paul.eggle...@linux.intel.com
 wrote:

 On Friday 08 February 2013 19:17:35 Rudolf Streif wrote:
  This is weird and I do not have an explanation for it. For Danny:
 
  core-image-minimal-dev is missing the dev packages (pkg-dev)
 
  I build it but the packages are not there. The cause does not seem to
 be my
  setup because the core-image-minimal on the ADT download site is missing
  them too.

 I can't tell but it could be this bug, for which I have sent a patch:

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

 (Although this doesn't prevent *all* dev packages from being included,
 just
 some.)

 Cheers,
 Paul

 --

 Paul Eggleton
 Intel Open Source Technology Centre


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

[yocto] PROVIDES for Yocto Kernel Recipes

[Rudolf Streif]

I apologize if that has been brought up before.

The linux-yocto kernel recipes include the git tags into PV by explicitly
setting:

PV = ${LINUX_VERSION}+git${SRCPV}

This means that you cannot for example do

bitbake linux-yocto-3.2

anymore because PROVIDES does not contain linux-yocto-3.2 but only the
rather cumbersome string linux-yocto-3.2+git${SRCPV}, with ${SRCPV}
expanded of course.

The percent notation only works for

PREFERRED_VERSION_linux-yocto = 3.2%

but does not work for

bitbake linux-yocto-3.2%

That really only leaves you with setting PREFERRED_VERSION which is not
that convenient if you just want to build a different kernel version.

I am not sure how others feel about that and maybe I am missing something
but it would be rather simple to add that back by setting

PV = ${LINUX_VERSION} ${LINUX_VERSION}+git${SRCPV}

Well, kind of, you still would have to know the minor version number.

Cheers,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PROVIDES for Yocto Kernel Recipes

[Rudolf Streif]

Yes, of course with a space. Proportional fonts don't work that well with
code. :)

That's why I am asking if anyone else found that to be a nuisance. Of
course, for a BSP you have to set PREFERRED_VERSION. But for testing and
working with different kernel version I would find it more convenient if I
had not to change PREFERRED_VERSION in the machine file or override it in
local.conf.

It's also sort of an inconsistency. Typically, one would expect that you
could run bitbake against a recipe by specifying the package name and
version. Using -b with the recipe file name is not an option since you
would not get the bbappends.

Cheers,
Rudi


On Thu, Feb 7, 2013 at 5:39 PM, Bruce Ashfield bruce.ashfi...@gmail.comwrote:




 On Thu, Feb 7, 2013 at 8:22 PM, Rudolf Streif rudolf.str...@linux.comwrote:

 I apologize if that has been brought up before.

 The linux-yocto kernel recipes include the git tags into PV by explicitly
 setting:

 PV = ${LINUX_VERSION}+git${SRCPV}

 This means that you cannot for example do

 bitbake linux-yocto-3.2

 anymore because PROVIDES does not contain linux-yocto-3.2 but only the
 rather cumbersome string linux-yocto-3.2+git${SRCPV}, with ${SRCPV}
 expanded of course.

 The percent notation only works for

 PREFERRED_VERSION_linux-yocto = 3.2%

 but does not work for

 bitbake linux-yocto-3.2%

 That really only leaves you with setting PREFERRED_VERSION which is not
 that convenient if you just want to build a different kernel version.

 I am not sure how others feel about that and maybe I am missing something
 but it would be rather simple to add that back by setting

 PV = ${LINUX_VERSION} ${LINUX_VERSION}+git${SRCPV}


 You mean with a space in the version string ? I know that I don't want
 directories floating around
 with spaces, since they cause no end of troubles. But maybe it's just the
 font in gmail playing
 tricks with my eyes.

 Perhaps Richard has a suggestion, but in 3+ years, this is the first time
 that this particular issue
 has come up. Most everyone is setting the PREFERRED_VERSION in their bsps,
 or local.conf
 and not using that particular mechanism of switching between kernels ..
 myself included, and I
 probably build more versions of linux-yocto than anyone you'll find :)

 Don't get me wrong, I'm not dead set against changing it, but we do need
 both the meta and
 machine git hashes in the version to uniquely identify the tree (and my no
 spaces comment!).
 Maybe someone knows of a better way for command line switching of the
 version ?

 Cheers,

 Bruce






 Well, kind of, you still would have to know the minor version number.

 Cheers,
 Rudi


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




 --
 Thou shalt not follow the NULL pointer, for chaos and madness await thee
 at its end




-- 
-- 
*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] Busybox still old version: Still looking for a clear understanding of an old mystery.

[Rudolf Streif]

Brian,

What are you exactly referring to as new version? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.

I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache.
Try this:

bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox

BR,
Rudi
On Jan 15, 2013 1:27 PM, Brian Smucker b...@bsmucker.eu.org wrote:

 Hello All,

 I'm a relative newbie to yocto/oe, but have got a ways down the road to
 understanding, but the gaps in my understanding cause me great grief at
 times.

 I think this probably is a simple question, but somehow I'm doing
 something wrong.

 I recompile busybox with a new config: bitbake -c menuconfig busybox
 I make busybox: bitbake busybox
 bitbake gets compiled.

 Then I do a bitbake core-image-minimal.  It does the do_rootfs action and
 makes a new image.
 But the busybox is not the newly-compiled one, it is old.
 I expect the new version.
 Maybe my expectations are wrong.  But I've struggled with this and similar
 scenarios time and time again, sometimes hitting on a combination of things
 that work or by selectively deleting a directory or so or by bitbake -c
 cleansstate -f on one target or another.

 But it's always been kind of a mystery to me how to recompile a particular
 target, which then succeeds, and subsequently make sure that target is
 included in the image target (core-image-minimal). I've succeeded in a
 hit-or-miss way at times, but I would love to know a clear series of steps
 that will work definitively.

 I know I can delete the entire tmp directory, but that seems far too
 extreme, not to mention slow to recover from.

 Can someone help me?

 I'm using Danny.

 Thanks,
 Brian






 __**_
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] should users be able to run yocto's pre-built images standalone?

[Rudolf Streif]

Hi Robert,



 a basic question -- is it supported that users be able to download and
 run yocto's pre-built QEMU images without having to download an entire
 build system, and set up bitbake, etc?  theoretically, of course, it
 can be done, but it's not set up to do it conveniently (if it even
 should be).


IMHO that is exactly what the ADT installer does. OK, it could use some
enhancements but it lets you specify what pre-built images you would like
to use and sets it up, including QEMU and the related scripts.



   first, one can't get yocto's qemu-related utilities without
 downloading either oe-core or a toolchain.  is that really necessary?
 how hard would it be to break out the QEMU stuff into a much smaller
 tarball if that's all people want?


I think you want at least QEMU, the scripts, the user-space NFS server and
the cross-toolchain. Quite frankly, what do you really do with just QEMU,
scripts and images? Either you want to build your own images then you need
Poky (the build system) or you want to do user-space development then you
need images and a cross-toolchain. Just booting an image into QEMU seems
quite boring to me.


   and if that's done, certainly, the help messages from runqemu can be
 updated, since those utilities clearly assume they're running as part
 of a build infrastructure when that's not necessary.

 Fair enough, but if you could provide more details outlining what the
error message said, what the root cause of the problem was, and what you
think the error message should say, it would really help the developers to
make the improvements. Unless you are inclined to rummage through the code,
fix it and submit patches.

runqemu uses bitbake to determine the environment and infer the paths to
kernels and root fs images when using the short version of invoking it.
That is actually what the message says that you have on your webpage:

In order for this script to dynamically infer paths to kernels or
filesystem images, you either need bitbake in your PATH or to source
oe-init-build-env before running this script

However, you can directly invoke runqemu with paths to kernel and root fs
images:

$ runqemu /path/to/kernelimage /path/to/rootfsimage

and the paths can of course be absolute and relative. That is what ADT
does. ADT does not have bitbake included.


   anyway, you can see the observations i made on my QEMU page.  it
 seems that, if you just want people to be able to *easily* fire up
 some pre-built images to see the beauty of yocto, you shouldn't make
 them download an entire build infrastructure they don't need.

 I looked at your page and, no offense, it seems more complicated to me
than it ought to be. Just use the ADT installer, provide your settings in
the adt-installer.conf file, and take it from there.


Cheers,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_fetch failure with libowl-0.1

[Rudolf Streif]

Looks like the downloaded source file is corrupted although that should be
caught by the checksum verification. Try to locate the source file in
DL_DIR and unpack it manually. If it is corrupt delete the file, run a
cleanall on the libowl recipe and run bitbake again.

Rudi
On Nov 14, 2012 10:39 AM, Ramming, Brian brian.ramm...@intel.com wrote:

  Hello,

 ** **

 I am looking into converting my layer from Yocto 1.2 to Yocto 1.3 running
 into an issue when trying to build my image. It fails when trying to fetch
 libowl-0.1:

 ** **

 ERROR: Fetcher failure: Fetch command failed with exit code 2, output:

 tar: Skipping to next header

 ** **

 gzip: stdin: invalid compressed data--crc error

 ** **

 gzip: stdin: invalid compressed data--length error

 tar: Child returned status 1

 tar: Error is not recoverable: exiting now

 ** **

 DEBUG: Python function base_do_fetch finished

 DEBUG: Python function do_fetch finished

 ERROR: Function failed: Fetcher failure for URL: 'git://
 git.yoctoproject.org/libowl;protocol=git'. Unable to fetch URL from any
 source.

 ** **

 ** **

 I attached the full log from:
 \build\tmp\work\core2-poky-linux\libowl-0.1+git1+6ebc8ac8f8575278dd40a535cadefa26374e44b1-r0
 

 ** **

 If there is anything else that I should attach, or additional information
 I should provide please let me know.

 ** **

 Any information on this would be much appreciated.

 ** **

 Thank you kindly,

 Brian R.

 ___
 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] Olb Beagleboard support

[Rudolf Streif]

To chime in: I successfully used kernel and root fs built by plain Yocto,
meta and meta-yocto layers, for C4 and xM Beagleboards. On some C4 with
certain MMC I had the issue that the kernel would not be able to mount the
root fs and just sat there waiting. Unplugging and replugging the MMC
resets the flash reader and driver and then the kernel can mount the root
fs.

Rudi
On Nov 12, 2012 4:22 PM, Jeff Osier-Mixon je...@jefro.net wrote:

 Hi Flavio - sorry for the delay, everyone was very busy last week with the
 Embedded Linux Conference in Barcelona.

 You should be able to use the Yocto Project with the older BeagleBoard if
 you use the BSPs in the meta-ti layer (
 http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/). For more specific
 questions, I would encourage you to join the meta-ti mailing list (
 https://lists.yoctoproject.org/listinfo/meta-ti).

 Hope that helps!


 On Thu, Nov 8, 2012 at 8:51 AM, Flavio Castro Alves Filho 
 flavio.al...@gmail.com wrote:

 Hello,

 Does anybody know if current Yocto support for BeagleBoard works for
 OMAP3530 based BeagleBoard.

 It works correctly with BeagleBoard-xM, but with old BeagleBoard I don't
 have any information.

 If it doesn't work, can anybody give me some clue about how to build
 Yocto for this old board?

 Best regards,

 Flavio

 --
 Flavio de Castro Alves Filho

 flavio.al...@gmail.com
 www.linuxembarcado.com
 Twitter: http://twitter.com/#!/fraviofii
 LinkedIn profile: www.linkedin.com/in/flaviocastroalves


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




 --
 Jeff Osier-Mixon http://jefro.net/blog
 Yocto Project Community Manager @Intel http://yoctoproject.org


 ___
 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] Requesting information on some variables

[Rudolf Streif]

Scott,

Thanks for addressing this confusing part. The list of DISTRO_FEATURES (DF)
and MACHINE_FEATURES (MF) in the documentation also does not seem to be
complete. For instance, vfat is (at least the code in bitbake.conf that
intersects DF and MF suggests so) is a MF as well as a DF.

It also seems that any package is fair game for DF (which makes sense) but
the documentation says The items below are valid options for
DISTRO_FEATUREShttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-DISTRO_FEATURES
:.

Some elaboration on the features would be great too. From the explanation
it is not obvious why ext2 is considered a DF as well as a MF. The same
seems to be the case with vfat (although not listed in the documentation).
Other file systems e.g. ext3 etc. are purely considered DF.

Here are the variables from a build environment building for the Beagleboard

bitbake core-image-minimal -e | grep MACHINE_FEATURES
MACHINE_FEATURES=apm usbgadget usbhost vfat alsa

bitbake core-image-minimal -e | grep DISTRO_FEATURES
DISTRO_FEATURES=alsa argp bluetooth ext2 irda largefile pcmcia usbgadget
usbhost wifi xattr nfs zeroconf pci 3g x11 ipv4 ipv6 libc-backtrace
libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets
libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg
libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm
libc-libm-big libc-locales libc-locale-code libc-memusage libc-nis
libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
libc-posix-regexp-glibc libc-posix-wchar-io largefile opengl pulseaudio

bitbake core-image-minimal -e | grep COMBINED_FEATURES
COMBINED_FEATURES=alsa usbgadget usbhost

CF seems to be an intersection of DF and MF.  If I remove usbgadget from MF
then CF will of course not contain it. DF will still have it. What actually
does get included with the image? Is it DF - [list of all available machine
features] + CF?

[list of all available machine features] is then the superset of MF that is
typically defined in a machine.conf file. That list must be implicit
somewhere in the classes/configuration files somewhere, possibly
bitbake.conf.

That leads me to the next question. I have seen BSPs that include 'screen'
into MF in their machine.conf files. That feature is also in the
documentation. But it does not show up anywhere in DF or bitbake.conf etc.

Cheers,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple partitions in drive image

[Rudolf Streif]

Jonathan,

For what hardware are you building? It depends on the hardware how you need
to layout the file system on the boot device. YP provides you with a kernel
image and a root file system image and eventually, dependent on the
hardware, with bootloaders in ${TMPDIR}/deploy/images.

Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

The T variable points to a directory were Bitbake places temporary files
when building a particular package. It is typically set to

T = ${WORKDIR}/temp

WORKDIR is the directory into which Bitbake unpacks and builds a package.
The default bitbake.conf file sets this variable.

T is not to be confused with TMPDIR which points to the root of the
directory tree where Bitbake puts the output of an entire build.

:rjs

On Mon, Oct 8, 2012 at 5:30 PM, Patrick Turley
patricktur...@gamestop.comwrote:

  I am continuing my work on creating a Hello, World! BitBake project.
 Because of the excellent help I got before, things have gone reasonably
 well, but I'm again running into something I don't know how to fix.

  As before, the entire contents of my very small project appear at the
 end of this message. Here's what works fine:


  $ ../BitBake/bin/bitbake-layers show-layers
 Parsing recipes..done.

  layer pathpriority
 ==
 LayerA/home/pturley/Workspace/Hello/LayerA1

  $ ../BitBake/bin/bitbake-layers show-recipes
 Parsing recipes..done.
 === Available recipes: ===
 a:
   LayerA   1


  When I tried this:


  ../BitBake/bin/bitbake -c listtasks a


  I got a Python stack trace that ended here:


File ../BitBake/lib/bb/runqueue.py, line 902, in
 RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
  # If the stamp is missing its not current
 if not os.access(stampfile, os.F_OK):
  logger.debug(2, Stampfile %s not available,
 stampfile)
 TypeError: coercing to Unicode: need string or buffer, NoneType found


  This code isn't expecting the stampfile variable to be None (which
 it is), so it freaks out. I made a very simple fix to get past the problem:


  if not stampfile or not os.access(stampfile, os.F_OK):


  That made a dramatic difference, and enabled me to get this far:


  $ ../BitBake/bin/bitbake -c listtasks a
 Loading cache: 100%
 |###| ETA:
  00:00:00
 Loaded 2 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 NOTE: Preparing runqueue
 NOTE: Executing RunQueue Tasks
 NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/
 a.bb, do_listtasks)
 ERROR: T variable not set, unable to build
 ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb,
 do_listtasks) failed with exit code '1'
 NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
 rerun and 1 failed.

  Summary: 1 task failed:
   /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
 Summary: There was 1 ERROR message shown, returning a non-zero exit
 code.

  $ ../BitBake/bin/bitbake a
 Loading cache: 100%
 |###| ETA:
  00:00:00
 Loaded 2 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 NOTE: Preparing runqueue
 NOTE: Executing RunQueue Tasks
 NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/
 a.bb, do_build)
 ERROR: T variable not set, unable to build
 ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
 failed with exit code '1'
 NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
 rerun and 1 failed.

  Summary: 1 task failed:
   /home/pturley/Workspace/Hello/LayerA/a.bb, do_build
 Summary: There was 1 ERROR message shown, returning a non-zero exit
 code.


  As you can see, BitBake is expecting the T variable to be set.  I
 don't think I've ever seen this variable -- so I don't know what it's for
 or what I should change.

  Can anyone offer a hint?


  


  ├── build
 │   │
 │   ├── classes
 │   │   │
 │   │   └── base.bbclass
 │   │
 │   │   +---
 │   │   |  addtask listtasks
 │   │   |
 │   │   |  do_listtasks[nostamp] = 1
 │   │   |
 │   │   |  python do_listtasks() {
 │   │   |  import sys
 │   │   |  # emit variables and shell functions
 │   │   |  #bb.data.emit_env(sys.__stdout__, d)
 │   │   |  # emit the metadata which isnt valid shell
 │   │   |  for e in d.keys():
 │   │   |  if d.getVarFlag(e, 'task'):
 │   │   |  bb.plain(%s % e)
 │   │   |  }
 │   │   |
 │   │   |  addtask build
 │   │   |
 │   │   |  do_build() {
 │   │   |  echo Hello
 │   │   |  }
 │   │   +---
 │   │
 │   └── conf
 │   │
 │   ├── bblayers.conf
 │   │
 │   │   +---
 │  

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

[Warning: lengthy post, and probably boring to most.]

My Bitbake Hello World is a little more than a basic Hello World. It's
idea is to incorporate a layer and use a structure similar to what OE and
Yocto are using. You can do it simpler if you want to. I did this a while
ago with Bitbake 1.12.0. I would think it works with newer versions too
although I have not tested it. This is the layout I am using:

bbtest/
├── conf
│   ├── bblayers.conf
│   └── bitbake.conf
├── downloads
│   └── /* need to create but will be populated with downloads */
├── meta-test
│   ├── classes
│   │   └── base.bbclass
│   ├── conf

│   │   └── layer.conf

│   └── recipes-test

│   └── nano

│ └── nano.bb

└── tmp

└── /* will be created and populated when building */

The first thing Bitbake looks for is a conf/bblayers.conf file in the
directory you started it from. This file must provide an initial setting
for BBPATH:

bblayers.conf:

BBPATH := ${TOPDIR}
BBFILES ?= 
BBLAYERS =  \
  ${TOPDIR}/meta-test \
  

Without BBPATH Bitbake will not find any conf/filename.conf files and
recipe files at all. It will also not find bitbake.conf. I simply copied
bitbake.conf from the Bitbake download and edited DL_DIR:

bitbake.conf:

# comments omitted
B = ${S}

CVSDIR = ${DL_DIR}/cvs

DEPENDS = 

DEPLOY_DIR = ${TMPDIR}/deploy
DEPLOY_DIR_IMAGE = ${DEPLOY_DIR}/images
DL_DIR = ${TOPDIR}/downloads
FETCHCOMMAND = 
FETCHCOMMAND_cvs = /usr/bin/env cvs -d${CVSROOT} co ${CVSCOOPTS}
${CVSMODULE}
FETCHCOMMAND_svn = /usr/bin/env svn co ${SVNCOOPTS} ${SVNROOT}
${SVNMODULE}
FETCHCOMMAND_wget = /usr/bin/env wget -t 5 --passive-ftp -P ${DL_DIR}
${URI}
FILESDIR = ${@bb.utils.which(bb.data.getVar('FILESPATH', d, 1), '.')}
FILESPATH =
${FILE_DIRNAME}/${PF}:${FILE_DIRNAME}/${P}:${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}
FILE_DIRNAME = ${@os.path.dirname(bb.data.getVar('FILE', d))}
GITDIR = ${DL_DIR}/git
IMAGE_CMD = _NO_DEFINED_IMAGE_TYPES_
IMAGE_ROOTFS = ${TMPDIR}/rootfs
MKTEMPCMD = mktemp -q ${TMPBASE}
MKTEMPDIRCMD = mktemp -d -q ${TMPBASE}
OVERRIDES = local:${MACHINE}:${TARGET_OS}:${TARGET_ARCH}
P = ${PN}-${PV}
PERSISTENT_DIR = ${TMPDIR}/cache
PF = ${PN}-${PV}-${PR}
PN = ${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0]
or 'defaultpkgname'}
PR = ${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[2]
or 'r0'}
PROVIDES = 
PV = ${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[1]
or '1.0'}
RESUMECOMMAND = 
RESUMECOMMAND_wget = /usr/bin/env wget -c -t 5 --passive-ftp -P ${DL_DIR}
${URI}
S = ${WORKDIR}/${P}
SRC_URI = file://${FILE}
STAMP = ${TMPDIR}/stamps/${PF}
SVNDIR = ${DL_DIR}/svn
T = ${WORKDIR}/temp
TARGET_ARCH = ${BUILD_ARCH}
TMPDIR = ${TOPDIR}/tmp
UPDATECOMMAND = 
UPDATECOMMAND_cvs = /usr/bin/env cvs -d${CVSROOT} update ${CVSCOOPTS}
UPDATECOMMAND_svn = /usr/bin/env svn update ${SVNCOOPTS}
WORKDIR = ${TMPDIR}/work/${PF}
PERSISTENT_DIR = ${TMPDIR}/cache

That's more than you need but it's convenient.

Bitbake will require a base.bbclass file somewhere in a classes
subdirectory of BBPATH. I used the base.bbclass file from the Bitbake
download. As a minimum it should contain a do_build task. That's the target
that Bitbake invokes by default if you do not use the -c option explicitly.
It's empty and does not do anything but it functions as an anchor for tasks
you define in your recipes:

base.bbclass:

# comments omitted
die() {
bbfatal $*
}

bbnote() {
echo NOTE: $*
}

bbwarn() {
echo WARNING: $*
}

bbfatal() {
echo FATAL: $*
exit 1
}

addtask showdata
do_showdata[nostamp] = 1
python do_showdata() {
import sys
# emit variables and shell functions
bb.data.emit_env(sys.__stdout__, d, True)
# emit the metadata which isnt valid shell
for e in bb.data.keys(d):
if bb.data.getVarFlag(e, 'python', d):
sys.__stdout__.write(\npython %s () {\n%s}\n %
(e, bb.data.getVar(e, d, 1)))
}

addtask listtasks
do_listtasks[nostamp] = 1
python do_listtasks() {
import sys
for e in bb.data.keys(d):
if bb.data.getVarFlag(e, 'task', d):
sys.__stdout__.write(%s\n % e)
}

addtask build
do_build[dirs] = ${TOPDIR}
do_build[nostamp] = 1
python base_do_build () {
bb.note(The included, default BB base.bbclass does not define a
useful default task.)
bb.note(Try running the 'listtasks' task against a .bb to see what
tasks are defined.)
}

EXPORT_FUNCTIONS do_clean do_mrproper do_build

Again, it's more than you need. It's just convenient to use it. I put this
file inside the layer but you can also create a classes directory in
${TOPDIR} (bbtest in this example). Next, create a layer (meta-bbtest in my
example, name does not matter, meta-* is convention). It needs a
conf/layer.con file:

layer.conf:

# We have a metadata layer directory, add to BBPATH
BBPATH .= :${LAYERDIR}

# We have a recipe directory, add to BBFILES
BBFILES 

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Rudolf Streif]

I eventually had to clean out the sstate-cache to make it work. Not a big
deal and not probably not worth any further investigation. Thanks for
helping.

:rjs

On Thu, Oct 4, 2012 at 1:22 AM, Martin Jansa martin.ja...@gmail.com wrote:

 On Thu, Oct 04, 2012 at 09:43:58AM +0300, Andrei Gherzan wrote:
  There were some issues with libffi while updating the package. Maybe some
  bumps were missed. So:

  1. This is not new build. In this case a pull on master should fix it. I
  think I saw some pr bumps sent as patch.

 Yes but I did PR bumps only of packages in my feed

 http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029759.html

  2. If 1. won't work, recompile libowl si libclutter as a workaround.

 wont fix it on target

 Cheers,

 
  ag
   On Oct 4, 2012 4:40 AM, Rudolf Streif rudolf.str...@linux.com
 wrote:
 
   No, nothing extra. But you are right about the number of tasks. I
 checked
   out master a while ago, built successfully back then, now pulled the
 latest
   today, and reused the build environment. I will try again with a fresh
   environment.
  
   :rjs
   On Oct 3, 2012 6:35 PM, Saul Wold s...@linux.intel.com wrote:
  
   On 10/03/2012 04:21 PM, Rudolf Streif wrote:
  
   I checked out Poky from Master and tried to build core-image-minimal.
   do_rootfs failed on the libffi dependency [1]. Is that
 known/expected?
  
This is interesting, I just tried it also, and it is working, see
 below.
  
  
:rjs
  
   
  
   [1]
  
   bitbake core-image-minimal
   Loading cache: 100%
   |#**##**
   #|
   ETA:  00:00:00
   Loaded 1131 entries from dependency cache.
  
   Build Configuration:
   BB_VERSION= 1.16.0
   TARGET_ARCH   = i586
   TARGET_OS = linux
   MACHINE   = qemux86
   DISTRO= poky
   DISTRO_VERSION= 1.2+snapshot-20121003
   TUNE_FEATURES = m32 i586
   TARGET_FPU= 
   meta
   meta-yocto
   meta-yocto-bsp= master:**09aaad16be178bd675750aa6cfe7a3**
   73d7c9a8a6
  
   NOTE: Resolving any missing task queue dependencies
   NOTE: Preparing runqueue
   NOTE: Executing SetScene Tasks
   NOTE: Executing RunQueue Tasks
   ERROR: Function failed: do_rootfs (see
   /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
   linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
   for further information)
   ERROR: Logfile of failure stored in:
   /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
   linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
   Log data follows:
   | DEBUG: Executing shell function do_rootfs
   | Generating solve db for
   /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/qemux86...
   | Generating solve db for
   /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/i586...
   | Generating solve db for
   /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
   | Generating solve db for
   /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
   | Processing packagegroup-core-tools-**profile...
   | Processing packagegroup-core-boot...
   | Processing packagegroup-core-tools-**testapps...
   | Processing packagegroup-core-tools-debug.**..
   | error: Failed dependencies:
   |   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
   |   libffi.so.5 is needed by
   clutter-box2d-0.12.1+git1+**de5452e56b537a11fd7f9453d048ff**
   4b4793b5a2-r1.qemux86
   |   libffi.so.5 is needed by
  
 libowl-av0-0.1+git1+**03030c41ea578cfa74a2ffceb87567**5b248318ae-r3.i586
   |   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.**i586
   | ERROR: Function failed: do_rootfs (see
   /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
   linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
   for further information)
   ERROR: Task 7
   (/data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
   core-image-minimal.bb http://core-image-minimal.bb
   http://core-image-minimal.bb**, do_rootfs) failed with exit code
 '1'
   NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need
 to
   be rerun and 1 failed.
   No currently running tasks (3890 of 3892)
  
The number of tasks and including lttng-viewer and clutter seems to
 be
   lartger than core-image-minimal, do you have anything in the
 local.conf?
  
   Sau!
  
Summary: 1 task failed:
  
   /data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
   core-image-minimal.bb http://core-image-minimal.bb
   http://core-image-minimal.bb**, do_rootfs
   Summary: There was 1 ERROR message shown, returning a non-zero exit
 code.
  
  
  
   __**_
   yocto mailing list
   yocto@yoctoproject.org
   https://lists.yoctoproject.**org/listinfo/yocto
 https://lists.yoctoproject.org/listinfo/yocto
  
  
   ___
   yocto mailing list
   yocto@yoctoproject.org
   https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Rudolf Streif]

 hmmm clearing sstate generally should not be needed. I wonder if there
 is something to fix here
 but now you have blown up you cache :)


Fair enough. Hindsight. I should have moved it. There will be a next
time
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

Disclaimer: I am no Bitbake expert. I just put this together by rummaging
through the Bitbake code for a couple of minutes. I am reasonably confident
that what I am saying below is rather accurate but the Bitbake experts know
better.


Indeed it is.  One of my first tasks will be to *remove* as much as
 possible from this until the only thing it does is print out Hello,
 World!  I'll be happy to share my results if anyone is interested.

 You can just do a recipe and overwrite do_build() in it e.g.

python do_build() {
bb.note(Hello World)
}


 If I understand correctly, the name of the task is build, and the name
 of the Python function that implements it is do_build().  So, it appears
 BitBake prefixes all task names with do_ to derive the name of the
 function that implements the task.  Have I got that right?


Yes. All tasks defined in recipes or classes have to follow the naming
convention do_taskname when defining them. However, when adding them to
the queue you have to omit the do_ e.g. addtask taskname.



  The build task is *required*, and it's the *only* one that's required?


No task is really required. The build task is only the default task if you
do not specify a specific task with -c. However, if you use -c Bitbake will
only execute that task and not check and run any task that this task is
depending on. But that's a whole different story.



  I've been looking around in the BitBake source code a lot, so I'm
 *somewhat* familiar with it.  I tried to find the hard reference to
 do_build you described,  but I couldn't.  Can you give me a hint?

 In bitbakedir/lib/bb/cooker.py:

class BBCooker:

Manages one bitbake build run


def __init__(self, configuration, server_registration_cb):

# stuff omitted

if not self.configuration.cmd:
self.configuration.cmd = bb.data.getVar(BB_DEFAULT_TASK,
self.configuration.data, True) or build

  # more stuff

Bitbake checks if the variable BB_DEFAULT_TASK is set and if not uses
build as default task. You could set BB_DEFAULT_TASK in a configuration
file e.g. bitbake.conf to any task you like (as long as it is defined).


  I see here that you're creating the recipe-specific do_fetch()
 function, which seems intended to override the default do_fetch()
 provided by the base class.  This prompts some questions:


My  base.bbclass file does not have a do_fetch function. What am I missing?



  1) Must a task function be a Python function?  Or will a bash function
 do?


Tasks must be Python functions.


  2) Is it absolutely necessary to follow a recipe-specific task function
 with an addtask?  Based on experience from real object-oriented
 languages, a naive observer (like me) would guess the simple presence of
 do_fetch() in the recipe is all that's necessary.  Or is it the addtask
 that actually slots the new function in?

   You have to use addtask to make your Python function, given it follows
the naming convention, known to Bitbake as a task. You can put addtask with
the tasks name anywhere in your recipe. It does not need to follow the task
but it makes it easier to read. If you just add a task using addtask it is
kind of standalone. If you use addtask with the before/after directives you
establish an execution order.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

 And one final question: Have I been putting this on the wrong mailing
list?

Kind of, but you would not have gotten my response because I do not
subscribe to bitbake-devel :)

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

 And one final question: Have I been putting this on the wrong mailing
list?

Possibly, kind of, but you would not have gotten my response because I do
not follow to bitbake-devel :)

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of Hello, World!

[Rudolf Streif]

Hi Patrick,

I think I understand what you are looking for. I created this Bitbake Hello
World for a training class. It just uses 'raw' Bitbake and a very basic
recipe to build the Nano editor (including download from the project site).

You need to have a couple of things in place to make this work. I got to
run but I will get back to it and post it.

:rjs

On Wed, Oct 3, 2012 at 3:56 PM, Patrick Turley
patricktur...@gamestop.comwrote:

 In my previous message, some of the indentation in the representation of
 my file tree was wrong (because we're using Outlook, which destroy all
 indentation when you paste it into an e-mail message). The errors are
 small, but I want to avoid annoying anyone who might think I don't even
 have the file tree constructed correctly.

 The following is accurate:

 /home/pturley/Workspace/woohoo
 |
 +-- build
 |   |
 |   +-- classes
 |   |   |
 |   |   +-- base.bbclass
 |   |
 |   | +---
 |   | | do_hello() {
 |   | | echo Hello
 |   | | }
 |   | |
 |   | | addtask hello
 |   | +---
 |   |
 |   +-- conf
 |   |
 |   +-- bblayers.conf
 |   |
 |   | +---
 |   | | BBLAYERS ?=  \
 |   | |   /home/pturley/Workspace/woohoo/LayerA \
 |   | |   
 |   | +---
 |   |
 |   +-- bitbake.conf
 |
 | +---
 | | CACHE = ${TOPDIR}/cache
 | +---
 |
 +-- LayerA
 |   |
 |   +-- a.bb
 |   |
 |   | +---
 |   | | PN = 'a'
 |   | | PV = '1'
 |   | +---
 |   |
 |   +-- conf
 |   |
 |   +-- layer.conf
 |
 | +---
 | | BBPATH .= :${LAYERDIR}
 | | BBFILES += ${LAYERDIR}/*.bb
 | +---
 |
 +-- BitBake ...
 
 The BitBake directory origin is:
 
 http://git.openembedded.org/bitbake/
 
 I have the 1.15.2 tag checked out, which is what
 Yocto denzil uses.

 ___
 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] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Rudolf Streif]

I checked out Poky from Master and tried to build core-image-minimal.
do_rootfs failed on the libffi dependency [1]. Is that known/expected?

:rjs



[1]

bitbake core-image-minimal
Loading cache: 100%
||
ETA:  00:00:00
Loaded 1131 entries from dependency cache.

Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH   = i586
TARGET_OS = linux
MACHINE   = qemux86
DISTRO= poky
DISTRO_VERSION= 1.2+snapshot-20121003
TUNE_FEATURES = m32 i586
TARGET_FPU= 
meta
meta-yocto
meta-yocto-bsp= master:09aaad16be178bd675750aa6cfe7a373d7c9a8a6

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Logfile of failure stored in:
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
Log data follows:
| DEBUG: Executing shell function do_rootfs
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/qemux86...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/i586...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Processing packagegroup-core-tools-profile...
| Processing packagegroup-core-boot...
| Processing packagegroup-core-tools-testapps...
| Processing packagegroup-core-tools-debug...
| error: Failed dependencies:
|   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
|   libffi.so.5 is needed by
clutter-box2d-0.12.1+git1+de5452e56b537a11fd7f9453d048ff4b4793b5a2-r1.qemux86
|   libffi.so.5 is needed by
libowl-av0-0.1+git1+03030c41ea578cfa74a2ffceb875675b248318ae-r3.i586
|   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.i586
| ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Task 7 (/data/Develop/yocto-develop/poky/meta/recipes-core/images/
core-image-minimal.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to be
rerun and 1 failed.
No currently running tasks (3890 of 3892)

Summary: 1 task failed:
  /data/Develop/yocto-develop/poky/meta/recipes-core/images/
core-image-minimal.bb, do_rootfs
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The term Package as used in the YP docs

[Rudolf Streif]

+1

I agree with Scott's definition. In the general Linux context a Package is
a compilation of binaries, documentation, development files, etc. wrapped
up in a format that can be used by a package management system to install
it on a target system.

It is somewhat confusing that YP and OE use the term 'package' synonymously
with 'recipe'. In most cases a package is the output of a recipe.

I am all for making this more consistent at least to start with in the
documentation. Unfortunately, changing variables like P, PN, PV, PR etc.
may cause some pain. If a transition is what the broader community would
like to achieve then a period where old and new variables can be used
interchangeably (if possible) would be the way to go.

:rjs

On Fri, Sep 28, 2012 at 11:14 AM, Rifenbark, Scott M 
scott.m.rifenb...@intel.com wrote:

  This post will have some strong opinions and responses.  But, I want to
 throw this out as a re-write of the term “Package” as defined in the YP
 Development Manual’s “Terms” section.  I gave this a shot based on my brief
 understanding and on some email that was tossed about a while back on the
 term.  What I would like to ultimately come up with is a definition that
 works for the term as we want to use it in the YP docs and also as an
 explanation for some of our older variable names like PR, PV, and so forth
 that really refer to recipes.  Please thrash over it….

 ** **

 **· ***Package:* In the context of the Yocto Project, this term
 refers to the packaged output from a baked recipe. A package is generally
 the compiled binaries produced from the recipe's sources. You ‘bake’
 something by running it through BitBake.

 It is worth noting that the term package can, in general, have subtle
 meanings. For example, the packages refered to in the The 
 Packageshttp://www.yoctoproject.org/docs/1.3/yocto-project-qs/yocto-project-qs.html#packages
 section are compiled binaries that when installed add functionality to your
 Linux distribution.

 Another point worth noting is that historically within the Yocto Project,
 recipes were referred to as packages - thus, the existence of several
 BitBake variables that are seemingly mis-named, (e.g. 
 PRhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PR,
 PRINChttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PRINC,
 PVhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PV,
 and 
 PEhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PE).
 

 ** **

 ** **

 *Scott Rifenbark***

 Intel Corporation

 Yocto Project Documentation

 503.712.2702

 503.341.0418 (cell)

 ** **

 ___
 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] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image

[Rudolf Streif]

In Denil modifying kernel parameters and doing

bitbake linux-yocto -c compile -f
bitbake linux-yocto

worked perfectly fine. The tasks after compile were rerun and the new
kernel copied to tmp/deploy/images

In Edison 7.0.1 this does not seem to work anymore. The tasks do not rerun
and the kernel image is not deployed.

What has changed? Why does it not work anymore?

Thanks,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image

[Rudolf Streif]

Thanks, Chris. From what bitbake version on is that command available? The
bitbake version bundled with YP Denzil 7.0.1 is 1.15.2 and it does not
recognize that command:

...
bitbake: error: no such option -C

Rudi

On Wed, Sep 12, 2012 at 8:08 AM, Chris Larson clar...@kergoth.com wrote:

 On Wed, Sep 12, 2012 at 8:06 AM, Rudolf Streif rudolf.str...@linux.com
 wrote:
  bitbake linux-yocto -c compile -f
  bitbake linux-yocto
 
  worked perfectly fine. The tasks after compile were rerun and the new
 kernel
  copied to tmp/deploy/images
 
  In Edison 7.0.1 this does not seem to work anymore. The tasks do not
 rerun
  and the kernel image is not deployed.

 I'd suggest using bitbake's new -C argument. Run bitbake -C compile
 linux-yocto.
 --
 Christopher Larson

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

Re: [yocto] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image

[Rudolf Streif]

Thanks. That explains -C. But what happened to -f in the 1.15.2? It seems
that it does not trigger a rerun of the dependent tasks anymore when
bitbake is invoked again specifying the package only.

I am actually teaching a class right now and it happens to all of the
systems including my dev box. So it's not isolated to one system only.

Thanks,
Rudi

On Wed, Sep 12, 2012 at 9:01 AM, Paul Eggleton 
paul.eggle...@linux.intel.com wrote:

 On Wednesday 12 September 2012 08:16:46 Rudolf Streif wrote:
  Thanks, Chris. From what bitbake version on is that command available?
 The
  bitbake version bundled with YP Denzil 7.0.1 is 1.15.2 and it does not
  recognize that command:
 
  ...
  bitbake: error: no such option -C

 That's correct. This has been implemented in master (and will be in the
 upcoming stable release).

 Cheers,
 Paul

 --

 Paul Eggleton
 Intel Open Source Technology Centre

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

Re: [yocto] Eclipse Juno Plugin?

[Rudolf Streif]

Hi Axel,

The autotools.ui package is there in Juno given that you installed
Autotools support for CDT. However, it's a newer version and the YP Eclipse
plugin 1.2 requires exactly version 1.0.0 of the CDT Autotools support.

Until the 1.3 plugin is released and you can point Eclipse to the download
site you will have to build it yourself.

Rudi
On Sep 3, 2012 6:54 AM, Axel Beierlein belatro...@freenet.de wrote:

 Hello,

 is it right that Eclipse Juno need the Plugin Ver. 1.3?

 When i try to install the 1.2.1 Version of the Plugin in Juno, i get the
 Error that autotools.ui was required.

 -- Missing requirement: Yocto Plugin IDE 1.2.0.201206291757
 (org.yocto.sdk.ide 1.2.0.201206291757) requires 'bundle
 org.eclipse.linuxtools.cdt.autotools.ui 1.0.0' but it could not be found --

 Where is this Package in Juno? The former installation of the Autotools
 Package was successful.

 Axel
 ___
 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] Beaglebone BSP for denzil?

[Rudolf Streif]

Yes, I will share it once I got it working. It's not that much a function
of if and how but more of when. My time during the next couple of weeks
will be mostly consumed by the Linux Foundation's Automotive Linux Summit.

Cheers,
Rudi

On Mon, Sep 3, 2012 at 2:44 AM, Anders Darander and...@chargestorm.sewrote:

 * Rudolf Streif rstr...@linuxfoundation.org [120901 08:15]:

  Yes, there were a lot of patches that I applied to the upstream kernel.
 It
  worked but I do not think that they are all required. That's what I am
  currently trying to figure out.

 Sounds interesting!

 Do plan to share your efforts in a layer somewhere?

 Cheers,
 Anders


  On Aug 31, 2012 8:03 PM, Khem Raj raj.k...@gmail.com wrote:

  On Fri, Aug 31, 2012 at 6:44 PM, Rudolf Streif
  rstr...@linuxfoundation.org wrote:
   Hey Scott,
  
   I am doing the same thing for a Linux Foundation class.
  
   The root filesystem that YP builds for the BBoard works just fine
 for the
   BBone. That's at least true for core-image-minimal. I tested that
 with
  the
   kernel that comes with the BBone.
  
   The kernel does not work. The BBoard has an OMAP3 CPU the BBoard
 has an
   AM3359 CPU.
  
   I built a kernel with YP from kernel.org some patches and a
 defconfig. My
   goal is to use linux-yocto so I started from scratch and did not
 use
   meta-ti. And it's educational too.
  
   I still used MLO and UBoot that came with the BBone. My next steps
 are to
   build the kernel using linux-yocto and then eventually also
 building
  UBoot
   with YP.

  you need to add the right .config and may be patches. But there are
 lot
  of patches see meta-ti for more details.

  
   I can give more info but right now I am just typing this on a
 mobile with
  no
   access to my dev box. I will follow up.
  
   Cheers,
   Rudi
  
   On Aug 31, 2012 4:11 PM, Scott Garman scott.a.gar...@intel.com
 wrote:
  
   Hello,
  
   Am I correct in understanding that the TI Beagleboard BSP from
   yoctoproject.org should work with the Beaglebone, or do I need
 meta-ti?
  I'm
   not looking for accelerated graphics or anything - this will just
 be
  used in
   a classroom setting where there will be Beaglebones I'd like to
 boot up
  to a
   minimal console image.
  
   I'll be doing this with the denzil release.
  
   Thanks,
  
   Scott
  
   --
   Scott Garman
   Embedded Linux Engineer - Yocto Project
   Intel Open Source Technology Center
   ___
   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 mailing list
  yocto@yoctoproject.org
  https://lists.yoctoproject.org/listinfo/yocto

 --
 Anders Darander
 ChargeStorm AB / eStorm AB
 ___
 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] Beaglebone BSP for denzil?

[Rudolf Streif]

Yes, there were a lot of patches that I applied to the upstream kernel. It
worked but I do not think that they are all required. That's what I am
currently trying to figure out.
On Aug 31, 2012 8:03 PM, Khem Raj raj.k...@gmail.com wrote:

 On Fri, Aug 31, 2012 at 6:44 PM, Rudolf Streif
 rstr...@linuxfoundation.org wrote:
  Hey Scott,
 
  I am doing the same thing for a Linux Foundation class.
 
  The root filesystem that YP builds for the BBoard works just fine for the
  BBone. That's at least true for core-image-minimal. I tested that with
 the
  kernel that comes with the BBone.
 
  The kernel does not work. The BBoard has an OMAP3 CPU the BBoard has an
  AM3359 CPU.
 
  I built a kernel with YP from kernel.org some patches and a defconfig.
 My
  goal is to use linux-yocto so I started from scratch and did not use
  meta-ti. And it's educational too.
 
  I still used MLO and UBoot that came with the BBone. My next steps are to
  build the kernel using linux-yocto and then eventually also building
 UBoot
  with YP.

 you need to add the right .config and may be patches. But there are lot
 of patches see meta-ti for more details.

 
  I can give more info but right now I am just typing this on a mobile
 with no
  access to my dev box. I will follow up.
 
  Cheers,
  Rudi
 
  On Aug 31, 2012 4:11 PM, Scott Garman scott.a.gar...@intel.com
 wrote:
 
  Hello,
 
  Am I correct in understanding that the TI Beagleboard BSP from
  yoctoproject.org should work with the Beaglebone, or do I need
 meta-ti? I'm
  not looking for accelerated graphics or anything - this will just be
 used in
  a classroom setting where there will be Beaglebones I'd like to boot up
 to a
  minimal console image.
 
  I'll be doing this with the denzil release.
 
  Thanks,
 
  Scott
 
  --
  Scott Garman
  Embedded Linux Engineer - Yocto Project
  Intel Open Source Technology Center
  ___
  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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Beaglebone BSP for denzil?

[Rudolf Streif]

Hey Scott,

I am doing the same thing for a Linux Foundation class.

The root filesystem that YP builds for the BBoard works just fine for the
BBone. That's at least true for core-image-minimal. I tested that with the
kernel that comes with the BBone.

The kernel does not work. The BBoard has an OMAP3 CPU the BBoard has an
AM3359 CPU.

I built a kernel with YP from kernel.org some patches and a defconfig. My
goal is to use linux-yocto so I started from scratch and did not use
meta-ti. And it's educational too.

I still used MLO and UBoot that came with the BBone. My next steps are to
build the kernel using linux-yocto and then eventually also building UBoot
with YP.

I can give more info but right now I am just typing this on a mobile with
no access to my dev box. I will follow up.

Cheers,
Rudi
On Aug 31, 2012 4:11 PM, Scott Garman scott.a.gar...@intel.com wrote:

 Hello,

 Am I correct in understanding that the TI Beagleboard BSP from
 yoctoproject.org should work with the Beaglebone, or do I need meta-ti?
 I'm not looking for accelerated graphics or anything - this will just be
 used in a classroom setting where there will be Beaglebones I'd like to
 boot up to a minimal console image.

 I'll be doing this with the denzil release.

 Thanks,

 Scott

 --
 Scott Garman
 Embedded Linux Engineer - Yocto Project
 Intel Open Source Technology Center
 __**_
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Beaglebone BSP for denzil?

[Rudolf Streif]

Typo correction: the BBone has an AM3359 CPU.
On Aug 31, 2012 6:44 PM, Rudolf Streif rstr...@linuxfoundation.org
wrote:

 Hey Scott,

 I am doing the same thing for a Linux Foundation class.

 The root filesystem that YP builds for the BBoard works just fine for the
 BBone. That's at least true for core-image-minimal. I tested that with the
 kernel that comes with the BBone.

 The kernel does not work. The BBoard has an OMAP3 CPU the BBoard has an
 AM3359 CPU.

 I built a kernel with YP from kernel.org some patches and a defconfig. My
 goal is to use linux-yocto so I started from scratch and did not use
 meta-ti. And it's educational too.

 I still used MLO and UBoot that came with the BBone. My next steps are to
 build the kernel using linux-yocto and then eventually also building UBoot
 with YP.

 I can give more info but right now I am just typing this on a mobile with
 no access to my dev box. I will follow up.

 Cheers,
 Rudi
 On Aug 31, 2012 4:11 PM, Scott Garman scott.a.gar...@intel.com wrote:

 Hello,

 Am I correct in understanding that the TI Beagleboard BSP from
 yoctoproject.org should work with the Beaglebone, or do I need meta-ti?
 I'm not looking for accelerated graphics or anything - this will just be
 used in a classroom setting where there will be Beaglebones I'd like to
 boot up to a minimal console image.

 I'll be doing this with the denzil release.

 Thanks,

 Scott

 --
 Scott Garman
 Embedded Linux Engineer - Yocto Project
 Intel Open Source Technology Center
 __**_
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto


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

[yocto] [Eclipse ADT] Eclipse plugin download site is not a valid Eclipse site

[Rudolf Streif]

The download site
http://downloads.yoctoproject.org/releases/eclipse-plugin/1.2.1/indigo/ for
the Eclipse plugin is not a correctly setup Eclipse download site. The site
root does not have the correct layout for Eclipse to be able to recognize
it:

site root/
content.jar
artifacts.jar
features/
feature archives
plugins/
plug-in archives
binary/
binary artifact archives

However, the file org.yocto.sdk-rc1-201206291755-archive.zip looks as if it
contains the correct site layout. The
file org.yocto.sdk-rc1-201206291755.zip does contain the features and
plugins only however time stamps in the file names and file sizes differ
from the ones contained in org.yocto.sdk-rc1-201206291755-archive.zip.

Could anybody please shed some light on this?

Thanks,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ADT] Sysroot setup issue

[Rudolf Streif]

Hi Jessica,

Thanks while responding while on vacation.

No worries. I have resolved the NFS boot issue. I entirely missed that my
dev system had a firewall running blocking ports 3048 and 3049 used by the
user-space rpc.mountd and rpc.nfsd daemons that runquemu-export-rootfs sets
up. My fault. Sorry about that.

The kernel images may be an incorrect expectation from my side. I checked
the ADT installer scripts and they do not seem to do anything with the
kernel images they download. From my point of view it would make sense to
copy them into sysroot/boot.

The adt_installer.conf file suggests that minimal, minimal-dev, sato,
sato-dev, sato-sdk,lsb, lsb-dev, lsb-sdk are valid images
for YOCTOADT_ROOTFS_arch, but really only the *-dev and *-sdk images make
sense for an ADT as the others are missing the dev headers and libs.

While the ADT installer downloads all the image files specified in
YOCTOADT_ROOTFS_arch it really only extracts the one specified
by YOCTOADT_TARGET_SYSROOT_IMAGE_arch into the location specified
by YOCTOADT_TARGET_SYSROOT_LOC_arch. If you keep the installer files
around you can of course later install them with runqemu-extract-sdk but
that's not necessarily intuitive.

I eventually extracted all the sysroot images into separate directories and
created a link to the one I wanted to use with the name specified
by YOCTOADT_TARGET_SYSROOT_LOC_arch. That works well.

I don't know what the overall direction of development for the ADT
installer is but I could make some patches to address these items if that
makes sense to the community.

:rjs



On Wed, Aug 22, 2012 at 5:16 PM, Zhang, Jessica jessica.zh...@intel.comwrote:

  Hi Rudi,

 ** **

 I’m currently on vacation so have very limited access to my YP setup.
  We’ve been using the sysroot and nfs like below to start qemu after
 adt-installation, can you give it a try to see whether there’s problem or
 not?

 ** **

 Runqemu youradtinstallerdir/download_image/bzImage-qemux86.bin
 ${HOME}/test-yocto/x86

 ** **

 ** **

 Scott,

 ** **

 Can you help answer or look into the boot dir missing kernel file issue
 that Rudi’s reporting to see whether it’s a bug on our end?

 ** **

 Thanks,

 Jessica

 ** **

 *From:* yocto-boun...@yoctoproject.org [mailto:
 yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif
 *Sent:* Tuesday, August 21, 2012 1:17 PM
 *To:* yocto@yoctoproject.org
 *Subject:* [yocto] [ADT] Sysroot setup issue

 ** **

 Hi, 

 ** **

 I am trying to setup the ADT using an ADT installer. I have downloaded the
 installer from
 http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/adt_installer/ as
 well as created my own installer using a build environment with Denzil
 7.0.1.

 ** **

 The adt_installer.conf contains these settings:

 ** **

 YOCTOADT_REPO=http://adtrepo.yoctoproject.org/1.2.1

 YOCTOADT_TARGETS=arm x86

 YOCTOADT_QEMU=Y

 YOCTOADT_NFS_UTIL=Y

 ** **

 YOCTOADT_ROOTFS_arm=minimal

 YOCTOADT_TARGET_SYSROOT_IMAGE_arm=minimal

 YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm

 ** **

 YOCTOADT_ROOTFS_x86=minimal

 YOCTOADT_TARGET_SYSROOT_IMAGE_x86=minimal

 YOCTOADT_TARGET_SYSROOT_LOC_x86=$HOME/test-yocto/x86

 ** **

 The installer downloads kernel and root fs images. After the installation
 has finished

 ** **

 ${HOME}/test-yocto/arm/boot does not contain any kernel images and

 ** **

 ${HOME}/test-yocto/x86/boot only contains a empty link bzImage -
 bzImage-3.2.18-yocto-standard

 ** **

 I manually copied the x86 kernel image bzImage-qemux86.bin from the
 download_image directory of the extracted installer tarball into the
 directory, initialized the ADT environment and then ran

 ** **


 runqemu ${HOME}/test-yocto/x86/boot/bzImage-qemux86.bin ${HOME}/test-yocto/x86
 

 ** **

 The NFS user-space server initializes on the tap0 interface and the kernel
 boots. However, it panics because it cannot locate the root fs. rpcbind is
 started with the -i option on my system.

 ** **

 I also ran QEMU directly using:

 ** **

 /opt/poky/1.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu -kernel
 /home/rudi/test-yocto/x86/boot/bzImage-qemux86.bin -show-cursor -usb
 -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append
 root=/dev/nfs nfsroot=192.168.100.199://home/rudi/test-yocto/x86 rw
 ip=192.168.100.38::192.168.100.199:255.255.255.0 mem=128M
 oprofile.timer=1 

 ** **

 with my dev system's NFS server running and exporting the file system (I
 verified that I can mount the exported file system via NFS).

 ** **

 Questions:

1. Why do the sysroot boot directory not contain any kernel images? I
don't think that is what it is supposed to be.
2. Is there anything broken with the sysroot causing the boot process
to fail when the kernel tries to access the root fs?
3. Any hints on how to fix it?

  Thanks,

 Rudi

Re: [yocto] Building linux-yocto kernel for BeagleBone

[Rudolf Streif]

Thank you Sanyaade. That's what I tried and I probably should have added
some more detail to my first e-mail.

Here it is:

I create at beaglebone.conf machine configuration with this content:

#@TYPE: Machine
#@NAME: BeagleBone machine
#@DESCRIPTION: Machine configuration for the http://beagleboard.org/boneboard

PREFERRED_PROVIDER_virtual/xserver = xserver-xorg
XSERVER = xserver-xorg \
   xf86-input-evdev \
   xf86-video-fbdev

# Only has DVI connector for external screen
GUI_MACHINE_CLASS = bigscreen

# Ship all kernel modules by default
MACHINE_EXTRA_RRECOMMENDS =  kernel-modules

# Allow for MMC booting (required by the NAND-less Beagleboard XM)
EXTRA_IMAGEDEPENDS += u-boot x-load

# 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 ?= cortexa8hf-neon

SOC_FAMILY = ti33x
require conf/machine/include/soc-family.inc

require conf/machine/include/tune-cortexa8.inc

IMAGE_FSTYPES += tar.bz2 jffs2
EXTRA_IMAGECMD_jffs2 = -lnp 

# 2.6.37 and later kernels use OMAP_SERIAL, ttyO0
SERIAL_CONSOLE = 115200 ttyO0

PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto
PREFERRED_VERSION_linux-yocto ?= 3.0%

KERNEL_IMAGETYPE = uImage

UBOOT_MACHINE = am335x_evm_config
UBOOT_ENTRYPOINT = 0x80008000
UBOOT_LOADADDRESS = 0x80008000

MACHINE_FEATURES = apm usbgadget usbhost vfat alsa

I created a linux-yocto_3.0.bbappend with this content:

KMACHINE_beaglebone = yocto/standard/beagleboard
SRCREV_machine_beaglebone ?= 8fd5a8eb4067c7032389e82d54f0e54e1e27f78c
COMPATIBLE_MACHINE_beaglebone = beaglebone

Then I am trying to boot the BeagleBone with the kernel:

reading uImage



3016584 bytes read

## Booting kernel from Legacy Image at 8200 ...

   Image Name:   Linux-3.0.24-yocto-standard

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:3016520 Bytes = 2.9 MiB

   Load Address: 80008000

   Entry Point:  80008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK



Starting kernel ...


And this is where the boot process hangs.


One suggestion here is that machine id of uBoot and the kernel to not
match. I am using MLO and u-boot.img from the SD that shipped with the
BBone. And I set UBOOT_MACHINE = am335x_evm_config in beaglebone.conf
which is what uBoot should be using.

I also tried a plain BeagleBoard kernel and MLO and u-boot.img created by
Yocto and it did not work.

Any suggestions would be appreciated.

Rudi


On Sun, May 27, 2012 at 12:34 PM, Sanyaade Adekoya sanya...@gmail.comwrote:

 Hi,
 According to Ti, BeagleBone is just a small BeagleBoard in a small factor
 so a common base like a bare build for BeagleBoard should run
 on BeagleBone. I think the is same for OMAP family.

 God blesses!!!

 Best regards,
 Sanyaade


 On 25 May 2012 23:52, Rudolf Streif rudolf.str...@linux.com wrote:

 Has anyone tried to build a linux-yocto kernel for the BeagleBone? I
 understand that there is the meta-ti layer to build an image for the BBone
 but the recipes are not utilizing the Yocto Project kernels.

 I know that the OMAP3 CPU of the BBoard is different form the AM355x CPU
 on the BBone. However, can the yocto/standard/beagleboard branch be
 leveraged to start off?

 Thanks,
 Rudi

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



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