Difference between revisions of "Building a kernel from Buffalos source"

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search
(How to make)
(Building the kernel itself)
Line 9: Line 9:
 
2009.12.30: Succeeded to build the kernel using this .config http://downloads.buffalo.nas-central.org/Users/kenatonline/config.gz.
 
2009.12.30: Succeeded to build the kernel using this .config http://downloads.buffalo.nas-central.org/Users/kenatonline/config.gz.
  
I had to edit some files, because the original source from buffalo was not error free (to be gentle).
+
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.
 +
 
 +
I had to edit some more files, because the original source from buffalo was not error free (to be gentle).
  
 
=== Real errors ===
 
=== Real errors ===

Revision as of 14:29, 31 December 2009

Contents

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.

I had to edit some more files, because the original source from buffalo was not error free (to be gentle).

Real errors

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.

arch/arm/kernel/process.c:

 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:

 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.

driver/md/md.c:

 #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

arch/arm/plat-feroceon-kw/mv_hal/buffalo/buffalocore.c:

 void egiga_buffalo_change_configuration(unsigned short mode);
 int mvBoardNameGet(char *pNameBuff);
 unsigned int mvBoardIdGet(void);

arch/arm/plat-feroceon-kw/mv_hal/buffalo/BuffaloGpio.c:

 void buffalo_link_led_off(unsigned int ethPortNum);
 void buffalo_link_led_on(unsigned int ethPortNum);

arch/arm/plat-feroceon-kw/mv_hal/buffalo/BuffaloGpioDriver.c:

 void bfSetMagicKey(unsigned int key);
 unsigned int bfGetMagicKey(void);

arch/arm/plat-feroceon-kw/mv_hal/buffalo/BuffaloUart.c:

 unsigned int mvBoardTclkGet(void);

Missing includes

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.

arch/arm/plat-feroceon-kw/mv_hal/cesa/aes_dev.c:

 #include "ctrlEnv/sys/mvSysCesa.h"
 status = mvCesaInit(numOfSessions, queueDepth, pSram, NULL);

How to make

Making the kernel itself:

 make uImage

Making the modules:

 make 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. This is a real challenge and not yet finished.