Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX)

Howdy,
I've spent some time over the past year working on adapting the device tree for the the Linkstation 421DE found here to work with the Vanilla Kernel provided by Debian Stretch and also adapt it for the other Armada-370 Buffalo devices. Using these device trees along with the ssh-based network-console installer image provided by Debian it is now possible to install Debian Stretch on these devices fairly easily.

I've published the necessary files and instructions to Github:

https://github.com/1000001101000/Debian_on_Buffalo

I've created device trees and tested for the following devices:

Linkstation LS210
Linkstation LS220DE
Linkstation LS410
Linkstation LS420D
Linkstation LS421DE
Linkstation LS441DE
Terastation TS1200D
Terastation TS1400D
Terastation TS1400R

I'm currently working on making similar device trees for Debian Buster but there are issues with the Debian Kernels 4.17+ that have stalled that work somewhat. If someone is interested in trying those with the 4.18 kernel/MVEBU package in the meantime, let me know (they should work).

1000001101000 Wrote:
-------------------------------------------------------
> Howdy,
> I've spent some time over the past year
> working on adapting the device tree for the the
> Linkstation 421DE found
> here
> to work with the Vanilla Kernel provided by Debian
> Stretch and also adapt it for the other Armada-370
> Buffalo devices. Using these device trees along
> with the ssh-based network-console installer image
> provided by Debian it is now possible to install
> Debian Stretch on these devices fairly easily.
>
> I've published the necessary files and
> instructions to Github:
>
> https://github.com/1000001101000/Debian_on_Buffalo
>
> I've created device trees and tested for the
> following devices:
>
> Linkstation LS210
> Linkstation LS220DE
> Linkstation LS410
> Linkstation LS420D
> Linkstation LS421DE
> Linkstation LS441DE
> Terastation TS1200D
> Terastation TS1400D
> Terastation TS1400R
>
> I'm currently working on making similar device
> trees for Debian Buster but there are issues with
> the Debian Kernels 4.17+ that have stalled that
> work somewhat. If someone is interested in trying
> those with the 4.18 kernel/MVEBU package in the
> meantime, let me know (they should work).

Very cool! Pardon me for forgeting this post (too many on my tabs:)

Let me take a look at your DTS files. And perhaps I could add them to the MVEBU kenel release for general consumption.

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

Right on.

I'm currently working on making some adjustment to the Stretch (4.9.XX) device trees to address some hardware differences that have come up in testing. Once I get those changes finished I'll make the adjustments needed to account for the binding changes needed for the 4.18 kernel and try them out with your kernel. I'll plan on using that for my testing while I wait for Debian to move to 4.19 from EXPERIMENTAL to TESTING (and update their installer image with it).

