Re: [yocto] prelink-cross with -fno-plt

[Shane Peelar]

Great!  Would you be willing to accept a patch that makes arch-x86_64.c
handle that condition like the other arches?

-Shane

On Fri, May 24, 2019 at 12:27 PM Khem Raj  wrote:

>
>
> On 5/24/19 8:10 AM, Shane Peelar wrote:
> > I did some reading into the sources in other architectures.  The closest
> > match, arch_i386.c, makes the write conditional as you say.
> > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||
> > ||
> > ||
> > Notably, |||arch-cris.c||| has the same assert as
> > |||arch-x86_64.c||| instead of the conditional.
> >
> > The code roughly looks like follows:||
> > ||
> > |||
> > |||
> > 1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> > 3. Look for the section named ".plt" in the ELF.
> > 4. If the section cannot be found, return 0
> > 5. Otherwise, write the address of .plt + constant (dependent on arch)
> > to got[1]||
> > ||
> > |||
> > |||
> > In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an
> > assert:|||
> >
> > |||1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> > 3. Look for the section named ".plt" in the ELF.
> > 4. Assert that the section was found
> > 5. Write the address of .plt + constant (dependent on arch) to got[1]
> >
> > I tested out making the assert conditional and nothing seemed to break
> > at least.
> > |||
> > |||
>
> It seems ok to me.
>
> >
> > On Fri, May 24, 2019 at 12:08 AM Khem Raj  > > wrote:
> >
> >
> >
> > On 5/23/19 7:53 PM, Shane Peelar wrote:
> >  > Any of them on the system pretty much, and yes they are also
> > built with
> >  > -fno-plt.
> >
> > OK, I think its better to them conditionally check for .plt section,
> > can you describe more of whats going on when sections are checked.
> >
> >  >
> >  > On Thu, May 23, 2019 at 9:59 PM Khem Raj  > 
> >  > >> wrote:
> >  >
> >  >
> >  >
> >  > On 5/23/19 8:05 AM, Shane Peelar wrote:
> >  >  > Hi Everyone @ the Yocto project,
> >  >  >
> >  >  > I'm Shane Peelar, a PhD Candidate at the University of
> > Windsor.
> >  >  > I'm writing to you about prelink-cross, as part of the
> > Yocto project.
> >  >  > Specifically, I'm looking at using it with executables
> > built using
> >  >  > `-fno-plt` under GCC.
> >  >  > I wasn't quite sure where to send this email to, so I
> > figured I'd
> >  > try
> >  >  > here.  If there's a better place to send this, please let
> > me know.
> >  >  >
> >  >  > Right now, prelink-cross seems to fail an assertion in
> >  > arch-x86_64.c,
> >  >  > line 421, when
> >  >  > using it with an executable built with `-fno-plt`:
> >  >  >
> >  >  > ...
> >  >  > assert (i < dso->ehdr.e_shnum)
> >  >  > ...
> >  >  >
> >  >  > This snippet seems to be looking for the ".plt" section
> and,
> >  > since it
> >  >  > can't find it, the assertion fires.  This makes sense
> > because in
> >  >  > `-fno-plt` executables, the `.plt` section is missing
> > entirely.
> >  >  > I'm not an expert on ELF stuff, although I am learning
> > quickly.  It
> >  >  > looks like
> >  >  > this code wants to write into GOT[1] the address of ".plt"
> > + 0x16 --
> >  >  > since ".plt" doesn't
> >  >  > exist, does it make sense to just change this assert to an
> if
> >  > statement
> >  >  > like so:
> >  >  >
> >  >  > ...
> >  >  >if (i < dso->ehdr.e_shnum)
> >  >  >{ ... }
> >  >  > ...
> >  >  >
> >  >  > and skip over that part?  Or is this a real error
> > condition for
> >  >  > prelink-cross and it really should not continue?  The
> > executable in
> >  >  > question is also non-PIE, if that makes a difference.
> >  >  >
> >  >
> >  > what shared libs is this linking to ? are they also built with
> >  > -fno-plt ?
> >  >
> >  >  > Thanks for your time,
> >  >  > Shane
> >  >  >
> >  >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto is unstable to build final image when recipe has slash in SRCBRANCH

[Davis Roman]

Hello,

In my recipe, I've found that a forward slash in SRCBRANCH, results in an
error during the final image construction,

SRCBRANCH = "feature/compile_with_gcc7_4_rocko_toolchain"


Error given:

Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy
'tron-app'.

ERROR: tron-image-grip-1.0-r0 do_rootfs: Function failed: do_rootfs


Does anyone have a way to make the slash in the SRCBRANCH variable work?

Thank you,

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

Re: [yocto] problem adding a user

[Greg Wilson-Lindberg]

Hi Khem,

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Thursday, May 23, 2019 07:11 PM
> To: Rudolf Streif ; Greg Wilson-Lindberg
> 
> Cc: Yocto list discussion 
> Subject: Re: [yocto] problem adding a user
> 
> 
> 
> On 5/23/19 1:40 PM, Rudolf Streif wrote:
> > Greg,
> >
> > It eluded me earlier but in both instances the variable containing the
> > password does not seem to be expanded.
> >
> > First version without the single quotes:
> >
> > SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
> >
> > EXTRA_USERS_PARAMS = "\
> >      usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
> >      usermod -a -G sudo,dialout ${SAKURA_USER}; \
> >      "
> > results in:
> >
> > NOTE: scribe: Performing usermod with [-R
> > /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/wor
> > k/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs -p sakura]
> >
> > and with the quotes:
> >
> > SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
> >
> > EXTRA_USERS_PARAMS = "\
> >      usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
> >      usermod -a -G sudo,dialout ${SAKURA_USER}; \
> >      "
> > results in:
> > NOTE: scribe: Performing usermod with [-R
> > /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/wor
> > k/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs -p '' sakura]
> >
> > It looks as if the variable SAKURA_PASS is not set at all. I looked at
> > your scribe.bb  recipe you attached earlier but I
> > could not find any reason why the variable is not set. Is there a
> > chance that it is overridden somewhere elase?
> >
> 
> 
> This is correct with one small nit that we need to escape some characters 
> which has
> special meaning for shell. e.g. $
> 
> e.g. in local.conf something like below
> 
> INHERIT += "extrausers"
> 
> EXTRA_USERS_PARAMS += "\
>  useradd sakura; \
>  usermod -p '\$1\$QVO3K6Ii\$fvkoDKnlzz3d5uVoL7KcM0' sakura; \ "
> 
> might work as you expect.

This does leave the hash in the usermod command line finally.
So it is possible to pass MD5 hashes through if the '$' are escaped. I can't 
use non-alphabetic
characters, i.e replace 's' with '$', and 'a' with '@', I can't login with 
those changes. But MD5 hashes
of alphabetic only passwords work for the cases that I have tested. I can also 
pass the escaped
hash in to usermod as a macro.

It looks like I've got something that I can work with.

Thanks to all for the help that you have so kindly given,

Greg

