Buffalo Linkstation Live V3 (LS-XL V3) Kernel Source (3.13-7)

Hi guys and gals,

I recently got ahold of two Buffalo Linkstation Live V3 devices.
These are based on Marvell Kirkwood 88F6192 SOCs, have 64MB DDR2 RAM, a Gigabit Ethernet port and one single SATA connector. No additional USB, or other nice things. :-) Just the amount of hardware to make data available on one's network, and nothing more.

After having tinkered with these little Gizmos for the last few days, I came up with kernel support for Mainline Kernel 3.13-7. Actually I used the Debian Sources, from Debian Unstable.

The 3.13-7 sources are available here:
https://github.com/ingmar-k/Buffalo-Linkstation-Kirkwood-Kernel

Seems to work just fine. I had "upgraded" my two devices by soldering a 128MB Samsung SLC NAND to each unit. This way they now run with Emdebian testing in NAND (ubifs).


Here are some hints that you need, in order to get Debian to run with this Kernel:

- Stock UBoot is 1.1.4
- A LOT OF Uboot's environment settings were made permanent by Buffalo (i.e. you can only temporarily change them)
- The bootcommands are part of those hardcoded commands. So, I found no way to change the automatic boot behaviour!
- You need to set the variable "mainlineLinux" to "yes" in order to run this new kernel. (setenv mainlineLinux yes) With the stock settings you can only boot non-Mainline Linux kernels like built from the older Sources provided by Marvell/Buffalo!!!
- Due to bootargs being static, you need to hardcode the bootargs into the Kernel !!! In other words, you tell the kernel to just ignore the bootloader atags, and just use the compiled in commandline.

With menuconfig, just head to "Boot options --->", change "CONFIG_CMDLINE" and finally set "CONFIG_CMDLINE_FORCE".

- BE SURE to check the kernel commandline and edit it, according to your needs.
- The boot process tries to load the kernel "uImage.buffalo" and an initrd "initrd.buffalo" from HDD, then from NAND and finally from TFTP, if neither of the previous was successful.
- If you want to use a kernel without an initrd, just create a "dummy" initrd and let it load that. I use nandboot with a initrd dummy and a small 3MB JFFS2 formatted partition in NAND, where kernel and dummy initrd reside.
- There is full control over the blue power led through "/sys/class/leds/...".
- You can completely shut down the SATA port's power by using "/sys/class/gpio/gpio14/value". Echo a "0" there and the port will be powered down.


You can use a tftp server for kernel testing:
- setenv serverip 'my_servers_ip'
- setenv gatewayip 'my_gateways_ip'
- setenv ipaddr 'my_imaginary_ip_for_this_thing'
- setenv test_uImage 'tftp 0x00100000 uImage; bootm 0x00100000;'
- By running 'run test_uImage', you can now quickly test newly comiled uImages, directly from your tftp-server.



Howto create a "dummy" initrd file:

echo "This is a dummy initrd file" > dummy_initrd.txt
mkdir initrd
cd initrd/
cp ../dummy_initrd.txt .
find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../new-initrd.lz
ls ../
mkimage -A arm -O linux -T ramdisk -a 0x00000000 -n "Dummy ramdisk" -C lzma -d new-initrd.lz initrd.buffalo

Pictures of the PCB, and the UART0 connection for serial console, can be found here:
http://www.hs-augsburg.de/~ingmar_k/Buffalo_LS-XL/pictures/


Have fun!

Regards

Ingmar



Edited 4 time(s). Last edit at 04/30/2014 03:23PM by ingmar_k.

And before I forget:
With my NAND Device (Samsung K9F1G08U0x), I had to solder a wire from the NANDs WP/-Pin to VCC, in order to completely disable WriteProtection. Otherwise the NAND writes would fail sporadically. Strange, but now it works.



Edited 2 time(s). Last edit at 04/08/2014 07:26AM by ingmar_k.

Wow! that was very informative. And professional soldering job in addition to all these mods, too. Thanks ingmar_k.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

You are very welcome!
I hope the information will help some people.
About the soldering: Well, it actually could have been better. Partly at least. I didn't do any soldering for a long time before that. I was a bit out of practice, but it all worked. So it's fine.
Looks like it could finally start to pay out to be a computer engineer and soon to be master of computer science. :-D

My conclusion is actually pretty positive. The whole act of modding the devices and getting the kernel patched was very informative for me, too. I never added a new machine to kernel sources before. So that was a really pleasant experience, when it finally worked. You learn somethng new every day.
I now seem to understand how new kirkwood devices can be added to the kernel sources. And I actually think that I understand how the "mpp"-magic works. That was a bit strange at first.
I found that if there is some "old" GPL source available for your device, it should be possible to add it to the new kernel sources pretty (=relatively) quickly, as Kirkwood support is really good, today.

Congratulation! and your knowledge is so much more than regular computer engineers out there (speaking from real life experience :)

Quote

I found that if there is some "old" GPL source available for your device, it should be possible to add it to the new kernel sources pretty (=relatively) quickly, as Kirkwood support is really good, today

Agreed, all it would take is a setup.c file which can be based from other devices source code, trivially modified Makefile & Kconfig, and possibly slightly modified mpp.h (this would be more dangerous if needed). And of course, with a lot of perseverance :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/08/2014 06:40PM by bodhi.

Question:

Quote

You can completely shut down the SATA port's power by using "/sys/class/gpio/gpio14/value". Echo a "0" there and the port will be powered down.

So later when needed you would power on by echoing a "1" to this gpio pin?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Exactly!
I found that there seem to be other implementations that define a gpio switch like that, as a "regulator". At least I saw some dts files where it was done like that.

The NSA32x series use GPIO's like this for USB & SATA[2] power.

ingmar_k,

So after you've decided to solder additional NANDs, how did you determine that is possible, and buy a maching NAND (ie. Samsung SLC) ?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@WarheadsSE:
Thanks for the hint. I will have a look at that.

@bodhi,
I had seen that the installed U-Boot had nand functions and just guessed that there could be another product model with NAND, i.e. NAND should work.
I already had some NAND chips here, that I had desoldered with a hot air soldering station (from old USB flash drives, old IDE DOMs etc.).
And I just picked a Samsung SLC 128MB chip and gave it a try. Mere trial and error.

Oh, BTW, concerning the "great" :-D soldering job:
If you look closely at the follwoing picture you will notice some missing solder pads (top row, brown in color).
http://www.hs-augsburg.de/~ingmar_k/Buffalo_LS-XL/pictures/Buffalo_LS_XL_V3_back_with_NAND.jpg
That is because a lot of them on TSOP NAND are NC, and as such get removed really easily. They are not held in place by anything in particular and tend to just get stuck to the solder wick, if heat is applied a little too long. Luckily that doesn't matter at all, because afterall they are NC. :-D But from a professional point of view that shouldn't happen.



Edited 1 time(s). Last edit at 04/10/2014 02:41AM by ingmar_k.