Re: [yocto] Kernel configuration fragments and defconfig from kernel source tree, not meta layer file

[Bruce Ashfield]

On Tue, Mar 17, 2015 at 1:57 PM, Alex J Lennon
 wrote:
> Hi,
>
> I've been looking into a request to have Yocto kernel configuration
> fragment support in meta-raspberrypi with a defconfig which is pulled
> from the kernel source tree for the configured machine.
>
> My understanding is that Yocto expects the defconfig file to be supplied
> in the meta-layer and then configured with SRC_URI += "file://defconfig"
>
> We'd prefer not to maintain copies of defconfigs, instead using the true
> default configuration from the kernel tree and allowing users to add
> their own .cfg fragments to the SRC_URI via, say, .bbappends.

Anyone who knows me, knows that I'd say I hate to see defconfigs
at all ;)

But back on topic, this is something I can change, it is simply that
when I first put together the linux-yocto kernel configuration steps,
that most defconfigs were actually out of tree, and not within the kernel
tree itself.

>
> It's easy enough to _prepend() a function to copy the appropriate
> defconfig from the kernel source to the working directory, but I am
> having a problem as do_patch() in kernel-yocto.bbclass seems to require
> a defconfig file from the layer itself via use of SRC_URI in find_sccs().
>
> Any thoughts? Thanks,

Pop an enhancement request into the yocto bugzilla and assign it to
me. I can take care of it from there.

But just to be clear, this will have to stay out of oe-core for a bit, since
it is past feature freeze for 1.8 and even bug fixes are cut off shortly.

Cheers,

Bruce

>
> Alex
>
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto master work-shared, kernel .config seems to have gone awol

[Bruce Ashfield]

On 2015-03-30 01:36 PM, Alex J Lennon wrote:

Hi,

I'm updating to Yocto master and have been seeing that when I bitbake -c
devshell virtual/kernel I go into a work-shared tree now.


There was a discussion on the list about this. See the patch from
Ross:

[OE-core] [PATCH] devshell: allow the starting directory to be overridden

Since there are those that want to be in the source dir, and those
that want to be in the build dir .. there's a variable to make that
change.



(This is all with meta-fsl-arm)

I'd normally change the kernel configuration with bitbake -c menuconfig
virtual/kernel then pull out the .config and make my changes to
defconfig as needed.


In this case, you need to be in the source tree, but have your output
pointing to the build dir.

That used to be set when you dropped into the devshell, check and see
if KBUILD_OUTPUT is set.



But I can't seem to find it any more, either in work-shared or if I
traverse to the work tree.

No doubt my own stupidity here but where is it supposed to be nowadays?

Could anybody point me to a discussion on how things are going to be
broken out into work-shared and (presumably) work so I can get up to speed?


Most of the changes are documented in the commits that make the switch,
and you'll see them proposed on the oe-core mailing list by Richard,
with me following up with comments and details.

Bruce



Not finding the configuration I thought I'd try generating a kernel
fragment with bitbake  -c diffconfig virtual/kernel from the Yocto docs
but I can't see a fragment.cfg anywhere in the tree

I guess this could all be just that meta-fsl-arm isn't quick in sync
with current the current master? (assuming it's not the more likely
explanation that I just have this plain wrong)

Thanks,

Alex



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

Re: [yocto] "fatal: A branch named 'meta-orig' already exists."

[Bruce Ashfield]

On 2015-03-31 6:26 PM, Robert P. J. Day wrote:


   oh, what fresh hell is this?

... snip ...
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_validate_branches (log file is located at
/home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524)
ERROR: Logfile of failure stored in:
/home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| NOTE: Setting branch meta to
9e70b482d3773abf92c9c5850e134cbca1d5651f
| fatal: A branch named 'meta-orig' already exists.

   this is building core-image-minimal for qemux86, and i'm assuming
this is not fedora rawhide related.


You've got a borked tree sitting in work-shared. If you clean-all
and start again, does it show up ?

If it repeats, then it very well could be the version of git in
rawhide that is causing the issue.

Bruce



rday



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

Re: [yocto] "fatal: A branch named 'meta-orig' already exists."

[Bruce Ashfield]

On 2015-04-01 3:07 AM, Robert P. J. Day wrote:

On Tue, 31 Mar 2015, Bruce Ashfield wrote:


On 2015-03-31 6:26 PM, Robert P. J. Day wrote:


oh, what fresh hell is this?

... snip ...
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_validate_branches (log file is located at
/home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524)
ERROR: Logfile of failure stored in:
/home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| NOTE: Setting branch meta to
9e70b482d3773abf92c9c5850e134cbca1d5651f
| fatal: A branch named 'meta-orig' already exists.

this is building core-image-minimal for qemux86, and i'm assuming
this is not fedora rawhide related.


You've got a borked tree sitting in work-shared. If you clean-all
and start again, does it show up ?

If it repeats, then it very well could be the version of git in
rawhide that is causing the issue.


   i started with a fresh build, got a validate_branches error, and
used "bb" to dump the log file for that step:


There's definitely something wrong or a strange integration between
the version of git and that tree.

Without a place to poke at this, there's not much I can say about
actually changing that behaviour.

All my local builds are green, all the yocto release builds are green,
etc, so this is somehow specific to your build and location
environment.

This is on a fully up to date master ?

Bruce



/ START /

DEBUG: Executing shell function do_validate_branches
NOTE: Setting branch meta to 9e70b482d3773abf92c9c5850e134cbca1d5651f
error: The following untracked working tree files would be removed by checkout:
.gitignore
.mailmap
COPYING
CREDITS
Documentation/00-INDEX
Documentation/ABI/README
Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads
Documentation/ABI/obsolete/sysfs-bus-usb
Documentation/ABI/obsolete/sysfs-class-rfkill
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra
Documentation/ABI/removed/devfs
Documentation/ABI/removed/dv1394
Documentation/ABI/removed/ip_queue
Documentation/ABI/removed/net_dma
Documentation/ABI/removed/o2cb
Documentation/ABI/removed/raw1394
Documentation/ABI/removed/video1394
Documentation/ABI/stable/firewire-cdev
Documentation/ABI/stable/o2cb
Documentation/ABI/stable/syscalls
Documentation/ABI/stable/sysfs-acpi-pmprofile
Documentation/ABI/stable/sysfs-bus-firewire
Documentation/ABI/stable/sysfs-bus-usb
Documentation/ABI/stable/sysfs-bus-xen-backend
Documentation/ABI/stable/sysfs-class-backlight
Documentation/ABI/stable/sysfs-class-rfkill
Documentation/ABI/stable/sysfs-class-tpm
Documentation/ABI/stable/sysfs-class-ubi
Documentation/ABI/stable/sysfs-class-udc
Documentation/ABI/stable/sysfs-devices-node
Documentation/ABI/stable/sysfs-devices-system-cpu
Documentation/ABI/stable/sysfs-devices-system-xen_memory
Documentation/ABI/stable/sysfs-driver-ib_srp
Documentation/ABI/stable/sysfs-driver-qla2xxx
Documentation/ABI/stable/sysfs-driver-usb-usbtmc
Documentation/ABI/stable/sysfs-driver-w1_ds28e04
Documentation/ABI/stable/sysfs-firmware-efi-vars
Documentation/ABI/stable/sysfs-firmware-opal-dump
Documentation/ABI/stable/sysfs-firmware-opal-elog
Documentation/ABI/stable/sysfs-module
Documentation/ABI/stable/sysfs-transport-srp
Documentation/ABI/stable/thermal-notification
Documentation/ABI/stable/vdso
Documentation/ABI/testing/configfs-spear-pcie-gadget
Documentation/ABI/testing/configfs-usb-gadget
Documentation/ABI/testing/configfs-usb-gadget-acm
Documentation/ABI/testing/configfs-usb-gadget-ecm
Documentation/ABI/testing/configfs-usb-gadget-eem
Documentation/ABI/testing/configfs-usb-gadget-ffs
Documentation/ABI/testing/configfs-usb-gadget-hid
Documentation/ABI/testing/configfs-usb-gadget-loopback
Documentation/ABI/testing/configfs-usb-gadget-mass-storage
Documentation/ABI/testing/configfs-usb-gadget-midi
Documentation/ABI/testing/configfs-usb-gadget-ncm
Documentation/ABI/testing/configfs-usb-gadget-obex
Documentation/ABI/testing/configfs-usb-gadget-phonet
Documentation/ABI/testing/configfs-usb-gadget-rndis
Documentation/ABI/testing/configfs-usb-gadget-

Re: [yocto] "fatal: A branch named 'meta-orig' already exists."

[Bruce Ashfield]

On Wed, Apr 1, 2015 at 7:24 AM, Robert P. J. Day  wrote:
> On Wed, 1 Apr 2015, Bruce Ashfield wrote:
>
>> On 2015-04-01 3:07 AM, Robert P. J. Day wrote:
>> > On Tue, 31 Mar 2015, Bruce Ashfield wrote:
>> >
>> > > On 2015-03-31 6:26 PM, Robert P. J. Day wrote:
>> > > >
>> > > > oh, what fresh hell is this?
>> > > >
>> > > > ... snip ...
>> > > > NOTE: Preparing RunQueue
>> > > > NOTE: Executing SetScene Tasks
>> > > > NOTE: Executing RunQueue Tasks
>> > > > ERROR: Function failed: do_validate_branches (log file is located at
>> > > > /home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524)
>> > > > ERROR: Logfile of failure stored in:
>> > > > /home/rpjday/oe/builds/qemux86/tmp/work/qemux86-poky-linux/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/temp/log.do_validate_branches.17524
>> > > > Log data follows:
>> > > > | DEBUG: Executing shell function do_validate_branches
>> > > > | NOTE: Setting branch meta to
>> > > > 9e70b482d3773abf92c9c5850e134cbca1d5651f
>> > > > | fatal: A branch named 'meta-orig' already exists.
>> > > >
>> > > > this is building core-image-minimal for qemux86, and i'm assuming
>> > > > this is not fedora rawhide related.
>> > >
>> > > You've got a borked tree sitting in work-shared. If you clean-all
>> > > and start again, does it show up ?
>> > >
>> > > If it repeats, then it very well could be the version of git in
>> > > rawhide that is causing the issue.
>> >
>> >i started with a fresh build, got a validate_branches error, and
>> > used "bb" to dump the log file for that step:
>>
>> There's definitely something wrong or a strange integration between
>> the version of git and that tree.
>>
>> Without a place to poke at this, there's not much I can say about
>> actually changing that behaviour.
>>
>> All my local builds are green, all the yocto release builds are green,
>> etc, so this is somehow specific to your build and location
>> environment.
>>
>> This is on a fully up to date master ?
>
> ... snip ...
>
>   yup. and i realize that fedora rawhide isn't supported here, but if
> there's something funky about fedora rawhide that's causing this, best
> to figure it out earlier than later. i'll try more testing later, but
> i've redone this test three times, same result each time.


I completely agree .. better to sort this out sooner rather than later, I'm just
trying to narrow down on a  configuration that allows me to see the problem
and poke at the smouldering pile. If git is doing something different now, it
won't be hard to fix, but hands on, versus code inspection, is the real
trick here.

Bruce

>
> 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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [kernel config]: specified values did not make it into the kernel's final configuration

[Bruce Ashfield]

On Fri, Apr 3, 2015 at 4:34 PM, Liam Maps  wrote:
> Hi,
>
> During the build of a core-image-base for BeagleBone using the master branch
> I was presented with the following warning:
>
> "WARNING: [kernel config]: specified values did not make it into the
> kernel's final configuration:"
>
> The full list of configuration values, which did not make it into kernel's
> configuration can be found here:
> http://pastebin.com/sAvXuNC8
>
> Most variables seem to have something to do with things which are not
> applicable for my particular build and device. There is no need for any
> graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed
> anyway. But there are a few which look less innocent such as for example
> CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO.
>
> I did a few builds with poky-dizzy-12.0.1 before moving to the master branch
> and the mentioned warning was not issued during those builds.
>
> The only information about the warning I was able to find on the web is
> this:
> http://patchwork.openembedded.org/patch/89289/
>
> So it seems that this is not that critical and somewhere during the build
> process some kernel configuration values are dropped. Since I do not have
> enough knowledge about the subject I would like to ask the more
> knowledgeable of you to reassure me that this warning is not critical. Also,
> if someone could give an example of why some values are dropped and by
> who/what, I would be most grateful.

They are just that .. warnings. We have a patch for the beaglebone to clean up
the input configs, it just didn't make it into master yet.

Old values, values missing dependencies, etc, all may be dropped by the
kernel configuration phase. The tools detect and warn if this happens, since
it may be critical (i.e. boot failure) or not .. and if not, it does
indicate that
the input configuration fragments need some cleaning.

Cheers,

Bruce


>
> I should probably mention that I can successfully deploy the build despite
> the warnings and everything works as expected. Well, there is one thing and
> that is that one of requested packages is not built (ntfs-3g) but that is an
> issue for another thread, if I am unable to find the solution myself.
>
> Thank you.
>
> FYI: I am new to Yocto and this mailing list
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [kernel config]: specified values did not make it into the kernel's final configuration

[Bruce Ashfield]

On Sat, Apr 4, 2015 at 3:55 PM, Liam Maps  wrote:
> Thank you for the info. But who sets the .config "Requested value" of a
> configuration variable and who then overrides it and sets the "Actual value
> set"? (The quoted text is from the [kernel config] warning.)

The kernel development manual covers the details, but the linux-yocto
tree carries
meta-data that describes the baseline BSP (patches and configuration), and then
configuration fragments and more patches are applied on top based on what is
specified via recipes.

Either those fragments, or the baseline configuration can have kernel config
values that are missing dependencies or aren't valid for a given kernel (i.e.
right after a new version has been introduced, there is some initial skew to
adapt to new options).

I only just re-exposed the configuration audit details to the build
output, so what you
see now, was happening before .. it was just hidden. Now that it is visible, the
motivation to keep things up to date and clean is there.

>
> After a bit of research this is what I think I know:
> For my example when working with the master branch and building for
> BeagleBone, the CONFIG_ARCH_NR_GPIO config value gets set to 512 in the
> meta/cfg/kernel-cache/bsp/beaglebone/beaglebone.cfg. So the beaglebone bsp
> for the kernel.

Correct, that's the baseline BSP configuration I mentioned above.

> Somewhere that value then gets set to 0. But I can't find out where and by
> who. Shouldn't the bsp values be the final ones? It's the bsp who knows most
> about the target device after all. Or am I mistaken?

That's the actual kernel Kconfig* values. They have a range restriction that
is changing what is specified in that fragment to a value that is valid for the
kernel in question. So no matter what we set it to, the kernel configuration
system (i.e. korg, not yocto) has the final say. That's more than often what you
are seeing when those values change.

Bruce

>
> Thank you.
>
>
>
> On 04/04/2015 08:10 PM, Bruce Ashfield wrote:
>>
>> On Fri, Apr 3, 2015 at 4:34 PM, Liam Maps  wrote:
>>>
>>> Hi,
>>>
>>> During the build of a core-image-base for BeagleBone using the master
>>> branch
>>> I was presented with the following warning:
>>>
>>> "WARNING: [kernel config]: specified values did not make it into the
>>> kernel's final configuration:"
>>>
>>> The full list of configuration values, which did not make it into
>>> kernel's
>>> configuration can be found here:
>>> http://pastebin.com/sAvXuNC8
>>>
>>> Most variables seem to have something to do with things which are not
>>> applicable for my particular build and device. There is no need for any
>>> graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and
>>> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed
>>> anyway. But there are a few which look less innocent such as for example
>>> CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO.
>>>
>>> I did a few builds with poky-dizzy-12.0.1 before moving to the master
>>> branch
>>> and the mentioned warning was not issued during those builds.
>>>
>>> The only information about the warning I was able to find on the web is
>>> this:
>>> http://patchwork.openembedded.org/patch/89289/
>>>
>>> So it seems that this is not that critical and somewhere during the build
>>> process some kernel configuration values are dropped. Since I do not have
>>> enough knowledge about the subject I would like to ask the more
>>> knowledgeable of you to reassure me that this warning is not critical.
>>> Also,
>>> if someone could give an example of why some values are dropped and by
>>> who/what, I would be most grateful.
>>
>> They are just that .. warnings. We have a patch for the beaglebone to
>> clean up
>> the input configs, it just didn't make it into master yet.
>>
>> Old values, values missing dependencies, etc, all may be dropped by the
>> kernel configuration phase. The tools detect and warn if this happens,
>> since
>> it may be critical (i.e. boot failure) or not .. and if not, it does
>> indicate that
>> the input configuration fragments need some cleaning.
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>> I should probably mention that I can successfully deploy the build
>>> despite
>>> the warnings and everything works as expected. Well, there is one thing
>>> and
>>> that is that one of requested packages is not built (ntfs-3g) but that is
>>> an
>>> issue for another thread, if I am unable to find the solution myself.
>>>
>>> Thank you.
>>>
>>> FYI: I am new to Yocto and this mailing list
>>> --
>>> ___
>>> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The error of task do_validate_branches

[Bruce Ashfield]

On 2015-04-13 11:14 PM, neil...@emerson.com wrote:

Hi, all

I build the custom linux-yocto kernel, it appears the error as bellow :


Hi Neil,

Can you provide a bit more information ? What release/branch are you
building ?

Obviously you are building a variant of linux-yocto that wasn't
released as part of the project (since we don't have a tiam335x
recipe), is there a place that recipe can be found ?



ERROR: Function failed: do_validate_branches (log file is located at
/home/ectrs/poky/coretexa8/tmp/work/am335x_evm-poky-linux-gnueabi/linux-yocto-tiam335x/3.12.10--SS-r0/temp/log.do_validate_branches.4899)

ERROR: Logfile of failure stored in:
/home/ectrs/poky/coretexa8/tmp/work/am335x_evm-poky-linux-gnueabi/linux-yocto-tiam335x/3.12.10--SS-r0/temp/log.do_validate_branches.4899

Log data follows:

| DEBUG: Executing shell function do_validate_branches

| NOTE: custom recipe is being built, forcing SRCREV to INVALID

| NOTE: SRCREV validation skipped for AUTOREV or empty meta branch

| fatal: A branch named 'master-orig' already exists.

| fatal: ambiguous argument 'INVALID': unknown revision or path not in
the working tree.


These errors are pointing to an invalid or somehow corrupted/partially
built kernel git repository being used.

I assume that you've tried a clean/cleanll on the kernel recipe and
then rebuilt ?

Bruce



| Use '--' to separate paths from revisions, like this:

| 'git  [...] -- [...]'

| WARNING: exit code 128 from a shell command.

| ERROR: Function failed: do_validate_branches (log file is located at
/home/ectrs/poky/coretexa8/tmp/work/am335x_evm-poky-linux-gnueabi/linux-yocto-tiam335x/3.12.10--SS-r0/temp/log.do_validate_branches.4899)

ERROR: Task 69
(/home/ectrs/poky/meta-emerson-ecosys/recipes-kernel/linux/linux-yocto-tiam335x_3.12.10.bb,
do_validate_branches) failed with exit code '1'

How to resolve this problem? if you know please help me.

Thanks

Neil





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

Re: [yocto] SRCREV Issue for custom linux kernel

[Bruce Ashfield]

On 2015-04-14 6:48 AM, Raghavendra Kakarla wrote:

Hi All,

I got the an error while i am checking out the linux kernel from the SVN to 
build in the YOCTO project environment.



What release is this ? master ? An older release ?

And are you seeing this same error if you have a kernel recipe
that builds from git ? i.e. one of the Yocto reference boards
with a similar SRCREV ?

The yocto kernel's expect to be able to validate the commits
and then modify the tree with additional git commands, so the
tree is either in git format, or is converted to a git format
(in the case of a tgz) .. so it could be that the SVN checkout
is preventing that conversion from happening.

Bruce


Could please help me in resolving the Issue.


Error log is:
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| NOTE: custom recipe is being built, forcing SRCREV to INVALID
| NOTE: SRCREV validation skipped for AUTOREV or empty meta branch
| fatal: ambiguous argument 'INVALID': unknown revision or path not in the 
working tree.
| Use '--' to separate paths from revisions
| WARNING: exit code 128 from a shell command.
| ERROR: Function failed: do_validate_branches (log file is located at 
/home/testuser/poky/build/tmp/work/dhruva-poky-linux/linux-yocto-custom/3.10.14-r0/temp/log.do_validate_branches.6852)


Thanks in advance.

Regards,

Raghavendra K.

From: yocto-boun...@yoctoproject.org  on behalf of 
yocto-requ...@yoctoproject.org 
Sent: Tuesday, April 14, 2015 2:50 PM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 55, Issue 46

Send yocto mailing list submissions to
 yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
 yocto-requ...@yoctoproject.org

You can reach the person managing the list at
 yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

1. Re: yocto Digest, Vol 53, Issue 97 (Raghavendra Kakarla)


--

Message: 1
Date: Tue, 14 Apr 2015 09:20:38 +
From: Raghavendra Kakarla 
To: "yocto@yoctoproject.org" 
Subject: Re: [yocto] yocto Digest, Vol 53, Issue 97
Message-ID: <1429003199394.19...@inedasystems.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi All,

When I take kernel from the SVN I got the validation error that SRCREV is not 
proper.

Could you please help me in resolving this issue.

Thanks in advance.

Regards,
Raghavendra.



From: yocto-boun...@yoctoproject.org  on behalf of 
yocto-requ...@yoctoproject.org 
Sent: Saturday, February 21, 2015 4:04 AM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 53, Issue 97

Send yocto mailing list submissions to
 yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
 yocto-requ...@yoctoproject.org

You can reach the person managing the list at
 yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

1. Re: Simple recipe quit working in dizzy (akuster)


--

Message: 1
Date: Fri, 20 Feb 2015 14:28:10 -0800
From: akuster 
To: yocto@yoctoproject.org
Subject: Re: [yocto] Simple recipe quit working in dizzy
Message-ID: <54e7b4fa@mvista.com>
Content-Type: text/plain; charset=windows-1252; format=flowed



On 02/20/2015 09:49 AM, Jim Rafert wrote:

Hi Paul,

Thank you for taking an interest in this.

I looked at the log.do_rootfs, and didn't see anything that was immediately 
suspicious.
I have inlined the log at the end of my reply, here.

I don't see how such a simple recipe could be broken by a Yocto bug, and not 
have the
whole thing be massively broken.


Is it possible for you to try your recipe on 'master'? that might tell
use if something is missing in dizzy.


- Armin


-Jim-

cat ./core-image-full-cmdline/1.0-r0/temp/log.do_rootfs
DEBUG: Executing python function rootfs_process_ignore
DEBUG: Python function rootfs_process_ignore finished
DEBUG: Executing python function rootfs_runtime_mapping
DEBUG: Python function rootfs_runtime_mapping finished
DEBUG: Executing python function do_rootfs
NOTE: configuring RPM platform settings
NOTE: configuring RPM system provides
NOTE: configuring RPM DB settings
NOTE: configuring Smart settings
NOTE: Note: adding Smart channel spectra_ls (35)
NOTE: Note: adding Smart channel i586 (30)
NOTE: Note: adding Smart channel all (25)
NOTE: adding Smart RPM DB channel
NOTE: Note: configuring RPM cross-install scriptlet_wrapper
NOTE: ## Gene

Re: [yocto] Move device tree generation from include file to bbclass

[Bruce Ashfield]

On 2015-04-15 08:33 AM, Bach, Pascal wrote:

Hi



Adding oe-core, since that's the right place to have a discussion like
this.


As ARM now also moved to device tree it look like in future we will have more 
kernels that are using device tree then ones that are not.


True, but it has been like this for quite some time now :)


As far as I understand currently the generation of device trees is controlled 
via KERNEL_DEVICETREE and is handled in via an include file 
recipes-kernel/linux/linux-dtb.inc.

I was thinking about moving this include into a class so it becomes easier to 
use. Before I dive into implementing something I would like some feedback from 
the community.


The big trick with changing anything like this is compatibility with
existing recipes. Whatever we do, existing recipes and layers shouldn't
be broken .. or if they are broken, there should be a compelling
technical reason to do so.



I have the following variant in mind.

Add the device tree generation to the current kernel.bbclass (or let 
kernel.bblcass inherit from a kernel-dtb.bbclass).
This way all kernels would automatically be DT enabled.
The class would check if KERNEL_DEVICETREE is set and generate device trees 
based on this information. For boards that don't have KERNEL_DEVICETREE set the 
class would do nothing and the behavior is like before.
The advantage I see with this approach is that the only thing a user needs to 
do is to set KERNEL_DEVICETREE in the board and make sure the device trees are 
available in the kernel they like to build.


That's pretty much the experience that most users have now, since
there's nearly always a kernel recipe created, that recipe includes
linux-dtb.inc, and sets KERNEL_DEVICETREE.

Everything else happens to build and package the device tree.

Was there something specifically that was causing issues with the
current way of building them ?

Cheers,

Bruce



I appreciate your feedback?

Regards
Pascal



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

Re: [yocto] Move device tree generation from include file to bbclass

[Bruce Ashfield]

On Wed, Apr 15, 2015 at 11:22 AM, Nikolay Dimitrov  wrote:
> Hi Bruce,
>
>
> On 04/15/2015 04:13 PM, Bruce Ashfield wrote:
>>
>> On 2015-04-15 08:33 AM, Bach, Pascal wrote:
>>>
>>> Hi
>>>
>>
>> Adding oe-core, since that's the right place to have a discussion
>> like this.
>>
>>> As ARM now also moved to device tree it look like in future we will
>>>  have more kernels that are using device tree then ones that are
>>> not.
>>
>>
>> True, but it has been like this for quite some time now :)
>>
>>> As far as I understand currently the generation of device trees is
>>>  controlled via KERNEL_DEVICETREE and is handled in via an include
>>> file recipes-kernel/linux/linux-dtb.inc.
>>>
>>> I was thinking about moving this include into a class so it becomes
>>>  easier to use. Before I dive into implementing something I would
>>> like some feedback from the community.
>>
>>
>> The big trick with changing anything like this is compatibility with
>> existing recipes. Whatever we do, existing recipes and layers
>> shouldn't be broken .. or if they are broken, there should be a
>> compelling technical reason to do so.
>>
>>>
>>> I have the following variant in mind.
>>>
>>> Add the device tree generation to the current kernel.bbclass (or
>>> let kernel.bblcass inherit from a kernel-dtb.bbclass). This way all
>>> kernels would automatically be DT enabled. The class would check if
>>> KERNEL_DEVICETREE is set and generate device trees based on this
>>> information. For boards that don't have KERNEL_DEVICETREE set the
>>> class would do nothing and the behavior is like before. The
>>> advantage I see with this approach is that the only thing a user
>>> needs to do is to set KERNEL_DEVICETREE in the board and make sure
>>> the device trees are available in the kernel they like to build.
>>
>>
>> That's pretty much the experience that most users have now, since
>> there's nearly always a kernel recipe created, that recipe includes
>> linux-dtb.inc, and sets KERNEL_DEVICETREE.
>
>
> As far as I understood, Pascal's idea is to remove the need for user
> recipes to include linux-dtb.inc, and provide this functionality via
> inheritance.