> 
> > :rjs
> >
> >
> > On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg
> > mailto:gwil...@sakuraus.com>> wrote:
> >
> > Rudolf,
> >
> > Here is the first half of the file,  the whole file is over the 500k
> > limit of free pastebin:
> >
> > https://pastebin.com/UcnKebce
> >
> >
> > And here is the 2nd half of the file:
> >
> > https://pastebin.com/9117tdUU
> >
> >
> > Greg
> >
> > 
> > *From:* Rudolf Streif  > >
> > *Sent:* Wednesday, May 22, 2019 12:42:40 PM
> > *To:* Greg Wilson-Lindberg
> > *Cc:* Yocto list discussion
> > *Subject:* Re: [yocto] problem adding a user
> > Greg,
> > Can you share the logfile via Pastebin?
> > :rjs
> >
> > On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg
> > mailto:gwil...@sakuraus.com>> wrote:
> >
> > Rudolf,
> >
> > Something else is happening to me. I changed to this in the
> > image recipe:
> >
> > SAKURA_USER = "sakura"
> >
> > SAKURA_PASSWD = "Distracted"
> > SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
> >
> > EXTRA_USERS_PARAMS = "\
> >      usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
> >      usermod -a -G sudo,dialout ${SAKURA_USER}; \
> >      "
> >
> > deleting all of the commented out lines, and I get this in the
> > log file:
> >
> >
> > /scribe/1.0-r0/rootfs -p '' sakura]
> >
> >
> > nothing between the single quotes. It's acting like SAKURA_PASS
> > is not defined.
> >
> > This is only happening when I'm trying the MD5 password.
> >
> >
> > Greg
> >
> > 
> > 
> > *From:* Rudolf Streif  > >
> > *Sent:* Tuesday, May 21, 2019 5:37:23 AM
> > *To:* Greg Wilson-Lindberg
> > *Cc:* Yocto list discussion
> > *Subject:* Re: [yocto] problem adding a user
> > Greg,
> >
> > usermod does not work for the MD5 algorithm with the explicit
> > password hash as it contains the $ field delimiters which are
> > interpreted by the shell executing the usermod command. Use
> > single quotes around the password hash:
> >
> > usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
> >
> > :rjs
> >

Re: [yocto] Investigate virtual/kernel assignment

[Bruce Ashfield]

On Fri, May 24, 2019 at 12:27 PM Mauro Ziliani  wrote:
>
> Hi all.
>
> How can I ask to bitbake which is the actual value of virtual/kernel?
>


Here's one way:

bitbake -e virtual/kernel | grep PREFERRED_PROVIDER_virtual\/kernel
# $PREFERRED_PROVIDER_virtual/kernel [2 operations]
PREFERRED_PROVIDER_virtual/kernel="linux-yocto"

Bruce
>
>
> Thanks all
>
> MZ
>
> --
> ___
> 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
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/24/19 8:10 AM, Shane Peelar wrote:
I did some reading into the sources in other architectures.  The closest 
match, arch_i386.c, makes the write conditional as you say.
So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c, 
|arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||

||
||
Notably, |||arch-cris.c||| has the same assert as 
|||arch-x86_64.c||| instead of the conditional.


The code roughly looks like follows:||
||
|||
|||
1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. If the section cannot be found, return 0
5. Otherwise, write the address of .plt + constant (dependent on arch) 
to got[1]||

||
|||
|||
In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an 
assert:|||


|||1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. Assert that the section was found
5. Write the address of .plt + constant (dependent on arch) to got[1]

I tested out making the assert conditional and nothing seemed to break 
at least.

|||
|||


It seems ok to me.



On Fri, May 24, 2019 at 12:08 AM Khem Raj > wrote:




On 5/23/19 7:53 PM, Shane Peelar wrote:
 > Any of them on the system pretty much, and yes they are also
built with
 > -fno-plt.

OK, I think its better to them conditionally check for .plt section,
can you describe more of whats going on when sections are checked.

 >
 > On Thu, May 23, 2019 at 9:59 PM Khem Raj mailto:raj.k...@gmail.com>
 > >> wrote:
 >
 >
 >
 >     On 5/23/19 8:05 AM, Shane Peelar wrote:
 >      > Hi Everyone @ the Yocto project,
 >      >
 >      > I'm Shane Peelar, a PhD Candidate at the University of
Windsor.
 >      > I'm writing to you about prelink-cross, as part of the
Yocto project.
 >      > Specifically, I'm looking at using it with executables
built using
 >      > `-fno-plt` under GCC.
 >      > I wasn't quite sure where to send this email to, so I
figured I'd
 >     try
 >      > here.  If there's a better place to send this, please let
me know.
 >      >
 >      > Right now, prelink-cross seems to fail an assertion in
 >     arch-x86_64.c,
 >      > line 421, when
 >      > using it with an executable built with `-fno-plt`:
 >      >
 >      > ...
 >      > assert (i < dso->ehdr.e_shnum)
 >      > ...
 >      >
 >      > This snippet seems to be looking for the ".plt" section and,
 >     since it
 >      > can't find it, the assertion fires.  This makes sense
because in
 >      > `-fno-plt` executables, the `.plt` section is missing
entirely.
 >      > I'm not an expert on ELF stuff, although I am learning
quickly.  It
 >      > looks like
 >      > this code wants to write into GOT[1] the address of ".plt"
+ 0x16 --
 >      > since ".plt" doesn't
 >      > exist, does it make sense to just change this assert to an if
 >     statement
 >      > like so:
 >      >
 >      > ...
 >      >        if (i < dso->ehdr.e_shnum)
 >      >        { ... }
 >      > ...
 >      >
 >      > and skip over that part?  Or is this a real error
condition for
 >      > prelink-cross and it really should not continue?  The
executable in
 >      > question is also non-PIE, if that makes a difference.
 >      >
 >
 >     what shared libs is this linking to ? are they also built with
 >     -fno-plt ?
 >
 >      > Thanks for your time,
 >      > Shane
 >      >
 >


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

[yocto] Investigate virtual/kernel assignment

[Mauro Ziliani]

Hi all.

How can I ask to bitbake which is the actual value of virtual/kernel?


Thanks all

MZ

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

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

YUP! Thank you for the fix (I totally forgot about scripts directory).

Command: make scripts prepare solved it all!

Here is all captured (in order of execution):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/LKM/prepare_modules.log

These bugzillas will be still nice to have, Bruce, if possible (net
pointers to them).

I am acting as Scott Rifenbark, since I would like all of these
details to be rock-solid documented!

Thank you.
Zoran
___



