how to build external firmware for kernel

how to build external firmware for kernel

[lothar]

Hello Yocto Comunity,

I have a linux kernel and a external firmware. Building manually,  
first I have to checkout and build the firmware "native" to obtain a  
firmware blob, then I need this firmware blob to build the kernel for  
the target.

So far I tried to do this in yocto with separate recipes: a  
firmware.bb and a mylinux.bb. In firmware.bb, I check out the firmware  
via git and let it run "make" on native (this is necessary, since the  
Makefile builds a tool which then automatically gets called inside the  
Makefile to create the firmware blob).

In the kernel recipe, I declare a DEPEND on firmware.bb. I set the  
.config options to load an extra firmware blob. But now, I have a  
problem: I need actually to have the firmware blob within the kernel's  
file hierarchy. Ideally I would copy/move it from the firmware's  
destination directory into the kernel's source directory.

Questions:
How can I achieve this kind of setup working out with yocto or  
bitbake, respectively? What might be the best approach in my situation?

Thanks in advance,
Lothar

Re: how to build external firmware for kernel

[Paul Eggleton]

Hi Lothar,

On Monday 05 August 2013 11:42:22 lothar@denx.de wrote:
> I have a linux kernel and a external firmware. Building manually,
> first I have to checkout and build the firmware "native" to obtain a
> firmware blob, then I need this firmware blob to build the kernel for
> the target.
> 
> So far I tried to do this in yocto with separate recipes: a
> firmware.bb and a mylinux.bb. In firmware.bb, I check out the firmware
> via git and let it run "make" on native (this is necessary, since the
> Makefile builds a tool which then automatically gets called inside the
> Makefile to create the firmware blob).
> 
> In the kernel recipe, I declare a DEPEND on firmware.bb. I set the
> .config options to load an extra firmware blob. But now, I have a
> problem: I need actually to have the firmware blob within the kernel's
> file hierarchy. Ideally I would copy/move it from the firmware's
> destination directory into the kernel's source directory.

Shouldn't firmware go into /lib/firmware?
 
> Questions:
> How can I achieve this kind of setup working out with yocto or
> bitbake, respectively? What might be the best approach in my situation?

You can get the kernel version name from ${STAGING_KERNEL_DIR}/kernel-
abiversion if that helps, but I wouldn't have thought you'd need it if the 
firmware is installed to /lib/firmware instead.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: how to build external firmware for kernel

[lothar]

Zitat von Paul Eggleton <paul.eggleton@linux.intel.com>:

> Hi Lothar,
>
> On Monday 05 August 2013 11:42:22 lothar@denx.de wrote:
>> I have a linux kernel and a external firmware. Building manually,
>> first I have to checkout and build the firmware "native" to obtain a
>> firmware blob, then I need this firmware blob to build the kernel for
>> the target.
>>
>> So far I tried to do this in yocto with separate recipes: a
>> firmware.bb and a mylinux.bb. In firmware.bb, I check out the firmware
>> via git and let it run "make" on native (this is necessary, since the
>> Makefile builds a tool which then automatically gets called inside the
>> Makefile to create the firmware blob).
>>
>> In the kernel recipe, I declare a DEPEND on firmware.bb. I set the
>> .config options to load an extra firmware blob. But now, I have a
>> problem: I need actually to have the firmware blob within the kernel's
>> file hierarchy. Ideally I would copy/move it from the firmware's
>> destination directory into the kernel's source directory.
>
> Shouldn't firmware go into /lib/firmware?

Hi Paul, yes, so my first approach was indeed in the firmware.bb  
something like:
     install -d ${D}/lib/firmware/imx/sdma/
     install -m 755 sdma-imx53.bin ${D}/lib/firmware/imx/sdma/sdma-imx53.bin
...and to set in the kernel.bb (I'm aware of the existens of other  
ways to set .config using yocto)
     echo 'CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx53.bin"' >>  
${WORKDIR}/defconfig