That is obvious. My questions are around "why". There's no big
technical advantage, and if you remove that existing file, you break
existing recipes. Which means you need to leave a stub in place.

So without a technical advantage, it's churn for the sake of
churn.

Bruce

>
>> Everything else happens to build and package the device tree.
>>
>> Was there something specifically that was causing issues with the
>> current way of building them ?
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> I appreciate your feedback?
>>>
>>> Regards Pascal
>>>
>>
>
> Regards,
> Nikolay
>
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Move device tree generation from include file to bbclass

[Bruce Ashfield]

On Wed, Apr 15, 2015 at 12:12 PM, Nikolay Dimitrov  wrote:
> Hi Bruce,
>
>
> On 04/15/2015 06:26 PM, Bruce Ashfield wrote:
>>
>> On Wed, Apr 15, 2015 at 11:22 AM, Nikolay Dimitrov
>>  wrote:
>>>
>>> Hi Bruce,
>>>
>>>
>>> On 04/15/2015 04:13 PM, Bruce Ashfield wrote:
>>>>
>>>>
>>>> On 2015-04-15 08:33 AM, Bach, Pascal wrote:
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>
>>>> Adding oe-core, since that's the right place to have a discussion
>>>> like this.
>>>>
>>>>> As ARM now also moved to device tree it look like in future we
>>>>> will have more kernels that are using device tree then ones
>>>>> that are not.
>>>>
>>>>
>>>>
>>>> True, but it has been like this for quite some time now :)
>>>>
>>>>> As far as I understand currently the generation of device
>>>>> trees is controlled via KERNEL_DEVICETREE and is handled in via
>>>>> an include file recipes-kernel/linux/linux-dtb.inc.
>>>>>
>>>>> I was thinking about moving this include into a class so it
>>>>> becomes easier to use. Before I dive into implementing
>>>>> something I would like some feedback from the community.
>>>>
>>>>
>>>>
>>>> The big trick with changing anything like this is compatibility
>>>> with existing recipes. Whatever we do, existing recipes and
>>>> layers shouldn't be broken .. or if they are broken, there
>>>> should be a compelling technical reason to do so.
>>>>
>>>>>
>>>>> I have the following variant in mind.
>>>>>
>>>>> Add the device tree generation to the current kernel.bbclass
>>>>> (or let kernel.bblcass inherit from a kernel-dtb.bbclass).
>>>>> This way all kernels would automatically be DT enabled. The
>>>>> class would check if KERNEL_DEVICETREE is set and generate
>>>>> device trees based on this information. For boards that don't
>>>>> have KERNEL_DEVICETREE set the class would do nothing and the
>>>>> behavior is like before. The advantage I see with this
>>>>> approach is that the only thing a user needs to do is to set
>>>>> KERNEL_DEVICETREE in the board and make sure the device trees
>>>>> are available in the kernel they like to build.
>>>>
>>>>
>>>>
>>>> That's pretty much the experience that most users have now, since
>>>> there's nearly always a kernel recipe created, that recipe
>>>> includes linux-dtb.inc, and sets KERNEL_DEVICETREE.
>>>
>>>
>>>
>>> As far as I understood, Pascal's idea is to remove the need for
>>> user recipes to include linux-dtb.inc, and provide this
>>> functionality via inheritance.
>>
>>
>> That is obvious. My questions are around "why". There's no big
>> technical advantage, and if you remove that existing file, you break
>>  existing recipes. Which means you need to leave a stub in place.
>>
>> So without a technical advantage, it's churn for the sake of churn.
>
>
> Well, removing redundancy and simplifying users' recipes could be
> considered an advantage. Also, as the contents of linux-dtb.inc are
> going to be moved to bbclass, the file can be left empty, later
> maintainers remove the extra line from all users' recipes in following
> commits. I don't see breaking as an option.

And we could argue that having more inherits in the base is a bad
thing for users that have no interest in device trees.

One person's advantage is another's churn. I was looking for technical
advantages or a plan for future features that might leverage this.

Cheers,

Bruce

>
>> Bruce
>>
>>>
>>>> Everything else happens to build and package the device tree.
>>>>
>>>> Was there something specifically that was causing issues with the
>>>> current way of building them ?
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> I appreciate your feedback?
>>>>>
>>>>> Regards Pascal
>
>
> Kind regards,
> Nikolay



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] Initramfs not appended to kernel image

[Bruce Ashfield]

On 2015-04-16 6:23 AM, Wouter van Rooy wrote:

Hello,

For the last week or so I have been struggling to build a kernel image with an embedded 
initramfs using the mechanisms provided by Poky Daisy. In local.conf I have set 
INITRAMFS_IMAGE_BUNDLE to "1" and INITRAMFS_IMAGE to the name of my image 
recipe. When I try to build virtual/kernel no errors are shown, but the resulting kernel 
image does not contain an initramfs either.


I'm the proud owner of the bugzilla to document this process better,
so let's work through the issues and see if there's a bug, or something
that just isn't clearly described.

We are talking about the 1.6 release here .. so at least the recent changes
in kernel.bbclass processing won't be the cause of the breakage.



I have traced this issue to the passing of the $use_alternate_initrd variable 
in kernel.bbclass. The run.do_bundle_initramfs log contains the following 
snippets:

Lines 103..120:

do_bundle_initramfs() {
 if [ ! -z "sytxg1-bootmode-image" -a x"1" = x1 ]; then
 echo "Creating a kernel image with a bundled initramfs..."
 copy_initramfs
 if [ -e arch/powerpc/boot/uImage ] ; then
 mv -f arch/powerpc/boot/uImage 
arch/powerpc/boot/uImage.bak
 fi
 
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/usr/sytxg1-bootmode-image-sytxg1.cpio
 kernel_do_compile
 mv -f arch/powerpc/boot/uImage 
arch/powerpc/boot/uImage.initramfs
 mv -f arch/powerpc/boot/uImage.bak arch/powerpc/boot/uImage
 # Update install area
 echo "There is kernel image bundled with initramfs: 
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
 install -m 0644 
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs
 
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/image/boot/uImage-initramfs-sytxg1.bin
 echo 
"/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
 fi
  
}


Lines 164..171:

kernel_do_compile() {
 unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
 oe_runmake uImage  CC="powerpc-oe-linux-gcc " LD="powerpc-oe-linux-ld.bfd 
"
 if test "uImage.gz" = "uImage"; then
 gzip -9c < "uImage" > "arch/powerpc/boot/uImage"
 fi
  
}


So, it seems that although do_bundle_initramfs() sets the $use_alternate_initrd to the 
correct value it is not passed in the oe_runmake call in kernel_do_compile(). Judging 
from the contents of kernel.bbclass I would expect it to be appended after the 
LD="..." statement. For now I have found a workaround by copying the relevant 
oe_runmake call to do_bundle_initramfs(). The patch is included below.

Correct, and this definitely used to work. I can't see anything wrong by
inspection alone, but will launch some builds to see if I can confirm the
behaviour and that variable not making it down into the function call.

Bruce



I cannot imagine this is the intended way to make things work. Could anyone 
please shed some light on what I am doing wrong in this matter?

Kind regards,

Wouter van Rooy


diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 19b159b..224e01e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -131,8 +131,11 @@ do_bundle_initramfs () {
if [ -e ${KERNEL_OUTPUT} ] ; then
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.bak
fi
-   
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
-   kernel_do_compile
+   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+   oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} 
CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} 
CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+   if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = 
"${KERNEL_IMAGETYPE}"; then
+   gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > 
"${KERNEL_OUTPUT}"
+   fi
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
# Update install area
@@ -150,20 +153,7 @@ addtask bundle_initramfs after do_install before do_deploy
  
  kernel_do_compile() {

unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
-   # The $use_alternate_initrd is only set from
-   # do_bundle_initramfs() This variable is specifically for the
-   # case where we are making a second pass at the kernel
-   

Re: [yocto] SRCREV Issue for custom linux kernel

[Bruce Ashfield]

On 2015-04-15 1:38 AM, Raghavendra Kakarla wrote:

Hi Bruce,

My recipe is like following:


#   oe-core kernel classes to apply a subset of yocto kernel
#   management to git managed kernel repositories.
#
# Warning:
#
#   Building this kernel without providing a defconfig or BSP
#   configuration will result in build or boot errors. This is not a
#   bug.
#
# Notes:
#
#   patches: patches can be merged into to the source git tree itself,
#added via the SRC_URI, or controlled via a BSP
#configuration.
#
#   example configuration addition:
#SRC_URI += "file://smp.cfg"
#   example patch addition:
#SRC_URI += "file://0001-linux-version-tweak.patch
#   example feature addition:
#SRC_URI += "file://feature.scc"
#

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

SRC_URI = 
"svn://192.168.24.190:9090/svn/trunk/code/kernels;module=linux-3.10.14;protocol=http;user=admin;pswd=Welcome123"


I don't have a SVN server with the linux kernel handy, so I wasn't able
to test this exact same configuration. But I can say a similar git
configuration to kernel.org, or to a tgz worked when I tried a test
build.

Looking through the code more .. this is simply a case that isn't common
or anticipated. The mixing of the SVN SRCREV and the linux-yocto-custom
means that the code that follows is looking to manipulate the tree as a
git repository.

Can you look at your linux source directory in the build, and see if
the SVN checkout has been converted to a git repo ?

If so, the workaround would be to set SRCREV_machine = "AUTOREV", and
that should short circuit the SRCREV validation that simply won't be
correct for a converted git tree.

Alternatively, you can also create an override to do_validate_branches
and stub out the functionality completely.

Bruce



SRC_URI += "file://defconfig"

SRC_URI += "file://arqlyn.scc \
 file://arqlyn.cfg \
 file://arqlyn-user-config.cfg \
 file://arqlyn-user-patches.scc \
"


LINUX_VERSION ?= "3.10.14"
LINUX_VERSION_EXTENSION ?= "-custom"
SRCREV = "94"
PR = "r0"
PV = "${LINUX_VERSION}"
S = "${WORKDIR}/linux-3.10.14"
COMPATIBLE_MACHINE_arqlyn = "arqlyn"


Regards,

Raghavendra


From: Bruce Ashfield 
Sent: Tuesday, April 14, 2015 5:36 PM
To: Raghavendra Kakarla; yocto@yoctoproject.org
Subject: Re: [yocto] SRCREV Issue for custom linux kernel

On 2015-04-14 6:48 AM, Raghavendra Kakarla wrote:

Hi All,

I got the an error while i am checking out the linux kernel from the SVN to 
build in the YOCTO project environment.



What release is this ? master ? An older release ?

And are you seeing this same error if you have a kernel recipe
that builds from git ? i.e. one of the Yocto reference boards
with a similar SRCREV ?

The yocto kernel's expect to be able to validate the commits
and then modify the tree with additional git commands, so the
tree is either in git format, or is converted to a git format
(in the case of a tgz) .. so it could be that the SVN checkout
is preventing that conversion from happening.

Bruce


Could please help me in resolving the Issue.


Error log is:
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| NOTE: custom recipe is being built, forcing SRCREV to INVALID
| NOTE: SRCREV validation skipped for AUTOREV or empty meta branch
| fatal: ambiguous argument 'INVALID': unknown revision or path not in the 
working tree.
| Use '--' to separate paths from revisions
| WARNING: exit code 128 from a shell command.
| ERROR: Function failed: do_validate_branches (log file is located at 
/home/testuser/poky/build/tmp/work/dhruva-poky-linux/linux-yocto-custom/3.10.14-r0/temp/log.do_validate_branches.6852)


Thanks in advance.

Regards,

Raghavendra K.

From: yocto-boun...@yoctoproject.org  on behalf of 
yocto-requ...@yoctoproject.org 
Sent: Tuesday, April 14, 2015 2:50 PM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 55, Issue 46

Send yocto mailing list submissions to
  yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
  https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
  yocto-requ...@yoctoproject.org

You can reach the person managing the list at
  yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

 1. Re: yocto Digest, Vol 53, Issue 97 (Raghavendra Kakarla)


--

Message: 1
Date: Tue, 14 Apr 2015 09:20:38 +
From: Raghavendra Kakarla 
To: "yocto@yoctop

Re: [yocto] SRCREV issue with linux-yocto-custom do_validate_branches()

[Bruce Ashfield]

On 2015-04-17 6:12 AM, Mills, Clayton wrote:

Hi All,

I'm having a little trouble with do_validate_branches() inherited by my 
linux-yocto-custom.
I'm building the 3.14.28 kernel with ltsi kernel patch set applied, so was 
trying to set this up with a custom linux recipe in my bsp.


Out of curiosity, was something missing in the linux-yocto 3.14 LTSI
integration ? I'll comment on the specifics below, but I was wondering
about that high level point as well.


Pointing to a branch in my own git repo that has the patch set pre-applied.
I've got a clone of dizzy. Which I used yocto-bsp create to start my bsp layer.

But the process stops in do_validate_branches() with the following error log:

DEBUG: Executing shell function do_validate_branches
usage: git cat-file (-t|-s|-e|-p||--textconv) 
or: git cat-file (--batch|--batch-check) < 

 can be one of: blob, tree, commit, tag
 -tshow object type
 -sshow object size
 -eexit with zero when there's no error
 -ppretty-print object's content
 --textconvfor blob objects, run textconv on object's content
 --batch[=]show info and content of objects fed from the 
standard input
 --batch-check[=]
   show info about objects fed from the standard input

ERROR:  is not a valid commit ID.
ERROR: The kernel source tree may be out of sync
WARNING: exit code 1 from a shell command.


Do you have the entire log pastebin'd somewhere ? It would be nice to know
if this is the meta, or machine validation that is getting an empty commit.


ERROR: Function failed: do_validate_branches (log file is located at 
/opt/git/poky/build/tmp/work/mylayer-poky-linux-gnueabi/linux-yocto-custom/3.14.28+gitAUTOINC+7035c2a67d-r0/temp/log.do_validate_branches.56991)



The do_validate_branches() code from kernel-yocto.bbclass is as follows...

# Ensure that the branches (BSP and meta) are on the locations specified by
# their SRCREV values. If they are NOT on the right commits, the branches
# are corrected to the proper commit.
do_validate_branches() {
 set +e
 cd ${S}
 export KMETA=${KMETA}

 machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"

 machine_srcrev="${SRCREV_machine}"

 # if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to
 # check and we can exit early
 if [ "${machine_srcrev}" = "AUTOINC" ]; then
 bbnote "SRCREV validation is not required for AUTOREV"
 elif [ "${machine_srcrev}" = "" ] && [ "${SRCREV}" != "AUTOINC" ]; then
 # SRCREV_machine_ was not set. This means that a 
custom recipe
 # that doesn't use the SRCREV_FORMAT "machine_meta" is being 
built. In
 # this case, we need to reset to the give SRCREV before 
heading to patching
 bbnote "custom recipe is being built, forcing SRCREV to 
${SRCREV}"
 force_srcrev="${SRCREV}"
 else
 git cat-file -t ${machine_srcrev} > /dev/null
 if [ $? -ne 0 ]; then
 bberror "${machine_srcrev} is not a valid commit ID."
 bbfatal "The kernel source tree may be out of sync"
 fi
 force_srcrev=${machine_srcrev}
 fi

 ## KMETA branch validation.
 target_meta_head="${SRCREV_meta}"
 if [ "${target_meta_head}" = "AUTOINC" ] || [ "${target_meta_head}" = 
"" ]; then
 bbnote "SRCREV validation skipped for AUTOREV or empty meta 
branch"
 else
 meta_head=`git show-ref -s --heads ${KMETA}`

 git cat-file -t ${target_meta_head} > /dev/null
 if [ $? -ne 0 ]; then
 bberror "${target_meta_head} is not a valid commit ID"
 bbfatal "The kernel source tree may be out of sync"
 fi
 if [ "$meta_head" != "$target_meta_head" ]; then
 bbnote "Setting branch ${KMETA} to ${target_meta_head}"
 git branch -m ${KMETA} ${KMETA}-orig
 git checkout -q -b ${KMETA} ${target_meta_head}
 if [ $? -ne 0 ];then
 bbfatal "Could not checkout ${KMETA} branch from 
known hash ${target_meta_head}"
 fi
 fi
 fi

 git checkout -q -f ${machine_branch}
 if [ -n "${force_srcrev}" ]; then
 # see if the branch we are about to patch has been properly 
reset to the defined
 # SRCREV .. if not, we reset it.
  

Re: [yocto] Problems enabling systemd

[Bruce Ashfield]

On 04/20/2015 04:43 AM, Anders Darander wrote:

* Matt Schuckmann  [150417 23:27]:

I've got an image for a AM3352 system based on Dylan and Arago and I'm
trying to switch to systemd for init.



So far I haven't had much luck.
First off I'm getting different results depending on where I turn it on.
I'm turning it on via the following 2 lines:



DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"


These two lines looks correct, though, if you're building a systemd-only
distro & image, you migth want to add:

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"


If I place these lines in my_image.bb file I seem to get a partial
install of systemd, systemd_udev is there and seems to run but that's
about it, there is no systemctrl journalctl and the sysvinit init
scripts still seem to be called.



And also on this point, make sure to check your PACKAGECONFIG values
for systemd. The optional utilities like networkd are not enabled by
default, and a bbapend of the systemd recipe is needed to enable them
via PACKAGECONFIG.

Cheers,

Bruce



DISTRO_FEATURES is a distro (policy) configuration, and thus, can't be
modfied in a recipe. The correct way would be to add this in your own
my_distro.conf.


If I place these lines in either local.conf or my_distrobution.conf
all of the systemd utility seem to get installed and systemd startups
up but it's clearly not configured correctly.


Good that it seems to be installed OK.


For starters the systemd dbus isn't getting created and that seems to
lead to a whole host of other problems, including journald constant
spewing the following error messages:



[   55.926223] systemd-journald[715]: Failed to write entry, ignoring: Argument 
list too long
[   55.936931] systemd-journald[715]: Failed to rotate 
/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file 
or directory
[   55.950911] systemd-journald[715]: Failed to write entry, ignoring: Argument 
list too long
[   55.961580] systemd-journald[715]: Failed to rotate 
/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file 
or directory
[   55.975568] systemd-journald[715]: Failed to write entry, ignoring: Argument 
list too long
[   55.986329] systemd-journald[715]: Failed to rotate 
/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file 
or directory



I don't know if it matters but this system has no display at all, it's
a strictly embedded installation.


That shouldn't really matter, I'm running systemd in headless setups.

I'd guess that you're getting some errors earlier than this in the
bootlog? Could you paste them?

Cheers,
Anders




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

Re: [yocto] Problems enabling systemd

[Bruce Ashfield]

On 04/20/2015 02:06 PM, Matt Schuckmann wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Monday, April 20, 2015 7:52 AM
To: Matt Schuckmann; Yocto Project
Subject: Re: [yocto] Problems enabling systemd

On 04/20/2015 04:43 AM, Anders Darander wrote:

* Matt Schuckmann  [150417 23:27]:

I've got an image for a AM3352 system based on Dylan and Arago and
I'm trying to switch to systemd for init.



So far I haven't had much luck.
First off I'm getting different results depending on where I turn it

on.

I'm turning it on via the following 2 lines:



DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"


These two lines looks correct, though, if you're building a
systemd-only distro & image, you migth want to add:

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"


If I place these lines in my_image.bb file I seem to get a partial
install of systemd, systemd_udev is there and seems to run but

that's

about it, there is no systemctrl journalctl and the sysvinit init
scripts still seem to be called.



And also on this point, make sure to check your PACKAGECONFIG values
for systemd. The optional utilities like networkd are not enabled by
default, and a bbapend of the systemd recipe is needed to enable them
via PACKAGECONFIG.

Cheers,

Bruce


Thanks for the info, Bruce I'll try a take a look. Are there any good examples 
for what to do with PACKAGECONFIG? the Yocto manual doesn't mention this at all 
for systemd.



I can share my configuration in a day or so, I'm in need of a refresh to
github, and that'll work for one reference (and one that I know works).

Otherwise, I recall that Angstrom has some systemd usecases, so cloning
and having a look at those layers would also be a good reference.

Bruce





DISTRO_FEATURES is a distro (policy) configuration, and thus, can't

be

modfied in a recipe. The correct way would be to add this in your own
my_distro.conf.


If I place these lines in either local.conf or my_distrobution.conf
all of the systemd utility seem to get installed and systemd

startups

up but it's clearly not configured correctly.


Good that it seems to be installed OK.


For starters the systemd dbus isn't getting created and that seems

to

lead to a whole host of other problems, including journald constant
spewing the following error messages:



[   55.926223] systemd-journald[715]: Failed to write entry,

ignoring: Argument list too long

[   55.936931] systemd-journald[715]: Failed to rotate

/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No
such file or directory

[   55.950911] systemd-journald[715]: Failed to write entry,

ignoring: Argument list too long

[   55.961580] systemd-journald[715]: Failed to rotate

/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No
such file or directory

[   55.975568] systemd-journald[715]: Failed to write entry,

ignoring: Argument list too long

[   55.986329] systemd-journald[715]: Failed to rotate

/run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No
such file or directory



I don't know if it matters but this system has no display at all,
it's a strictly embedded installation.


That shouldn't really matter, I'm running systemd in headless setups.

I'd guess that you're getting some errors earlier than this in the
bootlog? Could you paste them?

Cheers,
Anders









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

Re: [yocto] SRCREV issue with linux-yocto-custom do_validate_branches()

[Bruce Ashfield]

On 04/21/2015 08:21 AM, Mills, Clayton wrote:

On 17 April 2015 14:28, Bruce Ashfield wrote:

On 2015-04-17 6:12 AM, Mills, Clayton wrote:

Hi All,

I'm having a little trouble with do_validate_branches() inherited by my 
linux-yocto-custom.
I'm building the 3.14.28 kernel with ltsi kernel patch set applied, so was 
trying to set this up with a custom linux recipe in my bsp.

Out of curiosity, was something missing in the linux-yocto 3.14 LTSI 
integration ? I'll comment on the specifics below, but I was wondering about 
that high level point as well.

I'll admit I'm new to yocto so if I've missed where I could have easily 
selected v3.14.28-ltsi along the way then my bad. Unfortunate because I'm 
probably making more work for myself. Though this is probably as good an 
opportunity for learning my way around. To be honest in the very near future I 
will be building from a branch that is forked off of v3.14.28-ltsi with some 
custom stuff anyway, so perhaps this isn't a complete waste of time.

Feel free to expand on what I should be doing. Like I said, I'm new to yocto.


The kernel's that we select for release with the fall Yocto project are 
LTSI kernel versions.
As such, the LTSI changes are merged into both a standalone branch, and 
then into
each and every BSP branch in the kernel. So any of the SRCREVs that you 
get by default
for the qemu*  BSPs have the LTSI content integrated and present. For 
custom BSPs,
they can branch from standard/base and have that same LTSI content 
present in their

build.




Pointing to a branch in my own git repo that has the patch set pre-applied.
I've got a clone of dizzy. Which I used yocto-bsp create to start my bsp layer.

But the process stops in do_validate_branches() with the following error log:
--
--
DEBUG: Executing shell function do_validate_branches
usage: git cat-file (-t|-s|-e|-p||--textconv) 
 or: git cat-file (--batch|--batch-check) < 

 can be one of: blob, tree, commit, tag
  -tshow object type
  -sshow object size
  -eexit with zero when there's no error
  -ppretty-print object's content
  --textconvfor blob objects, run textconv on object's content
  --batch[=]show info and content of objects fed from the 
standard input
  --batch-check[=]
show info about objects fed from the
standard input

ERROR:  is not a valid commit ID.
ERROR: The kernel source tree may be out of sync
WARNING: exit code 1 from a shell command.

Do you have the entire log pastebin'd somewhere ? It would be nice to know if 
this is the meta, or machine validation that is getting an empty commit.


ERROR: Function failed: do_validate_branches (log file is located at
/opt/git/poky/build/tmp/work/mylayer-poky-linux-gnueabi/linux-yocto-cu
stom/3.14.28+gitAUTOINC+7035c2a67d-r0/temp/log.do_validate_branches.56
991)
--
--


The do_validate_branches() code from kernel-yocto.bbclass is as follows...
--
-- # Ensure that the branches (BSP and meta) are on the
locations specified by # their SRCREV values. If they are NOT on the
right commits, the branches # are corrected to the proper commit.
do_validate_branches() {
  set +e
  cd ${S}
  export KMETA=${KMETA}

  machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"

  machine_srcrev="${SRCREV_machine}"

  # if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to
  # check and we can exit early
  if [ "${machine_srcrev}" = "AUTOINC" ]; then
  bbnote "SRCREV validation is not required for AUTOREV"
  elif [ "${machine_srcrev}" = "" ] && [ "${SRCREV}" != "AUTOINC" ]; 
then
  # SRCREV_machine_ was not set. This means that a 
custom recipe
  # that doesn't use the SRCREV_FORMAT "machine_meta" is being 
built. In
  # this case, we need to reset to the give SRCREV before 
heading to patching
  bbnote "custom recipe is being built, forcing SRCREV to 
${SRCREV}"
  force_srcrev="${SRCREV}"
  else
  git cat-file -t ${machine_srcrev} > /dev/null
  if [ $? -ne 0 ]; then
  bberror "${machine_srcrev} is not a valid commit ID."
  bbfatal "The kernel source tree may be out of sync"
  fi
  force_srcrev=${machine_srcrev}
  fi

  

Re: [yocto] [poky] Initramfs not appended to kernel image

[Bruce Ashfield]

On 2015-04-20 05:09 AM, Wouter van Rooy wrote:

Hi Bruce,

First of all, thanks for your answer. It would be a comforting idea to
get this initramfs implemented cleanly in my project.

On 16-04-15 16:22, Bruce Ashfield wrote:

I'm the proud owner of the bugzilla to document this process better,
so let's work through the issues and see if there's a bug, or
something that just isn't clearly described. We are talking about the
1.6 release here .. so at least the recent changes in kernel.bbclass
processing won't be the cause of the breakage.

Correct, to be even more precise I am using the daisy-11.0.0 tag for Poky.

Correct, and this definitely used to work. I can't see anything wrong
by inspection alone, but will launch some builds to see if I can
confirm the behaviour and that variable not making it down into the
function call. Bruce

Thanks, I would love to hear the results of your test builds. Just drop
me a line if you need anything else from my build environment for
reproduction, like log files and such.


I was traveling last week and am just getting back to this now.
I wanted to check in to see if your issues are still persisting
to see if you worked it out in the meantime.

Bruce



Kind regards,
Wouter van Rooy


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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-04-28 02:49 AM, Schaumlöffel, Jan wrote:

Hi everyone,

I have a working root fs based on “dizzy”, for which I created a
customized machine config, a custom package config recipe and a custom
image recipe.

When running into problems with the python installation on that rootfs I
decided to upgrade to Poky 1.8 “fido”.

So I checked out the “fido” branches of the following repositories:

-git.yoctoproject.org/git/poky

-github.com/openembedded/openembedded-core.git

-github.com/openembedded/meta-openembedded.git

After that, a lot of packages were rebuilt (obviously), but everything
seemed to work, excluding the last step:

NOTE: Executing buildhistory_get_image_installed ...

DEBUG: Executing shell function buildhistory_get_image_installed

DEBUG: Shell function buildhistory_get_image_installed finished

NOTE: Executing: ldconfig -/…/mymachine
-poky-linux-gnueabi/mymachine-image/1.0-r0/rootfs-c new -v

ERROR: No kernel-abiversion file found
(/…/pkgdata/kernel-depmod/kernel-abiversion), cannot run depmod, aborting

DEBUG: Python function do_rootfs finished

ERROR: Function failed: do_rootfs

I already verified that a completely “vanilla” setup from these
repositories (i.e. source oe-init-build-env into empty directory, then
bitbake core-image-minimal) does indeed complete.

The problem is re-introduced as soon as I do not build with MACHINE ?=
“beaglebone” but with my own machine configuration. Naturally I compared
the configurations without finding anything too suspicious.

So, before I go into any further lengths about my machine configuration:
Are there any general hints why the “kernel-abiversion” file might go
missing after migrating from 1.7 to 1.8?


Hmmm. It shouldn't have gone missing. Bits of the kernel build
outputs did move around in 1.8, but the abiversion is still
generated and placed in the STAGING_KERNEL_BUILDDIR.

As for modules, it is placed in the PKGDESTWORK directory as part
of packaging.

After your build has failed, if you look in STAGING_KERNEL_BUILDDIR
do you see the abiversion file ?

Bruce




KR and TIA,

Jan





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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-04-28 11:36 AM, Schaumlöffel, Jan wrote:

Hmmm. It shouldn't have gone missing. Bits of the kernel build outputs
did move around in 1.8, but the abiversion is still generated and
placed in the STAGING_KERNEL_BUILDDIR.


I was just wondering, is there an easy way to resolve these Paths from the 
ommand line? I do not have a lot of experience with bitbake, so I have no good 
guess where STAGING_KERNEL_BUILDDIR should be located.


I always just run bitbake -e , and then either grep or
capture the output. The value and places the variable are set will be
in the bulk data export. Others may have fancier ways to do the
same thing.



Also, I don't quite get why the kernel abiversion and kernel modules are needed 
at all, because I build the kernel externally with no modules at all. Although 
in the future it might be nice to integrate building the kernel into the 
bitbake process, at the moment I would be equally happy to just leave off 
everything that has to do with the kernel.


Have you tried setting linux-dummy as the preferred provider for the
kernel ? That would skip the build processing doing anything more than
satisfying the various kernel dependencies.




After your build has failed, if you look in STAGING_KERNEL_BUILDDIR do
you see the abiversion file ?


There are three instances of the file:

~/yocto-build-fido$ find . -name kernel-abiversion
./tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14.36+gitAUTOINC+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion
./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion
./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion


Those are where I'd expect them for 1.8, so they should be found and
used by the various parts of the build process. Something different
is happening in your build .. hmm.

Bruce



Jan



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

Re: [yocto] Yocto linux-kernel

[Bruce Ashfield]

On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote:

i am using beagleboard-xm like board for my custom use. for my
development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i
downgraded).
  while bitbaking kernel, i got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| Reinitialized existing Git repository in
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
| On branch standard/base
| nothing to commit, working directory clean
| ERROR. The branch 'meta' is required and was not
| found. Ensure that the SRC_URI points to a valid linux-yocto
| kernel repository
| WARNING:
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_kernel_checkout (log file is located at
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)

due to this error i thought error can be cleared if kernel fetched from
yocto git repository, but i cat get from there,  so how do i get
kernel-2.6.32 for yocto project.


There isn't a released 2.6.32 linux-yocto version, so if you
really want that old version, you'd need to create a linux-yocto-custom
recipe for the version (unless that is what you already did).

Bruce



--
thanks and regards,
parthiban
   +919790329795




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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 04/29/2015 03:38 AM, Schaumlöffel, Jan wrote:

Have you tried setting linux-dummy as the preferred provider for the kernel
? That would skip the build processing doing anything more than satisfying
the various kernel dependencies.


Ah, that's a good hint, I'll try that.




After your build has failed, if you look in STAGING_KERNEL_BUILDDIR
do you see the abiversion file ?


There are three instances of the file:

~/yocto-build-fido$ find . -name kernel-abiversion
./tmp/work/beaglebone-poky-linux-gnueabi/linux-

yocto/3.14.36+gitAUTOIN

C+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion
./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion
./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion


Those are where I'd expect them for 1.8, so they should be found and used
by the various parts of the build process. Something different is happening in
your build .. hmm.


It looks like those were from another run, built from scratch in a new 
directory I now see the following result:


NOTE: Executing RunQueue Tasks
ERROR: No kernel-abiversion file found 
(/home/astro/yocto-build-reproduce/tmp/sysroots/u159/pkgdata/kernel-depmod/kernel-abiversion),
 cannot run depmod, aborting
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/astro/yocto-build-reproduce/tmp/work/u159-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.7440
ERROR: Task 7 
(/home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1776 tasks of which 93 didn't need to be rerun 
and 1 failed.
No currently running tasks (1775 of 1777)

Summary: 1 task failed:
   /home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
astro@eldk-vm:~/yocto-build-reproduce$ find . -name kernel-abiversion
astro@eldk-vm:~/yocto-build-reproduce$ bitbake -e core-image-minimal | grep 
STAGING_KERNEL_BUILDDIR
# $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts"
astro@eldk-vm:~/yocto-build-reproduce$ ls -la 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts
ls: cannot access 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts: 
No such file or directory
astro@eldk-vm:~/yocto-build-reproduce$

It looks like the entire STAGING_KERNEL_BUILDDIR is missing.


I'll try some more variatons of my setup to try and narrow down why that 
happens.



That is really odd. I'll be interested to hear how that happened. I just
did a test and it points to where I expect:

 [/home/bruc...poky/build]> bitbake -e core-image-minimal | grep 
STAGING_KERNEL_BUILDDIR

# $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-build-artifacts"

Bruce




Jan



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

Re: [yocto] Kernel customized do_fetch issue

[Bruce Ashfield]

On 2015-04-29 01:39 PM, Joel (Xi Zhou) Zhou wrote:

Hi all,

I created a do_fetch() for checkout in-house git repo, which is working
fine with OE.

do_fetch() {

 cd ${WORKDIR}

 rm -rf ${PN}-${PV}

 git clone ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk ${PN}-${PV}

 cd ${PN}-${PV}

 git checkout ${KBRANCH}

}

With Yocto, the do_fetch() does its job, but do_configure create an issue.

do_configure_prepend() {

 cp ${WORKDIR}/${KERNEL_CONFIG_FILE} ${S}/.config

 oe_runmake oldconfig

}

The do_configure error message:

| make: *** No rule to make target `oldconfig'.  Stop.

Basically, the kernel source checkout by do_fetch() is delete/erase
while running do_configure().

I suspect some tasks between do_fetch and do_configure are doing some
magic work of moving the kernel  source around.


It's better if you can post your entire kernel recipe, and what
branch/release you are using.

There are steps that move the kernel source into work-shared, so that
may be impacting your flow.

But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.

If you need to modify the source directory later, have a look at the
steps that I'm taking in kernel-yocto.bbclass, since that works properly
within the fetcher and build infrastructure.

Bruce



Any suggestion?

Thanks,

Joel





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

Re: [yocto] Kernel customized do_fetch issue

[Bruce Ashfield]

On 2015-04-29 02:08 PM, Joel (Xi Zhou) Zhou wrote:

But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.


The whole story is starting at the url of our git repo. We have a git URL like:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk

So the SRC_URI like this, but the fetcher try to apply "scp" over it.
KBRANCH= 3.14_common_dev
SRC_URI = 
"ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}"
Error:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-lsk'

Then I change it  according the suggestion in this mailing list:
SRC_URI = 
"git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh"

This time "bitbake linux-lsk -c fetch" return no error, but the source folder 
in working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp. 
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.


I'd expect that it part of the log, since obviously the mirrors aren't
going to have a copy of your kernel.

You really aren't seeing anything land in the build/downloads/git2/
directory structure ? ssh fetches seem to work here.

You'd be better of working through the issues and getting the right
SRC_URI specification for the fetcher, since taking the fetch into a
custom routine is going to short circuit parts of the build .. and you'll
have to take care of them yourself.

Cheers,

Bruce



Thanks,
Joel



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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-04-30 3:14 AM, Schaumlöffel, Jan wrote:

That is really odd. I'll be interested to hear how that happened. I just did a
test and it points to where I expect:

   [/home/bruc...poky/build]> bitbake -e core-image-minimal | grep
STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work-
shared/qemux86-64/kernel-build-artifacts"



So I experimented a bit more and found a minimal set of steps to reproduce the 
problem. Maybe that might give someone a clue as to what is happening and/or 
how to resolve it.

Steps to reproduce:

- clone Poky repository, checkout branch 'fido'
- go to meta-yocto-bsp/conf/machine and copy beaglebone.conf to another file (I 
used astro.conf)
- from poky repository do source oe-init-build-env into new build directory
- edit conf/local.conf to set MACHINE ?= "astro" (use filename from second 
step) and DL_DIR (if present)
- run bitbake core-image-minimal

-> kernel-abiversion is missing, build fails

- edit conf/local.conf, set MACHINE ?= "beaglebone"
- run bitbake core-image-minimal

-> image builds fine

It stays the same if the copied config is in a custom BSP layer, some minor 
modifications are made, etc., but to eliminate complexity I just put that into 
the meta-yocto-bsp layer. What strikes me as really odd is that now the only 
thing changed between working and non-working configuration seems to be the 
filename of the machine configuration - what am I missing?



What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to
another known kernel recipe ?

The big difference that I see would be the kernel recipe, and
some of the tasks not executing (and hence not generating the
abiversion file).

Bruce


How do I create a working machine configuration for Poky 1.8? (In 1.7.1 I just 
took some machine configuration from eldk, fiddled around with it a bit, put it 
into my BSP layer and never had any trouble with that.)

Regards,
Jan



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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:

What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?


How would I see which kernel recipe is used?


This is where my brute force techniques probably break down. I just
do a 'bitbake virtual/kernel' and you'll see it display which
recipe is being built.

If you haven't added compatibility for your new machine to any
recipe, I'm betting that linux-dummy is used.



I did not customize anything except for aforementioned steps, simply copied 
beaglebone.conf to astro.conf in the same directory. Also I did not touch any 
kernel recipes (kernel is built externally), maybe that's what's missing?


It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce



Jan



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

Re: [yocto] fido: out-of-tree module build fails due to wrong Module.symvers reference

[Bruce Ashfield]

On 2015-05-03 12:16 PM, Timo Korthals wrote:

Dear yocto developers,

the following "more generic" workaround worked also, which let's me
assume that the "Module.symvers" in ${S} is somehow broken?

Content of "linux-yocto_3.19.bbappend":
do_install_append() {
 cp -f ${KBUILD_OUTPUT}/Module.symvers ${STAGING_KERNEL_BUILDDIR}
}


We have a race condition in the build artifacts copy routine in fido.
The fix missed the release, but we are working through the change now
(the latest variant was posted today).

So yes, what is being copied during the build may not be the proper
.symvers file at the moment, but once do_shared_workdir() is called
directly from the kernel do_install() routine, we'll have the proper
copy in place before your out of tree module builds.

Bruce



Greetings,
Timo


On 03.05.2015 17:26, Timo Korthals wrote:

Dear yocto developers,

with the yocto projects < 1.8 we were able to build our out-of-tree
module without any linking failures, but since the upgrade to 1.8
there seems to be something wrong with the "Module.symvers".
For our external module we use exactly the same Makefile as you
proposed in hello-mod (but of course with another obj-m argument).
If we then build the module, the do_compile stage prints, what you can
find under [1].
I think the problem refers to a wrong "Module.symvers" which is used
by the MODPOST stage.

I just searched for all "Module.symvers" files in my fido work folder,
after a full build:
-rw-r--r-- 1 myName staff 528483 Apr 29 17:59
/home/myName/fido/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/linux-amiro-standard-build/Module.symvers
-rw-r--r-- 1 myName staff  0 May  3 16:22
/home/myName/fido/tmp/work/amiro-poky-linux-gnueabi/ov5647/0.0-r0/Module.symvers
-rw-r--r-- 1 myName staff 386012 Apr 29 17:58
/home/myName/fido/tmp/work-shared/amiro/kernel-build-artifacts/Module.symvers

In my old (projects < 1.8) workfolder, the "Module.symvers" files,
where distributed as follows:
-rw-r--r-- 4 myName staff 528483 Mar 11 13:48
/home/myName/tmp/sysroots/amiro/usr/src/kernel/Module.symvers
-rw-r--r-- 4 myName staff 528483 Mar 11 13:48
/home/myName/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19+gitAUTOINC+8897ef68b3_bfa76d4957-r0/image/usr/src/kernel/Module.symvers
-rw-r--r-- 4 myName staff 528483 Mar 11 13:48
/home/myName/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19+gitAUTOINC+8897ef68b3_bfa76d4957-r0/linux-amiro-standard-build/Module.symvers
-rw-r--r-- 2 myName staff 528483 Mar 11 13:48
/home/myName/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19+gitAUTOINC+8897ef68b3_bfa76d4957-r0/packages-split/kernel-dev/usr/src/kernel/Module.symvers
-rw-r--r-- 2 myName staff 528483 Mar 11 13:48
/home/myName/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19+gitAUTOINC+8897ef68b3_bfa76d4957-r0/package/usr/src/kernel/Module.symvers
-rw-r--r-- 4 myName staff 528483 Mar 11 13:48
/home/myName/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19+gitAUTOINC+8897ef68b3_bfa76d4957-r0/sysroot-destdir/usr/src/kernel/Module.symvers
-rw-r--r-- 1 myName staff 0 Mar  3 10:08
/home/tkorthals/tmp/work/amiro-poky-linux-gnueabi/ov5647/0.0-r0/ov5647/Module.symvers
-rw-r--r-- 1 myName staff  0 Mar  3 10:08
/home/myName/tmp/work/amiro-poky-linux-gnueabi/ov5647/0.0-r0/ov5647/Module.symvers

A small hotfix to solve my problem is just a copy of the
"Module.symvers" from the kernel build into my source folder of the
module, by the following extension in my "ov5647.bb":
# Copy the fiel containing all kernel modules
do_patchappend() {
cp -f
/home/myName/fido/tmp/work/amiro-poky-linux-gnueabi/linux-yocto/3.19.2+gitAUTOINC+9e70b482d3_31b35da6a5-r0/linux-amiro-standard-build/Module.symvers
${S}
}
addtask patchappend after do_configure before do_compile

If I take the "Module.symvers" from
"kernel-build-artifacts/Module.symvers", the linkage fails because all
the symbols are missing which are important for the module.
Do you have any Idea, if this is a bug in the new 1.8 build
environment, or if I am doing something wrong?

Greetings,
Timo



[1]

+ module_do_compile
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
+ oe_runmake
KERNEL_PATH=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_VERSION=3.19.2-yocto-standard 'CC=arm-poky-linux-gnueabi-gcc  '
'LD=arm-poky-linux-gnueabi-ld.bfd  ' 'AR=arm-poky-linux-gnueabi-ar '
O=/mnt$
+ oe_runmake_call
KERNEL_PATH=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_VERSION=3.19.2-yocto-standard 'CC=arm-poky-linux-gnueabi-gcc  '
'LD=arm-poky-linux-gnueabi-ld.bfd  ' 'AR=arm-poky-linux-gnueabi-ar ' O$
+ bbnote make -j 8 -e MAKEFLAGS=
KERNEL_SRC=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_PATH=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_VERSION=3.19.2-yocto-standard 'CC=arm-poky-$
+ echo 'NOTE: make -j 8 -e MAKEFLAGS=
KERNEL_SRC=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_PATH=/home/myHome/fido/tmp/work-shared/amiro/kernel-source
KERNEL_VER

Re: [yocto] Need advice on tracking down "-dirty"

[Bruce Ashfield]

On 2015-05-08 5:36 AM, Spriggs, Jim wrote:

Hi Guys,

Using poky dizzy with meta-altera (from OE), and trying to implement a simple 
loadable kernel-module by following the method outlined  in Lab3 of  
https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf.

I'm doing an "rm -rf tmp" before starting "bitbake virtual/kernel  
my-image-recipe".

The build seems to work just fine: the kernel-module--1.0-r0.machine.rpm 
appears as expected under .../deploy/...

The package installation task fails, however, with:

 error: Can't install kernel-module--1.0-r0@machine : no package 
provides kernel-3.15.0-00184-g5ae31a7

and indeed, the kernel packages available in .../deploy/... are:

 kernel-3.15-r1.machine.rpm
 kernel-3.15.0-00184-g5ae31a7-dirty-3.15-r1.machine.rpm
 kernel-dev-3.15-r1.machine.rpm
 kernel-image-3.15.0-00184-g5ae31a7-dirty-3.15-r1.machine.rpm


Yet "git status" reports "nothing to commit, w.d. clean" for both the main poky 
tree and the meta-altera sub-tree.


By this, do you mean the kernel source tree ? Or the layers ?

I haven't looked at the kernel recipe you are using, but PV
and the git hash you have in those package names is coming from
the kernel source directory.

It is there that you'll likely find un-commited changes, and what
is triggering the -dirty flag to be captured.

Bruce



So I guess the n00b needs a clue about how to find out why and where the 
dirty-flag is getting set?

Thanks for listening!
--
jim spriggs

PS: the real names of module and machine have been redacted above to protect 
the guilty...
PPS: sorry about the company sig., I can't switch it off.




RAYLASE AG
Argelsrieder Feld 2+4
82234 Wessling
Germany
Tel.: +49-(0)8153/88 98-0
Fax: +49-(0)8153/88 98-10
http://www.raylase.de

District Court Munich, HRB 131450

Board: Peter von Jan (CEO)

Supervisory Board: Dr. Ulrich Lohmann (Chairman)


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.



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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-05-11 02:10 PM, Brian Hutchinson wrote:

On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
 wrote:

It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce


I can confirm this same problem is happening to me.  I just updated
one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail
due to no abi kernel version:


We still have a race condition in the 1.8 branch for the population
of the build-artifacts directory.

If modules start building, they'll race against the population of the
abiversion, and you may see that message.

There's a proposed patch for master, but I don't think it is in
fido yet.

Bruce



ERROR: No kernel-abiversion file found
(/home/hutch/yocto_1.8_davinci/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-abiversion),
cannot run depmod, aborting
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/hutch/yocto_1.8_davinci/poky/build/tmp/work/am180x_evm-poky-linux-gnueabi/core-image-nodeam/1.0-r0/temp/log.do_rootfs.23558
ERROR: Task 7 
(/home/hutch/yocto_1.8_davinci/poky/meta/recipes-core/images/core-image-nodeam.bb,
do_rootfs) failed with exit code '1'

This is for an AM1808 build.  I'm using fido branch of yocto and
openembedded and master of meta-ti (since it doesn't have a fido
branch yet).

STAGING_KERNEL_BUILDDIR="/home/hutch/yocto_1.8_davinci/poky/build/tmp/work-shared/am180x-evm/kernel-build-artifacts"

I didn't do anything different in my local.conf than what I normally
do.  linux-dummy was also built with my last yocto 1.7 build and it
didn't have this problem.

Regards,

Brian



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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-05-12 10:20 AM, Brian Hutchinson wrote:

On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
 wrote:

On 2015-05-11 02:10 PM, Brian Hutchinson wrote:


On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
 wrote:


It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce



I can confirm this same problem is happening to me.  I just updated
one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail
due to no abi kernel version:



We still have a race condition in the 1.8 branch for the population
of the build-artifacts directory.

If modules start building, they'll race against the population of the
abiversion, and you may see that message.

There's a proposed patch for master, but I don't think it is in
fido yet.

Bruce


Hi Bruce,

I did some searches and looks like there are a number of 'race'
condition fixes but it wasn't obvious which one I may need.  Is it
this one:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98



That's the one that should make sure that the shared workdir
(Which has the abiversion) is in place before building any modules.

I can't say that it is exactly your issue, but it is the change
I was thinking of.

Bruce


Regards,

Brian



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

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson  wrote:
> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson  
> wrote:
>> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson  
>> wrote:
>>> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson  
>>> wrote:
>>>>
>>>> On May 14, 2015 6:08 PM, "Denys Dmytriyenko"  wrote:
>>>>>
>>>>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:
>>>>> > On 2015-05-12 10:20 AM, Brian Hutchinson wrote:
>>>>> > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
>>>>> > > wrote:
>>>>> > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote:
>>>>> > >>>
>>>>> > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
>>>>> > >>> wrote:
>>>>> > >>>>
>>>>> > >>>>It is plausible. But in theory, linux-dummy should still provide
>>>>> > >>>>what you need (but since it doesn't build anything, there is
>>>>> > >>>>no abi .. and no modules can be built against it) .. so the
>>>>> > >>>>error isn't graceful.
>>>>> > >>>>
>>>>> > >>>>Bruce
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>I can confirm this same problem is happening to me.  I just updated
>>>>> > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to
>>>>> > >>> fail
>>>>> > >>>due to no abi kernel version:
>>>>> > >>
>>>>> > >>
>>>>> > >>We still have a race condition in the 1.8 branch for the population
>>>>> > >>of the build-artifacts directory.
>>>>> > >>
>>>>> > >>If modules start building, they'll race against the population of the
>>>>> > >>abiversion, and you may see that message.
>>>>> > >>
>>>>> > >>There's a proposed patch for master, but I don't think it is in
>>>>> > >>fido yet.
>>>>> > >>
>>>>> > >>Bruce
>>>>> > >
>>>>> > >Hi Bruce,
>>>>> > >
>>>>> > >I did some searches and looks like there are a number of 'race'
>>>>> > >condition fixes but it wasn't obvious which one I may need.  Is it
>>>>> > >this one:
>>>>> >
>>>>> > > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98
>>>>> > >
>>>>> >
>>>>> > That's the one that should make sure that the shared workdir
>>>>> > (Which has the abiversion) is in place before building any modules.
>>>>> >
>>>>> > I can't say that it is exactly your issue, but it is the change
>>>>> > I was thinking of.
>>>>>
>>>>> Brian,
>>>>>
>>>>> Were you able to try the above mentioned commit against am180x in meta-ti?
>>>>> Did
>>>>> it solve the missing abi kernel version? Thanks.
>>>>>
>>>>> --
>>>>> Denys
>>>>
>>>> Hi Denys,
>>>>
>>>> No, I got caught up in something else ... I'll try it tomorrow and report
>>>> back after I cherry pick that commit Bruce mentioned.
>>>>
>>>> Regards,
>>>>
>>>> Brian
>>>
>>> Update.  Not sure if I did this right but this is what I did.  I added
>>> master as a remote and cherry picked
>>> 02d0a003d603266114512160b209876199241e98.  Next I just went for it and
>>> tried to bitbake my image again and got the same result as before.
>>> Next I did a bitbake cleanall on virtual/kernel and tried to make my
>>> image again and still got the same result.
>>>
>>> I'm going to leave this build as is and setup a new one using 1.8
>>> master and see if I get the same thing again.  I'll leave this broken
>>> build alone for a while in case someone wants me to try something with
>>> it to fix it.
>>>
>>> Regards,
>>>
>>> Brian
>>
>> Yet another up

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-05-19 07:39 AM, Bruce Ashfield wrote:

On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson  wrote:

On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson  wrote:

On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson  wrote:

On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson  wrote:


On May 14, 2015 6:08 PM, "Denys Dmytriyenko"  wrote:


On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:

On 2015-05-12 10:20 AM, Brian Hutchinson wrote:

On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
 wrote:

On 2015-05-11 02:10 PM, Brian Hutchinson wrote:


On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
 wrote:


It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce



I can confirm this same problem is happening to me.  I just updated
one of my builds from 1.7 to 1.8 and am also getting my rootfs to
fail
due to no abi kernel version:



We still have a race condition in the 1.8 branch for the population
of the build-artifacts directory.

If modules start building, they'll race against the population of the
abiversion, and you may see that message.

There's a proposed patch for master, but I don't think it is in
fido yet.

Bruce


Hi Bruce,

I did some searches and looks like there are a number of 'race'
condition fixes but it wasn't obvious which one I may need.  Is it
this one:



http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98




That's the one that should make sure that the shared workdir
(Which has the abiversion) is in place before building any modules.

I can't say that it is exactly your issue, but it is the change
I was thinking of.


Brian,

Were you able to try the above mentioned commit against am180x in meta-ti?
Did
it solve the missing abi kernel version? Thanks.

--
Denys


Hi Denys,

No, I got caught up in something else ... I'll try it tomorrow and report
back after I cherry pick that commit Bruce mentioned.

Regards,

Brian


Update.  Not sure if I did this right but this is what I did.  I added
master as a remote and cherry picked
02d0a003d603266114512160b209876199241e98.  Next I just went for it and
tried to bitbake my image again and got the same result as before.
Next I did a bitbake cleanall on virtual/kernel and tried to make my
image again and still got the same result.

I'm going to leave this build as is and setup a new one using 1.8
master and see if I get the same thing again.  I'll leave this broken
build alone for a while in case someone wants me to try something with
it to fix it.

Regards,

Brian


Yet another update ... I did a fresh checkout of master and tried to
build and had the same kernelabiversion error:

WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for
now###
   | ETA:
00:00:28
WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now
WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for
now

  | ETA:  00:00:26
Parsing recipes: 100%
|##|
Time: 00:01:02
Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303
targets, 182 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for u-boot (u-boot,
u-boot-glsdk, u-boot-ti-staging)
NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot
NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg

Build Configuration:
BB_VERSION= "1.27.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-7.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "am180x-evm"
DISTRO= "poky"
DISTRO_VERSION= "1.8+snapshot-20150515"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f"
meta-ti   = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e"
meta-oe
meta-python
meta-networking
meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package
apache2-dev requires /usr/bin/perl, but no providers found in its
RDEPENDS [file-rdeps]
ERROR: No kernel-abiversion file found
(/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depm

Re: [yocto] Kernel config fragments are no longer applied after update to Fido

[Bruce Ashfield]

On Thu, Jun 4, 2015 at 6:47 AM, Neuer User  wrote:
> Hello
>
> I have the following kernel recipe, which is based on some help from
> Bruce Ashfield last year:
>
> -
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> SUMMARY = "Linaro Kernel 3.14 with additional machine specific patches"
>
> SRCREV = "91d5e90284ee69d219872e3ae42ae0eac417f7e9"
> LOCALVERSION = "-cubox-i+linux4kix+${SRCPV}"
>
> DEPENDS += "lzop-native bc-native"
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/linux-cubox-i:"
>
> SRC_URI = "file://defconfig \
>file://videoin.cfg \
>file://dvb.cfg \
>file://networking.cfg \
>file://wlan.cfg \
>file://dm-crypt.cfg \
>file://no-caam.cfg \
>file://leds.cfg \
>file://mod-to-builtin.cfg \
>file://watchdog-nowayout.cfg \
>file://brcmfmac4330-sdio.bin \
>file://brcmfmac4330-sdio.txt \
> "
>
> SRC_URI +=
> "git://github.com/linux4kix/linux-linaro-stable-mx6.git;branch=${SRCBRANCH}"
> SRCBRANCH ?= "linux-linaro-lsk-v3.14-mx6"
>
> COMPATIBLE_MACHINE = "(cubox-i)"
>
> KERNEL_IMAGETYPE_cubox-i = "zImage"
>
> SRCREV_machine = "${SRCREV}"
> --
>
>
> This worked nicely under yocto daisy. Now, after I migrated my recipes
> to yocto fido, the recipe no longer seems to include the kernel
> fragments, i.e. everything runs without errors, but the fragments are
> not applied. (They are, however, copied to the build directory.)
>
> Any idea, what the problem is or how to debug/solve it?

The transition should have been seamless .. this is something that
works here and
something that was obviously tested as part of the release.

Is there somewhere that I can get a copy of the layer you are using
for your BSP ?
Otherwise, let me hack something up and try my own build.

Bruce

>
> Thanks in advance
>
> Michael
>
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-06-09 9:12 PM, Brian Hutchinson wrote:

On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson  wrote:

On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield
 wrote:

On 2015-05-19 07:39 AM, Bruce Ashfield wrote:


On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson 
wrote:


On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson 
wrote:


On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson 
wrote:


On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson
 wrote:



On May 14, 2015 6:08 PM, "Denys Dmytriyenko"  wrote:



On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:


On 2015-05-12 10:20 AM, Brian Hutchinson wrote:


On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
 wrote:


On 2015-05-11 02:10 PM, Brian Hutchinson wrote:



On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
 wrote:



It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce




I can confirm this same problem is happening to me.  I just
updated
one of my builds from 1.7 to 1.8 and am also getting my rootfs to
fail
due to no abi kernel version:




We still have a race condition in the 1.8 branch for the
population
of the build-artifacts directory.

If modules start building, they'll race against the population of
the
abiversion, and you may see that message.

There's a proposed patch for master, but I don't think it is in
fido yet.

Bruce



Hi Bruce,

I did some searches and looks like there are a number of 'race'
condition fixes but it wasn't obvious which one I may need.  Is it
this one:





http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98





That's the one that should make sure that the shared workdir
(Which has the abiversion) is in place before building any modules.

I can't say that it is exactly your issue, but it is the change
I was thinking of.



Brian,

Were you able to try the above mentioned commit against am180x in
meta-ti?
Did
it solve the missing abi kernel version? Thanks.

--
Denys



Hi Denys,

No, I got caught up in something else ... I'll try it tomorrow and
report
back after I cherry pick that commit Bruce mentioned.

Regards,

Brian



Update.  Not sure if I did this right but this is what I did.  I added
master as a remote and cherry picked
02d0a003d603266114512160b209876199241e98.  Next I just went for it and
tried to bitbake my image again and got the same result as before.
Next I did a bitbake cleanall on virtual/kernel and tried to make my
image again and still got the same result.

I'm going to leave this build as is and setup a new one using 1.8
master and see if I get the same thing again.  I'll leave this broken
build alone for a while in case someone wants me to try something with
it to fix it.

Regards,

Brian



Yet another update ... I did a fresh checkout of master and tried to
build and had the same kernelabiversion error:

WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for
now###
| ETA:
00:00:28
WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now
WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for
now

   | ETA:  00:00:26
Parsing recipes: 100%

|##|
Time: 00:01:02
Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303
targets, 182 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for u-boot (u-boot,
u-boot-glsdk, u-boot-ti-staging)
NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot
NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg

Build Configuration:
BB_VERSION= "1.27.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-7.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "am180x-evm"
DISTRO= "poky"
DISTRO_VERSION= "1.8+snapshot-20150515"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f"
meta-ti   = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e"
meta-oe
meta-python
meta-networking
meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package
apache2-dev requires /usr/bin

Re: [yocto] failure in linux-yocto kernel do_patch

[Bruce Ashfield]

On 2015-06-12 04:41 AM, Mayank Agarwal wrote:

Hi

I am getting the following error while compiling linux-yocto from
yocto openembedded.

  DEBUG: Executing shell function do_patch
| Deleted branch meta-temp (was d36a7ef).
| WARNING: addon feature "features/nfsd/nfsd-enable.scciso" was not found


There's 'iso' appended to that .scc file name .. so it definitely
isn't going to be found.

There are likely other KERNEL_FEATURES in play, so make sure that
you have a space after your nfsd-enable.scc line .. and see what
happens.

Bruce


| ERROR: required features were not found. aborting
| ERROR. Could not update standard/common-pc/base
| WARNING: 
/home/projectubuntu/mayank/workspacemaster/../../../linux-yocto/3.14.5+gitAUTOINC+183622e809_4aa41764bf-r0/temp/run.do_patch.5192:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_patch (log file is located at
/home/projectubuntu/mayank/workspacemaster/../../../linux-yocto/3.14.5+gitAUTOINC+183622e809_4aa41764bf-r0/temp/log.do_patch.5192)

Any help on this:tried almost all things like appending
KERNEL_FEATURE_append-pn-linux-yocto = "features/nfsd/nfsd-enable.scc"
but not getting help

Regards
Mayank



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

Re: [yocto] Problems using "In-Tree" defconfig File

[Bruce Ashfield]

On 2015-06-19 03:28 AM, Andreas Fenkart wrote:

I want to use a defconfig, that is provided by the linux git
repository, hence this seems to fit my need:

http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file

Anybody used that feature recently? I couldn't get it to work, :-(


Works here.



The build fails in kernel_config target, in merge_config.sh. It fails
to merge kernel config fragments. Probably because I don't have any.

[INFO] collecting configs in .meta/meta-series
ARCH=arm O=/linux-dss11e-standard-build merge_config.sh -d
mv: cannot stat '/linux-dss11e-standard-build/.tmp.config*': No
such file or directory


This actually means something else, like a misconfigured BSP.



Grep'ing for KBUILD_DEFCONFIG in kernel-tools only get_defconfig seems
to use  that variable

$ get_defconfig arm dss20_defconfig
linux/arch/arm/configs/dss20_defconfig  ...so that works fine

I took that snipped from check_defconfig functoin, here:
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/createme#n201

but that function is not called anywhere in script createme. After all
that script only creates the meta folder but has nothing to do with
kernel configuration. Seems to be a dead end. Probably get_defconfig
call should be added to configme script


In this case no. What release are you using ? And what does your kernel
recipe look like ?

do_kernel_metadata is responsible for yanking that defconfig out of the
tree and feeding it into the build just like a 'defconfig' passed via
the SRC_URI.

Bruce



Anybody had the same problem, is there a patch. Or did I misconfigure something?

kind regards,
Andi


Here my recipe:
---
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

SRCBRANCH = "dSS"
SRCREV="82d97d74bb072fe24be10b46d0782d3735130199"
SRC_URI =
"git://git.digitalstrom.org/bsp/linux.git;protocol=https;branch=${SRCBRANCH}"

LINUX_VERSION = "4.1"
LINUX_VERSION_EXTENSION = ""
KBUILD_DEFCONFIG_dss11e = "dss20_defconfig"

PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"

COMPATIBLE_MACHINE = "(dss11e)"



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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-06-23 3:15 PM, Robert Calhoun wrote:



On 4/30/15 10:06 AM, "Bruce Ashfield"  wrote:


On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:

What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?


How would I see which kernel recipe is used?


This is where my brute force techniques probably break down. I just
do a 'bitbake virtual/kernel' and you'll see it display which
recipe is being built.

If you haven't added compatibility for your new machine to any
recipe, I'm betting that linux-dummy is used.



I did not customize anything except for aforementioned steps, simply
copied beaglebone.conf to astro.conf in the same directory. Also I did
not touch any kernel recipes (kernel is built externally), maybe that's
what's missing?


It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce



Jan



I encountered the same error ("ERROR: No kernel-abiversion file found
(build/tmp/sysroots/{machinename}/pkgdata/kernel-depmod/kernel-abiversion),
  cannot run depmod, aborting") after porting my system from poky-daisy to
poky-fido. My machine config sets PREFERRED_PROVIDER_virtual/kernel =
"linux-dummy", as we currently use a monolithic out-of-tree 2.6 kernel.
It's a clean fido checkout, and I tried trashing tmp and rebuilding
everything to no effect.

Based on
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbcl
ass I have worked around this by setting:

USE_DEPMOD = "0"

in my image configuration. This works, and allows the root file system to
be built.

Is it a bug that depmod is not skipped automatically when linux-dummy is
specified? Am I risking death and destruction by overriding it? (We don't
have any kernel modules.)


See Saul's patch from about 33 minutes ago:

[OE-core] [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the 
dummy kernel


:)

Bruce



Thanks,

Rob Calhoun



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

Re: [yocto] Creating image with genericx86 machine and RT-Preempt Patch

[Bruce Ashfield]

On 2015-07-07 7:56 AM, Gorny Krystian wrote:

Hi,

I try to build an image for a x86 architecture with RT-Preemtp Patch. So
I use the genericx86 machine and try to build the core-image-rt recipe.
This fails with the following errors:

/> ERROR: Nothing PROVIDES 'linux-yocto-rt' (but
/media/disk/myYocto/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS
on or otherwise requires it)/

/> ERROR: linux-yocto-rt was skipped: incompatible with machine
genericx86 (not in COMPATIBLE_MACHINE)/

/> ERROR: Required build target 'core-image-rt' has no buildable providers./

/> Missing or unbuildable dependency chain was: ['core-image-rt',
'linux-yocto-rt']/

So I add the following parameter to my local.conf file:

/> COMPATIBLE_MACHINE_genericx86 = "genericx86"/

/> COMPATIBLE_MACHINE_quilt-native = "genericx86"/

/> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"/

But I get this error:

/> ERROR: Task 80
(/media/disk/myYocto/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb,
do_compile) failed with exit code '1'/

In the log.do_compile file I see:

/> NOTE: make -j 4 bzImage CC=i686-poky-linux-gcc
LD=i686-poky-linux-ld.bfd/

/> make[3]: Nothing to be done for `all'./

/>   CHK include/config/kernel.release/

/>   GEN
/media/disk/myYocto/poky/build/tmp/work/genericx86-poky-linux/linux-yocto-rt/3.14.36+gitAUTOINC+a996d95104_3428de7103-r0/linux-genericx86preempt-$/

/>   CHK include/generated/uapi/linux/version.h/

/>   CHK include/generated/utsrelease.h/

/>   HOSTCC  scripts/conmakehash/

/>   HOSTCC  scripts/sortextable/

/>   CC  scripts/mod/empty.o/

/>
/media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0:
error: code model 'kernel' not supported in the 32 bit >mode/

/>  /* empty file to figure out endianness / word size *//

/>  ^/

/>
/media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0:
sorry, unimplemented: 64-bit mode not compiled in/

/> make[4]: *** [scripts/mod/empty.o] Error 1/

/> make[4]: *** Waiting for unfinished jobs/

/>   HOSTCC  scripts/mod/mk_elfconfig/

/> make[3]: *** [scripts/mod] Error 2/

/> make[3]: *** Waiting for unfinished jobs/

/> make[2]: *** [scripts] Error 2/

/> make[1]: *** [sub-make] Error 2/

/> make: *** [all] Error 2/

/> ERROR: oe_runmake failed/

/> WARNING: exit code 1 from a shell command./

I already tried genericx86_64 machine and it’s still not working. Are
the genericx86 machine incompatible with the core-image-rt recipy? If
yes how can I build a x86 image with the RT patch?


What you did should have worked, since we do map the genericx86 BSP onto
one of the configurations that supports preempt-rt.

It looks like a compile error has crept in .. I'll start a build and see
if it is indeed broken at the moment (and then I can fix it).

Bruce



Many Thanks


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com





Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.




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

Re: [yocto] Creating image with genericx86 machine and RT-Preempt Patch

[Bruce Ashfield]

On 2015-07-07 12:30 PM, Bruce Ashfield wrote:

On 2015-07-07 7:56 AM, Gorny Krystian wrote:

Hi,

I try to build an image for a x86 architecture with RT-Preemtp Patch. So
I use the genericx86 machine and try to build the core-image-rt recipe.
This fails with the following errors:

/> ERROR: Nothing PROVIDES 'linux-yocto-rt' (but
/media/disk/myYocto/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS
on or otherwise requires it)/

/> ERROR: linux-yocto-rt was skipped: incompatible with machine
genericx86 (not in COMPATIBLE_MACHINE)/

/> ERROR: Required build target 'core-image-rt' has no buildable
providers./

/> Missing or unbuildable dependency chain was: ['core-image-rt',
'linux-yocto-rt']/

So I add the following parameter to my local.conf file:

/> COMPATIBLE_MACHINE_genericx86 = "genericx86"/

/> COMPATIBLE_MACHINE_quilt-native = "genericx86"/

/> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"/

But I get this error:

/> ERROR: Task 80
(/media/disk/myYocto/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb,

do_compile) failed with exit code '1'/

In the log.do_compile file I see:

/> NOTE: make -j 4 bzImage CC=i686-poky-linux-gcc
LD=i686-poky-linux-ld.bfd/

/> make[3]: Nothing to be done for `all'./

/>   CHK include/config/kernel.release/

/>   GEN
/media/disk/myYocto/poky/build/tmp/work/genericx86-poky-linux/linux-yocto-rt/3.14.36+gitAUTOINC+a996d95104_3428de7103-r0/linux-genericx86preempt-$/


/>   CHK include/generated/uapi/linux/version.h/

/>   CHK include/generated/utsrelease.h/

/>   HOSTCC  scripts/conmakehash/

/>   HOSTCC  scripts/sortextable/

/>   CC  scripts/mod/empty.o/

/>
/media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0:

error: code model 'kernel' not supported in the 32 bit >mode/

/>  /* empty file to figure out endianness / word size *//

/>  ^/

/>
/media/disk/myYocto/poky/build/tmp/work-shared/genericx86/kernel-source/scripts/mod/empty.c:1:0:

sorry, unimplemented: 64-bit mode not compiled in/

/> make[4]: *** [scripts/mod/empty.o] Error 1/

/> make[4]: *** Waiting for unfinished jobs/

/>   HOSTCC  scripts/mod/mk_elfconfig/

/> make[3]: *** [scripts/mod] Error 2/

/> make[3]: *** Waiting for unfinished jobs/

/> make[2]: *** [scripts] Error 2/

/> make[1]: *** [sub-make] Error 2/

/> make: *** [all] Error 2/

/> ERROR: oe_runmake failed/

/> WARNING: exit code 1 from a shell command./

I already tried genericx86_64 machine and it’s still not working. Are
the genericx86 machine incompatible with the core-image-rt recipy? If
yes how can I build a x86 image with the RT patch?


What you did should have worked, since we do map the genericx86 BSP onto
one of the configurations that supports preempt-rt.

It looks like a compile error has crept in .. I'll start a build and see
if it is indeed broken at the moment (and then I can fix it).



Assuming you are building with yocto/poky, you need the following patch.
(note: this is configure tested only).

Since without this bbappend, we don't have genericx86 mapped to a valid
linux-yocto BSP and commit hash.

I'll be sending this change for merging into the project shortly.

Cheers,

Bruce


Bruce



Many Thanks


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com



<http://www.wipotec.com>

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.








0001-yocto-bsps-add-3.14-rt-configuration.patch
Description: application/mbox
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] populate_sdk and kernel headers

[Bruce Ashfield]

On 2015-07-08 1:05 PM, Benjamin Fleming wrote:

Ok,
adding kernel-devsrc to my IMAGE_INSTALL caused the kernel source to be 
included in the SDK. Unfortunately, it is now also included in the target image.
I found adding kernel-devsrc instead to TOOLCHAIN_TARGET_TASK gave me what I 
wanted (/usr/src/kernel in the SDK but NOT in the target image)

Also, I really only need the kernel headers (similar to the linux-headers 
packages in Ubuntu) for developing out-of-source kernel modules. Is there is a 
different package I should be using?



The linux-libc-headers are the uapi exported headers, but as for the
source for module builds, it is currently unified in the
kernel-devsrc package.

We have a long history with the packaging of the sources, and what
to export where .. and even the ordering of that packaging. So while
splitting out the headers may seem simple, it requires a bit more
finesse of getting the headers, the right amount of script and Kbuild
support to get it exactly right.

By keeping the two together, we ensure that we have enough to meet
all development tasks.

There are some enhancements for this in flight for the 1.9 release, so
it is something that we are considering .. just keeping those existing
use cases and workflows from breaking is the sticky part.

Cheers,

Bruce


Thanks,
Ben


-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Tuesday, July 07, 2015 5:54 PM
To: Benjamin Fleming
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] populate_sdk and kernel headers

On Tue, Jul 7, 2015 at 4:16 PM, Benjamin Fleming
 wrote:

Hello,
I want my kernel headers to be included in the SDK output when I run

bitbake myimage -c populate_sdk. I expect to see the headers in my installed
SDK folder such as /sysroot//usr/src/kernel; however, I
don't see anything there. Also, I don't want the headers appearing on the
target.


In my recipe I have added IMAGE_INSTALL += kernel-modules, and
SDKIMAGE_FEATURES += kernel-devsrc.  The kernel I'm using is
linux-altera-ltsi-rt from
https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/l
inux-altera-ltsi-rt_3.10.bb
What am I missing?


Try adding kernel-devsrc to IMAGE_INSTALL rather than
SDKIMAGE_FEATURES.


Thanks,

Ben
--
___
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] Selecting different kernel inside an image recipe

[Bruce Ashfield]

On 2015-07-08 12:36 PM, Klaus Knopper wrote:

Hello Leonardo,

On Wed, Jul 08, 2015 at 10:40:10AM -0500, Leonardo Sandoval wrote:

On 07/08/2015 09:50 AM, Klaus Knopper wrote:

Hello list,

I'm trying to build variantions/brands of an image that only differ in
kernel configuration and kernel modules included, but everything else stays
the same, for the exact same board, as in the main image.

Setting PREFERRED_PROVIDER_virtual/kernel = "different_kernel"
right inside in the new image recipe does not have any effect, as that
variable seems to be evaluated exclusively in the local.conf machine
file, which is read by all recipes.


This variable is commonly used inside configuration metadata (machine or
distro conf files). You may try it there.


Please help me to understand your answer: You are saying that I do have
to change the machine or distro config used for ALL recipes, to be able
to use a different kernel configuration in ONE recipe, right?

I was really trying to avoid that. :-(

So it is really not possible to just select a different kernel config
within a normal recipe without changing the global configuration?


You really want a different kernel recipe to provide that different
kernel configuration.  Which looks to be what you are describing, and
you just want to switch the provider (again, what you are saying).

Changing the included kernel via that different kernel recipe/package
name, and setting it via the preferred provider is the same as any
bitbake variable.

So you should be able to set it in any .conf file, and then have what
you want. I've used layers with layer.conf files, and similar mechanisms
to do what you are trying in the past .. but the longer serving oe/bitbake
folks may have a better example to point at.

Cheers,

Bruce



Regards
-Klaus



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

Re: [yocto] Kernel header missing for specific Target

[Bruce Ashfield]

On 15-07-17 08:47 AM, Gorny Krystian wrote:

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I
have already my own recipe, for normal user space programs everything is
working fine.

For the kernel space driver Yocto is missing at do_comile task the
asm/atomic.h header file. I have searched for the atomic.h file and
found a lot of them in the ./build/tmp/work folder. Yocto should use one
of them for the right hardware architecture right? Or is the a something
else I have forget to do?


What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming
that your driver recipe has the proper dependencies.  Without seeing
that recipe, it is hard to say more.

Cheers,

Bruce



Many thanks

Krystian


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com





Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.




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

Re: [yocto] Kernel header missing for specific Target

[Bruce Ashfield]

On 15-07-17 09:55 AM, Gorny Krystian wrote:

I'm using the fido branch. My iointerrupt.bb file looks as follow:


DESCRIPTION = "Simple IO-interrupt driver"
SECTION = "iointerrupt"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://drv_iointerrupt.c"
S = "${WORKDIR}"
do_compile() {
  ${CC} drv_iointerrupt.c -o iointerrupt
}


And so I'm clear .. this is a standard .ko ? Or a userspace kernel driver ?

If you are looking for the internal kernel sources to be on the include
path, you need to reference STAGING_KERNEL_DIR (and something has to
depend on the kernel do_shared_workdir task to get the right bits
in place).

 recipes-kernel/lttng/lttng-modules_2.6.1.bb

Is an example of both.

Bruce


do_install() {
  install -d ${D}${bindir}
  install -m 0755 iointerrupt ${D}${bindir}
}

Thanks,
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


_

Weigh Cells | Weighing systems

See our solutions. Visit us at our events
http://www.wipotec.com/de/aktuelles/veranstaltungen/

_

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, July 17, 2015 3:32 PM
To: Gorny Krystian; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel header missing for specific Target

On 15-07-17 08:47 AM, Gorny Krystian wrote:

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I
have already my own recipe, for normal user space programs everything
is working fine.

For the kernel space driver Yocto is missing at do_comile task the
asm/atomic.h header file. I have searched for the atomic.h file and
found a lot of them in the ./build/tmp/work folder. Yocto should use
one of them for the right hardware architecture right? Or is the a
something else I have forget to do?


What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming that 
your driver recipe has the proper dependencies.  Without seeing that recipe, it 
is hard to say more.

Cheers,

Bruce



Many thanks

Krystian


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com



<http://www.wipotec.com>

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern,
Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.







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

Re: [yocto] Problem overwriting default kernel config values

[Bruce Ashfield]

On 2015-07-17 9:35 PM, Ryan Soussan wrote:

Hello,
We're having a problem overwriting the default linux kernel config
values.  We tried adding our own .cfg file to our layer and appending it
to the source url of the linux-yocto bitbake file.  The variable in our
case is not getting overwritten though (changing CONFIG_ATH5K=m to =y).
Here's some relevant output from mismatch.txt:
Value requested for CONFIG_ATH5K not in final .config
   Requested value:  CONFIG_ATH5K=y
 Actual value: CONFIG_ATH5K=m

And basically the same error message in missing_required.cfg.  So it
looks like yocto is seeing our request but ignoring it.  The source code
for these messages is located here:
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check

We were following the instructions for editing the config file located
in the linux directory of the meta-skeleton layer in poky.   Any help
would be appreciated!



What release/branch are you using ? This is a test case that I run
ever release (and use every day), so the overrides do work.

The kernel configuration system doesn't have the opportunity to
ignore settings. They are consolidated and then passed to the kernel's
config subsystem and then the results audited.

I'll run a similar test here, since if something else later in the
configuration is selecting that driver as a module, or another constraint
is kicking in .. you will end up with a module, no matter what you
set in your fragment.

Bruce


Thanks,
Ryan




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

Re: [yocto] Problem overwriting default kernel config values

[Bruce Ashfield]

On 2015-07-18 11:53 PM, Bruce Ashfield wrote:

On 2015-07-17 9:35 PM, Ryan Soussan wrote:

Hello,
We're having a problem overwriting the default linux kernel config
values.  We tried adding our own .cfg file to our layer and appending it
to the source url of the linux-yocto bitbake file.  The variable in our
case is not getting overwritten though (changing CONFIG_ATH5K=m to =y).
Here's some relevant output from mismatch.txt:
Value requested for CONFIG_ATH5K not in final .config
   Requested value:  CONFIG_ATH5K=y
 Actual value: CONFIG_ATH5K=m

And basically the same error message in missing_required.cfg.  So it
looks like yocto is seeing our request but ignoring it.  The source code
for these messages is located here:
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check


We were following the instructions for editing the config file located
in the linux directory of the meta-skeleton layer in poky.   Any help
would be appreciated!



What release/branch are you using ? This is a test case that I run
ever release (and use every day), so the overrides do work.

The kernel configuration system doesn't have the opportunity to
ignore settings. They are consolidated and then passed to the kernel's
config subsystem and then the results audited.

I'll run a similar test here, since if something else later in the
configuration is selecting that driver as a module, or another constraint
is kicking in .. you will end up with a module, no matter what you
set in your fragment.


And yes, it was a contraint in the end. I needed this in my fragment to
flip ATH5K to =y

CONFIG_ATH5K=y
CONFIG_ATH_CARDS=y
CONFIG_ATH_COMMON=y
CONFIG_CFG80211=y
CONFIG_R8723AU=y
CONFIG_MAC80211=y

I'm working on some diagnostics and symbol lookups that will help with
this in the future .. but it is much more challenging than you'd expect!

Cheers,

Bruce



Bruce


Thanks,
Ryan






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

Re: [yocto] Kernel header missing for specific Target

[Bruce Ashfield]

On 15-07-23 09:31 AM, Gorny Krystian wrote:

So my drv_iointerrupt.c is a standard *.ko driver. It's still missing the 
include files asm/atomic.h and linux/cdev.h when I try to build it ($bitbake 
iointerrupt).

Can I compile and install the driver module to the kernel with normal *.bb 
files (like a normal recipe)? I'm still not sure about this.



If the driver follows kernel conventions, then yes, you can write a
recipe that builds and packages the modules.

If you look in meta-skeleton, there is a hello-mod example of a kmod
recipe.

Bruce


Many Thanks
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


_

Weigh Cells | Weighing systems

See our solutions. Visit us at our events
http://www.wipotec.com/de/aktuelles/veranstaltungen/

_

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

-Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, July 17, 2015 5:40 PM
To: Gorny Krystian; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel header missing for specific Target

On 15-07-17 09:55 AM, Gorny Krystian wrote:

I'm using the fido branch. My iointerrupt.bb file looks as follow:


DESCRIPTION = "Simple IO-interrupt driver"
SECTION = "iointerrupt"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://drv_iointerrupt.c"
S = "${WORKDIR}"
do_compile() {
   ${CC} drv_iointerrupt.c -o iointerrupt }


And so I'm clear .. this is a standard .ko ? Or a userspace kernel driver ?

If you are looking for the internal kernel sources to be on the include path, 
you need to reference STAGING_KERNEL_DIR (and something has to depend on the 
kernel do_shared_workdir task to get the right bits in place).

   recipes-kernel/lttng/lttng-modules_2.6.1.bb

Is an example of both.

Bruce


do_install() {
   install -d ${D}${bindir}
   install -m 0755 iointerrupt ${D}${bindir} }

Thanks,
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


_

Weigh Cells | Weighing systems

See our solutions. Visit us at our events
http://www.wipotec.com/de/aktuelles/veranstaltungen/

_

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern,
Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, July 17, 2015 3:32 PM
To: Gorny Krystian; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel header missing for specific Target

On 15-07-17 08:47 AM, Gorny Krystian wrote:

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I
have already my own recipe, for normal user space programs everything
is working fine.

For the kernel space driver Yocto is missing at do_comile task the
asm/atomic.h header file. I have searched for the atomic.h file and
found a lot of them in the ./build/tmp/work folder. Yocto should use
one of them for the right hardware architecture right? Or is the a
something else I have forget to do?


What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming that 
your driver recipe has the proper dependencies.  Without seeing that recipe, it 
is hard to say more.

Cheers,

Bruce



Many thanks

Krystian


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com



<http://www.wipotec.com>

Legal infor

Re: [yocto] qemux86 and generic86

[Bruce Ashfield]

On Wed, Aug 5, 2015 at 1:44 AM, Amit Kumar
 wrote:
> Hi,
>
>
>
> I have a basic doubts on qemux86 build application image is not working on
> generic86 target.
>
> Suppose I have a application which I would like to test on target board, but
> the target board is not yet ready. If I will want to test that application I
> will use the qemu  to test.
>
> But if I build the application for qemu, it does not work for actual target
> board.
>
> Could you please let me know the details reason. If I want to do like that
> what I should have to do.
>

Are you concerned about the kernel, or userspace ? You say 'application', but
I wanted to be sure.

Assuming that your application is generic, and isn't using any machine specific
ops, then it will work fine on qemu and on a h/w target.

That being said, applications are typically rebuilt o be included in a different
image when switching between qemu and the h/w .. so they'l be rebuild and
relinked anyway.

Bruce

>
>
>
>
> Thanks & Regards
>
> Amit
>
> L&T Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do not
> use or disseminate the information, notify the sender and delete it from
> your system.
>
>
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-virtualization] openvsitch: set CONFIGUREOPT_DEPTRACK to empty

[Bruce Ashfield]

On 15-08-26 01:48 AM, rongqing...@windriver.com wrote:

From: Roy Li 

compilation failed since the needed dirs maybe not created when make
".in" target, fix it by creating the needed dirs before, but mainstream
thinks the needed dirs should be created when do configuration.
at last, find CONFIGUREOPT_DEPTRACK disable the creation, so empty
it
http://openvswitch.org/pipermail/dev/2015-August/059189.html

set CONFIGUREOPT_DEPTRACK to empty, is lower effective, but harmless,
and can fix the parallel building issue;
see oe-core 970e0ae6108[autotools: Disable dependency tracking


This should have gone to the meta-virtualization mailing list, but no
need to re-send .. I have it from here and have merged it.

Bruce



Signed-off-by: Roy Li 
---
  recipes-networking/openvswitch/openvswitch.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/recipes-networking/openvswitch/openvswitch.inc 
b/recipes-networking/openvswitch/openvswitch.inc
index 58c8352..454aadf 100644
--- a/recipes-networking/openvswitch/openvswitch.inc
+++ b/recipes-networking/openvswitch/openvswitch.inc
@@ -39,6 +39,7 @@ EXTRA_OECONF += "\
TARGET_PYTHON=${bindir}/python \
TARGET_PERL=${bindir}/perl \
"
+CONFIGUREOPT_DEPTRACK = ""

  # Don't compile kernel modules by default since it heavily depends on
  # kernel version. Use the in-kernel module for now.



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

Re: [yocto] [meta-raspberrypi] kernel do_patch lasts ages

[Bruce Ashfield]

On 2015-08-31 9:07 PM, Andreas Müller wrote:

On Thu, Aug 20, 2015 at 12:23 AM, Andreas Müller
 wrote:

Hi

since one week or so my build sometimes freezes with

linux-raspberrypi-3.18.11+gitd64fa8121fca9883d6fb14ca06d2abf66496195e-r0
do_patch (pid 7335)

without any progress noticeable.

In log.do_patch I see strange stuff:

DEBUG: Executing shell function do_patch
[INFO] validating against known patches  (raspberrypi2-standard-meta)
   
[]
(|)(200 %)

Anybody out there with ideas what's going on?


OK a successful log says

DEBUG: Executing shell function do_patch
[INFO] validating against known patches  (raspberrypi2-standard-meta)
   
[]
(|)(200 %)   [##]
(completed in 6326 seconds)
DEBUG: Shell function do_patch finished

What takes 108 minutes??


Wow. That is REALLY long. In existing releases the tools are looking
for place to resume a previously applied set of matches. Depending
on the history of a branch, it means quite a few commits are
checked.

I'm betting this is falling into some sort of pathological case where
hundreds of commits are being checked.

As it turns out, I completed a set of changes just today that eliminate
that checking and make the patch phase take almost no time.

If someone is willing to test an in-progress patch, I can send it out
tomorrow and see if the change resolves this issue.

Bruce



Andreas



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

Re: [yocto] Warning about auto generated BSP description

[Bruce Ashfield]

On 15-09-13 04:15 PM, Paul D. DeRocco wrote:

I'm getting the following warning:

[kernel]: An auto generated BSP description was used, this normally
indicates a misconfiguration.
Check that your machine (chroma-bsp) has an associated kernel description.

Googling turns up the information that this is sometimes a spurious error
and nothing to worry about, because a full BSP description isn't strictly
required. However, as far as I can see I do indeed have a BSP description.
I built the BSP using the yocto-bsp tool. It created a
linux-yocto-rt_3.14.bbappend (since I'm using the RT kernel), and the
following files:

 chroma-bsp.cfg
 chroma-bsp.scc
 chroma-bsp-preempt-rt.scc
 chroma-bsp-standard.scc
 chroma-bsp-tiny.scc
 chroma-bsp-user-config.cfg
 chroma-bsp-user-features.scc
 chroma-bsp-user-patches.scc


The tool may have created these files, but the question is .. were they
actually used.

That's what the check in question is trying to determine.

Rather than fail to build, the tools (kernel, not yocto-bsp) will
generate a skeleton BSP, and start the build. Chances are that
skeleton BSP isn't what you want .. and that's what the tools are
warning.

Clearly the message still needs more tweaking, as do the docs.



The bbappend refers to chroma-bsp-preempt-rt.scc and the last three
(empty) files. chroma-bsp-preempt-rt.scc contains the requisite KMACHINE,
KTYPE and KARCH, and includes chroma-bsp.scc, which refers to
chroma-bsp.cfg. This seems to fit the definition of a "BSP description" in
3.4.5 of the Kernel Development Manual. The whole BSP tree is called
"meta-chroma-bsp" and that is indeed listed in my bblayers.conf. So why is
it complaining?


What release are you using ? If you check something in the kernel meta
directory, I can tell you if the warning is wrong, or something is 
really being missed.


The reason I asked about the release, is that the location of the kernel
meta directory will be in a different place between the various
releases. But it is always in the kernel source directory, whether it is
in work-shared, or in work. So if you head to that directory and look
for either .meta or .kernel-meta, you should see a file "top_tgt" in that
directory.

Look at the contents of that file. It should point to those generated
files you referenced above. If it doesn't .. they weren't used, and we
need to figure out why.

Cheers,

Bruce



Also, I don't know that "Check that your machine has an associated kernel
description" means. The term "kernel description" doesn't appear anywhere
in the docs.



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

Re: [yocto] Warning about auto generated BSP description

[Bruce Ashfield]

On 15-09-14 01:38 PM, Paul D. DeRocco wrote:

From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]

The tool may have created these files, but the question is ..
What release are you using ? If you check something in the kernel meta
directory, I can tell you if the warning is wrong, or something is
really being missed.


I'm using Fido.


The reason I asked about the release, is that the location of
the kernel
meta directory will be in a different place between the various
releases. But it is always in the kernel source directory,
whether it is
in work-shared, or in work. So if you head to that directory and look
for either .meta or .kernel-meta, you should see a file
"top_tgt" in that
directory.

Look at the contents of that file. It should point to those generated
files you referenced above. If it doesn't .. they weren't used, and we
need to figure out why.


The file
"/home/pauld/yocto-fido/build/tmp/work-shared/chroma-bsp/kernel-source/.me
ta/top_tgt" contains
"/home/pauld/yocto-fido/build/tmp/work-shared/chroma-bsp/kernel-source/.me
ta/cfg/scratch/obj/home/pauld/yocto-fido/meta-chroma-bsp/recipes-kernel/li
nux/files/chroma-bsp-preempt-rt.scc". That referenced folder includes a
copy of all the .scc and .cfg files I mentioned before. I guess that means
that they are in fact being used.


Yep. If everything was copied, then you are good.

And now that you point that out, I recall a bug that when I created
that warning, that it was catching the yocto BSP generated files.
I swear I fixed it, but obviously not. I'll need to track down that
bugzilla entry.

Bruce



Does that mean that this warning message is spurious, and can be ignored?
My kernel is hanging during the boot at this point, but I suspect my real
problem is elsewhere.

Thanks so much for your time helping me to figure this out.



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

Re: [yocto] RFC: Yocto LTS?

[Bruce Ashfield]

On 15-10-14 11:12 AM, Chris Simmonds wrote:

Hi,

On 14/10/15 14:50, akuster808 wrote:

Chris,


On 10/14/2015 06:28 AM, Chris Simmonds wrote:

Hi,

Is there a statement about the period of support for a Yocto release?
Looking through the updates, it seems that 12 months is typical, a was
the case for 1.4, 1.5 and 1.6 for example, but I cannot see a
declaration anywhere that this is the expected norm.


There is a release every 6 months.

https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_release_cycle_of_the_Yocto_Project.3F



Leading on from that, is 12 months enough? Most projects have a
lifecycle that is much longer. Is there an argument for an LTS Yocto
release, maybe once a year? If not, what is the recommended way for a
project developer to keep a distribution up to date in the light of the
several well-publicised security flaws that have been discovered over
the last year or so and the new ones that will no doubt be discovered in
the future?


At table of the current supported release can be found at
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance

- Armin



Thanks, Armin, that is the kind of thing I was looking for. It doesn't
mention a timespan for updates, but there does seem to be an implicit
maintenance period of 12 months after release. I am still worried that
this is a rather short period of time, though, and encourages device
manufacturers to avoid ever updating boxes in the field.


For longer term support, or for support of truly critical devices, the
Yocto project has relied on OSVs to offer commercial support for their
Yocto compatible distributions.

For the project itself, and the projects under the umbrella, the
developer capacity to maintain and support a release for longer than a
year simply doesn't exist. And that lack of cycles is only from the
point of view of duration, much less to offer something that looks
like a SLA on critical issues.

Cheers,

Bruce








Regards,
Chris Simmonds







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

Re: [yocto] multiple yocto-kernel-cache mirrors support in linux-yocto style recipe

[Bruce Ashfield]

On 15-10-20 09:01 AM, Luo Zhenhua wrote:

Hi,

I created a bbappend for linux-yocto_4.1.bb to use our own kernel source
git url, a yocto-kernel-cache git tree is created to manage the distro
specific kernel fragments, I want to use both Yocto yocto-kernel-cache
and our own yocto-kernel-cache git, can this multiple yocto-kernel-cache
mirrors be supported by linux-yocto style bb file? If no, what’s the
best method to handle such multiple kernel fragments mirrors case?


Just add them into the SRC_URI, with their own name, destination and
type of kmeta (just like the yocto one).

The system will pick them up as meta data sources and allow them to
be used.

Cheers,

Bruce



Best Regards,

Zhenhua





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

Re: [yocto] kernel defconfig configuration

[Bruce Ashfield]

On 15-10-29 03:22 AM, Edward Wingate wrote:

On Tue, Oct 27, 2015 at 5:36 AM, Daniel.  wrote:

I suggest that you do an "bitbake -fc configure YOUR_KERNEL" and
inspect the .config WORKDIR folder. Is that yours .config?


I'm not sure if this is the WORKDIR I'm suppose to be looking at, but
after I ran that bitbake command, I found my defconfig in
build/tmp/work/wandboard-dual-poky-linux-gnueabi/linux-wandboard/3.14.28-r0

It is also in .config.old in
build/tmp/work/wandboard-dual-poky-linux-gnueabi/linux-wandboard/3.14.28-r0/build

The .config in in
build/tmp/work/wandboard-dual-poky-linux-gnueabi/linux-wandboard/3.14.28-r0/build
is not mine.  My .config seems to have been renamed to .config.old and
replaced with this one.


That's the kernel's configuration subsystem at play, it still has to
process the the defconfig (which was placed as .config before starting
the kernel build). Invalid options are removed, others are selected
by Kconfigs, etc. So what you end up with is the processed .config and
your old one in .config.old.

Cheers,

Bruce





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

Re: [yocto] kernel defconfig configuration

[Bruce Ashfield]

On 15-10-29 03:06 PM, Edward Wingate wrote:

On Thu, Oct 29, 2015 at 6:10 AM, Bruce Ashfield
 wrote:

That's the kernel's configuration subsystem at play, it still has to
process the the defconfig (which was placed as .config before starting
the kernel build). Invalid options are removed, others are selected
by Kconfigs, etc. So what you end up with is the processed .config and
your old one in .config.old.


Ah, OK, it's possible the option I wanted (CONFIG_REMOTEPROC) is not
available for my machine (imx6/wandboard) and so removed.  Where can I
look to see if a config option is valid for a particular
machine/architecture?


I'm working on some patches that will show you that as part of the
configuration audit task (there's potentially a library I can
leverage) .. but for now, either looking at the Kconfig's or running
menuconfig are the best (brute force) way to find what is missing.

Bruce



Thanks for the help.



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

Re: [yocto] Copying the kernel in the poky directory

[Bruce Ashfield]

On 15-11-26 02:39 AM, Deepika Teriar wrote:

Hi

I am customizing yocto for beaglebone black
I do not want my kernel to get downloaded from the git after I clean the
build directory. So i have kept the linux-kernel directory with the name
kernel-3.14.29 in the poky directory.
And in the linux-yocto_3.14.bb  file i have
changed SRC_URI *from:*

SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta
"

*to :*

SRC_URI = "file://${COREBASE}/kernel-3.14.29"

On compiling core-image-minimal I am getting the following error
*
ERROR: ExpansionError during parsing
/home/deepika/bbb/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb
: Failure expanding variable do_patch:
ExpansionError: Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI

*
Can any one tell me the error?


You still need the git protocol, the fetcher can't determine what to
do with the SRCREV.

Try:

SRC_URI = 
"git://${COREBASE}/kernel-3.14.29;protocol=file;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"


Bruce



Thanks
Deepika






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

Re: [yocto] [PATCH][yocto-kernel-cache] base.cfg: enable TMPFS_POSIX_ACL and TMPFS_XATTR

[Bruce Ashfield]

On 2015-11-26 2:50 AM, rongqing...@windriver.com wrote:

From: Roy Li 

enable Tmpfs POSIX Access Control Lists and Tmpfs extended attributes
this will remove the error when systemd apply the ACL to tmpfs:

 systemd-udevd[335]: Failed to apply ACL on /dev/dri/card0: Operation not 
supported
 systemd-udevd[552]: Failed to apply ACL on /dev/adsp: Operation not 
supported


I didn't notice this change. It should go to the linux-yocto mailing
list, not to the main yocto list.

I'll review this on Monday.

Cheers,

Bruce



Signed-off-by: Roy Li 
---
  ktypes/base/base.cfg | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/ktypes/base/base.cfg b/ktypes/base/base.cfg
index 3b8ccd2..28a0d83 100644
--- a/ktypes/base/base.cfg
+++ b/ktypes/base/base.cfg
@@ -933,6 +933,8 @@ CONFIG_PROC_FS=y
  CONFIG_PROC_KCORE=y
  CONFIG_SYSFS=y
  CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_TMPFS_XATTR=y
  # CONFIG_HUGETLB_PAGE is not set

  #



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

Re: [yocto] [PATCH][yocto-kernel-cache] netfilter: enable several netfilter options

[Bruce Ashfield]

On 2015-11-26 12:25 AM, rongqing...@windriver.com wrote:

From: Roy Li 

the below kernel options are enabled:
 LOG target support
 IPv6 connection tracking support,
 "addrtype" address type match support
 "recent" match support

the default configuration of ufw(Uncomplicated Firewall) asked them.


Like the other patch you submitted, this should go to the linux-yocto
list, but I'll reply here, since this one needs a bit more tweaking.



Signed-off-by: Roy Li 
---
  features/netfilter/netfilter.cfg | 4 
  1 file changed, 4 insertions(+)

diff --git a/features/netfilter/netfilter.cfg b/features/netfilter/netfilter.cfg
index 8ecef4a..7bb8490 100644
--- a/features/netfilter/netfilter.cfg
+++ b/features/netfilter/netfilter.cfg
@@ -62,12 +62,16 @@ CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
  CONFIG_NETFILTER_XT_MATCH_STRING=m
  CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
  CONFIG_NETFILTER_XT_MATCH_U32=m
+CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
+CONFIG_NETFILTER_XT_MATCH_RECENT=m
+CONFIG_NETFILTER_XT_TARGET_LOG=m


Adding these are fine, but if ufw needs these extra options, we should
also have a ufw.scc/.cfg fragment that can be triggered when ufw is
being built.

So either create that fragment and inside it, document the NF options
it needs, and have ufw include netfilter.scc to get the options you
are adding above.

or .. at the very least, put comments in the .cfg file above the
options indicating that they are required for ufw.

Bruce



  #
  # IP: Netfilter Configuration
  #
  CONFIG_NF_DEFRAG_IPV4=m
  CONFIG_NF_CONNTRACK_IPV4=m
+CONFIG_NF_CONNTRACK_IPV6=m
  CONFIG_NF_CONNTRACK_PROC_COMPAT=y
  CONFIG_IP_NF_IPTABLES=m
  CONFIG_IP_NF_MATCH_AH=m



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

Re: [yocto] [PATCH][yocto-kernel-cache] netfilter: enable several netfilter options

[Bruce Ashfield]

On 2015-11-30 8:08 PM, Rongqing Li wrote:



On 2015年11月30日 13:22, Bruce Ashfield wrote:

On 2015-11-26 12:25 AM, rongqing...@windriver.com wrote:

From: Roy Li 

the below kernel options are enabled:
 LOG target support
 IPv6 connection tracking support,
 "addrtype" address type match support
 "recent" match support

the default configuration of ufw(Uncomplicated Firewall) asked them.


Like the other patch you submitted, this should go to the linux-yocto
list, but I'll reply here, since this one needs a bit more tweaking.



Signed-off-by: Roy Li 
---
  features/netfilter/netfilter.cfg | 4 
  1 file changed, 4 insertions(+)

diff --git a/features/netfilter/netfilter.cfg
b/features/netfilter/netfilter.cfg
index 8ecef4a..7bb8490 100644
--- a/features/netfilter/netfilter.cfg
+++ b/features/netfilter/netfilter.cfg
@@ -62,12 +62,16 @@ CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
  CONFIG_NETFILTER_XT_MATCH_STRING=m
  CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
  CONFIG_NETFILTER_XT_MATCH_U32=m
+CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
+CONFIG_NETFILTER_XT_MATCH_RECENT=m
+CONFIG_NETFILTER_XT_TARGET_LOG=m


Adding these are fine, but if ufw needs these extra options, we should
also have a ufw.scc/.cfg fragment that can be triggered when ufw is
being built.

So either create that fragment and inside it, document the NF options
it needs, and have ufw include netfilter.scc to get the options you
are adding above.

or .. at the very least, put comments in the .cfg file above the
options indicating that they are required for ufw.


I think the below two configurations are more basic, not special to
ufw, and netfiler.cfg lost them.
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NF_CONNTRACK_IPV6=m


Sure, but we still don't have anything within the fragments or
their descriptions that document what ufw is looking for, which
means we could remove them in the feature and unknowingly break
that functionality.

You can still add those options to the netfilter config, but we'd
be wise to add those comments, or create a ufw.scc file that (for
now), simply includes netfilter.scc and indicates that ufw requires
the options as they are in that config.

Bruce




since this change has entered wrlinux kernel cache, I hope we do not
add the comment on .cfg


-Roy





Bruce



  #
  # IP: Netfilter Configuration
  #
  CONFIG_NF_DEFRAG_IPV4=m
  CONFIG_NF_CONNTRACK_IPV4=m
+CONFIG_NF_CONNTRACK_IPV6=m
  CONFIG_NF_CONNTRACK_PROC_COMPAT=y
  CONFIG_IP_NF_IPTABLES=m
  CONFIG_IP_NF_MATCH_AH=m








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

Re: [yocto] compiling out-of-tree modules with master

[Bruce Ashfield]

On 15-12-01 11:57 AM, Stuart Weaver wrote:

Hi All,

I’m currently merging my Yocto repo up to master (from Daisy). I’m
having problems compiling some of the out-of-tree modules that we have
which I’ve tracked down to the Makefiles looking for:

include/generated/autoconf.h

include/generated/uapi/linux/version.h

Now I originally had to heavily patch these Makefiles to include
variables like KERNEL_SRC and KERNEL_VERSION as they were just calling
shell commands (e.g. echo uname –a). However the KERNEL_SRC is pointing
to the new location of the source in ‘work-shared’ where none of the
generated .h files are.



STAGING_KERNEL_BUILDDIR is what you want. That's where all the artifacts
of the build required for external module builds are placed.

Bruce



Could someone inform on the differences in workflow and which variables
I should be using to point to the build source of the kernel (i.e.
work/corei7-intel-common-poky-linux/linuux-yocto/3.19.5…./linux-corei7-64-intel-common-standard-build)?

*Best Regards,*

*Stuart*


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__




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

Re: [yocto] [meta-oracle-java][PATCH v2] oracle-jse-jdk: Don't use ${D} installing symlink target

[Bruce Ashfield]

On 15-12-02 06:39 PM, Kyle Russell wrote:

When installed to the sysroot, this makes the symlink point to the
workdir, which is invalid in the sstate package.  Since we cd to
${D} before creating the symlink, this ensures the link is created
in the correct install location, so just point the link to the final
target so that the patch is correctly fixed up during populate_sysroot.


Looks good to me: Acked-by: Bruce Ashfield 



Signed-off-by: Kyle Russell 
---
  recipes-devtools/oracle-java/oracle-jse-jdk.inc |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk.inc 
b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
index 54e83b8..6f13125 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk.inc
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
@@ -16,7 +16,7 @@ do_install_class-native() {
  install -d -m 0755 ${D}${bindir}
  cp -a ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${libdir}/
  for prog in java javac; do
-   ( cd ${D}${bindir} && ln -sf 
${D}${libdir}/${JDK_JRE}${PV}_${PV_UPDATE}/bin/$prog )
+   ( cd ${D}${bindir} && ln -sf 
${libdir}/${JDK_JRE}${PV}_${PV_UPDATE}/bin/$prog )
  done

  ( cd ${D}${libdir}/${JDK_JRE}${PV}_${PV_UPDATE}/bin ; \



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

Re: [yocto] PREEMPT-RT patch: wrong header

[Bruce Ashfield]

On 12/07/2015 08:03 AM, mike9874 channel wrote:

Hello,
i am building an image for qeumux86 with the PREEMT-RT patch. Therefore
I use the following in my image.conf file:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
PREFERRED_VERSION_linux-yocto-rt ?= "4%"

I get an image with the 4.1.8-rt8-yocto-preempt-rt kernel. I have an
Application which is also build into the image where I try to use
SCHED_DEADLINE with sched_setattr() and struct sched_attr from
. My bitbake compiler throws following error: storage size of
'scheduling_attribut' isn't known.
Where do I get the correct Headers to compile my application?


You need to look at the kernel sources themselves:

STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"

The preempt-rt kernel isn't messing with the libc-headers, so if you
are missing a struct that it is modifying, it'll be in the kernel
source itself.

Bruce



Regards,
Mike




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

Re: [yocto] [PATCH][yocto-kernel-cache] netfilter: enable several netfilter options

[Bruce Ashfield]

On Tue, Dec 1, 2015 at 12:24 AM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 2015-11-30 8:08 PM, Rongqing Li wrote:
>
>>
>>
>> On 2015年11月30日 13:22, Bruce Ashfield wrote:
>>
>>> On 2015-11-26 12:25 AM, rongqing...@windriver.com wrote:
>>>
>>>> From: Roy Li 
>>>>
>>>> the below kernel options are enabled:
>>>>  LOG target support
>>>>  IPv6 connection tracking support,
>>>>  "addrtype" address type match support
>>>>  "recent" match support
>>>>
>>>> the default configuration of ufw(Uncomplicated Firewall) asked them.
>>>>
>>>
>>> Like the other patch you submitted, this should go to the linux-yocto
>>> list, but I'll reply here, since this one needs a bit more tweaking.
>>>
>>>
>>>> Signed-off-by: Roy Li 
>>>> ---
>>>>   features/netfilter/netfilter.cfg | 4 
>>>>   1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/features/netfilter/netfilter.cfg
>>>> b/features/netfilter/netfilter.cfg
>>>> index 8ecef4a..7bb8490 100644
>>>> --- a/features/netfilter/netfilter.cfg
>>>> +++ b/features/netfilter/netfilter.cfg
>>>> @@ -62,12 +62,16 @@ CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
>>>>   CONFIG_NETFILTER_XT_MATCH_STRING=m
>>>>   CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
>>>>   CONFIG_NETFILTER_XT_MATCH_U32=m
>>>> +CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
>>>> +CONFIG_NETFILTER_XT_MATCH_RECENT=m
>>>> +CONFIG_NETFILTER_XT_TARGET_LOG=m
>>>>
>>>
>>> Adding these are fine, but if ufw needs these extra options, we should
>>> also have a ufw.scc/.cfg fragment that can be triggered when ufw is
>>> being built.
>>>
>>> So either create that fragment and inside it, document the NF options
>>> it needs, and have ufw include netfilter.scc to get the options you
>>> are adding above.
>>>
>>> or .. at the very least, put comments in the .cfg file above the
>>> options indicating that they are required for ufw.
>>>
>>
>> I think the below two configurations are more basic, not special to
>> ufw, and netfiler.cfg lost them.
>> CONFIG_NETFILTER_XT_TARGET_LOG=m
>> CONFIG_NF_CONNTRACK_IPV6=m
>>
>
> Sure, but we still don't have anything within the fragments or
> their descriptions that document what ufw is looking for, which
> means we could remove them in the feature and unknowingly break
> that functionality.
>
> You can still add those options to the netfilter config, but we'd
> be wise to add those comments, or create a ufw.scc file that (for
> now), simply includes netfilter.scc and indicates that ufw requires
> the options as they are in that config.
>

ping.

And just so we are clear, I didn't merge this yet, and it should be
re-submitted
to the linux-yocto mailing list with the comments addressed.

Cheers,

Bruce


>
> Bruce
>
>
>>
>> since this change has entered wrlinux kernel cache, I hope we do not
>> add the comment on .cfg
>>
>>
>> -Roy
>>
>>
>>
>>
>>> Bruce
>>>
>>>
>>>>   #
>>>>   # IP: Netfilter Configuration
>>>>   #
>>>>   CONFIG_NF_DEFRAG_IPV4=m
>>>>   CONFIG_NF_CONNTRACK_IPV4=m
>>>> +CONFIG_NF_CONNTRACK_IPV6=m
>>>>   CONFIG_NF_CONNTRACK_PROC_COMPAT=y
>>>>   CONFIG_IP_NF_IPTABLES=m
>>>>   CONFIG_IP_NF_MATCH_AH=m
>>>>
>>>>
>>>
>>>
>>
> --
> ___
> 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"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][yocto-kernel-cache] base.cfg: enable TMPFS_POSIX_ACL and TMPFS_XATTR

[Bruce Ashfield]

On 11/26/2015 02:50 AM, rongqing...@windriver.com wrote:

From: Roy Li 

enable Tmpfs POSIX Access Control Lists and Tmpfs extended attributes
this will remove the error when systemd apply the ACL to tmpfs:

 systemd-udevd[335]: Failed to apply ACL on /dev/dri/card0: Operation not 
supported
 systemd-udevd[552]: Failed to apply ACL on /dev/adsp: Operation not 
supported


Sorry for the long delay on this, I thought I had replied before .. but
then found this in my inbox.

If already replied, I hope I'm consistent here.



Signed-off-by: Roy Li 
---
  ktypes/base/base.cfg | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/ktypes/base/base.cfg b/ktypes/base/base.cfg
index 3b8ccd2..28a0d83 100644
--- a/ktypes/base/base.cfg
+++ b/ktypes/base/base.cfg
@@ -933,6 +933,8 @@ CONFIG_PROC_FS=y
  CONFIG_PROC_KCORE=y
  CONFIG_SYSFS=y
  CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_TMPFS_XATTR=y


Looking at these more closely, I think they belong in the standard
and preempt-rt kernel types, versus base.cfg.

base is used by all kernel types, regardless of init system, or other
system capabilities. I know that tiny and other derivative kernels
may not want this, so it needs to be pulled one level higher.

Bruce


  # CONFIG_HUGETLB_PAGE is not set

  #



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

Re: [yocto] how can i figure out where a particular kernel config option came from?

[Bruce Ashfield]

On 12/09/2015 05:36 AM, Robert P. J. Day wrote:


   short version: with a short BSP layer i've been handed, the eventual
kernel .config file ends up with the setting:

   CONFIG_WIRELESS=y

which makes no sense as the target board has no wireless and the BSP
itself doesn't set that, so how can i start tracking back to figure
out where that particular setting came from?

   long version: i'm actually using Wind River Linux 7, but the
question remains the same. it turns out that CONFIG_WIRELESS is
selected by CONFIG_WLAN, so i'm really after what sets CONFIG_WLAN. i
don't see it in the BSP layer, so i'm tracing back to the WR kernel
recipe, and possibly features templates and any other kernel .cfg
snippets i can find, so far with no luck.

   in either case, is there a log file that lists *precisely* which
kernel config snippets contributed to the final .config file? thanks.


The meta-series in the kernel source directory has all the details.
If you locate the kernel source for your build, it'll be in a 'meta'
or '.meta' directory (depending on the version of the tools), and be
called ... 'meta-series'.

Bruce



rday



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

Re: [yocto] in-tree defconfig

[Bruce Ashfield]

On 12/09/2015 06:43 PM, Robert Berger wrote:

Hi,

This seems to do the trick:

https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/linux-yocto-custom.inc



That's what I would have suggested. Set the kconfig mode so that in
tree config becomes the baseline.

In the upcoming release, I have an open bugzilla to tweak the way
that this works, and I should be able to detect that in tree
defconfig and make alldefconfig the default for that mode.

Let me know if you have other issues with it.

Bruce


Regards,

Robert



..."The scientific name for an animal that doesn't either run from or
fight its enemies is lunch." - Michael Friedman

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




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

[yocto] [PATCH 2/3] poky-lsb/poky-tiny: update preferred kernel to 4.1

[Bruce Ashfield]

The 3.14 LTSI kernel has been removed, so we bump the preferred
kernel version to 4.1.

Signed-off-by: Bruce Ashfield 
---
 meta-yocto/conf/distro/poky-lsb.conf  | 2 +-
 meta-yocto/conf/distro/poky-tiny.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-yocto/conf/distro/poky-lsb.conf 
b/meta-yocto/conf/distro/poky-lsb.conf
index 6f2be808e4ed..e7d6995a7357 100644
--- a/meta-yocto/conf/distro/poky-lsb.conf
+++ b/meta-yocto/conf/distro/poky-lsb.conf
@@ -12,4 +12,4 @@ PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
 
 # Use the LTSI Kernel for LSB Testing
-PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "3.14%"
+PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.1%"
diff --git a/meta-yocto/conf/distro/poky-tiny.conf 
b/meta-yocto/conf/distro/poky-tiny.conf
index b0227dedf68e..fbcbf1ae716b 100644
--- a/meta-yocto/conf/distro/poky-tiny.conf
+++ b/meta-yocto/conf/distro/poky-tiny.conf
@@ -37,7 +37,7 @@ DISTRO = "poky-tiny"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "3.19%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "4.1%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
-- 
2.1.0

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

[yocto] [PATCH 0/3] yocto/meta-yocto-bsp: remove 3.14 and 3.19 references

[Bruce Ashfield]

Hi all,

As a follow up to a series I sent to the oe-core list, this series removes
references to the 3.14 and 3.19 kernel's that are being dropped. Hopefully
this is them all, but you never know ...

Since the preferred version was already 4.1 for the reference BSPs, I expect
minimal runtime fallout from this switch.

Bruce

The following changes since commit 019f38adf3086bba356b7d6175aafec2eaf4388a:

  linux-yocto: remove 3.14 and 3.19 recipes (2015-12-18 15:32:50 -0500)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (3):
  yocto-bsp: remove 3.14 and 3.19 bbappends
  poky-lsb/poky-tiny: update preferred kernel to 4.1
  meta-yocto-bsp: remove 3.14 and 3.19 bbappends

 .../linux/linux-yocto-rt_3.14.bbappend | 11 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 20 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 20 ---
 meta-yocto/conf/distro/poky-lsb.conf   |  2 +-
 meta-yocto/conf/distro/poky-tiny.conf  |  2 +-
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 62 --
 .../linux/linux-yocto-tiny_3.14.bbappend   | 62 --
 .../linux/linux-yocto-tiny_3.19.bbappend   | 62 --
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 61 -
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 61 -
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 40 files changed, 2 insertions(+), 1339 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/t

[yocto] [PATCH 3/3] meta-yocto-bsp: remove 3.14 and 3.19 bbappends

[Bruce Ashfield]

the 3.14 and 3.19 kernels have been removed from oe-core master, so
we drop the bbappens for the yocto reference BSPs.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_3.14.bbappend   | 11 ---
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend   | 20 
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend   | 20 
 3 files changed, 51 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.19.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
deleted file mode 100644
index 52fd07fd5d81..
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
+++ /dev/null
@@ -1,11 +0,0 @@
-KBRANCH_genericx86  = "standard/common-pc/base"
-KBRANCH_genericx86-64  = "standard/common-pc-64/base"
-
-KMACHINE_genericx86 ?= "common-pc"
-KMACHINE_genericx86-64 ?= "common-pc-64"
-
-SRCREV_machine_genericx86 ?= "bda175966009d5a94103559e6e6ae51279952f39"
-SRCREV_machine_genericx86-64 ?= "bda175966009d5a94103559e6e6ae51279952f39"
-
-COMPATIBLE_MACHINE_genericx86 = "genericx86"
-COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
deleted file mode 100644
index 589ece73c25d..
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ /dev/null
@@ -1,20 +0,0 @@
-KBRANCH_genericx86  = "standard/common-pc/base"
-KBRANCH_genericx86-64  = "standard/common-pc-64/base"
-KBRANCH_edgerouter = "standard/edgerouter"
-KBRANCH_beaglebone = "standard/beaglebone"
-KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
-
-KMACHINE_genericx86 ?= "common-pc"
-KMACHINE_genericx86-64 ?= "common-pc-64"
-
-SRCREV_machine_genericx86 ?= "af1f7f586bd32d39c057f17606991b887eadb389"
-SRCREV_machine_genericx86-64 ?= "578602a722dbfb260801f3b37c6eafd2abb2340d"
-SRCREV_machine_edgerouter ?= "578602a722dbfb260801f3b37c6eafd2abb2340d"
-SRCREV_machine_beaglebone ?= "578602a722dbfb260801f3b37c6eafd2abb2340d"
-SRCREV_machine_mpc8315e-rdb ?= "1cb1bbaf63cecc918cf36c89819a7464af4c4b13"
-
-COMPATIBLE_MACHINE_genericx86 = "genericx86"
-COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.19.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.19.bbappend
deleted file mode 100644
index c87f840ef43b..
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.19.bbappend
+++ /dev/null
@@ -1,20 +0,0 @@
-KBRANCH_genericx86  = "standard/common-pc"
-KBRANCH_genericx86-64  = "standard/common-pc-64/base"
-KBRANCH_edgerouter = "standard/edgerouter"
-KBRANCH_beaglebone = "standard/beaglebone"
-KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
-
-KMACHINE_genericx86 ?= "common-pc"
-KMACHINE_genericx86-64 ?= "common-pc-64"
-
-SRCREV_machine_genericx86 ?= "e152349de59b43b2a75f2c332b44171df461d5a0"
-SRCREV_machine_genericx86-64 ?= "e152349de59b43b2a75f2c332b44171df461d5a0"
-SRCREV_machine_edgerouter ?= "e152349de59b43b2a75f2c332b44171df461d5a0"
-SRCREV_machine_beaglebone ?= "e152349de59b43b2a75f2c332b44171df461d5a0"
-SRCREV_machine_mpc8315e-rdb ?= "2893f3e8ece72f6f47329714d6afe4c9c545bbf9"
-
-COMPATIBLE_MACHINE_genericx86 = "genericx86"
-COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
-- 
2.1.0

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

[yocto] [PATCH 1/3] yocto-bsp: remove 3.14 and 3.19 bbappends

[Bruce Ashfield]

The 3.14 and 3.19 kernel have been removed from oe-core, so we drop
our bbappends.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 .../linux/linux-yocto-rt_3.14.bbappend | 62 --
 .../linux/linux-yocto-tiny_3.14.bbappend   | 62 --
 .../linux/linux-yocto-tiny_3.19.bbappend   | 62 --
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 61 -
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 61 -
 .../linux/linux-yocto-rt_3.14.bbappend | 33 
 .../linux/linux-yocto-tiny_3.14.bbappend   | 33 
 .../linux/linux-yocto-tiny_3.19.bbappend   | 33 
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend | 32 ---
 .../recipes-kernel/linux/linux-yocto_3.19.bbappend | 32 ---
 35 files changed, 1286 deletions(-)
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/linux-yocto-tiny_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/linux-yocto_3.14.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/linux-yocto_3.19.bbappend
 delete mode 100644 
scripts/lib/bsp/substrate/target/arch/powerpc/recipes

Re: [linux-yocto] [PATCH 10/28] LSI AXM55xx: Various performance fixes for rapidio endpoint code.

[Bruce Ashfield]

On 14-05-02 03:16 PM, Charlie Paul wrote:

From: Michael Bringmann 

Increased the inbox mail buffer size by 8 times.


Is there a reason why it was increased ? Were events being lost under load ?

.. that's what we want to see in the commit message.


Removed __devinit from the initialization routines


Again, this really should be two commits.

Bruce



Signed-off-by: Michael Bringmann 
---
  drivers/rapidio/devices/lsi/axxia-rio-irq.c |   24 +---
  drivers/rapidio/devices/lsi/axxia-rio.c |4 ++--
  drivers/rapidio/rio.c   |9 ++---
  3 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/rapidio/devices/lsi/axxia-rio-irq.c 
b/drivers/rapidio/devices/lsi/axxia-rio-irq.c
index 73b5a4c..6a4d227 100644
--- a/drivers/rapidio/devices/lsi/axxia-rio-irq.c
+++ b/drivers/rapidio/devices/lsi/axxia-rio-irq.c
@@ -1010,7 +1010,7 @@ static inline int choose_ob_dme(
if (len > sz)
continue;

-   if (dme->entries >= (dme->entries_in_use+1)) {
+   if (dme->entries > (dme->entries_in_use+1)) {
(*ob_dme) = dme;
(*buf_sz) = sz;
return ret + i;
@@ -1474,7 +1474,6 @@ static void ib_dme_irq_handler(struct rio_irq_handler *h, 
u32 state)
u32 dw0;
int dme_no = 31 - CNTLZW(dme_mask);
int num_new;
-   int nPending;
dme_mask ^= (1 << dme_no);

while (mb->me[letter]->dme_no != dme_no)
@@ -1514,7 +1513,7 @@ static void ib_dme_irq_handler(struct rio_irq_handler *h, 
u32 state)
  #endif
/**
 * Set Valid flag to 0 on each desc with a new message.
-* Flag is reset when the message beloning to the desc
+* Flag is reset when the message belonging to the desc
 * is fetched in get_inb_message().
 * HW descriptor update and fetch is in order.
 */
@@ -1545,6 +1544,12 @@ static void ib_dme_irq_handler(struct rio_irq_handler 
*h, u32 state)
dw0 & ~DME_DESC_DW0_VALID);
}

+   if (mport->inb_msg[mbox_no].mcback)
+   mport->inb_msg[mbox_no].mcback(mport,
+   me->dev_id,
+   mbox_no,
+   desc->desc_no);
+
__ib_dme_dw_dbg(priv, dw0);
__ib_dme_event_dbg(priv, dme_no,
   1 << RIO_IB_DME_RX_PUSH);
@@ -1565,16 +1570,6 @@ static void ib_dme_irq_handler(struct rio_irq_handler 
*h, u32 state)
__ib_dme_event_dbg(priv, dme_no,
   1 << RIO_IB_DME_RX_RING_FULL);

-   nPending = atomic_read(&me->pending);
-   if (nPending &&
-   mport->inb_msg[mbox_no].mcback) {
-
-   mport->inb_msg[mbox_no].mcback(mport,
-  me->dev_id,
-  mbox_no,
-  letter);
-   }
-
if (dme_stat & IB_DME_STAT_SLEEPING) {
struct rio_msg_desc *desc;
u32 dme_ctrl;
@@ -2129,8 +2124,7 @@ static struct rio_msg_desc *get_ob_desc(struct rio_mport 
*mport,
   DESC_TABLE_W0(desc->desc_no),
   &dw0);
}
-   if (!(dw0 & DME_DESC_DW0_VALID) ||
-   (dw0 & DME_DESC_DW0_ERROR_MASK)) {
+   if (!(dw0 & DME_DESC_DW0_VALID)) {
if (desc_num != mb->write_idx)
return NULL;
if (desc_num == mb->write_idx)
diff --git a/drivers/rapidio/devices/lsi/axxia-rio.c 
b/drivers/rapidio/devices/lsi/axxia-rio.c
index 4673b6b..1f1fc39 100644
--- a/drivers/rapidio/devices/lsi/axxia-rio.c
+++ b/drivers/rapidio/devices/lsi/axxia-rio.c
@@ -1369,7 +1369,7 @@ static int rio_mport_dtb_setup(struct platform_device 
*dev,
return -ENOMEM;
}
rio_init_dbell_res(&mport->riores[RIO_DOORBELL_RESOURCE], 0, 0x);
-   rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 8);
+   rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 64);
rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 3);
sprintf(mport->name, "RIO%d mport", mport->id);

@@ -1743,7 +1743,7 @@ err_ops:
  /*
The probe function for RapidIO peer-to-peer n

Re: [linux-yocto] [PATCH 1/1] mei.cfg: enable Intel chipsets

[Bruce Ashfield]

On 14-05-02 08:01 PM, Kamble, Nitin A wrote:


On 4/25/2014 8:51 AM, Hart, Darren wrote:

On 4/24/14, 18:42, "Kamble, Nitin A"  wrote:


From: Nitin A Kamble 

Enable Intel Chipsets in the AMT/MEI driver.

Signed-off-by: Nitin A Kamble 

Acked-by: Darren Hart 

Hi Bruce,
Can you pull this fix in the v3.10 kernel repository as well?



No problem. I'm doing some -stable updates and will put this
on top of them.

Cheers,

Bruce


Thanks,
Nitin





---
meta/cfg/kernel-cache/features/amt/mei/mei.cfg | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg
b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg
index c1c2ace..313084b 100644
--- a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg
+++ b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg
@@ -1,3 +1,4 @@
CONFIG_STAGING=y
CONFIG_WATCHDOG_CORE=y
CONFIG_INTEL_MEI=y
+CONFIG_INTEL_MEI_ME=y
--
1.8.1.4








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

Re: [yocto] Anybody managed to get Beagleboard xM to work?

[Bruce Ashfield]

On 14-05-05 10:38 PM, Jeremy Cole-Baker wrote:

Hi,

Has anyone else been successful in getting a Beagleboard xM to work?


Our QA results for Yocto 1.5 and through most of the 1.6 cycle
had green results, with a few issues that are logged in the
bugzilla. Core functionality definitely worked.



I have built with Yocto, using the beagleboard-dora-10.0.0 package and
"core-image-basic". I installed everything to the uSD card as per
instructions, including root filesystem, modules, .dtb, kernel image and
boot loader.

It boots up fine (viewing via serial port console), and the content of
the system log looks good. However, there are no USB devices, including
the ethernet adaptor. It is supposed to appear as "usb0", but the only
adaptors are "lo" and "sit0". "ifup usb0" results in a "no such device"
error.


Hmm. As it stands, we did have some outstanding USB issues:

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

When we moved into 1.6 development, they got a bit less attention, since
efforts were moving to support of the beagle bone black as the reference
board.



Also, nothing appears in the log when I connect a USB memory stick.
There is no video output either.

Someone mentioned turning on "CONFIG_USB_ETH"; I enabled this under
Device Drivers->USB Support (I think it's called "Ethernet Gadget") but
it made no difference, and looking at the help, this setting is to do
with USB OTG which I don't need.

Anything else I am missing? Some configuration I need to set up? I have
no idea where to look! It is frustrating because it seems to be very
close to working.


As an alternative to using the Yocto reference BSP (Which I mentioned
has moved onto the BBB with a better focus on core functionality), the
meta-beagleboard layer has a more complete feature focus and should
solve the problem (via a different kernel and configuration).



Also, I'm loading the Kernel at 0x8030 and the .dtb at 0x815f
(see below). I don't remember where I got those addresses. How are those
addresses determined? Are they correct? I can't find any help on what
they should be, only examples of people using them.


As long as they are far enough apart (so the kernel doesn't clobber
the dtb, and vice versa), and not over where the kernel uncompresses ..
you'll be fine.

Cheers,

Bruce



Any suggestions very welcome!


=== Build Details: 
3.10.11-yocto-standard
beagleboard-dora-10.0.0
Build Machine: x86 / ubuntu 13.04

=== Target: 
BeagleBoard-xM Rev C


Here's the startup text and output of dmesg. It seems to indicate (to
me) that device drivers have been loaded and USB devices found OK:




Hit any key to stop autoboot:  0
i2c_write: pads on bus 0 probably not configured (status=0x10)
Could not write vsel to reg 85 (2)
mmc0 is current device
i2c_write: pads on bus 0 probably not configured (status=0x10)
Could not write vsel to reg 85 (2)
gpio: pin 173 (gpio 173) value is 0
gpio: pin 4 (gpio 4) value is 0
SD/MMC found on device 0
reading uEnv.txt
660 bytes read in 6 ms (107.4 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading zImage
4653552 bytes read in 298 ms (14.9 MiB/s)
reading beagle-xm.dtb
11444 bytes read in 9 ms (1.2 MiB/s)
Kernel image @ 0x8030 [ 0x00 - 0x4701f0 ]
## Flattened Device Tree blob at 815f
Booting using the fdt blob at 0x815f
Loading Device Tree to 8fffa000, end 8cb3 ... OK

Starting kernel ...


Poky (Yocto Project Reference Distro) 1.5 beagleboard /dev/ttyO2

beagleboard login: root
root@beagleboard:~# dmesg
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.11-yocto-standard (hundehoden@Huzap)
(gcc version 4.8.1 (GCC) ) #1 Tue May 6 12:10:22 NZST 2014
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic OMAP3 (Flattened Device Tree), model: TI
OMAP3 BeagleBoard xM
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 130816
[0.00] free_area_init_node: node 0, pgdat c09e9de4, node_mem_map
c0aab000
[0.00]   Normal zone: 1024 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 130816 pages, LIFO batch:31
[0.00] DT missing boot CPU MPIDR[23:0], fall back to default
cpu_logical_map
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in

Re: [yocto] A simpler way of creating an using a local kernel repository - BeagleBone example

[Bruce Ashfield]

On 2014-05-06, 6:31 PM, Bob Feretich wrote:

I have had problems getting good download performance when accessing the
kernels at kernel.org. Since I expect to build the kernel several times,
I decided to create a copy of the kernel repository locally and use that
for my builds.

There are instructions on how to create a local repository in the Yocto
manuals, but those are more complex than I needed. (I don't plan on
checking anything into the repository.)

The below is a simpler way of creating and using the repository.
I'm publishing this because my search though the Yocto/OE/Angstrom
yielded only the more complicated or incomplete methods.

// First set up local kernel repository
mkdir ~/ksrc3-8
cd ~/ksrc3-8
git clone --bare
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
stable-work-bare.git

// Then modify the kernel recipe to use the local repository instead of
the the one at kernel.org.
// The beaglebone recipe for the 3.8 kernel is at...
setup-scripts/sources/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb


// Replace the file's SRC_URI with one that points to your local
repository.
#SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=linux-3.8.y"

SRC_URI = "git:///home/Bob/ksrc3-8/stable-work-bare.git;branch=linux-3.8.y"


That's exactly how we've been doing it all along in the "meta-kernel-dev"
layer found in poky-extras (now meta-yocto-kernel-extras):

http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-kernel-extras/tree/meta-kernel-dev/recipes-kernel/linux

Cheers,

Bruce



Regards,
Bob


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

Re: [yocto] Anybody managed to get Beagleboard xM to work?

[Bruce Ashfield]

On 2014-05-06, 6:10 PM, Jeremy Cole-Baker wrote:

On 7/05/2014 2:01 a.m., Bruce Ashfield wrote:


Anything else I am missing? Some configuration I need to set up? I have
no idea where to look! It is frustrating because it seems to be very
close to working.


As an alternative to using the Yocto reference BSP (Which I mentioned
has moved onto the BBB with a better focus on core functionality), the
meta-beagleboard layer has a more complete feature focus and should
solve the problem (via a different kernel and configuration).




Hi, can you explain how to use the meta-beagleboard layer? My build was
done using the BSP for "Texas Instruments ARM Cortex-A8 development
board (Beagleboard)" (10.0.0 Dora). I downloaded it, and I think I built
it with Hob the first time. I also used 'bitbake' to adjust the
configuration and build from the command line to try different options.

I just downloaded the latest Yocto project 1.6 (11.0.0 Daisy), and had a
look around including running Hob. However, I couldn't find a
meta-beagleboard layer.


If I recall correctly, its this:

   https://github.com/beagleboard/meta-beagleboard

The Yocto reference BSPs themselves are about exercising core
functionality on easily available h/w references (one per major arch).

Those reference BSPs are on the Yocto release kernel (which is now
typically LTSI kernel), and hence have all the Yocto kernel features
(union filesystems, optional preempt-rt support, CVEs, -stable updates,
etc) and configuration meta-data (base policy + configuration fragemnt
support).

We try and make them as functional as possible, but sticking with the
stable and longer term kernels means that development which happens
on the latest mainline, or different community trees is only merged to
the Yocto kernel if we get explicit support and patches ported. That
means that some bleeding edge, or advanced functionality is available
in those feature-full and community supported trees.

The layer I pointed at above, has that mix of extended/enhanced
functionality.

We refreshed the the ARM reference to the beaglebone black in the latest
Yocto release, and thanks to TIs (via DenysD) support .. we have a
mainline supported, and very functional refernece.

That being said, working USB is core functionality and it was tested
green for the 1.5 release .. at least if my memory serves. So it
should be working in your build.

Bruce



I also downloaded and installed binaries for the latest build from:

autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/beagleboard/

These worked but showed the same behaviour (i.e. no USB). Maybe it has
something to do with the way I set up the boot environment?

Thanks,
Jeremy


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

Re: [yocto] linux-yocto custom device tree in overlay

[Bruce Ashfield]

On 14-05-07 11:33 AM, Andreas Galauner wrote:

Hi Yocto Community,

I'm currently trying to build a custom image for a beaglebone black for
which I need to enable the can-controllers on the SoC. I managed to
create an overlay which already deals with building a few tools for CAN
communication, I created a kernel config snippet for linux-yocto to
enable CAN-support in the kernel and it already works with a USB
transceiver.

Now I need to modify the device tree for the board to enable the SoC
controllers. How do I put the device tree into my overlay? I tried
several ways, but the kernel buildsystem doesn't seem to find the dts
file to be compiled.

That definitely doesn't work:

SRC_URI += "file://can.cfg \
 file://am335x-boneblack-cansniff.dts"
KERNEL_DEVICETREE = "am335x-boneblack-cansniff.dtb"


Any ideas? Google wasn't too fruitful either.
With non-yocto kernels I always put the device tree into the whole path
like 'git/arch/arm/boot/dts/mydevicetree.dts'  but that also doesn't
seem to work on linux-yocto because it uses another layout in its
working directory.


I use device trees all the time with linux-yocto based kernels, and
what you have above is fundamentally correct, except (as you noted)
the dts is going only be in ${WORKDIR} and not somewhere the kernel
build can find it.

So you can either patch it into the kernel, or do a bbappend with
that copies it into the source tree 
(linux/arch/arm/boot/dts/mydevicetree.dts).


Cheers,

Bruce



I'd rather not want to create my own git repo for linux-yocto like I did
for another project where I needed the same.

Thanks for your help,
- Andy



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

Re: [yocto] linux-yocto custom device tree in overlay

[Bruce Ashfield]

On 14-05-08 09:48 AM, Andreas Galauner wrote:

On 07/05/14 21:37, Bruce Ashfield wrote:

So you can either patch it into the kernel, or do a bbappend with
that copies it into the source tree
(linux/arch/arm/boot/dts/mydevicetree.dts).


Thx! That worked fine.


Glad to hear!

Bruce



For reference, this is what I added:

do_install_prepend() {
cp ${WORKDIR}/*.dts ${WORKDIR}/linux/arch/${ARCH}/boot/dts/
}


Cheers,
- Andy



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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bruce Ashfield]

On 14-05-09 09:44 AM, Brian Karcz wrote:

Hi,

Not sure if this is the correct place to email this, but I’ve seen a few
other meta-atmel references so I figured I’d give it a shot.

I’m attempting to setup a core-image-minimal build using the guidelines
in the meta-atmel README for the at91sam9x5ek machine type. When the
kernel build goes to link, I get a “no machine record defined” error. Is
this something others are seeing in the meta-atmel demo builds?

It’s a pretty benign build setup according to the README:

git clone git://git.yoctoproject.org/poky

cd poky

git checkout dora-10.0.1 -b dora-10.0.1

git clone git://git.openembedded.org/meta-openembedded

cd meta-openembedded

git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch

cd ..

git clone http://github.com/linux4sam/meta-atmel

source oe-init-build-env /workspace/build-atmel

modify local.conf:

MACHINE ??= ”at91sam9x5ek”

PACKAGE_CLASSES ?= “package_ipk”

modify bblayers.conf:

BBLAYERS ?= " \

   /opt/poky/meta-atmel \

   /opt/poky/meta \

   /opt/poky/meta-yocto \

   /opt/poky/meta-yocto-bsp \

   /opt/poky/meta-openembedded/meta-oe \

   /opt/poky/meta-openembedded/meta-networking \

   "

bitbake core-image-minimal

Setting this up, I get the following build configuration and error:

/workspace/build-atmel$ bitbake core-image-minimal

Loading cache: 100%
|##|
ETA:  00:00:00

Loaded 1782 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

Build Configuration:

BB_VERSION= "1.20.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING   = "Ubuntu-12.04"

TARGET_SYS= "arm-poky-linux-gnueabi"

MACHINE   = "at91sam9x5ek"

DISTRO= "poky"

DISTRO_VERSION= "1.5.1"

TUNE_FEATURES = "armv5 thumb dsp"

TARGET_FPU= "soft"

meta-atmel= "master:269066a8128d1e767deee64854a142e67451a5f2"

meta

meta-yocto

meta-yocto-bsp= "dora-10.0.1:8e410e9e46e3335458a7747cdd32e05f5c19ccbb"

meta-oe

meta-networking   = "my_branch:6572316557e742c2dc93848e4d560242bf0c3995"

NOTE: Preparing runqueue

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

ERROR: Function failed: do_compile (log file is located at
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)

ERROR: Logfile of failure stored in:
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291

Log data follows:

| DEBUG: Executing shell function do_compile

| NOTE: make -j 2 zImage CC=arm-poky-linux-gnueabi-gcc
-mno-thumb-interwork -marm LD=arm-poky-linux-gnueabi-ld.bfd

|   GEN
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux-at91sam9x5ek-standard-build/Makefile

|   CHK include/generated/uapi/linux/version.h

|   CHK include/generated/utsrelease.h

|   Using
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux
as source for kernel

| make[3]: `include/generated/mach-types.h' is up to date.

|   CC  scripts/mod/devicetable-offsets.s

|   GEN scripts/mod/devicetable-offsets.h

|   HOSTCC  scripts/mod/file2alias.o

|   CALL
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux/scripts/checksyscalls.sh

|   HOSTLD  scripts/mod/modpost

|   CHK include/generated/compile.h

|   LINKvmlinux

|   LD  vmlinux.o

|   MODPOST vmlinux.o

|   GEN .version

|   CHK include/generated/compile.h

|   UPD include/generated/compile.h

|   CC  init/version.o

|   LD  init/built-in.o

| arm-poky-linux-gnueabi-ld.bfd: no machine record defined

| make[2]: *** [vmlinux] Error 1

| make[1]: *** [sub-make] Error 2

| make: *** [all] Error 2

| ERROR: oe_runmake failed

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_compile (log file is located at
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)

ERROR: Task 208
(/opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb,
do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 793 tasks of which 785 didn't need to be
rerun and 1 failed.

Waiting for 0 running tasks to finish:

Summary: 1 task failed:

   /opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb,
do_compile

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Any thoughts on what might be missing from the README or my
implementation of it to get this demo build working?


Can you confirm that the final .config for the board has the machine
definitions that you'd expect for the board ?

Bruce



Thanks,

Brian





--

Re: [yocto] Question / issue

[Bruce Ashfield]

On 14-05-09 01:14 AM, Paul McGougan wrote:


Hi all.

We are currently using Poky 1.5.0.

We have created our own custom layer for our powerpc-based board.

We are running u-boot as our bootloader and want to use the new FIT 
(FDT) style kernel/dtb image blob.


To that end, in our custom layer we have a file 
poky/meta-OURS/recipes-kernel/linux/linux-yocto_3.10.bbappend, and in 
that file I have a function do_install_append() in which I call 
u-boot's mkimage passing it the kernel and DTB files that we want 
stored in the FIT image that we will use to boot from u-boot.


My first question is, is there a better place to be making the FIT image?



It depends on if everything you need to construct the FIT image is
in the kernel's build directory, or also available in the sysroot/deploy
directories.

If you need kernel build artifacts, doing it in the bbappend (or a .inc,
.bbclass, etc) of the kernel recipe is the right place.

As a side-question to that, I was surprised that there isn't native 
support already for creating this type of u-boot image considering how 
useful it is, does anyone know if there is a specific reason no one 
has done this yet?




None that I know of (but I haven't checked all the SDK, vendor
and distro layers in the ecosystem).

Either a image_types bbclass or something like the existing linux-dtb.inc
could fill the roll. It just depends on what is needed to build the uImage.

Secondly, (and this is our main issue) I have found that by adding the 
do_install_append function, even if it is completely empty, whenever I 
try to bitbake anything that depends on the kernel, that bitbake 
always re-runs the kernel install stage, even when there have been no 
changes. Literally I can run a bitbake, then run the same bitbake 
command again, and both times the kernel install stage gets run (this 
is a problem because it takes a long time to run). It appears to be 
happening because the stampfile is not found every time (the hash 
appears to be wrong). Is this a bug? Is there a fix or work-around for 
this problem?




In this front, I'm not the best reference. Checking the sstate signature
might help, it should show which variables are being used .. and possibly
invalidating the signature, triggering the steps to run again.

Bruce


Thanks.

Paul.


Confidentiality Notice: This message (including attachments) is a 
private communication solely for use of the intended recipient(s). If 
you are not the intended recipient(s) or believe you received this 
message in error, notify the sender immediately and then delete this 
message. Any other use, retention, dissemination or copying is 
prohibited and may be a violation of law, including the Electronic 
Communication Privacy Act of 1986."   ­­





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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bruce Ashfield]

On 14-05-09 10:58 AM, Brian Karcz wrote:

Hi Bruce,

I'm not entirely familiar with the mechanism that gets the defconfig from the 
BSP to the .config in work area, but here is how things currently look. The two 
files aren't a direct match as there appear to be some formatting differences, 
but the variables in the SOC/ARCH section seem to correlate partially (ie. it 
knows its trying to build for an at91sam9x5 SOC).

defconfig:
CONFIG_ARCH_AT91=y
CONFIG_SOC_AT91SAM9260=y
CONFIG_SOC_AT91SAM9263=y
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
CONFIG_MACH_AT91SAM_DT=y

.config:
#
# Atmel AT91 Processor
#
# CONFIG_SOC_AT91RM9200 is not set
CONFIG_SOC_AT91SAM9260=y
# CONFIG_SOC_AT91SAM9261 is not set
CONFIG_SOC_AT91SAM9263=y
# CONFIG_SOC_AT91SAM9RL is not set
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
# CONFIG_SOC_AT91SAM9N12 is not set

#
# Atmel Non-DT world
#
CONFIG_ARCH_AT91_NONE=y
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
# CONFIG_ARCH_AT91SAM9261 is not set
# CONFIG_ARCH_AT91SAM9263 is not set
# CONFIG_ARCH_AT91SAM9RL is not set
# CONFIG_ARCH_AT91SAM9G45 is not set

#
# AT91 Board Options
#

#
# Generic Board Type
#
# CONFIG_MACH_AT91SAM9_DT is not set

Given the fact that the ARCH and DT variables don't appear to match, it looks 
like this might be device tree related.


The reason I asked is that in the past, the error you are seeing
was related to the machine not being properly defined in the
kernel's .config.

FWIW, assuming you have a full "defconfig", and not a "save_defconfig"
variant, the path from it to the final .config is pretty much a copy
into the kernel and a "make oldconfig", so nothing is thrown away
unless there is a missing dependency, or the Kconfig doesn't exist in
the given kernel.

It's worth checking via menuconfig to see if anything obvious is
missing, and trying some quick builds to rule out a bad configuration.

Bruce



I was hoping the code out of the box was going to be able to provide a demo 
image that I could build and poke around in for some guidance. My ultimate goal 
is to port the at91sam9x5ek machine definition to one for the at91sam9g20ek 
demo board and then port THAT over to a custom machine based roughly off that 
reference design.


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, May 09, 2014 9:55 AM
To: Brian Karcz; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" 
failure for core-image-minimal

On 14-05-09 09:44 AM, Brian Karcz wrote:

Hi,

Not sure if this is the correct place to email this, but I've seen a
few other meta-atmel references so I figured I'd give it a shot.

I'm attempting to setup a core-image-minimal build using the
guidelines in the meta-atmel README for the at91sam9x5ek machine type.
When the kernel build goes to link, I get a "no machine record
defined" error. Is this something others are seeing in the meta-atmel demo 
builds?

It's a pretty benign build setup according to the README:

git clone git://git.yoctoproject.org/poky

cd poky

git checkout dora-10.0.1 -b dora-10.0.1

git clone git://git.openembedded.org/meta-openembedded

cd meta-openembedded

git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch

cd ..

git clone http://github.com/linux4sam/meta-atmel

source oe-init-build-env /workspace/build-atmel

modify local.conf:

MACHINE ??= "at91sam9x5ek"

PACKAGE_CLASSES ?= "package_ipk"

modify bblayers.conf:

BBLAYERS ?= " \

/opt/poky/meta-atmel \

/opt/poky/meta \

/opt/poky/meta-yocto \

/opt/poky/meta-yocto-bsp \

/opt/poky/meta-openembedded/meta-oe \

/opt/poky/meta-openembedded/meta-networking \

"

bitbake core-image-minimal

Setting this up, I get the following build configuration and error:

/workspace/build-atmel$ bitbake core-image-minimal

Loading cache: 100%
|#
|#|
ETA:  00:00:00

Loaded 1782 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

Build Configuration:

BB_VERSION= "1.20.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING   = "Ubuntu-12.04"

TARGET_SYS= "arm-poky-linux-gnueabi"

MACHINE   = "at91sam9x5ek"

DISTRO= "poky"

DISTRO_VERSION= "1.5.1"

TUNE_FEATURES = "armv5 thumb dsp"

TARGET_FPU= "soft"

meta-atmel= "master:269066a8128d1e767deee64854a142e67451

Re: [yocto] Question / issue

[Bruce Ashfield]

On 14-05-12 01:56 AM, Paul McGougan wrote:

From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]


Secondly, (and this is our main issue) I have found that by adding the
do_install_append function, even if it is completely empty, whenever I
try to bitbake anything that depends on the kernel, that bitbake always
re-runs the kernel install stage, even when there have been no changes.
Literally I can run a bitbake, then run the same bitbake command again,
and both times the kernel install stage gets run (this is a problem
because it takes a long time to run). It appears to be happening because
the stampfile is not found every time (the hash appears to be wrong).
Is this a bug? Is there a fix or work-around for this problem?



In this front, I'm not the best reference. Checking the sstate signature
might help, it should show which variables are being used .. and possibly
invalidating the signature, triggering the steps to run again.


Thanks Bruce.

Just for reference of anyone else who runs into a similar issue our issue was:
1. The do_install_append function was not *really* empty, the content of it
was commented out.
2. The dependency parser when parsing recipes not only looks for content
changes, but for also for changes to the values of referenced variables, and
unfortunately it still performs variable-value substitution in commented-out
code. In our case, we had the variable $DATETIME in there (but commented
out), this caused the dependency checker to substitute in the current value for
DATETIME which of course changed on each run.


Aha. That's what I thought it might be (and what I've been hit by
before in the past), sstate signature checking showed the variable
in these other cases .. so I thought I'd suggest it.

Glad to hear you have a working solution.

Cheers,

Bruce



The fix was to add:
do_install[vardepsexclude] += "DATETIME"

Regards,
Paul McGougan

Confidentiality Notice:  This message (including attachments) is a private 
communication solely for use of the intended recipient(s).
If you are not the intended recipient(s) or believe you received this message 
in error, notify the sender immediately and then delete this
message.  Any other use, retention, dissemination or copying is prohibited and 
may be a violation of law, including the Electronic
Communication Privacy Act of 1986."



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

Re: [yocto] kernel-yocto.bbclass ignoring SRCREV?

[Bruce Ashfield]

On 14-05-21 08:33 AM, Wolfgang Denk wrote:

Hi,

is my understanding of kernel-yocto.bbclass correct that it
effectively completely ignores any specific git commit ID that was
gien in SRCREV, but instead always checks out and uses the HEAD of the
respective branch?

Or am I missing something here?  My expectation was that we specify a
git commit ID (as the only reliable, truly unique identifier for a
specific source code version) in SRCREV, but instead it appears that
this information is effectively being ignored?


kernel-yocto does respect SRCREV. It uses the routine do_validate_branches
to reset to a specific SRCREV as a baseline, it then starts processing
and applying BSP descriptions on top of that point.

We test SRCREV specific builds on a ongoing basis, so they do work,
and if a different behaviour is being seen .. that's a bug.

Cheers,

Bruce



I can understand that there are situations where automatically using
the top commit of a branch (say, the latest stable version of some
package) may be useful, but should there not be some different way to
do that?

I mean, how can we make sure to ever be able to reproduce the very
same build if the git commit ID specified in SRCREV will not be used
for the checkout?

Thanks in advance.

Best regards,

Wolfgang Denk



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

Re: [yocto] kernel-yocto.bbclass ignoring SRCREV?

[Bruce Ashfield]

On 14-05-21 08:44 AM, Bruce Ashfield wrote:

On 14-05-21 08:33 AM, Wolfgang Denk wrote:

Hi,

is my understanding of kernel-yocto.bbclass correct that it
effectively completely ignores any specific git commit ID that was
gien in SRCREV, but instead always checks out and uses the HEAD of the
respective branch?

Or am I missing something here?  My expectation was that we specify a
git commit ID (as the only reliable, truly unique identifier for a
specific source code version) in SRCREV, but instead it appears that
this information is effectively being ignored?


kernel-yocto does respect SRCREV. It uses the routine do_validate_branches
to reset to a specific SRCREV as a baseline, it then starts processing
and applying BSP descriptions on top of that point.


And I forgot to point out that do_validate_branches() has been nearly
completely removed/rewritten as part of the upcoming yocto 1.7
development cycle. So what I mention above is more clear in the new
versions.

Bruce



We test SRCREV specific builds on a ongoing basis, so they do work,
and if a different behaviour is being seen .. that's a bug.

Cheers,

Bruce



I can understand that there are situations where automatically using
the top commit of a branch (say, the latest stable version of some
package) may be useful, but should there not be some different way to
do that?

I mean, how can we make sure to ever be able to reproduce the very
same build if the git commit ID specified in SRCREV will not be used
for the checkout?

Thanks in advance.

Best regards,

Wolfgang Denk





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

Re: [yocto] Building for Boards not supported by Yocto Project

[Bruce Ashfield]

On 14-06-05 07:28 AM, Kashyap Gada wrote:

Hello.

I have successfully built and tested core-image-sato through the process
given by the quick start guide at the yocto project website. Now I
intend to build an image for a board which is not officially supported
by yocto project. I have a FriendlyArm mini6410 whose BSP is available
for linux.

I would like to know how should I proceed further.
Is it possible to use the same BSP without any changes and make an image
using Yocto?


Using the Yocto BSP guide 
(http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html)

as a reference, you can create a minimal BSP layer for the board.

You don't have to do everything in the guide, but you do need to
have a machine definition, the userspace tuning and a custom kernel
recipe for the platform (i.e. you point at some vendor or project
tree that has all the required patches).

Unless the support for the board is already in the mainline kernel, and
then you can have a custom linux-yocto recipe to leverage the existing
configuration and code in the linux-yocto repository.

Cheers,

Bruce



Kashyap Gada




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

Re: [yocto] Newbee - patching kernel

[Bruce Ashfield]

On 14-06-06 09:39 AM, Kai Ulrich wrote:

Hi,

Is there a way to create a separate layer that adds kernel patches to an
existing machine?
Is there a example to learn from?


Patching the kernel works just like patching any package, but there is a
specific section in the manual (which perhaps you've already read):

http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#patching-the-kernel

It contains examples as well as explanations.

Bruce




friendly regards
Kai Ulrich




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

Re: [yocto] Hmm, possible bug in poky?

[Bruce Ashfield]

On 14-06-06 07:16 AM, Neuer User wrote:

I get the following error:

WARNING: Failed to fetch URL file://defconfig, attempting MIRRORS if
available
ERROR: Fetcher failure: Unable to find file file://defconfig anywhere.
The paths that were searched were:

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/poky
...
 /home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/arm

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30-linux4kix/

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i/
 /home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/
 /home/ubuntu/yocto/downloads/
ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'.
Unable to fetch URL from any source.


Now, the directory:


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/

which is listed above, contains the "missing" file ("defconfig").

Hmm, strange...



Here are my recipes:

linux-cubox-i_3.10.30.inc:

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

SUMMARY = "Linaro Kernel 3.10.30 with additional machine specific patches"

SRCBRANCH ?= "linux-linaro-lsk-mx6"

FILESEXTRAPATHS_prepend += "${THISDIR}/${PN}-3.10.30:"


Have you tried this variant ?

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.10.30:"

You need the := in the assignment to have it evaluate immediately and
pick up the directory of your bbappend (who's subdir is the one that
contains the defconfig).

Bruce




SRC_URI = "file://defconfig \
file://videoin.cfg \
file://networking.cfg \
file://wlan.cfg \
file://dm-crypt.cfg \
file://no-caam.cfg \
file://leds.cfg \
file://mod-to-builtin.cfg \
file://brcmfmac4330-sdio.bin \
file://brcmfmac4330-sdio.txt \
"

do_configure_append () {
 cd ${S}
 mkdir firmware/brcm
 cp ../brcmfmac4330-sdio.bin ./firmware/brcm/
 cp ../brcmfmac4330-sdio.txt ./firmware/brcm/
}

COMPATIBLE_MACHINE = "(cubox-i)"

KERNEL_IMAGETYPE_cubox-i = "zImage"
KERNEL_DEVICETREE_cubox-i = "imx6dl-cubox-i.dtb imx6q-cubox-i.dtb"

SRCREV_machine = "${SRCREV}"



linux-cubox-i_3.10.30.bb:

include linux-cubox-i_3.10.30.inc

SRCREV = "592b2d941dc3ecb6335d6820757340ffb5a192c8"
#SRCREV = "860304ab6e749777523f3714d18c4c7d39b728fa"
LOCALVERSION = "-cubox-i+SolidRun+${SRCPV}"

SRC_URI +=
"git://github.com/SolidRun/linux-linaro-stable-mx6;branch=${SRCBRANCH}"
---


linux-cubox-i_3.10.30-linux4kix.bb:

include linux-cubox-i_3.10.30.inc

SRCREV = "a4ed70040f9dfdcdd6546a85c0477ecd1030e065"
LOCALVERSION = "-cubox-i+linux4kix+${SRCPV}"

SRC_URI +=
"git://github.com/linux4kix/linux-linaro-stable-mx6.git;branch=${SRCBRANCH}"





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

Re: [yocto] Hmm, possible bug in poky?

[Bruce Ashfield]

On 14-06-06 10:56 AM, Neuer User wrote:

Hi Bruce

Thanks for the hint. I changed it, but the result is the same.

Strange is really that it shows the directory as being searched through
but does not find the file that's contained?!

Also, there are two "main" recipes, which both include the inc file.
This one throws warnings, but works:

linux-cubox-i_3.10.30.bb

This one throws warnings and then the error shown:

linux-cubox-i_3.10.30-linux4kix.bb


${PN} is going to change between those two recipes, so the defconfig
will need to be in a different directory for each recipe.

But as Gary just suggested, getting a full directory listing in
tree format would help clarify they layout you are using.

Bruce



Am I doing it right (now with the :=), or is there something
fundamentally wrong with the two recipes and the include file?

Michael

Am 06.06.2014 16:40, schrieb Bruce Ashfield:

On 14-06-06 07:16 AM, Neuer User wrote:

I get the following error:

WARNING: Failed to fetch URL file://defconfig, attempting MIRRORS if
available
ERROR: Fetcher failure: Unable to find file file://defconfig anywhere.
The paths that were searched were:

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/poky

...

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/arm

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30-linux4kix/


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i/


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/
  /home/ubuntu/yocto/downloads/
ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'.
Unable to fetch URL from any source.


Now, the directory:


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/


which is listed above, contains the "missing" file ("defconfig").

Hmm, strange...



Here are my recipes:

linux-cubox-i_3.10.30.inc:

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

SUMMARY = "Linaro Kernel 3.10.30 with additional machine specific
patches"

SRCBRANCH ?= "linux-linaro-lsk-mx6"

FILESEXTRAPATHS_prepend += "${THISDIR}/${PN}-3.10.30:"


Have you tried this variant ?

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.10.30:"

You need the := in the assignment to have it evaluate immediately and
pick up the directory of your bbappend (who's subdir is the one that
contains the defconfig).

Bruce




SRC_URI = "file://defconfig \
 file://videoin.cfg \
 file://networking.cfg \
 file://wlan.cfg \
 file://dm-crypt.cfg \
 file://no-caam.cfg \
 file://leds.cfg \
 file://mod-to-builtin.cfg \
 file://brcmfmac4330-sdio.bin \
 file://brcmfmac4330-sdio.txt \
"

do_configure_append () {
  cd ${S}
  mkdir firmware/brcm
  cp ../brcmfmac4330-sdio.bin ./firmware/brcm/
  cp ../brcmfmac4330-sdio.txt ./firmware/brcm/
}

COMPATIBLE_MACHINE = "(cubox-i)"

KERNEL_IMAGETYPE_cubox-i = "zImage"
KERNEL_DEVICETREE_cubox-i = "imx6dl-cubox-i.dtb imx6q-cubox-i.dtb"

SRCREV_machine = "${SRCREV}"



linux-cubox-i_3.10.30.bb:

include linux-cubox-i_3.10.30.inc

SRCREV = "592b2d941dc3ecb6335d6820757340ffb5a192c8"
#SRCREV = "860304ab6e749777523f3714d18c4c7d39b728fa"
LOCALVERSION = "-cubox-i+SolidRun+${SRCPV}"

SRC_URI +=
"git://github.com/SolidRun/linux-linaro-stable-mx6;branch=${SRCBRANCH}"
---


linux-cubox-i_3.10.30-linux4kix.bb:

include linux-cubox-i_3.10.30.inc

SRCREV = "a4ed70040f9dfdcdd6546a85c0477ecd1030e065"
LOCALVERSION = "-cubox-i+linux4kix+${SRCPV}"

SRC_URI +=
"git://github.com/linux4kix/linux-linaro-stable-mx6.git;branch=${SRCBRANCH}"











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

Re: [yocto] Newbee - patching kernel

[Bruce Ashfield]

On 14-06-06 04:00 PM, Kai Ulrich wrote:

Hi Bruce,

Thanx for your answer.

So can I write a recipe which just contains the patches an extends an 
kernel-recipe?


Correct. You add them to the SRC_URI, just like you'd patch any package.

Bruce




k.


/  Hi,

/>/
/>/  Is there a way to create a separate layer that adds kernel patches to an
/>/  existing machine?
/>/  Is there a example to learn from?
/
Patching the kernel works just like patching any package, but there is a
specific section in the manual (which perhaps you've already read):

http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#patching-the-kernel

It contains examples as well as explanations.

Bruce



/

/>/  friendly regards
/>/  Kai Ulrich
/>/
/>/
/





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

Re: [yocto] Hmm, possible bug in poky?

[Bruce Ashfield]

On 14-06-06 11:36 AM, Neuer User wrote:

Hi Gary, Hi Bruce

This is the directory layout:

Both recipes are extremely similar, only differ by a different git repo
and SRCREV. I might need to later have different patches for both
recipes, but currently everthing is identical. That's why I made an
include file.

.
├── linux-cubox-i-3.10.30
│   ├── brcmfmac4330-sdio.bin
│   ├── brcmfmac4330-sdio.txt
│   ├── defconfig
│   ├── dm-crypt.cfg
│   ├── leds.cfg
│   ├── mod-to-builtin.cfg
│   ├── networking.cfg
│   ├── no-caam.cfg
│   ├── touchscreen.cfg
│   ├── videoin.cfg
│   └── wlan.cfg
├── linux-cubox-i_3.10.30.bb
├── linux-cubox-i_3.10.30.inc
└── linux-cubox-i_3.10.30-linux4kix.bb


I looks to be what I mentioned in my other reply. If you are using
${PN} to add the directories for searching, then the two recipes
shouldn't result in the same ${PN} value, even if they are using a
common .inc.

Check the output of bitbake -e when you build the non-working
recipe, what does it have for PN ?

Bruce








Am 06.06.2014 17:12, schrieb Gary Thomas:

On 2014-06-06 08:56, Neuer User wrote:

Hi Bruce

Thanks for the hint. I changed it, but the result is the same.

Strange is really that it shows the directory as being searched through
but does not find the file that's contained?!

Also, there are two "main" recipes, which both include the inc file.
This one throws warnings, but works:

linux-cubox-i_3.10.30.bb

This one throws warnings and then the error shown:

linux-cubox-i_3.10.30-linux4kix.bb


It's a bit hard to see what files you have where.  Perhaps you
could send a listing, e.g. for the standard Yocto kernel:
   $ tree meta/recipes-kernel/linux
   meta/recipes-kernel/linux
   ├── linux-dtb.inc
   ├── linux-dummy
   │   └── COPYING.GPL
   ├── linux-dummy.bb
   ├── linux-yocto_3.10.bb
   ├── linux-yocto_3.14.bb
   ├── linux-yocto_3.4.bb
   ├── linux-yocto-dev.bb
   ├── linux-yocto.inc
   ├── linux-yocto-rt_3.10.bb
   ├── linux-yocto-rt_3.14.bb
   ├── linux-yocto-rt_3.4.bb
   ├── linux-yocto-tiny_3.10.bb
   ├── linux-yocto-tiny_3.14.bb
   └── linux-yocto-tiny_3.4.bb

Do this for each of the kernel recipes you are trying to use.



Am I doing it right (now with the :=), or is there something
fundamentally wrong with the two recipes and the include file?

Michael

Am 06.06.2014 16:40, schrieb Bruce Ashfield:

On 14-06-06 07:16 AM, Neuer User wrote:

I get the following error:

WARNING: Failed to fetch URL file://defconfig, attempting MIRRORS if
available
ERROR: Fetcher failure: Unable to find file file://defconfig anywhere.
The paths that were searched were:

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/poky


...

/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/arm


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/



/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30-linux4kix/



/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i/



/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/files/
   /home/ubuntu/yocto/downloads/
ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'.
Unable to fetch URL from any source.


Now, the directory:


/home/ubuntu/yocto/sources/meta-omnisonix/recipes-kernel/linux/linux-cubox-i-3.10.30/



which is listed above, contains the "missing" file ("defconfig").

Hmm, strange...



Here are my recipes:

linux-cubox-i_3.10.30.inc:

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

SUMMARY = "Linaro Kernel 3.10.30 with additional machine specific
patches"

SRCBRANCH ?= "linux-linaro-lsk-mx6"

FILESEXTRAPATHS_prepend += "${THISDIR}/${PN}-3.10.30:"


Have you tried this variant ?

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.10.30:"

You need the := in the assignment to have it evaluate immediately and
pick up the directory of your bbappend (who's subdir is the one that
contains the defconfig).

Bruce




SRC_URI = "file://defconfig \
  file://videoin.cfg \
  file://networking.cfg \
  file://wlan.cfg \
  file://dm-crypt.cfg \
  file://no-caam.cfg \
  file://leds.cfg \
  file://mod-to-builtin.cfg \
  file://brcmfmac4330-sdio.bin \
  file://brcmfmac4330-sdio.txt \
"

do_configure_append () {
   cd ${S}
   mkdir firmware/brcm
   cp ../brcmfmac4330-sdio.bin ./firmware/brcm/
   cp ../brcmfmac4330-sdio.txt ./firmware/brcm/
}

COMPATIBLE_MACHINE = "(cubox-i)"

KERNEL_IMAGETYPE_cubox-i = "zImage"
KERNEL_DEVICETREE_cubox-i = "imx6dl-cubox-i.dtb imx6q-cubox-i.dtb"

SRCREV_machine = "${SRCREV}"



linux-cubox-i_3.10.30.bb:
--

Re: [yocto] beaglebone black usb device problem (daisy)

[Bruce Ashfield]

On 2014-06-03, 6:06 AM, Daniel Groß wrote:

Hello there,
I have successfully build several beaglebone (qt4embedded demo and
sato+mono hard float) images using yocto 1.6 (daisy) for the beagle bone
black.

However USB devices (mouse, keyboard, anything) are only found during
the first boot.

I narrowed the problem down to the file "/etc/udev/cache.data". If I
remove this file and boot again (using the serial console), USB works
once for the next boot process.

After some try and error, I was able to restart the USB enumeration by
issuing a "udevadm trigger" command again using the serial console. That
always works. To me it seems that USB root hub is not loaded by udev if
the /etc/udev/cache.data file exists.

The output of the trigger command is:
root@beaglebone:~# udevadm trigger
udevadm trigger
47401300.usb-phy supply vcc not found, using dummy regulator
47401b00.usb-phy supply vcc not found, using dummy regulator
omap_rng 4831.rng: OMAP Random Number Generator ver. 20
root@beaglebone:~# musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usb 2-1: new low-speed USB device number 2 using musb-hdrc
input: Logitech USB Optical Mouse as
/devices/ocp.3/4740.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.0/0003:046D:C00C.0001/input/input0
hid-generic 0003:046D:C00C.0001: input: USB HID v1.10 Mouse [Logitech
USB Optical Mouse] on usb-musb-hdrc.1.auto-1/input0

The content of the /etc/udev/cache.data file is:
root@beaglebone:~# cat /etc/udev/cache.data
cat /etc/udev/cache.data
Linux version 3.14.0-yocto-standard (daniel@daniel-ubuntu) (gcc version
4.8.2 (GCC) ) #1 PREEMPT Sat May 24 16:40:23 CEST
2014console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4
rootwaitCharacter devices:1 mem2 pty3 ttyp4 /dev/vc/04 tty5 /dev/tty5
/dev/console5 /dev/ptmx7 vcs10 misc13 input29 fb89 i2c90 mtd128 ptm136
pts180 usb189 usb_device226 drm250 ttySDIO251 ttyO252 bsg253 watchdog254
rtcBlock devices:1 ramdisk259 blkext8 sd31 mtdblock65 sd66 sd67 sd68
sd69 sd70 sd71 sd128 sd129 sd130 sd131 sd132 sd133 sd134 sd135 sd179 mmc


For the sake of completeness:
root@beaglebone:~# uname -a
uname -a
Linux beaglebone 3.14.0-yocto-standard #1 PREEMPT Sat May 24 16:40:23
CEST 2014 armv7l GNU/Linux


Did anyone else see these problems? And is this a bug - or a feature?


I've never seen this myself. But it is worth logging this in the Yocto
bugzilla with a request for the QA team to confirm that they don't see
this during beaglebone testing.

Bruce




Daniel




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

Re: [yocto] Conditional Configuration Fragments

[Bruce Ashfield]

On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:

Hello,

I really don’t know whether this is feasible or not, but I’m trying to
build a yocto image (custom image) with conditional configuration fragments.

Today I have 2 image type: one for deployment purpose and another for
debug purpose. Debug images is only a superset of deployment image with
additional debug capabilities: nothing else.

However now I would like to add additional linux kernel features to this
debug image (ex: CONFIG_DEBUG_INFO=y).

I want to add this feature into debug image, but NOT in deployment image.

I was thinking to create a .bbappend to my linux .bb file, but again I
don’t see how to use .bbappend in a conditional way (based on image name
for instance)

Do you have any idea to perform such request ?


Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
the normal variable assignment rules.

So if you have something that you can test on (image/distro feature as
an example), you can use anonymous python and do a conditional
assignment.

Others on the list may have more elegant suggestions!

Bruce




Many thanks in advance

Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: logo_big5

Pierre-Yves MORDRET |TINA: 166 7286 |Tel: +33 244027286 | Mobile: +33
611091514

UPD | Middleware Integrator





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

Re: [yocto] Conditional Configuration Fragments

[Bruce Ashfield]

On 14-06-10 11:11 AM, Pierre Yves MORDRET wrote:

On Monday 09 June 2014 09:56:20 Paul Eggleton  
wrote:

On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:

On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:

Hello,

I really don't know whether this is feasible or not, but I'm trying to
build a yocto image (custom image) with conditional configuration
fragments.

Today I have 2 image type: one for deployment purpose and another for
debug purpose. Debug images is only a superset of deployment image with
additional debug capabilities: nothing else.

However now I would like to add additional linux kernel features to this
debug image (ex: CONFIG_DEBUG_INFO=y).

I want to add this feature into debug image, but NOT in deployment image.

I was thinking to create a .bbappend to my linux .bb file, but again I
don't see how to use .bbappend in a conditional way (based on image name
for instance)

Do you have any idea to perform such request ?


Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
the normal variable assignment rules.

So if you have something that you can test on (image/distro feature as
an example), you can use anonymous python and do a conditional
assignment.

Others on the list may have more elegant suggestions!


This can't work for what Pierre is asking for. You can't have a single recipe
built differently depending on what image is being built - our system does not
work that way. At a basic level, recipes create packages, and then the image
recipe selects which packages should go into the image.

Given that the kernel does not produce named packages in our system, I'm not
sure we currently have a way to build two different kernel recipes and select
one in one image and another in another image (which is the way we normally
handle this kind of requirement with other recipes.) Probably the only way to
do this is to have two completely separate build directories.


Many Thanks for your answers.
Thus I was thinking of making 2 separate linux.bb, one for deployment and the 
other for debug (i.e. linux-debug.bb) and update 
PREFERRED_PROVIDER_virtual/kernel accordingly.
But is there an automatic way to select proper .bb (linux.bb or linux-debug.bb) 
file like setting this variable(PREFERRED_PROVIDER_virtual/kernel) within the 
.bb image file ? Won't it work ?

Another option which is coming on top of my mind:
SRC_URI_append_ = " file://configuration_segment.cfg"
Is it something realistic and working ?


The image name would have to be an OVERRIDE value for variables.
Last I checked it wasn't, but perhaps Paul can straighten out that
point as well :)

Cheers,

Bruce



Please advise
Many thanks in advance



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

Re: [yocto] Linux Yocto style kernel errors with no config fragments

[Bruce Ashfield]

On 14-06-12 09:46 AM, Alex J Lennon wrote:

Hi,

I was taking a quick look at converting the meta-raspberrypi kernel
recipes to be linux-yocto style, to provide config frag support.

I'm working with poky master, referencing linux-yocto-custom.bb in
meta-skeleton

This seems to be working as far as it goes, but I get an error when
there are no configuration fragments supplied on the SRC_URI.

| DEBUG: Executing shell function do_kernel_configme
| [INFO] doing kernel configme
| [INFO] Configuring target/machine combo: "standard/raspberrypi"
| [INFO] collecting configs in ./.meta/meta-series
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| mv: cannot stat
`[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*':
No such file or directory
| creation of pre-processed config data failed
| config of "standard/raspberrypi" failed

When I add an empty file://dummy.cfg file to the SRC_URI then I can
build successfully.

When I add a dummy option CONFIG_DUMMY=y into that fragment file
do_kernel_configcheck correctly flags up that this is an unknown option
for the kernel so it seems to be pulled in ok.

Can anybody advise?


I have a fix for a similar issue in a patch queue that I'm going to
finish work on short (as part of 1.7 development work) .. the error
message that is generated in that scenario is certainly not much
help to anyone.

To see if this is the same issue, I'll ask a quick clarification
question.

From what you describe .. when you see the message, do you also
have a defconfig on the SRC_URI ?

Bruce



Thanks,

Alex



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

Re: [yocto] Linux Yocto style kernel errors with no config fragments

[Bruce Ashfield]

On 14-06-12 09:59 AM, Alex J Lennon wrote:


On 12/06/2014 14:53, Bruce Ashfield wrote:

On 14-06-12 09:46 AM, Alex J Lennon wrote:

Hi,

I was taking a quick look at converting the meta-raspberrypi kernel
recipes to be linux-yocto style, to provide config frag support.

I'm working with poky master, referencing linux-yocto-custom.bb in
meta-skeleton

This seems to be working as far as it goes, but I get an error when
there are no configuration fragments supplied on the SRC_URI.

| DEBUG: Executing shell function do_kernel_configme
| [INFO] doing kernel configme
| [INFO] Configuring target/machine combo: "standard/raspberrypi"
| [INFO] collecting configs in ./.meta/meta-series
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| mv: cannot stat
`[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*':

No such file or directory
| creation of pre-processed config data failed
| config of "standard/raspberrypi" failed

When I add an empty file://dummy.cfg file to the SRC_URI then I can
build successfully.

When I add a dummy option CONFIG_DUMMY=y into that fragment file
do_kernel_configcheck correctly flags up that this is an unknown option
for the kernel so it seems to be pulled in ok.

Can anybody advise?


I have a fix for a similar issue in a patch queue that I'm going to
finish work on short (as part of 1.7 development work) .. the error
message that is generated in that scenario is certainly not much
help to anyone.

To see if this is the same issue, I'll ask a quick clarification
question.

 From what you describe .. when you see the message, do you also
have a defconfig on the SRC_URI ?


Hi Bruce,

Currently I'm using -

SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \
file://sl030raspberrypii2ckernel.patch \
file://dummy.cfg \
   "

The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use
an existing config within the tree so I had left that alone thus far,
but I'm not sure it
is being pulled in so am looking at this now too,


Aha, so yes, that is likely the same thing that I was seeing before. If
you have no configuration at all, the tools don't have anything to seed
into the config_frag.txt file (and in earlier versions they didn't
touch the file to ensure it is present, or use the missing file as a
trigger for a more useful message).

Bruce



# NOTE: For now we pull in the default config from the RPi kernel GIT tree.
KERNEL_DEFCONFIG = "bcmrpi_defconfig"

Thanks,

Alex



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

Re: [yocto] Linux Yocto style kernel errors with no config fragments

[Bruce Ashfield]

On 14-06-12 10:52 AM, Alex J Lennon wrote:


On 12/06/2014 14:59, Alex J Lennon wrote:

On 12/06/2014 14:53, Bruce Ashfield wrote:

On 14-06-12 09:46 AM, Alex J Lennon wrote:

Hi,

I was taking a quick look at converting the meta-raspberrypi kernel
recipes to be linux-yocto style, to provide config frag support.

I'm working with poky master, referencing linux-yocto-custom.bb in
meta-skeleton

This seems to be working as far as it goes, but I get an error when
there are no configuration fragments supplied on the SRC_URI.

| DEBUG: Executing shell function do_kernel_configme
| [INFO] doing kernel configme
| [INFO] Configuring target/machine combo: "standard/raspberrypi"
| [INFO] collecting configs in ./.meta/meta-series
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or
directory
| mv: cannot stat
`[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*':

No such file or directory
| creation of pre-processed config data failed
| config of "standard/raspberrypi" failed

When I add an empty file://dummy.cfg file to the SRC_URI then I can
build successfully.

When I add a dummy option CONFIG_DUMMY=y into that fragment file
do_kernel_configcheck correctly flags up that this is an unknown option
for the kernel so it seems to be pulled in ok.

Can anybody advise?

I have a fix for a similar issue in a patch queue that I'm going to
finish work on short (as part of 1.7 development work) .. the error
message that is generated in that scenario is certainly not much
help to anyone.

To see if this is the same issue, I'll ask a quick clarification
question.

 From what you describe .. when you see the message, do you also
have a defconfig on the SRC_URI ?

Hi Bruce,

Currently I'm using -

SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \
file://sl030raspberrypii2ckernel.patch \
file://dummy.cfg \
   "

The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use
an existing config within the tree so I had left that alone thus far,
but I'm not sure it
is being pulled in so am looking at this now too,

# NOTE: For now we pull in the default config from the RPi kernel GIT tree.
KERNEL_DEFCONFIG = "bcmrpi_defconfig"



I think I see the problem now. A defconfig must be provided on SRC_URI
(or a fragment) or we see the failure.

I'll add in a SRC_URI defconfig instead of it reusing the in-tree config.


We crossed in the air. I just sent something similar, and I was going
to go dig into the details .. but you are already there.

Let me know if you have further issues, and I can also say that the error
message will be more informative in the future :)

Bruce



Cheers, Alex



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

Re: [yocto] Conditional patches on kernel depending on board, how to maintain?

[Bruce Ashfield]

On 14-06-12 07:54 AM, Daniel Hilst Selli wrote:

I have a SoM which will be used on several boards, this SoM has a base
kernel for it, with its board-*.c file. In each board I may have
different peripherals, so I have to patch the same board-*.c file
depending on my target board, and that patches may be conflicting one
each other. For example, I could have a RF on first SPI bus on one
board, and on another board a SD card on same first SPI bus.

So basically I will have a different kernel(uImage) and rootfs (with
kernel modules) for each board.

I think to create a layer for each target board, with the
linux-SoM.bbappend including the patches for that board..., so I enable
the layer depending on target board I'm creating, but is too much file
editions, or have a build directory for each target board, enabling the
right layer on each local.conf, but this means mantaining build
directories, or at last local.conf, which doesn't seem a good idea for
me...

Would be possible to do this relying only new layers and its
configurations?


As was mentioned in the other replies, you can always have a single
bbappend with board specific SRC_URI updates to add the patches you
need onto the base board support.

It's unfortunate that the patches conflict, since stacking hem in
board specific SRC_URIs can lead to patch failures in some configs
and not others .. if you change the baseline.

Typically in this situation, I either #ifdef the patches and use
a different configuration to conditionally build the consistent set
of changes, or maintain the changes in a git repository with board
specific patches on each branch. Again, that git approach avoids
patch failures during build.

Cheers,

Bruce



Thanks in advance
Cheers!


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

Re: [yocto] how many variations to build for a beaglebone black (BBB)?

[Bruce Ashfield]

On 14-07-07 09:13 AM, Robert P. J. Day wrote:


   i want to build a bootable system for a BBB, and i can see at least
three possibilities:

   1) the meta-yocto-bsp layer defines the beaglebone as one of its
  reference boards

   2) the "meta-ti" layer is advertised as "official" TI board support

   3) there is a "meta-beagleboard" layer, but that one looks a bit
  stagnant

any preferences out there for people working with the BBB?


The generic "it depends" answer applies here.

Due to the efforts of TI,the core BBB support made it into the mainline
kernel for 3.14, so that forms a common baseline of feature support.

Outside of that, it depends on the functionality you need in the image
and your familiarity with integration of multiple layers and features.

meta-ti gets you the latest and greatest features and support, while
the reference BSP was also done by TI to provide a good baseline level
of support (graphics, usb, ethernet, etc) and is supported via Wind River
in the linux-yocto repository.

Cheers,

Bruce



rday



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

Re: [yocto] How to select defconfig for kernel build with yocto/bitbake

[Bruce Ashfield]

On 14-07-09 05:38 AM, Dr. Markus Eich wrote:

Dear all,

I work on the process to compile odroid xu kernel with yocto/bitbake

In the kernel sources (from hardkernel) I have the corresponding
defconfig file, i.e. in the git folder
/arch/arm/configs/odroidxu_ubuntu_defconfig.

How can I tell bitbake in my recipe to use "odroidxu_ubuntu_defconfig"?


To trigger the oe-core kernel processing to use the defconfig, you need
to put that defconfig in your SRC_URI.

Which means you should grab a copy of that from the kernel tree, and
in the same directory structure as your kernel recipe.

See meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb for an
example.

Cheers,

Bruce




My recipe looks as follow:

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

KERNEL_IMAGETYPE = "uImage"

COMPATIBLE_MACHINE = "odroid-xu"

LINUX_VERSION = "3.4.91"
LINUX_VERSION_EXTENSION = "-custom"

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-hardkernel-3.4:"

S = "${WORKDIR}/git"

# from where to fetch the kernel
KERNEL_REPO_OWNER ??= "hardkernel"
KERNEL_REPO_URI ??= "git://github.com/${KERNEL_REPO_OWNER}/linux.git"
KBRANCH = "odroidxu-3.4.y"

SRCREV = "${AUTOREV}"

KV = "3.4.91"
PV = "${KV}+gitr${SRCPV}"
LOCALVERSION ?= ""


SRC_URI = " \
   ${KERNEL_REPO_URI};nocheckout=1;branch=${KBRANCH} \
"

PACKAGES =+ "kernel-headers"
FILES_kernel-headers = "${exec_prefix}/src/linux*"
===

Cheers,

Markus






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

Re: [yocto] How to select defconfig for kernel build with yocto/bitbake

[Bruce Ashfield]

On 14-07-10 07:11 AM, Dr. Markus Eich wrote:

Thank you Bruce, that did the trick. But I am facing a new problem while
using bitbake for the build process.

I have checked to build the odroid kernel with a standard crosscompiler
tool chain and it works without any problems.

When I do the same with the bitbake toolchain (bitbake virtual/kernel),
it somehow creates a recursive link in the folder

package/usr/src/kernel/drivers/gpu/arm/mali400/ump/arch/arch-release ->
arch-release

This causes a crash in the build system.

Compilation runs fine though. This error seems to be within do_package.
I have removed the link, but somehow it is created automatically.

Any ideas?


Nothing off the top of my head. That link would be created by the kernel
build, and not by bitbake or the oe-core kernel build classes.

I'd start by looking at the kernel's makefiles and seeing where the
link is being created.

Do specific tasks work ? i.e. is that happening during unpack/patch, or
during compilation.

Bruce



/Markus



On 09.07.2014 14:44, Bruce Ashfield wrote:

On 14-07-09 05:38 AM, Dr. Markus Eich wrote:

Dear all,

I work on the process to compile odroid xu kernel with yocto/bitbake

In the kernel sources (from hardkernel) I have the corresponding
defconfig file, i.e. in the git folder
/arch/arm/configs/odroidxu_ubuntu_defconfig.

How can I tell bitbake in my recipe to use "odroidxu_ubuntu_defconfig"?


To trigger the oe-core kernel processing to use the defconfig, you need
to put that defconfig in your SRC_URI.

Which means you should grab a copy of that from the kernel tree, and
in the same directory structure as your kernel recipe.

See meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb for an
example.

Cheers,

Bruce




My recipe looks as follow:

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

KERNEL_IMAGETYPE = "uImage"

COMPATIBLE_MACHINE = "odroid-xu"

LINUX_VERSION = "3.4.91"
LINUX_VERSION_EXTENSION = "-custom"

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-hardkernel-3.4:"

S = "${WORKDIR}/git"

# from where to fetch the kernel
KERNEL_REPO_OWNER ??= "hardkernel"
KERNEL_REPO_URI ??= "git://github.com/${KERNEL_REPO_OWNER}/linux.git"
KBRANCH = "odroidxu-3.4.y"

SRCREV = "${AUTOREV}"

KV = "3.4.91"
PV = "${KV}+gitr${SRCPV}"
LOCALVERSION ?= ""


SRC_URI = " \
   ${KERNEL_REPO_URI};nocheckout=1;branch=${KBRANCH} \
"

PACKAGES =+ "kernel-headers"
FILES_kernel-headers = "${exec_prefix}/src/linux*"
===

Cheers,

Markus










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