Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch

Hello All:

This is my first post on here in a long while. So bear with me as I have to put up corresponding Readouts and such for you to look at.

I have a Buffalo Terastation III TS-X4.0TL/R5 (Sakura) and it has the latest Buffalo FW (1.71 at this writing....)

It's a 4 bay Sata II NAS drive, which I have upgraded to take 3 TB Hitachi Drives. (Hey It worked)

But what I REALLY want to do, is rip out the stock OS, and replace it with Debian.

I have a USB<->DB9 Serial cable, which will hook into the front of this sucker, but I have no idea how to use it.

I have been trying to follow KOLIOS' insructions for when he upgraded his Terasation DUO as it seems to be using the same board.

https://web.archive.org/web/20111013194749/http://www.kolios.dk:80/2009/09/07/howto-install-a-debian-from-scratch-on-a-buffalo-terastation-duo-2/

but when I get into chroot, and do the next instruction, everything fails.....and I have to go back into Windows and run TSUPDATER and put everything back into stock again.....and I'm just frustated. I've got 12 TB of HARD DRIVE SPACE I can't use right now, because the OS sucks, and I really want to run Debian on this sucker to get latest and greatest.

Honestly I think I should rip out the motherboard and the Sata Daughtercard and get a PI with a sata port, a 1 to 4 Sata port multiplier, and go on from there.....I don't know.

As is this is my first post, being a cry for help, or a rant, as you choose to interpret. I don't have anything else to post up, but I will soon.

Ok, that's my post for now, thank you again.

Kapt Blasto,

Your box does not seem to have supports anywhere to run Debian/Arch. So the first thing you should do is to get serial console working. And get the boot log, so we can see what SoC is used in this box.

If using Windows, use putty to connect. On Mac OSX use screen. On Linux use minicom/picocom.

> I have a USB<->DB9 Serial cable, which will hook

Not sure what this serial console look like.

Do you have a picture of the board you can post? Ususally on most boxes, the serial console must be connected to a serial header on the board. And we use a serial console module converter as discussed in this thread:

https://forum.doozan.com/read.php?8,13263

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

Hi Bodhi,

Thank for your reply. I can get the Pictures, as they are at (right now) http://www.yamasita.jp/linkstation/2010/01/100111_post_250.html

Here's the front of what I think my board is.http://www.yamasita.jp/linkstation/2010/01/100111_1l.jpg

And the Back: http://www.yamasita.jp/linkstation/2010/01/100111_3s.jpg

It is a MARVELL MV78100 Board (could be a 88f621 as a base? not sure....)

Boot log coming soon.

Kapt Blasto,

I could not tell where the serial header on the board (not a very good quality pic). Usually it has JP1 or JP2 marking.

There is a 4 solder-filled holes on the top right (a couple inches? from the right edge). That looks like serial pinout solder buttons. But those don't have any marking.

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

This any help?

http://buffalo.nas-central.org/wiki/Terastation_III_Serial_console

feas Wrote:
-------------------------------------------------------
> This any help?
>
> http://buffalo.nas-central.org/wiki/Terastation_III_Serial_console


The plot thicken :) if that is true for this box, there will be a lot of works ahead to install serial console.

OTOH, MV78100 means it is possible to get Debian running with my released rootfs, and tweak a few things in the DTS for specific HWs in it.

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

Hi Bodhi,

Well, IIRC, the latest Kernel has the Terastation _W_XL patch inside it already.... now, whether or not there is a way to make a DTB or FDT? I don't know.

It would be nice to just try dropping Jessie or Stretch straight into it, but....seeing as Buffalo is using a "crippled" version of Debian Lenny....it might just be better to start from there.....and work my way up TO jessie or stretch... you know Lenny =>Wheezy =>Jessie =>Stretch....

And then take a snapshot of everything as I go....
I dunno.....

I'm trying again with Kolios' instructions....this time I went into debian-archive to get Lenny seeing as that's close to what it's got on there, now....

The one problem I had so far, today?
Couldn't "cpio -i < ../initrd" in a deb_init directory on a 64-bit VirtualBox with Mint (even though that's what I am right now accessing the Buffalo through, so .....had to transfer the initrd.gz I got , into the buffalo first, and put it into a separate direcotry from "/root" there to do the cpio'ing.....and then continue the intructions...

Right now I am at the point where I throw the sucker into em mode.....

I'll give update to what happens from there, later.

Thank you again, so far....

Kapt Blasto,