On Fri, May 24, 2019 at 4:16 PM Bruce Ashfield  wrote:
>
>
>
> On Fri, May 24, 2019 at 8:50 AM Bruce Ashfield  
> wrote:
>>
>>
>>
>> On Fri, May 24, 2019 at 7:24 AM Zoran Stojsavljevic 
>>  wrote:
>>>
>>> As I said, I am a man of experimental try-outs. And here is the try!
>>>
>>> Now, after setting sources, I tried to compile the example (from my Git):
>>> https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues/LKM
>>>
>>> The results are the following (all on the target):
>>> root@beaglebone:~# pwd
>>> /home/root
>>> root@beaglebone:~# ls -al
>>> drwx--2 root root 0 May 24 13:11 .
>>> drwxr-xr-x3 root root 0 May 23 13:03 ..
>>> -rw-r--r--1 root root   159 May 24 12:54 Makefile
>>> -rw-r--r--1 root root  1228 May 24 12:54 p15_test.c
>>> root@beaglebone:~# make all
>>> make -C /lib/modules/5.0.15-jumpnow/build M=/home/root modules
>>> make[1]: Entering directory '/lib/modules/5.0.15-jumpnow/build'
>>>   CC [M]  /home/root/p15_test.o
>>> In file included from ./include/asm-generic/int-ll64.h:11,
>>>  from ./arch/arm/include/uapi/asm/types.h:5,
>>>  from ./include/uapi/linux/types.h:5,
>>>  from ./include/linux/types.h:6,
>>>  from ./include/linux/list.h:5,
>>>  from ./include/linux/module.h:9,
>>>  from /home/root/p15_test.c:5:
>>> ./include/uapi/asm-generic/int-ll64.h:12:10: fatal error: 
>>> asm/bitsperlong.h: No such file or directory
>>>  #include 
>>>   ^~~
>>> compilation terminated.
>>> make[2]: *** [scripts/Makefile.build:283: /home/root/p15_test.o] Error 1
>>> make[1]: *** [Makefile:1577: _module_/home/root] Error 2
>>> make[1]: Leaving directory '/lib/modules/5.0.15-jumpnow/build'
>>> make: *** [Makefile:4: all] Error 2
>>
>>
>> I'll try some test builds and see what I can find. Some new issues may have 
>> crept in.
>
>
> I can confirm that after wget'ing the files from your github, that I can 
> build the module just by using
> kernel-devsrc (on the core-image-kernel-dev image).
>
> I only had my qemux86-64 build handy, so I commented out the inline assembly 
> in the module to make sure it would build :D
>
> Outside of that, I only ran: 'make scripts prepare' in the kernel source dir 
> that dev-src installed to the image.
> root@qemux86-64:/tmp/f# make all
> make -C /lib/modules/5.0.17-yocto-standard/build M=/tmp/f modules
> make[1]: Entering directory '/lib/modules/5.0.17-yocto-standard/build'
>   CC [M]  /tmp/f/p15_test.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   CC  /tmp/f/p15_test.mod.o
>   LD [M]  /tmp/f/p15_test.ko
> make[1]: Leaving directory '/lib/modules/5.0.17-yocto-standard/build'
>
> Bruce
>
>
>>
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>>
>>>
>>> I see that you have changed the kernel from 5.0.7-jumpnow to 5.0.15-jumpnow 
>>> . Did you?
>>>
>>> This example works on the same target out of Debian (flashed in eMMC), 
>>> without the problems.
>>>
>>> Something is wrong with the YOCTO source kernel tree.
>>>
>>> You are free to try example on YOCTO and Embedded Debian yourselves!
>>>
>>> Zoran
>>> ___
>>>
>>> On Fri, May 24, 2019 at 6:37 AM Khem Raj  wrote:



 On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:
 >  > I think this is a fair suggestion. Having prebuilt kernel available
 >  > that contains the configuration and header files used in the build is
 >  > all that is required for external modules to build in addition to
 >  > toolchain, so maybe its worth a try to create such a package and then
 >  > have kernel-source separated out which can be installed on top if one
 >  > needs
 >
 > I am man of experimental try-outs. So, in order to see how big kernel is,
 > I did the following:
 > Fedora 29 (which I am using as a host) with kernel-headers (NOT full
 > kernel source tree):
 > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
 > /usr/src/kernels/5.0.16-200.fc29.x86_64
 > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
 > /*102124. <<=== ~95MB*/
 >
 > Kernel.org kernel 5.0.6, the full kernel source tree size:
 > [vuser@fedora29-ssd linux-5.0.6]$ pwd
 > /home/vuser/projects/kernel.org/linux-5.0.6 
 > 
 > [vuser@fedora29-ssd linux-5.0.6]$ du --summarize
 > /*960592. <<=== ~900MB*/
 >
 > These are ballpark numbers. You can draw 

Re: [yocto] prelink-cross with -fno-plt

[Shane Peelar]

I did some reading into the sources in other architectures.  The closest
match, arch_i386.c, makes the write conditional as you say.
So do other arches, including arch_arm.c, arch_sh.c, arch-mips.c, arch-s390.c,
arch-s390x.c, and arch-ia64.c.

Notably, arch-cris.c has the same assert as arch-x86_64.c instead of the
conditional.

The code roughly looks like follows:

1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. If the section cannot be found, return 0
5. Otherwise, write the address of .plt + constant (dependent on arch) to
got[1]

In arch-x86_64.c and arch-cris.c, step (4) above is an assert:

1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. Assert that the section was found
5. Write the address of .plt + constant (dependent on arch) to got[1]

I tested out making the assert conditional and nothing seemed to break at
least.


On Fri, May 24, 2019 at 12:08 AM Khem Raj  wrote:

>
>
> On 5/23/19 7:53 PM, Shane Peelar wrote:
> > Any of them on the system pretty much, and yes they are also built with
> > -fno-plt.
>
> OK, I think its better to them conditionally check for .plt section,
> can you describe more of whats going on when sections are checked.
>
> >
> > On Thu, May 23, 2019 at 9:59 PM Khem Raj  > > wrote:
> >
> >
> >
> > On 5/23/19 8:05 AM, Shane Peelar wrote:
> >  > Hi Everyone @ the Yocto project,
> >  >
> >  > I'm Shane Peelar, a PhD Candidate at the University of Windsor.
> >  > I'm writing to you about prelink-cross, as part of the Yocto
> project.
> >  > Specifically, I'm looking at using it with executables built using
> >  > `-fno-plt` under GCC.
> >  > I wasn't quite sure where to send this email to, so I figured I'd
> > try
> >  > here.  If there's a better place to send this, please let me know.
> >  >
> >  > Right now, prelink-cross seems to fail an assertion in
> > arch-x86_64.c,
> >  > line 421, when
> >  > using it with an executable built with `-fno-plt`:
> >  >
> >  > ...
> >  > assert (i < dso->ehdr.e_shnum)
> >  > ...
> >  >
> >  > This snippet seems to be looking for the ".plt" section and,
> > since it
> >  > can't find it, the assertion fires.  This makes sense because in
> >  > `-fno-plt` executables, the `.plt` section is missing entirely.
> >  > I'm not an expert on ELF stuff, although I am learning quickly.
> It
> >  > looks like
> >  > this code wants to write into GOT[1] the address of ".plt" + 0x16
> --
> >  > since ".plt" doesn't
> >  > exist, does it make sense to just change this assert to an if
> > statement
> >  > like so:
> >  >
> >  > ...
> >  >if (i < dso->ehdr.e_shnum)
> >  >{ ... }
> >  > ...
> >  >
> >  > and skip over that part?  Or is this a real error condition for
> >  > prelink-cross and it really should not continue?  The executable
> in
> >  > question is also non-PIE, if that makes a difference.
> >  >
> >
> > what shared libs is this linking to ? are they also built with
> > -fno-plt ?
> >
> >  > Thanks for your time,
> >  > Shane
> >  >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building single package as image, respecting dependencies

[Norman Stetter]

Is there no way to simply force bitbake to only build the packages I want, 
ignoring dependencies? We used to build the image like this before, using 
PTXDist.

Everything else seems to be a dirty hack.

Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH

21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
[cid:image001.jpg@01D5124D.B0588270]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

Von: Burton, Ross [mailto:ross.bur...@intel.com]
Gesendet: Friday, May 24, 2019 11:45 AM
An: Norman Stetter 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Building single package as image, respecting dependencies

On Fri, 24 May 2019 at 07:30, Norman Stetter 
mailto:norman.stet...@garz-fricke.com>> wrote:
For the OS image I use cpio.gz as file system. It gets booted as a RAMdisk. 
Sorry, forgot to mention that.

Would you consider switching to a proper filesystem?  The peril of using a 
cpio.gz is that every file you add slows the boot down: using a proper 
filesystem solves this.

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

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Bruce Ashfield]

On Fri, May 24, 2019 at 8:50 AM Bruce Ashfield 
wrote:

>
>
> On Fri, May 24, 2019 at 7:24 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> As I said, I am a man of experimental try-outs. And here is the try!
>>
>> Now, after setting sources, I tried to compile the example (from my Git):
>> https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues/LKM
>>
>> The results are the following (all on the target):
>> root@beaglebone:~# pwd
>> /home/root
>> root@beaglebone:~# ls -al
>> drwx--2 root root 0 May 24 13:11 .
>> drwxr-xr-x3 root root 0 May 23 13:03 ..
>> -rw-r--r--1 root root   159 May 24 12:54 Makefile
>> -rw-r--r--1 root root  1228 May 24 12:54 p15_test.c
>> root@beaglebone:~# make all
>> make -C /lib/modules/5.0.15-jumpnow/build M=/home/root modules
>> make[1]: Entering directory '/lib/modules/5.0.15-jumpnow/build'
>>   CC [M]  /home/root/p15_test.o
>> In file included from ./include/asm-generic/int-ll64.h:11,
>>  from ./arch/arm/include/uapi/asm/types.h:5,
>>  from ./include/uapi/linux/types.h:5,
>>  from ./include/linux/types.h:6,
>>  from ./include/linux/list.h:5,
>>  from ./include/linux/module.h:9,
>>  from /home/root/p15_test.c:5:
>> *./include/uapi/asm-generic/int-ll64.h:12:10: fatal error:
>> asm/bitsperlong.h: No such file or directory*
>>  #include 
>>   ^~~
>> compilation terminated.
>>
>>
>>
>> *make[2]: *** [scripts/Makefile.build:283: /home/root/p15_test.o] Error
>> 1make[1]: *** [Makefile:1577: _module_/home/root] Error 2make[1]: Leaving
>> directory '/lib/modules/5.0.15-jumpnow/build'make: *** [Makefile:4: all]
>> Error 2*
>>
>
> I'll try some test builds and see what I can find. Some new issues may
> have crept in.
>

