[yocto] Installing linux image with two separate flash partitions

[A]

I'm currently using petalinux to build a image.ub that works fine for me so
far (petalinux hides many things from me, but is bitbake under the hood).

However, this image will get stored into a flash device which I intend to
configure with three partitions
1) uboot
2) linux
3) an extra jffs2 with data and executables from my linux recipes

I currently build this third partition manually with mkfs.jffs2, after my
bitbake recipe has completed.
However, since the openembedded framework is pretty nifty and extensible,
I'd like to be able to have this in a recipe.

So far, I've thought to store the things for partition #3 in a STAGING_*
area, and create a new recipe that will DEPEND on those other recipes.  The
new recipe will do a mkfs.jffs2 command in its do_compile().  Then I would
find that jffs file in the build subdirectories somewhere, and assemble it
into the larger image for insertion into the flash device.

However, a) I'm not sure if this is the best way do do this, and b) I have
a "DEPEND" statement, but the "do_stage()" function of the dependency still
doesn't appear to have been invoked.

All advice welcome.

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

[yocto] if for SRCREV

[Mues, Pascal]

Hello,

on my recipe I would like to distinguish between release and other build.
The release shall just stay on a fixed "stable" version - where the other stuff 
shall just build latest greatest.
The easiest idea was have an environment variable set and check on recipe if 
this exist to switch the srcrev for Git.
As a pseudo code:

if env(Release)
   SRCREV = "613b64e3ba8e796e27e86560020d39d9dfd0407d"
else
   SRCREV = "autorev"

Unfortunately, I wasn't able to find anything how this could be done.
Someone can help?

BR
Pascal

 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 

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

Re: [yocto] if for SRCREV

[Burton, Ross]

A fairly standard way of doing this is to have an include file that
overrides SRCREV for the recipes that you'd like to build from HEAD.  See,
for example, the poky-bleeding.conf distro which includes
poky-floating-revisions.inc.

You could have an include file which does the same so you toggle
"development build" in once place (eg by including that file in local.conf)
and everything which needs to switch to HEAD does.

Ross
Ross

On Wed, 10 Oct 2018 at 09:51, Mues, Pascal  wrote:

> Hello,
>
>
>
> on my recipe I would like to distinguish between release and other build.
>
> The release shall just stay on a fixed “stable” version – where the other
> stuff shall just build latest greatest.
>
> The easiest idea was have an environment variable set and check on recipe
> if this exist to switch the srcrev for Git.
>
> As a pseudo code:
>
>
>
> if env(Release)
>
>SRCREV = "613b64e3ba8e796e27e86560020d39d9dfd0407d"
>
> else
>
>SRCREV = "autorev"
>
>
>
> Unfortunately, I wasn’t able to find anything how this could be done.
>
> Someone can help?
>
>
>
> BR
>
> Pascal
> 
> Note: If the reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by replying to
> the message and deleting it from your computer. Thank you.
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Steps to enable u-boot signed verified images?

[Irving ST]

Hello,

I'm trying to make u-boot perform signature verification of fitImages. I
have problems getting it to work, and the documentation seems to be
scattered in different places on the internet (I found plenty
descriptions of the concept, but I haven't seen detailed step-by-step
instructions on how to actually do it).

This is on an NXP i.MX7 Dual chip, using yocto 2.5, linux-fslc-imx 4.9,
and u-boot 2017.07 with vendor-specific patches to enable hardware
support and the like.

According to:
-
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/uboot-sign.bbclass
I set these variables in the machine config file :

UBOOT_SIGN_KEYDIR
UBOOT_SIGN_KEYNAME
UBOOT_MKIMAGE_DTCOPTS
UBOOT_SIGN_ENABLE
KERNEL_CLASSES
KERNEL_IMAGETYPE

According to:
-
https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/verified-boot.txt
- https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt
- https://github.com/u-boot/u-boot/blob/master/doc/README.fdt-control
I added the following configuration in u-boot defconfig:

CONFIG_SECURE_BOOT=y
CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_FIT_SIGNATURE=y
CONFIG_RSA=y
CONFIG_OF_CONTROL=y
CONFIG_OF_SEPARATE=y

This causes u-boot compilation failure, with the relevant line being:

| make[2]: *** No rule to make target 'arch/arm/dts/unset.dts', needed
by 'arch/arm/dts/unset.dtb'.  Stop.

If I added CONFIG_DEFAULT_DEVICE_TREE in u-boot defconfig, the
compilation failure goes away.
Am I correct that I need to provide the same device tree source to this
uboot config as the one I give to my kernel?
Or is there a way to not need to specify this config, considering the
only reason I enabled CONFIG_OF_CONTROL is because the current scheme in
yocto requires it?


Anyway, I tried setting this config to "imx7d-sdb" to see what happens,
and I got error from bitbake (relevant parts only):

