Community thread on building a Device tree enabled kernel

[sbp]

Hi

I have trouble with building a new working kernel based on 3.18.5 which introduced the device tree (and I know Belá also have some problems).
Therefore, I thought that we might share our experience and solutions that we find on our way. The hope is that this will help in our struggle to build a piCore with device tree enabled.

My first contribution:
I have noticed that a new step is introduced in the kernel building process. This step is needed in order to be able to boot a kernel with DT enabled: http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=98009
So you will need to download mkknlimg from https://github.com/raspberrypi/tools/blob/master/mkimage/mkknlimg 
and then use this command on your newly build Image or zImage:

Code: [Select]

./mkknlimg zImage kernel.img

This brought me a little closer, however it is still not booting correctly.

Please share your tips and tricks - and if you have a working recipe for building a working piCore, please share it.

Steen   

[bmarkus]

Main issue at the moment is not building a new kernel, as the stock Raspbian kernel can be used at the beginning and can be replaced with a piCore kernel later. The issue is how to boot our initrd with root=/dev/ram0 which doesn't work the same way as with non-DT kernels.

[Paul_123]

Main issue at the moment is not building a new kernel, as the stock Raspbian kernel can be used at the beginning and can be replaced with a piCore kernel later. The issue is how to boot our initrd with root=/dev/ram0 which doesn't work the same way as with non-DT kernels.

Why is that?  The odroid-c1 is using a DTB, and it boots just fine with root=/dev/ram0    But then the odroid is using uboot, it could be an rpi issue.

I wonder if this solution for uboot would work with the rpi.   http://xilinx.wikidot.com/ram-disk-issues-with-device-tree

https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/boot/dts/bcm2708.dtsi

[bmarkus]

RPi has a different bootloader then odrois. Beaglebone Black also boots fine with DT.

[Paul_123]

Couple of links

http://www.raspberrypi.org/documentation/configuration/device-tree.md

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

[sbp]

Hi

I don't know if you have seen it already, but it was suggested to try using 

Code: [Select]

ramfsaddr=-1  and this seems to have helped a lot. Now I don't get kernel panic anymore and it says that it is:

Code: [Select]

Booting Core 6.0alpha401
Running Linux Kernel 3.18.5-piCore+
Checking boot options... Done
Starting Udev daemon script for hotplug support.... Done
But then it hangs - so I must work a little more on the initrd - but we are a lot closer now

Steen

[sbp]

Addition

After updating to the latest firmware files from today It booted further and now the following is shown during booting:

Code: [Select]

Booting Core 6.0alpha401
Running Linux Kernel 3.18.5-piCore+
Checking boot options... Done
Starting Udev daemon script for hotplug support.... Done
modprobe: Can't change directory to '3.18.5+' : No such file or directory
modprobe: Can't change directory to '3.18.5+' : No such file or directory

_

So probably I have made a mistake when I made the initrd - I will have a look.
Steen

Edit:  I have no idea where the modprobe command comes from and why it is executed twice?
I thought that maybe the file /lib/modules/3.18.5-piCore+/kernel.tclocal in the initrd.gz was linking to a wrong directory but it seems to be linking to /usr/local/lib/modules/3.18.5-piCore+/kernel which I suppose is correct.
So can anybody see where the issue is?

[sodface]

Hi

I don't know if you have seen it already, but it was suggested to try using 

Code: [Select]

ramfsaddr=-1  and this seems to have helped a lot.

Just wondering if you removed initrd references from cmdline.txt?  They are not needed but I'm not sure if they would hurt or not if present.

[sbp]

Hi sodface

Yes I did remove the initrd reference from cmdline.txt before I booted (I also had tested it with a reference to initrd in place  - but the result was the same)

Steen

[Paul_123]

Edit:  I have no idea where the modprobe command comes from and why it is executed twice?
I thought that maybe the file /lib/modules/3.18.5-piCore+/kernel.tclocal in the initrd.gz was linking to a wrong directory but it seems to be linking to /usr/local/lib/modules/3.18.5-piCore+/kernel which I suppose is correct.
So can anybody see where the issue is?

Did you rebuild and replace the dtb's on the boot disk.   When building the kernel make sure you do

Code: [Select]

make dtbs  and the dtbs will be in arch/arm/boot/dts  directory.

[Greg Erskine]

Addition

After updating to the latest firmware files from today It booted further and now the following is shown during booting:

Code: [Select]

Booting Core 6.0alpha401
Running Linux Kernel 3.18.5-piCore+
Checking boot options... Done
Starting Udev daemon script for hotplug support.... Done
modprobe: Can't change directory to '3.18.5+' : No such file or directory
modprobe: Can't change directory to '3.18.5+' : No such file or directory

_

So probably I have made a mistake when I made the initrd - I will have a look.
Steen

Edit:  I have no idea where the modprobe command comes from and why it is executed twice?
I thought that maybe the file /lib/modules/3.18.5-piCore+/kernel.tclocal in the initrd.gz was linking to a wrong directory but it seems to be linking to /usr/local/lib/modules/3.18.5-piCore+/kernel which I suppose is correct.
So can anybody see where the issue is?

Hi Steen,

Why is it saying "Booting Core 6.0alpha401"? That seems wrong to me.

regards
Greg

[bmarkus]

I created a version for the original RPi using today's RPi firmware and stock kernel. With ramfsaddr=-1 it boots, but freezing at the

Starting udev daemon ...

It looks that booting issue is solved, it is another issu.

Will try RPi2 next.

[bmarkus]

Good news, RPi2 now boots piCore too and hangs at the same point as the RPi release.

[bmarkus]

Now piCore boots with the official 3.18.5+ kernel. I will upload the first alpha during the weekend for both RPi2 and the older RPi boards. Stay tuned.

[sbp]

Nice, Can you please tell us what the problem was?