I can confirm that after wget'ing the files from your github, that I can
build the module just by using
kernel-devsrc (on the core-image-kernel-dev image).

I only had my qemux86-64 build handy, so I commented out the inline
assembly in the module to make sure it would build :D

Outside of that, I only ran: 'make scripts prepare' in the kernel source
dir that dev-src installed to the image.
root@qemux86-64:/tmp/f# make all
make -C /lib/modules/5.0.17-yocto-standard/build M=/tmp/f modules
make[1]: Entering directory '/lib/modules/5.0.17-yocto-standard/build'
  CC [M]  /tmp/f/p15_test.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC  /tmp/f/p15_test.mod.o
  LD [M]  /tmp/f/p15_test.ko
make[1]: Leaving directory '/lib/modules/5.0.17-yocto-standard/build'

Bruce



>
> Cheers,
>
> Bruce
>
>
>
>>
>> I see that you have changed the kernel from 5.0.7-jumpnow to
>> 5.0.15-jumpnow . Did you?
>>
>> This example works on the same target out of Debian (flashed in eMMC),
>> without the problems.
>>
>> Something is wrong with the YOCTO source kernel tree.
>>
>> You are free to try example on YOCTO and Embedded Debian yourselves!
>>
>> Zoran
>> ___
>>
>> On Fri, May 24, 2019 at 6:37 AM Khem Raj  wrote:
>>
>>>
>>>
>>> On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:
>>> >  > I think this is a fair suggestion. Having prebuilt kernel available
>>> >  > that contains the configuration and header files used in the build
>>> is
>>> >  > all that is required for external modules to build in addition to
>>> >  > toolchain, so maybe its worth a try to create such a package and
>>> then
>>> >  > have kernel-source separated out which can be installed on top if
>>> one
>>> >  > needs
>>> >
>>> > I am man of experimental try-outs. So, in order to see how big kernel
>>> is,
>>> > I did the following:
>>> > Fedora 29 (which I am using as a host) with kernel-headers (NOT full
>>> > kernel source tree):
>>> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
>>> > /usr/src/kernels/5.0.16-200.fc29.x86_64
>>> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
>>> > /*102124. <<=== ~95MB*/
>>> >
>>> > Kernel.org kernel 5.0.6, the full kernel source tree size:
>>> > [vuser@fedora29-ssd linux-5.0.6]$ pwd
>>> > /home/vuser/projects/kernel.org/linux-5.0.6 <
>>> http://kernel.org/linux-5.0.6>
>>> > [vuser@fedora29-ssd linux-5.0.6]$ du --summarize
>>> > /*960592. <<=== ~900MB*/
>>> >
>>> > These are ballpark numbers. You can draw conclusions for yourselves!
>>> >
>>> > It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
>>> > and initramfs for testing purposes, in speaks for itself.
>>> >
>>>
>>> yes thats what I was expecting too. Anything smaller helps.
>>>
>>>
>>> > (I am aware that YOCTO kernels are less/smaller in size, but how
>>> smaller?)
>>> >
>>>
>>> Not in source. The binaries may be
>>>
>>> > Zoran
>>> > ___
>>> >
>>> >
>>> > On Fri, May 24, 2019 at 3:00 AM Khem Raj >> > > wrote:
>>> >
>>> >
>>> >
>>> > On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
>>> >  > After some tests (and I 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

> I'm going to create two new optional packages for the fall release
> that are simply captured kernel-source and kernel-headers for
> those uses cases where someone really does want the entire
> source tree, or just the headers. The details for that work are in
> bugzilla.

Could you, please, point to me which YOCTO bugzilla this is? I would
like to capture these in the
https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues,
just to have them as addition/addendum to all this what we have
discussed here?

Thank you,
Zoran

(PS. I'll continue some investigation as well)
___


On Fri, May 24, 2019 at 2:48 PM Bruce Ashfield  wrote:
>
>
>
> On Thu, May 23, 2019 at 9:00 PM Khem Raj  wrote:
>>
>>
>>
>> On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
>> > After some tests (and I had other problems to take care of, as well),
>> > here is the following:
>> >
>> >> These have all been discussed off an on over the past 5 years.
>> >> I can't get at bugzilla right now, but all the details are logged in 
>> >> cases.
>> >> A survey of all the distros, their kernel package, etc, were all looked 
>> >> at.
>> >> We had to balance the traditional packaging with some new concepts
>> >> and landed with what we have now.
>> >
>> > I tried several tests. This is my final conclusion (two cases):
>> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
>> >
>> > The kernel issue is described here: there is need to have the YOCTO
>> > minimum configuration with the kernel setup:
>> > [1] The entire kernel source code in:
>> > /usr/src/kernel/`uname-r`/
>> > [2] The header files in: /usr/src/kernel/`uname-r`/> > directory structures>
>> >
>> > Point [1] is achieved with the following local.config file:
>> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
>> >
>> > Namely, with the following snippets in the local.conf:
>> > TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
>> > packagegroup-core-buildessential kernel-devsrc"
>> > KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
>> > packagegroup-core-buildessential kernel-devsrc"
>> > KERNEL_DEV_MODULE = "kernel-modules"
>> > CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
>> > ${KERNEL_DEV_TOOLS} \
>> > systemtap \
>> > "
>> >
>> > Problem with this approach is that such a kernel makes the rootfs too
>> > big and impractical:
>> > -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
>> > core-image-minimal-beaglebone.rootfs.tar.xz
>> >
>> > The main issue is point [2]: how to achieve it?
>> > The suggestion is to introduce the new package in YOCTO kernel,
>> > called: kernel-headers
>> > The OBVIOUS benefit is that it will serve to the purpose of building
>> > modules out of the tree on the target with
>> > minimal mpact to rootfs!
>>
>> I think this is a fair suggestion. Having prebuilt kernel available
>> that contains the configuration and header files used in the build is
>> all that is required for external modules to build in addition to
>> toolchain, so maybe its worth a try to create such a package and then
>> have kernel-source separated out which can be installed on top if one
>> needs
>
>
> That's exactly what the kernel-devsrc package is. It is about 90 Megs 
> (unpacked) and is the headers + config required to build out of tree modules 
> against the kernel.
>
> I'm going to create two new optional packages for the fall release that are 
> simply captured kernel-source and kernel-headers for those uses cases where 
> someone really does want the entire source tree, or just the headers. The 
> details for that work are in bugzilla.
>
> Bruce
>
>
>>
>>
>> >
>> > Thank you,
>> > Zoran Stojsavljevic
>> > ___
>> >
>> > On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
>> >  wrote:
>> >>
>> >>
>> >>
>> >> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic 
>> >>  wrote:
>> >>>
>>  The core-image-kernel-dev image is how I do all my on target
>>  testing when I introduce a new reference kernel for a release.
>> >>>
>> >>> Maybe you are correct. Maybe I should use/add in my local.conf the 
>> >>> following:
>> >>>
>> >>> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
>> >>> packagegroup-core-buildessential kernel-devsrc"
>> >>> KERNEL_DEV_MODULE ?= "kernel-modules"
>> >>> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
>> >>>   ${KERNEL_DEV_TOOLS} \
>> >>>   systemtap \
>> >>>  "
>> >>> I need to try these... Maybe this addendum will solve the $1 mio USD 
>> >>> problem?!
>> >>>
>>  And IIRC the autobuilders are using a sato based image (Richard
>>  could confirm more easily that I could what image type the
>>  autobuilders are using for hello-world on target module tests).
>> >>>
>> >>> I am just advertising something more simple. To have mandatory
>> >>> /lib/modules/`uname -r` directory. And introduce few more packages, as
>> >>> Fedora distro, for 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Bruce Ashfield]

On Fri, May 24, 2019 at 7:24 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> As I said, I am a man of experimental try-outs. And here is the try!
>
> Now, after setting sources, I tried to compile the example (from my Git):
> https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues/LKM
>
> The results are the following (all on the target):
> root@beaglebone:~# pwd
> /home/root
> root@beaglebone:~# ls -al
> drwx--2 root root 0 May 24 13:11 .
> drwxr-xr-x3 root root 0 May 23 13:03 ..
> -rw-r--r--1 root root   159 May 24 12:54 Makefile
> -rw-r--r--1 root root  1228 May 24 12:54 p15_test.c
> root@beaglebone:~# make all
> make -C /lib/modules/5.0.15-jumpnow/build M=/home/root modules
> make[1]: Entering directory '/lib/modules/5.0.15-jumpnow/build'
>   CC [M]  /home/root/p15_test.o
> In file included from ./include/asm-generic/int-ll64.h:11,
>  from ./arch/arm/include/uapi/asm/types.h:5,
>  from ./include/uapi/linux/types.h:5,
>  from ./include/linux/types.h:6,
>  from ./include/linux/list.h:5,
>  from ./include/linux/module.h:9,
>  from /home/root/p15_test.c:5:
> *./include/uapi/asm-generic/int-ll64.h:12:10: fatal error:
> asm/bitsperlong.h: No such file or directory*
>  #include 
>   ^~~
> compilation terminated.
>
>
>
> *make[2]: *** [scripts/Makefile.build:283: /home/root/p15_test.o] Error
> 1make[1]: *** [Makefile:1577: _module_/home/root] Error 2make[1]: Leaving
> directory '/lib/modules/5.0.15-jumpnow/build'make: *** [Makefile:4: all]
> Error 2*
>

I'll try some test builds and see what I can find. Some new issues may have
crept in.

Cheers,

Bruce



>
> I see that you have changed the kernel from 5.0.7-jumpnow to
> 5.0.15-jumpnow . Did you?
>
> This example works on the same target out of Debian (flashed in eMMC),
> without the problems.
>
> Something is wrong with the YOCTO source kernel tree.
>
> You are free to try example on YOCTO and Embedded Debian yourselves!
>
> Zoran
> ___
>
> On Fri, May 24, 2019 at 6:37 AM Khem Raj  wrote:
>
>>
>>
>> On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:
>> >  > I think this is a fair suggestion. Having prebuilt kernel available
>> >  > that contains the configuration and header files used in the build is
>> >  > all that is required for external modules to build in addition to
>> >  > toolchain, so maybe its worth a try to create such a package and then
>> >  > have kernel-source separated out which can be installed on top if one
>> >  > needs
>> >
>> > I am man of experimental try-outs. So, in order to see how big kernel
>> is,
>> > I did the following:
>> > Fedora 29 (which I am using as a host) with kernel-headers (NOT full
>> > kernel source tree):
>> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
>> > /usr/src/kernels/5.0.16-200.fc29.x86_64
>> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
>> > /*102124. <<=== ~95MB*/
>> >
>> > Kernel.org kernel 5.0.6, the full kernel source tree size:
>> > [vuser@fedora29-ssd linux-5.0.6]$ pwd
>> > /home/vuser/projects/kernel.org/linux-5.0.6 <
>> http://kernel.org/linux-5.0.6>
>> > [vuser@fedora29-ssd linux-5.0.6]$ du --summarize
>> > /*960592. <<=== ~900MB*/
>> >
>> > These are ballpark numbers. You can draw conclusions for yourselves!
>> >
>> > It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
>> > and initramfs for testing purposes, in speaks for itself.
>> >
>>
>> yes thats what I was expecting too. Anything smaller helps.
>>
>>
>> > (I am aware that YOCTO kernels are less/smaller in size, but how
>> smaller?)
>> >
>>
>> Not in source. The binaries may be
>>
>> > Zoran
>> > ___
>> >
>> >
>> > On Fri, May 24, 2019 at 3:00 AM Khem Raj > > > wrote:
>> >
>> >
>> >
>> > On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
>> >  > After some tests (and I had other problems to take care of, as
>> well),
>> >  > here is the following:
>> >  >
>> >  >> These have all been discussed off an on over the past 5 years.
>> >  >> I can't get at bugzilla right now, but all the details are
>> > logged in cases.
>> >  >> A survey of all the distros, their kernel package, etc, were all
>> > looked at.
>> >  >> We had to balance the traditional packaging with some new
>> concepts
>> >  >> and landed with what we have now.
>> >  >
>> >  > I tried several tests. This is my final conclusion (two cases):
>> >  >
>> >
>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
>> >  >
>> >  > The kernel issue is described here: there is need to have the
>> YOCTO
>> >  > minimum configuration with the kernel setup:
>> >  > [1] The entire kernel source code in:
>> >  > /usr/src/kernel/`uname-r`/
>> >  > [2] The header files in: 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Bruce Ashfield]