Do you know of a thread/person who is working on armada-370 support on 4.18+ kernels? In my initial testing (once I figured out why the Debian Vanilla Kernel wouldn't boot) I discovered that the Marvell temperature sensor drive for the 370 seems to have been broken in 4.19, or at least changed in a way that requires a change to the device trees.

Talk to you soon,

1000001101000,

> Once I get those changes finished I'll make the
> adjustments needed to account for the binding
> changes needed for the 4.18 kernel and try them
> out with your kernel.

That would be great!

> Do you know of a thread/person who is working on
> armada-370 support on 4.18+ kernels? In my initial
> testing (once I figured out why the Debian Vanilla
> Kernel wouldn't boot) I discovered that the
> Marvell temperature sensor drive for the 370 seems
> to have been broken in 4.19, or at least changed
> in a way that requires a change to the device
> trees.

Yes. I'm talking to wacke right now on the Armada IO Coherency topic:

https://forum.doozan.com/read.php?3,43214

Let's see if wacke's box has temp sensor and has the same problem.

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

Fortunately Debian has now moved to kernel 4.19 which includes all the fixes required to boot armada-370 devices again and even fixes the temperature sensor issue. I've created new device trees for the 4.19 kernel which can be found at https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/device_trees

I attempted to install your linux-4.19.1-mvebu-tld-1 kernel on a device using the updated device tree but it failed to boot. I didn't have a serial console set up so i didn't capture any useful information from the attempt. I took a look at your config and couldn't see any obvious reason why it should fail.

I'll try again and see if i can figure out what's going on when I get some time.

In the meantime if anyone is interested in running Jessie/Stretch/Buster on any of these devices I have Installer images on my github page for each of them.

> I attempted to install your
> linux-4.19.1-mvebu-tld-1 kernel on a device using
> the updated device tree but it failed to boot. I
> didn't have a serial console set up so i didn't
> capture any useful information from the attempt. I
> took a look at your config and couldn't see any
> obvious reason why it should fail.

Usually it does not have anything to do with the config. Very often, the size of the kernel files uImage and uInitrd are the reason you have booting problem. To boot a custom kernel with stock u-boot, we need to adjust the envs for those load addresses (almost aways, stock u-boots are not robust enough in this matter).

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

fortunately these devices don't have that issue, in my previous testing I confirmed they can handle kernels up to 11mb (I only tested up to 6mb) and initrd > 75mb.

I hooked up the serial console and tried again, unfortunately I didnt get anything past "Starting Kernel ...".

most of the times I've had that problem have been an issue with the dtb I was testing, considering it's a known working dtb It could be a mis-match with the kernel... though I would think yours is build from basically the same source from a bindings standpoint.

if you get a chance, could you grab some of my dts files and try building them with your source and see if any errors/warning are generated?

are there any other troubleshooting steps you can think of that I should try at this point?

> if you get a chance, could you grab some of my dts
> files and try building them with your source and
> see if any errors/warning are generated?

Sure. I'll do that when I get back home in a couple weeks.

> I hooked up the serial console and tried again,
> unfortunately I didnt get anything past "Starting
> Kernel ...".

This is most likely the uInird problem.

1. Interrupt u-boot at countdown and add earlyprintk=serial to the end of the bootargs in serial console.

If you're not sure about the syntax, please get the listing of envs at the u-boot prompt:

printenv

And post the entire serial console log until the end of the printenv output. I'll adjust the envs so we can see the error during kernel starting.

2. And go ahead, run boot to boot into Debian.

====

And if you want me to double check the error in the boot log then later post the entire serial console log.

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

I forgot you're out of town, I can probably try builing against your source. I've got your patch and config, which version of the source are you currently using?

The device I'm using doesn't permit input on the console ( I beleive I need to remove/bypass a diode to re-enable it). It'll be a while before I get a chance to try out that operation. I suppose I could make the change from an already working debian install, normally I avoid making environment changes without a way to recover but this one has a seperate usb boot option which should provide an avenue of recovery provided I don't break more than the idebootcmd. I'll look into that and report back when I get that far.

can you elaborate on what you think could be wrong with the initrd? I would expect to get past uncompressing the kernel before a bad initrd would cause trouble but I don't have a ton of experience troubleshooting that piece.

here's the console output and envvars:

it any key to stop autoboot:  0                                                                             
Loading file "/initrd.buffalo" from ide device 2:1 (primary)                                                 
8257580 bytes read                                                                                           
Loading file "/uImage.buffalo" from ide device 2:1 (primary)                                                 
4519720 bytes read                                                                                           
<<stop_sound>>                                                                                               
## Booting kernel from Legacy Image at 01200000 ...                                                          
   Image Name:   kernel 4.19.1-mvebu-tld-1                                                                   
   Created:      2019-01-12  16:28:59 UTC                                                                    
   Image Type:   ARM Linux Kernel Image (uncompressed)                                                       
   Data Size:    4519656 Bytes = 4.3 MiB                                                                     
   Load Address: 00008000                                                                                    
   Entry Point:  00008000                                                                                    
   Verifying Checksum ... OK                                                                                 
## Loading init Ramdisk from Legacy Image at 02600000 ...                                                    
   Image Name:   ramdisk 4.19.1-mvebu-tld-1                                                                  
   Created:      2019-01-12  16:28:59 UTC                                                                    
   Image Type:   ARM Linux RAMDisk Image (uncompressed)                                                      
   Data Size:    8257516 Bytes = 7.9 MiB                                                                     
   Load Address: 00000000                                                                                    
   Entry Point:  00000000                                                                                    
   Verifying Checksum ... OK                                                                                 
   Loading Kernel Image ... OK                                                                               
OK                                                                                                           
                                                                                                             
Starting kernel ...

CASset=min
DEVICEID=_tysgkFFSXXXXXXXXXXXXXX
MALLOC_len=5
MPmode=SMP
SerialNo=80068XXXXXXXXXX
amp_enable=no
autoload=n
baudrate=115200
bootargs_end=:10.4.50.254:255.255.255.0:DSMP:eth0:none
bootargs_mtd=ubi.mtd=1
bootargs_root=panic=5
bootcmd=for i in $bootorder; do run ${i}bootcmd; done
bootcommon=setenv bootargs $console $bootargs_root $mtdparts $bootargs_mtd $opt_arg $buffalo_ver $uboot_date $bootsystem earlyprintk;bootm 0x01200000 0x02600000
bootdelay=3
bootorder=ide nand tftp 
buffalo_ver=BOOTVER=0.18
cacheShare=no
console=console=ttyS0,115200
disL2Cache=yes
disL2Prefetch=yes
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaDCPref=yes
enaFPU=yes
enaICPref=yes
enaLPAE=no
enaMonExt=no
enaWrAllo=no
eth1addr=10:6F:3F:CE:XX:XX
eth1mtu=1500
eth2addr=00:50:43:fe:XX:XX
eth2mtu=1500
ethact=egiga0
ethaddr=10:6F:3F:CE:XX:XX
ethmtu=1500
ethprime=egiga0
idebootcmd=ext2load ide 0:1 0x01200000 /$kernel;ext2load ide 0:1 0x02600000 /$initrd;setenv bootsystem;run bootcommon
image_name=uImage
initrd=initrd.buffalo
ipaddr=192.168.11.150
kernel=uImage.buffalo
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:-(nandubifs)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:fe:f5:fe
nandEcc=1bit
nandbootcmd=dispboot nand;mtdpart;ubi part nandubifs;ubifsmount nandubifs;ubifsload 0x01200000 $kernel;ubifsload 0x02600000 $initrd;setenv bootsystem nandboot=yes;run bootcommon
netbsd_en=no
netmask=255.255.255.0
pcieTune=no
pexMode=RC
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
serverip=192.168.11.1
setL2CacheWT=no
stderr=serial
stdin=serial
stdout=serial
tftpbootcmd=dispboot tftp;dhcp;tftp 0x01200000 $kernel;tftp 0x02600000 $initrd;setenv bootsystem tftpboot=yes;run bootcommon
uboot_date=UBOOT_DATE="2015/08/17"
usb0Mode=host
usb1Mode=host
usb2Mode=host
usbActive=0
usbbootcmd=dispboot usb;for i in 1 2 3 ;do setenv usbActive $i;usb reset;fatload usb 0 0x01200000 /$kernel;fatload usb 0 0x02600000 /$initrd;if fatIsSettingRecoveryDisk usb 0;then setenv bootsystem usbboot=yes mode=rescue;elif fatIsSettingInitializeDisk usb 0;then setenv bootsystem usbboot=yes mode=initialize;else usbboot=yes;fi;run bootcommon;done;ucom_usbbootfail
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
EnableNandBoot=1

> builing against your source. I've got your patch
> and config, which version of the source are you
> currently using?

The kernel version matches the mainline source. So to build linux-4.19.0-kirkwood-tld-1 you'd use linux-4.19.0-kirkwood-tld-1-bodhi.tar.bz2 and the linux-4.19.0 source from kernel.org/pub/linux/kernel/v4.x/

>
> The device I'm using doesn't permit input on the
> console ( I beleive I need to remove/bypass a
> diode to re-enable it). It'll be a while before I
> get a chance to try out that operation.

Perhaps your box RX pin is faulty? It is very rare that the serial console is working one way but not the other.

Basically, assuming you can enter command after you interrupt the countdown

Quote

it any key to stop autoboot: 0

Try

setenv bootcommon 'setenv bootargs $console $bootargs_root $mtdparts $bootargs_mtd $opt_arg $buffalo_ver $uboot_date $bootsystem earlyprintk=serial; bootm 0x01200000 0x02600000'

and then boot

boot

> can you elaborate on what you think could be wrong
> with the initrd? I would expect to get past
> uncompressing the kernel before a bad initrd would
> cause trouble but I don't have a ton of experience
> troubleshooting that piece.

You will need earlyprintk=serial to see the kernel log in serial console when this type of error occur (assuming it isindeed what I suspected). Stock u-boot does not do a good job at reallocating the kernel images in memory, so the possibility of corruption is high. Without earlyprintk=serial, the kernel log is gone when it encounters any serious error such as corrupted initramfs (in memory).

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



Edited 1 time(s). Last edit at 01/13/2019 04:42AM by bodhi.

The model I’m working with (TS3400D) helpfully has a serial port on the front which outputs the console, but they disconnect or otherwise inhibit the RX pin. Most other models don’t have any easily accessible UART header (or if they do it’s disconnected). One of these days I’ll put more effort into working around those issues but so far I’ve just lived without being able to directly access the bootloader/console.

You’ve given me some things to try next time I’m home between building the dtbs against your kernel and adding earlyprintk to the bootenv (or compiling it into the kernel).

I’ll let you know how it goes

I forgot this is MVEBU kernel :)

To build the linux-4.19.1-mvebu-tld-1 kernel, you would use linux-4.19.1-mvebu-tld-1-bodhi.tar.bz2 and the linux-4.19.1 source from kernel.org.

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

Thank you for your hard work.
I am trying to use debian Stretch on my TS1200D
I have
1) bootet the NAs with your TFTP-Files
2) partitioned the disk with 3 new partitions
3) followed the instruktions from the installer

