Latest kernel not working?

[keylevel]

I've updated the kernel recipe to use SRCREV = "e3a21fc997669aae744537bf69e123f88a5e69e2"

and the bootfiles to use SRCREV = "9308c7ed387e5422883753f7fb71a75506abd1f8"

However, this seems to give a kernel that doesn't boot. The compiled kernel.img is also about half the size of the image from raspberrypi/linux. Using the raspberrypi/linux image with the bootfiles from the above SRCREV works, as does using the "3fc65f9f291fb19cad434968a4a0f66ab749e637" kernel srcrev with the kernel recipe.

The later kernels just get the "four-colours" at boot, so the bootloader is failing to load the image.

[djwillis]

Hi,

The closed source bootloader has changed to load more traditional kernel images but the documentation on this is somewhat vague.

I have started looking into this and plan to switch over to a working set of boot files and normal kernel image but have not got it all working just yet.

Thanks,

John

[keylevel]

Hi John,

On 29 Jun 2012, at 23:21, David-John Willis wrote:

Hi,

The closed source bootloader has changed to load more traditional kernel images but the documentation on this is somewhat vague.

I have started looking into this and plan to switch over to a working set of boot files and normal kernel image but have not got it all working just yet.

From what I've seen, it's not that simple. I've updated to use the latest firmware and the latest kernel. The kernel fails to boot (four-colour screen).

However, kernels from a while back will work with the latest firmware, as will then github/bootc/linux 3.2 kernel (don't recall the branch, but it's easy to find). I've got a recipe for this kernel that's nearly ready to go out to my fork.

Chris Tapp

opensource@keylevel.com www.keylevel.com

[agherzan]

I will look into this. I will keep you guys posted.

[keylevel]

The 3.2 kernel (from github/bootc/linux) works as expected (with the latest firmware).

[agherzan]

@keylevel This is because you used the uncompressed version of the krenel image isn't it? You used the "Image" to boot from, am i right?

Anyway i managed to find the issue. Actually bootloader can't boot a zImage (or uImage - even if i didn't try to boot a uImage). It needs an uncompressed Image file. Patches are on the way.

Chris, would you please review the pull request that i'm talking about?

P.S: Patches will remove the need for the mangled kernel image version. Bootloader can boot a Image directly.

@g

[keylevel]

I've always used KERNEL_IMAGETYPE="zImage". The 3,2 kernel works, the early 3.1.9 images work, the latest ones I tried (not the last few, as I've had other things to do) don't.

I've not been using mangled images for a while now.

[agherzan]

You can boot zImage with rpi bootloader? Are you sure? Cause ALL distributions of rpi have uncompressed kernel Images.

[keylevel]

I use the image file from tmp/deploy/images.

At the moment I'm using zImage-3.2.21-rpi+r1+git-5b0ccb02927b9e1843cd2e1f68ca6025ee2741ef-r1-raspberrypi-20120704190800.bin (bootc/linux rpi-3.2.21 branch) with the firmware from the 2012-07-01.

I wonder if compression support isn't reliable - it may explain why some images fail?

[agherzan]

So it's true. zImages used to work. For me - NEVER been able to boot a zImage. And you should check the official distros. Have uncompressed images...

So i would go with uncompressed Images until this will be reliable.

[christianege]

I also can only boot uncompressed images on my rpi. If I use the compressed ones nothing happens. I was searching for a commit on the firmware regarding this feature but could not find any comments on that topic.

Somewhere on the rpi forum a guy reported a similar issue with compressed images but later he said it was a corrupted SD-Card. Maybe compressed images do not work on all SD-Cards? Yes it sounds silly...

[agherzan]

Indeed. Anyway until this will be fixed we will go with uncompressed Images. Patches are already sent. @keylevel @cybertux would you spend some time on that pull req? In this way we will have a bootable rpi out of the box.

[christianege]

I've fixed it locally like in this gist: https://gist.github.com/3049451 . I am a open embedded newbie so this solution was guided by grep ;-) But I'll download your pull request and check. If it is working. Btw. I also had to add the bcm2835-kernel-image to the IMAGE_BOOTLOADER variable in sdcard_image-rpi.bbclass otherwise no Image could be created.

[agherzan]

I don't understand that patch. There is no Image value for KERNEL_IMAGETYPE. Check kernel.bbclass.

[christianege]

Maybe I mixed up some stuff. I am not an OE guru. Looking at this commit https://github.com/djwillis/meta-raspberrypi/commit/4728e85ed190a8fff207fb7b79c4320640cc051b So I thought setting to Image should not harm.

[agherzan]

For start go and read / understand kernel.bbclass

[keylevel]

Well, the latest kernel "c47ee9d4a48c1f3cc53a54e096ca0f7a3961ed9f" also loads using zImage.

However, the zImage for "f679f0534867d64a3672108d73bed5d349728f73" fails to boot. Is the vmlinux in the work area the uncompressed copy of the image? If so, then that also fails to boot.

[agherzan]

You are tying to boot vmlinux?

[keylevel]

Sorry, what I meant was:

• kernel "c47ee9d4a48c1f3cc53a54e096ca0f7a3961ed9f" boots with "Image" and "zImage".
• kernel "f679f0534867d64a3672108d73bed5d349728f73" boots with "Image" but not with "zImage".

The only difference between these is the SRCREV in the kernel recipe.

[agherzan]

Are you sure about c47ee9d4a48c1f3cc53a54e096ca0f7a3961ed9f? I will check this tomorrow.

[agherzan]

"kernel "f679f0534867d64a3672108d73bed5d349728f73" boots with "Image" but not with "zImage"."

I finished c47ee9d4a48c1f3cc53a54e096ca0f7a3961ed9f kernel and doesn't boot.

@g

[keylevel]

I've just rebuilt "c47ee9d4a48c1f3cc53a54e096ca0f7a3961ed9f" as a zImage and it boots ok for me. Strange...

[agherzan]

With new patches the latest kernel is booting.

@g

[keylevel]

Support for kernel compression should be back in soon. See http://www.raspberrypi.org/phpBB3/viewtopic.php?f=71&t=10759&p=119797#p119797.

[agherzan]

Good to know. You can check and submit patch to go back to zimage as soon as this is fixed.

@g