On Thu, May 23, 2019 at 9:00 PM Khem Raj  wrote:

>
>
> On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
> > After some tests (and I had other problems to take care of, as well),
> > here is the following:
> >
> >> These have all been discussed off an on over the past 5 years.
> >> I can't get at bugzilla right now, but all the details are logged in
> cases.
> >> A survey of all the distros, their kernel package, etc, were all looked
> at.
> >> We had to balance the traditional packaging with some new concepts
> >> and landed with what we have now.
> >
> > I tried several tests. This is my final conclusion (two cases):
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
> >
> > The kernel issue is described here: there is need to have the YOCTO
> > minimum configuration with the kernel setup:
> > [1] The entire kernel source code in:
> > /usr/src/kernel/`uname-r`/
> > [2] The header files in: /usr/src/kernel/`uname-r`/ > directory structures>
> >
> > Point [1] is achieved with the following local.config file:
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
> >
> > Namely, with the following snippets in the local.conf:
> > TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
> > packagegroup-core-buildessential kernel-devsrc"
> > KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
> > packagegroup-core-buildessential kernel-devsrc"
> > KERNEL_DEV_MODULE = "kernel-modules"
> > CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> > ${KERNEL_DEV_TOOLS} \
> > systemtap \
> > "
> >
> > Problem with this approach is that such a kernel makes the rootfs too
> > big and impractical:
> > -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
> > core-image-minimal-beaglebone.rootfs.tar.xz
> >
> > The main issue is point [2]: how to achieve it?
> > The suggestion is to introduce the new package in YOCTO kernel,
> > called: kernel-headers
> > The OBVIOUS benefit is that it will serve to the purpose of building
> > modules out of the tree on the target with
> > minimal mpact to rootfs!
>
> I think this is a fair suggestion. Having prebuilt kernel available
> that contains the configuration and header files used in the build is
> all that is required for external modules to build in addition to
> toolchain, so maybe its worth a try to create such a package and then
> have kernel-source separated out which can be installed on top if one
> needs
>

That's exactly what the kernel-devsrc package is. It is about 90 Megs
(unpacked) and is the headers + config required to build out of tree
modules against the kernel.

I'm going to create two new optional packages for the fall release that are
simply captured kernel-source and kernel-headers for those uses cases where
someone really does want the entire source tree, or just the headers. The
details for that work are in bugzilla.

Bruce



