Re: [yocto] Building kernel backports for ARM with Yocto
On Thu, 2017-10-19 at 14:18 -0700, Khem Raj wrote:
> On Thu, Oct 19, 2017 at 12:38 PM, Marlon Smith <marlon.smith10@gmail.
> com> wrote:
> >
> > On Wed, 2017-10-18 at 22:50 -0700, Khem Raj wrote:
> > >
> > > On Wed, Oct 18, 2017 at 3:13 PM, Marlon Smith <marlon.smith10@gma
> > > il.c
> > > om> wrote:
> > > >
> > > >
> > > > Hi everyone,
> > > >
> > > > I'm trying to build the Linux backports project to get updated
> > > > wifi
> > > > drivers
> > > > on an older kernel. The problem is that when building
> > > > backports,
> > > > it first
> > > > builds several tools that need to be run natively before cross-
> > > > compiling the
> > > > rest of the project.
> > > >
> > > > I know how to write a bitbake recipe to compile natively, and
> > > > how
> > > > to write
> > > > one to build for the target, but I can't figure out how to
> > > > combine
> > > > the two.
> > > > The backports project has steps for LTIB:
> > > >
> > > > %Build
> > > > export PATH=$UNSPOOF_PATH
> > > >
> > > > make menuconfig prefix=%{_prefix} \
> > > > CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> > > > ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> > > > KLIB_BUILD=${TOP}/rpm/BUILD/linux
> > > >
> > > > export PATH=$SPOOF_PATH
> > > >
> > > > make prefix=%{_prefix} \
> > > > CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> > > > ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> > > > KLIB_BUILD=${TOP}/rpm/BUILD/linux
> > > >
> > > >
> > > > I believe what I need is an equivalent to the line export
> > > > PATH=$UNSPOOF_PATH
> > > > but I can't find anything in the Yocto documentation or mailing
> > > > lists that
> > > > would be equivalent to that.
> > > >
> > > >
> > > > Any help would be much appreciated!
> > > You might try this out
> > >
> > > https://github.com/kraj/meta-himvis/blob/master/recipes-kernel/li
> > > nux-
> > > backports/linux-backports_4.14-rc4.bb
> > >
> > > it does not work out of box but with few fixes here and there it
> > > should work
> > It looks like that recipe inherits backports_module and kernel-
> > backports_module-split.. do I need those files as well?
> >
> backports_module is merged into recipe itsellf. Other one can be
> replaced with inehrtiting
> module bbclasss
Ok I'll give that a try. Thanks for the help!
>
> >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > Marlon
> > > >
> > > >
> > > > --
> > > > ___
> > > > yocto mailing list
> > > > yocto@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > > >
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building kernel backports for ARM with Yocto
On Wed, 2017-10-18 at 22:50 -0700, Khem Raj wrote:
> On Wed, Oct 18, 2017 at 3:13 PM, Marlon Smith <marlon.smith10@gmail.c
> om> wrote:
> >
> > Hi everyone,
> >
> > I'm trying to build the Linux backports project to get updated wifi
> > drivers
> > on an older kernel. The problem is that when building backports,
> > it first
> > builds several tools that need to be run natively before cross-
> > compiling the
> > rest of the project.
> >
> > I know how to write a bitbake recipe to compile natively, and how
> > to write
> > one to build for the target, but I can't figure out how to combine
> > the two.
> > The backports project has steps for LTIB:
> >
> > %Build
> > export PATH=$UNSPOOF_PATH
> >
> > make menuconfig prefix=%{_prefix} \
> > CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> > ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> > KLIB_BUILD=${TOP}/rpm/BUILD/linux
> >
> > export PATH=$SPOOF_PATH
> >
> > make prefix=%{_prefix} \
> > CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> > ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> > KLIB_BUILD=${TOP}/rpm/BUILD/linux
> >
> >
> > I believe what I need is an equivalent to the line export
> > PATH=$UNSPOOF_PATH
> > but I can't find anything in the Yocto documentation or mailing
> > lists that
> > would be equivalent to that.
> >
> >
> > Any help would be much appreciated!
> You might try this out
>
> https://github.com/kraj/meta-himvis/blob/master/recipes-kernel/linux-
> backports/linux-backports_4.14-rc4.bb
>
> it does not work out of box but with few fixes here and there it
> should work
It looks like that recipe inherits backports_module and kernel-
backports_module-split.. do I need those files as well?
>
> >
> >
> >
> > Thanks
> >
> >
> > Marlon
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building kernel backports for ARM with Yocto
Darcy, thanks for the detailed reply!
Do you remember how you were able to get it to compile in the first
place? I end up with this error:
./kconf/conf: 1: ./kconf/conf: Syntax error: word unexpected (expecting
")")
..because backports needs to compile conf for x86_64, but instead
compiles it for ARM. Once that step is done, it needs to compile the
rest of the project for ARM, but this error stops it.
I think I could work around the sysroot arm-wrestle because of the way
our project is built, but haven't made it to that point yet.
Here's the bb file I'm using:
---
include backports.inc
SRCBRANCH = "linux-4.2.y"
LOCALVERSION = "v4.2.6-1-0-g90118c7"
SRCREV = "90118c7656bb55243620c9dc9cc3f12582b1807f"
DEPENDS += "linux-myproject"do_configure_prepend() {
export CROSS_COMPILE=${TARGET_PREFIX}
export ARCH=${TARGET_ARCH}
export KLIB_BUILD=${STAGING_KERNEL_DIR}
export KLIB=${STAGING_DIR_TARGET}
make
}
---
On Wed, 2017-10-18 at 22:53 +, Darcy Watkins wrote:
> I tried building backports under Yocto a few years back using Yocto
> daisy branch with kernel 3.4 for x86 and kernel 3.12 for ARM. After
> a fair amount of pain I was able to get it to sort of work. The
> problem was mainly a sysroot arm-wrestle between kernel and backports
> because they both generate the same kernel module packages. It was a
> last-one-wins arm-wrestle. It sort of worked OK with daisy branch,
> but newer yocto versions have stricter management of sysroots and
> staging areas.
>
> I think what we need is some sort of virtual provider or alternatives
> scheme to make this work properly.
>
> You can also run into problems related to exports to other out-of-
> tree modules but IIRC, it would only affect an out-of-tree module
> with an incompatible license.
>
> I was able to run a few circa kernel 3.18 backports experimentally on
> a kernel 3.4 and a kernel 3.12. Eventually we just upgraded the
> kernel. Another project I know of used backports to update their
> kernel source and then created a recipe to build kernel from that
> source.
>
> The notes/questions I had in the end were:
>
> was building backports as out-of-tree kernel modules
> was concerned that this wouldn’t provide updated kernel staging
> source, particularly with respect to any updated includes
> wasn’t sure what would be propagated into the sysroot
> should consider the backports use case that patches the kernel source
> and then perhaps use this to generate patchset to be added to kernel
> recipe (bbappend)
> otherwise need to ensure proper handling of sysroot, staging, (as
> well as a notion of providers and/or alternatives like I mentioned
> earlier)
>
> I haven’t touched this in years, but perhaps it may help a bit.
>
> I think your best bet for short term is to use it to patch the kernel
> and then capture the changes as a patchset to add to a kernel recipe.
>
>
>
> Regards,
>
> Darcy
>
> Darcy Watkins :: Senior Staff Engineer, Firmware
>
> SIERRA WIRELESS
> Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604
> 231 1100
> 13811 Wireless Way :: Richmond, BC Canada V6V 3A4
> [P2]
> dwatk...@sierrawireless.com :: www.sierrawireless.com
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-bounces@yoctoproje
> ct.org] On Behalf Of Marlon Smith
> Sent: October-18-17 3:14 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] Building kernel backports for ARM with Yocto
>
> Hi everyone,
>
> I'm trying to build the Linux backports project to get updated wifi
> drivers on an older kernel. The problem is that when building
> backports, it first builds several tools that need to be run natively
> before cross-compiling the rest of the project.
>
> I know how to write a bitbake recipe to compile natively, and how to
> write one to build for the target, but I can't figure out how to
> combine the two. The backports project has steps for LTIB:
>
> %Build
> export PATH=$UNSPOOF_PATH
>
> make menuconfig prefix=%{_prefix} \
> CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
> export PATH=$SPOOF_PATH
>
> make prefix=%{_prefix} \
> CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
> ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
> KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
> I believe what I need is an equivalent to the line export
> PATH=$UNSPOOF_PATH but I can't find anything in the Yocto
> documentation or mailing lists that would be equivalent to that.
>
> Any help would be much appreciated!
>
> Thanks
>
> Marlon--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building kernel backports for ARM with Yocto
Hi everyone,
I'm trying to build the Linux backports project to get updated wifi
drivers on an older kernel. The problem is that when building
backports, it first builds several tools that need to be run natively
before cross-compiling the rest of the project.
I know how to write a bitbake recipe to compile natively, and how to
write one to build for the target, but I can't figure out how to
combine the two. The backports project has steps for LTIB:
%Build
export PATH=$UNSPOOF_PATH
make menuconfig prefix=%{_prefix} \
CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
KLIB_BUILD=${TOP}/rpm/BUILD/linux
export PATH=$SPOOF_PATH
make prefix=%{_prefix} \
CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
KLIB_BUILD=${TOP}/rpm/BUILD/linux
I believe what I need is an equivalent to the line export
PATH=$UNSPOOF_PATH but I can't find anything in the Yocto documentation
or mailing lists that would be equivalent to that.
Any help would be much appreciated!
Thanks
Marlon--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Why use Yocto?
Wow, thanks everyone for the excellent replies. I am a developer and not much of a legal guy, so pointing out the licensing issues with Ubuntu was especially helpful. It sounds like we are going to choose Yocto for our product. On Tue, 2014-06-10 at 17:42 +0200, Nicolas Dechesne wrote: On Tue, Jun 10, 2014 at 4:39 PM, Bob Cochran yo...@mindchasers.com wrote: How dp you plan to sell/market/license your Ubuntu based machine? Would you become an Ubuntu hardware partner? http://www.ubuntu.com/partners/find-a-partner/hardware The scope of this partnership seems to be servers and desktops. I assume they also have something in the works for smart phone partners. However, I'm guessing you're building something that doesn't fit these categories. I remember seeing various demo images over the years of Ubuntu running on embedded hardware, but it always seems to fizzle out. EmbeddedUbuntu on the Ubuntu Wiki was last updated in 2009. But maybe you're talking with people at Canonical and they are telling you something different? If so, please share. i guess this is of interest for the discussion (from [1]): === 2. Your use of Ubuntu You can download, install and receive updates to Ubuntu for free. Ubuntu is freely available to all users for personal, or in the case of organisations, internal use. It is provided for this use without warranty. All implied warranties are disclaimed to the fullest extent permitted at law. You can modify Ubuntu for personal or internal use. You can make changes to Ubuntu for your own personal use or for your organisation’s own internal use. You can redistribute Ubuntu, but only where there has been no modification to it. You can redistribute Ubuntu in its unmodified form, complete with the installer images and packages provided by Canonical (this includes the publication or launch of virtual machine images). Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below). === IANAL... but i guess the last paragraph clarifies what you can do (or not). [1] http://www.canonical.com/intellectual-property-rights-policy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best way to freeze Yocto for production
Hi everyone, We've decided to use Yocto in our company's product! And I have a question: Since Yocto is updated pretty frequently, at some point we'll need to freeze everything and keep a permanent copy so that we can make small changes/bug fixes without having to worry about anything being changed outside of our control. My current theory is that we'll do a bitbake -c fetchall, then zip up the entire Yocto directory and save it somewhere so we'll always have a static copy. We'll place our application and custom bsp layer under a separate Git repository, and then to do a build we'll just combine everything together and run bitbake on the whole thing. Is there a better or recommended way of doing this? Thanks again, and I'm excited to start working with Yocto! Marlon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Why use Yocto?
Hi everyone, I'm developing a product that will run on a custom i.MX6 board and I'm trying to decide whether to use Yocto or Ubuntu (there's a version of Ubuntu packaged for the Wandboard that will run on our board). The board will run our own custom app, and we'll modify the Linux kernel to support our hardware. Ubuntu seems like it would be ready to go - just put it on an SD card, boot the board, compile the app and create a new SD card image from the result to use for manufacturing. Yocto seems like it would be easier to remove unneeded packages from, and easier to cross-compile the application for. This means we could have a smaller SD card image in the end. What are your thoughts on this? Thanks Marlon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
