[yocto] Problem with own kernel recipe on Dora

Richard Purdie richard.purdie at linuxfoundation.org
Tue Apr 22 01:23:02 PDT 2014


On Tue, 2014-04-22 at 07:52 +0000, Richard Leitner - SKIDATA wrote:
> Hi Yocto-Community,
> as the subject already says I've a problem with my kernel recipe after the "migration" from the Dylan to the Dora (10.0.1) branch.
> I've tried the 10.0.1 release tag as well as the current dora master (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> 
> The kernel recipe I'm using is derived from the skeleton:
> DESCRIPTION = "Linux Kernel"
> SECTION = "kernel"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> inherit kernel
> KSRC = "/home/leri/VCS/git/linux"
> KBRANCH = "master"
> SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> SRCREV = "2014_03_07"
> PR = "sd_15.2"
> LINUX_VERSION = "${PV}"
> LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> KERNEL_IMAGETYPE = "uImage"
> SRC_URI += "file://defconfig"
> require recipes-kernel/linux/linux-yocto.inc
> 
> 
> This recipe was working well with the Dylan branch and following changes:
> -SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> +S = "${WORKDIR}/git"
> 
> 
> When compiled with the dora branch the kernel hangs at "Starting kernel..." and doesn't start:
> ## Booting kernel from Legacy Image at 00000000 ...
>    Image Name:   Linux-3.1.10-sd_15.2
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    3181616 Bytes = 3 MiB
>    Load Address: 00008000
>    Entry Point:  00008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 
> I've already looked through the migration notes in the manual but I'm unable to find any hints...
> Are there any ideas why the kernel doesn't start with the Dora branch?

We saw an issue recently on beaglebone that looked very like this. It
turned out the load address for the kernel was conflicting in memory
with the device tree binary.

It easily be something different but I thought I'd mention it.

Cheers,

Richard




More information about the yocto mailing list