>
> >
> > Thank you,
> > Zoran Stojsavljevic
> > ___
> >
> > On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
> >  wrote:
> >>
> >>
> >>
> >> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> >>>
>  The core-image-kernel-dev image is how I do all my on target
>  testing when I introduce a new reference kernel for a release.
> >>>
> >>> Maybe you are correct. Maybe I should use/add in my local.conf the
> following:
> >>>
> >>> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
> >>> packagegroup-core-buildessential kernel-devsrc"
> >>> KERNEL_DEV_MODULE ?= "kernel-modules"
> >>> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> >>>   ${KERNEL_DEV_TOOLS} \
> >>>   systemtap \
> >>>  "
> >>> I need to try these... Maybe this addendum will solve the $1 mio USD
> problem?!
> >>>
>  And IIRC the autobuilders are using a sato based image (Richard
>  could confirm more easily that I could what image type the
>  autobuilders are using for hello-world on target module tests).
> >>>
> >>> I am just advertising something more simple. To have mandatory
> >>> /lib/modules/`uname -r` directory. And introduce few more packages, as
> >>> Fedora distro, for example, has: kernel-headers (assuming YOCTO
> >>> rootfs, the following will be installed: /usr/src/kernel/`uname
> >>> -r`/. This also makes addition of
> >>> /lib/modules/`uname -r`/build file (which is soft link to
> >>> usr/src/kernel/`uname -r`).
> >>
> >>
> >> These have all been discussed off an on over the past 5 years. I can't
> get at bugzilla right now, but all the details are logged in cases. A
> survey of all the distros, their kernel package, etc, were all looked at.
> We had to balance the traditional packaging with some new concepts and
> landed with what we have now.
> >>
> >>
> >>>
> >>> Or kernel-devel package. Then, the whole current kernel source code
> >>> will be introduced, and also support for it.
> >>
> >>
> >> There's a case for 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

As I said, I am a man of experimental try-outs. And here is the try!

Now, after setting sources, I tried to compile the example (from my Git):
https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues/LKM

The results are the following (all on the target):
root@beaglebone:~# pwd
/home/root
root@beaglebone:~# ls -al
drwx--2 root root 0 May 24 13:11 .
drwxr-xr-x3 root root 0 May 23 13:03 ..
-rw-r--r--1 root root   159 May 24 12:54 Makefile
-rw-r--r--1 root root  1228 May 24 12:54 p15_test.c
root@beaglebone:~# make all
make -C /lib/modules/5.0.15-jumpnow/build M=/home/root modules
make[1]: Entering directory '/lib/modules/5.0.15-jumpnow/build'
  CC [M]  /home/root/p15_test.o
In file included from ./include/asm-generic/int-ll64.h:11,
 from ./arch/arm/include/uapi/asm/types.h:5,
 from ./include/uapi/linux/types.h:5,
 from ./include/linux/types.h:6,
 from ./include/linux/list.h:5,
 from ./include/linux/module.h:9,
 from /home/root/p15_test.c:5:
*./include/uapi/asm-generic/int-ll64.h:12:10: fatal error:
asm/bitsperlong.h: No such file or directory*
 #include 
  ^~~
compilation terminated.



*make[2]: *** [scripts/Makefile.build:283: /home/root/p15_test.o] Error
1make[1]: *** [Makefile:1577: _module_/home/root] Error 2make[1]: Leaving
directory '/lib/modules/5.0.15-jumpnow/build'make: *** [Makefile:4: all]
Error 2*

I see that you have changed the kernel from 5.0.7-jumpnow to 5.0.15-jumpnow
. Did you?

This example works on the same target out of Debian (flashed in eMMC),
without the problems.

Something is wrong with the YOCTO source kernel tree.

You are free to try example on YOCTO and Embedded Debian yourselves!

Zoran
___

On Fri, May 24, 2019 at 6:37 AM Khem Raj  wrote:

>
>
> On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:
> >  > I think this is a fair suggestion. Having prebuilt kernel available
> >  > that contains the configuration and header files used in the build is
> >  > all that is required for external modules to build in addition to
> >  > toolchain, so maybe its worth a try to create such a package and then
> >  > have kernel-source separated out which can be installed on top if one
> >  > needs
> >
> > I am man of experimental try-outs. So, in order to see how big kernel is,
> > I did the following:
> > Fedora 29 (which I am using as a host) with kernel-headers (NOT full
> > kernel source tree):
> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
> > /usr/src/kernels/5.0.16-200.fc29.x86_64
> > [vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
> > /*102124. <<=== ~95MB*/
> >
> > Kernel.org kernel 5.0.6, the full kernel source tree size:
> > [vuser@fedora29-ssd linux-5.0.6]$ pwd
> > /home/vuser/projects/kernel.org/linux-5.0.6 <
> http://kernel.org/linux-5.0.6>
> > [vuser@fedora29-ssd linux-5.0.6]$ du --summarize
> > /*960592. <<=== ~900MB*/
> >
> > These are ballpark numbers. You can draw conclusions for yourselves!
> >
> > It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
> > and initramfs for testing purposes, in speaks for itself.
> >
>
> yes thats what I was expecting too. Anything smaller helps.
>
>
> > (I am aware that YOCTO kernels are less/smaller in size, but how
> smaller?)
> >
>
> Not in source. The binaries may be
>
> > Zoran
> > ___
> >
> >
> > On Fri, May 24, 2019 at 3:00 AM Khem Raj  > > wrote:
> >
> >
> >
> > On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
> >  > After some tests (and I had other problems to take care of, as
> well),
> >  > here is the following:
> >  >
> >  >> These have all been discussed off an on over the past 5 years.
> >  >> I can't get at bugzilla right now, but all the details are
> > logged in cases.
> >  >> A survey of all the distros, their kernel package, etc, were all
> > looked at.
> >  >> We had to balance the traditional packaging with some new
> concepts
> >  >> and landed with what we have now.
> >  >
> >  > I tried several tests. This is my final conclusion (two cases):
> >  >
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
> >  >
> >  > The kernel issue is described here: there is need to have the
> YOCTO
> >  > minimum configuration with the kernel setup:
> >  > [1] The entire kernel source code in:
> >  > /usr/src/kernel/`uname-r`/
> >  > [2] The header files in: /usr/src/kernel/`uname-r`/ >  > directory structures>
> >  >
> >  > Point [1] is achieved with the following local.config file:
> >  >
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
> >  >
> >  > Namely, with the following snippets in the local.conf:
> >  > TOOLCHAIN_TARGET_TASK_append = " 

Re: [yocto] Building single package as image, respecting dependencies

[Norman Stetter]

In fact the OS is just a minimal rescue OS. On a second partition we run our 
main OS, which is ‘properly’ installed.
So, I’m afraid using a ‘proper’ file system wouldn’t fit our use case. We run 
the rescue OS as RAMdisk to be able to self-update it without having to worry 
about modifying a mounted file system.

Norman



Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH

21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
[cid:image001.jpg@01D51228.BD16AF70]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

Von: Burton, Ross [mailto:ross.bur...@intel.com]
Gesendet: Friday, May 24, 2019 11:45 AM
An: Norman Stetter 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Building single package as image, respecting dependencies

On Fri, 24 May 2019 at 07:30, Norman Stetter 
mailto:norman.stet...@garz-fricke.com>> wrote:
For the OS image I use cpio.gz as file system. It gets booted as a RAMdisk. 
Sorry, forgot to mention that.

Would you consider switching to a proper filesystem?  The peril of using a 
cpio.gz is that every file you add slows the boot down: using a proper 
filesystem solves this.

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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Tg, Harish]

Hi Paul,
   I understood what you are trying to say but from where does the 
Yocto pick up the contents for a directory in final rootfs image. Is there any 
recipe file in which I can find this. For example: do_install() etc.
I also came to know from you that I need a recipe for adding a file into rootfs 
image. That's well understood. Please clarify about the particular recipe file 
where the contents are copied from source to the rootfs image.

Thank you for writing to me.

Regards,
Harish.

-Original Message-
From: Paul Barker [mailto:p...@betafive.co.uk] 
Sent: Friday, May 24, 2019 3:26 PM
To: Tg, Harish ; Yocto discussion list 

Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

On Fri, 24 May 2019, at 10:14, Tg, Harish wrote:
> Kindly help me out in locating the source for /usr/bin of rootfs image 
> in yocto. I did a find but I do not see the /usr/bin and its exact 
> contents as in the rootfs image. I need to locate this badly as this 
> would help in adding the commands to the folder which would be finally 
> added to the rootfs image. Your help is highly appreciated. Thanks in 
> advance.
> 

In a Yocto Project build, the rootfs is built from packages and the packages 
are in turn built from recipes. The supported process for adding new software 
to the image is to write a recipe which creates a new package, then add the 
package to IMAGE_INSTALL for an image.

There isn't a location where you can just drop files for them to be included in 
a rootfs build.

I'd recommend you search online for a tutorial on this, there's plenty of good 
resources available.

--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Paul Barker]

