[oe] generate a named kernel in ${DEPLOY_DIR_IMAGE}

[Frans Meulenbroeks]

2010/9/29 Andrea Adami <andrea.adami at gmail.com>:
> On Tue, Sep 28, 2010 at 6:54 PM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
>> Hi,
>>
>> As I needed to generate two different kernels for the same machine I
>> had some kind of problem (as emailed yesterday).
>> For now I've solved it as follows:
>>
>> I created a 2nd recipe (in an overlay):
>> linux-small_2.6.34.bb
>> this one essentially only requires linux_2.6.34.bb and sets S to the linux_${PN}
>> Then I can just add a dir linux-small and add the small defconfig in it.
>>
>> That way bitbake linux-small should give me the 2nd kernel.
>> And actually it builds the kernel but this one is also packaged in a
>> kernel-*.ipk.
>> I could have made two different machines, but that seemed somewhat
>> overkill, so in the end I decided to modify do_install_append in
>> linux.inc.
>>
>
> We solved same issues with linux-kexecboot.inc including linux.inc and
> redefining vars/tasks.
> In particular
> ...
> PACKAGES = ""
> PROVIDES = ""
> ...
> KERNEL_IMAGE_BASE_NAME = "${KERNEL_IMAGETYPE}-kexecboot-${PV}-${PR}-${MACHINE}"
> KERNEL_IMAGE_SYMLINK_NAME = "${KERNEL_IMAGETYPE}-kexecboot-${MACHINE}"
> ...
>
> do_populate_sysroot() {
> }
>
> do_install() {
> }
>
> python do_package() {
> }
>
> So we end having in e.g.
> /oe/build/tmp/deploy/glibc/images/c7x0
> zImage-2.6.26-r13-c7x0.bin                        1351824│Sep 25 04:37
> @zImage-c7x0.bin                                             26│Sep 25 04:38
> zImage-kexecboot-2.6.26-r20.0-c7x0.bin      1113112│Sep 25 04:40
> @zImage-kexecboot-c7x0.bin                             38│Sep 25 04:40
>
>
>
>> This function currently reads:
>>
>> do_install_append() {
>>        oe_runmake headers_install
>> INSTALL_HDR_PATH=${D}${exec_prefix}/src/linux-${KERNEL_VERSION}
>> ARCH=$ARCH
>> }
>>
>> And I just added a line:
>>    cp ${D}/boot/uImage ${DEPLOY_DIR_IMAGE}/uImage-${PN}
>
> I don't think patch is necessari, though you should use
> ${KERNEL_IMAGETYPE} and not uImage
>
>

Andrea,

Thanks for the info.
I was unaware of  ${KERNEL_IMAGETYPE}.
That definitely makes things more generic
And indeed the code could go into do_deploy instead of do_install.
Both work, but it is more appropriate in do_deploy than in do_install

Wrt  KERNEL_IMAGE_BASE_NAME and  KERNEL_IMAGE_SYMLINK_NAME: didn't
know about these either. They are not in the OE manual; searching for
it gave me an angstrom doc on it though. Guess the OE manual could use
a list of all vars and their purpose.
With them I can avoid the copy line, so this is a nice improvement.

Frans

PS: referring to Denys' message about multi-linux.inc: still haven't
tested it, but what isslightly nasty about it is that it does not
package, so I cannot easily include modules in an image
(as my kernels are from the same recipe the modules are compatible,
and it helps to be able to say in an image recipe that you want to add
kernel-module-xyz)