Building a kernel from Buffalos source
- 1 How to build a custom kernel from Buffalos source
How to build a custom kernel from Buffalos source
This is an ongoing task. I will report my success as a step-by-step guide to build a kernel from the GPL sources Buffalo provided here http://opensource.buffalo.jp/gpl_storage.html .
This will not be a guide for noobs having no Linux background at all, because one has to know what to do if problems arise (during compilation as well as when testing the kernel). If you do not know now what JTAG and OpenOCD is, you are a noob as meant before. ;-)
Building the kernel itself
2009.12.30: Succeeded to build the kernel using this .config http://downloads.buffalo.nas-central.org/Users/kenatonline/config.gz.
Buffalo used the codesourcery toolchain arm-2007q1 (as you can see in dmesg on a box with stock kernel) although the provided Makefile still points to arm-2005q3. Lets hope that they did not change something else in their makefile which they did not provide to us. Does the makefile belongs to the files one has to provide if he changes GPL code?
If you want to use the same toolchain Buffalo used, change "CROSS_COMPILE" to "arm-none-eabi-" in the Makefile. Btw. why made Buffalo this variable not conditional ("?=" instead of "=")? At least it is another sign that this makefile is not the one Buffalo uses itself.
If you want to use the Optware GCC to compile the kernel right on the LS-XHL itself, you have to add the path to the GCC includes to the variable LINUXINCLUDE in Makefile:
I had to edit some more files, because the original source from buffalo was not error free (to be gentle).
How could it be, that Buffalo provides sources which fail to build due to beginners bugs (missing forward declaration resp. using of a function before implementing it)? Also warnings about implicit declaration of a function should ring some bells, because it is a sign of a missing include. Please excuse that I was too lazy to solve this by determining the "correct" include statements. I used "correct" forward declarations instead.
void BuffaloChangePowerStatusBeforeHalt(void); void BuffaloGpio_CpuReset(void); void bfSetMagicKey(unsigned int key); unsigned int bfGetMagicKey(void);
This wrong coding is my favourite, because of missing function call brackets, which is a typical beginners bug. Due to dependency problems, I did not solve the bug, but accepted the outcome. It "just" causes no output at the serial console if the output is done via strput.
include/asm/arch/uncompress.h:34: warning: the address of `bfIsSerialConsoleEnable', will always evaluate as `true'
Missing includes solved by correct forward declaration
Noone should ignore warnings like the ones one get compiling the Buffalo source (even not Buffalo itself). Please excuse that I was too lazy to solve this by determining the "correct" include statements. I used "correct" forward declarations instead.
#ifdef CONFIG_BUFFALO_PLATFORM void kernevnt_RadiDegraded(int devno, int major, int minor); void kernevnt_RadiRecovery(int devno, int on, int isRecovery, int major, int minor); void kernevnt_RadiScan(int devno, int on); #endif
void egiga_buffalo_change_configuration(unsigned short mode); int mvBoardNameGet(char *pNameBuff); unsigned int mvBoardIdGet(void);
void buffalo_link_led_off(unsigned int ethPortNum); void buffalo_link_led_on(unsigned int ethPortNum);
void bfSetMagicKey(unsigned int key); unsigned int bfGetMagicKey(void);
unsigned int mvBoardTclkGet(void);
The following missing include will cause a call to the wrong version of the function. The "correct" include causes then an error instead of a warning, which can be solved by changing the affected line like below.
status = mvCesaInit(numOfSessions, queueDepth, pSram, NULL);
How to make
Making the kernel itself:
Making the modules:
Make the directory and deploy the modules files:
make modules_install INSTALL_MOD_PATH=/tmp/MyModules
Now you can find the kernel (uImage) at arch/arm/boot and the modules at /tmp/MyModules.
This kernel is running well and I have not discovered any problems yet.
Building the nfs-utils
Because I want to have NFS also, I had to build the nfs-utils as well, because the nfs-utils are marked "broken" in the optware feed for the LS-XHL.
I took the source nfs-utils-1.2.1 and tried to do a "configure". Unfortunately it failed due to missing libraries.
I had to compile the following libraries for a successful configure:
librpcsecgss-0.18 libnfsidmap-0.23 krb5-1.7 ncurses-5.6 tcp_wrappers_7.6-ipv6.4
Unfortunately I did not manage to compile libtirpc-0.2.1 and therefore decided to disable tirpc for nfs-utils.
Last but not least, I created start scripts for bootup.
What is left to do?
Of course you have to configure your NFS.
Because I often answer questions regarding configuration of NFS in the forum, I wrote this little guide NFS for Beginners.
You want to have a NFS enabled kernel but do not want to build it yourself?
There is a ready-to-use kernel available: Ready-to-use NFS kernel.
01.01.2010: Success! I now do have a LS-XHL running my custom kernel serving as NFS server.
08.01.2010: Uptime is now 5 days. No problems at all so far.
19.01.2010: Uptime is now 16 days. 317 GB stored, twice as much trasfered, load average 0,02%, still no problems.
I am looking for volunteers to test an ready-to-use installation of this kernel. If you are interested: http://forum.buffalo.nas-central.org/viewtopic.php?f=69&t=21338&p=134551#p134551
Or if you prefer german: http://forum.buffalo.nas-central.org/viewtopic.php?f=14&t=21347&p=134612#p134612
01.02.2010: Bukisch tested the installation on his LS-XHL. You can find an installation guide here: Ready-to-use NFS kernel
05.02.2010: Uptime is now 33 days. No problems at all. Several TB transfered in the meantime.
16.02.2010: Uptime is now 44 days. Still no problems. For me, this kernel is now declared "stable".
10.04.2010: Uptime is now 97 days. Serving as TimeMaschine destination and as file storage for two Linux PVRs, handling up to six streams concurrently. NiugeS managed to install the kernel onto a LS-XHL running firmware 1.24.
11.02.2011: Uptime is now 404 days. Still no problems.