On Fri, 24 May 2019, at 11:02, Tg, Harish wrote:
> Hi Paul,
>I understood what you are trying to say but from where 
> does the Yocto pick up the contents for a directory in final rootfs 
> image. Is there any recipe file in which I can find this. For example: 
> do_install() etc.
> I also came to know from you that I need a recipe for adding a file 
> into rootfs image. That's well understood. Please clarify about the 
> particular recipe file where the contents are copied from source to the 
> rootfs image.
> 
> Thank you for writing to me.

This is all covered in the documentation, online tutorials and several 
excellent books. I'd recommend you set aside some time for learning here as it 
sounds like you're not familiar with the basic concepts used in Yocto Project.

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Paul Barker]

On Fri, 24 May 2019, at 10:14, Tg, Harish wrote:
> Kindly help me out in locating the source for /usr/bin of rootfs image 
> in yocto. I did a find but I do not see the /usr/bin and its exact 
> contents as in the rootfs image. I need to locate this badly as this 
> would help in adding the commands to the folder which would be finally 
> added to the rootfs image. Your help is highly appreciated. Thanks in 
> advance.
> 

In a Yocto Project build, the rootfs is built from packages and the packages 
are in turn built from recipes. The supported process for adding new software 
to the image is to write a recipe which creates a new package, then add the 
package to IMAGE_INSTALL for an image.

There isn't a location where you can just drop files for them to be included in 
a rootfs build.

I'd recommend you search online for a tutorial on this, there's plenty of good 
resources available.

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building single package as image, respecting dependencies

[Burton, Ross]

On Fri, 24 May 2019 at 07:30, Norman Stetter 
wrote:

> For the OS image I use cpio.gz as file system. It gets booted as a
> RAMdisk. Sorry, forgot to mention that.
>

Would you consider switching to a proper filesystem?  The peril of using a
cpio.gz is that every file you add slows the boot down: using a proper
filesystem solves this.

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

Re: [yocto] Finding recipe for ATOM N450

[Burton, Ross]

The meta-intel BSP is the recommend BSP for all Intel platfoms.

Ross

On Fri, 24 May 2019 at 10:30, Ranran  wrote:
>
> Hello,
>
> I searched for ATOM N450 recipe, but only found very old one:
> https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc
> The problem is that we need newer gcc (above 4.8.2).
>
> Should it be better to just use generic x86 recipe ?
> https://old.yoctoproject.org/downloads/bsps/rocko24/generic-x86
>
> Thank you,
> ranran
> --
> ___
> 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] Finding recipe for ATOM N450

[Ranran]

Hello,

I searched for ATOM N450 recipe, but only found very old one:
https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc
The problem is that we need newer gcc (above 4.8.2).

Should it be better to just use generic x86 recipe ?
https://old.yoctoproject.org/downloads/bsps/rocko24/generic-x86

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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Tg, Harish]

Kindly help me out in locating the source for /usr/bin of rootfs image in 
yocto. I did a find but I do not see the /usr/bin and its exact contents as in 
the rootfs image. I need to locate this badly as this would help in adding the 
commands to the folder which would be finally added to the rootfs image. Your 
help is highly appreciated. Thanks in advance.

Harish.

-Original Message-
From: Tg, Harish 
Sent: Friday, May 24, 2019 12:05 PM
To: yocto@yoctoproject.org
Subject: FW: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

Mailing it to the thread.

-Original Message-
From: Tg, Harish
Sent: Friday, May 24, 2019 11:17 AM
To: Khem Raj ; yocto@yoctoproject.org
Subject: RE: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

Hi Raj,
What I am asking you is that how the yocto picks up components for 
/usr/bin folder of rootfs. Where do they exist before copying? I am sorry but I 
feel I do not need to write a recipe for adding just one of the commands. It is 
just that I need to add "ubiattach" to target /usr/bin of rootfs. That’s why I 
am asking where do I place my "ubiattach" command and there should also be a 
folder for this. Please clarify.

Thanks,
Harish.
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, May 24, 2019 11:03 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

Please keep the thread on list and avoid pm.

as I said you need

1. Write a recipe for your package
2. in do_install of the recipe you want to mention where it should be placed 
e.g.

install -D -m 0755  ${D}${bindir}/

would put it in /usr/bin on target when this package is included in image

3. Include the package in image via IMAGE_INSTALL



On 5/23/19 10:13 PM, Tg, Harish wrote:
> Hi Raj,
>  Another question I have is where do I place my custom 
> "ubiattach" command. Also I am not sure from where does the yocto builds the 
> rootfs /usr/bin components. Where do they copied from?
> 
> Thanks,
> Harish.
> 
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, May 24, 2019 7:07 AM
> To: Tg, Harish ; yocto@yoctoproject.org
> Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95
> 
> 
> 
> On 5/23/19 5:59 AM, Tg, Harish wrote:
>> Hi,
>>I have a question. How to add commands like "ubiattach" to /usr/bin 
>> of rootfs image. I struggling with the recipes. I do not want to write my 
>> own recipe but I need to edit some recipe and add the command. Which is the 
>> place? I am using yocto for my project on TI platform and Linux.
>> Kindly help.
>>
> 
> There is oe-pkgdata-util which can help to map files to recipes but we 
> do not have a database for mapping. Maybe it is a good thing to have
> 
> for your problem ubiattach is provided by mtd-utils-ubifs which is 
> built from mtd-utils recipe. I found it via above tool
> 
> % oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
> mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils
> 
> % oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils
> 
> So you need to add
> 
> IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or 
> local.conf
>>
>> Thanks,
>> Harish.
>>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of 
>> yocto-requ...@yoctoproject.org
>> Sent: Wednesday, May 22, 2019 6:57 PM
>> To: yocto@yoctoproject.org
>> Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95
>>
>> Send yocto mailing list submissions to
>>  yocto@yoctoproject.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproje
>> c
>> t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYA
>> f
>> VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5Y
>> Y Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
>> 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. GPLv3 package present in rootfs (virendra kumar thakur)
>>  2. Building single package as image, respecting dependencies
>> (Norman Stetter)
>>
>>
>> -
>> -
>>
>> Message: 1
>> Date: Wed, 22 May 2019 18:55:45 +0530
>> From: virendra kumar thakur 
>> To: yocto@yoctoproject.org
>> Subject: [yocto] GPLv3 package present in rootfs
>> Message-ID:
>>  
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello team,
>>
>> I want to remove some GPLv3 package from rootfs, but it is still present.
>>
>> I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"
>>
>> still some package gnutls, 

Re: [yocto] /usr/share/common-license package/recipeinfo contains GPLv3 info

[virendra kumar thakur]

Ok, thanks.

On Fri 24 May, 2019, 2:12 PM Burton, Ross,  wrote:

> On Thu, 23 May 2019 at 10:43, virendra kumar thakur
>  wrote:
> > But I can see in
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
> >
> > LICENSE: GPLV2+ + +
> > PR: r0
> > PV : 1.8.4
>
> At a guess, because the libgcrypt recipe is:
>
> LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
>
> Whereas libgcrypt itself is:
>
> LICENSE_${PN} = "LGPLv2.1+"
>
> That's a bit of a meta-question: what license is a license package
> that only contains license texts?
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] /usr/share/common-license package/recipeinfo contains GPLv3 info