But now i am staying still on

Finishing the installation
13%
Running preseed...


Is there a configuration file on your server missing.



I am searching the error:

from /var/log/syslog


Mar 17 11:48:24 finish-install: info: Running /usr/lib/finish-install.d/07preseed
Mar 17 11:48:24 preseed: running preseed command preseed/late_command: cp /source/phytool /target/usr/local/bin/; cp /source/*.dtb /target/etc/flash-kernel/dtbs/; cp /source/*.db /target/usr/share/flash-kernel/db/; cp /source/in_target_finish.sh /target/tmp/; /source/late_devspec.sh; echo "BOOT=local" > /target/usr/share/initramfs-tools/conf.d/localboot; echo mtdblock >> /target/etc/modules; echo m25p80 >> /target/etc/modules; echo "/dev/mtdblock1 0x00000 0x10000 0x10000" >> /target/etc/fw_env.config; mount -t proc none /target/proc/; mount -t sysfs none /target/sys/; /source/hardcode_mac.sh; in-target /tmp/in_target_finish.sh; in-target udevadm trigger; in-target update-initramfs -u; /source/reboot_prep.sh


Mar 17 11:48:24 log-output: cat: can't open '/source/eth1-mac.txt': No such file or directory


On which point i have to create this file?

i found the file for eth0 with my correct mac adress



Edited 2 time(s). Last edit at 03/17/2019 07:25AM by oxygen8.

Good to hear from you!

That file gets generated automatically but only if needed, it shouldn’t be triggering an error for that device. I must have made a mistake when I updated that script. I’m confused how I missed that in my testing but it should be an easy fix.

What version of debian are you trying to install?

Stretch

I have rebooted the nas with a second console and can now successfully login

thank you

excellent!

I don't beleive there will be any bad effects from getting interrupted at that point, the only other tasks after that are specific to the ts3000 and ls441. Either way I'll try to get a fix out in the next day or so.

I am compiling my tools now.
Looks good.
Thank you.

The fan is running at full speed.
I will try installing the tools later.

I got the same error on my ts1200d, i'm still not clear why I didn't get it when I did my original testing.... oh well

I posted a new version that corrects the issue

I have installed fancontrol

this controls the fan to cool the cpu
on all nas it is recommendet to control the fan to cool the disks

buffalo uses smartctl to read out the disk temp
but the firmware has a bug and the fan allway runns at slow speed
i had fixed this with a script

HD_TEMP=`smartctl -A /dev/sda | awk '/^194/ { print($10) }'`

if [ $HD_TEMP -lt 42 ]; then
   if [ $HD_TEMP -lt 35 ]; then
      echo slow >/proc/buffalo/gpio/fan/control
   else
      echo fast >/proc/buffalo/gpio/fan/control
   fi
else
   echo full >/proc/buffalo/gpio/fan/control
fi

from
https://forum.nas-hilfe.de/buffalo-technology-nas-anleitungen/luefterregelung-fuer-die-400er-serie-t2422.html


Now i am searching for the new flags to control the fan

root@debian:/usr/src# echo 10 >/sys/devices/platform/gpio-fan/hwmon/hwmon1/pwm1
-su: /sys/devices/platform/gpio-fan/hwmon/hwmon1/pwm1: Permission denied

looks like fancontrol reserves access to the pwm once you enable it. Just stopping fancontrol doesn't seem to release it but when I removed fancontrol and reboot I'm able to access it manually.

if you're planning to control it manually/by a custom script you'll probably want to remove fancontrol anyway.



Edited 1 time(s). Last edit at 03/17/2019 02:10PM by 1000001101000.

Thank you again

anytime!

let me know if you run across anything I should add to the installer/instructions.

one mistake



Edited 2 time(s). Last edit at 03/17/2019 09:03PM by oxygen8.

The installer is just the debian netboot installer with a few scripts added to:
-retrieve the mac address from the uboot parameters and set it in the interfaces file
-install flash-kernel and copy over all the files to make it work (device trees and the db file)
-configure update-initramfs to work with the kernel params passed by stock uboot
-a script to ensure the ls441de reboots rather than shuts down after the install
-a script to setup the lcd display on the ts3000s

I didn’t copy anything over from the buffalo firmware. acp_commander, lsupdate etc won’t work because buffalo’s services aren’t there to communicate with. If it did show ip in any of those it would be a sign you somehow booted into em mode (possibly from the on-board flash).

I’ve never had a root password randomly change and I don’t know of any way that would happen. How do you know it changed? Are tou getting some sort of authentication error?

I usually reformat /boot when I run the install. I’d defintely recommend getting rid of the buffalo files though I wouldnt think they would hurt anything.

the LS4XX serie sets an unnown root password on every reboot ore on switching settings with the webif
my quick and dirty solution was to set my password every 5 mins with a script

from
http://forum.nas-hilfe.de/buffalo-technology-nas-anleitungen/ls420-serie-root-kennwort-wird-von-buffalo-ueberschrieben-t2232.html


i had transfered this script to the new nas
and this has manipulated my testpassword

thats why a have edited my post to "one mistake"

Ah, good. You had me very confused.

1000001101000,

> https://github.com/1000001101000/Debian_on_Buffalo

Is there a way to just copy/download the DTS file in this folder? your GitHub has lot of large files that make cloning the git a time consuming process!

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

Yeah, the device trees are located in:
Stretch/device-trees/
Buster/device-trees/
etc

I am searching now for a way to enable the usb3 port on the front of my ls421D

# lspci
01:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)

it has no power



Edited 1 time(s). Last edit at 03/19/2019 02:45PM by oxygen8.

It should work immediately once you've got Debian installed. I use mine quite a bit.

Are you using Stretch on that one too?

can you verify the output of "/proc/device-tree/model" (usb3 is only enabled in the ls421d device tree)