But, compiling I got something as follows:
(...)
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8 uImage CC=arm-linux-gnueabi-gcc   
-mno-thumb-interwork -marm LD=arm-linux-gnueabi-ld   LOADADDR=0x70008000
| scripts/kconfig/conf --silentoldconfig Kconfig
|   CHK     include/generated/uapi/linux/version.h
|   CHK     include/generated/utsrelease.h
| make[1]: `include/generated/mach-types.h' is up to date.
|   CC      scripts/mod/devicetable-offsets.s
|   CALL    scripts/checksyscalls.sh
|   GEN     scripts/mod/devicetable-offsets.h
|   HOSTCC  scripts/mod/file2alias.o
|   HOSTLD  scripts/mod/modpost
|   CHK     include/generated/compile.h
| make[1]: *** No rule to make target  
`/lib/firmware/imx/sdma/sdma-imx53.bin', needed by  
`firmware/imx/sdma/sdma-imx53.bin.gen.o'.  Stop.
| make[1]: *** Waiting for unfinished jobs....
|   MK_FW   firmware/imx/sdma/sdma-imx53.bin.gen.S
| make: *** [firmware] Error 2
| make: *** Waiting for unfinished jobs....
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see  
/work/lothar/BUILD__XXX__m53evk/tmp/work/m53evk-linux-gnueabi(...)

Honestly, I already expected some trouble, because of firmware.bb  
being built for "native", and the kernel not. I sort of played around  
with CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR without  
success.

I also tried to build it manually by the approach specified here:
https://community.freescale.com/thread/302880
...means, just copying the firmware blob into the kernel source's  
"firmware" folder and running make afterwards. Since this worked just  
perfectly, I thought of doing it like this, since it seemed easier  
than messing with /lib/firmware and yocto/bitbake. But with this  
approach I'm stuck at getting the firmware blob into the firmware  
folder.

Can you please tell me, is this the wrong approach?



>> Questions:
>> How can I achieve this kind of setup working out with yocto or
>> bitbake, respectively? What might be the best approach in my situation?
>
> You can get the kernel version name from ${STAGING_KERNEL_DIR}/kernel-
> abiversion if that helps, but I wouldn't have thought you'd need it if the
> firmware is installed to /lib/firmware instead.

How may I work with the STAGING_KERNEL_DIR, since I first run the  
firmware.bb and then the kernel.bb. I think I did not understand well,  
how I may achieve this. Do I need to install the firmware blob into  
something like $STAGING_KERNEL_DIR/firmware? How may I proceed here,  
could you please explain a bit more?

Re: how to build external firmware for kernel

[Paul Eggleton]

On Monday 05 August 2013 14:41:04 lothar@denx.de wrote:
> How may I work with the STAGING_KERNEL_DIR, since I first run the
> firmware.bb and then the kernel.bb. I think I did not understand well,
> how I may achieve this. Do I need to install the firmware blob into
> something like $STAGING_KERNEL_DIR/firmware? How may I proceed here,
> could you please explain a bit more?

Sorry, I misunderstood your original explanation - in that case you cannot use 
STAGING_KERNEL_DIR because it will only exist after the kernel has been built.

It seems a bit odd that you'd need to build the firmware first and then use that 
as an input to the kernel build - is it baking the firmware into the module 
instead of loading the firmware at runtime like most other drivers?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: how to build external firmware for kernel

[lothar]

Zitat von Paul Eggleton <paul.eggleton@linux.intel.com>:

> On Monday 05 August 2013 14:41:04 lothar@denx.de wrote:
>> How may I work with the STAGING_KERNEL_DIR, since I first run the
>> firmware.bb and then the kernel.bb. I think I did not understand well,
>> how I may achieve this. Do I need to install the firmware blob into
>> something like $STAGING_KERNEL_DIR/firmware? How may I proceed here,
>> could you please explain a bit more?
>
> Sorry, I misunderstood your original explanation - in that case you  
> cannot use
> STAGING_KERNEL_DIR because it will only exist after the kernel has  
> been built.
>
> It seems a bit odd that you'd need to build the firmware first and  
> then use that
> as an input to the kernel build - is it baking the firmware into the module
> instead of loading the firmware at runtime like most other drivers?
>
> Cheers,
> Paul
>
> --

Hi Paul,

I appologize, probably I did not explain it very well.

So, in brief, I need to perform these steps in the following order:
1) check out firmware source via git
2) call "make" (builds a firmware generator tool (native), AND then  
calls it automatically right away to generate the firmware blob still  
in the same "make" call)
3) place the firmware blob somewhere, where the kernel('s recipe) can  
access it
4) check out kernel source
5) configure kernel source, and set the firmware blob
6) compile the kernel

So it's not a kernel module that has to be compiled after having the  
kernel source. It needs to be compiled before the kernel, the kernel  
needs its binary as EXTRA_FIRMWARE.

Can you help me, how to perform this? Perhaps /usr/firmware works, but  
as I already mentioned I had just problems with it, that's why I  
thought it's easier to pass the binary somehow directly.. Perhaps  
another approach would be not to have a separate recipes, but to do  
step 1-3 within the kernel .bb file, but this has to be done by the  
native toolchain, while the kernel should not use the native toolchain  
of course.. Any ideas?

BR,
L

Re: how to build external firmware for kernel

[lothar]

Am 2013-08-05 16:38, schrieb Paul Eggleton:
> On Monday 05 August 2013 14:41:04 lothar@denx.de wrote:
>> How may I work with the STAGING_KERNEL_DIR, since I first run the
>> firmware.bb and then the kernel.bb. I think I did not understand well,
>> how I may achieve this. Do I need to install the firmware blob into
>> something like $STAGING_KERNEL_DIR/firmware? How may I proceed here,
>> could you please explain a bit more?
> 
> Sorry, I misunderstood your original explanation - in that case you 
> cannot use
> STAGING_KERNEL_DIR because it will only exist after the kernel has been 
> built.
> 
> It seems a bit odd that you'd need to build the firmware first and
> then use that
> as an input to the kernel build - is it baking the firmware into the 
> module
> instead of loading the firmware at runtime like most other drivers?
> 
> Cheers,
> Paul

Hi,

I think I found a solution to my issue myself, at least it works out. I 
don't
know if it is nice.

Rethinking about the problem, and playing around with the information of 
the
answer Paul gave me I did the following modifications.


## in firmware.bb now I do the following
(...)
do_install(){
     install -d ${base_libdir}/firmware/imx/sdma || die "something wrong 
with firmware path"
     install -m 755 sdma-imx53.bin 
${base_libdir}/firmware/imx/sdma/sdma-imx53.bin
}


## in kernel.bb
(...)
DEPENDS = "firmware-native"
do_configure_prepend(){
     ## set option to use the firmware
     echo 'CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx53.bin"' >> 
${WORKDIR}/defconfig

     ## fetch the firmware blob
     cp -arv ${STAGING_DIR_NATIVE}/lib/firmware/imx ${S}/firmware/ || die 
"no sdma-firmware found"
}

then the kernel compilation works just perfectly

BR,
L