> Well, IIRC, the latest Kernel has the Terastation
> _W_XL patch inside it already....

When you say "latest kernel" did you mean "latest stock kernel"?

> now, whether or
> not there is a way to make a DTB or FDT? I don't
> know.

Usually if you have a patch of older non-FDT kernel, then it could be used to translate it into a DTS.

But for this box, it is ARMv5 so I think you can boot with the Sheevaplug DTB, and see how far you will get. I would not start from Buffalo version of Lenny.

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

>But for this box, it is ARMv5 so I think you can boot with the Sheevaplug DTB, and see how far you will get. I would not start from Buffalo version of Lenny.

Ok, will try that way....thanks, Bodhi, will let u know.

Any progress on this? Wondering about doing this myself.

TS-XL(sakura)

Esteban Wrote:
-------------------------------------------------------
> TS-XL(sakura)

https://mizupc8.bio.mie-u.ac.jp/pukiwiki/index.php?LinkStation/TeraStation/%E7%8E%84%E7%AE%B1/ARM/TS-XL/kernel

Digging into this device is on my extended todo list (funny how the list keeps getting longer faster than it gets worked on)

There is code in the mainline kernel for this series of devices(specifically the 2 bay model I think). see here:
https://github.com/torvalds/linux/blob/master/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c

Quote
bodhi
But for this box, it is ARMv5 so I think you can boot with the Sheevaplug DTB, and see how far you will get

I may give this a try in the near-ish future. If I could get it to boot at all I can usually get from there to a full DTB pretty quickly and would gladly add this to my list of supported buffalo devices.

@bodhi
Do you know of any MV78100/MV78200 devices with working device trees I could work from?

1000001101000,

> @bodhi
> Do you know of any MV78100/MV78200 devices with
> working device trees I could work from?

That's Armada XP. In mainline, there are a few that based on MV78230.

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

My bad. Specifically the mv781xx

Ah. Then it is not Armada XP.

Those are dual-core dual-issue ARMv5TE Discovery.

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

Do you know if there are bindings for those devices or an example device tree I’m unaware of?

1000001101000,

By the way, I think this is a much bigger job then just writing DTS for it to run as FDT kernel. Looks like this SoC is still in pre-FDT infrastructure.

I don't know how familiar you are with arch setup code in the pre-FDT days? If you decide to bring it up, you might need to look for mach number and add new one if it is not already there. And add some new code for a specific flavor of the box that uses the SoC.

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

Please see above.

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

I beleive the code for the ts-wxl (the two bay version of this dev). Would probably work (assuming it still works). I’m pretty sure there is a mach number for it.

Admittedly I haven’t looked at that process since the 2.6.35 days. Is there a resource with the commands you can point me at?

> Admittedly I haven’t looked at that process
> since the 2.6.35 days. Is there a resource with
> the commands you can point me at?

I don't know any site that has the instruction or roadmap for the transition from non-FDT to FDT.

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

I’m just looking for the procedure for setting the mach_type so I can try booting it that way for now.

If I understood what you meant, this mach-type needs to be set in u-boot before booting. arcNumber is included in the data that u-boot passes to the kernel.

terastation_wxl		MACH_TERASTATION_WXL	TERASTATION_WXL		2697

In Debian (possibly stock OS)

fw_setenv arcNumber 2697

or in serial console

setenv arcNumber 2697

And if that alone did not boot. Then you might also set machid to the hex value A89

setenv machid A89

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

I found one of the references I had remembered. It looks like you can also stick it in front of the kernel in some configurations.

devio > /tmp/foo 'wl 0xe3a01c07,4' 'wl 0xe3811027,4'
cat foo /boot/vmlinuz-$ver > /tmp/zImage

I don’t exactly get what that does and haven’t seen a reference to the technique just a couple examples.

If I didn’t know better i’d say they’re adding machine code to load the values in the ATAG registers to run just before the kernel starts.

> devio > /tmp/foo 'wl 0xe3a01c07,4' 'wl
> 0xe3811027,4'
> cat foo /boot/vmlinuz-$ver > /tmp/zImage

That's a really poor way of hacking. It is quite simple to use serial console and set a few variables.

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

Yeah, I think it dates back to the first attempts to boot multiple devices from the same kernel rather than custom compile for every board... way before device trees were standardized. Still, this device requires removing an IC from the board and bridging the resulting gap to enable input from the serial port which makes that route unappealing to me in the short term.

oddly enough it looks like flash-kernel supports this method too:

Machine: QNAP TS-109/TS-209
Kernel-Flavors: orion5x marvell
Machine-Id: 1565
Mtd-Kernel: Kernel
Mtd-Initrd: RootFS1
U-Boot-Kernel-Address: 0x00c08000
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes

# output ARM instructions to set machine number; argument is the decimal
# machine number as found in linux/arch/arm/tools/mach-types
set_machine_id() {
	local machine_id="$1"
	local high
	local low

	if [ -z "$machine_id" ]; then
		return
	fi

	high="$(printf "%02x" $(($machine_id / 256)))"
	low="$(printf "%02x" $(($machine_id % 256)))"

	devio "wl 0xe3a01c$high,4" "wl 0xe38110$low,4"
}

I remain somewhat baffled how little information I've found on the subject, still that gives me enough info to give this a try.

1000001101000 Wrote:
-------------------------------------------------------
> Yeah, I think it dates back to the first attempts
> to boot multiple devices from the same kernel
> rather than custom compile for every board... way
> before device trees were standardized. Still, this
> device requires removing an IC from the board and
> bridging the resulting gap to enable input from
> the serial port which makes that route unappealing
> to me in the short term.
>
> oddly enough it looks like flash-kernel supports
> this method too:
>

> Machine: QNAP TS-109/TS-209
> Kernel-Flavors: orion5x marvell
> Machine-Id: 1565
> Mtd-Kernel: Kernel
> Mtd-Initrd: RootFS1
> U-Boot-Kernel-Address: 0x00c08000
> Required-Packages: u-boot-tools
> Bootloader-Sets-Incorrect-Root: yes
>

>

> # output ARM instructions to set machine number;
> argument is the decimal
> # machine number as found in
> linux/arch/arm/tools/mach-types
> set_machine_id() {
> 	local machine_id="$1"
> 	local high
> 	local low
> 
> 	if [ -z "$machine_id" ]; then
> 		return
> 	fi
> 
> 	high="$(printf "%02x" $(($machine_id / 256)))"
> 	low="$(printf "%02x" $(($machine_id % 256)))"
> 
> 	devio "wl 0xe3a01c$high,4" "wl 0xe38110$low,4"
> }
> 
>

>
> I remain somewhat baffled how little information
> I've found on the subject, still that gives me
> enough info to give this a try.

We’ve booted the same customed Kirwood kernel for all of these Kirkwood boxes back around 2013, by setting arcNumber env. I think you meant mainline kernel?

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

1000001101000,

> Still, this
> device requires removing an IC from the board and
> bridging the resulting gap to enable input from
> the serial port which makes that route unappealing
> to me in the short term.

I see. This hack became necessary without serial console.


> I remain somewhat baffled how little information
> I've found on the subject, still that gives me
> enough info to give this a try.

I think you've guessed correctly previously about the register (register r1). This trick most likely only works with Marvell u-boot circa 2009 (or one similar to it). The r1 location seems odd until I remember that u-boot reserved 14MB RAM in this version. And the ATAG offset is 0x100.

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

Interesting, That's good to know.

Buffalo also has the unfortunate habit of not posting their u-boot source. I wouldn't mind but they do a whole bunch of interesting things in u-boot. My new favorite is that they trigger a watchdog timer in a separate microcontroller before booting the kernel and then rely on the firmware to turn it off if the system boots successfully. It took me an embarrassingly long time to figure out why the TS3400 was rebooting every 4 hour hours like clockwork.

I think I have everything I need to attempt to boot this device on the mainline kernel "the old fashioned way". It looks like it worked for the 2-bay model (at least as recently as Lenny). I think I'll start with Jessie and work my way forward in case the underlying code broke at some point without anyone noticing. If I have to go back further than that I may loose interest before I get anywhere.

1000001101000 Wrote:

> My new favorite is that they trigger a
> watchdog timer in a separate microcontroller
> before booting the kernel and then rely on the
> firmware to turn it off if the system boots
> successfully. It took me an embarrassingly long
> time to figure out why the TS3400 was rebooting
> every 4 hour hours like clockwork.

Yeah, you could turn it off if you have their u-boot GPL source!

> I'll start with Jessie and work my way
> forward in case the underlying code broke at some
> point without anyone noticing. If I have to go
> back further than that I may loose interest before
> I get anywhere.

I think this is too long a way to bring it up, just because you lack serial console. You'll have to hard code a lot of parameters and try each build until you get it right. If you had serial console, you can watch the current mainline kernel booting and figure out along the way how to get through each hurdle quite easily.

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