There are 4 variants (the tar archives contain uImage and all modules and config files)kernel-2.6.16.57-lsp_eabi-dh_v1.tar.gz kernel-2.6.16.57-lsp_oabi-dh_v1.tar.gzkernel-2.6.16.57-lsp_eabi-dh_v2.tar.gz kernel-2.6.16.57-lsp-oabi-dh_v2.tar.gz

(just unpack the tar archive in the / directory, then go to /boot, move uImage.buffalo to (say) uImage.old, and make uImage.buffalo a symbolic link to the new uImage file; see the README-2.6.16.57-lsp_xabi-dh_vx file)

v1: ext3 and xfs file systems have ACL and security label supportv2: ext3 and xfs support is compiled exactly as in the stock buffalo kernels.

the config is based on 1.10 Buffalo Linkstation kernels, with lots of extra modules for usb and serial devices (these can be attached with a usb-to-serial cable), as well as modules for other filesystem types.

see README-2.6.16.57-lsp_xabi-dh_vx

For rebuilders, the patch to the buffalo GPL source that updates 2.6.16.16 to 2.6.16.57, and a native arm OABI mkimage executable are also posted. The patch adds squashfs support too.

Thanks to dmik for hosting these while ftp uploads at nas-central are not working.

These LinkStation Live/Pro kernels also work on a Kurobox Pro, but don't support its extra features.

Which format, EABI or OABI to use? With Freelink (debian-arm)there is no advantage (and there are disadvantages) in using an EABI kernel (with OABI legacy support), except that Buffalo kernels are EABI, and may have better-tested ext3 and xfs filesystem support. With a debian-armel distribution (SID, not stable), use EABI kernels.

Last edited by duncan_h on Sat Jan 26, 2008 6:01 pm, edited 7 times in total.

Serial port access is real useful for testing kernels. The v2 LinkStations have a nice little socket on the bottom of the box which accepts a modified USB type-A female plug. This make it easy to gain serial port access to u-boot on v2 LinkStations, so you can select which kernel to boot during the booting process (that makes it easy to recover from bad test kernels). Otherwise you need to mount the drive with the /boot partition on a linux PC to put back a working uImage.

Unfortunately, the Terastation in the pictures http://buffalo.nas-central.org/index.php/Disassemble_the_TSPROv2/TSLIVE seems only to have some place on the mainboard marked for soldering serial cable leads, but no nice external socket. You probably need to solder leads to the TS mainboard to get serial port access. You then connect to a PC using a FTDI (USD20) USB-TTL adapter cable. (or a hacked cell-phone data cable if you can find the right one). (Personally, I am scared to use a soldering iron on my mainboard, in case I mess it up.)

EDIT: the place for attaching (soldering) the serial cable leads is accessible by just removing the TS side panel

I believe that the drives on the TeraStation are designed to be easily swappable, so maybe all you need is a usb-to-SATA cable and power supply ( you can get this for USD 15 or so), and just remove the drive when you need to. I would not play about with untested kernels until you have verified that you can access /boot on a non-bootable TeraStation to fix it. (It's just a question of making /boot/uImage.buffalo a symbolic link to a working uImage.) If you have serial port access, you can interrupt the booting process to specify the kernel uImage you want to u-boot to use, and use a different one than the default one (u-boot is the equivalent of grub on a i386 PC)

If you want to try to compile TeraStation kernels, I would start by checking that you can recreate the Stock Buffalo one (they supplied their config files) and can install it, etc.

Don't try patching the source from linux 2.6.16.16 to linux 2.6.16.57 at first, as there are significant fixes to the RAID code in the kernel sources in drivers/md/ (multi-device support), and lots of that code is patched by Buffalo. That's not an issue for the Linkstation, which does not use it, but is for the TeraStation. Just try adding extra module support for features you need. That way you are just adding stubs for the new modules to the kernel image (which must not grow to be larger than 1.9MB) The process is easy once you have learned to sucessfully recompile the standard Buffalo kernel.

Unless you want iptables or ALSA usb sound card support, use the same 2005q3 cross-compiling toolchain that Buffalo uses (available here), and do all the compiling on a linux pc. (this builds EABI kernels with legacy OABI support for debian-arm (i.e., FreeLink)).

PM me if you need any specific tips to get started. I found a few minor difficulties in the way, but managed to work it out. I'm assuming you have a PC that can run linux.

If you really want me to, I could compile a Terastation kernel for you, but its not really difficult at all

Last edited by duncan_h on Fri Jan 25, 2008 7:27 pm, edited 1 time in total.

hi!i would like to test the new kernels from duncan_h as well.but i can't download anything from ftp://ftp.dmik.org/incoming/i'am getting strange errors like "550 can't change directory to /incoming/kernel...." with firefox.can you plz take a look at it?greetzawx

hi!i would like to test the new kernels from duncan_h as well.but i can't download anything from ftp://ftp.dmik.org/incoming/i'am getting strange errors like "550 can't change directory to /incoming/kernel...." with firefox.can you plz take a look at it?greetzawx

Same prolem here~~~

I used FTP to try

Code:

ftp> mget *200 TYPE is now ASCIImget README-2.6.16.57-lsp_xabi-dh_vx? y200 PORT command successful550-This file has been uploaded by an anonymous user. It has not550 yet been approved for downloading by the site administrators.

Local directory now D:\.ftp> mget *200 TYPE is now 8-bit binarymget README-2.6.16.57-lsp_xabi-dh_vx? y200 PORT command successful550-This file has been uploaded by an anonymous user. It has not550 yet been approved for downloading by the site administrators.

great!the kernel files in "kernel-2.6.16.57-lsp_oabi-dh_v2.tar.gz" bricked my LSProchanging back the kernel with the drive attached to another linux box didn't work this time.the drive is now stuck in em-mode. any suggestions?awx

mount the LSPRO's /boot partition and post what ls -l reports is init.

(Maybe also mount the root partition and ls-l in etc/)

Relax: you *cannot* badly "brick" your LSPRO by changing the kernel if you are able to mount the drive on a PC to fix it. The only way to really brick the LSPRO is to destroy the u-boot bootloader image in flash memory.

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum