Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: sbp on February 05, 2015, 02:12:29 AM
-
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: ./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
-
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.
-
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
-
RPi has a different bootloader then odrois. Beaglebone Black also boots fine with DT.
-
Couple of links
http://www.raspberrypi.org/documentation/configuration/device-tree.md
https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README
-
Hi
I don't know if you have seen it already, but it was suggested to try using ramfsaddr=-1 and this seems to have helped a lot. Now I don't get kernel panic anymore and it says that it is:
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
-
Addition
After updating to the latest firmware files from today It booted further and now the following is shown during booting:
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
I don't know if you have seen it already, but it was suggested to try using 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.
-
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
-
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 make dtbs and the dtbs will be in arch/arm/boot/dts directory.
-
Addition
After updating to the latest firmware files from today It booted further and now the following is shown during booting:
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
-
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.
-
Good news, RPi2 now boots piCore too and hangs at the same point as the RPi release.
-
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.
-
Nice, Can you please tell us what the problem was?
-
1) How to boot initrd, see ramfsaddr=-1
2) Stock kernel do not have compressed RAM, NOZSWAP in cmdline.txt needed (piCore kernel will fix it)
-
Hi Belá
So if I understand you correctly we need to add this to the /arch/arm/configs/bcmrpi_defconfig before we use it as .config for building piCore?
CONFIG_LOCALVERSION="-piCore+"
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
Steen
-
Steen
do not touch defconfig. Use .config only.
Béla
-
Sorry, probably wrong wording from my side - I'm not touching the defconfig directly.
What I have been told is to make a copy of defconfig and rename it to .config as defconfig contains the options the Raspberry foundation use to make their default kernel.
Then we have to modify/adapt this .config for making a piCore, so I was merely trying to make a list of needed changes that have to be set in order to produce a working .config for building piCore.
I know that we also remove some options that we don't need, but it could be handy to know what we at least need to add to the default raspberry config in order to start building a working piCore. Then we can always start removing unnecessary options from a booting piCore.
Steen
-
defconfig is not the same as the Raspbian config. On a clean system after defconfig you must work a lot to get a config you want. Even I experencied non-working system using a plain kernel after defconfig.
Better to start with a prooven config and make necessary changes. In case of 3.18.6 main changes on Raspbian kernel:
- configure squashfs and move to kernel
- enable compressed RAM and compressed swap
- enable USB/IP
- few smaller changes
Regards... Béla
-
What I have been told is to make a copy of defconfig and rename it to .config as defconfig contains the options the Raspberry foundation use to make their default kernel.
defconfig files typically only contain hardware related patches. It's always best to get a working config from the system you are trying to upgrade. On the odroid-c1 it has been a bit of a challenge, as they don't have the options turned on to put a copy of the config in the kernel /proc. But in the case of the odroid, it does appear they are pushing changes to the defconfig_odroidc, so I think I'm okay.
What I have been struggling with is doing things the tiny core way. Things like sound are built into the kernel by default, but If I make them modules, the kernel doesn't load. I think it has something to do with the way the dtb is expecting to find the driver.......but still learning the dtb concepts.
-
Now I'm solving the same issue. I need to add the new hardware support. The Rasbian build works fine and after applying mkknlimg loads all overlays correctly. Now I'm looking for the building modifications to get the TC kernel. Please share the tutorial for the TC build.