| uboot-mkimage: Can't open
/workdir/build/upstream/tmp/deploy/images//u-boot.dtb:
No such file or directory
| uboot-mkimage Can't add hashes to FIT blob: -5
| WARNING: exit code 255 from a shell command.
| ERROR: Function failed: do_assemble_fitimage (log file is located
at
/workdir/build/upstream/tmp/work/-poky-linux-gnueabi/linux-fslc-imx/4.9-1.0.x+gitAUTOINC+953c6e30c9-r0/temp/log.do_assemble_fitimage.883)
ERROR: Task
(/workdir/upstream/meta-freescale/recipes-kernel/linux/linux-fslc-imx_4.9-1.0.x.bb:do_assemble_fitimage)
failed with exit code '1'


u-boot.dtb file is indeed not present on disk, so my next step is to
figure out why.
In the meantime, is there anything obvious that I am currently still
missing? I would be very happy if someone knows a good detailed guide to
implement this, since I have not found any.


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

[yocto] Sumo distro problem with dhcp packet?

[Zoran Stojsavljevic]

Hello.

I need on my test initramfs YOCTO image to add dhcp package (both dhcp
server and client).

For the beginning, I traced it, where it is:
.../poky/meta/recipes-connectivity/dchp

and decided to test it adding it to ...poky/build/conf/local.conf for the
starters:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp cmake... "

But it produced the following error:
[user@fedora28-ssd conf]$ bitbake -k core-image-base

   [snap]

ERROR: Nothing RPROVIDES 'dhcp' (but
/home/user/projects2/beaglebone-black/sumo/poky/meta/recipes-core/images/
core-image-base.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp']
ERROR: Nothing RPROVIDES 'core-image-base'
No eligible RPROVIDERs exist for 'core-image-base'
NOTE: Runtime target 'core-image-base' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-base']

I added another package, dhcpcd, which is located in the another layer:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcpcd cmake... "

so this one worked/was integrated seamlessly.

What is the catch 22 here?

Thank you,
Zoran
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OEDEM in Edinburgh in 2 weeks

[Philip Balister]

On 10/04/2018 08:20 AM, Philip Balister wrote:
> OEDEM is basically full at this time.
> 
> https://www.openembedded.org/wiki/OEDEM_2018
> 
> We have had the room rearranged to seat 45 people and I am not sure how
> we would handle anyone over this. If you know you can't make it, could
> you please remove your name from the attendee list. We'd like to get a
> better idea of how many people on the waiting list we can accommodate.
> There are some long time contributors on the wait list we'd like to get in.

OK, I've had the room arranged for 50 people. Everyone who is signed up
has a chair. Thanks for your interest in OpenEmbedded.

See you all soon!

Philip

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

Re: [yocto] Sumo distro problem with dhcp packet?

[Kosta Zertsekel]

You need to take a look at the available dhcp packages
for dhcp recipe here:
https://git.yoctoproject.org/clean/cgit.cgi/poky/tree/meta/recipes-connectivity/dhcp/dhcp.inc#n100

PACKAGES += "dhcp-libs dhcp-server dhcp-server-config dhcp-client dhcp-relay 
dhcp-omshell"

For example, you can do the below:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server cmake... "

Thanks,
--- Kosta Z

From: yocto-boun...@yoctoproject.org  on behalf 
of Zoran Stojsavljevic 
Sent: Wednesday, 10 October 2018 16:29:05
To: Yocto Project
Subject: [yocto] Sumo distro problem with dhcp packet?

Hello.

I need on my test initramfs YOCTO image to add dhcp package (both dhcp server 
and client).

For the beginning, I traced it, where it is:
.../poky/meta/recipes-connectivity/dchp

and decided to test it adding it to ...poky/build/conf/local.conf for the 
starters:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp cmake... "

But it produced the following error:
[user@fedora28-ssd conf]$ bitbake -k core-image-base

   [snap]

ERROR: Nothing RPROVIDES 'dhcp' (but 
/home/user/projects2/beaglebone-black/sumo/poky/meta/recipes-core/images/core-image-base.bb
 RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp']
ERROR: Nothing RPROVIDES 'core-image-base'
No eligible RPROVIDERs exist for 'core-image-base'
NOTE: Runtime target 'core-image-base' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-base']

I added another package, dhcpcd, which is located in the another layer:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcpcd cmake... "

so this one worked/was integrated seamlessly.

What is the catch 22 here?

Thank you,
Zoran

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

Re: [yocto] changing kernel config in Morty build

[Greg Wilson-Lindberg]

Hi Bruce,
Thanks for all of your help in looking into this. I did get another response 
that detailed using an out of tree defconfig. They didn't know if it would work 
with Morty, they are using it with Sumo. I'll have to try it with Morty.
Thanks again,
Greg Wilson-Lindberg  
Principal Firmware Engineer | Sakura Finetek USA, Inc.  

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, October 09, 2018 08:16 PM
> To: Greg Wilson-Lindberg ; yocto@yoctoproject.org
> Subject: Re: [yocto] changing kernel config in Morty build
> 
> On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:
> > Hi Bruce,
> > I've been able to reproduce the problem in a more minimal environment.
> >
> > To build a basic Yocto Raspberry Pi environment I based my build on the
> instructions found here:
> > https://themeaningfulengineer.github.io/exploring-yocto-with-raspberry
> > pi/
> >
> > The steps that I actually executed are:
> >
> > git clone -b morty --single-branch git://git.yoctoproject.org/poky cd
> > poky/ git clone -b morty
> > http://git.yoctoproject.org/git/meta-raspberrypi
> > source oe-init-build-env rpi-build
> >
> > In rpi-build/conf/local.conf I changed the MACHINE assignment to 
> > "raspberrypi2"
> from "qemu86"
> >
> > In rpi-build/conf/bblayers.conf I added "  
> > /home/gwilson/Qt/poky/meta-raspberrypi
> \" to pick up the raspberry layer.
> >
> > At this point I ran:
> > bitbake rpi-hwup-image
> >
> > to verify that the environment was correct. The build finished with only a 
> > couple of
> warnings about checksum problems and using alternate mirrors.
> >
> > I then copied in my kernel scripts and added in the directory to the 
> > bblayers file.
> >
> > When I rebuilt with these changes I get the same warnings/errors about 
> > changing
> the kernel config that I get with my full build environment.
> >
> > I've attached my meta-test directory with the kernel configuration 
> > .bbappend and
> .scc & .cfg files, and the final bblayers.conf & local.conf files.
> 
> Thanks for the layers and cut & paste instructions. They helped a lot.
> 
> .. even with that start, it took me a bit to figure things out.
> 
> In the end, I can't actually figure out how to get the fragment working with 
> the rpi
> kernel configuration routines as they stand in the morty timeframe.
> 
> in recipes-kernel/linux/linux-rpi.inc, there's a do_configure_prepend routine 
> who's
> first action is to clear ${B}/.config .. which is where the kernel-yocto 
> bbclass would
> have put the merged config + fragment.
> (The defconfig is also a placeholder defconfig, I could work around that, but 
> in the
> end, it doesn't matter since that routine zeros out anything that has merged).
> 
> So as I see it, you'll either need to carry your own defconfig, patch the 
> in-tree
> defconfig that is used, or write routines in your bbappend to modify the 
> configuration
> directly. I admit to not looking to see if the techniques to do this are 
> described
> anywhere, since I was just trying to sort out why the fragment wasn't being 
> properly
> applied.
> 
> Sorry I couldn't be of more help.
> 
> Cheers,
> 
> Bruce
> 
> >
> > Thank you for taking a look at this.
> >
> > Regards,
> >
> > Greg Wilson-Lindberg
> >
> >
> >
> > --
> > --
> > *From:* yocto-boun...@yoctoproject.org
> >  on behalf of Greg Wilson-Lindberg
> > 
> > *Sent:* Friday, October 5, 2018 9:23:52 AM
> > *To:* Bruce Ashfield; yocto@yoctoproject.org
> > *Subject:* Re: [yocto] changing kernel config in Morty build Hi Bruce,
> > I'll do my best to get something for you.
> > Thanks,
> >
> > Greg Wilson-Lindberg
> > Principal Firmware Engineer | Sakura Finetek USA, Inc.
> >
> > 1750 W 214th Street | Torrance, CA 90501 | U.S.A.
> > T: +1 310 783 5075
> > F: +1 310 618 6902 | E: gwil...@sakuraus.com www.sakuraus.com
> > 
> >
> >
> >
> >
> >
> > Confidentiality Notice: This e-mail transmission may contain
> > confidential or legally privileged information that is intended only
> > for the individual or entity named in the e-mail address. If you are
> > not the intended recipient, you are hereby notified that any
> > disclosure, copying, distribution, or reliance upon the contents of
> > this e-mail is strictly prohibited. If you have received this e-mail
> > transmission in error, please reply to the sender, so that Sakura
> > Finetek USA, Inc. can arrange for proper delivery, and then please
> > delete the message from your inbox. Thank you.
> >
> >
> >
> >> -Original Message-
> >> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> >> Sent: Friday, October 05, 2018 08:46 AM
> >> To: Greg Wilson-Lindberg ;
> >> yocto@yoctoproject.org
> >> Subject: Re: [yocto] changing kernel config in Morty build
> >>
> >> On 2018-10-04 4:38 PM, Greg Wilson-Lindberg wrote:
> >> > Does anybody else have any idea about what is going on here?
> >> >
> >>
>

[yocto] Fwd: preempt-rt for 4.14.71 fails to build

[Dimitris Tassopoulos]

Hi all!

I've tried to build the latest preempt-rt kernel from the
`v4.14/standard/preempt-rt/base`
and it fails to build. These are the hashes I've used:

```
LINUX_VERSION = "4.14.71"
SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
```

And the errors I get are:
```
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:
In function '__rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48:
error: passing argument 3 of 'rt_mutex_fastlock' from incompatible pointer
type [-Werror=incompatible-pointer-types]
  rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:
note: expected 'struct ww_acquire_ctx *' but argument is of type 'int
(*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum
rtmutex_chainwalk,  struct ww_acquire_ctx *)'
 rt_mutex_fastlock(struct rt_mutex *lock, int state,
 ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2:
error: too few arguments to function 'rt_mutex_fastlock'
  rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
  ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:
note: declared here
 rt_mutex_fastlock(struct rt_mutex *lock, int state,
 ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:
In function 'rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2:
error: too many arguments to function 'rt_mutex_lock_state'
  rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
  ^~~
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20:
note: declared here
 static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int state)
```

Is there any change that the latest rt44 patches are nor applied?

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

Re: [yocto] changing kernel config in Morty build

[Greg Wilson-Lindberg]

Hi Bruce,
I've got another question. I know that in a .bbappend I can specify functions 
to run during the build procedure, would it be possible to add in a function 
that would run after the do_configure_prepend() in the linux-rpi.inf file? If I 
could do that, then I could modify the config file that is produced by that 
...prepend() function.

Or the other option is to modify the linux-rpi.inc file itself.
Regards,

Greg Wilson-Lindberg  
Principal Firmware Engineer | Sakura Finetek USA, Inc.  
 

> -Original Message-
> From: Greg Wilson-Lindberg
> Sent: Wednesday, October 10, 2018 09:31 AM
> To: 'Bruce Ashfield' ; yocto@yoctoproject.org
> Subject: RE: [yocto] changing kernel config in Morty build
> 
> Hi Bruce,
> Thanks for all of your help in looking into this. I did get another response 
> that
> detailed using an out of tree defconfig. They didn't know if it would work 
> with Morty,
> they are using it with Sumo. I'll have to try it with Morty.
> Thanks again,
> Greg Wilson-Lindberg
> Principal Firmware Engineer | Sakura Finetek USA, Inc.
> 
> > -Original Message-
> > From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> > Sent: Tuesday, October 09, 2018 08:16 PM
> > To: Greg Wilson-Lindberg ;
> > yocto@yoctoproject.org
> > Subject: Re: [yocto] changing kernel config in Morty build
> >
> > On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:
> > > Hi Bruce,
> > > I've been able to reproduce the problem in a more minimal environment.
> > >
> > > To build a basic Yocto Raspberry Pi environment I based my build on
> > > the
> > instructions found here:
> > > https://themeaningfulengineer.github.io/exploring-yocto-with-raspber
> > > ry
> > > pi/
> > >
> > > The steps that I actually executed are:
> > >
> > > git clone -b morty --single-branch git://git.yoctoproject.org/poky
> > > cd poky/ git clone -b morty
> > > http://git.yoctoproject.org/git/meta-raspberrypi
> > > source oe-init-build-env rpi-build
> > >
> > > In rpi-build/conf/local.conf I changed the MACHINE assignment to
> "raspberrypi2"
> > from "qemu86"
> > >
> > > In rpi-build/conf/bblayers.conf I added "
> > > /home/gwilson/Qt/poky/meta-raspberrypi
> > \" to pick up the raspberry layer.
> > >
> > > At this point I ran:
> > > bitbake rpi-hwup-image
> > >
> > > to verify that the environment was correct. The build finished with
> > > only a couple of
> > warnings about checksum problems and using alternate mirrors.
> > >
> > > I then copied in my kernel scripts and added in the directory to the 
> > > bblayers file.
> > >
> > > When I rebuilt with these changes I get the same warnings/errors
> > > about changing
> > the kernel config that I get with my full build environment.
> > >
> > > I've attached my meta-test directory with the kernel configuration
> > > .bbappend and
> > .scc & .cfg files, and the final bblayers.conf & local.conf files.
> >
> > Thanks for the layers and cut & paste instructions. They helped a lot.
> >
> > .. even with that start, it took me a bit to figure things out.
> >
> > In the end, I can't actually figure out how to get the fragment
> > working with the rpi kernel configuration routines as they stand in the 
> > morty
> timeframe.
> >
> > in recipes-kernel/linux/linux-rpi.inc, there's a do_configure_prepend
> > routine who's first action is to clear ${B}/.config .. which is where
> > the kernel-yocto bbclass would have put the merged config + fragment.
> > (The defconfig is also a placeholder defconfig, I could work around
> > that, but in the end, it doesn't matter since that routine zeros out 
> > anything that has
> merged).
> >
> > So as I see it, you'll either need to carry your own defconfig, patch
> > the in-tree defconfig that is used, or write routines in your bbappend
> > to modify the configuration directly. I admit to not looking to see if
> > the techniques to do this are described anywhere, since I was just
> > trying to sort out why the fragment wasn't being properly applied.
> >
> > Sorry I couldn't be of more help.
> >
> > Cheers,
> >
> > Bruce
> >
> > >
> > > Thank you for taking a look at this.
> > >
> > > Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > > 
> > > --
> > > --
> > > *From:* yocto-boun...@yoctoproject.org
> > >  on behalf of Greg Wilson-Lindberg
> > > 
> > > *Sent:* Friday, October 5, 2018 9:23:52 AM
> > > *To:* Bruce Ashfield; yocto@yoctoproject.org
> > > *Subject:* Re: [yocto] changing kernel config in Morty build Hi
> > > Bruce, I'll do my best to get something for you.
> > > Thanks,
> > >
> > > Greg Wilson-Lindberg
> > > Principal Firmware Engineer | Sakura Finetek USA, Inc.
> > >
> > > 1750 W 214th Street | Torrance, CA 90501 | U.S.A.
> > > T: +1 310 783 5075
> > > F: +1 310 618 6902 | E: gwil...@sakuraus.com www.sakuraus.com
> > > 
> > >
> > >
> > >
> > >
> > >
> > > Confidentiality Notice: This e-mail transmission may contain
> > > confidential or le

Re: [yocto] changing kernel config in Morty build

[Bruce Ashfield]

On 2018-10-10 3:07 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've got another question. I know that in a .bbappend I can specify functions 
to run during the build procedure, would it be possible to add in a function 
that would run after the do_configure_prepend() in the linux-rpi.inf file? If I 
could do that, then I could modify the config file that is produced by that 
...prepend() function.


Yep. You can specify routines like that. You just need to get the
content and ordering right to do what you want.

Bruce



Or the other option is to modify the linux-rpi.inc file itself.
Regards,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.
  


-Original Message-
From: Greg Wilson-Lindberg
Sent: Wednesday, October 10, 2018 09:31 AM
To: 'Bruce Ashfield' ; yocto@yoctoproject.org
Subject: RE: [yocto] changing kernel config in Morty build

Hi Bruce,
Thanks for all of your help in looking into this. I did get another response 
that
detailed using an out of tree defconfig. They didn't know if it would work with 
Morty,
they are using it with Sumo. I'll have to try it with Morty.
Thanks again,
Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, October 09, 2018 08:16 PM
To: Greg Wilson-Lindberg ;
yocto@yoctoproject.org
Subject: Re: [yocto] changing kernel config in Morty build

On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've been able to reproduce the problem in a more minimal environment.

To build a basic Yocto Raspberry Pi environment I based my build on
the

instructions found here:

https://themeaningfulengineer.github.io/exploring-yocto-with-raspber
ry
pi/

The steps that I actually executed are:

git clone -b morty --single-branch git://git.yoctoproject.org/poky
cd poky/ git clone -b morty
http://git.yoctoproject.org/git/meta-raspberrypi
source oe-init-build-env rpi-build

In rpi-build/conf/local.conf I changed the MACHINE assignment to

"raspberrypi2"

from "qemu86"


In rpi-build/conf/bblayers.conf I added "
/home/gwilson/Qt/poky/meta-raspberrypi

\" to pick up the raspberry layer.


At this point I ran:
bitbake rpi-hwup-image

to verify that the environment was correct. The build finished with
only a couple of

warnings about checksum problems and using alternate mirrors.


I then copied in my kernel scripts and added in the directory to the bblayers 
file.

When I rebuilt with these changes I get the same warnings/errors
about changing

the kernel config that I get with my full build environment.


I've attached my meta-test directory with the kernel configuration
.bbappend and

.scc & .cfg files, and the final bblayers.conf & local.conf files.

Thanks for the layers and cut & paste instructions. They helped a lot.

.. even with that start, it took me a bit to figure things out.

In the end, I can't actually figure out how to get the fragment
working with the rpi kernel configuration routines as they stand in the morty

timeframe.


in recipes-kernel/linux/linux-rpi.inc, there's a do_configure_prepend
routine who's first action is to clear ${B}/.config .. which is where
the kernel-yocto bbclass would have put the merged config + fragment.
(The defconfig is also a placeholder defconfig, I could work around
that, but in the end, it doesn't matter since that routine zeros out anything 
that has

merged).


So as I see it, you'll either need to carry your own defconfig, patch
the in-tree defconfig that is used, or write routines in your bbappend
to modify the configuration directly. I admit to not looking to see if
the techniques to do this are described anywhere, since I was just
trying to sort out why the fragment wasn't being properly applied.

Sorry I couldn't be of more help.

Cheers,

Bruce



Thank you for taking a look at this.

Regards,

Greg Wilson-Lindberg




--
--
*From:* yocto-boun...@yoctoproject.org
 on behalf of Greg Wilson-Lindberg

*Sent:* Friday, October 5, 2018 9:23:52 AM
*To:* Bruce Ashfield; yocto@yoctoproject.org
*Subject:* Re: [yocto] changing kernel config in Morty build Hi
Bruce, I'll do my best to get something for you.
Thanks,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.

1750 W 214th Street | Torrance, CA 90501 | U.S.A.
T: +1 310 783 5075
F: +1 310 618 6902 | E: gwil...@sakuraus.com www.sakuraus.com






Confidentiality Notice: This e-mail transmission may contain
confidential or legally privileged information that is intended only
for the individual or entity named in the e-mail address. If you are
not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or reliance upon the contents of
this e-mail is strictly prohibited. If you have received this e-mail
transmission in error, please reply to the sender, so that Sakura
Finetek USA, In

Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build

[Bruce Ashfield]

On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote:

Hi all!

I've tried to build the latest preempt-rt kernel from the 
`v4.14/standard/preempt-rt/base`

and it fails to build. These are the hashes I've used:



This should go to the linux-yocto list, since that's where
people interested in the linux-yocto kernel variants will
notice it.

In this case, there was a bad merge. If you check the
preempt-rt branches of 4.14 there's a fix queued, but I
haven't sent SRCREV updates yet.

Bruce


```
LINUX_VERSION = "4.14.71"
SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
```

And the errors I get are:
```
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: 
In function '__rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48: 
error: passing argument 3 of 'rt_mutex_fastlock' from incompatible 
pointer type [-Werror=incompatible-pointer-types]

   rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
                                                 ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: 
note: expected 'struct ww_acquire_ctx *' but argument is of type 'int 
(*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum 
rtmutex_chainwalk,  struct ww_acquire_ctx *)'

  rt_mutex_fastlock(struct rt_mutex *lock, int state,
  ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2: 
error: too few arguments to function 'rt_mutex_fastlock'

   rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
   ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: 
note: declared here

  rt_mutex_fastlock(struct rt_mutex *lock, int state,
  ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: 
In function 'rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2: 
error: too many arguments to function 'rt_mutex_lock_state'

   rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
   ^~~
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20: 
note: declared here

  static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int state)
```

Is there any change that the latest rt44 patches are nor applied?

Thanks!
Dimitris




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

Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build

[Dimitris Tassopoulos]

I've already send this to that list a few days ago, but since I didn't got
any reply there I've also asked here in case that someone else shares the
same experience.

Dimitris

On Wed, 10 Oct 2018, 21:48 Bruce Ashfield, 
wrote:

> On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote:
> > Hi all!
> >
> > I've tried to build the latest preempt-rt kernel from the
> > `v4.14/standard/preempt-rt/base`
> > and it fails to build. These are the hashes I've used:
> >
>
> This should go to the linux-yocto list, since that's where
> people interested in the linux-yocto kernel variants will
> notice it.
>
> In this case, there was a bad merge. If you check the
> preempt-rt branches of 4.14 there's a fix queued, but I
> haven't sent SRCREV updates yet.
>
> Bruce
>
> > ```
> > LINUX_VERSION = "4.14.71"
> > SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
> > SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
> > ```
> >
> > And the errors I get are:
> > ```
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:
>
> > In function '__rt_mutex_lock':
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48:
>
> > error: passing argument 3 of 'rt_mutex_fastlock' from incompatible
> > pointer type [-Werror=incompatible-pointer-types]
> >rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
> >  ^
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:
>
> > note: expected 'struct ww_acquire_ctx *' but argument is of type 'int
> > (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum
> > rtmutex_chainwalk,  struct ww_acquire_ctx *)'
> >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
> >   ^
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2:
>
> > error: too few arguments to function 'rt_mutex_fastlock'
> >rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
> >^
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:
>
> > note: declared here
> >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
> >   ^
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:
>
> > In function 'rt_mutex_lock':
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2:
>
> > error: too many arguments to function 'rt_mutex_lock_state'
> >rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
> >^~~
> >
> /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20:
>
> > note: declared here
> >   static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int
> state)
> > ```
> >
> > Is there any change that the latest rt44 patches are nor applied?
> >
> > Thanks!
> > Dimitris
> >
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] failed to compile php_7.2.10.bb

[Simon Chamlian]

Hi,

I tried to bitbake php_7.2.10.bb and I am getting the following error.

Did anyone tried to compile php_7.2.10.bb ?

Any clue on what the issue can be ?

*$ bitbake php*
Loading cache: 100%
|###|
Time: 0:00:01
Loaded 3104 entries from dependency cache.
ERROR: ExpansionError during parsing
/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-oe/recipes-devtools/php/
php_7.2.10.bb
| ETA:  --:--:--
Traceback (most recent call last):
  File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass", line
375, in
__anon_656__opt_PHYTEC_BSPs_yocto_imx7_sources_poky_meta_classes_base_bbclass(d=):
 pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
>pn = d.getVar("PN", True)

  File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
noweakdefault=False, parsing=False):
 def getVar(self, var, expand, noweakdefault=False, parsing=False):
>return self.getVarFlag(var, "_content", expand, noweakdefault,
parsing)

  File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
expand=True, noweakdefault=False, parsing=False):
 cachename = var + "[" + flag + "]"
