It's been one year since I published a compiled kernel for our devices. Now I decided to build a new one and share it!
Some facts about it:
- As all of my other kernels this one uses heartbeat during boot.
- It supports the dockstar, goflex net and home.
- Some of you asked for I2C support, it's now working on the dockstar and goflex net. i2cdetect -l has the desired output!
If you encounter any missing modules for certain devices, try to compile them yourself with the given headers and give me a hint so I can include them in feature releases.
In order to install the kernel properly, you need to have initramfs-tools installed. Otherwise your device won't be able to boot! Thanks to chessplayer for sharing this info!
apt-get install initramfs-tools
Make sure you have the latest uboot installed. See 1. in Dockstar: new Kernel 3.3.3 ready to use.
Did you want to reboot your Dockstar or Golfex with multiple drives attached? Well, that's not the problem if uboot lists the devices in the correct order.
But what if your Golfex has SATA drives attached and you want to boot from an usb-drive?
The answer my Goflex gives me all the time: Loading kernel from usb works. Starting the kernel also works. But mounting the filesystem fails, because the device names are remapped when the SATA drives are initialized. The usb-drive ain't /dev/sda anymore...
I (have) had one rule since I had to drive more than 100 kilometers to fix that: never reboot remotely with SATA attached.
The solution is quite simple:
We have to tell the kernel properly where to get the rootfs from to mount it. To be versatile, uboot is configured to boot the kernel with device names as parameter, such as /dev/sda1. But I know what I am doing and want to boot from one single device, no matter if other drives are attached or not, which could mess the device names. So the disk LABEL or the Universally Unique Identifier (UUID) is what we need.
You might say: Ha! I adapt fstab. But this doesn't do the trick.
We need to alter the uboot bootargs. You have to decide which method is more suitable for your environment.
It's now been a while since I installed the 3.1.0-1 kernel from sid and made some testing. But I don't like the LED beeing solid green during boot, I want to see whats going on. Thats why I decided to compile 3.1.10 with heartbeat from this erlier article: Dockstar: new Kernel 2.6.38 ready to use. The config is based on sid's 3.1.0-1, if you want to take a look at it, you will find it here: config-3.1.10-dockstar-shyd_1.2
It supports several devices like wifi, webcam, audio or dvb.
Some of you might ask why I didn't build 3.2.1. I did, but it wouldn't boot.
Normally you should be able to manage the dockstar over the ethernet, but what if you can't establish no connection because you did something wrong? There is a serial connector inside the device we can use for debugging and other things.
1. Required: USB to TTL bridge
Some weeks ago I ordered an USB to TTL UART bridge on eBay, just to have it if I will need it. You also can buy it on amazon: USB2.0 an TTL UART 6pin Konverter seriell CP2102 ID9372 PAUB022
Here are some technical specifications of the one I bought:
All handshaking and modem interface signals Data formats supported: 8-bit; 1 Stop bit Parity: Odd, Even, No Parity Baud rates: 300 bps to 921.6 kbps 512 byte receive buffer; 512 byte transmit buffer Hardware X-On/X-Off handshaking Event character support 6 Pins: 3.3V, RST, TxD, RxD, GND, 5V
When I was trying to find proper kernel configs for the dockstar, I had to try several builds. Everytime my kernel didn't boot I had to revert the arcNumber and install a working kernel again.
There are two ways to test a kernel:
- Grab another USB stick, make a backup and try the kernel on this backup. If you always do a new backup before testing another build, it will take a long time.
- Test the kernel on the running system (or a backup-stick) and reinstall another kernel in case yours wont boot. In difference to 1. you do this in a chrooted jail.
I want to explain how you do the chroot thing with some lines.
Some days ago I wanted to test the performance of a partition with XFS as its filesystem. But I wasn't able to mount it. After a look into the kernelconfig of gorgone's heavykernel I noticed that he obviously didn't build it with XFS-support.
I do want to make the test and take a look at kernelbuilding things anyway. Well, I don't want to keep it back, so I decided to verbalize the steps I took.
In this guide you will learn how to set up the crosscompile toolchain to let a more powerful CPU do the job. If you prefer doing the whole thing on the dockstar it will take you several hours.
Further more we will go through the build process until we have a deb-file with the built kernel.