[Burton, Ross]

On Thu, 23 May 2019 at 10:43, virendra kumar thakur
 wrote:
> But I can see in 
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
>
> LICENSE: GPLV2+ + +
> PR: r0
> PV : 1.8.4

At a guess, because the libgcrypt recipe is:

LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"

Whereas libgcrypt itself is:

LICENSE_${PN} = "LGPLv2.1+"

That's a bit of a meta-question: what license is a license package
that only contains license texts?

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

Re: [yocto] Fwd: /usr/share/common-license package/recipeinfo contains GPLv3 info

[virendra kumar thakur]

Thank you khem raj for your input, I have already tried with

INCOMPATIBLE_LICENSE = "GPLv3+ LGPLv3+ AGPLv3+"

And this also

INCOMPATIBLE_LICENSE = "GPLv3* LGPLv3* AGPLv3*"

But no luck, still I can see same output


rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo

LICENSE: GPLV2+ + +
PR: r0
 PV : 1.8.4


On Fri 24 May, 2019, 5:25 AM Khem Raj,  wrote:

>
>
> On 5/23/19 2:42 AM, virendra kumar thakur wrote:
> >
> >
> > Hello team,
> >
> > I am trying to build yocto image without GPLv3 package, I have added
> > below things in local.conf and enable meta-gplv2 layer.
> >
> > INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0" in local.conf.
>
> Can you try adding GPLv3+ to INCOMPATIBLE_LICENSE and see if that helps ?
>
> >
> > After verifying from package.manifest and license.manifest file in
> > build/tmp/deploy/license/ directory I observe that no GPLv3 package is
> > present in rootfs.
> >
> > But I can see in
> > rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
> >
> > LICENSE: GPLV2+ + +
> > PR: r0
> > PV : 1.8.4
> >
> > Is present..
> >
> > My doubt is why any GPLv3 is present in common-license directory?
> >
> > From: "Burton, Ross"  ross.bur...@intel.com>>
> > To: virendra kumar thakur  > >
> > Cc: Yocto-mailing-list  > >
> > Subject: Re: [yocto] GPLv3 package present in rootfs
> >
> > On Wed, 22 May 2019 at 06:26, virendra kumar thakur
> > mailto:coolvee...@gmail.com>> wrote:
> >> still some package gnutls, libidn2, libassuan, are added into rootfs.
> >
> > Randomly picking libassuan:
> >
> > LICENSE_${PN} = "LGPLv2.1+"
> >
> > The library itself is LGPL-2.  Have you verified the *package*
> > licenses for what is actually going into the image?
> >
> > Ross
> >
> >
> >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building single package as image, respecting dependencies

[Norman Stetter]

For the OS image I use cpio.gz as file system. It gets booted as a RAMdisk. 
Sorry, forgot to mention that.

Building two different images doesn’t suit our use case. We install the image 
on a device and run different automated test suites on it, some of which need 
python. But for all of the testing time is critical.

I now have it running with the recipe I posted in the first mail in this 
thread. But I still can’t get rid of busybox in my python image.

Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH

21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
[cid:image001.jpg@01D5120A.5B66BBD0]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

Von: Burton, Ross [mailto:ross.bur...@intel.com]
Gesendet: Thursday, May 23, 2019 3:46 PM
An: Norman Stetter 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Building single package as image, respecting dependencies

On Thu, 23 May 2019 at 13:46, Norman Stetter 
mailto:norman.stet...@garz-fricke.com>> wrote:
That seems to be a misunderstanding. I want to keep the OS image as small as 
possible to reduce boot time. We only use python for some test scenarios, so it 
doesn’t have to be included in the OS image. I did some measurements and 
including python3 in the OS image increased the boot time by over 30%. So the 
idea is to have it separately, and only mount it, when needed.

What filesystem are you using?  I wasn't aware of any modern file systems where 
the number of files installed affected mount performance.

Could you just build two images and have a 'normal' image and a 'test image'?  
This is basically what the tools-testapps image feature is for.

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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Tg, Harish]

Hi Raj,
What I am asking you is that how the yocto picks up components for 
/usr/bin folder of rootfs. Where do they exist before copying? I am sorry but I 
feel I do not need to write a recipe for adding just one of the commands. It is 
just that I need to add "ubiattach" to target /usr/bin of rootfs. That’s why I 
am asking where do I place my "ubiattach" command and there should also be a 
folder for this. Please clarify.

Thanks,
Harish.
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Friday, May 24, 2019 11:03 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

Please keep the thread on list and avoid pm.

as I said you need

1. Write a recipe for your package
2. in do_install of the recipe you want to mention where it should be placed 
e.g.

install -D -m 0755  ${D}${bindir}/

would put it in /usr/bin on target when this package is included in image

3. Include the package in image via IMAGE_INSTALL



On 5/23/19 10:13 PM, Tg, Harish wrote:
> Hi Raj,
>  Another question I have is where do I place my custom 
> "ubiattach" command. Also I am not sure from where does the yocto builds the 
> rootfs /usr/bin components. Where do they copied from?
> 
> Thanks,
> Harish.
> 
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, May 24, 2019 7:07 AM
> To: Tg, Harish ; yocto@yoctoproject.org
> Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95
> 
> 
> 
> On 5/23/19 5:59 AM, Tg, Harish wrote:
>> Hi,
>>I have a question. How to add commands like "ubiattach" to /usr/bin 
>> of rootfs image. I struggling with the recipes. I do not want to write my 
>> own recipe but I need to edit some recipe and add the command. Which is the 
>> place? I am using yocto for my project on TI platform and Linux.
>> Kindly help.
>>
> 
> There is oe-pkgdata-util which can help to map files to recipes but we 
> do not have a database for mapping. Maybe it is a good thing to have
> 
> for your problem ubiattach is provided by mtd-utils-ubifs which is 
> built from mtd-utils recipe. I found it via above tool
> 
> % oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
> mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils
> 
> % oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils
> 
> So you need to add
> 
> IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or 
> local.conf
>>
>> Thanks,
>> Harish.
>>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of 
>> yocto-requ...@yoctoproject.org
>> Sent: Wednesday, May 22, 2019 6:57 PM
>> To: yocto@yoctoproject.org
>> Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95
>>
>> Send yocto mailing list submissions to
>>  yocto@yoctoproject.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproje
>> c 
>> t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYA
>> f 
>> VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5Y
>> Y Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
>> 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. GPLv3 package present in rootfs (virendra kumar thakur)
>>  2. Building single package as image, respecting dependencies
>> (Norman Stetter)
>>
>>
>> -
>> -
>>
>> Message: 1
>> Date: Wed, 22 May 2019 18:55:45 +0530
>> From: virendra kumar thakur 
>> To: yocto@yoctoproject.org
>> Subject: [yocto] GPLv3 package present in rootfs
>> Message-ID:
>>  
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello team,
>>
>> I want to remove some GPLv3 package from rootfs, but it is still present.
>>
>> I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"
>>
>> still some package gnutls, libidn2, libassuan, are added into rootfs.
>> -- next part -- An HTML attachment was 
>> scrubbed...
>> URL:
>> > c 
>> t.org_pipermail_yocto_attachments_20190522_fb9ebe67_attachment-2D0001.
>> html=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQy
>> s 
>> OP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=BBPanV
>> h jmdOQaYXZFeb4RWi9MdRpGYBFLmqihDeSAds=>
>>
>> --
>>
>> Message: 2
>> Date: Wed, 22 May 2019 12:36:18 +
>> From: Norman Stetter 
>> To: "yocto@yoctoproject.org" 
>> Subject: [yocto] Building single package as image, respecting
>>  dependencies
>> Message-ID:
>>  
>> 
>> Content-Type: