From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id E0F66E00B5F; Thu, 23 May 2019 21:14:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY, RCVD_IN_DNSWL_NONE,US_DOLLARS_3 autolearn=no version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (zoran.stojsavljevic[at]gmail.com) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no * trust * [209.85.222.174 listed in list.dnswl.org] * 1.4 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 LOTS_OF_MONEY Huge... sums of money Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B27C5E00798 for ; Thu, 23 May 2019 21:14:25 -0700 (PDT) Received: by mail-qk1-f174.google.com with SMTP id p26so2862570qkj.5 for ; Thu, 23 May 2019 21:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HTGCStDOYtLVIE3Qs/s1zofwk9CajH3/ltIpmfQnKZI=; b=jGP+bjK4HEyolpL1DCB3dRL+jxjAfpYthprlXmyNGIc2nyooPeqY62qgVSkscvWOhR yitHhWKgD6ugyN4M1HXkMkgT52N8+4/qzuGleBpABaaMYpHvv/8U3ZEcIOwVtVo2G52x /moUcdNs93pK4MkuDRl8RE+bEH8NMaE0TgWm8jsJ7XnZ7EPO+Ymu2XjlNTUtJV5f5bKd dUXLEy6iSILtML8SAwXzvpcx82q/+zy6/onGJaKw534+diSUhW0jBI7RNgM6lxN2ZN9b a6mlfdMpUUsaT7oQW6uUXx8ZlrDkoeXG2MaaxduCskwEjAcAg7+9Z2Xw3zhnYvuhaCUa rB5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HTGCStDOYtLVIE3Qs/s1zofwk9CajH3/ltIpmfQnKZI=; b=iJZJNFOQE7R+Fi5IAmOF7iZdy3r+IWGrys/BJlIzawJ7LQTvbRMJxsLPi901582D8q CaA+djdhX/V5HNlAnwa2AEbBjx34LNNE2PYkRU0HdfHwhmPHPpMOufiY0dIpjdaQ7vIE C6szcvr2kiYK4QdfP/aBqFPse2AyENoP3KgpQg9inXqIbykR84dBC/yMkL6b8C25VkTd 2dukRAmIO5kCvUYAcFmni3M8NV7kAmg0L7ClljWw4MjT3gyzgRM1vD00ZHaksOiYa2Lp 7K5uAZSS2HR+J+JGmOUef0PcfDMpvqRZNIHGFjyhcC1+TdoV7vmRnksSaYifEQZDuXeQ L7aw== X-Gm-Message-State: APjAAAVGH1/HNXAO/K3Ux7cTOVVLgcni0otB2bxQlgCgLgxY/VAy64Ys xdy0IgxcWwhH9g7Zwdle+P8c3hojnfNWgwEEXqE= X-Google-Smtp-Source: APXvYqyTL4CblEHXtbeHqx2JKad+Fx9eiRQELiW0181pzruY7o/eZljJhmu4kpGSfwRekfbDrjRExWsXC1z+OVN9IPI= X-Received: by 2002:ac8:2617:: with SMTP id u23mr83302343qtu.141.1558671264703; Thu, 23 May 2019 21:14:24 -0700 (PDT) MIME-Version: 1.0 References: <903d2bf0-2711-b734-d844-ef032fb67d58@2net.co.uk> In-Reply-To: From: Zoran Stojsavljevic Date: Fri, 24 May 2019 06:14:12 +0200 Message-ID: To: Khem Raj Cc: Yocto Project Subject: Re: Building Out-of-Tree Modules on the BBB Target X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 04:14:27 -0000 Content-Type: multipart/alternative; boundary="0000000000000deac505899a6f69" --0000000000000deac505899a6f69 Content-Type: text/plain; charset="UTF-8" > 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 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. (I am aware that YOCTO kernels are less/smaller in size, but how smaller?) 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 = " 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 > > > > > 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.stojsavljevic@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 this one as well, I'll probably have it done for the > fall release. But our devsrc used to pretty much be the full source it has > now been pruned down to something more manageable. There are definitely > some cases for having the full source on the target again, and it will be a > separate package, just not the minimal one to build out of tree modules, > etc. > >> > >> > >> > >>> > >>> > >>> SDK building with such a support is good/cool. But sometimes, before > >>> introducing SDK, some tests should be done on target. NO need to > >>> optionally include built-in layer hello-world driver example. Since I > >>> (or you name the person) have own test drivers, which will be imported > >>> out of tree, externally, to the target test bed! > >>> > >> > >> I never use the SDK myself, so you are not alone in not going to it > first. Hopefully I'll get some new patches out in the coming month before > summer holidays really kick in. > >> > >> Bruce > >> > >> > >>> > >>> Just thinking loud... > >>> > >>> Zoran > >>> _______ > >>> > >>> On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield < > bruce.ashfield@gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic < > zoran.stojsavljevic@gmail.com> wrote: > >>>>> > >>>>>> That's correct. That command only adds the kernel source and > >>>>>> build infrastructure to the SDK, not to your target image. You'd > still > >>>>>> need to arrange to have the kernel-devsrc package installed on the > >>>>>> target image if you want it on the board's rootfs. How you arrange > >>>>>> to have the package installed to the image varies with the image > >>>>>> (since they all don't have the same image install variables, etc). > >>>>> > >>>>> And here is a $1,000,000 USD question? How to do it on Poky (as > >>>>> example of what you have stated in RED)? ;-) > >>>>> > >>>>> In other words: how to arrange it on Poky (as a Referent example)? > >>>> > >>>> > >>>> 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. 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). > >>>> > >>>> Bruce > >>>> > >>>> > >>>>> > >>>>> > >>>>> Thank you, > >>>>> Zoran > >>>>> _______ > >>>>> > >>>>> > >>>>> On Wed, May 15, 2019 at 7:41 AM Bruce Ashfield < > bruce.ashfield@gmail.com> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, May 14, 2019 at 1:30 PM Zoran Stojsavljevic < > zoran.stojsavljevic@gmail.com> wrote: > >>>>>>> > >>>>>>> Hello Chris, Bruce, > >>>>>>> > >>>>>>> I have some additional data to share with you both, since I have > tried > >>>>>>> something. And here is my take on the things! > >>>>>>> > >>>>>>>> 1. Build using a bb recipe. > >>>>>>>> Take a look at meta-skeleton/recipes-kernel/hello-mod for an > example. > >>>>>>>> You just need to add meta-skeleton to your bblayers.conf and then > >>>>>>>> bitbake hello-mod > >>>>>>> > >>>>>>> I looked into this example, and, yes, it is classic kernel module > >>>>>>> definition out of the tree. With some outdated data, all cool, the > >>>>>>> YOCTO designer should take care himself to fix these data, if using > >>>>>>> this stuff. > >>>>>>> > >>>>>>> But this is NOT mandatory, since I can add out of the tree module > NOT > >>>>>>> actually using built-in module. I just use > .../tmp/deploy/images/bbb/* > >>>>>>> generated stuff, since I have automated scripts which are bringing > all > >>>>>>> these on my BBB target. Then I tftp my source code module to the > >>>>>>> target. > >>>>>>> > >>>>>>>> 2. Build from the SDK: > >>>>>>>> First, add the kernel source to the SDK by adding this to > conf/local.conf > >>>>>>>> TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc" > >>>>>>> > >>>>>>> YES, this is THE command which should generate > >>>>>>> /usr/src/kernel(s)/`uname -r` or similar... But adding it to > >>>>>>> local.conf and after deleting kernel, then regenerating bitbake -k > >>>>>>> core-image-minimal does not bring this path into the rootfs image!? > >>>>>> > >>>>>> > >>>>>> That's correct. That command only adds the kernel source and build > infrastructure to the SDK, not to your target image. You'd still need to > arrange to have the kernel-devsrc package installed on the target image if > you want it on the board's rootfs. How you arrange to have the package > installed to the image varies with the image (since they all don't have the > same image install variables, etc). > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I did it actually using meta-bbb, and using poky referent distro as > >>>>>>> two additional layers to the more complex bbb image! > >>>>>>> https://github.com/jumpnow/meta-bbb.git > >>>>>>> > >>>>>>> The (KAS - you can figure out out of it local.conf) script I am > using > >>>>>>> to build such a BBB image is here: > >>>>>>> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/kas-bbb-warrior.yml > >>>>>>> > >>>>>>> I did not try it with BBB reference poky only! Maybe I should try > it > >>>>>>> as only referent poky? What do you think? > >>>>>>> > >>>>>>> Does in this case is SDK build really mandatory??? Should NOT be! > >>>>>>> > >>>>>> > >>>>>> You only do the SDK steps if you want to support building out of > tree modules in an SDK install. So it is not mandatory for on target module > builds. > >>>>>> > >>>>>> Bruce > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> Once the SDK is installed, generate the kernel headers: > >>>>>>>> sudo -i > >>>>>>>> . > /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi > >>>>>>>> cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi > >>>>>>>> cd /usr/src/kernel > >>>>>>>> make oldconfig scripts > >>>>>>>> exit > >>>>>>> > >>>>>>> This is in nutshell the same what I did (a bit different) for > Embedded > >>>>>>> Debian. This is already on the target BBB, NOT while building YOCTO > >>>>>>> BBB image! > >>>>>>> > >>>>>>>> Finally, build your module using a Makefile like this > >>>>>>>> obj-m := hello-mod.o > >>>>>>>> all: > >>>>>>>> make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd) > >>>>>>> > >>>>>>> As said before: bringing my own module into the target BBB (I have > my > >>>>>>> own examples, and I build them on the target with the almost the > same > >>>>>>> Makefiles) > >>>>>>> > >>>>>>> Zoran > >>>>>>> _______ > >>>>>>> > >>>>>>> On Sun, May 12, 2019 at 3:15 PM Chris Simmonds > wrote: > >>>>>>>> > >>>>>>>> Hi Zoran, > >>>>>>>> > >>>>>>>> There are two ways to do this > >>>>>>>> > >>>>>>>> 1. Build using a bb recipe. > >>>>>>>> Take a look at meta-skeleton/recipes-kernel/hello-mod for an > example. > >>>>>>>> You just need to add meta-skeleton to your bblaysers.conf and then > >>>>>>>> bitbake hello-mod > >>>>>>>> > >>>>>>>> > >>>>>>>> 2. Build from the SDK: > >>>>>>>> First, add the kernel source to the SDK by adding this to > conf/local/conf > >>>>>>>> TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc" > >>>>>>>> > >>>>>>>> Then build the SDK > >>>>>>>> bitbake -c populate_sdk [your image recipe] > >>>>>>>> > >>>>>>>> Once the SDK is installed, generate the kernel headers: > >>>>>>>> sudo -i > >>>>>>>> . > /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi > >>>>>>>> cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi > >>>>>>>> cd /usr/src/kernel > >>>>>>>> make oldconfig scripts > >>>>>>>> exit > >>>>>>>> > >>>>>>>> Finally, build your module using a Makefile like this > >>>>>>>> > >>>>>>>> obj-m := hello-mod.o > >>>>>>>> all: > >>>>>>>> make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd) > >>>>>>>> > >>>>>>>> > >>>>>>>> HTH, > >>>>>>>> Chris > >>>>>>>> > >>>>>>>> On 12/05/2019 11:53, Zoran Stojsavljevic wrote: > >>>>>>>>> Hello to the YOCTO community, > >>>>>>>>> > >>>>>>>>> I am using (to build the target for Beagle Bone Black) the > following script: > >>>>>>>>> https://github.com/ZoranStojsavljevic/bbb-yocto > >>>>>>>>> > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh > >>>>>>>>> > >>>>>>>>> The latest kernel I am using from the following repo: > >>>>>>>>> https://github.com/jumpnow/meta-bbb > >>>>>>>>> > >>>>>>>>> Is kernel 5.0.14 . > >>>>>>>>> > >>>>>>>>> Here is the snippet of the boot traces: > >>>>>>>>> Starting kernel ... > >>>>>>>>> > >>>>>>>>> [ 0.000000] Booting Linux on physical CPU 0x0 > >>>>>>>>> [ 0.000000] Linux version 5.0.14-jumpnow (oe-user@oe-host) > (gcc > >>>>>>>>> version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019 > >>>>>>>>> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 > (ARMv7), cr=10c5387d > >>>>>>>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT > aliasing > >>>>>>>>> instruction cache > >>>>>>>>> [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black > >>>>>>>>> [ 0.000000] Memory policy: Data cache writeback > >>>>>>>>> [ 0.000000] cma: Reserved 16 MiB at 0x9f000000 > >>>>>>>>> [ 0.000000] CPU: All CPU(s) started in SVC mode. > >>>>>>>>> [ 0.000000] AM335X ES2.1 (sgx neon) > >>>>>>>>> [ 0.000000] random: get_random_bytes called from > >>>>>>>>> start_kernel+0xa4/0x460 with crng_init=0 > >>>>>>>>> [ 0.000000] Built 1 zonelists, mobility grouping on. Total > pages: 130048 > >>>>>>>>> [ 0.000000] Kernel command line: console=ttyO0,115200n8 > >>>>>>>>> root=/dev/ram0 ip=dhcp > >>>>>>>>> > >>>>>>>>> According to the documentation, the following: > >>>>>>>>> 2.10.1. Building Out-of-Tree Modules on the Target > >>>>>>>>> > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html > >>>>>>>>> > >>>>>>>>> I tried to find /usr/src/kernels/5.0.14... Directory, since I > see > >>>>>>>>> from the build that kernel-dev and kernel-devsrc are included: > >>>>>>>>> [user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel > >>>>>>>>> core-image-kernel-dev :1.0-r0 > >>>>>>>>> kernel-devsrc :1.0-r0 > >>>>>>>>> kernel-selftest :1.0-r0 > >>>>>>>>> > >>>>>>>>> THE PROBLEM: But I could not find ob BBB target /usr/src/kernels > >>>>>>>>> directory at all!? > >>>>>>>>> > >>>>>>>>> Two questions here? > >>>>>>>>> [1] Do you have any advice on this problem (what I am missing > here)? > >>>>>>>>> [2] Alternative to [1]: how I can use cross compiler from > >>>>>>>>> .../build/tmp to build Out-of-Tree Module for the BBB target on > the > >>>>>>>>> host? > >>>>>>>>> > >>>>>>>>> Thank you, > >>>>>>>>> Zoran > >>>>>>>>> _______ > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Chris Simmonds, trainer and consultant at 2net > >>>>>>>> http://www.2net.co.uk > >>>>>>>> Author of "Mastering Embedded Linux Programming" > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> - Thou shalt not follow the NULL pointer, for chaos and madness > await thee at its end > >>>>>> - "Use the force Harry" - Gandalf, Star Trek II > >>>>>> > >>>> > >>>> > >>>> -- > >>>> - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > >>>> - "Use the force Harry" - Gandalf, Star Trek II > >>>> > >> > >> > >> > >> -- > >> - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > >> - "Use the force Harry" - Gandalf, Star Trek II > >> > --0000000000000deac505899a6f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I think this is a fair suggestion. Having prebuilt ke= rnel available
> that contains the configuration and header files use= d in the build is
> all that is required for external modules to buil= d 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 i= nstalled on top if one
> needs

I am man of experimental try-ou= ts. So, in order to see how big kernel is,
I did the following:
Fedor= a 29 (which I am using as a host) with kernel-headers (NOT full
kernel s= ource tree):
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
/usr/sr= c/kernels/5.0.16-200.fc29.x86_64
[vuser@fedora29-ssd 5.0.16-200.fc29.x86= _64]$ du --summarize
102124 =C2= =A0 =C2=A0. <<=3D=3D=3D=3D=3D=3D=3D ~95MB

Kerne= l.org kernel 5.0.6, the full kernel source tree size:
[vuser@fedora29-ss= d linux-5.0.6]$ pwd
/home/vuser/projects/kernel.org/linux-5.0.6
[vuser@fedora29-= ssd linux-5.0.6]$ du --summarize
<= b>960592 =C2=A0 =C2=A0. <<=3D=3D=3D=3D=3D=3D=3D ~900MB=

These are ballpark numbers. You can draw conclusion= s for yourselves!

It is ~ 7x to 9x reduction in si= ze. Having BBB's DDR2 of size 512MB,
and initramfs for testin= g purposes, in speaks for itself.

(I am aware that= YOCTO kernels are less/smaller in size, but how smaller?)
Zoran
_______


On Fri, May 24, 2019 at 3= :00 AM Khem Raj <raj.khem@gmail.com> 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),<= br> > 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 log= ged in cases.
>> A survey of all the distros, their kernel package, etc, were all l= ooked 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-develop= ment.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`/<kernel source code>
> [2] The header files in: /usr/src/kernel/`uname-r`/<header file
> directory structures>
>
> Point [1] is achieved with the following local.config file:
> https://git= hub.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
>
> Namely, with the following snippets in the local.conf:
> TOOLCHAIN_TARGET_TASK_append =3D " packagegroup-core-tools-profil= e
> packagegroup-core-buildessential kernel-devsrc"
> KERNEL_DEV_TOOLS =3D "packagegroup-core-tools-profile
> packagegroup-core-buildessential kernel-devsrc"
> KERNEL_DEV_MODULE =3D "kernel-modules"
> CORE_IMAGE_EXTRA_INSTALL +=3D "${KERNEL_DEV_MODULE} \
> ${KERNEL_DEV_TOOLS} \
> systemtap \
> "
>
> Problem with this approach is that such a kernel makes the rootfs too<= br> > 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

>
> Thank you,
> Zoran Stojsavljevic
> _______
>
> On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
> <bruc= e.ashfield@gmail.com> wrote:
>>
>>
>>
>> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic <zoran.stojsavljevi= c@gmail.com> wrote:
>>>
>>>> The core-image-kernel-dev image is how I do all my on targ= et
>>>> testing when I introduce a new reference kernel for a rele= ase.
>>>
>>> Maybe you are correct. Maybe I should use/add in my local.conf= the following:
>>>
>>> KERNEL_DEV_TOOLS ?=3D "packagegroup-core-tools-profile >>> packagegroup-core-buildessential kernel-devsrc"
>>> KERNEL_DEV_MODULE ?=3D "kernel-modules"
>>> CORE_IMAGE_EXTRA_INSTALL +=3D "${KERNEL_DEV_MODULE} \
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0${KERNEL_DEV_TOOLS} \
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0systemtap \
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "
>>> I need to try these... Maybe this addendum will solve the $1 m= io USD problem?!
>>>
>>>> And IIRC the autobuilders are using a sato based image (Ri= chard
>>>> could confirm more easily that I could what image type the=
>>>> autobuilders are using for hello-world on target module te= sts).
>>>
>>> I am just advertising something more simple. To have mandatory=
>>> /lib/modules/`uname -r` directory. And introduce few more pack= ages, as
>>> Fedora distro, for example, has: kernel-headers (assuming YOCT= O
>>> rootfs, the following will be installed: /usr/src/kernel/`unam= e
>>> -r`/<header file directory structures>. 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 c= an'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 a= t. We had to balance the traditional packaging with some new concepts and l= anded 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 this one as well, I'll probably have it= done for the fall release. But our devsrc used to pretty much be the full = source it has now been pruned down to something more manageable.=C2=A0 Ther= e are definitely some cases for having the full source on the target again,= and it will be a separate package, just not the minimal one to build out o= f tree modules, etc.
>>
>>
>>
>>>
>>>
>>> SDK building with such a support is good/cool. But sometimes, = before
>>> introducing SDK, some tests should be done on target. NO need = to
>>> optionally include built-in layer hello-world driver example. = Since I
>>> (or you name the person) have own test drivers, which will be = imported
>>> out of tree, externally, to the target test bed!
>>>
>>
>> I never use the SDK myself, so you are not alone in not going to i= t first. Hopefully I'll get some new patches out in the coming month be= fore summer holidays really kick in.
>>
>> Bruce
>>
>>
>>>
>>> Just thinking loud...
>>>
>>> Zoran
>>> _______
>>>
>>> On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield <bruce.ashfield@gmail.com= > wrote:
>>>>
>>>>
>>>>
>>>> On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic <zoran.stoj= savljevic@gmail.com> wrote:
>>>>>
>>>>>> That's correct. That command only adds the ker= nel source and
>>>>>> build infrastructure to the SDK, not to your targe= t image. You'd still
>>>>>> need to arrange to have the kernel-devsrc package = installed on the
>>>>>> target image if you want it on the board's roo= tfs. How you arrange
>>>>>> to have the package installed to the image varies = with the image
>>>>>> (since they all don't have the same image inst= all variables, etc).
>>>>>
>>>>> And here is a $1,000,000 USD question? How to do it on= Poky (as
>>>>> example of what you have stated in RED)? ;-)
>>>>>
>>>>> In other words: how to arrange it on Poky (as a Refere= nt example)?
>>>>
>>>>
>>>> The core-image-kernel-dev image is how I do all my on targ= et testing when I introduce a new reference kernel for a release. And IIRC = the autobuilders are using a sato based image (Richard could confirm more e= asily that I could what image type the autobuilders are using for hello-wor= ld on target module tests).
>>>>
>>>> Bruce
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Zoran
>>>>> _______
>>>>>
>>>>>
>>>>> On Wed, May 15, 2019 at 7:41 AM Bruce Ashfield <bruce.ashfield@g= mail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 14, 2019 at 1:30 PM Zoran Stojsavljevi= c <zo= ran.stojsavljevic@gmail.com> wrote:
>>>>>>>
>>>>>>> Hello Chris, Bruce,
>>>>>>>
>>>>>>> I have some additional data to share with you = both, since I have tried
>>>>>>> something. And here is my take on the things!<= br> >>>>>>>
>>>>>>>> 1. Build using a bb recipe.
>>>>>>>> Take a look at meta-skeleton/recipes-kerne= l/hello-mod for an example.
>>>>>>>> You just need to add meta-skeleton to your= bblayers.conf and then
>>>>>>>>=C2=A0 =C2=A0bitbake hello-mod
>>>>>>>
>>>>>>> I looked into this example, and, yes, it is cl= assic kernel module
>>>>>>> definition out of the tree. With some outdated= data, all cool, the
>>>>>>> YOCTO designer should take care himself to fix= these data, if using
>>>>>>> this stuff.
>>>>>>>
>>>>>>> But this is NOT mandatory, since I can add out= of the tree module NOT
>>>>>>> actually using built-in module. I just use ...= /tmp/deploy/images/bbb/*
>>>>>>> generated stuff, since I have automated script= s which are bringing all
>>>>>>> these on my BBB target. Then I tftp my source = code module to the
>>>>>>> target.
>>>>>>>
>>>>>>>> 2. Build from the SDK:
>>>>>>>> First, add the kernel source to the SDK by= adding this to conf/local.conf
>>>>>>>>=C2=A0 =C2=A0TOOLCHAIN_TARGET_TASK_append = =3D " kernel-devsrc"
>>>>>>>
>>>>>>> YES, this is THE command which should generate=
>>>>>>> /usr/src/kernel(s)/`uname -r` or similar... Bu= t adding it to
>>>>>>> local.conf and after deleting kernel, then reg= enerating bitbake -k
>>>>>>> core-image-minimal does not bring this path in= to the rootfs image!?
>>>>>>
>>>>>>
>>>>>> That's correct. That command only adds the ker= nel source and build infrastructure to the SDK, not to your target image. Y= ou'd still need to arrange to have the kernel-devsrc package installed = on the target image if you want it on the board's rootfs. How you arran= ge to have the package installed to the image varies with the image (since = they all don't have the same image install variables, etc).
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I did it actually using meta-bbb, and using po= ky referent distro as
>>>>>>> two additional layers to the more complex bbb = image!
>>>>>>> https://github.com/jumpnow/meta-= bbb.git
>>>>>>>
>>>>>>> The (KAS - you can figure out out of it local.= conf) script I am using
>>>>>>> to build such a BBB image is here:
>>>>>>> https://github.com/ZoranStojsavljevic/bbb= -yocto/blob/master/bbb-releases/bbb-warrior/kas-bbb-warrior.yml
>>>>>>>
>>>>>>> I did not try it with BBB reference poky only!= Maybe I should try it
>>>>>>> as only referent poky? What do you think?
>>>>>>>
>>>>>>> Does in this case is SDK build really mandator= y??? Should NOT be!
>>>>>>>
>>>>>>
>>>>>> You only do the SDK steps if you want to support b= uilding out of tree modules in an SDK install. So it is not mandatory for o= n target module builds.
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Once the SDK is installed, generate the ke= rnel headers:
>>>>>>>>=C2=A0 =C2=A0sudo -i
>>>>>>>>=C2=A0 =C2=A0. /opt/poky/2.6.2/environment-= setup-cortexa8hf-neon-poky-linux-gnueabi
>>>>>>>>=C2=A0 =C2=A0cd /opt/poky/2.6.2/sysroots/co= rtexa8hf-neon-poky-linux-gnueabi
>>>>>>>>=C2=A0 =C2=A0cd /usr/src/kernel
>>>>>>>>=C2=A0 =C2=A0make oldconfig scripts
>>>>>>>>=C2=A0 =C2=A0exit
>>>>>>>
>>>>>>> This is in nutshell the same what I did (a bit= different) for Embedded
>>>>>>> Debian. This is already on the target BBB, NOT= while building YOCTO
>>>>>>> BBB image!
>>>>>>>
>>>>>>>> Finally, build your module using a Makefil= e like this
>>>>>>>>=C2=A0 =C2=A0obj-m :=3D hello-mod.o
>>>>>>>>=C2=A0 =C2=A0all:
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make -C $= (SDKTARGETSYSROOT)/usr/src/kernel M=3D$(shell pwd)
>>>>>>>
>>>>>>> As said before: bringing my own module into th= e target BBB (I have my
>>>>>>> own examples, and I build them on the target w= ith the almost the same
>>>>>>> Makefiles)
>>>>>>>
>>>>>>> Zoran
>>>>>>> _______
>>>>>>>
>>>>>>> On Sun, May 12, 2019 at 3:15 PM Chris Simmonds= <chris@2net.co.uk= > wrote:
>>>>>>>>
>>>>>>>> Hi Zoran,
>>>>>>>>
>>>>>>>> There are two ways to do this
>>>>>>>>
>>>>>>>> 1. Build using a bb recipe.
>>>>>>>> Take a look at meta-skeleton/recipes-kerne= l/hello-mod for an example.
>>>>>>>> You just need to add meta-skeleton to your= bblaysers.conf and then
>>>>>>>>=C2=A0 =C2=A0 bitbake hello-mod
>>>>>>>>
>>>>>>>>
>>>>>>>> 2. Build from the SDK:
>>>>>>>> First, add the kernel source to the SDK by= adding this to conf/local/conf
>>>>>>>>=C2=A0 =C2=A0 TOOLCHAIN_TARGET_TASK_append = =3D " kernel-devsrc"
>>>>>>>>
>>>>>>>> Then build the SDK
>>>>>>>>=C2=A0 =C2=A0 bitbake -c populate_sdk [your= image recipe]
>>>>>>>>
>>>>>>>> Once the SDK is installed, generate the ke= rnel headers:
>>>>>>>>=C2=A0 =C2=A0 sudo -i
>>>>>>>>=C2=A0 =C2=A0 . /opt/poky/2.6.2/environment= -setup-cortexa8hf-neon-poky-linux-gnueabi
>>>>>>>>=C2=A0 =C2=A0 cd /opt/poky/2.6.2/sysroots/c= ortexa8hf-neon-poky-linux-gnueabi
>>>>>>>>=C2=A0 =C2=A0 cd /usr/src/kernel
>>>>>>>>=C2=A0 =C2=A0 make oldconfig scripts
>>>>>>>>=C2=A0 =C2=A0 exit
>>>>>>>>
>>>>>>>> Finally, build your module using a Makefil= e like this
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 obj-m :=3D hello-mod.o
>>>>>>>>=C2=A0 =C2=A0 all:
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 make -C = $(SDKTARGETSYSROOT)/usr/src/kernel M=3D$(shell pwd)
>>>>>>>>
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>> On 12/05/2019 11:53, Zoran Stojsavljevic w= rote:
>>>>>>>>> Hello to the YOCTO community,
>>>>>>>>>
>>>>>>>>> I am using (to build the target for Be= agle Bone Black) the following script:
>>>>>>>>> https://github.c= om/ZoranStojsavljevic/bbb-yocto
>>>>>>>>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yo= cto.sh
>>>>>>>>>
>>>>>>>>> The latest kernel I am using from the = following repo:
>>>>>>>>> https://github.com/jumpnow/m= eta-bbb
>>>>>>>>>
>>>>>>>>> Is kernel 5.0.14 .
>>>>>>>>>
>>>>>>>>> Here is the snippet of the boot traces= :
>>>>>>>>> Starting kernel ...
>>>>>>>>>
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] Booting Linux= on physical CPU 0x0
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] Linux version= 5.0.14-jumpnow (oe-user@oe-host) (gcc
>>>>>>>>> version 8.3.0 (GCC)) #1 Fri May 10 13:= 12:33 UTC 2019
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] CPU: ARMv7 Pr= ocessor [413fc082] revision 2 (ARMv7), cr=3D10c5387d
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] CPU: PIPT / V= IPT nonaliasing data cache, VIPT aliasing
>>>>>>>>> instruction cache
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] OF: fdt: Mach= ine model: TI AM335x BeagleBone Black
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] Memory policy= : Data cache writeback
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] cma: Reserved= 16 MiB at 0x9f000000
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] CPU: All CPU(= s) started in SVC mode.
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] AM335X ES2.1 = (sgx neon)
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] random: get_r= andom_bytes called from
>>>>>>>>> start_kernel+0xa4/0x460 with crng_init= =3D0
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] Built 1 zonel= ists, mobility grouping on.=C2=A0 Total pages: 130048
>>>>>>>>> [=C2=A0 =C2=A0 0.000000] Kernel comman= d line: console=3DttyO0,115200n8
>>>>>>>>> root=3D/dev/ram0 ip=3Ddhcp
>>>>>>>>>
>>>>>>>>> According to the documentation, the fo= llowing:
>>>>>>>>> 2.10.1. Building Out-of-Tree Modules o= n the Target
>>>>>>>>> https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html=
>>>>>>>>>
>>>>>>>>> I tried to find /usr/src/kernels/5.0.14... Di= rectory, since I see
>>>>>>>>> from the build that kernel-dev and ker= nel-devsrc are included:
>>>>>>>>> [user@fedora29-ssd bbb-yocto]$ bitbake= -s | grep kernel
>>>>>>>>> core-image-kernel-dev=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0:1.0-r0
>>>>>>>>> kernel-devsrc=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:1.0-r0
>>>>>>>>> kernel-selftest=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:1.0-r0
>>>>>>>>>
>>>>>>>>> THE PROBLEM: But I could not find ob B= BB target /usr/src/kernels
>>>>>>>>> directory at all!?
>>>>>>>>>
>>>>>>>>> Two questions here?
>>>>>>>>> [1] Do you have any advice on this pro= blem (what I am missing here)?
>>>>>>>>> [2] Alternative to [1]: how I can use = cross compiler from
>>>>>>>>> .../build/tmp to build Out-of-Tree Mod= ule for the BBB target on the
>>>>>>>>> host?
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Zoran
>>>>>>>>> _______
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chris Simmonds, trainer and consultant at = 2net
>>>>>>>> http://www.2net.co.uk
>>>>>>>> Author of "Mastering Embedded Linux P= rogramming"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> - Thou shalt not follow the NULL pointer, for chao= s and madness await thee at its end
>>>>>> - "Use the force Harry" - Gandalf, Star = Trek II
>>>>>>
>>>>
>>>>
>>>> --
>>>> - Thou shalt not follow the NULL pointer, for chaos and ma= dness await thee at its end
>>>> - "Use the force Harry" - Gandalf, Star Trek II<= br> >>>>
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness aw= ait thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>>
--0000000000000deac505899a6f69--