>value = self.expand(value, cachename)

  File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 410, in DataSmart.expand(s="mysql sqlite3 imap opcache
openssl${@bb.utils.filter('DISTRO_FEATURES', 'ipv6
pam', d)}  apache2 sqlite3 pgsql ", varname='PACKAGECONFIG'):
 def expand(self, s, varname = None):
>return self.expandWithRefs(s, varname).value

  File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 400, in DataSmart.expandWithRefs(s="mysql sqlite3 imap opcache
openssl${@bb.utils.filter('DISTRO_FEATURES', 'ipv6
pam', d)}  apache2 sqlite3 pgsql ", varname='PACKAGECONFIG'):
 except Exception as exc:
>raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
expression was mysql sqlite3 imap opcache openssl
${@bb.utils.filter('DISTRO_FEATURES', 'ipv6 pam', d)}  apache2 sqlite3
pgsql  which triggered exception AttributeError: module 'bb.utils' has no
attribute 'filter'


Summary: There was 1 ERROR message shown, returning a non-zero exit code.
*$*

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

Re: [yocto] failed to compile php_7.2.10.bb

[Martin Jansa]

On Wed, Oct 10, 2018 at 04:03:55PM -0400, Simon Chamlian wrote:
> Hi,
> 
> I tried to bitbake php_7.2.10.bb and I am getting the following error.
> 
> Did anyone tried to compile php_7.2.10.bb ?
> 
> Any clue on what the issue can be ?
> 
> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
> expression was mysql sqlite3 imap opcache openssl
> ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6 pam', d)}  apache2 sqlite3
> pgsql  which triggered exception AttributeError: module 'bb.utils' has no
> attribute 'filter'

You're missing different versions of oe-core and meta-oe, use both from
the same branch and it will work.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [prelink-cross] [PATCH] testsuite/functions.sh: produce deterministic GNU_PRELINK section

[Sergei Trofimovich]

Before the change one test failed due to timestamp drift:
  FAIL: shuffle7.sh

This happens because prelinking takes time on the file
and timestamp differs slightly.

Avoid timestamp drift by overriding real timestamp
with PRELINK_TIMESTAMP variable.

Signed-off-by: Sergei Trofimovich 
---
 testsuite/functions.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/testsuite/functions.sh b/testsuite/functions.sh
index 85bf875..5e98725 100755
--- a/testsuite/functions.sh
+++ b/testsuite/functions.sh
@@ -4,6 +4,12 @@ CCLINK=${CCLINK:-${CC} -Wl,--dynamic-linker=`echo 
./ld*.so.*[0-9]`}
 CXX="${CXX:-g++} ${LINKOPTS}"
 CXXLINK=${CXXLINK:-${CXX} -Wl,--dynamic-linker=`echo ./ld*.so.*[0-9]`}
 PRELINK=${PRELINK:-../src/prelink -c ./prelink.conf -C ./prelink.cache 
--ld-library-path=. --dynamic-linker=`echo ./ld*.so.*[0-9]`}
+
+# force deterministic timestamps to make double prelinking
+# to produce unmodified binary.
+PRELINK_TIMESTAMP=${PRELINK_TIMESTAMP:-12345678}
+export PRELINK_TIMESTAMP
+
 srcdir=${srcdir:-`dirname $0`}
 savelibs() {
   for i in $LIBS $BINS; do cp -p $i $i.orig; done
-- 
2.19.1

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

[yocto] [prelink-cross] [PATCH] x86_64: allow prelinking of PIE executables with COPY relocs

[Sergei Trofimovich]

COPY relocs are fine to have in PIE executables (as opposed to
shared libraries).

By enabling prelink on PIEs we achieve a few goals:
- prelink more PIE files on system: nicer for uniformity,
- avoid spurious warnings about shared libraries with COPY relocs

It's usefult to prelink PIEs when kernel ASLR is disabled:
kernel.randomize_va_space=0 + PIE-randomization patches.

I have gcc built as `--enable-default-pie` (generates PIE
executables by default).

Testsute results before the change:
  PASS:  14
  FAIL:  31

After the change:
  PASS:  32
  FAIL:  13

Signed-off-by: Sergei Trofimovich 
---
 src/arch-x86_64.c |  4 ++--
 src/dso.c | 19 +++
 src/prelink.h |  1 +
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/arch-x86_64.c b/src/arch-x86_64.c
index 5c95f47..2f6c551 100644
--- a/src/arch-x86_64.c
+++ b/src/arch-x86_64.c
@@ -179,7 +179,7 @@ x86_64_prelink_rela (struct prelink_info *info, GElf_Rela 
*rela,
value + rela->r_addend - info->resolvetls->offset);
   break;
 case R_X86_64_COPY:
-  if (dso->ehdr.e_type == ET_EXEC)
+  if (dso->ehdr.e_type == ET_EXEC || dso_is_pie(dso))
/* COPY relocs are handled specially in generic code.  */
return 0;
   error (0, 0, "%s: R_X86_64_COPY reloc in shared library?", 
dso->filename);
@@ -503,7 +503,7 @@ x86_64_undo_prelink_rela (DSO *dso, GElf_Rela *rela, 
GElf_Addr relaaddr)
   write_le32 (dso, rela->r_offset, 0);
   break;
 case R_X86_64_COPY:
-  if (dso->ehdr.e_type == ET_EXEC)
+  if (dso->ehdr.e_type == ET_EXEC || dso_is_pie(dso))
/* COPY relocs are handled specially in generic code.  */
return 0;
   error (0, 0, "%s: R_X86_64_COPY reloc in shared library?", 
dso->filename);
diff --git a/src/dso.c b/src/dso.c
index a5fcec5..9fcfc3d 100644
--- a/src/dso.c
+++ b/src/dso.c
@@ -1106,6 +1106,25 @@ dso_is_rdwr (DSO *dso)
   return dso->elfro != NULL;
 }
 
+/* Return true is DSO is position independent executable.
+
+   There is no simple way to distinct between shared library
+   and PIE executable.  Use presence of interpreter as a heuristic.  */
+
+int dso_is_pie(DSO *dso)
+{
+  int i;
+
+  if (dso->ehdr.e_type != ET_DYN)
+return 0;
+
+  for (i = 0; i < dso->ehdr.e_phnum; ++i)
+if (dso->phdr[i].p_type == PT_INTERP)
+  return 1;
+
+  return 0;
+}
+
 GElf_Addr
 adjust_old_to_new (DSO *dso, GElf_Addr addr)
 {
diff --git a/src/prelink.h b/src/prelink.h
index 93dbf7a..d8a00c6 100644
--- a/src/prelink.h
+++ b/src/prelink.h
@@ -298,6 +298,7 @@ int reopen_dso (DSO *dso, struct section_move *move, const 
char *);
 int adjust_symbol_p (DSO *dso, GElf_Sym *sym);
 int check_dso (DSO *dso);
 int dso_is_rdwr (DSO *dso);
+int dso_is_pie(DSO *dso);
 void read_dynamic (DSO *dso);
 int set_dynamic (DSO *dso, GElf_Word tag, GElf_Addr value, int fatal);
 int addr_to_sec (DSO *dso, GElf_Addr addr);
-- 
2.19.1

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

Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build

[Bruce Ashfield]

Check the list. It never came through. You need to be a subscriber
and would have received a bounce message.

I know that, since I got the bounce as the list admin :D

Bruce

On 2018-10-10 4:03 PM, Dimitris Tassopoulos wrote:
I've already send this to that list a few days ago, but since I didn't 
got any reply there I've also asked here in case that someone else 
shares the same experience.


Dimitris

On Wed, 10 Oct 2018, 21:48 Bruce Ashfield, > wrote:


On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote:
 > Hi all!
 >
 > I've tried to build the latest preempt-rt kernel from the
 > `v4.14/standard/preempt-rt/base`
 > and it fails to build. These are the hashes I've used:
 >

This should go to the linux-yocto list, since that's where
people interested in the linux-yocto kernel variants will
notice it.

In this case, there was a bad merge. If you check the
preempt-rt branches of 4.14 there's a fix queued, but I
haven't sent SRCREV updates yet.

Bruce

 > ```
 > LINUX_VERSION = "4.14.71"
 > SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
 > SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
 > ```
 >
 > And the errors I get are:
 > ```
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:

 > In function '__rt_mutex_lock':
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48:

 > error: passing argument 3 of 'rt_mutex_fastlock' from incompatible
 > pointer type [-Werror=incompatible-pointer-types]
 >    rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
 >                                                  ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:

 > note: expected 'struct ww_acquire_ctx *' but argument is of type
'int
 > (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum
 > rtmutex_chainwalk,  struct ww_acquire_ctx *)'
 >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
 >   ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2:

 > error: too few arguments to function 'rt_mutex_fastlock'
 >    rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
 >    ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:

 > note: declared here
 >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
 >   ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:

 > In function 'rt_mutex_lock':
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2:

 > error: too many arguments to function 'rt_mutex_lock_state'
 >    rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
 >    ^~~
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20:

 > note: declared here
 >   static int __sched rt_mutex_lock_state(struct rt_mutex *lock,
int state)
 > ```
 >
 > Is there any change that the latest rt44 patches are nor applied?
 >
 > Thanks!
 > Dimitris
 >
 >



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

[yocto] [prelink-cross][PATCH] src/arch-mips.c: check info->resolvetls before use its member

[Robert Yang]

The info->resolvetls might be NULL according to src/prelink.c:
[snip]
 /* Dynamic linker does not depend on any other library,
all symbols resolve to themselves with the exception
of SHN_UNDEF symbols which resolve to 0.  */
if (info->symtab[r_sym].st_shndx == SHN_UNDEF)
  {
info->resolveent = NULL;
info->resolvetls = NULL;
[snip]

So we must check it before use its members, otherwise, there might be
Segmentation fault error.

Fixed:
MACHINE = "qemumips"
IMAGE_INSTALL_append = " qemu"
$ bitbake core-image-minimal
[snip]
| 
/path/to/qemumips-poky-linux/core-image-minimal/1.0-r0/temp/run.prelink_image.1000:
 line 111:  1010 Segmentation fault  (core dumped) 
/path/to/qemumips-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/sbin/prelink
 --root /path/to/qemumips-poky-linux/core-image-minimal/1.0-r0/rootfs -amR -N 
-c /etc/prelink.conf --dynamic-linker $dynamic_loader
[snip]

Signed-off-by: Robert Yang 
---
 src/arch-mips.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/arch-mips.c b/src/arch-mips.c
index ccb1834..02c608f 100644
--- a/src/arch-mips.c
+++ b/src/arch-mips.c
@@ -567,7 +567,8 @@ mips_prelink_reloc (struct prelink_info *info, GElf_Addr 
r_offset,
   if (dso->ehdr.e_type == ET_EXEC)
{
  value = info->resolve (info, r_sym, r_type);
- value += info->resolvetls->offset - TLS_TP_OFFSET;
+ if (info->resolvetls != NULL)
+   value += info->resolvetls->offset - TLS_TP_OFFSET;
  if (r_type == R_MIPS_TLS_TPREL32)
mips_prelink_32bit_reloc (dso, rela, value);
  else
-- 
2.7.4

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